1. DAE object no longer held onto by plugin.
2. Filename to URI conversion now handled internally by plugin.
2. User can supply an external DAE object for use by the plugin.
3. User can supply a std:string object for the plugin to return the URI of
the document just processed.
4. User can supply a std::string to receive the unit name information from
the document just read in. (e.g. meters, inches, etc.)
5. User can supply a float to receive the metric conversion factor from the
document just read in.
6. User can supply an enum to receive the up axis orientation information
from the document just read in.
7. Material transparency can be both read and written.
8. User can supply an experimental GoogleMode option on output. The plugin
will try to emulate the way Sketchup specifies transparency (i.e. the
inverse of what it should be!). I am still struggling to get GE to
understand transparency, anyone know what it expects?
9. Rudimentary support for Collada effect parameters (newparam, setparam,
param) on input. Basic nVidia FX Composer dae documents can now be read.
"
- Material class contained both 'shininess' and 'Ns' member variables
- 'Ns' and 'Ni' are initialized to 0 ('Ni' is unused at the moment)
- only 'Ns' was read from .mtl file but 'shininess' was used for osg::Material
- 'illum' was read from .mtl file but never used; it is now used as follows
-- illum==0 -> no osg::Material created/attached therefore no lighting
-- illum==1 -> osg::Material specular is set to black
-- illum==2 (default) -> specular read from .mtl file is used
- 'map_Kd' and 'map_Ks' may contain additional arguments (e.g. '-s 1 1 1'),
these are now skipped over and the texture filename is properly extracted
"
* Support for Box, Sphere, Cone, and Cylinder. These nodes are converted
to osg::Geometry conform the VRML97 spec.
* Backface culling is enabled/disabled according to the "solid" flag for
geometries that are converted from IndexFaceSets.
* PROTO instances can now be used for "appearance" and "geometry" fields
in a Shape node.
The file ReaderWriterVRML2.cpp is adapted for the latest stable public
release:
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.2.0
The changes where needed for being able to read VRML file which are
output by VMD (http://www.ks.uiuc.edu/Research/vmd/). A sample VRML file
is enclosed in this submission.
The plugin has been tested against a number of VRML samples that include
texturing. The texturing is found to be VRML97 compliant for all added
geometry nodes.
"
You were right about the CMAKE_MODULE_LINKER_FLAGS option for CMake, so here is a modification allowing to not generate the manifest files for the plugins making them a lot more easy to redistribute. I have also made the same modification to the wrappers as they are also put into the osgPlugin folder when generated.
"
both Jeremy and Anders added static build support as an option, but one was
for Unix and one for Windowsm, but the two mods were also inconsitent in naming
and implementation. I have had a bash at merging them both, but don't know yet
if these changes will work yet on either configuration... user testing will tell...
size of the image data is greater than the actual image size. This
causes the memcpy call to go out of the array bounds. I modified the
code so that it copies the data during the iteration, instead of
memcpy'ing. This fixes the problems i was having.
If you are curious, the writer was crashing when trying to write an
RGB image that was 2050 x 1280. You might be able to reproduce it by
allocating an empty image of that size and writing it to a file."
"" for all platforms except Cygwin where its set to "cygwin_" and Mingw where
it is set to "mingw_". Updated osgDB::Registry to look for these for the plugins.
Updated the osgintrospection example to search for these names as well.
The options are intended to match the existing read options. By default it will only write RGB32F format; if the "RAW" option is selected, it will output 8 bit RGBA as "raw" RGBE. Note also that the writer inserts a flipVertical(); although the RGBE format, according to spec, should support top-to-bottom or bottom-to-top ordering, no software I've found, including that from the formats originator, actually respects this."
