Jump to content
  • Advertisement
Sign in to follow this  

OpenGL allowing for instancing and lod

This topic is 4023 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Please read a brief description about my engine design so far, and help me figure out how to (elegantly) add LOD and instancing! I just started learning about shaders (pixel and vertex shaders, just general concepts) and how to add them into my engine, so please correct me if I get anything horrendously wrong. I intend to support the fixed function pipeline as much as possible, so that may influence some of my design decisions. Also, I am working with C++ / Direct3D 9 not-for-Vista, but I hope to make my code clean enough to be able to port it to Linux / OpenGL in the near future. That is, I would prefer an API-independent way of doing things, but if I need the API I will use it. Engine Design The basic unit in my engine is called a geometry chunk. It supplies information about vertex layout (like a Direct3D vertex declaration) and also the actual vertex data. It's designed to be as general as possible, from loading raw data directly from file to procedurally generating vertex data when it needs to be uploaded to video memory. During each frame, I traverse the scene graph and try to cache objects that will probably be rendered. Then I would perform texture/shader/state sorting, followed by a second pass through all the geometry to actually render it. If data was not cached in the initial traversal, it has to be uploaded during the second pass before the geometry is rendered.
  1. A video memory manager I am thinking of managing video memory as arbitrary data: let a geometry chunk upload any data it wants to because it will be responsible for making sure the vertex shader knows how to interpret it. It seems like Direct3D doesn't care what is in the buffers as long as you know how to interpret the data in your shaders. But video memory is very different than any memory manager (I've) ever written because:
    • It's okay to overwrite some memory, because the memory is backed up (or at least easily accessible) in system memory. (I wish I knew something about caches.)
    • It has to be very fast, or at least understand video memory access semantics because memory accesses are much slower than system memory. (The lock/unlock you have to do to let your program access the memory. And the fact that slow accesses mess up the CPU-GPU parallelization that is so important to framerate).
    • The amount of free memory can't (and shouldn't be) accurately determined. You can't predict when a lost device will invalidate all memory, or when some memory will magically free itself up for your use.
    • Also, on older cards (older shader versions?) you can't render offsets into a vertex buffer. I'm not exactly sure how this will affect my manager.
    I have not yet tried my hand at writing such a memory manager, but I would like to hear what people think. Are there points about video memory that I'm missing? Is there a much better way to deal with video memory?
  2. Level of Detail For pre-computed LOD meshes, you can give the geometry chunk some information about the level of detail needed, and it should return the appropriate mesh data. What I have some qusetions about is LOD at runtime; are LOD schemes feasible with vertex shaders? I don't know enough about shaders or about current LOD algorithms to judge whether my current system works with them.
  3. Instancing Say I had certain complex teapot model in my teapot warehouse scene. When rendering, I want my engine to be able to identify that all the teapots are the same (well, teapots with identical materials and geometry chunks anyway) and somehow put them together to use with instancing. I think that after some particular sorting (first by render states, then by geometry chunks), multiple instances of an object will appear together in the render queue. They can be identified, and when they are to be rendered the engine can take their per-instance data and perform stream instancing (at least). Is this the wrong way to use instancing? Should I have to explicitly mark a model as being rendered several times in a scene for my engine to use instancing?
Thanks for taking the time to think about my questions, I hope they inspire you to ask some questions of your own

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!