XSI to chan

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

Previous topic - Next topic

JohnnyBoy

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. :'(

JimB

#1
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
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

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
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.

JohnnyBoy

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

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.

JimB

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.
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

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

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  ::)
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

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.
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.

JohnnyBoy

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.

JimB

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.

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.

JohnnyBoy

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.

JohnnyBoy

#10
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.

JohnnyBoy

I plan to fix the problems, add more functionality and improve usability and optimise the script. Suggestions welcome.

JimB

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.
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.

Oshyan

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

JimB

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.
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.