Hello Wojtek > Method called by user has to be generic. Its prototype must be as simple as > SetShadowTextureCoordUnit( unit ). Search and replace method could be > auxillary but SetShadowTextureCoordUnit or some higher level method has to > know what strings to search and replace. What you seem to propose is > changing search strings when shader changes... This means that whenever user > wants to change shader he has to override some method of the technique to > properly define lookup strings....
Please check the submission before complaining. The change isn't more than 20 lines. > > [...]The actual number (1) wasn't used at all in defining where > > to replace. It isn't pretty, but I don't know of any other way to do it > > without a priori knowledge of the number (1 in your example). > > > And now we agree ;-). Thats exactly my point. In general case (ie when we > don't know shader sources) its impossible to provide a search and replace > method that would be independent of currently used unit. I do not agree at all. Firstly, Your "general case" is never the case in OSG. If you can replace the shader source you can also read it, just call getShaderSource() on the same Shader object. This is what both the original and new functions do. Secondly, if you don't know the source code, you cannot know what the currently currently used unit is. This means the StandardShadowMap function is also useless. (I readily admit that if you didn't have access to the code (which we do), you could just guess the unit number, going through every possible number until you get it right, which would not work for context.) If you, as the programmer, need to inspect the code to figure out context for either method, cout or printf in combination with getShaderSource() works well (that is precisely how I got osgCal and shadows working). Of course with external libraries this can be problematic, when they change the glsl code around (for instance, osgCal uses compile time selection of code, meaning different builds of the same library could have different glsl code), but if they change the "magic number" the other method needs doesn't work either. > > > If you do happen to know the number (1), the simpler function from > > StandardShadowMap is definitely better to use. > > And thats why I prefer to stay with current solution for StandardShadowMap. I personally don't care which method is used, except it should to work. I submitted a patch that does work for ShadowMap and SoftShadowMap, with minimal changes necessary. Jean-Sébastien suggested combining them to use a common base. Either way of combining them is possible. Making the function from StandardShadowMap work in ShadowMap is possible, but requires other, more invasive changes to ShadowMap, which I have alluded to already. Unfortunately, I'm not likely to have time to work on this further for some time. I've taken the time to create a patch, so that others who aren't as savvy wouldn't have to wade through the source code and figure out how to fix this by changing sources or deriving a new class (which I've done already for my needs). Whatever those with the power to decide what is committed eventually decide, someone else can happily make the required changes. -Kris _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
