Parameter Limited Terrain Export?

[PabloMack]

I understand that a procedural terrain would produce far too much detail to export a whole planet full of terrain to a 3D package. However, if you limited the detail to a distance from camera and also set a lower geometric limit on scale, it should be very doable. Does TG2 have such a facility? I am wanting to export to Lightwave for the purpose of aiding in the compositing process.

[update]
I have found references to the "LWO micro exporter" that may be suitable for my needs. How do you bring this panel up?

[PabloMack]

Okay. I have created an "LWO micro exporter" node by right-clicking on the background of the Node View Window and
selected Create Other/LWO micro exporter. I can then bring the panel up by double-right-clicking on the new node after
finding it (its not obvious). I have specified a file name. Now how do I make it produce the file? There is no "Execute" or
"Okay, go ahead and do it" button. Do I invoke it by actually doing a render? Also, the node graphic has a down triangle
output. Am I supposed to connect it to something else?

I am presuming that the output doesn't include geometry that is not visible. That is okay and is even desirable. Does this
export include geometry that is visible from all camera locations in my camera path sequence or is the geometry only
generated from the camera's perspective from the current time frame?

All help is appreciated.

[dhavalmistry]

you would have to connect the lwo exporter to the render node under sequence/output tab and hit render sequence button

check the screen grab

just  be aware that the exported file size could get quite large.

[Floating.Point]

When using the Micro Exporter you must be careful with the detail settings of your render... this will affect the density (/size) of the LWO generated!!
in fact... its usually best to set up a new renderer just for the micro export with far lower settings than your actual hero render

[Cyber-Angel]

Well there is away round all of this if Planetside (Please consider) had an export feature where you converted the procedural landscape as a mesh (Quads please, not triangles) with the displacement been exported in the same file (Say .FBX or layered .PSD) as a separate map that would be loaded into the displacement channel of the target application with the artist given control weather this process is automatic (Target application creates appropriate displacement channel on import) or manual.

That way you could keep the detail created in TG2 without having to lose information using .LWO files using Grey-scale height-fields. This file, thus exported would also contain other important data such as Color, Reflection and so-forth again with artist control (Weather they are to be opened by the target application as an automatic or manual process).

The tessellation (Mesh conversion) process would either be an in Terragen option or more practically, an option on export form the File Menu labeled some thing like "Convert Terrain to Mesh" there should naturally be options about what is to be converted into a mesh, these might included

•   Terrain Viable to current render camera

•   User defined Tile Selection: User defines the terrain tile/s to be exported

•   Whole Planet Export: this option is likely to take longest in terms of user wait time, but this is codependent on many factors including file size, limitations (Technical) of chosen export format (Vendor issue rather than user issue), user hardware limitations etc.

Sorry, to hijack this thread but some thing to consider for the future.

Regards to you.

Cyber-Angel                               

[PabloMack]

you would have to connect the lwo exporter to the render node under sequence/output tab and hit render sequence button
check the screen grab just  be aware that the exported file size could get quite large.

It would make sense to have to do the whole sequence render to
produce a LWO because the geometry that is produced has to
be visible from every frame. However, TG2 produces a new LWO for
every frame and each LWO is only good for that frame. It doesn't seem
to produce a single LWO that is usable for all frames. It makes this
feature seem pretty useless in animation work and only useful for
stills. I can't imagine anyone trying to do an animation where the
object defining the terrain has to be replaced with a new one for
every frame. What a nightmare.

[PabloMack]

Of course you could position the camera straight down
to basically capture a part of the terrain that is
visible to the camera. But this would include parts
of the terrain that are not visible to the camera
at any point in its traversal of its animation path
and it would most likely not include distant features
of the terrain that are visible to the camera in its
traversal of its animation path. It is still better than
not having a terrain export method that includes
procedural terrain.

If TG2 could generate a single LWO that includes
all terrain that is visible to the camera throughout
its camera path, it would be extremely useful. You
could then use a perspective camera in Lightwave
to project the TG2 render sequence onto that terrain
and easily composite both renders into one sequence.
If TG2 can't do this yet, l would like to make this an
official feature request!

[dhavalmistry]

have you tried importing the object in lightwave?

[PabloMack]

have you tried importing the object in lightwave?

Yes. It works with no errors. However, the object is only "complete" for the frame it was generated for. As the Lightwave camera moves along the same path as the TG2 camera, its changing perspective will make it see missing parts of any one of the LWO's that were created for any one frame.

