its not a bug, its the way you have named your intances or the way
your exporter generates them.
just clear spaces in your materialid.
but indeed, it would be nice if it would work out of the box for L3DT
outputs.
Can you send me offline a set to test [obj, mtl, texture] generated by
this app?
So I can test and update the parser?
Fabrice
On Aug 6, 2009, at 2:44 PM, David Parks wrote:
Hi there,
In loading an OBJ from L3DT, I found that the Obj loader makes the
assumption that the textures referenced in the MTL (using map_Kd)
don’t have any arguments. It expects the file name as the first
token after map_Kd (but it should take the last).
In looking at the specs (http://ozviz.wasp.uwa.edu.au/~pbourke/dataformats/mtl/
) it looks like the format should be (file name last):
map_Kd -options args filename
I have an MTL generated from L3DT which makes use of these options
(the MTL is referenced below), it also demonstrates two other minor
issues – path names with spaces; and absolute paths with “\” in
them, both of which cause the loader some issue.
I added a function to parse the more complex map_Kd and added one
line to swap “\” for “/” in the base URL to get the loader to work
with MTLs generated by L3DT on a win platform. I’ll post those
updates in a bug report if there’s no other question/issue here.
As always, thanks for all the amazing work that’s gone into this
product!
Dave
p.s. is it best to post something like this before opening a bug, or
better just to open the bug in a straight forward case? Just curious
about the preferred protocol.
# L3DTio_OBJ2 MTL File
# Material Count: 1
newmtl terrain_mtl
Ka 0.000000 0.000000 0.000000
Kd 0.640000 0.640000 0.640000
Ks 0.500000 0.500000 0.500000
Ni 1.000000
d 1.000000
illum 1
map_Kd -s 1 1 1 -o 0 0 0 -mm 0 1 C:\temp\folder with spaces
\testExport_TX.jpg
