Hi Julian, These changes are all in support of the shader_pipeline work, to enable automatic mapping of fixed function pipeline to shaders. This functionality isn't tied to just mapping fixed function across, it can be used for custom shader composition as well. It's bleeding edge work though, and not complete, but is powerful enough to do some neat things - it's the next step beyond #pragma(tic) shader composition.
The change to introduce a TextureAttribute base class and binding of the texture unit with to this when assigning to a StateSet was the only way I could find for being able to add the extra uniform and #Pragma(tic) shader composition support. It is a new limitation that I tried to avoid but in the end found it was the best compromise to achieve the required functionality. So it's a case a loose a bit of flexibility in one area but gain a lot elsewhere - it's an engineering compromise. To understand the power that this approach you'll need to look into the extra capabilities that the shadper_pipeline work offers, off the top of my head I don;t recall the best parts to look at to see where what it's capable of- there are some shaders in OpenSceneGraph-Data/shader that leverae this functionality, and the osgshadercomposition example. Unfortunately for this particular work I have had to put it aside while I get the VSG on it's feet. The world needs a Vulkan scene graph right now more than it needs an OSG-4.0 with automatic mapping of fixed function to shaders. For end users I would recommend sticking with OSG-3.6.x for their main application work, and it totally unaffected by the TextureAttribute/shader_pipeline changes . OSG master contains bleeding edge work, and I don't have near term plans for making 4.0 that will build upon this, so what is in master about to become production ready. Cheers, Robert. On Sat, 18 Aug 2018 at 02:34, Julien Valentin <julienvalenti...@gmail.com> wrote: > > Hi, > After Merging with master I had a bug in the beginning of the year > diggin for the bug i found that there were changes in Texture base class and > that because of some kind of propertization of the textureunit as Texture > member variables, Textures I used with different texture unit (in different > stateset) doesn't display anymore > > There's no urge as the release doesn't include this new feature (i think), > but this could lead to break backward compatibility. > > At first glance, making tu member of TextureAttribute seams a bad design but > there surely a reason... > Further, I can't see any usecase where TextureAttributes in the same stateset > share a common texture unit :/ so getMember of textures may stay: return 0 > > I suspect its use is to conform with the pragma pipeline but I can understand > in what way. > If you can explain me the main reason of this huge change I would be welcome > > Thank you! > > Cheers, > Julien > > ------------------------ > Twirling twirling twirling toward freedom > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=74562#74562 > > > > > > _______________________________________________ > osg-users mailing list > firstname.lastname@example.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list email@example.com http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org