Hi Vlado,
We use Vray Displacement in our pipeline quite a lot for Environments and some characters and it would be great if the vrayDisplaceMod had an option to apply the displacement algorithm to the geometry in the viewport so we can use ground objects etc as deflectors in PFlow/fumefx with close to correct geometry (obviously with a few meshsmooths under it!!)
I have tried using the Standard max displacement modifier but as it only takes one uvw channel it is somewhat limited, and our displacement maps often need many uvw channels and vertex colour channels.
Thanks!!
Im curious. Are there other renderers out there that allow their rendertime micropoly displacement to be shown in this fashion?
I dont think so. I think its mostly because Maxs displacement is limited to one UVW channel. If Max’s one was better I wouldnt need to ask this question, but then again it would be good to have it all in one modifier too.
What you are asking for is not impossible. But its not up to a render engine developer to integrate that. Max architecture has to support this natively, in order for vray modifiers to be able to take advantage of it.
Foe example, if max’s geometry handling was like in zbrush, fast, handle millions of triangles in real time, then one could take these already integrated functions and connect them to vray. But unfortinantly none of the functions of that nature exist. And for one to develop such way would mean to change max’s view port architecture.
I think that if you are applying the displacement through a material, you can use a displacement approx. modifier to visualize this displacement in the viewports, but I’m not 100% sure.
Best regards,
Vlado
Yeah, that actually works. Groovy.
Yeah, it actually does, only it is the “Displace mesh” world-space modifier 
I thought I’d seen it once… Only remember to make the WSM modifier “Off in renderer” as otherwise V-Ray will try to displace the viewport mesh preview.
Best regards,
Vlado
Sadly the max displacement approx wsm has some limitation. For example the meshing sometimes misses details badly, and by bad i mean the regular expression of the average max user the “Wtf!!!”
There were times when I wished I could just get the vray displaced mesh into max, and convert it into a proxy for example to speed up the rendering of objects with displacement based on complex, and cpu hungry procedurals. We can always spare several gigs of hdd space for that, but that’s not true for cpus.
Anyway, I really second this. Or maybe just caching of the displacement directly into a proxy like dataset, even if view dependent in some aspects.
Best regards,
A.
this was posted a long time ago…
i d see it being usefull for a couple of everyday’s routine tasks, and now with so much power under the hood on the average workstation i do agree this could be built into vraydisplacement modifier :)…
luckyly for us max users that expression is allready built into our routine!:lol:
quoted for agreement!
Ok, that *seems* to work ok, but only if you have the displacement in the material slot and you are not using any shift in the vraydisp? Is this right? There is still some stuffing around to get it to match properly.
Another thing that came into my mind about having a premade displaced mesh is the idea of caching. Vlado,could you give us some insight on how the displacement works currently? To me it seems like every time a ray hits a specific area the displacement is being calculated for that region, time and time again, everytime a different pass reaches that region. Calculates the displaced faces for a lightcache ray, then unloads, next an irradiance map bucket reaches that region, calculates displacement, unloads faces, during rendering a glossy ray hits it from somewhere, calculates displacement, unloads, minutes later another ray hits it, etc… This way If I’ve got a complex procedural as displacement the meshing of the displacement itself will be a large portion of the rendertime, the procedurals will be evaluated over and over again, whereas this could be done in just one pass, and the result could be dumped into a vrayproxy like container. Just for some interesting numbers on how well the current proxy system can perform, we had a scene where vray had to deal with more than three gigs of proxies, and the render was smooth, predictable, and quite fast. Not to mention that all on budget level hardware, on you average everyday sata hdd without raid.
The displacement is cached as well; V-Ray only destroys cached geometry when the dynamic memory limit is reached - not when it moves on to the next bucket.
If you have a complex procedural though, V-Ray may call it many times for evaluation of the surface normal, which may take more time than the actual raytracing. It is in principle possible to cache the normals too, but at the expense of more RAM and somewhat reduced quality.
Best regards,
Vlado
Ah, thank you for the insight! Does this mean that the dynamic memory limit set in the system rollout will always affect the displacement, regardless of what memory method you’re using? Sounds obvious though, just didn’t thought about this before.
Thank you!
Best regards,
A.
Yes, displacement is always dynamic memory (like VRayFur); the “Default geometry” option is only for regular meshes.
Best regards,
Vlado
So any more thoughts on the VrayDispalceMod preview in viewport funcion Vlado?
It is not impossible, but it will be a quick-and-dirty solution, more similar to the Displace modifier than anything else.
Best regards,
Vlado
If you plan and have the time to add something like this to the vray tool palette, could you add the support of view dependent meshing, eg. based on a picked camera and edge size in generic world units?
Best regards,
A.
That would be great as it would give our animators and FX guys some idea where the ground actually is when it is displaced, dont really need super fine detail.
I recall at Siggraph a couple years back you were working on a separate tool - perhaps that would intergrate vraydisplacement?
Also, maybe a separate viewer could be called up within max (similar to the irmapviewer) that could display the results independantly of that single object alone based upon standalone integration? Then you could rotate that displaced mesh in 3d space.
Either way - it sounds like a lot of hard work.
I guess as a third option as well, the vraydisplacement would have a button that says ‘preview displacement’ then it calls open a vray frame buffer of the selected objects in a neutrally lit setting.
If im understanding correctly, this would not solve the problem of using a vraydisplaced ground for animators to animate to (in viewport) or using it as particle deflectors etc.
You are jsut talking about quick vraydiplacemnt previews, yes?