Intersection Priority / Coplanar Geometry

[Jim Meston]

I have an ice cream model that is coated in a semi transparent gel, at some point in the modelling process the ice cream bar is booleaned out of the gel so I end up with coplanar surfaces. Ice cream surface and gel inner surface touching it.

What is the best way to deal with this to get predictable results.
Currently there is some fairly obvious zfighting with the coplanar polys.

Overlap?
Micro air gap?
Coplanar with a magic setting?

[david.anastacio]

Hi Jim Meston,

Secondary Ray Bias:



Best,
David.

[Jim Meston]

It seems that with coplanar polys, it tries to render as if there is an overlap, but produces shading errors.
What ever I do with secondary ray bias, I am just getting a large variety of outcomes with no idea which one is "Correct".

You can see the dilemma here.

[Jim Meston]

And with srb

[david.anastacio]

If Secondary ray Bias is not helping, then you need to modify the geometry with a small offset. If they are completely perfectly co-planar you should introduce a small offset in the geometry after the boolean is performed.

[Jim Meston]

If you look at the one with the offset and the one with the overlap I am not sure which is "correct".
So which direction the offset should be, to overlap or to have a tiny gap.

I am guessing if it is a solid, such as glass then it would be an gap as that is what would happen in reality.
But if it was a liquid or a gel, then the interface would be different. This in mind I am not sure how vray calculates its exit/ entry IOR at the interface. I am guessing if it is touching(overlapping) then that interface is rendered as if it was perfectly aligned, as in the situation of liquid flush to a surface.

[Jim Meston]

I am an idiot. Got stuck in the mental weeds for a while.

I was doing sdf intersections (essentially Boolean subtract) etc and the output geo wasn't matching up so some of it was overlappng and some of it was making a gap, all very shallow angles and very small amounts.
Just doing straight booleans seems to have fixed it.

Good to have learnt about SRB though.

Thanks David. You are a star!

[david.anastacio]

I am an idiot. Got stuck in the mental weeds for a while.

I was doing sdf intersections (essentially Boolean subtract) etc and the output geo wasn't matching up so some of it was overlappng and some of it was making a gap, all very shallow angles and very small amounts.
Just doing straight booleans seems to have fixed it.

Good to have learnt about SRB though.

Thanks David. You are a star!

No problem, happy to help.
Regarding your previous question, yes, liquids should intersect the glass/container, and glass should have a bit of "air" between it and the next object.

best,
David.

[Jim Meston]

Hmmm further it seems that there is some odd stuff going on ...

If I split out the groups and then merge them, everything renders differently. This is with exactly coplanar polys and no secondary ray bias. How odd. And what a rabbit hole.

With regards secondary ray bias I would imagine that if you put a positive number it gives you that "air gap" and if you put a negative number it kind of "overlaps" or a similar idea.

By default the slider doesnt go below zero, I wonder if that is an oversight, I only ask because the only way I can get anything reasonable is with a negative secondary ray bias. But I have no idea if it is accurate as I am lookign at a thin film of gel and have no real way to judge what would happen in reality.

[david.anastacio]

Not sure what could be causing that issue without test the scene. But one thing I can see is that you are rendering polygons and bgeo files. This should both be avoided, you should be rendering packed geometry and use alembic files.
V-Ray supports alembic files not bgeo, using bgeo files you are causing you geometry to be saved later on in the render scenes (vrscenes) and if you use alembic files only a link to that files is saved in the render scene.
And regarding polygons vs packed geo, there are several render discrepancies between rendering packed vs unpacked, as you model is seen a single object when unpacked and separate objects when packed, also renders tend to go faster when using packed geometry.
Using alembics is the way to go, make sure you save them with the path attribute if you are saving them from Houdini, when they come from another software, your path will be the different objects, and instead of using groups, use the path attribute to access/split/blast geometry.


Make sure to use "Build Hierarchy from Attribute" option in the ROP Alembic node:

You will have your geometry packed and accessible by the path attribute:


And be careful using the file node, the default is "load all geometry" and I see people many times forgetting to change it to "Packed Disk Primitives" and so loading their models as polygons (specially critical when loading VDBs):


Best,
David.

[Jim Meston]

Well that's great info and makes sense. I would have thought just a pack sop at the end of the network would work, but I guess it would still need to embed the geo as it cant reference it on disk. Cool.

So would you recommend saving EVERYTHING out to alembic so the vrscene is better optimised? Or in some cases would you just output polys direct from a scene if it was low resource intensity?

I will check the docs on packed prims to go over the info, but is there any specific other docs or commentary on this that I can look at to see render discrepencies.

Thanks for going to that effort. Much appreciated. I always love to see a few screen shots

[Jim Meston]

Also does it matter how you create the path attrib or is just for splitting?
Like this?

[david.anastacio]

I would have thought just a pack sop at the end of the network would work, but I guess it would still need to embed the geo as it cant reference it on disk.

That is common misconception, using a pack SOP doesn't help in regards to geometry ending up in the vrscene, the moment you unpack/load all geometry you will end up with the data in the vrscene. This is not a V-Ray issue, this is just Houdini, you will have the same behavior in mantra and the IFD files.

So would you recommend saving EVERYTHING out to alembic so the vrscene is better optimized? Or in some cases would you just output polys direct from a scene if it was low resource intensity?

Yes, totally. Any changes in terms of model we cache it out to an alembic and read it back in. Things to be careful still are:
- Points for the instance node, this always have to be unpacked so will always be written to the vrscene, so be careful with animated points.
- /img context images, these also end up in the vrscenes.
- VDBs, make sure to always load as "Packed disk Primitives"
- materials and lights always get written into the vrscene, but that's totally ok and expected.


As I mentioned before, non of this is exclusive to V-Ray, this is all just how Houdini operates and how we are allowed to render in the network and create render files. The rule is, anything you read and modify needs to go somewhere, can't stay "live" in your hip file.

Also does it matter how you create the path attrib or is just for splitting?
Like this?

Go with the "attribute create", and you can even make "hierarchy" with it, by using "/". This a simple example and you can automate this and create paths from the names if you want or paths by connected geo and so on.

Just a simple example to get you going with paths.
Split and create paths for the parts you want, notice that the 3 different parts are grouped under "flippy":

Attribute create setup:

Writing the alembic file and reading it back again:


Best,
David.

[Jim Meston]

That is clear. It is just a prim string attribute.

So for the sake of total clarity, paths are used in Vray somehow? Or is it just a convenient way to split things up for animation. If it's the latter then why not bring in groups the alembic import?

[EDIT] ahh "build hierarchy from attribute" gives a clue I imagine. I am guessing this is useful for tree like parenting dependencies.

[david.anastacio]

The path represents the hierarchy in alembics.
If you bring an alembic file created in another software eg:3dsMax/Maya you will see the different objects and hierarchy represent in the alembic path (represented like a hierarchical tree).