Today there are two major definitions of keyword Tr in mtl. And both of them are applied in different big 3D softwares. So I think it a proper way to add a new option equalizeTransparency in materialOptions of MTLLoader.
According to the original spec http://paulbourke.net/dataformats/mtl/ , there's no Tr field. The Tr field is added into mtl format later than other field, and up to now, there are not any 'standard' spec defined it.
The most widely used definition might be set Tr = 1 - d. The value of 1.0 of d or the 0 of Tr means fully opaque. This is used in Wikipedia, and most of other softwares.
However, another definition is using Tr as an alias of d, with the same usage. So the fully opaque is d = Tr = 1. This implementation is recorded in andrewnoske鈥榮 wiki and another spec from Department of Scientific Computing at Florida State University (FSU) (They delete it at early 2014. So this link is the cache page from web.archive.org). This definition is accepted in 3ds Max, vcglib and MeshLab.
related to #43
Is that issue id correct?
My fault. sorry.馃槀
for example, if you use 3ds max to export a obj and mtl file, you will probably find
Tr 1.000000
d 1.000000
in the output mtl file.
If you use meshLab (which use vcglib to save file), you can only find
Tr 1.000000
and no d field.
I like this solution:
https://github.com/syoyo/tinyobjloader/issues/43#issuecomment-269862274
@mrdoob Unfortunately, that solution isn't enough. It only deal with some of the specific cases rather than solving the problem itself. And definitely there are cases isn't covered.
one example is the mtl file from meshlab. There is no d field but one Tr with the definition of Tr = d. We cannot decide how to understand this Tr field.
鈽癸笍
Most of the OBJ importers (including those for 3DS Max) process the "d" parameter only.
If "d" is missing, dissolve is set to 1.0 (fully opaque).
@RemusMar
I have no idea about other importers' implementation..But for my personal work these days, I used meshlab and it use Tr only for transparent.
If I understand correctly, your suggest is giving up parsing Tr field?
(Well, it may not solve the problem I am facing now)
Another possible solution is process d field when it exists, and process Tr field if and only if there is no d field. However, an option indicating how to process Tr is also necessary.
By the way, I send an email to Dr. John Burkardt, the owner of Ts=d definition web page from FSU. He has no idea too. Perhaps this is a historical issue and no one can tell us which is correct. Thus my suggestion is improving compatibility as much as we can.
But for my personal work these days, I used meshlab and it use Tr only for transparent.
The "Tr" parameter was never a part of a MTL standard.
So in my opinion it should be ignored by the MTL loader.
You're free to create a custom MTL loader (not a big deal anyway) and to process the "Tr" parameter.
The "Tr" parameter was never a part of a MTL standard.
So in my opinion it should be ignored by the MTL loader.
I totally understand and agree.
Actually there is no "MTL standard" I think. The link we can find called "MTL material format (Lightwave, OBJ)" is also an excerpt from Alias|Wavefront, Inc. 1995. I do believe such a widely used feature (you can find it in lots of big 3D programs) should be considered as a extension or update of the file format lifetime, rather than something be of no great importance.
Why not make it work for most practical cases :)
Here is a custom MTL loader able to add normal maps (the "map_norm" custom parameter):
http://necromanthus.com/Test/html5/Claire.html
Coming back to your MeshLab and Tr parameter, all you have to do is to edit (with Notepad) this file:
https://github.com/mrdoob/three.js/blob/dev/examples/js/loaders/MTLLoader.js
Replace the content of line 467 with
params.opacity = n;
In other words,, make the "Tr" case the same as the "d" case.
That's all.
well. I absolutely know how to change it, that's actually what I have done in my project.
See my PR #12862 , which adds a new option to indicate Tr definition.
Or, as you just said, there might be an alternative PR, which delete the whole case 'tr' block from line 462 to line 472.
I am not here just arguing and complaining for this issue but try to contribute.
See my PR #12862 , which adds a new option to indicate Tr definition.
Just think about this scenario:
every user will add a custom parameter to the MTL loader.
We'll end up with ... LOL
every user will add a custom parameter to the MTL loader.
They don't need to change anything in their code for the most common situation. The default value will keep it works. Only when you meet another specific situation (like your model provider uses another Tr definition), you can also make it work using this option.
I send this PR just because I think MTLLoader a some-how standard sample, it should provide the most basic or the most compatible implementation. Rather than a misleading implementation to work with one kind of input and crashes with others. 馃槃