Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am aware that similar questions have been asked many times before. However, this is a different case.
I am writing a game in C++ using SDL2. Currently, all objects draw themselves. They do this because they all draw slightly differently.
For instance, a Button contains a rectangle, drawn with SDL_RenderFillRect();
Buttons also contain text, which are drawn using SDL_RenderCopy(), which takes a texture generated by SDL_TTF as a parameter.
Additionally, a MapView widget (basically a grid that can load a tilemap) draws the grid out using a 'for' loop containing horizontal and vertical SDL_RenderDrawLine() calls.
Finally, the tiles themselves are stored as textures, drawn using SDL_RenderCopy().
I understand that it is generally preferable to NOT have objects draw themselves. However, because there is so much variation in how the objects are drawn, I'm not sure of another way!
I thought it might be possible to have a GetTexture() function for each object, and the ones using textures could simply 'return texture', while the geometric objects could generate a texture. This gets complicated with my MapView object, because the grid is constantly updated when the user navigates around the game world (an offset value is changed and the grid is redrawn when moved).
Like so many questions of this type the answer is: it depends on your program.
If you are only every going to draw it the same way using SDL, then no reason why not. Another alternative might be to have a specific rendering class for each object, but that's doubling the effort. Having all your rendering code in a single class or function works fine too, but it gets big and complicated fast.
It's a judgement call based on the complexity of your code and what you want to do with it in the future, and my advice is to choose the simplest solution. As long as you've considered the potential downsides, you can make an educated decision.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In my OpenGL projects I have always used glDrawElements or glDrawElementsBaseVertex with GL_TRIANGLES. When rendering a complex object I can, for example sort meshes based on the material index, update textures and uniforms and call glDrawElements for each group.
I have started exploring other draw commands. I wonder when glMuliDrawElements is useful. I have found the following example. There glMulitDrawElements is used with GL_TRIANGLE_STRIP and is in fact a equivalent for primitive restart functionality. That is clear.
When glMuliDrawElements/glMultiDrawArrays with GL_TRIANGLES may be useful ? Could you provide please some example ?
You would use them when you have multiple, discontiguous ranges of primitives to draw (without any state changes between them).
The availability of gl_DrawID in vertex shaders makes it possible to issue multiple draws in such a way that the VS can index into some memory to find the specific per-model data for that rendering call. So in that event, you could draw dozens of entirely separate models, using different transforms stored in a buffer, all with the same draw call.
So long as you can put their per-model data in a buffer object indexable by the draw identifier (and so long as all of these models use the same vertex format and buffer storage), you could render much of the entire scene in a single call.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I am trying to build an .obj file importer that renders said model to the screen.
At present I have imported the vertices and they are stored in a
std::vector<vec3> vertices;
My renderer class quite large so I'll link github instead of posting it here.
https://github.com/rob-DEV/OpenGL-Model-Viewer/blob/master/OpenGL-Model-Viewer/src/graphics/renderer/renderer.cpp
So at line 41 in renderer.cpp. I submit these vertexs to the renderer. Originally I just drew triangles, but I would like to take advantage of GL_ELEMENTS
My question is how (if possible) can I calculate these indices from a list of vertices? I have tried to find duplicates and do so when the model is loaded but i don't know how to map them.
Using mapped buffers (by glMapBuffer) does not work in your case.
For example, if you want to know if a vertex has been already mapped (a duplicate) you should read all of currently mapped vertices, which is slow.
If you want to use a sorted array (so fast binary search can be used) then many portions of that mapped buffer must be re-written during the sorting/storing process. Slow too.
A better option is to build your sorted vertices array on your own, on normal RAM. Be adviced of searching issues due to numerical matters when comparing two floats.
On a second pass each index is just the position of the current vertex. Same advice for numerical issues.
Data can be sent to the GPU by two simple glBufferSubData, one for vertices (and their colors and normals and etc) and another one for the indices.
If the object moves (and you prefer to update coordinates instead of use a translation matrix) then it's right to use a mapped buffer with new coordinates (as you currently do). Indices don't change, so they don't need to be updated.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been using pixels as units for aspects of my game such as movement, but I've been told that this is a bad practice. However, I've never seen a good explanation on what I'm supposed to do instead. Can somebody provide a good explanation on how to handle units in my games?
It doesn't matter what units you use; they can be completely arbitrary. The only thing that you need to do is make sure that they are not fixed to the screen pixels, because you later find out you want to change the scale of things that are displayed. It's OK if the conversion factor happens to be 1; just make sure that the conversion exists, so that you can change it if you have reason to later.
(And, as a practical matter, don't make the conversion exactly 1 because that hides bugs if you forgot to convert in one place.)
For 3D realistic games, a common unit is "1 meter". Real world units don't matter, but the idea is to use a unit that is similar to the size of objects in your world.
For tile-based or voxel-based games, a common unit is the width of one tile. This also allows you to omit some conversions, but you're much less likely to have a problem tying to tiles than to pixels because tiles affect the game rules anyway.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
This is a question about 3D programming in general, but I'm learning OpenGL if that makes the answer any different. What I wonder is if all of the work in displaying a image always has to start from scratch for each new frame, or if there's some way to save intermediate data that could be reused when rendering the next frame, instead of having to be recomputed? Let's say you're standing right next to a mountain, then the stuff on the other side of the mountain are occluded by the mountain, there could be a lot of stuff on the other side of the mountain that simply doesn't have to be rendered because it can't be seen. Now assume that your character can't walk particularly fast, then there's no way that the stuff on the other side of the mountain could be visible already in the next frame, or maybe not even the next 100 frames. Is it possible to avoid having to do the same occlusion check in each frame?
The problem you're referring to is called "hidden surface removal" and "occlusion culling".
In realtime graphics it's usual to rerender each frame from scratch. However every good renderer will omit all the things that are definitively not visible. There are various algorithms for this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a model designed in Blender that i am going to render, in my game engine built using opengl, after exporting it to collada. The model in blender is divided into groups. These groups contains vertices normals and textures with there own index. is it a good thing to do if i rendered each group as a separate vbo or should i render the whole model as a single vbo?
Rules of thumb are:
always do as few OpenGL state changes as possible;
always talk to OpenGL as little as possible.
The main reason being that talking to the GPU is costly. The GPU is much happier if you give it something it'll take a long time to do and then don't bother it again while it's working. So it's likely that a single VBO would be a better solution, unless it would lead to a substantial increase in the amount of storage you need to use and hence run against caching elsewhere.