At the company where I work we model literally thousands of 3DS models for all types of objects. Most don't have transparent textures applied to them, but a few do. The issue is that a texture may have an alpha channel defined, yet its 3DS material definition is not marked as being an alpha source, or transparent. This can happen for any number of modelling reasons (so I'm told) but the net effect is that when a 3DS object is loaded with such a material applied, the stateset creation for the 3DS geometry omits to add the GL_BLEND attribute as neither of the conditions that it currently tests for are satisfied under this scenario.
However, one thing that is apparently an indication of transparency/alpha information that we do make use of when modelling, but that the 3DS reader omits to test, is that we assign to the transparent texture to the opacity_map of the 3DS material structure.
Now, having discussed with our modellers the theory behind the opacity map, it seems that it is safe to say that if an opacity map is specified, then the reader should really apply the GL_BLEND attribute as it is an indication of some form of blending being required between materials.
With this in mind, I have made a minor change to the function createStateSet below, from the ReaderWriter3DS.cpp file, that checks for an opacity map having been specified, and in such a scenario the GL_BLEND attribute is applied to the geometry. This fixed our issue, and thought it might be helpful to others."
osgText::Text and osgText::Text3D use the same font file.
The first really load the file and obtain an osgText::Font object,
the second use the cache created during the first load of the
font file, and so obtain an osgText::Font object instead of
osgText::Font3D object. To obtain an osgText::Font3D object,
osgText::Text3D call osgDB::readObjectFile(...) with an option
to specify the plugin we want an osgText::Font3D instead of
osgText::Font.
Generalised Problem:
In osgDB::Registry, loaded file cache is referenced by the name
of this file, so if I load a file with some options, and the cache
already contain object for this filename, I obtain an object
potentially not loaded with my options.
Behaviours:
Cache management is delegate to osgDB::Registry, but cache
coherence (load a file with option then reuse it, deactivate the
cache when load a specific file or don't cached the loaded file)
is user's responsibility.
Text3D solution:
Postfix the font file name by .text3d or something similar and then have the freetype plugin return
osgText::Font3D when it detects this.
This operation is done by osgText::readFont3DFile() which unsure the filename have .text3d as extension.
This is totaly transparent for user, and backward compatible.
BTW, I fix the bug about the Normal of 3D text. Currently, the front and wall face have
the same normal (0,0,1) in the Text3D object coordinate. Now the wall face have its own
normal array computed by the plugin.
BTW 2, I implement
- void Text3D::accept(osg::Drawable::ConstAttributeFunctor& af) const
- void Text3D::accept(osg::PrimitiveFunctor& pf) const
so now statistics are well reported.
"
"Summary of changes:
From Roland
-Added MorphGeometry
-Bone Bindmatrix is only calculated if needed
-osgAnimation plugin now supports all available channel types (before only linear vec3 or quat channels)
-osgAnimation plugin now supports MorphGeometry
-osgAnimation plugin now supports animation and channel weights, animation playmode, duration and starttime
-removed osgAnimationManager.cpp from CMakeList
From Cedric
-fixed the last_update field (it was only updated at the first update) in BasicAnimationManager.cpp
- Refactore some part of MorphGeometry minor changes
- Add osganimationmorph as example
"
It's really just a cut-paste job from the existing LINE support.
The current dxf plugin architecture isn't very efficient, especially if you
are loading large point clouds (LIDAR)
eg. it makes multiple lookups of the layer name for each vertex.
I don't know if I can improve this for the general case or if I have to add a
special large point cloud dxf reader."
It basically removes the static init() and exit() functions,and move them inside the observer class (the one that cleans everything up when the last media is unloaded).
It also add an extra check to clean up on exit if the QuickTime env is initialized, but no media is succesfully loaded / written (it might happens with streaming resources).
I tested it under WinXP with zero, one and multiple videos.
Stephan reads in copy: could you kindly check if everything runs smooth under OSX as well? Also, have you got a chance to test it with streaming media?
"
-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."
used but never restored to the decimal notation. That made OSG print messages
like the following after some notifications:
Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5
[...]
Scaling image 'brick_side.JPG' from (1b4,24f) to (200,200) <--- Values in hex
because of previous error.
[...]"
The vtf plugin wasn't working in Windows due to OS differences in the byte-packing of the header structure (on Windows, the big block read was causing a buffer overrun). I fixed this by reading the structure from the file field by field. It's now happy on both Linux and Windows."
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?"
