of the source file:
The "delete [] path" appears before the "osg::notify", causing the data pointed to by
"filename" to be deleted before access causing an access violation.
...
I have put a comment on
line 521 where I have moved the "delete []path" below.
"
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
COLLADA modules STLDatabase, LIBXMLPlugin and stdErrPlugin are
statically included in the main COLLADA library on Linux and shouldn't
be linked separately - those libraries do not exist in the default Linux
build and the compilation will fail.
Second issue - the current version of the COLLADA plugin (both current
HEAD in Subversion and the one in stable 2.0) do not work right with the
stable COLLADA DOM 1.4.1. I am getting the following error:
"
is not the usual OpenGL BOTTOM_LEFT orientation, but with the origin TOP_LEFT. This
allows geometry setup code to flip the t tex coord to render the movie the correct way up.
R3G3B2, R5G6B5, A1R5G5B5, X1R5G5B5, A4R4G4B4, X4R4G4B4, R8G8B8 (now
without swaping of red and blue), A8R8G8B8 (also w/o swapping),
X8R8G8B8, A8B8G8R8, X8B8G8R8, A2R10G10B10, A2B10G10R10, L4A4 (not work
on my machine), L16A16, L16, A16B16G16R16, A16B16G16R16F,
Q16W16V16U16, R32F, R16F and A32B32G32R32F.
And these ones are correctly detected, but prints "unsupported" using
osg::notify(osg::WARN) and are not loaded:
A8R3G3B2, G16R16, G16R16F, G32R32F and CxV8U8.
Also added checking of not supported DDPF_BUMPDUDV (V8U8, V16U16,
Q8W8U8L8, A2W10U10V10 etc.) and DDPF_BUMPLUMINANCE (L6V5U5, X8L8V8U8,
etc.) pixel formats.
Mipmap handling is slightly modified and now support all additional formats.
"
old loader, but appear very, very wrong with the new one. I traced the
problem to the handling of the palette override flags in the external
reference records. The current behavior for handling the palette
override flags for external references has different offsets for
different OpenFlight version (2 bytes for 14.2-15.1 and 4 bytes for 15.2
and later). However, I believe this behavior is incorrect.
I know that the original 14.2 OpenFlight spec (dated April 1995)
specifies 2 bytes between the filename and the override flags, and the
15.4 and later specs specify 4 bytes. However, I also found a 14.2.4
OpenFlight spec (dated January 1996) that changes the specification to 4
bytes. Also, the databases in question were created using an old IRIX
version of MultiGen II, which wrote OpenFlight 14.2 files natively.
These files also have 4 bytes between the filename and flags.
Furthermore, these databases have always worked properly under earlier
versions of OSG, under Performer, and in every MultiGen product we've used.
This leads me to believe that the original 14.2 spec was incorrect (the
14.2.4 spec corrected this error), and there should be 4 bytes between
the filename and flags for all OpenFlight files version 14.2 and later.
The attached fix modifies the OpenFlight loader to behave in this way."
Currently, if the texture attribute file doesn't explicitly specify an
internal format, the loader will force it to use GL_RGB, which keeps
translucent textures (eg. GL_RGBA textures) from showing up properly.
This patch changes the default behavior to simply use the image's format
instead of forcing a particular format."
libraries listed under TARGET_EXTERNAL_LIBRARIES.
The removed libraries are not needed when linking the plugin, they are
loaded during runtime by Performer.
The modified file is attached."
the specification. With these mods, blink sequences are now created for
flashing light point nodes, either palletized (v.15.8 and later) or
non-palletized (15.7 and earlier). Thanks to Brede for his
implementation of the palletized light point nodes.
There is still work to do on adding the capability to properly handle
light point system nodes, but this does add some capability that did not
previously exist. So, I wanted to at least submit this and I will
hopefully provide the additional capability in the near future.
I've tested the code modifications with Visual Studio 2005. I don't
have the means to test any other operating system, but I would suspect
that there shouldn't be any issue (famous last words). I used the test
files that I uploaded to the users forum to test the changes.
In addition to the added capability, I changed the light point node
radius to the "actualPixelSize" value in the file. Previously, the
radius was set to half the actual pixel size (see
LightPointRecords.cpp). Not sure why this was the case. But, it was
brought to my attention by a co-worker who created the OpenFlight files
and was testing them with different viewers. If there's some history
for setting the radius to half the size, then this change can be
omitted."
implements the LightPointSystem class to allow for the OpenFlight
plug-in to read and handle light point system nodes. The behavior is
very similar to the old plug-in in that a MultiSwitch node is created to
handle the "enabled" flag bit set in the node record. The code also
reverts the changes for the actualPixelSize as mentioned above. And
lastly, the code requires the previously submitted changes for the
plug-in.
As for the other changes, I've tested the code with Visual Studio 2005
and the files that I posted in the users forum.
With all of the submitted changes, the OpenFlight plug-in should now be
capable of loading files with light point system nodes and the use of
palletized light points and non-palletized light points.
"
accepted file extensions, so that once the plugin was loaded in the
Registry it would grab any image file write request, regardless of the
file extension. This was a particular problem if it was statically loaded."
according to the OpenSceneGraph/CMakeLists.txt and the include/osg/Version settings.
These changes mean that the 1.9.5 release will have a libs/osgPlugins-1.9.5 directory.
I added a new protected virtual method to ImageStream called
applyLoopingMode() which is called from setLoopingMode. The
quicktime-plugin has an implementation of applyLoopingMode which sets
some flags for the quicktime, so that quicktime handles the loop
playback by itself.
This has some benefits:
+ no gaps when looping audio
+ simplified code
Attached you'll find the modified files, hope you'll find them useful."
