Water Displacement issue

[Pavlov]

Hi larsgehrt,
Personally, I wouldn't choose this workflow to achieve this image, but that's not the subject of the post. That being said, as you can see, Octane Render's displacement nodes work well when used properly. I'm attaching the file so you can take a look and compare it with yours, in order to learn some useful tricks as well as the Kernel settings (Perhaps the use of the ray epsilon function was overlooked). I also add that it is not feasible to achieve a decent displacement using a low-resolution 8-bit JPG image. Additionally, when using a grayscale image (at least 16-bit depth and of adequate resolution), it would be correct to use the grayscale node instead of RGB. However, one thing should be mentioned: the interpenetration of the 'water' plane and the stones should be avoided. I didn't perform any boolean operations, precisely to demonstrate that the displacement works well anyway. I hope it's helpful.
Regards
Paride

Hi Paride, can you kindly post a screenshot of the nodeflow and Kernel settings, for those who do not use Max ?

Without seeing your setup - which may shed some light for sure - what i see is that texture displacment shows issues on large scenes, not small ones.
If i see a large portion of sea (i.e. an aerial view) i must use a large projection for the map, such as 100m x 100m or more, in order to avoid tiling.
In this case, even with 8K maps, intersections show an edge no matter what you do on Kernel and ray epsilon - or any other setting, including material's.
The only thing affecting the edge (making it more or less visible) are:
- projection size of the displacement map - smaller projection produces less edge.
- displacement resolution you set in Texture displacement node - higher resolution prodices less edge.
- Image map size and depth - large images at 16 or 32 bit produce less edge.

Anyway, i found no way to solve the issue completely. In images photoshop can help, in movies it's an issue.

Best
Paolo

[Pavlov]

Here is an example of broken borders.
One pic has displacement and the other does not, in order to show displacement is the responsible of the back line around the reef.

Sea is a flat plane crossing the terrain.
Project is larger than visible one.
I exclude the possibility to boolean sea with terrain geo, it would just be impossible since it's a 100km x 100 km area on red sea with hundred small islands - and anyway it would not be a reasonable workflow in absolute terms.
The piece i'm showing is 10-15km size.

Displacement is an Octane noise baked through an Image node, set in Float mode and at 10000 pixel resolution. Texture displacement is set at 8K.
Rising these values makes no difference, and tweaking any parameter in PT Kernel (Ray Epsilon but also other ones) does not affect it too.

Vertex displacement would need an unreasonable amount of subdivision so not a way for this kind of scene.

I ask if your technique works on a similar scenario , where i need detailed waves on a very large surface (as said, i do not have Octane for Max so i cannot check myself).

Best
Paolo

[Lewis]

Agreed with above, we need it to work on "regular displacement" not one with subdivisions (vertex) 'coz then to get needed detail level model becomes millions and millions of polygons = wasted VRAM and slowness.

[frankmci]

I had this issue on a project several years ago. As I recall, the problem is not specifically with displacement, but with specular/transparent materials intersecting non-specular, non-transparent materials. It is fundamentally a ray epsilon issue, but it is greatly exaggerated when using displaced geometry. I posted some examples about it a few years ago on this forum. I'll try to track them down.

There is always a small gap rendered when a transparent material intersects an opaque material, in the region where the space between the two surfaces is less than the ray epsilon. In this region, rays will pass right through the opaque surface, revealing whatever is behind it. Normally that gap is small enough that it gets hidden in the sampling process, but it is still there if rendered super close-up.

I'm guessing that there is some rounding/approximation involved when calculating the location of a displaced surface. This greatly exaggerates the usually tiny ray epsilon "transparency" zone at the intersection of the otherwise opaque surface. By "greatly", I mean by several orders of magnitude; it's so exaggerated that it's difficult to work around. It seems so exaggerated that it may well be an oversight. I think the developer-side solution is to figure out what step in the rendering of a displaced surface is causing that extreme reduction in ray epsilon accuracy. It feels like it might be basic number of digits of floating point accuracy buried somewhere in a core library that no dev has looked at in years. I wouldn't be surprised if compensating for it can potentially cause a significant render hit, but it would be nice to expose that parameter to the user for optional tweaking when necessary.

[paride4331]

Hi,
I'm just making some tests regarding this issue you reported. I will make a report as soon as possible.
Regards
Paride

[frankmci]

I found that old post I mentioned. It's got an example of the phenomenon with non-displaced, transparent surfaces. In normal situations, it's not really an issue if your scene is scaled appropriately. It's only with displaced surfaces that the ray epsilon accuracy becomes such a problem.

viewtopic.php?f=24&t=80814&p=420390&hil ... on#p420390

[Pavlov]

Hi all,

i want to precisate that the issue i show above is *not* tied to ray epsilon.
I tried extreme values - from 0.0001mm to 1 m and it does not change, not even by a small amount.

My bet is that the voxel that is intersecting the solid mesh is not read correctly and it's completely considred "under" the solid mesh.
In fact, the only thing that changes the amount of the black line is the displacement texture resolution + projection size.

Hope it helps,
Paolo

[Lewis]

Pavlov, maybe you should export that sea scene to ORBX so anyone can use/open it fine to see the issue, especially would be easier for DEVs to check in standalone Octane.

[paride4331]

Hi guys, I've run some tests, and it seems that the issue is simply the correct use of ray epsilon. Obviously, using the correct unit of measurement is essential. Let me know if the problem you're encountering is of a different nature, but I don't see any other issues. The scene is created with an appropriate map and simple texture displacement, not vertex displacement.
Regards
Paride

[Lewis]

Ok so now with your Ray epsilon set to 0.1 can you move your camera 100m away and then see is there problems in scene ? It has to be large scale scene not such easy close up shoot.
Then main problem is that you can't have tiny ray epsilon for large scale scene and then if you increase ray epsilon there is more black edges...