-I changed the SET of COLLADA_BOOST_INCLUDE_DIR to use findpath, so users may override this setting if they choose not to build against to precompiled boost libraries delivered with the Collada DOM.
-Changed daeRMaterials.cpp to prevent a compiler warning about a potentially uninitialized variable."
1. Support for ambient occlusion maps.
2. A fix for the incorrect handling of normals on all geometries. The optimizer usually fixed this bug so it probably was not noticed very often.
3. A new option flag on the reader. "StrictTransparency"
// Process transparent and transparency settings according to a strict interpretation of the spec
// See https://collada.org/public_forum/viewtopic.php?f=12&t=1210
otherwise
// Jump through various hoops to accomodate the multiplicity of different ways
// that various people have interpreted the specification
4. Handling of texures in the transparent channel. This is allowed provided that they are the same texture that is specified in the diffuse channel. Accomodating a different texture would require use of programmable pipeline functionality which I have tried to avoid.
5. Handling of <bind_vertex_input> elements.
""
A Collada camera will be added to the scenegraph as osg::CameraView. This allows the user to create a set of predefined camera viewpoints. I also added a new MatrixManipulator to osgGA called CameraViewSwitchManipulator and added usage of this to the osgviewer example. This manipulator allows switching between the predefined camera viewpoints. The current design limition I ran into is that a MatrixManipulator only manipulates the ViewMatrix, but for this particular manipulator I also want to update the projectionMatrix of the camera when switching to a new viewpoint. This is not implemented because I don't know what would be the best way to design it. Any ideas?
Furthermore Collada also supports orthographic camera's, where an osg::CameraView only supports a perspective camera. Would it be useful to create a CameraView with customizable optics for this?"
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
New features
+Read and write of osg::LOD, osg::Switch, osgSim::Sequence, osgim::MultiSwitch and osgSim::DOFTransform data in <extra>
+Read and write of osg::Node description data in <extra>
+Plugin option "NoExtras" to prevent writing of <extra> data and only traverse the active children when saving
Changes/additions
+instanced_geometry and instanced_controller are now loaded in a single Geode with multiple Geometries instead of multiple geodes with a single Geometry
+Changed all calls to the deprecated createAndPlace() to the new add() methods
+All transformation elements <scale>, <rotate>, <translate>, <lookat>, <matrix>, <skew> are now concatenated properly in to a single MatrixTransform.
Previously this was not done in order as required by Collada and and not all elements were included.
+Complete skew matrix creation
+Automatically add GL_RESCALE_NORMAL if scale is non-identity
+Blinn shininess remapping to [0,128] when in range [0,1]
+Changes to CMake file to make it compile on Windows
+Coding style and code documentation
Bug fixes
+Transparent texture writing fixed
+Fixed bug in using osg node name as collada node ID
+Fixed usage of double sided faces in GOOGLEEARTH extra
+Not adding blendfunc and blendcolor when opaque
TODO/Wishlist
-solve differences in drawables, DAE reader should place multiple collation elements into multiple primitivesets in a single geometry where possible (only when same material)
-solve differences in matrices
-multitexture support
-skinned mesh and generic animations using osgAnimation
-profile_GLSL based on COLLADA OpenGL Effects Viewer http://ati.amd.com/developer/rendermonkey/downloads.html
-handling more <extra> to more closely mimic the intended lighting"
support. While testing the pluggin we found a small bug and we are
submitting a patch.
The first attachment is a small program that creates a scene with two
pyramids, transformed by two instances of
osg::PositionAttitudeTransform. One of them is rotated 90 degrees in
the X axis, and the scene is exported both in the native OSG (.osg)
and COLLADA (.dae) formats. In the first case the rotated pyramid is
displayed correctly whereas in the second the pyramid seems not to be
rotated.
In the COLLADA 1.4.1 specification (found at
http://www.khronos.org/collada/) it is specified that
"The <rotate> element contains a list of four floating-point values
[...] followed by an angle in degrees" but the plugin seems to write
the value in radians.
The problem seems to be in the method daeWriter::apply() that seems to
be writing the angle value in radians to the COLLADA file. The patch
can be found in the second attachment and is simply a call to
RadiansToDegrees wrapped around the angle.
"
osgconv cessna.osg cessna.dae
Examination of the resulting .dae file reveals several out-of-range tristrip indices; viewing the .dae file in osgviewer causes a crash when OSG tries to lookup those indices.
Attached resolves this issue."
CLAMP ->GL_CLAMP_TO_EDGE
NONE->GL_CLAMP_TO_BORDER
The current 2.5.0 daePlugin assumes the following binding
CLAMP ->GL_CLAMP
NONE->GL_REPEAT
Notably the GL_CLAMP binding will result in visible black seams on input files that use otherwise matching textures. Replacing GL_CLAMP by GL_CLAMP_TO_EDGE solves this problem. I've updated both the read and write functions.
"
There was a problem converting a file to Collada by using osgconv like this:
osgconv file.osg file.dae
You would get an error message:
I/O error : Permission denied
I/O error : Permission denied
error : xmlNewTextWriterFilename : out of memory!
Error: daeLIBXMLPlugin::write(file://cessna.dae) failed
Warning: Error in writing to "cessna.dae".
This was due to some bad URI processing code in the Collada plugin. The attached file fixes this by using the Collada DOM's URI processing functions. After this change the file will convert successfully in the local directory.
"
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.
"
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...
I've done some additional small modification regarding constness in ReaderWriter and added
mutable on _pluginData so passing data back would be possible too.
Have updated the collada plugin (ReaderWriterDAE.cpp) to use the map to handle options and
have attached the changes.
The stuff in daeReader.h and daeWriter.h are just cosmetic changes to get rid of a warning."
is targeted by a rigid body which is the reason why the .h-file was changed too.
So now there'll be Group as often as possible, otherwise PostitionAttitudeTransform."
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:
"
I have decided to just normalise the drive letter part of file names for the time being and also ensure that names of the format x:/xxxxx are treated as absolute paths. This will cover a lot of cases.
I have raised a bug against collada which hopefully should resolve some others. However there are some pathological cases which I have commented on in the code, these will probably never work properly unless there is a significant rewrite of the daeURI functionality. Hopefully they are rare."
COLLADA plugin. dae->load will not return DAE_OK the second time a model is loaded, so a
second check for DAE_ERR_COLLECTION_ALREADY_EXISTS has been added."
only DAE instance when it's first needed instead of in the constructor.
This fixes the problem with osgdb_dae.dll not being loaded due to
unwanted ordering of global initialization.
This fix and the previous fix of the COLLADA plugin might be unnecessary
with the latest COLLADA DOM, but since many of us will probably still
use the older version of the DOM, I guess it's better this way.
"
