Jump to content
  • Advertisement
Sign in to follow this  
Wavesonics

In memory model format

This topic is 3631 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

So I'm redesigning my model rendering system in my engine, and I am interested in how you guys solve this problem: 1) I want to be able to do indirect rendering, so the model should have a "platform optimized" representation in memory. 2) I want to be able to control certain things per instance of the model. 3) I only want to store one copy of the model in memory So let me elaborate on the 2nd and 3rd there. Game code should be able to easily alter some general parameters such as the alpha for the entire object (So I can fade objects in and out). Also I would like to be able to set vertex color for parts of the model (for team color). Now it seems that #2 conflicts with #1 to me. Since indirect rendering you usually set it up in an array and then cache it on the GPU thus making it troublesome to change. Also, #2 and #3 seem to conflict. If we just made new copies with the proper changes #1 and #2 could work together, but of course, not #3. And that approach would be terrible if you were changing the alpha of the entire model each frame, you would constantly be creating new copies of the model with changes to them. My initial idea is to have the original copy in memory along with a indirect rendering representation of that original copy. Then GameObjects would hold "ModelViews" which would point to the indirect render copy unless they wanted to change something, like alpha or color, then they would point to the original copy and as the data is pulled through the view during direct rendering, certain things would be applied, like vertex color and alpha. This has a lot of down sides though: Anything that requires team color changes would never use indirect rendering, and anything using the view to apply changes to the model now renders slowly. So how is this usually handled? Any suggestions?

Share this post


Link to post
Share on other sites
Advertisement
What graphics API? If OpenGL, you can do something as simple as store the model in a display list and use that one display list for all object instances you want to render. Things such as altering alpha values or textures are done by simply not specifying them when compiling the displist, which makes it use whatever configuration is in memory when you render it.

Of course, geometry in displists is immutable, which is the big disadvantage. You can circumvent that if you need to by using vertex shaders, but at that point it might be simpler to just go with a different solution instead (VBO's maybe?).

Share this post


Link to post
Share on other sites
Well I'm not using OpenGL, but the principles for them are similar everywhere, things in the optimized format are immutable.

Share this post


Link to post
Share on other sites
Then the same should apply, meaning that as long as you don't need to actually deform vertices, the displist equivalent should work fine for what you describe.

Share this post


Link to post
Share on other sites
So you are saying, use a display list, but perform post processing to do things such as alpha and per polygon colorization?

Share this post


Link to post
Share on other sites
No, not at all. Read my first post again: "Things such as altering alpha values or textures are done by simply not specifying them when compiling the displist, which makes it use whatever configuration is in memory when you render it."

Basically, you simply supply whatever you want to be fixed to the displist compile function; in your case that would probably only be the geometry (vertices, texture coordinates, normals). Then, whenever you want to render an object using that displist, bind whatever texture or color/alpha settings you want for that particular object and call the displist. It will be rendered with whatever texture/color settings were specified at the time of rendering.

Share this post


Link to post
Share on other sites
Quote:
Original post by Wavesonics
Game code should be able to easily alter some general parameters such as the alpha for the entire object (So I can fade objects in and out). Also I would like to be able to set vertex color for parts of the model (for team color).


Just some ideas for these. No doubt some expert will have a much better idea and I'd like to hear the answers too...

1. Have a per-instance float alpha parameter that can be passed into your shaders to use in place of the model's texture alpha, or to modulate the model alpha.

2a. Include magenta patches in your textures for the regions you want to recolour, then programatically alter that colour and generate a set of textures per team - probably bad because you'd potentially be duplicating lots of textures.

2b. Include full-alpha patches in your textures for the recoloured regions, then render an object in two passes: once with the diffuse colour required for the team, then again as an overlay with the proper texture, so that the underlying team colour shows through the alpha 'windows' in the main texture. Involves more rendering but less texture data.

Share this post


Link to post
Share on other sites
why now use hardware instancing? Values like alpha that would affect individual instances can be stored in the instance stream. E.g

Model Data VertexBuffer assigned to Stream1. (you can cache Stream1 to the GPU as it does not change most of the time)
Model Instance VertexBuffer assigned to Steam2.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!