not find a way to do this in OSG. Therefore I implemented this by adding
an option called: JPEG_QUALITY <quality> to the JPEG reader/writer.
To parse the options string I use the same method as used in the LWO
reader/writer. "
attached):
* Light point strings using the REPLICATE opcode should now be supported
(>=15.6?)
* Directional lights should now work as in Performer using a viewing
frustrum defined by a direction vector, horizontal angular width, vertical
angular width, and roll angle about the direction vector. The current
directional light implementation had some bad assumptions which caused
problems with direction vectors not on the XY plane.
* IVE and OSG reader/writers were updated as appropriate"
"Changes to provide rudimentary support for OF 15.8 light point
animation palettes. This change also includes light point palette override
support for external references. This is the last of my code changes to
support OF 15.8 in the flt loader. Barring bugs, of course, knock on wood.
The gist of the animation palette code is to create ref_ptr'd
osgSim::BlinkSequence objects for each palette entry, and then pass them on
to osgSim::LightPoint for any OpenFlight light points that reference that
palette entry. This should be conservative of memory (not that I expect the
animation palette to be extremely large)."
with a CoordinateSystemNode which reflect the coordinate system of the
database.
Added support for reading and writing CoordianteSystemNode into the .osg
and .ive formats.
direction normal has a zero length. The net effect is that unidirectional
light points with zero length direction vectors are now treated as
omnidirectional light points."
Quicktime (under OSX) to do the reading of the movie files. Originally submitted as
a sperate .mov plugin, but integrated into the QuickTime plugin by Robert
Osfield.
point appearance palette to the OpenFlight loader. Both are 15.8 features.
I also added parsing/comments regarding other things that have changed for
v15.8."
record goes. I added a new function to read a continued record body. I added
code in the existing ReadRecord routine to peek ahead for a CONTINUATION_OP
if the current record could possibly be continued.
opcodes.h -- Besides adding the opcode for CONTINUATION_OP, I also added new
15.8 opcodes. I labeled opcodes as "ignored" if I could easily discern that
our loader wasn't doing anything with them. For historical reasons, I added
all obsolete opcodes, prefixed with "OBS_".
LocalVertexPoolRecord.h, LocalVertexPoolRecord.cpp -- This is one of three
types of records that can be continued with a CONTINUATION_OP record. I
removed all invalid assertions that assumed the record length would always
be less than 65535. I replaced the "vertex size" calculation with a more
efficient method based on caching the size from attribute bits, rather than
taking the length of the record and dividing it by numVerts (which would
have been incorrect if the record had been continued)."
