I have tried many times to use displacement, but I end up with errors and bugs a lot.
Game engines use displacement all the time, and they are super fast (if not they would not have used them) so they must do something on the graphiccard, but Rhino is super slow, and spends a lot of time on recalculating.
Please test this in the file:
Rotate the tire and see that it recalculates.
Copy paste and see that it recalculates many times… I had to hit ‘esc’ to make it stop.
Move the tire and it has to recalculate.
Now undo and see that it has to recalculate twice again.
IMO neither move nor rotate should cause a recalculation.
And it should be superfast and at a much better resolution IMO.
Note that the tire has a custom meshing to control the displacement better.
@Normand could be related, I’ll leave that to Andy to decide. In any case the bug I reported is not part of the fix, since a move and rotate causes a recalculation of the displacement.
No, I don’t, other than the games I have played
I know that basically all GPU’s can do both adaptive tessellation and displacement calculations these days, so that’s why I wondered.
This is a quick reference I found, old but might be interesting.
OK I have done some more testing and I didn’t know that PBR materials supported displacement directly. That is both faster and better looking IF a custom meshing is sat for the object.
But you can’t extract that PBR render mesh, cool if you could. Please add that if possible.
The displacement command doesn’t weld the mesh result, making it look more jaggy:
I used a very dense custom mesh for the sphere.
Yes, and only if you insanely increase the density of your mesh which totaly defeats the purpose of gpu based displacement where you do not have to add such a dense mesh to the doc, unless to you need it (eg. for export & 3d printing).
The whole PBR based displacement has so much potential compared to the old Displacement modifier feature, it is however still uncontrolable in the WIP. Once you turn on reflections of the PBR you’ll see that Rhino 8 shows the wrong normals (from the undisplaced mesh). If you copy the “Disp. Map” to “Bump/Normal” to try to fix the reflection problem as suggested here, the display framerate drops to a crawl, even with a single sphere mesh using a resolution of 256x1024 faces and the reflections are still wrong (see this item on the bugtracker)
I’ve reported this this multiple times, unfortunately without success.
Once you try to use PBR displacement in a slightly serious manner, you’ll notice that you can not control the displacement distance as you’re probably used to. It always displaces in both directions which halves the grayscale range of the image. I’ve reported that here
I hope that when Rhino 8 goes out, there will be a better support of PBR based displacement, including Breps and Subd displacement using the rendermesh.
@Holo fyi displacement no longer recalculates in latest internal build on moves, so I changed the YT title and added this new one: RH-81132 Displacement recalculates when rotating an object
Good, can you check if it recalculates on extractrendermesh? It did last time I checked, and some times it recalculates even if nothing was done.
I also wish it was possible to extract the rendermesh of a PBR displaced material, but that is maybe done on the GPU so it isn’t available to extract? PBR displacement is vastly faster so it would be cool if it worked. A bit niche though, so I understand if it isn’t of high priority.
