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?
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.
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.
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 :)
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
Quote from: dhavalmistry on January 08, 2011, 11:54:11 AM
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.
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!
have you tried importing the object in lightwave?
Quote from: dhavalmistry on January 09, 2011, 12:56:15 PM
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.
Have you tried "Heightfield export LWO" under heightfield operators?
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/
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
Quote from: Oshyan on January 11, 2011, 12:05:22 AM
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.
Quote from: dhavalmistry on January 10, 2011, 01:06:49 AM
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.
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)
Quote from: goldfarb on January 13, 2011, 12:31:50 AM
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)
This isn't very effective because the actual geometry created for each frame is different. This is why terrain pulsates in animations. TG2 starts fresh on each frame and each geometry that is created is an approximation to allow only that needed according to the distance from the camera. As the camera gets closer, more detail is needed for a given part of the geometry so that more polys are rendered. This means that the vertices are highly unlikely to correspond to those of the previous frame. If you tried to merge all of the objects you would get an awful mess of polys superimposed in the same space but not corresponding exactly. You think that loading one of these objects into LW is slow; try 250 of them for a 250 frame animation.
But your idea of generating one geometry that is used for rendering all frames in a camera path series is exactly what TG2 needs to do. This should completely eliminate the terrain pulsation that has been plaguing my TG2 work. If TG2 also created one set of light sampling points that are good for the whole camera path series, light pulsation could also be eliminated. All of the "flicker" problems could be eliminated and Planetside would be way ahead of Vue in terms of animation smoothness. Alas, more computing power and memory would be needed but the results would be spectacular. And I would not have had to spend days of tedious manual labor "fixing" flicker by hand. What a pain.
BTW- After fusing points don't forget to merge polys. They require separate operations.
Quote from: PabloMack on January 13, 2011, 07:12:05 PM
Quote from: goldfarb on January 13, 2011, 12:31:50 AM
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)
BTW- After fusing points don't forget to merge polys. They require separate operations.
not in Houdini ;D
animated geometry import and the ability to export terrains are two big features that will really help Terragen break into VFX work...I can't wait :)
Quote from: goldfarb on January 13, 2011, 12:31:50 AM
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)
Fusing points in LW is done with the Merge 'm' command. Eliminating redundant polys is then done with Detail/More/Unify Polys.
After thinking about this some more, though, having an object produced with every frame in the LWO micro exporter may be the only way to get all of the animations done in TG2 out into another package (without having to redo them in that other package). However, it might be so much labor for anyone to use all of these per-frame-objects that this method may rarely ever get used in animation work. I am going to look into it further.
Yes this is a real pain :(
I know that improved LWO export is on the "to do" list, but I have no idea of course when this will be available.
If your terrain doesn't have big overhangs then the best option for now is to create an LWO from heightfield and export that.
No overhangs etc. then, but something suitable for camera animation for example...
Or generate a heightfield from your terrain, save as .ter and convert to .bmp which you can in turn use as displacement map to reproduce the terrain in your app of choice.
See my workflow here:
http://www.planetside.co.uk/content/view/61/99/ (http://www.planetside.co.uk/content/view/61/99/)
I just discovered that LightWave CAN use objects that are replaced on each frame. See link below:
http://www.newtek.com/forums/showthread.php?t=115989
This makes me very ;D
oh, sorry...I didn't mean to imply that one would want to use per-frame terrains, I was referring to the obj objects etc...
one way to get terrains with overhangs into LW (or whatever) would be to use the LW exporter from a series of cameras placed to get as much of the terrain as possible - then fuse them, then hunt down any little areas that have low detail etc, and fix them with the standard poly tools...
Quote from: Tangled-Universe on January 16, 2011, 01:03:37 PM
Yes this is a real pain :(
I'm glad we see eye-to-eye on some things.
Quote from: Tangled-Universe on January 16, 2011, 01:03:37 PM
If your terrain doesn't have big overhangs then the best option for now is to create an LWO from heightfield and export that.
Or generate a heightfield from your terrain, save as .ter and convert to .bmp which you can in turn use as displacement map to reproduce the terrain in your app of choice.
See my workflow here:
http://www.planetside.co.uk/content/view/61/99/ (http://www.planetside.co.uk/content/view/61/99/)
For now I am avoiding heightfields altogether because I am working on designing whole planets using methods that apply to whole planets. I have glanced at some of your work for creating more local views. I am very impressed by your "Cloud Peak animation". I look forward to reading and going through it when priorities allow.