Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualnoizex

Posted 29 September 2012 - 06:55 AM

Wow, thanks! Thats a lot of very useful input, I was worried that this topic won't get any answer as it was few days and noone responded to it Posted Image

@Lightness1024:
Yeah, <code> tag is broken unfortunately, it seems to strip template braces because they're similar to HTML tags - it should escape them but it doesnt. Putting space between braces and the template parameter helps, but it requires changing all code so probably better using some external pastebin for longer code. Thanks for code sample, I will try and comprehend it, although I see Boost there and I try to stay away from it as my code already has a lot of external libraries. And I completly agree about switch not being bad speed-wise, I meant it more from a programmer's perspective - adding another type requires you to fill few switch statements which is error-prone, rather than speed of actual code.

@Katie:
Ok, my shader already has overloaded functions that take glm::vecs and glm::mats, floats etc. But not sure what you mean about templated setter class and how to store different types in one map. Some code sample would be great, because it sounds like it could be a good and clean solution, but I'm not sure I understand 100% of it.

@Hodgman
Your solution is probably fastest because it works on simple structs and you can then copy it into UBO - only potential drawback I can see is that it requires you to have really well-thought-of concept of what uniforms you need, even on object/mesh-level. Right now I use UBO for "render pass" information like camera projection & view matrices. I also plan to have one lower level UBO (for things like material), then we go down to per-object state and here I'm not sure, because uniforms can really vary per object. I can be wrong of course, because for now I only have very similar objects rendered (they use the same uniforms and stuff like that) but I can't know what the future will bring. Thats the reason why I made the lowest level based on setting uniforms rather than a buffer, because then I don't have to rely on some static structure of UBO.

But now that I think about it more and more, I may just go for UBO till the moment where my uniforms can't fit one structure. Well, I can even have few structs for different objects - only thing it requires is making new struct definition, instead of freely setting any uniform I want through some SetUniform(name, val) call.

#1noizex

Posted 29 September 2012 - 06:54 AM

Wow, thanks! Thats a lot of very useful input, I was worried that this topic won't get any answer as it was few days and noone responded to it :)

@Lightness1024:
Yeah, <code> tag is broken unfortunately, it seems to strip template braces because they're similar to HTML tags - it should escape them but it doesnt. Putting space between braces and the template parameter helps, but it requires changing all code so probably better using some external pastebin for longer code. Thanks for code sample, I will try and comprehend it, although I see Boost there and I try to stay away from it as my code already has a lot of external libraries. And I completly agree about switch not being bad speed-wise, I meant it more from a programmer's perspective - adding another type requires you to fill few switch statements which is error-prone, rather than speed of actual code.

@Katie:
Ok, my shader already has overloaded functions that take glm::vecs and glm::mats, floats etc. But not sure what you mean about templated setter class and how to store different types in one map. Some code sample would be great, because it sounds like it could be a good and clean solution, but I'm not sure I understand 100% of it.

@Hodgman
Your solution is probably fastest because it works on simple structs and you can then copy it into UBO - only potential drawback I can see is that it requires you to have really well-thought-of concept of what uniforms you need, even on object/mesh-level. Right now I use UBO for "render pass" information like camera projection & view matrices. I also plan to have one lower level UBO (for things like material), then we go down to per-object state and here I'm not sure, because uniforms can really vary per object. I can be wrong of course, because for now I only have very similar objects rendered (they use the same uniforms and stuff like that) but I can't know what the future will bring. Thats the reason why I made the lowest level based on setting uniforms rather than a buffer, because then I don't have to rely on some static structure of UBO.

But now that I think about it more and more, I may just go for UBO till the moment where my uniforms can't fit one structure. Well, I can even have few structs for different objects - only thing it requires is making new struct definition, instead of freely setting any uniform I want through some SetUniform(name, val) call.

PARTNERS