I am exporting a fluid vat with color on it that I am planning on using in the shader, but I am running into an issue that is caused by the polyreduction that in happening within the vat rop. See the attached images, for this test, I am specifically painting an area of this mesh, but once it goes through the vat rop the color gets messed up. Also, my mesh is only 2000 prims, so there is no need for the vat rop to do a polyreduce or a remesh.

For times like these, I think it would be nice to turn off the internal remeshing in the vat rop.

Any ideas on how to turn it off currently?

thanks

If your point count is consistent, you could use the soft export instead.
Otherwise, if you set your target prim count to 2000 and your mesh has that many polys on every frame, then the polyreduce won't change the topology of the mesh and the colour should stay consistent too.

Hi Mike, thanks for replying.

I have 2000 prims consistantly (this is just a test sphere) and I've set the target prim count to 10000 on the vat rop but it is still producing the reduced/retopo'd poly mesh. Are you sure it bypasses the reduce? Which, in the fluid portion of the vat rop isn't a polyreduce, but a setup that ends up copying a 3 division circle to the points. Btw, I am using the Labs Vat rop in h18.0.287

Also, It would be great to control this polyreduce because this will eventually go onto a changing fluid surface. I'll need to paint the color and it is hard to know exactly where I painting if it is going to do a reduce when going into the vat rop. I guess if the above method works, I can control it by doing my own reduce then painting after, but I don't think the above method is working.

-Jason

My bad. I was testing with a mesh that had a fixed edge length for all poly's so the polyreduce didn't do anything. It doesn't bypass the polyreduce, but if the polyreduce is set to keep the same amount of polys as the input, it will either leave the mesh unchanged or only make changes in certain areas. By the way, setting the target prim count to a value larger than your input will create unexpected results in your final output because that number is used in multiple places internally.

I think you're looking at a different part of the network. The polyreduce happens in objects/TEXTURE/polyreduce_make_sure_the_point_count_is_consistent. Copying 3 division circles is used to create the cloud of triangles needed for the mesh that you import into the game engine.

How do you want to control the polyreduce? That's what the target prim count parameter is for. The reason for using it is most fluid meshes are very dense and we need to reduce to meet the constraints of the texture.

You could also do your own polyreduce with the same settings, then your painting and set the target prim count to the same number as you used on your own polyreduce.

I see, yes, I was looking at the wrong area for the polyreduce. But, if I look in the vat rop under /objects/debug/ isn't that showing the reassembling of the mesh with the newly generated cloud of triangles? That looks incorrect and the colors are in the wrong place.

I am thinking, maybe it isn't a problem with the polyreduce, but the reassembling of the mesh? I also might be missing something.

If the mesh is changed by the polyreduce and then the original Cd is transferred with the attribtransfer afterwards, then it could look different. I think this is more pronounced with your example because you've colored a very small area with limited points. The color is in the right area but because of a different topology the blending of Cd between vertices will look different.

I think when you start using a fluid mesh you'll run into a similar problem because the fluid mesh will be changing every frame. If you intend on painting an area, you're going to have to transfer that colour onto the fluid mesh because a paint operation will be based on point ID.

Hi Mike,

In this example, the mesh shouldn't be changed, yet it is. The incoming mesh has 2000 prims and I've set the vat rop to target polycount=2000. If I look inside objects/TEXTURE/polyreduce_make_sure_the_point_count_is_consistent, the polyreduce isn't doing anything to the mesh and everything looks correct. But, if I look in /objects/debug/ at the reassembled mesh, it is put back together incorrectly with the polys misshapen. In this case, should it be reassembled back as is since the polyreduce isn't doing anything to it?

There might be some precision loss based on the texture and the scale of the object but it shouldn't be that dissimilar to the original. How misshapen is it?

You can see the misshapen polys in the attached images, this is 2000 polys and target polycount=2000.

Can you share your test file?

Sure, here you go. Hopefully it is just something I'm missing…

Can you try putting down a fresh ROP and setting it up?

I ran the setup on my side and the output is identical to the input.