Terrain Object export

Started by Mohawk20, March 10, 2007, 06:13:10 PM

Previous topic - Next topic


My brother is currntly working on a world for Myst Online: Uru Live, and needs a vulcanic landscape.
I thought, Let's make that in TG2, with some nice powerfractals and fakestones and all of that.

Problem is, he wants it as an object, rather than a heightmap, to preserve vertical details. How can I do that? Should I make a heightfield and try to get that as nice as possible and then export hat as an LWO, or is there a better way, so I can export a piece of the procedural landscape?


You can use the Lightwave "micro-exporter" to export geometry, but it would be difficult to get exactly what you want in terms of "vertical detail" since the exported geometry is dependent on camera angle. More info is here: http://forums.planetside.co.uk/index.php?topic=243.0

I'm surprised to hear that Uru doesn't utilize heightfields for its own terrain given their well-known efficiency. A mesh large enough to provide decent detail would be huge and quite burdensome for most game engines. If it *does* use heightfields than avoiding heightfield export isn't much use since it'll be limited by heightfield issues eventually anyway.

Ultimately TG2 may not be the best system as it's still not as easily controllable for terrain generation as other tools like World Machine, Leveller and Geocontrol. It's primarily a rendering application rather than for modeling. But if you can get the desired results out of it then more power to you.

- Oshyan


Well, the Uru worlds are made in blender by the comunity. So my brother uses an object and a surface texture. The texture is an orthographic render in Terragen.

We made one world for URU in TG 0.9, but that wasn't quite as good as possible (allthough better than anything others made because the shadows were in the texture, and shadowcasting wasn't available at the time).

That's why I want that vertical detail, for the terrain itself as well as for the texture.

I'll go check out the LWO export option....


the .lwo exporter (not the micro-exporter) works great!  matt came up with a very clever system for accomplishing this.

tg2 creates a series of .lwo's, as well as a .lws where the objects are already lined up and ready to work on.  warning tho, as each mesh object is VERY hi poly.

to get the whole thing into blender involves some work as well.  you'd have to, in lightwave, save all the separate meshes as one, then import that one enormous mesh into blender, which might choke on such a large object.  might not tho, i dunno :).

i can't imagine a game engine being happy with such poly heavy objects either (into the million somewhere)


Please help!

I'm getting a bit frustrated...
Oshyan, I need your expertise to device a workaround.

I am trying to export the terrain with the voronoi texture (check here for more info: http://forums.planetside.co.uk/index.php?topic=1037.0 ). Using the LWO micro exporter, I've set up 5 frames to render four angles and top view.
I have one extreme problem. The first frame renders without problem, the second crashes. The problem: I guess my fake stone are too big. I've resized from 1000 to 300. 1000 rendered the image shown in the other thread just fine, but I guess the other view had more stones visible.
I've had problems with this before, and resizing fixed the problem then (Check here: http://forums.planetside.co.uk/index.php?topic=744.0 ). (Difference here is I don't get the error message, but I guess it's still the same problem, only anim renders don't give some error messages, right?)

Anyway, to export using the micro exporter, the scene needs to be rendered completely. And I need those fake stones in the mesh. Is there any possible solution?

(And another question: For the micro exporter to work one should use the sequence render, and the normal render does not support it, right?)



The fake stones are not the problem, I started a frame 2 and it rendered complete. Frame 3 now halfway, what is the problem then? The LWO output?
Will it be overwritten per frame if I don't change the name per frame? And will that be something the program can't handle currently?

Anyway, problem sortof solved, kinda'...


And another thing (I just keep complaining and complaining... :-\)...

I have just insalled the update, and I gave it another shot, rendering only the first frame.
Wen I got home from work and had a look at my pc, I saw this Runtime error message (attached).
The image was fully rendered, but clicking OK allways shuts down the program, and I guess the data wasn't stored, not the LWO data anyways.

Just a bug of the new update that needs fixing, or a message from the new update, notifying a problem that allways has been there??


Mohawk, have you been able to get the micro-exporter to work *at all*? It may be that you just don't have it hooked up correctly yet.

I'm not sure why the crashing is happening, but it would be useful to determine whether it's related to the micro-exporter (disable/delete it and see if that fixes the crash). Do you have any populations in the scene? There is a known bug where large populations will cause crashes on sequence animation even though rendering the single frame will work - this may be a memory allocation error for consecutive frames.

In any case some more specifics of your scene, possibly sharing the .tgd, would be helpful.

- Oshyan


Well, the LWO does export, so that's fine.

I don't have to render all the frames in sequence, can do with one at a time.

I have no populations, only a fakestones shader.

Here is the .tgd:


It gives this error at 1024x768, and at 912x684.

It finishes without problem at 800x600. The LWO exports as well.
But I'd like to know why I can't render at larger resolution. I need a nice detailed texture, so bigger is better.

Any ideas? Will this be fixed soon?


I had a similar problem with my high resolution panorama test. Sequence rendering issues aside, the first thing I had to do was successfully render a single frame. This was a RAM issue for me.  By increasing the render size, you're increasing the resolution that TG needs to render, ie more triangles.

To get around this I had to first determine an image size that I could actually render.  I stuck to 10 pixels per 1° to maintain the final resolution and worked my way down from 90° degree tiles all the way down to a 10° tile before I could complete a render in a part of the scene with the most objects in view (15° tiles crashed).

For those frames with a lot of objects in them, render times were still in the order of 3-4 hours, partly due to the large size of the populations in the whole TGD, and also the number of trees visible in the frame.  Frames with no trees used less RAM and rendered quicker. Since then I found restricting populations to objects that could possibly be in view which greatly reduced the RAM usage so I could possibly go back up to a larger tile.  Fake stones are probably equivalent to objects in this respect in that more stones = more triangles to calculate.


I have rendered 2 of 5 frames succesfully, at 800x600, but it got stuck again at frame 3.
Do you think it would go on if I did a cropped render? (I think it does, gonna try it now...)

I must say this still is a bit frustrating, if even 800x600 starts to crash...


Mohawk, I'm not sure why this crashes. There doesn't seem to be anything terribly unusual or prone to crashing in the scene. I've forwarded it to development.

- Oshyan



1. Does it crash if you remove the LWO exporter?

2. Are you exporting a LWO for each of your 5 viewpoints? There should be no reason to do that. A single object should be sufficient.

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


Mohawk, remember that the microexporter is view, detail and resolution dependent. It will render geometry only from your current camera point of view and the density of that geometry will be dependent on the detail and resolution you're rendering at. I think it's basically like a direct dump from the subdivision engine as geometry (no doubt not fully accurate, but conceptually speaking at least...). The likelihood is that your game engine couldn't handle that much detail anyway, even if TG2 could export it.

- Oshyan