Isotropix Forums

We keep struggling with trying to export geo that has displacement on it (for animation placement issues).

Displacement shaders will not bake into actual geometry. Displacement deformations do. But there is no simple way to transfer a displacement shader to a displacement deformation.

Is there any way to bake the displacement into actual geo to export? In the past there was an argument that the resulting geometry would be too large for another DCC package to handle, but that should not be a reason not to try. Perhaps throw up a warning if the number of polygons goes beyond several million or something.

Right now there is no way for us to export geometry to animation that even remotely resembles the displaced geo in Clarisse. We have been limited to very laborious processes to try to approximate the surface - all of which take a lot of time and are quite imperfect.

I will also post this as a feature request, but I wanted to hear if others have the same issue (or solutions) here.

Thanks.

+1, let us choose and decide, even if dev thinks the resulting geo will be too heavy, its important we have to option to get it out.

Deformer is the right answer. I'm not sure why your Displacement Deformer and Displacement Shaders produce results very different from each other.

Here is a small trench displaced with a height map in both ways, and their exported OBJ and ABC models


I've attached this scene as well, let me know what you find

Thanks. I will look at that project. But I suspect it is a trivially simple example. I am going to package up a real world example in the next day or so and ask whether you can look at that and see where we might going wrong (or maybe convince you to enable baking displacements).

Thanks again!

Hey,

I think that I already explained why we are not exporting displacements today. Displacements are generates an implicit geometry where each micropolygon is a floating quad made up of 4 vertices that aren't shared across neighbor micropolygons.

To export Displacements, we would need to process the implicit geometry, perform some modelling operation to weld all these vertices etc... In other words we would need to write a "Convert To Polymesh" geometry operator.

Without it, the resulting geometry will be so heavy that even Clarisse wouldn't be able to load it back. The end result would be a soup of floating quads that each defines 4 vertices + normals + uvs + any attributes of the original geo without the connectivity information.

Using our SDK, it is obviously possible to do this conversion but right now it's far from being one of our hottest topic today.

Thanks!

bvz2000 wrote:Thanks. I will look at that project. But I suspect it is a trivially simple example. I am going to package up a real world example in the next day or so and ask whether you can look at that and see where we might going wrong (or maybe convince you to enable baking displacements).

Thanks again!

You asked about some geometry to aid in animation, so often proxy is good enough.

sam wrote:Hey,

I think that I already explained why we are not exporting displacements today. Displacements are generates an implicit geometry where each micropolygon is a floating quad made up of 4 vertices that aren't shared across neighbor micropolygons.

To export Displacements, we would need to process the implicit geometry, perform some modelling operation to weld all these vertices etc... In other words we would need to write a "Convert To Polymesh" geometry operator.

Without it, the resulting geometry will be so heavy that even Clarisse wouldn't be able to load it back. The end result would be a soup of floating quads that each defines 4 vertices + normals + uvs + any attributes of the original geo without the connectivity information.

Using our SDK, it is obviously possible to do this conversion but right now it's far from being one of our hottest topic today.

Thanks!

That makes some sense (I guess I didn't understand the explanation the last time).

sam wrote:Hey,

I think that I already explained why we are not exporting displacements today. Displacements are generates an implicit geometry where each micropolygon is a floating quad made up of 4 vertices that aren't shared across neighbor micropolygons.

To export Displacements, we would need to process the implicit geometry, perform some modelling operation to weld all these vertices etc... In other words we would need to write a "Convert To Polymesh" geometry operator.

Without it, the resulting geometry will be so heavy that even Clarisse wouldn't be able to load it back. The end result would be a soup of floating quads that each defines 4 vertices + normals + uvs + any attributes of the original geo without the connectivity information.

Using our SDK, it is obviously possible to do this conversion but right now it's far from being one of our hottest topic today.

Thanks!

So it sounds like there is a game plan and its possible...just not on your primary list of features to add. As far the weight, that would depend on how many spans we tell it to have for displace, like we currently do, so to say it will be too heavy is misleading and not true correct. Its like saying a zbrush model will be too heavy to load in maya...but on what basis?

If it can be made to export, even without uvs or any additional info other than the raw geo in place, that would be very helpful.

Everything is possible if you have time

Here it would be even heavier than ZBrush models since ZBrush doesn't export floating quads but connected quads. Just take a simple 5 million polymesh, and convert it to 5 million floating quads which would result to 20 million vertices, normals, uvs etc... You'll see how much heavier that gets...

Without the proper geometry processing that would be pointless.

I guess the question is, not that we know its possible, is this something on the roadmap?