Yeah, this solves the problem, want me to submit the changes or just
make them yourself?
Alan.
On 6 Dec 2006, at 09:56, Robert Osfield wrote:
Hi Alan,
Good catch on tracking down what the problem is, certainly is a most
obscure trail to find the final bug. I'm not sure of what the
solution should be off the top of my head, but its most likely be
necessary to add a namespace qualification to the DotOsgWrapper
associative names.
I'm sure Marco Jez and I have discussed this topic in long distant
past, it too long ago for me to remember the details. I have just
looked through osgPlugins/osgParticle and osgPlugins/osgFX and the
later contains namespace qualifications in the associative names
string. See src/osgPlugins/osgFX/IO_Effect.cpp, perhaps all that is
required is to add osgParticle:: i.e.:
osgDB::RegisterDotOsgWrapperProxy g_IOProgramProxy
(
0,
"osgParticle::Program",
"Object Node osgParticle::ParticleProcessor osgParticle::Program",
IOProgram_readLocalData,
IOProgram_writeLocalData
);
Could you try this?
As a general note, I have been very busy of late and haven't been able
to follow every thread or bug report to its conclusion. I try to
provide pointers where I can, but its not possible to do cover
everything.
Cheers,
Robert.
On 12/5/06, Alan Purvis <[EMAIL PROTECTED]> wrote:
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
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
