Hi Brad, On Thu, Jul 1, 2010 at 11:18 AM, Christiansen, Brad <[email protected]> wrote: > One thing I am not clear on is how the rules for injecting a Shader into a > ShaderMain would work. This is an area I have had difficulty with in my own > shader assembly approach. For example, how will it be possible to change the > order in which shaders are applied? As a contrived example, I might want to > use the material color of a fragment as the input to my lighting shader, and > then blend my textures with the result. Alternatively, I might want to first > blend all my textures, then use this color as the input to the lighting > shader. How would I specify these kind of rules?
These are all very good questions, ones that I'm aware of items we'll need to formalize and solve. Just how I don't have an answer to yet. The reason why I hadn't discussed these particular topics is that without a clear direction on it yet I don't have too much to say. Addressing these issue is something I decided to leave till later to fully resolve. I'm happy to do this as the high level mechanics, class design, and implementation is something that we have to addressed as well - but these I've been able to scope out and find a design that I feel has promise so I'm more confident about tackling implementation on them. I'm also now quite comfortable that the high level stuff is unlikely to change much with changes to the lower level details on the shader main generation, so we needn't worry too much about the rules right away - as long as we can get something basic working w.r.t main generation they we'll be able to thrash out and getting working all the high level details. Once the high level stuff is in place and working we'll have the framework in place to start testing various approaches to shader main generation, and we'll also have learnt more about the problem domain along the way, and also we can dump from our brains all the complexities of the high level stuff. I'm away for complexity overload so being able to tackle this task in stages like this is something I feel much more comfortable. > Another area I am not clear on is how (if at all) we will be able to avoid > doing the same calculations many times for a single vertex or fragment. Say, > for example, we need the ec position of a vertex as an input to several of > our vertex Shaders. Would each shader have to recalculate this value > independently? This shouldn't be a major hit to performance in most cases but > it is obviously less efficient than just doing the calculation once. Then > again, maybe the compiler can figure this out for us. It might be possible to have the shader generation parse the injected code to look for variables set up that are repeated in other injected code and use only the first instance. Using the same variables and code fragments for this would be required but should be possible with a little discipline and awareness of other shaders. Like the ordering issue I'm happy to not worry about this for now. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
