1
\$\begingroup\$

That question mind sound dumb, but let me explain: I'm writing a 3D rendering engine in C++, and my way of getting something to the screen seems rather unintuitive: enter image description here

I really hope that my artwork is understandable. To be sure, I'll just explain it again with words.

  1. [class Mesh] Load a raw mesh with vertices, uv coordinates, normals, etc
  2. [class Model] Creates VBO's off the data from the Mesh
  3. [class Shader] Reads and compiles shader
  4. [class RenderObject] Binds Shader
  5. [class RenderObject] Sets uniforms
  6. [class RenderObject] Binds Model VBO
  7. [class RenderObject] draw call

That would be how I get something drawn on the screen. Is that the proper way of doing so? Is there a more or less standard way of doing this?

\$\endgroup\$
4
  • 3
    \$\begingroup\$ First of all, make sure this is an actual bottleneck, if you create a low-poly 3d game or a 2d sprite-based game, then stuff like this doesn't count. \$\endgroup\$
    – Bálint
    May 8 '17 at 5:26
  • \$\begingroup\$ Its not really that much performance wise. More like how practical that structure is! \$\endgroup\$
    – Kiryu144
    May 9 '17 at 20:29
  • \$\begingroup\$ Does your Model really create a VBO or does it just call the RenderObject to do so? Cause if for any reason you change your rendering interface (Directx instead of OpenGL or Vulcan), you have to rewrite that aswell. \$\endgroup\$
    – PSquall
    Jul 12 '17 at 22:11
  • \$\begingroup\$ OpenGL doesn't care about your classes. Actually you might find that better ways to render doesn't fit your classes at all. Often times I've asked "how do I do X in framework Y?" and gotten an answer Z that I can't actually implement in my program because of the way my classes are laid out. \$\endgroup\$
    – user253751
    Sep 26 '18 at 1:26
1
\$\begingroup\$

Is there a more or less standard way of doing this?

Yes, there is; I would honestly say that it depends on your game:

If you are making a simple 2D game, with maximum 20/40 sprites at the time being rendered onto the screen, that ^ is an acceptable method, even if not the fastest.

If you are planning to port your game to mobile for example, you definitely need a faster way of rendering things on the screen.

For that, I would suggest you to take a look at Data Batching.

As the name already states, Data Batching is a process where you load all the data you want to render inside a single buffer (a Batch) and pass that to a Renderer of some sort, which then sends everything to the GPU and makes the draw call / draw calls (In OpenGL for example, you would call glMapBuffer(...), set the data, and call glUnmapBuffer()).

This way, instead of having a 1 object to 1 draw call ratio (which is quite expensive), you would have a x objects to 1 or 2 drawcalls ratio (depending on how you want to handle the buffer).

\$\endgroup\$
0
\$\begingroup\$

This is the bare bone structure and that's how a simple object is rendered. These are the things which you have to do,the optimization lies in the fact that how many times you bind or unbind an entity.

You should use which ever layout you want but it should keep the binding calls to its minimum.

eg- setting the uniform while you bind program while creating it minght reduce some program binding statements.

off course sometime it cant be avoided, so the best way is to try and keep less binding calls and be done with one entity in its first bind.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.