VDISP map challenge

[TheBadger]

I have only seen people making their terrains in other soft (mud, z, WM, ect) then going to unity or UDk.

[Matt]

Thanks for the feedback, all of you.

I will work on improvements to the Micro Exporter. The first priority is not having the disconnected triangles, i.e. vertex merging.

1 - The mesh is 'just' a disconnected triangle soap, and so far I never find a way to clean it up. Polycount need to be high for good result, and merging such big file takes ages.
2 - To have a good export (close to what we have in Terragen render), the polycount need to be insane. Dont expect any good result under 8-10M of triangles for middle piece of terrain, my best one was about 30M, file size 8gb. Not many software can deal with this kind of data, and .obj is probably the slower one, or at least the less compressed possible format.

From my pov, enhancing the micro-exporter would be awesome.

1 - a merge vertex option, of course the faster the better.
2 - a decimation/poly cruncher reduction tool that will light up the resulting mesh without loosing too much detail. (very optionnal)

The number 1 is very important. If the mesh is 'clean' (no holes or disconnected vertices), we can eventuelly use external decimation tool (atangeo balancer is very good) to reduce the data. Then it's quite easy to auto-create a clean low res version in zbrush (with uv's), and eventuelly bake the details from the hires model as normal, displacement, or vector map.

Yeah this is the problem I've encountered too. Vertex merging will probably reduce those sizes to about 1/3. As you pointed out, the merge step can take ages in other packages, and it's a necessary first step before you can do other good stuff like decimation / poly-count reduction, compute vertex normals etc. So, I hope I will be able compute the vertex merge reasonably quickly in TG before the file is written to disk. A certain amount of decimation in TG might be possible too, to shave some more off those file sizes before you send them to another package.

As for textures, that's a very tough one. What about storing the data as vertex map ?

If you use a format like .abc (alembic), it's possible to store multiple vertex data channel (called custom channel). So it should be possible to store diffuse, spec, gloss by vertex. It's not as clean as bitmap texture, but it doesn't require uv's, and the expected tessellation been insane anyway, I think the result might be very great.

We will investigate per-vertex colour, spec etc. But if you have to decimate your model to work with it, you'll also lose detail in those channels. Still, it will be good for the cases where you can work with the resolution.

Any 3d package with a good .abc loader can then use this data to reshade the model, either by using the embedded colors, or by remapping them with custom gradients. Without saying .abc 'otawaga' compression can help a lot with huge data.

Are these packages that many users will have, or is this furthering Badger's problem of having to go through too many different pieces of software to get where he wants, or does this work with the major modeling/sculpting apps? What is 'otawaga' compression?

Thanks,

Matt

[paq]

Hi Matt,

Great to hear about the possible micro-exporter improvements !
You are right about the decimation, it will also reduce vertex channel resolution.
Maybe we can use a lowres/hires backing strategy later on in an external 3d software.

.abc is starting to be common in many package, but it's still a young format.
There is a list of software's 'ready' for it on the alembic wiki :

http://en.wikipedia.org/wiki/Alembic_%28Computer_Graphics%29
I've read Blender is on his way, but I haven't investigate that much.

My only experience with custom channels are in Clarisse (works fine) and Modo (doesn't work).
Realflow use this format (+ channels) to transfer liquid simulation data into the mesh sequence (velocity, vorticity, etc ...)

HDF5 and Ogawa (sorry for the Otawaga mistake) are 2 'compression' options often avaible in .abc exporter.
I call it 'compression', but I don't really know what's behind the scene.

HDF5 is supposed to be depreciated, and 'we' should to use Ogawa now. Loading time are supposed to be much faster (up to x25),
and file sizer smaller (5-15%). But I don't know if this number can be applied for 'single' mesh export (.abc first purpose is animation sequence transfer using
a point cache system)

Maybe you should also consider or even prefer .fbx

