Planetside Software Forums

Support => Terragen Support => Topic started by: rcallicotte on March 16, 2007, 08:14:50 PM

Title: Images in Multishader Still Map wrong
Post by: rcallicotte on March 16, 2007, 08:14:50 PM
Imported objects are mapping wrong inside of the multishader.
Title: Re: Images in Multishader Still Map wrong
Post by: king_tiger_666 on March 16, 2007, 09:46:42 PM
I've had that too when trying to import the startrek model....

Title: Re: Images in Multishader Still Map wrong
Post by: rcallicotte on March 17, 2007, 08:06:49 AM
In my example I have a root '\' where there shouldn't be one.  Once that's gone, it works fine.  When I looked at my MTL file, it was mapped this wrong way too and, once changed, it imported fine.  That must be the issue.
Title: Re: Images in Multishader Still Map wrong
Post by: king_tiger_666 on March 17, 2007, 08:12:23 AM
do you use notepad to view a mtl file?

Title: Re: Images in Multishader Still Map wrong
Post by: rcallicotte on March 17, 2007, 02:25:41 PM
Wordpad seems better than Notepad (formatting issues), but I usually use Textpad which takes any format.
Title: Re: Images in Multishader Still Map wrong
Post by: Oshyan on March 19, 2007, 01:32:03 AM
Calico, does it look like this is indeed an error in the OBJ reader, or more of an issue in the mtl and/or model itself?

- Oshyan
Title: Re: Images in Multishader Still Map wrong
Post by: rcallicotte on March 19, 2007, 10:01:40 AM
Oshyan, the extra '/' in the name of the texture in the MTL seems to be a by-product of the way DAZ|Studio exports their maps.  Then, and this could hardly be seen as TG2's fault, when the imported object is converted to TGO the MTL keeps the same errant mapping.  It's a simple fix for me, but I believe it is the exporter's fault (DAZ Studio in this case).

If this isn't enough info, let me know.
Title: Re: Images in Multishader Still Map wrong
Post by: Oshyan on March 19, 2007, 02:19:26 PM
That is helpful to know as something to handle for compatibility. It would be most interesting to know if other exporters behave similarly. As I think has been said before the OBJ format is fairly broad and diverse, despite being a "standard" in some sense. So the more examples of different OBJ formatting we have, the better we can handle imports from a broader range of applications.

- Oshyan