My idea would be to draw several Graphics objects on memory and combine them when drawing the image.
But I haven't got a precise idea of how to do that. Shall I use GraphicsContainer's? Or save the objects as Metafile's? (these are temporary objects, I would like to keep them on memory)
Simplest method: create multiple bitmaps. Draw what you want to them. Composite them by drawing them back to front.
If you have a lot of text, then using a metafile for those layer(s) may improve the rendering quality somewhat.
Related
I recently came up with an idea that I should make a 3d engine from scratch. I also want to involve as few libraries as possible and keep it low-level. My plan is to create a window using windows.h and then do the math and draw the frame. I tried making something similar before using GDI's functions to draw the polygons one by one but it felt inefficient. I wonder if there is a performant way of drawing a bitmap that I would beforehand fill with pixels using algorithms and such. Or is there a better way of drawing a frame?
I am currently working on a Graphics Engine for a 2D game with OpenGL, but I have issues implementing a viable solution for partial transparency, since opaque objects need to be drawn first, and transparent objects from back to front.
Specifically, I want to be able to pass render commands in an arbitrary order, and let the Engine handle the sorting.
My current approach is that I simply collect all vertices and textures of each transparent object in a sorted list, and at the and of each frame, I simply draw them from this list.
Although I get correct results, this is obviously not a viable solution, due to a lot of copy instructions. In case I have a few thousand partially transparent particles, this approach does not work at all due to its low performance.
I did not find any other way to implement this for 2D Graphics, so my question is: What is the most common approach to this ? Are there any sources where I can read more about this topic?
I use glBlendFunc(GL_SOURCE_ALPHA, GL_ONE_MINUS_SRC_ALPHA) by the way.
In my game, I have about 50 filled-circles with different size and different color distributed full screen, and they continuously resize themselves, creating animation. I'm currently using Shaperenderer to render all of them. This way, all the circles look crisp but it seems like the performance is not very good. Should I make a circle sprite and then render all of them using SpriteBatch instead of Shaperenderer? Will the performance be improved by doing that?
Generally, yes, the SpriteBatch API is more optimized than the ShapeRenderer API in Libgdx. ShapeRenderer is designed for debug overlays and for being easy to use. But, it depends on the specifics of how you use the APIs, too.
The ShapeRenderer API assumes your viewport is mapped to pixel units. It determines the number of vertices to use in the circle based on a rough guess. You may be creating too many vertices for each circle (and you may be able to improve the performance without sacrificing fidelity by reducing the number of vertices computed).
For any specific case though, it makes sense to profile your code and see where the time is actually being spent before optimizing.
Ok, I have a renderer class which has all kinds of special functions called by the rest of the program:
DrawBoxFilled
DrawText
DrawLine
About 30 more...
Each of these functions calls glBegin/glEnd separably, which I know can be very inefficiently(its even deprecated). So anyways, I am planning a total rewrite of the renderer and I need to know the most efficient ways to set up the functions so that when something calls it, it draws it all at once, or whatever else it needs to do so it will run most efficiently. Thanks in advance :)
The efficient way to render is generally to use VBO's (vertex buffer objects) to store your vertex data, but that is only really meaningful if you are rendering (mostly) static data.
Without knowing more about what your application is supposed to render, it's hard to say how you should structure it. But ideally, you should never draw individual primitives, but rather draw the contents (a subset) of a vertexbuffer.
The most efficient way is not to expose such low-level methods at all. Instead, what you want to do is build a scene graph, which is a data structure that contains a representation of the entire scene. You update the scene graph in your "update" method, then render the whole thing in one go in your "render" method.
Another, slightly different approach is to re-build the entire scene graph each frame. This has the advantage that once the scene graph is composed, it doesn't change. So you can call your "render" method on another thread while your "update" method is going through and constructing the scene for the next frame at the same time.
Many of the more advanced effects are simply not possible without a complete scene graph. You can't do shadow mapping, for instance (which requires you to render the scene multiple times from a different angle), you can't do deferred rendering, it also makes anything which relies on sorted draw order (e.g. alpha-blending) very difficult.
From your method names, it looks like you're working in 2D, so while shadow mapping is probably not high on your feature list, alpha-blending deferred rendering might be.
I am working on a simple CAD program which uses OpenGL to handle on-screen rendering. Every shape drawn on the screen is constructed entirely out of simple line segments, so even a simple drawing ends up processing thousands of individual lines.
What is the best way to communicate changes in this collection of lines between my application and OpenGL? Is there a way to update only a certain subset of the lines in the OpenGL buffers?
I'm looking for a conceptual answer here. No need to get into the actual source code, just some recommendations on data structure and communication.
You can use a simple approach such as using a display list (glNewList/glEndList)
The other option, which is slightly more complicated, is to use Vertex Buffer Objects (VBOs - GL_ARB_vertex_buffer_object). They have the advantage that they can be changed dynamically whereas a display list can not.
These basically batch all your data/transformations up and them execute on the GPU (assuming you are using hardware acceleration) resulting in higher performance.
Vertex Buffer Objects are probably what you want. Once you load the original data set in, you can make modifications to existing chunks with glBufferSubData().
If you add extra line segments and overflow the size of your buffer, you'll of course have to make a new buffer, but this is no different than having to allocate a new, larger memory chunk in C when something grows.
EDIT: A couple of notes on display lists, and why not to use them:
In OpenGL 3.0, display lists are deprecated, so using them isn't forward-compatible past 3.0 (2.1 implementations will be around for a while, of course, so depending on your target audience this might not be a problem)
Whenever you change anything, you have to rebuild the entire display list, which defeats the entire purpose of display lists if things are changed often.
Not sure if you're already doing this, but it's worth mentioning you should try to use GL_LINE_STRIP instead of individual GL_LINES if possible to reduce the amount of vertex data being sent to the card.
My suggestion is to try using a scene graph, some kind of hierarchical data structure for the lines/curves. If you have huge models, performance will be affected if you have plain list of lines. With a graph/tree structure you can check easily which items are visible and which are not by using bounding volumes. Also with a scenegraph you can apply transformation easily and reuse geometries.