Parsing the key 'map_bump' was processed in the block, where the attributes
for 'bump' are extracted and results into having parts of the key in the
extracted filename, generating an invalid filename.
The mentioned string compare could be removed without loosing any features,
because the key 'map_bump' is parsed correctly some lines below.
"a last submission for the obj plugin
* supports vertex color definition after vertex position by Clément Léger
* supports zbrush vertex color definition (as #MRGB comment) by Aurélien Chatelain
* adds a noReverseFace option to not mess with face definition by Aurélien Chatelain
* makes material parsing case insensitive (by Paul Cheyrou-Lagrèze and me)
* makes the plugin resilient to faulty vertex uv/normal definition (i.e. when a too big index is referenced) by Aurélien hatelain
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14641 16af8721-9629-0410-8352-f15c8da7e697
- materialName used to be not stripped of whitespace, making number of models
fail to load materials; now fixed
- stripping was considering spaces only, thus models using tabs had problems
to load correctly; fixed
- fixed references to textures; they did not performed conversion to native
directory separators
- make d (dissolve) takes precedence over Tr (transparency); there seems to be
a confusion about the Tr item - some claiming 1 to be opaque and 0
transparent, while number of models uses exactly the opposite. d (dissolve),
if present in the model, does not suffer from this confusion, thus using it
instead fixes the problem for many many models.
I put many comments to the file concerning d and Tr item as others may further
investigate. Let me know in the case of any problems."
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."
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
"
