[osg-users] Can't share Texture among several texture unit?

Robert Osfield robert.osfield at gmail.com
Sat Aug 18 05:15:40 PDT 2018

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

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.

On Sat, 18 Aug 2018 at 02:34, Julien Valentin
<julienvalentin51 at 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
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

More information about the osg-users mailing list