.chan file formatting

[bigben]

Hi All

I've done a bit of searching but got lazy... can someone point me to some info on the structure of text files used for importing settings for animations. I'm tossing up whether to create individual TGDs for animation frames or use text files for settings.

I'm also tossing up whether to move the camera or move the whole terrain via a global transform shader for x,z and restrict animation of the camera to altitude, heading and bank. The latter should help to avoid those problems that occur at greater distances from the origin.

Ben

[Will]

Hey Ben,

I don't know much about .chan but I do remember it being talking about in connection to XSI a while ago so I found it for you: http://forums.planetside.co.uk/index.php?topic=246.msg1369#msg1369

AS I said I don't really know much about it but I hope the link helps a little.

Regards,

Will

[bigben]

Thanks for the link to the other thread, even though it wasn't quite what I was after.

I'm looking at animating several TG parameters including shaders, lighting and atmosphere options as well as the camera. My approach uses a database rather than an animation program so in the end there probably won't be much difference between using a settings file or creating separate TGDs, but it would be nice to investigate both.

I had alluded in the past that I might release a runtime of this database solution, but this is not looking feasible anymore as each project would require extensive programming of the database to provide fully customisable control over each parameter.

[fREeCYCLE]

Thanks for the link to the other thread, even though it wasn't quite what I was after.

I'm looking at animating several TG parameters including shaders, lighting and atmosphere options as well as the camera. My approach uses a database rather than an animation program so in the end there probably won't be much difference between using a settings file or creating separate TGDs, but it would be nice to investigate both.

I had alluded in the past that I might release a runtime of this database solution, but this is not looking feasible anymore as each project would require extensive programming of the database to provide fully customisable control over each parameter.

