Hello Robert, All,
A short while ago I posted about a strange bug in which some .osg
files containing GLSL program objects only loaded correctly with
shaders the first time; second and subsequent loading of the file
within one running session would result in the file being loaded with
empty GLSL program objects in place of ones that loaded correctly
with shaders intact the first time.
Robert suggested that this problem was in my code and not the osg,
seeing as nobody else had observed this bug. This seemed like a
logical conclusion to draw so I set about creating a minimal example
of the problem by modifying osgsimple, to see if the problem was in
my work or the osg. I created some code that definitively showed the
problem was within the .osg loading mechanisms and posted it here, I
received no reply, even just to acknowledge my multiple emails arrived.
I have spent the last two weeks stepping through the whole file
loading process with GDB without any advice, general directions or
otherwise. This was not an especially easy task given the size and
complexity of the code. I could have saved a week or more with even a
few pointers as to where I might start looking.
Anyway, I have found the source of the problem eventually and without
help, though due to its nature it is not something I can fix without
making some small decisions which might break other .osg files, so I
thought I'd post my findings here and see what other people think
might form an appropriate resolution.
-----------------
OSG maintains multiple <string, DotOsgWrapper> associative arrays and
string vectors of "associated" classes which it searches to find
functions for reading and writing nodes in .osg files. After
carefully watching what functions osg was extracting from these
arrays I noticed the following conflict in read/write function
registration:
osg/Program.cpp:
RegisterDotOsgWrapperProxy g_ProgramProxy
(
new osg::Program,
"Program",
"Object StateAttribute Program",
&Program_readLocalData,
&Program_writeLocalData
);
osgParticle/IO_Program.cpp:
osgDB::RegisterDotOsgWrapperProxy g_IOProgramProxy
(
0,
"Program",
"Object Node ParticleProcessor Program",
IOProgram_readLocalData,
IOProgram_writeLocalData
);
Both files are registering loaders for different nodes with the same
name; "Program", though they pair the common name with different read/
write functions.
The first time that a .osg file containing a GLSL program is loaded,
the correct read/write functions are extracted from the associative
array, second and subsequent attempts to load the file (for whatever
internal STL implementation reason) the read/write functions for the
osgParticle program are extracted, these functions naturally fail at
loading the GLSL program and leave a prototype GLSL program object
tacked to the scenegraph where the correctly loaded one should sit.
Changing the registered name of the osgParticle program to something
else (eg. "ParticleProgram"), resolves this conflict and results in
correct file loading each and every time. I'd send a fix to osg
submissions except to change the registered name of either class
would theoretically break the loading of some .osg files.
So, Instead I'm posting here in the hope that someone with more
authority might be able to make a decision about how to resolve this
issue.
Thanks for your time,
Alan.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
