VrayDispalcementMod - 3d Mapping + Ortho Camera

[joseph_stone]

There is a difference between rendering displacement with an orthographic viewport created from an orthographic camera, in comparison to rendering an orthographic view created from a perspective camera.

We are using latest Vray 7.1 and Max 2025.

I have tried to explain this with a video: https://www.dropbox.com/scl/fi/wli73...bd3h62vb9&dl=0

• Render with orthographic camera, object has a displacement map.
• Swap to an orthographic viewport, the displacement is still looking broken.
• Render with perspective camera, displacement looks correct.
• Swap to Orthographic viewport, the displacement still looks correct.Seems to be a bug with the orthographic camera rendering displacement incorrectly.
• But the orthographic view created from the perspective camera works.

We are using '3D Mapping' in the video since we need continuous mapping over complex surfaces..

Any ideas? Our pipeline has to use an orthographic camera since its an isometric game We would really like to use displacement on our assets. But this is really limiting our ability to do so..

Our example scene can be found here (since it exceeds the 10mb limit): https://www.dropbox.com/scl/fi/xamws...l5ooyhze7&dl=0

Any help / suggestions would be great.

[hermit.crab]

It's an old issue concerning Standard Cameras and their Orthographic projection. You can work around it by using a perspective (Standard) camera and turning "Orthographic" from the Render Settings (V-Ray>Camera>Type). The downside is that you won't have a viewport preview.

An alternative solution is baking the VRayDisplacement to .vrmesh and re-importing it as a VRayProxy. It's done through MaxScript:

$.modifiers[1],write_vrmesh = "path/to/mesh.vrmesh"

$ is the selected object, and [n] is the position in the modifiers stack.

After you run the line in the Script Listener, click Render until the .vrmesh is exported, after which you stop the process.

Make sure you return the property to an empty string after that, otherwise it'll export it every time you render:

$.modifers[1].write_vrmesh = ""

[joseph_stone]

The issue would be we are using displacement to drive some stylised foliage on trees, as such we would need many versions of the VrProxy, is it an issue that will be resolved in future? As you say the alternative of forcing the camera to ortho in the Vray settings is we get no preview of what we see in the scene

[hermit.crab]

The thing is, it's expected. The Free Camera's Ortho is a "fake" one, the displacement is actually calculated from the non-ortho point of view of the same camera. If you disable it, you'll see that the box is very tiny (because of the huge FOV) and works with a handful of pixels, hence the low-quality result. If you keep the ortho camera as it is and radically (tried 20k +) increase the image's resolution, you'll notice better, but not the same as the ortho settings override results.

[joseph_stone]

So one work around ive tried is using a Vray cam with a very narrow (1 degree) FOV and pulling it right out.. this gives us very little perspective distortion on our shot, and then i can enable the "Orthgraphic" override in the render settings as you suggested. Do you think that narrow FOV will cause us issues in future as it seems to work ok from my simple tests?

That way we can still preview the shot in the viewport with narrow perspective and then render for accurate ortho.

[hermit.crab]

Good idea. One thing that comes to mind is the dependency between FOV, Exposure, and Focus distance described here. Just a heads up that it may affect exposure. Otherwise, if you stumble upon something, write again.

[joseph_stone]

Ah great, we dont really use exposer, but cant certainly test it.