Interesting note for people trying to merge Maya renders and Terragen renders together via compositing.
I set my Maya working units to Meters and created a 1 meter cube which i exported as a OBJ.
In Terragen I made a 1 meter height field and loaded my OBJ. The OBJ was giant compared to the one meter heightfield.
If I scale my OBJ by 0.01 on all axis then it fits perfectly in to the 1M heightfiled.
Hopefully the same applies to the camera motions in Maya and by scalling them down I can get the exported Chan file to match when rendered in Terragen.
Very useful info. I wonder if this is an issue in how Maya saves OBJ's, how TG reads them, simply a fundamental "meter" interpretation issue, or something else. Can you try loading the Maya object in another application that supports real-world scaling?
- Oshyan
I'll do more tests and report back my findings later in the week.
Have a look here for some things that turned up with Johnnyboy's XSI to TG2 chan exporter:
http://forums.planetside.co.uk/index.php?topic=246.0 (http://forums.planetside.co.uk/index.php?topic=246.0)
There may or may not be some clues there.
What happens if you export an LWO from TG2 to Maya? Do you get the reverse happening?
What I have found is that leave the Maya settings at centimeters and when you import into TG2 it is in meters (i.e., 1cm in Maya equals 1m in TG2). Therefore the need to scale by 0.01.
Cube exported with cm from Maya (side = 1cm)
# This file uses centimeters as units for non-parametric coordinates.
mtllib test2.mtl
g default
v -0.500000 -0.500000 0.500000
v 0.500000 -0.500000 0.500000
v -0.500000 0.500000 0.500000
v 0.500000 0.500000 0.500000
v -0.500000 0.500000 -0.500000
v 0.500000 0.500000 -0.500000
v -0.500000 -0.500000 -0.500000
v 0.500000 -0.500000 -0.500000
vt 0.000000 0.000000
vt 1.000000 0.000000
vt 0.000000 1.000000
vt 1.000000 1.000000
vt 0.000000 2.000000
vt 1.000000 2.000000
vt 0.000000 3.000000
vt 1.000000 3.000000
vt 0.000000 4.000000
vt 1.000000 4.000000
vt 2.000000 0.000000
vt 2.000000 1.000000
vt -1.000000 0.000000
vt -1.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
s off
g pCube1
usemtl initialShadingGroup
f 1/1/1 2/2/2 4/4/3 3/3/4
f 3/3/5 4/4/6 6/6/7 5/5/8
f 5/5/9 6/6/10 8/8/11 7/7/12
f 7/7/13 8/8/14 2/10/15 1/9/16
f 2/2/17 8/11/18 6/12/19 4/4/20
f 7/13/21 1/1/22 3/3/23 5/14/24
Cube exported from Maya with meters (side =1m)
# This file uses meters as units for non-parametric coordinates.
mtllib test.mtl
g default
v -50.000000 -50.000000 50.000000
v 50.000000 -50.000000 50.000000
v -50.000000 50.000000 50.000000
v 50.000000 50.000000 50.000000
v -50.000000 50.000000 -50.000000
v 50.000000 50.000000 -50.000000
v -50.000000 -50.000000 -50.000000
v 50.000000 -50.000000 -50.000000
vt 0.000000 0.000000
vt 1.000000 0.000000
vt 0.000000 1.000000
vt 1.000000 1.000000
vt 0.000000 2.000000
vt 1.000000 2.000000
vt 0.000000 3.000000
vt 1.000000 3.000000
vt 0.000000 4.000000
vt 1.000000 4.000000
vt 2.000000 0.000000
vt 2.000000 1.000000
vt -1.000000 0.000000
vt -1.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 0.000000 1.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 0.000000 -1.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 0.000000 -1.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn 1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
vn -1.000000 0.000000 0.000000
s off
g pCube1
usemtl initialShadingGroup
f 1/1/1 2/2/2 4/4/3 3/3/4
f 3/3/5 4/4/6 6/6/7 5/5/8
f 5/5/9 6/6/10 8/8/11 7/7/12
f 7/7/13 8/8/14 2/10/15 1/9/16
f 2/2/17 8/11/18 6/12/19 4/4/20
f 7/13/21 1/1/22 3/3/23 5/14/24
It looks to me like the second cube actually has sides 100m long, not 1m as the header claims... So Terragen would seem to be acting appropriately, assuming that the units are meters.
Quote from: swiftstream on January 24, 2007, 06:55:25 PM
It looks to me like the second cube actually has sides 100m long, not 1m as the header claims... So Terragen would seem to be acting appropriately, assuming that the units are meters.
I agree. Also I noted that if you check the "Source in centimeters" box it reduces the size by 10 not 100. so the box reduces to 10M on a side.
Tonight I'll do another test of geo exported out of terragen and in to Maya. And see what type of scalling needs to be done when going in this direction... terragen --> Maya via LWO
Lwo can be imported directly in to Maya via The Beaver Project or if you load the LWO in to Modo
and turn it in to a Maya Ascii from there. Modo and Maya units are the same when exporting as a Maya Ascii.