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."
return the length of the stream.
Implemented the virtual methods in QuicktimeImageStream, (getLength,
getReferenceTime, setTimeMultiplier), to return valid value for each.
"
Just as in the pre-r6419 I used the COIN_BASIC_H define in order to discriminate
between the two versions of Inventor.
Additionally, I had to change the CMakeLists.txt to use the proper include path.
"
"I was working on a new version of Inventor plugin.
It was inspired by the need to get correct and high quality conversion,
so I verified the plugin on complex models and made number of serious fixes:
- the geometry is not two times on the output file (!)
- SoVRMLImageTexture: VRML texture support was rewritten according to
Inventor programming practices, since it does not worked correctly on
many models (Anyway, thanks for Gerrick Bivins to introduce it.)
- osg::ref wrong usage related crash fixed
- code cleaning and texture code overhaul
- LOD fixes
- appended README.txt with all the contributors I was able to get from
SVN logs"
