Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2007
Offline Last Active Yesterday, 06:26 AM

Posts I've Made

In Topic: Engine design v0.3, classes and systems. thoughts?

20 August 2016 - 09:58 AM

I want to be helpful, but it's difficult for me to reason about how the architecture works from a high-level graph like that. For instance, what information do your scenes contain? What constitutes a scene? Is your front menu a scene? How will the scenes be loaded/unloaded? Will you support dynamic, asynchronous loading of level fragments as the player plays through the level? Is each one of those fragments a scene? If not, how do you keep track of which assets are actually needed and which aren't? Some sort of usage counting? These are the sorts of questions that generally give rise to an overall architecture. However, these questions are usually not answerable from a high-level graph of class names alone.


I tend to have more success building up levels of abstraction from the bottom-up. I know how to draw a scene using low-level API calls, but that is tedious and painful. What tools and abstractions would be helpful here? Identify the biggest pain points and fix them first. For instance, there's so much that goes into just loading and initializing a texture with all of the right parameters (size, dimension, mip levels, etc.). You may even need a small constellation/hierarchy of classes to make this less painful while retaining the flexibility you need. And how much flexibility will you need, by the way? It's important to keep your design goals in mind. Are there any extreme optimizations you have in mind in order to reduce texture state changes? Atlasing? Placing multiple same-sized textures into one array? Sparse virtual texturing? You'll want to make sure that your low-level design doesn't preclude these options when you get to a higher level.


I don't know, maybe that's just me. I just find it hard to *start* with the highest-level abstractions. It seems like, once you start to get to the granularity of concrete, single-purpose objects, you may find that the boundaries you drew at the higher levels aren't going to work so well. It looks like you've designed some engines before, though, so maybe you just have some domain knowledge (even if that knowledge is just your usual way of doing things) that I don't have.

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?