My basic problem is to generate 2d renders of 3d objects, such as one could accomplish with openGL or DirectX. However I have no interest in displaying the rendered objects to the screen, only to generate the shaded/ textured/ rotated images as bitmaps (not necessarily written to disk). This process is likely to be a problematic bottleneck in my design, so I would prefer to keep my solution as compact as possible (ie, don't waste the time sending the image to the screen), and would be most pleased if I could make use of hardware-accelerated rendering. Does anyone know of a convenient library or tool to help in this?
Right now I would prefer a C/C++ option, however speed is what I'm going for, so I'm willing to deal with ASM/ super optimized anything if it gets what I want the fastest.
What you need is a so called technique "rendering to texture". With OpenGL you can do it very easy. Take a look at example here: http://www.songho.ca/opengl/gl_fbo.html#example
You can do this using "render to texture"
This process is likely to be a problematic bottleneck in my design, so I would prefer to keep my solution as compact as possible (ie, don't waste the time sending the image to the screen)
If you want rendering to be fast, you want to use the GPU for this. Sending a image to the screen comes for free with those things. But reading an image back to the CPU memory, that is actually quite a bottleneck. But unavoidable in you case probably.
Related
I have used OpenGL pretty exclusively for all my rendering, to the point that I'm unaware of any other way to write pixels to a window unfortunately.
This is a problem because my current project is a work tool that emulates an LCD display (pixel perfect, 2D, very few pixels are touched each frame, all 'drawing' can be done with memcpy() to a pixel buffer) and I feel that OpenGL might be too heavy for this, but I could absolutely be wrong in that assumption.
My goal is to borrow as little CPU time as possible. What's the best way to draw pixels to a window, in this limited way, on a modern typical machine running windows 10 circa 2019? Is OpenGL suited for this type of rendering, or should I adopt another rendering method in this case? And if so, what would that method be?
edit:
I should also mention, OpenGL can be used right away for me. If rendering textured triangles with an optimal setup is the fastest method, then I can already do that. Anything that just acts as an API over OpenGL or DirectX will likely be worse in my case.
edit2:
After some research, and thanks to the comments, I think I may just use OpenGL with Pixel Buffer Objects to optimize pixel uploads and keep rendering inexpensive.
I am developing a application with OpenGL+GLFW and Linux as a target platform.
The default rasterizing has VERY strong aliasing. I have implemented FXAA on top of my pipeline and I still got pretty strong aliasing. Especially when there's some kind of animation or movement, the edges of meshes are flickering. This literally renders the whole project useless.
So, I thought I would also add a supersampling and I have been trying to implement it for two weeks already and still can't make it work. I start to think it's not possible with the combination PyOpenGL+GLFW+Ubuntu18.04.
So, the question is, can I do a supersampling by hand (without OpenGL extentions)? At the end of my (deferred) rendering pipeline I save all the data from different passes to the hard drive, so I thought I would do something like this:
Render the image with 2x/3x resolution to the texture.
Save the texturebuffer to the array.
Get the average pixel's value from each 2x2/3x3/4x4 block
of this array.
Save it to the hard drive.
Obviously, it's gonna be slower than mulstisampling with OpenGL extention and require more memory, but I don't need high fps and I have a pretty small resolution (like 480x640 or similar) so it might work out.
Do you guys have any thoughts about it? I would be glad to any advice.
I am creating a video player application and I was wondering what would be the optimize way to handle the media changing action.
For now I am using 2xPBOs as explain here: OpenGL Pixel Buffer Object (very awesome website by the way) and some textures. In order to keep perfect colour and aspect, I need my PBOs and my textures to be the same size as my video clip. (The resize is done only once during the shadder stage).
So basically, if the actual media is like 1920x1080 but the next one on the playlist is 1280x720 what should I do? I am thinking of 2 solutions right now:
Resizing PBOs and Textures on the fly
Recreating everything, my whole OpenGLPreviewWidget
I know the solution 1 is include in solution 2 but, should I recreate a openGL context, windows, etc. or, because it's too slow, just resizing would do it?
Creating a new context is a fairly heavy weight operation, at least compared to most other things you would do when you use OpenGL. So unless you have a good reason why you need a new context, I would avoid it.
Re-allocating the PBOs and objects is easy enough. As you already pointed out, you'll end up doing this in either case. If that alone is enough, I think that's the way to go.
Background
I work on the game Bitfighter. We're still compatible with OpenGL 1.1 and compile for OSX, Windows, and Linux.
We use vector graphics for everything, including text rendering and manipulation. We use a slightly-modified variation of 'FontStrokeRoman' from GLUT, which is just a bunch of static lines. We like this as it seems to perform very well, easy to rotate/scale/manipulate. We also allow for in-game chat so text is drawn on the fly.
Problem
We want to use more/different fonts.
We've found several other fonts we like, but they are all TTF-type fonts that are built as polygons (with curves, etc.) instead of strokes or spines. This brings up a few problems:
We'd have to use textures (which we've avoided so far in the game)
They're not easily resizable/rotatable/etc.
Performance is significantly less (theoretically?)
We've experimented with converting the TTF fonts to polygon point arrays and then triangulating the fill. This however has been difficult to render nicely - pixel hinting/anti-aliasing seems difficult to do in this case.
We've even experimented with skeletonize-ing the polygon fonts using libraries like 'campskeleton', so we can output a vector-stroke font (with not much success that looks good).
What should we do?
I know this question is somewhat general. We want to keep performance and text manipulation abilities but be able to use better fonts. I am open to any suggestion in any direction.
Some solutions could be answers to the following:
How do we properly anti-alias polygon-based text and still keep performance?
Do textures really perform worse than static point arrays? Maybe I have a faulty assumption
Can textured fonts be resized/rotated in a fast manner?
Something entirely different?
After some convincing (thanks Serge) and trying out several of the suggestions here (including FTGL that uses freetype), we have settled on:
Font-Stash which uses stb_truetype
This seemed perfect for our game. Rendering performance was comparable to the vector-based stroke font we used - textured quads really are not that slow, once generated, and the caching from Font-Stash helps immensely. Also, the use of stb_truetype allowed us to not require another dependency in the game across all platforms.
For what its worth, this solution was roughly an order of magnitude faster than using FTGL for true-type fonts, probably because of the caching.
Thanks for the suggestions and pointers.
Update
The Font-Stash link above was a fork of the original here. The original has since been updated, has added some of the features that the fork, and can allow different rendering back-ends.
I'm no OpenGL expert, or graphical expert in general.
And, really, Raptor, I -hate- to be the guy that says this, because I know how you feel right now.
I really hate to say it, but honestly, I'd just give TTF fonts a shot, using their textures and polygons as they were intended. I doubt that such a usage would truly be detrimental towards your performance these days. It would likely be more valuable to save time to use them as is, rather than spending time to experiment around for some clever solution that more fits your desires.
I doubt that text drawing using polygons/textures would be detrimental, whatsoever, to you performance. This especially applies for today's computers. How many years back, technologically, do you intend on supporting with your application? Or perhaps you wish to run it on the Raspberry PI as well? Or other mobile platforms that do not have high graphical capabilities? Support of any of these could, perhaps, invalidate my claims.
But, like I said, I really hate to be the guy that suggests you to trudge forward as is. Because, I've been there, asking for performance advice (sometimes over even tinier things) and just groaning when someone says 'forget about it, the compiler will handle it' or 'computers are so advanced you shouldn't worry about it'. I honestly hope that someone else comes in with experience, and a good answer for you. However, if not, I just want let you know: I cannot foresee the possibility that using TTF, as it was intended, would be detrimental whatsoever to your gameplay performance.
Did you try outline glyph decomposition using freetype FT_Outline_Decompose ?
Freetype is the tool of choice for font rendering and glyph outlines extraction. Hinting is supported and rendering modes allows you to specify that you want antialiazing, hinting, monochrome targets etc.
Freetype also has a built in glyph/bitmaps cache mechanism which may be useful.
Note : OGFLT seems to bridge the gap between freetype and opengl although I never has the chance to use it
I'm currently in the process of designing and developing GUI's for some audio applications made in C++ (using the Juce framework).
So far I've been playing with using bitmap graphics to create custom sliders and dials, by using 'film strip' style images to animate the components (meaning when the user interacts with a slider it triggers a method that changes the offset of a film-strip image to change the components appearance). Depending on the size of the original image and the number of 'frames', the CPU usage level changes quite dramatically.
Firstly, what would be the most efficient bitmap file format to use in terms of CPU consumption? At the moment I'm using PNG images.
Secondly, would it be more efficient to use vector graphics for these kind of graphical components? I understand the main differences between bitmap and vector graphics, but I haven't found any information regarding their CPU usage levels with regard to GUI interaction.
Or would CPU usage be down to the particular methods/functions/libraries/frameworks being used?
Thanks!
Or would CPU consumption be down to the particular methods/functions/libraries/frameworks being used?
Any of these things could influence it.
Pixel based images might take a while to read off of disk the bigger they are. Compressed types might take more time to uncompress. Vector might take more time to render when are loaded.
That being said, I would definitely not expect that your choice of image type to have any impact on its performance. Since you didn't provide a code example it is hard to speculate beyond that.
In general, you would expect that the run-time costs of the images to happen when they are loaded. So whenever you create an image object. If you create an images all over the place, then maybe its expensive. It is possible that your film strip is recreating the images instead of loading them once and caching them.
Before choosing bitmap vs. vector graphics, investigate if your graphics processor supports vector or bitmap graphics. Some things take a long time to draw as vectors.
Have you tried double-bufferring?
This is where you write to a buffer in memory while the display (graphics processor) is loading another.
Load your bitmaps from the resource once. Store them as memory snapshots to avoid the additional cost of translating them from a format.
Does your graphic processor support "blitting"?
Blitting is where the graphics processor can copy a rectangular area in memory (bitmap) and display it along with apply optional operations before displaying (such as XOR with existing bits).
Summary:
To improve your rendering speed, only convert images from the file into a bitmap form once. Store this somewhere. Refer to this converted bitmap as needed. Next, investigate and implement double buffering. Lastly, investigate and use bit-blitting or blitting.
Other optimization rules apply here too, such as reviewing the design, removing requirements, loop unrolling, passing images via pointer vs. copying them, and reduce "if" statements by using boolean logic and Karnaugh (sp?) maps.
In general, calculations for rendering vector graphics are going to take longer than blitting a rectangular region of a bitmap to the screen. But for basic UI stuff, neither should be particularly intensive.
You probably should do some profiling. Perhaps you're redrawing much more frequently than necessary. Or perhaps the PNG is being decoded each time you try to draw from it. (I'm not familiar with Juce.)
For a straight Windows app, I'd probably render vector graphics into a device-dependent bitmap once on startup and then just blit from the bitmap to the screen. Using vector gives you DPI independence, and blitting from a device-dependent bitmap is about the fastest way to paint a block of pixels. I believe the color matching is done when you render to the device-dependent bitmap, so you don't even have the ICM overhead on the screen drawing.
Vector graphics was ditched long ago - bitmap graphics are more performant. The thing is that you can send a bitmap to the GPU once and then render it forever more by a simple copy.
Secondly, the GPU uses it's own texture compression. DirectX is DXT5, I believe, but when the GPU sees the texture, it doesn't care what you loaded it from.
However, a modern CPU even with a crappy integrated GPU should have absolutely no problem with simple GUI rendering. If you're struggling, then it's time to look again at the technique you're using. Perhaps your framework is slow or your use of it is suboptimal.