Jump to content
  • Advertisement
Sign in to follow this  
Juliean

OOP-approach for (game) effect system?

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

Hello,

 

refering once again to the frostbite render architecture article. I've already got the render queue, but now I'm wondering whats the best design for handling ingame effects? I'm not sure how to explain this properly. I'm not talking about the shaders per se, this is already handled by the render queue. I'm also not talking about setting input and ouput textures, but rather, handling all other parameters and the actual fullscreen pass. Every shader needs almost unique parameters: An SSAO-shader e.g. might need a view matrix, some artistic parameters and the size of the noise texture, a atmoshperic scattering shader might need all the atmospheric variables.

 

How did you design this? I'm unsure how to wrap this in a nice design, that goes hand in hand with the already flexible design of the rest of the rendering architecture. Right now I'm simply asigning a fullscreen-quad model via my entity-component system, and rendering this in a specific stage via a "EffectSystem". While it works, I'm sure this is not optimal, since entity/component is a lot of higher stage than rendering. How do you handle this? I'd be glad to hear some opinions on how to optimally design an game effect framework.

Share this post


Link to post
Share on other sites
Advertisement

I'm also not talking about setting input and ouput textures, but rather, handling all other parameters and the actual fullscreen pass. Every shader needs almost unique parameters: An SSAO-shader e.g. might need a view matrix, some artistic parameters and the size of the noise texture, a atmoshperic scattering shader might need all the atmospheric variables.

Of course you need a generic shader system supporting arbitrary data blobs. It's only a bit more complex than setting the textures. The amount of complexity depends on how much information you want to keep. My system currently blindly uploads blobs of binary data to D3D9 registers. Textures are just a special case, instead of being copied to registers they have to be copied to sampler state. It's really the same.

 

A different thing however is keeping track of those values so for example you can change atmospheric scattering parameters on a per-frame basis. This is not renderer's job! Some higher level component takes care of updating the blobs. What the renderer sees is that the blob itself has changed and updates it again.

Yes, I hear you saying... but this way there will be multiple copies! Yes, there are, but this performance is ok for me.

Share this post


Link to post
Share on other sites

Of course you need a generic shader system supporting arbitrary data blobs. It's only a bit more complex than setting the textures. The amount of complexity depends on how much information you want to keep. My system currently blindly uploads blobs of binary data to D3D9 registers. Textures are just a special case, instead of being copied to registers they have to be copied to sampler state. It's really the same.

 

Yeah, my system is pretty much alike. Instead of blobs, I store the data in float[4]-arrays, and I have one render command for each constant register. Might change that to cbuffers later, but thats aside the point, my question was more about what you said in the last paragraph... sorry, should have been more specifiy.

 

A different thing however is keeping track of those values so for example you can change atmospheric scattering parameters on a per-frame basis. This is not renderer's job! Some higher level component takes care of updating the blobs. What the renderer sees is that the blob itself has changed and updates it again.

Yes, I hear you saying... but this way there will be multiple copies! Yes, there are, but this performance is ok for me.

 

Ah, I see, I was thinking a bit to low level for that. But then again, thats what I'd like to hear: How would you design such a high(er) level system for different effects? Is this part of an entity/component-system? Is there a generic class that handles this? Or inheriting from an interface for each effect (since you need completely different high-level input to map to those low level registers)... how do you handle this?

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!