XSI to chan

Started by JohnnyBoy, December 30, 2006, 05:25:30 PM

Previous topic - Next topic

Postglory

#60
Hi Jim, that looks spot on

Many thanks to both you and Johnny

JimB

Quote from: godzooks on January 18, 2010, 02:45:02 PM
Hi Jim, that looks spot on

Many thanks to both you and Johnny

No prob. Did you actually try it, though?  ;)
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

Postglory

Just tried it
I'm sorry but this is not matching either, look

http://www.vimeo.com/8823578

JimB

#63
 ??? Did you change the FOV in TG2 from vertical to horizontal?

Sorry, it's there in your screengrab.
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

JimB

Can you open both the local and global kine editors for your camera, just to see if they look anything like the screengrab of mine here, in terms of differences?

Ignore the scaling.
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

Postglory

I'll check.

I think the local and globals ended up having the same values after I baked and separated it.  Maybe thats the problem now.

I'll have a look.

The FOV was horizontal
Have a look at the picture in my last post do all the numbers in XSI and Terragen look right?


JimB

#66
Quote from: godzooks on January 18, 2010, 06:24:03 PM
Have a look at the picture in my last post do all the numbers in XSI and Terragen look right?

They look right to me after doing a comparison to mine here, with the + and - changes in the transforms where they should be.

Interesting that your local and global transforms are identical, though. That's where ours differ.

Ah, one thing I did do was create a new camera in XSI. I then constrained it (position and orientation) to the original camera and plotted it (based on something Hetzen mentioned earlier). You might want to try that.
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

Matt

#67
Quote from: godzooks on January 17, 2010, 10:41:24 PM
From what Mat is saying terragen's data input pannel is ordered zxy for rotation, but position is xyz right? this is very confusing.
So is the rotation in terragen really ROT -Z +X -Y?

No, I didn't mean that. The values are XYZ in the GUI for position and rotation. I am talking about the order in which the rotations are applied, and it can be changed as an option in most high end 3D applications. You can have the same numbers for rotating on the X, Y and Z axes, but if you rotate them in a different order you get a different result. It's explained here:

http://vimeo.com/2649637 (3:00)

You need to set your XSI camera's rotation order to ZXY. Unfortunately this can't be changed on the TG side yet.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Matt

I realise that changing the rotation order might not be possible after you have already tracked the camera, but maybe it can be done in the track? I think we need to find out whether it is set to ZXY at least, so we know whether to look elsewhere for the problem.
Just because milk is white doesn't mean that clouds are made of milk.

JimB

GZ, you can change the XYZ order in the camera's Local Transforms ppg, found under the camera's kinematics. See the screengrab above again:
http://forums.planetside.co.uk/index.php?topic=246.msg92577#msg92577
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

JimB

#70
Okay, I just did some more testing and I think I've got it figured out. The camera you will export should have its rotation order set to ZXY under its Local Rotation before you do anything with it. We will call it ZXYcam.


Create a new camera, rename it to ZXYcam, go to its Local Kine settings and change its rotation order to ZXY.

Constrain ZXYcam's Position and Orientation to the track_cam (or whichever camera is animated and has the movement you want to export).

Load up xsi2chan8.js (the one that reads the local rotations) in the script editor, and run it on ZXYcam.


That's it. You don't even have to bake ZXYcam. Both Matt and Hetzen were right. I just did another number of tests and that's the reliable one so far.
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

Postglory

Yes this seems to work, If I try to change the rotation order on the track cam all the track points jump off and this throws the track off, but if I create a second camera and change it's rotation order to ZXY its OK.

This does work, but in Terragen its not quite 100%, well not as close as XSI, just a very small slide, a couple of pixels, but this will be acceptable as I'll be doing the very close stuff in XSI.

Thanks all for all your help, you've save me alot of time, this has got to be the best forum I ever been on.

Cheers


JimB

#72
Quote from: godzooks on January 19, 2010, 11:48:41 AM
This does work, but in Terragen its not quite 100%, well not as close as XSI, just a very small slide, a couple of pixels, but this will be acceptable as I'll be doing the very close stuff in XSI.

Hmmm. I'm not happy about that. Here's an amended version of the above procedure, just in case there's a crappy carryover offset from the new camera heirarchy in XSI:


Create a new camera (usually called *.Camera1), delete all of its constraints, cut it from the Camera Root, and delete the unused Camera Root so you're left with an isolated independent camera.

Rename the new camera to ZXYcam, go to its Local Kine settings and change its rotation order to ZXY.

Constrain ZXYcam's Position and Orientation to the track_cam (or whichever camera is animated and has the movement you want to export).

Load up xsi2chan8.js (the one that reads the local rotations) in the script editor, and run it on ZXYcam.

Once in TG2, be sure to delete the imported camera's FOV animation, and change the FOV to the original animated XSI camera's FOV.
Some bits and bobs
The Galileo Fallacy, 'Argumentum ad Galileus':
"They laughed at Galileo. They're laughing at me. Therefore I am the next Galileo."

Nope. Galileo was right for the simpler reason that he was right.

Hetzen

I did notice a little juddering with our exports too, which I have a feeling is something to do with slight miscalculations of the linked cameras, and think that there maybe a little fighting between the two rotation orders.

I also think the ultimate solution, would be to have the option to pick one of the six possible translation orders from within TG. As a lot of animators do actually custom pick camera orders depending on the shot and what the required movement is. (Although z,x,y does offer the more probable use for landscape photography (except when you look straight up or down)), and most pro apps have this function built in. I'm not sure how difficult that is to impliment, and what priority that has in TG's development, but the camera import scale in the last build was an excellent step in cross platform integration, as was the ability to change camera appature (film back), but this I think is equally as important.

Glad you guys got it sorted out. I had a couple of weeks of head-meets-wall moments over a similar problem.

Cheers

Jon

Postglory

This is the result, still a little slide

http://www.vimeo.com/8845094