erosion

Started by TheBadger, November 20, 2014, 10:33:38 PM

Previous topic - Next topic

TheBadger

 :-[
When I export from TG I get a warning that my XYZ are not the same, and that older versions and other software may not like it.
When I try to load it into GC2 I get  bounced. It say the size is not an allowed size for the .ter 10,??? something.

Any ideas?
It has been eaten.

Oshyan

It's saying the dimensions are not "power of two+1", which was a limitation in TG Classic but has since been removed. So valid "original" TER format sizes are square (x and y dimension the same) and one of these numbers of points to a side: 129, 257, 513  2049, 4097, 8193. So what you need to do is change your heightfield under "Number of Points" to be one of those dimensions, e.g. 2049x2049. In the case of an imported DEM terrain you would need to use a Heightfield Resize operator and use the "Resample pixels" option. To maintain resolution and detail I'd recommend 4097x4097.

- Oshyan

TheBadger

Thanks man. I understand you.

The last thing I wanted to ask is about the total size of the DEM VS the part of the terrain that I actually am interested in. If I add a simpShape to the network and isolate the general area I want, will that make it through the save as part? I mean do I have to take the whole terrain (which is massive) or can I just take the part I want, similar to when making a terrain object?
I see that the camera has no effect here. But I was just wondering about it having that control.
My understanding is that what you wrote is only about the file not whats in the file.

And really lastly, more generally, can I also save a .ter in this same way, from an imported vectorDisplacement? I am thinking that I can. But if you know that I cannot please let me know.

Thanks again for your help.
It has been eaten.

Oshyan

Simple Shape won't help you. You need to constrain the export area. Since you can't do this with the Geog Heightfield Shader itself, you have to use a sneaky workaround. I'm pretty sure it will work, but no guarantees of quality, etc. You'll just have to try it. So...

Take your scene with the geog Heightfield in it, now below it in the network add a Heightfield Generate. Then, feed the output of the Heightfield Shader that the Geog Heightfield is plugged into, feed that into the Shader input of the Heightfield Generate. You're connecting a *red* node to the input port of a *green* one here, that's critical. And it has to go into the Shader input, on the right side, not the generic "Input" one on the left. Then, move the heightfield to the center of the area you want to export, then set the size of the heightfield *in meters* (not "number of points") to cover the area you want to export. Basically you're moving this new, second heightfield, and using it as a sort of bounding box for your heightfield export. Then, set the Number of Points to be one of those power-of-two+1 variants I listed above, click Generate, and then you can do the Save As routine on it as before. That *should* get you a heightfield that is *just* the area you wanted to export.

Vector Displacement, any displacement applied to the terrain, can be saved as TER. BUT BUT BUT, you will LOSE overhangs and any non-planar features, AND you have the potential/likelihood of losing resolution/detail. Try it, if you get good results then great, but don't *expect* good results. It is *not* a workflow I would recommend.

Instead, IF your v-disp is planar, i.e. no overhangs, then it's essentially a heightfield already. Export it as an image format, import it into TG, save as TER (or import it into any terrain app that supports standard image formats). In other words if you are actually having to use vdisp, you probably can't accurately reflect the features in a heightfield, because the whole point of vdisp is it gets you non-planar features.

- Oshyan

TheBadger

Thank you for the in depth answer. I am trying this tonight.

About the vector question, Thanks for the extra ideas. Those will help too. good to have options!
It has been eaten.