The first leak is in the lib3ds module (yeah, I know that probably should be corrected at http://code.google.com/p/lib3ds/ but I'm assuming that as no commits have happened there since 2011 that it may be better to fix the copy we have in the OSG of that project) The leak is caused by lib3d's use of realloc(ptr, 0) to free up memory allocations, but realloc, when ptr==NULL returns malloc(0) rather than NULL and thus leaks a zero byte allocation. The solution here was to adjust the 'lib3ds_util_reserve_array' function so that it realloc is not used to release a NULL pointer.
The second leak is in ReaderWriter3DS.cpp and arises when any of the created StateSet objects added to the StateSetMap don't subsequently get applied to a Node. The solution here was just to simply use the osg::ref_ptr around the raw StateSet pointer that was used in the locally defined StateSetInfo struct."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14854 16af8721-9629-0410-8352-f15c8da7e697
The osg 3ds plugin modify the exported materials name in the same way it modifies the node names.
I've added an option to preserve originals materials names, with the assurance of unique material names are preserved."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14283 16af8721-9629-0410-8352-f15c8da7e697
The plugin does not support images without alpha channel for opacity
This seems to indicate that the check for alpha should be against the opacity map. I've attached the updated file.
"
1. Respect "noMatrixTransforms" option for matrices attached to meshes, not only those attached to nodes
2. traverse_nodes variable did the exact opposite of it's description.
3. Always try to load referenced textures, even if we can't find the files (in order to the the registry's ReadFileCallback have a stab at it)
"
2. Removed unecessary code. Also made sure the images names are not truncated in the middle of an UTF8 character. You'll find there a function called utf8TruncateBytes(), which may be moved in core OSG (osgDB/ConvertUTF I guess). Feel free to do it if you feel it that way.
"
recently we noticed a little mistake for 3DS files using instances of the same meshs: Every groupnode gets the same name instead of the (correct) instance name of the object. The fix only consists of two additional lines which check whether an instance_name is given for the object and then uses this one instead of the node name."
a byte order issue.
The problem is that osg::SwapBytes code has been copied from the old
plugin to the new one, but the latest lib3ds also incorporates code to
handle byte ordering in read & writing. So the net result is that the
swap is done twice.
The solution is simply to remove the custom osg code, and use the
stock lib3ds code. The attached files are against today's revision
11331. I've tested on Sparc & Intel.
"
- Fixed handling of MatrixTransforms (still doesn't support other Transforms types). Fixes things for OSG, DeepExploration, 3DSMax...
- Added support for writing double precision vertices by converting them.
- Added base code for future compatibility option (3rd-party apps that don't read animation data). See "DISABLE_3DS_ANIMATION" compile flag."
- Replaced exceptions with assert() or OSG_NOTIFY
- Replaced osg::notify() with OSG_NOTIFY
- Changed braces and tabs to fit OSG coding convention
- Cleaned a few things in code (names, added deallocations upon error)"
And by refactoring a bit of code, I may have fixed some StateSets related bugs (was ignoring StateSets for osg::Groups).
I also added support for Billboard's points, so now "osgconv lz.osg lz.3ds" has an acceptable output. However, there is no rotation depending on billboards' axis, hence the notice "Warning: 3DS writer is incomplete for Billboards (rotation not implemented).". You may want to remove this notice (or lower the notify severity) if you feel 3DS doesn't have to handle such rotations.
The attached archive contains 3 files from 3DS plugin, against rev. 11162.
Please note there is still the textures issue for cow.osg. I guess it's because it's not a "flat, dummy and standard" texture in slot 0... That is to say the only thing the writer can handle at the moment. I guess I won't address this soon.
"
and
"I've detected and fixed another bug in 3DS writer: support for automatic splitting of meshes having >65k faces/points was buggy (was deleting faces).
Here is my four 3DS modified files (in a ZIP), against rev. 11193, including previous fixes AND Stephan's fix about relative filenames."
- Improved identifiers generation in duplicate name handling (was limited to 1000 name collisions, which can be very short for some usages).
- Set all read/write operations use a custom log function that will redirect lib3DS log to osg::notify() (was only used for streams)
- Removed custom code (now uses osgDB::getFilePath())
- Added missing supportsOption() calls
- Cleaned a few minor things"
- Fixed creation of useless intermediate nodes
WriterNodeVisitor.cpp fixes:
- Fixed naming of textures (path and extension)
"
Note from Robert Osfield, this submission also came with changes to use of ref_ptr<> and removal of delete[]'s, but these were not merged as they didn't actually fix any memory leaks, and in once instance introduced one.
"Here is our freshly baked 3DS reader/writer (named 'v0.5' to differentiate from previous one). Changes are against trunk rev. 10819.
Short changelog (from rev 10819):
- Added 3DS writer
- Sync'd with latest lib3DS
- Added options, especially "flattenMatrixTransforms" to get the "old" behaviour (else the reader correctly maps to OSG the transforms from the 3DS file).
What should be done:
- Check with pivot points, with and without "flattenMatrixTransforms" option.
- We ran tests on it, but we can never be 100% sure there is no bug. Testing from the community would of course be helpful."
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."
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