I've had it in the back of my head that I'd be doing this for myself in the early stages.   Why do you feel it would involve termendous amounts of programming per project instance?  (remembering I'm new to this)  Doesn't quite ring right unless I'm missing something big.   If we can dump the animated channel data from TG into a generic text format, then why wouldn't a (reasonably) simple php/mysql solution work for redistributing the divided data?   I mean, the process seems limited to  'inhale, divy, format, exhale'.

Even if it were as crude as say... overwriting a new, single-frame .tgd file for each slave rig and then kicking off the slave render via a local crontab entry, providing a grep didn't turn up an existing process (can we pass flags to TG2 at launch?)... seems like it has viability as a itterative process (even if a loose and sloppy one).

Speaking of loose and sloppy.....what happened to GPU?   I had it working reasonably well with 0.9. and a 40rig farm.

[hyper1]

OK Ben,
We've got to stop meeting like this.  Here's the pdf for Nuke .chan file operation.  I've almost come to the conclusion that it would be easier to take a baked file, from your program of choice, make the necessary corrections for x,y,z and h,p,b and simply paste those coordinates into the .tgd file.  If you solve this riddle let us know.
Gary

http://www.leomedia.co.kr/newmedia/Download_Files/NUKE/Nuke_User_Guide.pdf

Hi All

I've done a bit of searching but got lazy... can someone point me to some info on the structure of text files used for importing settings for animations. I'm tossing up whether to create individual TGDs for animation frames or use text files for settings.

I'm also tossing up whether to move the camera or move the whole terrain via a global transform shader for x,z and restrict animation of the camera to altitude, heading and bank. The latter should help to avoid those problems that occur at greater distances from the origin.

Ben

[bigben]

...If we can dump the animated channel data from TG into a generic text format, then why wouldn't a (reasonably) simple php/mysql solution work for redistributing the divided data?   I mean, the process seems limited to  'inhale, divy, format, exhale'.

A number of reasons 

Potential placement of sun control:
Set planet, latitude/longitude, start date and time, end date and time... calculate position of sun for each frame
http://www.astro.uu.nl/~strous/AA/en/reken/zonpositie.html

Control of Surface shaders:
Change colours, coverage constraints... any numeric value

Cloud tweaks:
Changing weather, wind speed/direction etc...

Population control:
Rather than populate an entire planet with objects, restrict the distribution of objects to an area around the camera, moving each population with the camera. If surfaces are used to simulate objects on distant terrain then these need to be masked out of the population distribution and these masks must also be moved with the camera. The more I learn about TG2 the more ideas I get for how things can be done.

Tides:
e.g. Sinusoidal variation of water level

Interpolation methods and data conversion:
The method for calculating intermediate values between key frames can be completely customised to the type of data and the relationship between the way the data changes and the final render. Other data may be imported from other sources and may need converting to a form suitable for use in TG.

Integrating with other programs:
e.g. I use Panotools to use different lens projections, allowing extreme wide angle lenses to be used e.g. fisheye. This requires rendering multiple images per frame, stitching and then extracting the correct view from the stitched image (and cleaning up the temporary files). Using a commandline renderer this can be automated on a per frame basis.  And so on.

Here's an old project I did in TG0.9 using TerraTweak to create separate files for each frame.
http://www.path.unimelb.edu.au/~bernardk/terragen/terratweak/
The hardest part of this project was controlling the lighting transition for the sunrise/set. When I consider how much more is possible in TG2 and how accessible the variables are compared to TG0.9 it gets hard to keep a reign on the ideas 

I've almost come to the conclusion that it would be easier to take a baked file, from your program of choice, make the necessary corrections for x,y,z and h,p,b and simply paste those coordinates into the .tgd file.  If you solve this riddle let us know.

Thanks for the link. Looking at that and my answer above I think I'll probably end up on the per-frame TGD route. I've already done a proof of concept database (key frames sample image below of a converted Terranim script and increasing cloud cover). The database was pretty crude and I'm adding a TGD parser to make things a lot simpler (and make it possible to add some data validation to prevent stupid errors)

[fREeCYCLE]

Most of those notions seem geared around data manipulation outside of TG2.

All I was referring to was method of farm rendering a batch of frames for existing interpolated channel data which i was expecting to find in TG2.   (and my goal is only useful until an official network process emerges).   I think I'll hush up now and just sing along quitely for a bit.   

I'm not entirely sure what i stepped into on this thread, but I'll be watching regardless.    Thank you for the detailed response about your ideas!

[bigben]

Most of those notions seem geared around data manipulation outside of TG2...

While the data is manipulated outside of TG2, the question is which method is more practical to get the data back in.  Most of the variables have an "Import from text file" option and I'm trying to figure out how to format my data for the text file to import. Since both the TGD file and import file are ascii, implementing a solution for either is pretty straightforward (in principle). I suspect that even if I figure it out I'll probably end up using separate TGDs on the off chance that I try something that can't be done via the imported text file.

[JohnnyBoy]

As far as I know you would have to create a seperate text file for every parameter you want to import. The chan file can only have the camera info. I would be hesitant to develop too much for a program as unfinished as TG2.

[fREeCYCLE]

As far as I know you would have to create a seperate text file for every parameter you want to import. The chan file can only have the camera info. I would be hesitant to develop too much for a program as unfinished as TG2.

Rather quite what I was thinking.. quick and dirty but functional as a stopgap jumpstart on network renders.  I think ben's got substantially more ambitious thoughts.   My two cents;  make a hack fast and do whatever it'll do, but leave the rest until a control framework emerges from the man who do the voodo that he do.

So much for singing along quietly 

[bigben]

As far as I know you would have to create a seperate text file for every parameter you want to import..... I would be hesitant to develop too much for a program as unfinished as TG2.

Ouch! That's a lot of separate files. I'll definitely work on a separate TGD file process then. The process of collecting and manipulating data from TG2 is pretty straight forward, as is manipulating the data. The only thing that would really change significantly with further development of TG2 is the delivery of the data back into TG. This is just a finishing off process for me as the bulk of the work will be in the previous processes.

Rather quite what I was thinking.. quick and dirty but functional as a stopgap jumpstart on network renders.  I think ben's got substantially more ambitious thoughts....

I have a habit of learning things by trying to see how far I can push an idea until something breaks or I reach a logical extremity

Thanks for the feedback.

[Arandil]

OK Ben,
We've got to stop meeting like this.  Here's the pdf for Nuke .chan file operation.  I've almost come to the conclusion that it would be easier to take a baked file, from your program of choice, make the necessary corrections for x,y,z and h,p,b and simply paste those coordinates into the .tgd file.  If you solve this riddle let us know.
Gary

http://www.leomedia.co.kr/newmedia/Download_Files/NUKE/Nuke_User_Guide.pdf

Hi Gary, I reviewed the user guide you link to and I'm not certain where it details the .chan format.  I see the expressions section, but cannot deduce how to, for example, formulate a camera animation line.

Can you or someone else help me out?

Thanks!

[bigben]

I might try using keyframes within a tgd.  I looked into the tgd file after I created a few keyframes for a camera and ended up exporting the rest from excel/word.  Formatting is very basic so converting is a breeze....

These are my camera angle keyframes from my 10° tile panorama.

Code Select Expand

<param name = "rotation"
vf1 = "90 270 0"
vf2 = "80 270 0"
vf3 = "70 270 0"
vf4 = "60 270 0"
vf5 = "50 270 0"
...
vf611 = "-50 260 0"
vf612 = "-60 260 0"
vf613 = "-70 260 0"
vf614 = "-80 260 0"
/>


If the same xml style is used for imported files then it should be relatively straightforward. I'm in the middle of rendering at the moment but I'll have a play later.

[Arandil]

I might try using keyframes within a tgd.  I looked into the tgd file after I created a few keyframes for a camera and ended up exporting the rest from excel/word.  Formatting is very basic so converting is a breeze....

These are my camera angle keyframes from my 10° tile panorama.

Code Select Expand

<param name = "rotation"
vf1 = "90 270 0"
vf2 = "80 270 0"
vf3 = "70 270 0"
vf4 = "60 270 0"
vf5 = "50 270 0"
...
vf611 = "-50 260 0"
vf612 = "-60 260 0"
vf613 = "-70 260 0"
vf614 = "-80 260 0"
/>


If the same xml style is used for imported files then it should be relatively straightforward. I'm in the middle of rendering at the moment but I'll have a play later.

Gotcha!  That was my last resort .. lol

I'll give that a try, from your example output, it does look fairly straightforward.

Thanks!