If you specify a file name in the LWO micro exporter panel such as Terrain%04d.lwo then it will save a series of objects, one per frame. If you just specify a single file name such as Terrain.lwo, then it will over-write that same file for every frame. I am presuming that it is not "updating" the object so that it is useable by all frames rendered so far, rather, the LWO is merely over-written with the next object that is generated for each following frame. It will take many hours of render time to see if my suspicion is correct.

In order to generate a single LWO that is usable by all frames in a camera path sequence, TG2 would need to scan all camera positions to check for visibility within a single render. But because TG2 is primarily designed as a still image renderer (with camera motion added later), it is understandable that the "inner loop" (still frame render) is unaware of the other camera positions. This camera motion makes up the "outer loop" iterating through the frame numbers. I suspect it would be a very messy and time consuming job to try to merge all of the LWO's generated from a camera motion sequence into one.

[dhavalmistry]

Have you tried "Heightfield export LWO" under heightfield operators?

[Henry Blewer]

There are a couple video tutorials made by Walli that explain exporting Terragen 2 data into Maya and 3DS MAX. the technique works using Blender. The tutorial uses the Lightwave exporter.

http://www.planetside.co.uk/content/view/58/27/

[Oshyan]

There are currently two different ways to export geometry from TG2. There is the LWO Micro-exporter, which is camera-dependent, back-face culled, and captures overhangs properly. Detail depends on the render detail because it's essentially exporting the same triangles created by the renderer. Then there is the Heightfield Export LWO, which exports a specified area of terrain, with no back-face culling, but it's planar-only, so no overhangs.

There is a lot of additional and relevant discussion in prior threads that should be helpful in your decision on which approach to take:
http://forums.planetside.co.uk/index.php?topic=1910.0
http://forums.planetside.co.uk/index.php?topic=4727.0

We will be improving the geometry export in a future update, including the ability to turn off back-face culling.

- Oshyan

[PabloMack]

We will be improving the geometry export in a future update, including the ability to turn off back-face culling. - Oshyan

Thank you for the info.  I avoid using Height Fields because of their many limitations.  I am in the process of learning how to create whole planets and that means that I am restricting myself to methods such as procedural terrains and spherically mapped masks. I really do like the way the LWO micro exporter works. However, I do lots and lots of animations and this is where I ran into a brick wall. I can't see how I can get my other SW tools (with LW in particular) to make much use of the way one LWO is produced for every render frame.

If I had one wish in this area, it would be to produce a single LWO that includes every poly seen by the camera in any frame in the whole camera path series.  This would make the LWO micro exporter suddenly very useful in animation work where now it is essentially useful only for producing stills. But I do understand that this may not be easy to achieve given the architecture of TG2. However, having the renderer consider the whole camera path for rendering individual frames could have many benefits. If the same geometry is produced for any one part of the terrain regardless of any one of the camera's positions, the terrain would no longer "throb" as it does while the camera moves. If one set of light sampling points were produced before render began, then light pulsating could also be eliminated. The many "flicker" problems that continually harry virtual terrain software could be eliminated. We have seen what problems arrise from trying to turn a still renderer into a motion renderer simply by putting it into a loop to produce a series of stills. Still pictures do not pulsate by their very nature, but when you show a series of stills as motion, the lack of coordination and sharing common information between frame renders becomes apparent. Acheiving this, though, means that more geometry is produced than is needed by any one still if the camera is in motion. This also means that the render will take longer but the results will be much better and the LWOs will be more useful to animators.

[PabloMack]

Have you tried "Heightfield export LWO" under heightfield operators?

One thing I have tried that works quite well is to move the camera upwards into the sky and face it downward towards the terrain so that it can see the whole camera path and beyond. This takes a "snap shot" of a rectangle of terrain that produces a LWO. This should work with any terrain including those produced using height fields and procedurals and it works for anywhere on the planet.  There are two downsides. First, extraneous terrain that is never seen by the camera along the whole camera path is not eliminated. Second, distant terrain that is outside of the "snapshot" might still be in view by the camera as it travels along the camera path and will not be included in the LWO.

[goldfarb]

one method that planetside might consider to solve this sort of issue is to be able to define an area using the camera frustum (with some padding)
this would allow you to run the animation of the camera and all the geometry seen by the camera (with or without BFC) would be put into a group (or have an attribute or whatever)
the the exporter would only mesh this group -> and out to a single file (or a series of files that contain regular tiles of this mesh - for very large terrain areas)

I hope improved terrain export is coming sooner rather than later

oh, one way you might look into creating a single mesh out of your per frame files is to fuse the points in LW (I'm sure there must be some kind of tool for that)