The patched loader also complains more loudly if a material library file wasn't found or if a referenced material wasn't found in the material library."
makes smoothing optional for verticies which do not have a normal
associated with them in the OBJ input file. The previous behavior was
to always smooth at all verticies which did not have surface normals.
In this new implementation smoothing is on by default to be compatible
with previous behavior. The user can now specify the "generateFacetNormals"
option to the reader to use facet normals for verticies where the OBJ
file does not specify a normal."
Note from Robert Osfield, changed "noSmoothing" naming used by Lee to "generateFacetNormals".
f 15939/9999/16177 15941/10000/16178 15940/10001/16179\
15938/10002/16180
In the OBJ loader the newline would be interpreted as follows
f 15939/9999/16177 15941/10000/16178 15940/10001/1617915938/10002/16180
However, for correctly loading the model it should be interpreted as
f 15939/9999/16177 15941/10000/16178 15940/10001/16179 15938/10002/16180
Thus, the escaped newline should be interpreted as a space.
I tried to lookup what the correct interpretation for a backslash-newline was in the OBJ spec but did not find anything useful. Nevertheless, my suggestion would be to adopt replacing the escaped newline by a space in order to avoid problems as stated above. I cannot imagine a meaningful usage of a newline within a numerical literal so I do not foresee cases where replacing a backslash-newline by a space would be harmful. The fixed obj.cpp is zipped and attached to this mail."
The following link shows a very comprehensive list of .mtl file options:
http://local.wasp.uwa.edu.au/~pbourke/dataformats/mtl/
Attached is a patch that should fix spacey filenames and optional texture scale/offset. I have tested it with files I have that I modified to contain spaces in the texture filenames."
1. Added options to control wether the osgUtil::Tessellator or osgUtil::TriStripVisitor are run. By default they still run just as before.
2. Added support for the Emissive material. The data was being read from the mtl file but was never being applied to the model.
3. This is the main bug addressed, when a model is read in with an alpha value specified like:
newmtl Material__8
Ns 24
d 0.33
illum 2
Kd 0.204 0.204 0.204
Ks 0 0 0
Ka 0.153 0.153 0.153
where the alpha value is d. The loader would then overwrite the alpha value when reading the diffuse, specular, and ambient colors. I have changed all the material color readers to only set the values they read and to use the default colors specified in the constructor of the obj class. With these changes, the obj reader now handles opacity correctly if the alpha value is specified before the material colo"
this fix strips whitespace off externally referenced material files.
fixes a bug where the obj listed something like:
mtllib FR_PARIS_ESPACE_UNESCO_S.MTL
and then that caused failures in the load later:
FindFileInPath() : trying /Users/rpk/Downloads/
FR_PARIS_ESPACE_UNESCO_S.MTL ...
this fix simply strips whitespace around that filename before passing
it on to the remainder of the loader."
Changes from Robert Osfield, change std::cout to osg::notify(osg::INFO)
- 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
"
obj-files. It is not feature complete but usable.
Known issues:
* not all materials are handled correctly (especially when using
osg::StateAttribute::OVERRIDE), not all properties are supported
* could not test point and lines, all of my programs which are capable
to read obj-files only import triangle-meshes.
* only simple texture-handling"
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
