TG2 Heightfield Export does not match "LWO micro exporter" output in 3d space

Started by SteveScout, October 11, 2010, 09:40:51 AM

Previous topic - Next topic

SteveScout

Hi, folks!

I´m still trying to find the best way to integrate TG2 with the big 3d softwares on the market, on no tutorial yet has featured the WHOLE workflow for real professional vfx work. But I am ALMOST there! Just one last problem - maybe you can help me! I just want to match the LWO(s) from the "Heightfield export" with the "LWO micro exporter" output in a 3d software package that imports and exports cams to TG2.

My workflow is easy, I set up a scene, render a picture, export a lwo micro exporter during render, convert it to 3ds in DeepExploration, save the scene, import the 3ds (from LWO micro exporter) in 3dsmax and import the camera via the MANTANIA 3dsmax-terragen2 plugin. Size, scale etc. matches without any changes .. I can now export new cameras done in 3dsmax and import them via chan-files in TG2. But now I need more detail on the ground for shadow casting of 3d objects etc., and the lwo micro export output just has too many "holes", even if rendered from different camera angles.

I read all posts in this forum explaining how to output another LWO without holes from the Heightfield export - but this export (after converting to 3ds) is way smaller and positioned somewhere else in 3d space of 3dsmax after importing.
I was not able to get a live view in the 3d windows from the heightfield .. somehow there is no white rectangle representing the heightfield, so I could move it around or scale it with the values. But this is not a problem .. Í don´t have problems exporting hundreds of megabytes of data to get a clean ground - but I don´t find any way to scale or reposition the LWO file before exporting so it would match the (definitely correct!) mesh from the LWO micro exporter when both are put in one scene in 3dsmax.

Has anybody tried this before with success? Or is there anything very obvious and simple I´ve just been overlooking?

thanks!

Steffen

Matt

I realise this reply is pretty late, but I hope you (or others) find it useful.

The LWO exported from the Heightfield Export LWO node doesn't have any world space translation baked in. It's a geometry export of the raw heightfield data, prior to positioning by the Heightfield Shader or anything else. I'm surprised it doesn't have the correct scale though, as scaling attributes are stored in the heightfield nodes and I would think they are exported to the geo.

I think you should be able to find the world space coordinates of the heightfield by looking at the Heightfield Shader's location parameters, and then entering those in 3DS Max. You might have to swap the Y and Z coordinates, and negate Terragen's Z coordinate (which may be the Y coordinate in Max). DeepExploration might have its own ideas about how it scales the geometry though, so you might need to scale your translation values, and that's something you'd have to test on your end.

If the Heightfield Shader uses "position centre" then you might need to do some maths to figure out where the bottom left corner is. To do that you'll need to know the size of the heightfield in metres, and the way to do that will depend on the source of your heightfield. But you can get a rough estimate of coordinates by reading out coordinates in the 3D Preview.

If you read this and get a chance to try it out, please let me know how you get on.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Matt

I forgot to add that we're planning on making the LWO export more robust this winter. In particular, we want to solve the problem with holes in the exported geometry (i.e. back-facing culled polygons and any other bugs we might find), and allow export of larger files than what is possible at the moment. These improvements should be available early 2011.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Floating.Point

I have found that the further away the heightfiled export is from 0,0 in world space-
When bringing it into your 3D app of choice, there will be slight anomalies.
To circumvent this, I have used a transform shader in TG2 to reposition the terrain I want to export (back towards 0,0)
and then found that matching the alignment is much better / perfect.
I have only done this successfully using procedural terrain... I have been unable to 'translate' my terrain with the transform shader if it combines heightfields with procedurals.
(any ideas on doing that?)
(hope this made sense)


Looking forward to the new micro exporter :)

JimB

I've done this dozens and dozens of time, but importing into XSI, and never had a problem with alignment. But I've never had an intermediary stage as you do with 3DExploration (XSI natively imports LWO format). Are you sure 3DE isn't applying its own transforms to the mesh on import and changing the geometry's centre and SRT's to suit itself, and there isn't an option to not change the geometry's centre when importing into 3DE?

Also, when you export your camera from Max, is there an SRT transform happening then to the camera, so you might think you'r eworking to the same scale, etc, but you're actually not? I have to change the xsi2chan script's scale setting from 10 to 1. 1 unit in TG2 is 1 metre, which I therefore also use in XSI.

If I don't want the "holey" type of mesh, I export a .ter using Heightfield Generate (from the last shader before it plugs into the Planet node) and bring that into Daylon Graphics Leveller, which has a very useful optimised mesh output in obj format. But then I do have to work out the transforms to get the Leveller mesh into proper position and scale within XSI. I just have to do the maths.

Matt -- "In particular, we want to solve the problem with holes in the exported geometry"

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