Planetside Software Forums

General => Terragen Discussion => Topic started by: Hetzen on October 15, 2009, 12:55:36 pm

Title: Camera Rotation Import Issues
Post by: Hetzen on October 15, 2009, 12:55:36 pm
....with importing cameras.

I thought I had this worked out. But what ever I do, my animated renders seem to slip when comp'ed together from max and TG.

I really need some help here. What is the workflow for getting a Maya camera into TG?

To explain, we've had some models rigged in maya with an animated camera. The camera is then exported to max, so that scenery models can be rendered with vray scatter and vray GI. The background has been allocated to me, and I've been using TG, and don't mind saying is looking really good, (more to do with TG than me).

The routes I've tried so far..

Importing Maya cam into Max via FBX format, then using Emecstudio's script to export a .chan file.
Exporting Maya cam via FBX into a Nuke camera, then exporting a .chan from there.
Using a Maya script to create a mov file, then trying to get TG to read that.

All of them so far haven't worked, and I'm running out of time.

I could really do with some help now....

Title: Re: Ok, I really need some help now....
Post by: cyphyr on October 15, 2009, 01:10:13 pm
Are your objects and camera far from the 0,0,0 point, ie in orbit or above? If so TG will "round" the imported camera numbers up or down thereby creating the "slipage" your seeing. The only solution I've come across so far is to use the imported data to create some "pseudo" key frames (note down the frame numbers where there is least "slippage") and then copy paste the camera locations from the pseudo key frames to your actual render camera. Not ideal but it will work in some situations...
Title: Re: Ok, I really need some help now....
Post by: Hetzen on October 15, 2009, 01:16:55 pm
Thanks Cypher, the largest distance I have from the origin is -115 metres. In fact, the positional data seems to be correct, it's the rotational that's messing it up by the looks of things.
Title: Re: Ok, I really need some help now....
Post by: Matt on October 16, 2009, 12:18:34 am
What's the camera rotation order in Maya/Nuke etc.? If it's not ZXY (assuming Y is Up), some extra conversation will need to be done.

Can you email me a video showing the slippage?

Title: Re: Ok, I really need some help now....
Post by: Hetzen on October 16, 2009, 06:21:05 am
Thanks Matt, I would appreciate you having a look for me. The job has an NDA attached, so I need to swap out the model and replace it with some reference objects on the same horizontal plane, but I'll certainly send you a movie and also the maya fbx file.

For this particular shot the rotation translational order is x,y,z. But this will change per shot. Is there a formula I can use to work out other combinations? Would changing the translation order in Nuke when importing an FBX possibly fix the issue? Could I convert the Maya camera to a target/aim camera, then get Nuke to work out the rotation to generate a free camera?

Is there an app out there to solve these sorts of problems? I can't get Bigben's to open, which is a shame, as I have to scale the positional data as well as handle this rotation problem, and it looks like Bigben has written it to solve precisely these issues.

Anyway, incoming!! (e-mail).

I've basicly got the weekend to solve this.
Title: Re: Ok, I really need some help now....
Post by: Hetzen on October 16, 2009, 09:55:06 am
Ok, I'm begining to understand the problems now. After finding out about rotational orders and gimble locks, I can now see the difficulty in any conversion to a set format of Z,X,Y or any format for that matter. And why animators use different orders for specific movements.

Here's a usefull video link which explains the problem very well....

The FBX I get from Maya drops straight into Max, because Max can also change the rotational sequence of it's cameras. Is this a posibility with a future Terragen?

At the moment, I'm getting the Maya guy to attach a Z/X/Y free camera to his X/Y/Z camera, and see if we can bake the keyframes, although he is doubtfull on whether this will work. I'm also more aware of why Davy's Emecstudio plugin has struggled with this problem.

It's such a shame that I can't get TG to line up with bespoke camera setups, because the displacment power of the program is second to none. Looking at Littlecanons excellent "Flaky Canyon" render, our producer commented on how good it would be to get that sort of displacement and texturing on our near ground castle rock model. At the moment, I wouldn't even want to try and attempt it due to this alignment problem. A back ground plate we may be able to fudge it in post, but no way with tight masks.
Title: Re: Ok, I really need some help now....
Post by: cyphyr on October 16, 2009, 10:57:51 am
Have you tried to get the fbx data into a spreadsheet and change the order of the rows and export a .chan file from there. I was able to do this effectively with Lightwave but it was a fairly complex procedure. I dont know anything about Max or Maya so this may be entirelt irrelevant but if the work flow is useful give it a go.
link (

Good luck
Title: Re: Ok, I really need some help now....
Post by: Hetzen on October 16, 2009, 11:43:28 am
Thanks Cypher, unfortunately it's not a simple matter of swaping columns, because each column effects the next in calculating the rotation. Have a look at that video posted above, it explains the problem very well. It also shows how vector rotation works, similar to how TG describes it's planes.
Title: Re: Ok, I really need some help now....
Post by: Hetzen on October 16, 2009, 12:01:45 pm
Right, an update, and I'm not going to celebrate just yet. But this maybe of use to anyone who comes across a similar problem.....

Linking a Z,X,Y camera to the animation camera, then, baking on the keyframes seems to have done the trick. We've also used a script found at this page...

To generate a .mov file, which is really a .chan file. Because each frame has a keyframe, there is no interpolation between keys to go wrong. Well that was our theory. And at the moment it seems to work. The weird thing is that we used the verticle FOV generated from the .chan file instead of the horizontal.

So not counting chickens yet, we'll see how a full rez render works out over the weekend.

Thanks Richard and Matt for chiming in.