Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2007
Offline Last Active Feb 25 2016 04:52 PM

Posts I've Made

In Topic: Instancing, and the various ways to supply per-instance data

29 November 2015 - 01:06 PM

The Vertex Attribute method is the original, from GL2/D3D9 era hardware, so it's recommended if you want something that works everywhere.


Thanks! In practice, do you find the limit on vertex attrib locations to be a pain? At mimumum, it seems you'll want to pass in the world matrix, which will use four. From there, I suppose the wv and wvp matrices can be calculated in the shader, if needed, but it seems wasteful to calculate per-instance matrices on a per-vertex basis. So, suppose you pass those matrices in as vertex attributes. That would mean that 12 out of 16 vertex attrib locations are used just for transformation matrices. Positions, normals, and texcoords take up three more. That leaves only one more. If you want to do skinned animation, it seems like you'd have to fall back on calculating the additional per-instance matrices in the vertex shader.

In Topic: Need scene graph advice, please!

15 October 2015 - 08:06 AM



Unfortunately, because of the abstract meaning of “scene graph”, many people turned to OpenSceneGraph to understand what they are and what they do. Tom and I were mostly referring to the description of scene graphs on OpenSceneGraph’s site, which claimed that their graphs would help with rendering by sorting the scene for fastest material traversal, etc.
This is completely asinine and Tom’s article is completely correct in that context of scene graphs. 


For what it's worth, I've actually used OpenSceneGraph for a number of years at a previous job. It's true that the OSG libraries handle tasks such as asset file loading, culling, state-sorting, and rendering. However, it does not necessarily use the scene graph structure to complete these tasks. For instance, state sorting is performed on a linear list of drawables after the culling step. It is not performed by the scene graph itself. I have my complaints about OSG, but I don't think it can be blamed for the confusion about scene graphs on the basis that people are going to the website and making incorrect assumptions about how it's implemented.

In Topic: I'm having trouble making sense of these performance numbers (OpenGL)

14 October 2015 - 11:34 PM

Alright, so I wasn't able to start on this until late this evening, but I do have some results to share. The following graph shows the time vs. frame number for 50,000 cubes rendered using DrawElementsInstanced (no camera panning):



So, it seems that the gpu is the bottleneck in this case. Almost the entire frame time is spent waiting for SwapBuffers to return. I tried this same experiment with 5,000 cubes, and got the same results (albeit with smaller frame times). That is, gpuTime and swapBuffersTime were very close to the total frame time.


I then tried running the same experiments with DrawElements (not instanced), and I got a very different plot. This time, the frame times and gpu time were about equal still, but the swap buffers time was way lower:



This looks to me like the gpu is still taking the same amount of time to draw the cubes as in the Instanced case, but since the CPU is spending so much more time submitting draw calls, there is much less time left over for waiting for the buffer swap. Does that sound right?


I also tried using an object that is more complex than a cube -- just a quick mesh I made in Blender that has 804 unique verts. Once again, there is no performance difference between the DrawArrays, DrawElements, and DrawElementsInstanced cases. However, the good news is that the triangles-per-second increased by more than 2X with the more complex model, just as you predicted.


So, it appears that my test cases are not great -- they take long enough to draw on the GPU that there is plenty of time on the CPU side to submit all of the draw calls individually.


However, the vertex processing stage does not seem to be the culprit, since there is no difference in GPU time between the indexed and non-indexed cases. Next, I'll experiment more with fragment processing and reducing the number of single- and sub-pixel triangles in the scene.

In Topic: Why are voxels more efficient than polygons?

14 October 2015 - 09:33 PM

Freaky! Still, it looks fairly procedural. What about animating a dragon? 

In Topic: Why are voxels more efficient than polygons?

14 October 2015 - 09:19 PM

I'm surprised that they don't realize that claims of reducing costs by 90%, having unlimited detail, etc., are just going to sound like huge red flags to people.