XSI to chan

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

Previous topic - Next topic

Postglory

January 16, 2010, 01:13:03 pm #31 Last Edit: January 16, 2010, 01:14:37 pm by godzooks
Hi I was wondering if anybody knows how to use the xsi to chan plugin?

I use xsi to model my objects but when I try and export the camera using the chan script it messes up the rotation data, position data is fine.

The exported data seems to be global rotation data, is there any way to get the local camera data out?  I have used the max2terragen plugin and it is ok but I am not very proficient with max and I can not get it to match with the objects I make in xsi when setting up in terragen2 (xsi obj and max camera).  Is there an alteration I could do to the script to get local rotation data for the camera rot instead of global?  

I have tried crosswalk to move between xsi and max without success.

This is for match moving from live action so the data needs to be spot on, so there is no sliding.

Thanks.

JimB

Here's a mod of Johnnyboy's jscript that addresses a problem that I found was happening with the more recent releases of either XSI or TG2.

I hope he doesn't mind.

Change the .txt suffix back to .js

It might iron out any problems you have, if they're the same as the ones I was having.
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

Thanks for replying so quickly, but it still exports incorrect rotation data, it seems to pivot in the wrong location for the camera within terragen2.

thanks again.

Postglory

Here is a screen grab of the script, I changed the tranforms in both local and global, as see in the history part at the top, siPivot and siGlobal, also the output seems to only output global for both pos and rot.
I'm not really very good with programming, does anyone know how to split the output into global for position and local in the rotaion.

Thanks.

JimB

January 16, 2010, 08:21:09 pm #35 Last Edit: January 16, 2010, 08:42:49 pm by JimB
I just ran it and it works fine.

If the problem you're having is simply because you're expecting to see the exact same numbers in the SRT fields then it won't happen because of the different ways XSI and TG2 work with coordinates. That's partly the point of the script.


My pipeline usually involves rendering a LWO mesh of the landscape from a viewpoint within TG2, using the Render Sequence/Output>Micro Exporter. Low rez settings are fine for general reference.

Import that LWO into XSI. The mesh then acts as a properly translated reference point for XSI which you know is positioned, scaled and rotated correctly through translation. What you then do in XSI will translate correctly across to TG2.

Within XSI, child the entire tracking scene under a new model and rotate, translate and scale the track to suit the TG2 mesh. If the camera has an up-vector constraint I initially bake the camera animation to get rid of any possible SRT dependancies which may put the camera roll off kilter.

Select the camera and run xsi2chan6.js making sure the scale is 1:1


Seriously, I just tried it to check the JScript is okay and it worked just as expected. I've used it in production. The key thing I've always found is to not try to fit TG2 to your XSI scene, but do it the other way around. Parenting the tracked scene under a new model means that the camera's relative position to other parts of the track is not changed no matter how you move the model around.

I also avoid exporting a heightfield as a .ter under the Right-Click option, as importing it into XSI usually means you have to do the SRT adjustments yourself and it can go badly wrong. An exported mesh using the Render node means the exported mesh for reference is bang on the money, even though it comes in looking like a LIDAR scan.
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

Unless you have an unusual setup, I think the global rotation is the right one to use.

Perhaps it is the rotation order. What's your XSI camera rotation order set to? It probably needs to be ZXY to match with TG2, as I didn't see anything in the script that converts from other rotation orders.
Just because milk is white doesn't mean that clouds are made of milk.

JimB

Here are comparison frames from a quick 100 frame anim showing the match between XSI and TG2 using the script. I resized the heightfield in TG2 to 40x40 to match XSI's grid size.

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

January 16, 2010, 10:41:50 pm #38 Last Edit: January 17, 2010, 12:14:22 am by godzooks
Hi,

Yes the script works fine with a normal camera simply animated in xsi, so it must be something to do with my match move camera in xsi, it has keys for pos and rot on every frame, the closest I can get is if I alter the script by changing the global tag to local and deleting the pos data part of the output, then import it only to the rotation after the main chan import, but some of the values are given minus values in the export.

When you bake the camera in xsi do you use the tools/ plot/ all transformation command? and do you have to tick the box for null in the script?

Postglory

I've just noticed that the original match move xsi scene camera(direct import from match move software as .xsi) exports fine with the script and it's only when I merged the scene with another scene and moved things about, that things have messed up, there must be something in the new scene that corrupts the script when exporting and leaves the scene looking ok in xsi.

It may be easier to just learn to program and make a script for the matchmove software.

JimB

January 17, 2010, 06:38:26 am #40 Last Edit: January 17, 2010, 06:40:28 am by JimB
Quote from: godzooks on January 17, 2010, 12:24:28 am
I've just noticed that the original match move xsi scene camera(direct import from match move software as .xsi) exports fine with the script and it's only when I merged the scene with another scene and moved things about, that things have messed up, there must be something in the new scene that corrupts the script when exporting and leaves the scene looking ok in xsi.

It may be easier to just learn to program and make a script for the matchmove software.


Even since the days of Softimage3D I've always avoided merging scenes like the plague. Can you bundle up one scene into a Model/EMDL, and then import that into the other scene instead? It's more reliable.

Or, the camera still has constraints attached somewhere. Bake the original tracking camera in the original tracking scene (I use Tools/ Plot/ All Transformation and don't tick the Null box), and also delete all constraints once you've done that. To test that the camera isn't still influenced by anything else, cut it from the camera heirarchy, delete any constraint objects, and run the animation to make sure it's now independent and behaving correctly.

As for some of the values giving minus values in the export, that sounds like what you want to happen. XSI uses different coords to TG2. That's why I render a mesh in TG2 using a Micro Exporter within the render settings to use as a reference object imported into XSI, and base the animation within XSI around 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.

Postglory

January 17, 2010, 10:41:24 pm #41 Last Edit: January 18, 2010, 12:22:37 am by godzooks
Hi,
I followed your instructions and still can not get a decent track match, the mesh from terragen matched perfect in xsi, I baked the camera, deleted the constraints and separated it from everything.  It's close as you can see below, but still not right.
The camera settings are the same in both xsi and terragen:
fov=24.569 inches horizontal
fl=57.1568 mm
back plate= x 24.892mm     y 44.252mm

The camera data in terragen is POS     -X +Y -Z      ROT   -X +Y -Z
The camera data in XSI is        POS     -X +Y +Z      ROT   -X -Y -Z

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?

http://www.vimeo.com/8807724
http://www.vimeo.com/8808043 this is the altered script version 6
http://www.vimeo.com/8809474 this is the unaltered script version 5

JimB

And you changed the camera from Vertical FOV to Horizontal FOV in Terragen? It defaults to the former on import IIRC.
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

January 18, 2010, 07:40:29 am #43 Last Edit: January 18, 2010, 07:48:35 am by JimB
Okay, I just redid the whole test from scratch. It's now not working with either v5 or v6 of the script. I'm a bit baffled given it previously worked fine as seen in the grabs above.  ???

The lineup seems to start fine using v5 of the script (which is baffling in itself), but by frame 100 the camera has gone off. I'm rendering TG2 and XSI versions and will blend them together. Will post on Vimeo.
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

Quote from: godzooks on January 17, 2010, 10:41:24 pm
So is the rotation in terragen really ROT -Z +X -Y?


I had a similar issue exporting a .chan out of Maya, and the way we got around it was by linking a Z,X,Y rotation order camera to the camera already animated in Maya (IIRC was set at X,Y,Z), then baking the Z,X,Y camera and using that data. Not sure if this is precisely the problem, but looking at your videos, the track is actually shifting on the wrong axis, so something is working in the wrong order.

Jon