.fbx works for vertex data transfer (but I don't know if multiple channels are supported), it's for example the way to export/import vertex paint data from zbrush into other software's.
Mudbox can load .abc (with a external converter), but not zbrush ... and this 2 sculpting softwares could be a target of choice for terragen terrain export, as they are supposed to deal with high polycount models.

[TheBadger]

... and this 2 sculpting softwares could be a target of choice for terragen terrain export, as they are supposed to deal with high polycount models.

MudBox does not like tris. It can deal with them simply being there (for painting) but sculpting with tris in mudbox, you should just give up now 

[paq]

Hi TheBadger,

Well I'm not very familiar with Mudbox, but M2014 seems to come with auto retopology tool.
https://www.youtube.com/watch?v=cpVCvgvzR_I

Somehow it would be the same workflow than working with a 3d scan.
You can auto-retopo the mesh (terrain) into a 'low' quad mesh, and reproject the details as true geometry (surface subdivision), displacement, vector displacement or normal map.

Do you think there is something wrong with this method ?

[TheBadger]

Do you think there is something wrong with this method ?

Yes, that is true. But running retopo on a TG object? At scale to boot? I am not even sure it could work if the verts are disconnected, never mind the huge size. I have tried to open a TG object in Mud, it did not show up. I have seen people retopo dense scans like you say, and that looked cool to me. But I have not gotten a giant TG object to work.

Well, like with everything else, I guess it depends on your preferred or available soft. Z-brush users can skip all this as Chris does. But it wont work for me.

I maintain that the best solution is for TG to produce Vector displacement maps. As far as sculpting goes, then this makes it possible for TG/Mud users, and faster and simpler for Z users.

Its very important to get 1:1 results!

What makes TG so great in the workflows I am after, is that I have not found a faster way to create real scale terrain. With DEM and heightfeilds plus the standard TG tools, you can get a pretty awesome terrain to take to sculpt very specific features on. And then from there, go back to TG or any place else.

Unless someone can tell me about a limitation of vectors that I have not seen yet? Probably there is one and its not really "perfect". But I just don't know what that is yet.

[Matt]

I have tried to open a TG object in Mud, it did not show up. I have seen people retopo dense scans like you say, and that looked cool to me. But I have not gotten a giant TG object to work.

Have you got it to work with low-detail objects from TG? Something that is just a few Mb? So we can identify whether the problem is the file size or something else.

Remember that micro exports are in world space, so you need to recenter your view on the object (I'm not familiar with Mudbox to know whether that's automatic or not).

I maintain that the best solution is for TG to produce Vector displacement maps. As far as sculpting goes, then this makes it possible for TG/Mud users, and faster and simpler for Z users.
...
Unless someone can tell me about a limitation of vectors that I have not seen yet? Probably there is one and its not really "perfect". But I just don't know what that is yet.

Terragen's renderer is built on the idea of rendering terrains using vector displacement of a flat surface such as a plane (or large smooth object like the planet). We should be able to export a rasterised map of this displacement, along with a plane (or a low-res mesh of a section of the planet). We should also be able to export a low-res mesh of the terrain with UV coordinates and high-res vector displacement maps. Colour maps too, etc.

I plan to add a feature to do this in future. It could be an extension of the Micro Exporter, but it might be better as a new dialog that helps you through the process.

As to limitations... from my point of view, what might be a problem is the resolution of the maps. If you have a displacement that really stretches some parts of the terrain, then the textures will need to be much higher resolution in these areas. This stretching happens very often in TG scenes because the renderer adaptively subdivides the stretched surfaces and keeps producing detail because the shaders are procedural. The renderer encourages you to do things which might be difficult to transfer with simple meshes and vector displacements.

I might be exaggerating the importance of that problem. It might be something that artists are used to dealing with. But I know from analysing Micro Exporter exports that people have sent me over the years that Terragen setups can produce some insanely twisted, overlapping surfaces, often without the artist realising that's what they've done. This isn't helped by the fact that we can download other people's clip files, not always knowing how they work but admiring the images they produce, then combine them in new and interesting ways. That's works in Terragen, the renderer just eats up the displacements and renders whatever you throw it at, but exporting those kinds of assets can be difficult if you need a 1:1 round trip.

Anyway, in many cases this will work well, but there are some limitations I'm aware of.

Matt

[TheBadger]

Have you got it to work with low-detail objects from TG? Something that is just a few Mb? So we can identify whether the problem is the file size or something else.

Remember that micro exports are in world space, so you need to recenter your view on the object (I'm not familiar with Mudbox to know whether that's automatic or not).

I will retry everything tonight so it is fresh in my mind, and I can answer any specific questions fully and correctly. Is there anything else you would like me to do so you know the result?

But I am pretty sure the problem is not far clipping or camera position. Though that can be an issue, I just dont think that it was the issue with TG models. But since you asked now I feel not so confident I will make sure for the sake of good info here

[Matt]

Thanks for the extra info, Paq.

The Micro Exporter can write to FBX already, in case you didn't know. It would be great if vertex colour data could be standardised in one of these formats, then I would know what to support. PLY is another format that allows per vertex data in arbitrary channels.

Alembic seems like a good bet. We already have intentions to support this for full scene transfer to and from Terragen in future.

Matt

[paq]

Hi Matt,

That would be awesome 

Here's a little test of micro exporter in Clarisse, probably the only software I know that can eat this kind of insane geometry, with full interaction in the viewport.
Actually the main problem is not the polycount, but the loading time
Textures was just done with 2 or 3 occlusion shader ... I can't imagine how cool it will be with Terragen textures.

(I didn't know for the .fbx, thanks)

[Matt]

Cool. Was this an FBX or OBJ? How long did it take to load into Clarisse? Does it look like that in realtime, and how fast is it to navigate?

Matt

[Matt]

Hey Ulco, sorry we have hijacked your thread!

[paq]

Hi Matt,

It was using the .obj format.

Loading time is about 360 sec, + an other 350 sec to build the acceleration structure. (.obj size is 6.8Gb) ... but Clairsse give the hand back after the initial loading.
The image posted is a 'render' image, takes +- 8 min to render on a 6 cores cpu, with brute gi and a volumetric fog for the atmosphere (gi in desactivated on volume for this scene).

Scene interaction is very responsive ... you can manipulate the object in the 3d view with ease (gray shade mode, but it's still the render engine in fact)
You can duplicate the mesh like it's a simple cube.

I would probably never build a scene with a mesh like that, but importing multiple pieces of terrain of 4-8 gb is very doable on a low-end workstation .

[TheBadger]

As to limitations... from my point of view, what might be a problem is the resolution of the maps. If you have a displacement that really stretches some parts of the terrain, then the textures will need to be much higher resolution in these areas. This stretching happens very often in TG

If I can get the TG terrain into a vector map (by any means) than I can use it as a vector stencil. Once as a stencil I can retopo the result and go on like that making more and more complex vector stencils. Then at at end, Make a plane to project to, and make a vector to go back to TG with. In this way, stretching may be addressed down the pipe.

I will try to do as paq suggested with retopo-ing the TG .OBJ now. I am waiting for the object to render out. I think It will not work, but I cant remember exactly why. But maybe It will will if I had been doing something wrong.

Paq's argument about retopoing scans is a pretty good argument. Not exactly sure why it would not be the same with a TG obj... I am still guessing verts and scale, but...

[paq]

Hi TheBadger,

Well I was talking about retopology, but as a matter of fact I don't think I will even try that in zbrush if the mesh is too big (over 3-4M of tri's)
I will just use the zbrush dynamesh tool, that basically voxelize and re-mesh the object. It's a much faster than a retopo procedure, less clean (there will be lots of triangles and quads), but good enough
for sculpting.

For mudbox, as Matt said, the input mesh should probably more in the mid-res area, maybe don't exceed 1 or 2M of triangles at first ... disconnected triangles might be a problem for the retopo tool.

My advice about vector displacement is that it works well for ... displacement, but mixing displacement and bitmap texture is always a little bit cheesy.
It's like height map, high slope in the elevation = less definition.  So for the color textures (diff, gloss, etc), using low-res model as 'origin', like Matt said, is probably a good idea (as opposed to 'from a plane'). But uv's from this mesh need also a little bit of care, like relaxing or auto-pelting to get an uniform texture result ... sounds very very tricky to me.

That's said, a 'one click' vector displace export from Terragen can be handy as it is, just compute from the orignal plane(t). It could be used to create really impressive brushes for Z-box !