I'm working on a script to export a chan file from XSI, but I have a problem. The format of a chan file -
I can't find any documentation but this seems to work:
frame transform-x transform-y transform-z rotate-x rotate-y rotate-z fov
Here is what my script writes:
0 11 10 13 -30.422317286858405 40.23635830927338 -2.2915070762099087e-13 53.638
1 10.996722 9.997616 13.002086 -30.417123111374756 40.22340511257526 -1.6245761040608907e-13 53.592252607999995
2 10.986976 9.990528000000001 13.008288 -30.40166731792109 40.184888554657064 -2.4979281989690596e-13 53.457483264
3 10.970894 9.978832 13.018522 -30.376121930504585 40.121316563193545 -2.2252353394993361e-13 53.237401215999995
I import the chan file into Terragen2 and it works! However I need to adjust the transforms to match terragen2 values.
I want to include more functionality in the script like adding light info(I noticed this is possible because of the MAX plugin).
Does anybody have any idea how this is formatted?
At the Nuke site you can get help if your a developer or own the software, but that doesn't help me. :'(
Johnny, is this a script within XSI? I really have no idea about chan files, but I could really use getting a camera animation from XSI to TG2. The other big problem is getting the terrain from TG2 to XSI in the first place.
Is this relevant at all?
http://www.highend3d.com/xsi/downloads/tools/3d_converters/XSI-to-Nuke-Chan-exporter-4032.html (http://www.highend3d.com/xsi/downloads/tools/3d_converters/XSI-to-Nuke-Chan-exporter-4032.html)
I just realised that Generating the Heightfield and saving as a .ter file means you can use the GEM elevation dataset importer in XSI (I hadn't found the .ter save option):
http://www.highend3d.com/xsi/downloads/plugins/utility_external/import/3817.html (http://www.highend3d.com/xsi/downloads/plugins/utility_external/import/3817.html)
Hey, I'm writing it in jscript which runs in XSI's script editor.
So far it lets you select your start and end frame and the camera you wish to use.
I'm working on saving a file to a user selected directory and naming the file. (It defaults to the C: drive right now)
I also want to let the user select a null to use as an alternate origin.
I did a test with an xfrog tree and the camera matched perfectly in both apps. (I still need to do more tests to make sure rotations are not broken)
This is a very simple script, unfortunately I am just learning jscript and XSI's Object Model so something that should take 5min is taking me 1 or 2 hours. :) But I did start this last night and it already works so there is hope!
I don't like that exporter because you have to chage values in the script and I like to use popup dialogues. (Plus I don't know python)
Quote from: JimB on December 30, 2006, 07:32:13 PM
I just realised that Generating the Heightfield and saving as a .ter file means you can use the GEM elevation dataset importer in XSI (I hadn't found the .ter save option):
http://www.highend3d.com/xsi/downloads/plugins/utility_external/import/3817.html (http://www.highend3d.com/xsi/downloads/plugins/utility_external/import/3817.html)
Here is another .ter importer for XSI and MAX:
http://www.guruware.at/main/index.html
It's main advantage is that it can read in your terragen scene file and match the camera. But it's not for Terragen 2.
I tried the XSI to Nuke exporter, but TG2 expects at least 7 columns in the .chan file, whereas the exporter only has 6. Changing the first column to the frame numbers changes the X translation to 1, 2, 3, 4, etc, but the .chan file doesn't seem to need a frame number.
I exported a terrain from TG2 to .ter format, and imported that into XSI via GEM. I then ran the XSI2Nuke chan exporter on the camera.
The .chan file was edited in a text editor, where I added the FOV as a new column, making 7 columns. This imported fine, but the terrains don't match, although the camera move seems to be good in a lo-res test anim.
Need to figure out the proper terrain export procedure and any offsets.
Thanks for making this seem currently possible.
Jim.
Quote from: JohnnyBoy on December 30, 2006, 07:50:45 PM
Hey, I'm writing it in jscript which runs in XSI's script editor.
So far it lets you select your start and end frame and the camera you wish to use.
I'm working on saving a file to a user selected directory and naming the file. (It defaults to the C: drive right now)
I also want to let the user select a null to use as an alternate origin.
I did a test with an xfrog tree and the camera matched perfectly in both apps. (I still need to do more tests to make sure rotations are not broken)
This is a very simple script, unfortunately I am just learning jscript and XSI's Object Model so something that should take 5min is taking me 1 or 2 hours. :) But I did start this last night and it already works so there is hope!
I don't like that exporter because you have to chage values in the script and I like to use popup dialogues. (Plus I don't know python)
Quote from: JimB on December 30, 2006, 07:32:13 PM
I just realised that Generating the Heightfield and saving as a .ter file means you can use the GEM elevation dataset importer in XSI (I hadn't found the .ter save option):
http://www.highend3d.com/xsi/downloads/plugins/utility_external/import/3817.html (http://www.highend3d.com/xsi/downloads/plugins/utility_external/import/3817.html)
Here is another .ter importer for XSI and MAX:
http://www.guruware.at/main/index.html
It's main advantage is that it can read in your terragen scene file and match the camera. But it's not for Terragen 2.
Thanks for that - I was typing my last post at the same time as you ::)
Johnny, I got it all working now! Thanks! ;D
I used your TGtoXSI importer on a .ter file, created an animation, and then ran the XSItoNUKE exporter, added the FOV column at the end in the .chan file. It all seems to match, but I had to reload the .ter file I created at the start and ran through your converter. A lot to learn yet.
Thanks again.
Quote from: JimB on December 30, 2006, 08:55:36 PM
Johnny, I got it all working now! Thanks! ;D
I used your TGtoXSI importer on a .ter file, created an animation, and then ran the XSItoNUKE exporter, added the FOV column at the end in the .chan file. It all seems to match, but I had to reload the .ter file I created at the start and ran through your converter. A lot to learn yet.
Thanks again.
Heh, that's not my converter, I just happened upon once and you brought it back to my mind. ;D I could upload my script after testing a few more things if you want to avoid entering fov values.
Whoops, sorry ;)
I made a test, only 10 frames. Cubes rendered in XSI as an RGBA_Matte (they intesect the terrain), then comped on top of a TG2 render. Unfortunately, I don't have Mpeg output right now, so can't post it. Will try to find an alternative tomorrow.
It'd be great to try out your script though. It looks to be the bee's knees.
I used the terImport and noticed it scales the terrain by 1/10th so it works better in XSI. So I added a scale parameter that defaults to x10 for exporting the camera. This seems to work perfectly, but I rendered a few frames using the same camera resolution in both apps and noticed it is offset a bit(see pic). My (first)guess is that the ter file is offset from the origin a bit. I'll try to get this fixed for version 1.0 tomorrow.
After rendering 100 frames everything seems to match up. My problems last night may have been from camera settings not matching.
Using the script:
Change the file extension from .txt to .js
Open it in XSI's Script Editor. Views>Scripting>ScriptEditor
Set up the animation. (I used terImport to make sure the camera matched the terrain)
Refer to attached picture for these steps:
1. Select the camera you want to export. (Don't use camera_root or interest)
2. Click run in the script editor. (If you get errors it's because you selected the wrong part of the camera or something else)
3. You can change settings here, The frames default to whatever you have set for your in and out values.
scaleCam- defaults to 10 (Use this value if you used TerImport and didn't change the scale factor on import)
nullOrigin- Does nothing at the moment. (You can select a null and check this box, but no code)
Enter a file name.
4. Select a folder (This doesn't work properly- If you navigate to another folder nothing is saved)
Just click on the Select button and it saves to your current project folder.
You should see a message that it Exported Successfully.
-EDIT-
Newest version below.
I plan to fix the problems, add more functionality and improve usability and optimise the script. Suggestions welcome.
Thanks Johnny, I'll give it a whirl later. I'm having issues with importing a very hi-res .ter created in WM into XSI right now, so need to find a workaround. I also see that the clouds "oscillate" in brightness during an animation, which is a tad irritating.
Thanks for posting the script and I'll get feedback to you as soon as I can.
Jim.
Cloud brightness variations may be due to GI. If it's on currently try turning it off. If necessary you may need to revert to a basic fill light setup without GI. That can still give you very good results.
- Oshyan
Quote from: JavaJones on December 31, 2006, 02:10:03 PM
Cloud brightness variations may be due to GI. If it's on currently try turning it off. If necessary you may need to revert to a basic fill light setup without GI. That can still give you very good results.
- Oshyan
A fill light? ??? I'm not after very good results, to be honest; I'm after first class results that can't be bettered.
I already figured out it was GI, but without the GI being baked into the clouds this could always be a problem (and a pretty serious one). I don't see how I can use a fill light on the clouds and not the terrain, especially a fill light that would need to cover the entire cloudscape in a parallel manner!?
What I can't understand is why the terrain, which also receives GI, doesn't flicker, when that flickering as well would follow through logically with the rendering overall.
I'd got a fantastic result on clouds, but now this messes all of that up. Essentially, what you're saying is that GI can't be used in Atmospheres for animation? I really hope I'm wrong.
I've tried both with and without GI now, and the latter is looking nowhere near as good as the former on a single frame basis. Just so you know ;)
I also tried switching from GI to Ambient Occlusion, but that flickers as well.
I'm saying that *in its current state* GI may be problematic for animations, particularly on clouds. That doesn't mean it will always be that way - there's lots of room for improvement.
I don't know for sure why it's an issue with clouds and not terrain but I would guess the light transmission and volumetric nature of the material has a lot to do with it. It's a much more complex interaction than light on an opaque surface. Perhaps it is subject to more variability, particularly where sampling is involved. It may be that upping your cloud samples or GI samples would help, but this would of course increase render time. We do plan to support GI baking though, so you may just have to wait for that.
The Enviro Light can be used without GI and it should still have an effect. You may then be able to still control the strength on surfaces and in the atmosphere separately. If so this might give you a more stable lighting solution. Fill lights would affect both terrain and sky, yes, but then so does GI. Do you have the Enviro Light affect turned down for terrain or something?
- Oshyan
Thanks Oshyan, I've just set off a render using a potential workaround which involves increasing the light propogation mix ad other bits. It means the clouds look 'murkier', and don't pick up the freshness and the blues in the distance, but maybe I'm getting ahead of myself a bit.
Anyways, Happy New Year.
Jim.
Sounds good. Let us know how it goes as we certainly do want to enable quality professional-level animation work with TG2. Knowing the issues with current workflows will help us get the final product where it needs to be for these kinds of tasks.
- Oshyan
I had a problem with a worldmachine .ter that I had to adjust vertically in TG2 to be level with the rest of the world. The camera from XSI would then be below the ground in TG2. Added an adjust vertical parameter in the script.
Ex. If you add 1000 to the height in TG2, just enter 1000 for the adjustVert field in the script.
Quote from: JohnnyBoy on December 31, 2006, 11:25:08 AM
4. Select a folder (This doesn't work properly- If you navigate to another folder nothing is saved)
Just click on the Select button and it saves to your current project folder.
This really bothered me, so I fixed it. It will work like your standard XSI UI now. :)
Just done a test, and it works perfectly!! ;D ;D
Thanks for that, you are a star!!
I duffed up earlier because I forgot to make sure I had horizontal FOV switched on. That always gets me scratching my head for a while and then giving it a big old slap.
Cheers,
Jim.
Great to hear :), I noticed that sometimes the fov doesn't seem to be imported and I have to check and uncheck the FOV box in TG2. ??? Let me know if you have any suggestions or problems.
Hi everyone,
Great work Johnny boy :)
I assume that, for all this to work, you need the commercial (paid) version of T2TP, right ?
thanks,
nick
Yeah, you need the version with animation capabilities. Get it while it's cheap. ;)
Heh, yeah I 'm very seriously tempted to do that :)
Thanks for clearing that up !
nick
Yup I have the same issue with my height fields brought in by World Machine and the same tip made mine work too.
Now i can go back to testing out the Terragen --> Maya--> Terragen pipeline via chan files some more.
Quote from: JohnnyBoy on January 01, 2007, 07:21:46 PM
I had a problem with a worldmachine .ter that I had to adjust vertically in TG2 to be level with the rest of the world. The camera from XSI would then be below the ground in TG2. Added an adjust vertical parameter in the script.
Ex. If you add 1000 to the height in TG2, just enter 1000 for the adjustVert field in the script.
Thanks so much for the script. Works very well. Anyone have any thoughts on the best method to use to match a sunlight accurately between the two apps? I tried some complicated mathematics to convert the direction of an infinite light in XSI to the Heading/Elevation in Terragen, but did not get like results. I may have fubar'd one or more of the calculations, or equations... so I was wondering if anyone has already outlined a workflow that searching may have missed.
Funny, I asked the same question yesterday:
http://fl-tw.com/InfinityForums/viewtopic.php?t=4259&start=50
Scroll down about halfway through the post, I plan to add an export for lights to this script along with "other things" in the future, I've been waiting until a final release though.
Haha... coincidences are always great. I'm going to keep at it, and maybe I'll come up with something based upon those responses. Thanks for the link.
Here's a good site that may help:
http://www.euclideanspace.com/maths/geometry/rotations/conversions/index.htm
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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/8807724)
http://www.vimeo.com/8808043 (http://www.vimeo.com/8808043) this is the altered script version 6
http://www.vimeo.com/8809474 (http://www.vimeo.com/8809474) this is the unaltered script version 5
And you changed the camera from Vertical FOV to Horizontal FOV in Terragen? It defaults to the former on import IIRC.
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.
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
Quote from: Hetzen on January 18, 2010, 08:01:33 AM
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
I just tried that and it still doesn't work. Exactly the same result as previous.
Here's the test: http://vimeo.com/8815155
The numbers in the Transform fields are the same between TG2 and XSI except for the necessary changes to plus or minus.
can it be the FOV's dont match?
It definately looks like a rotation order problem. I was getting very similar results matching up a village to a lake edge.
Sorry for jumping in on this thread without knowing what you've done in the script. Am I right in asuming that all the keyframes in the rotational columns mach up in value? If so, then something is not right in matching the transform order. I'm pretty sure you can't just swap rotation columns around in a text editor, as the rotation order in TG tells the camera to first roll in Z, then with the X axis rotated pitch up or down along that axis, which then sets the Y axis. If you rearange that order, to say X,Y,Z, and feed in the same rotations, you'll pitch up/down first, then swivel on the new Y axis, then finally roll on the new Z, and end up facing in a very different direction. Try rotating your index finger with thumb and middle at 90 degrees to each other, through those translations, with the same values in for x,y,z.
Sorry if I'm stating the bleeding obvious.
Quote from: FrankB on January 18, 2010, 09:49:51 AM
can it be the FOV's dont match?
They're the same Frank. The rotations and translations are also off, as if some kind offset is being added through the animation.
Quote from: Hetzen on January 18, 2010, 09:57:49 AM
It definately looks like a rotation order problem. I was getting very similar results matching up a village to a lake edge.
Sorry for jumping in on this thread without knowing what you've done in the script. Am I right in asuming that all the keyframes in the rotational columns mach up in value? If so, then something is not right in matching the transform order. I'm pretty sure you can't just swap rotation columns around in a text editor, as the rotation order in TG tells the camera to first roll in Z, then with the X axis rotated pitch up or down along that axis, which then sets the Y axis. If you rearange that order, to say X,Y,Z, and feed in the same rotations, you'll pitch up/down first, then swivel on the new Y axis, then finally roll on the new Z, and end up facing in a very different direction. Try it with your fingers at 90 degrees.
Sorry if I'm stating the bleeding obvious.
But that doesn't account for the camera to cube distance being different by the end of the animation I posted, surely?
Are the distances different? Looks like the camera is just facing the wrong way.
Try rotating your index finger with thumb and middle at 90 degrees to each other, through those translations Z,X,Y - X,Y,Z - Y,Z,X, all through 30 degrees. Your index will face a different direction each time, even though all the rotation values are the same.
I just put another elongated cube in XSI Z+ and it imported into TG2 as expected (TG2 Z-). The camera to cube relationship is fine at the outset (the imported XSI camera is in TG2 Z- at the start, as it should be).
Matt, are there any hidden Angular Position offsets in the camera that perhaps weren't there in older versions of TG2?
If rotations are local to the camera in Terragen, would a local rotation export out of xsi not solve this?
Quote from: godzooks on January 18, 2010, 11:46:39 AM
If rotations are local to the camera in Terragen, would a local rotation export out of xsi not solve this?
The camera SRT's are global both before and after baking. There's deliberately no heirarchy involved. I did compare both Local and Global transforms and they're identical.
I did find a Python script that exports a .chan for Houdini. It only writes six columns (Pos and Rotation), so it needs to have the frame number and FOV columns added (first and last respectively). I'm clueless with Python (and most things including speaking English coherently), so if someone wants to look at it ...:
http://www.highend3d.com/xsi/downloads/tools/3d_converters/XSI-to-Nuke-Chan-exporter-4032.html
Right, can someone try this out. I took another look at the Global and Local comparisons using a different property editor, and there were differences.
I've changed the Jscript again and it seems to work at last.
var oTrans = cam.Kinematics.Global.Transform;
became:
var oTrans = cam.Kinematics.Local.Transform;
Again, I hope Johnny doesn't mind all this faffing about with his script.
The python script fails at line 23
f = open(File, 'w')
Any ideas?
Quote from: godzooks on January 18, 2010, 01:35:30 PM
The python script fails at line 23
f = open(File, 'w')
Any ideas?
Forget the Python script, the new version of the JScript seems to be working fine (xsi2chan8.txt). I'm just rendering a version now, and the first 50 frames as a comp on top of the XSI render looks spot on. I'll post it on Vimeo.
If you really want to mess about with the Python script, look to the line near the top that gives the output filename beginning with /Home...
Create a new .chan file in your directory of choice (rename a new text file) and replace the Python script's /Home with the new file's full filepath and filename (be sure to do forward / not backwards \ ) It basically needs a previously created .chan file to write over. But then you'll have to find a way to add the frame number column at the start of the .chan file. TG2 only accepts .chan files with 7,8 or 10 columns apparently.
Something's definitely changed over time. Perhaps baking the camera now needs a Local transform output, and non-baked needs Global? I need to look into it just in case. Weird.
Here's the video showing the match between XSI and TG2 using xsi2chan8.js :
http://www.vimeo.com/8821430
Hi Jim, that looks spot on
Many thanks to both you and Johnny
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? ;)
Just tried it
I'm sorry but this is not matching either, look
http://www.vimeo.com/8823578 (http://www.vimeo.com/8823578)
??? Did you change the FOV in TG2 from vertical to horizontal?
Sorry, it's there in your screengrab.
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.
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?
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.
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
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.
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
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.
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
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.
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
This is the result, still a little slide
http://www.vimeo.com/8845094 (http://www.vimeo.com/8845094)
It's better if I bake the camera before the export, but only very slightly.
That makes sense. Glad you got something useable.
You're sure the sliding in the latest video isn't a lag caused by an offset in the comp?
I'm not sure what you mean, I'm rendering out of After effects and just using the terragen bmp image sequence and an avi(with alpha) on top, but it does look like some sort of lag.
Terragen's frames start at 1, where as other apps start at zero. That maybe the offset.
Terragen can render frame 0, or even negative numbers if you don't mind the first digit being turned into a '-' symbol.
There is no offset, I tried moving a frame each way.
The only other thing is the image aspect, in the match mover it's 0.563, in XSI it's 0.5626 and in Terragen it's 0.5625, but I wouldn't have thought such a small change in value would give this error as each program is just rounding up in there own way.
I'd create four small cubes, position each one to sit at the bottom of each chair leg, merge them and export that as an obj. Then import it into TG2 and see if they match. It might be an offset of the camera during export.
Glad to see you guys working the issue out. I haven't been able to use xsi since upgrading to Vista - can't justify the money for an upgrade as a hobbyist.
Johnny, glad you wrote the script in the first place ;)
By the way, I'm pretty sure I had no problems installing XSI 7 on Vista using the same installer as the one I used on XP. In fact, there were a few features (import formats) on the 32-bit version which were missing from the 64-bit version.
Quote from: JimB on January 30, 2010, 11:02:23 AM
Johnny, glad you wrote the script in the first place ;)
By the way, I'm pretty sure I had no problems installing XSI 7 on Vista using the same installer as the one I used on XP. In fact, there were a few features (import formats) on the 32-bit version which were missing from the 64-bit version.
JimB
Hopefully this isn't out of line, but would you mind bundling up your cube example (xsi scene file and .tgd) to help us dissect what you guys did? I have been through this post several times and am still having trouble.
Thank you.
Quote from: JimB on January 30, 2010, 11:02:23 AM
Johnny, glad you wrote the script in the first place ;)
By the way, I'm pretty sure I had no problems installing XSI 7 on Vista using the same installer as the one I used on XP. In fact, there were a few features (import formats) on the 32-bit version which were missing from the 64-bit version.
Actually, I only have XSI 5, and it would install - but not function properly. It's a real shame because it was my favorite 3D software. I haven't tried using it on Win 7 yet, it's worth a shot. :)
Hi I know it's been a while but I finally got around to uploading my showreel on youtube and it contains the result of the terragen2 to XSI I was doing for my Uni project. It's the short part with base jumper on the tower, I used Terragen2 for the background, I know it could have been acheived in an easier way but I there was more to it and I wanted to get to grips with the workflow methods between the 2 apps. I had to really cut back on the detail in the background due to rendering demands and other projects. I also used Terragen2 in the hand head shot for the background but this was more of an environment sphere setup.
Well now I have Nukex and am trying to work out the workflow for that.
Regards and thank for all the help especially Jonnyboy.
Lee
http://www.youtube.com/watch?v=nKILGFFbWcQ (http://www.youtube.com/watch?v=nKILGFFbWcQ)
Don't be shy, link us to your showreel. ;D
- Oshyan
sorry, it's there now.
Looks good. I always like to see breakdowns of scene construction. Would be nice to see it in HD though. :)
- Oshyan