bake displacement to vrayproxy

[super gnu]

I know this has been asked for several times, but it keeps cropping up as a solution to stuff id like to do. Ive just spent the last hour waiting for a sphere to subdivide sufficiently to try and add a max displace modifier and get something reasonable out, since i need an actual mesh.

its extremely painful.

since i can get a very nice result with vraydisplacement mod, and since (for gpu at least) the entire mesh is precomputed before sending to gpu.. seems it should be "trivial" to export a mesh to disc.. and it seems vrayproxy would be a good format.

can we have it please?

p.s. ideally by next week

[^Lele^]

Umh, i agree in principle, but wouldn't this be problematic for anything which subdivides in raster (screen) space (say, when you set the edge length in pixels)?
If a camera tracked in a mesh so baked, as it got closer the proxy'd get coarser.
Likely, if one subsdivided a big mesh (say, a water plane), that'd be done with the camera frustum in mind, and the displacement would show the differences bewteen in-frustum and outside (V-Ray biases the subdivision to minimise off-screen data), on top of close to, and far from, the lens.
So, for raster-based stuff, i'd say it's a risky one in terms of re-usability.

It'd probably just work perfectly fine for world-space subdivision, and fixed subdivision (either specifying the edge length in scene units, or manually managing the amount of subdivisions), however.

And maybe devs have ideas i can't begin to imagine to get the issue with raster subdivision sorted.

[super gnu]

yeah i agree it would be tricky in that sense, i didnt think about the view-dependent aspect... how does the gpu deal with it? i guess just making a new mesh each frame.

a simple solution would just be the option to export whatever mesh the gpu engine uses at whatever frame you are on.. if view dependent is enabled, yeah you get a mesh that works only from that camera view.. if view dependent is disabled, you get a mesh that works from multiple angles. - although having said that, i dont know how vray deals with occluded geometry during displacement? would the back of an object be displaced if not seen?

obviously it wouldnt be as flexible as a proper rendertime displacement, but it would be useful in specific cases and (i imagine) a damn sight less painful than trying to do a detailed displace with the max modifier.

anyway id be happy with a "use at your own risk" maxscript command...

[^Lele^]

Indeed, each rendered frame is a separate event, and so each time the camera and mesh are re-evaluated.

Yeah, displacement happens also for parts not directly visible (it'd be trouble otherwise, in a few cases.), however for some things there is a bias to lower segmentation for out-of-frustum stuff (imagine an ocean plane.).
Regardless, i'd think if you need an actual mesh, you can, and probably should for the sake of topology, do with fixed-subdivisions, or world-space edge lengths, so perhaps that becomes less of an issue overall.
Export to proxy could be allowed only for said subdivision types, and the problem with view-dependancy would be gone.
It's also probably going to be much slower to load from disk than to compute across multiple cores on the fly before the render starts, in most cases (unless one's using pci4 M2 drives), but so long as it's clear it isn't an alternative to *rendering* displacements, that shouldn't be an issue in the end.

I still +1 this completely, and let the devs tell us it's a no-no. ^^

[HenrikBC]

+1 from me too.

I don't imagine this to replace all needs for dynamic displacement that is calculated for each frame, but in certain cases it would be very nice to be able to skip that computational step for each frame.
And while I'm dreaming, maybe a feature where we can let the output mesh be an assembled mesh from every Nth frame. Say frame 0,50,100 in a shot where the camera moves slowly sideways. Not sure if an extra parameter is needed to make sure there is enough "extra" resolution around the camera frustum - say in case the camera has a noise track that makes it shake a bit up and down.