DERBENDER Whaaat ? I haven’t been following this thread enough
Both of those were patches that were sitting in the tracker for months (since Mai does not have time for Cycles work right now). What happened is that Brecht picked them up, made a few changes, and committed them to master.
I can’t really give any results on my end since the Win64 buildbot is failing right now (no builds with the commits), it’s the same with Linux 64 bit so it means most of us can’t make use of it yet.
It will be once my quantum 3D printer arrives.
Doing an initial go-around with the new microdisplacement falloff (in a scene involving one of my Dragon models). The memory savings are immense to say the least.
I’m guessing the idea here would be to set the falloff as high as possible without causing visual issues (especially in areas where geometry or detail is seen via reflections or sharp shadows).
Last month I’ve posted Lee Griggs VD in Arnold http://www.leegriggs.com/abstract-render .
Today I found out that VD is coming to Cycles.
This is the end of the multires modifier for me.
Why microdisplacement flirck in animation? The adaptive subdivision Isn’t prepared for animations? look likes V-ray and Octane use the same process, but the displacement is perfectly stable in those render engines.
I personally think the multires sculpting in general should be replaced with the ability to directly paint vector displacement maps.
How it would work is that you would still have the sculpt brushes, but as you use them, Blender paints a texture which is then previewed via a GPU tessellation shader. The benefit of all that would be the end of spikes, NaN faces, and other bugs that have plagued the use of multires sculpting (even if you make changes or add on to your model, which will be a bonus).
Combine that with UDIM and the ability to just add new UV tiles and we would have cinematic-grade sculpting that is far more memory efficient (thanks to the dicing feature).
It looks like an idea using a dependency loop cycle. A brush to feel like a sculpt brush implies to be able to pass pointer over displaced parts of mesh to modify map responsible of this displacement.
Currently, you can create a protuberance with snake hook brush at a low level of subdivision and detail it at an higher subdivision.
A workflow based on maps would also conduct to manage several resolutions of details.
And anyways, current sculpt brushes would have to be kept for dyntopo sculpting which does not imply UVs and shapekeys sculpting.
Ability to simply bake a vector displacement map is already a challenging feature request.
yes, works fine (64 samples, motion blur, denoiser…)
me thinking more about animated textures
Making the round trip from actual geometry to vector displacement map back to actual geometry during sculpting is quite pointless, it only makes things slower for no benefit. The spikes in multires are due problems in the tangent space encoding of displacement, which would not be solved by storing the displacements in an image instead of on a mesh, that doesn’t change the encoding.
All renderers that do camera adaptive subdivision suffer from flickering to some extent. The solution is usually to make the dicing rate sufficiently small, specify a fixed dicing camera, and ensure that the displacement maps are smooth enough. I’m not sure what kind of setup you are comparing it to though, maybe something that just subdivides without taking the camera into account, or perhaps there is a bug in Cycles with some specific .blend.
In that case, there should be an effort to fix the broken tangent space encoding (Perhaps as part of the modifier rewrite in 2,8). Otherwise, I don’t see any reason why the Multires code shouldn’t be nuked entirely from Blender 2.8 so people won’t inevitably see their vision crushed. This would especially be so if Blender gets the ability to bake the sculpt work into a vector displacement map (so you can render it in Cycles using the adaptive dicing).
It’s good that the BF quietly removed all mention of Multires from their features page in the meantime (and gave it only a passing reference in the manual).
Great work with the latest displace patch’s, Big step forward. Being able to use Vector displace Stamps for sculpt brush’s in the sculpt tool would be handy. Sculpt with textures at this point is all height based, so no way of adding overhangs or detail that cant be mapped to a height field.
Beyond that even more helpful and needed is being able to sculpt with texture height map AND apply normal, albedo, Rough, at the same time. If im sculpting a rock face from a texture that I have PBR maps for like normal ,rough, albedo etc. As it is you can sculpt with a height brush, but that means all other textures that match cant be utilized. THAT would be ground breaking for sculpt work with Blender.
And about multi-res, Leave that bad boy alone!. Unless there is a better alternative, it’s still the best tool in the bag right now even with flaws. I can sculpt 130 milliion poly objects with it on very poor hardware, and output bakes as needed. You take that away without alternative the sculpt tool becomes unusable.
Actually I think I spoke early by saying it’s the end of multires modifier, as I doubt you could bake a vector displacement map from a high-res dyntopo model onto a retopologized model. Maybe I’m wrong? I’d like to be.
Many had the same opinion about Multires sculpting, until they started doing serious high resolution sculpt work (utilizing the full feature set of switching between levels and the like). Then they started getting spikes and NaN faces and never touched the modifier again.
That’s not to mention that rendering raw Multires data means no use of any dicing based on distance from the camera or how far away it is from the view cone (even 64GB of RAM will struggle to hold 130 million polygons once you add texturing and a scene). The only way forward is to bake the data to a displacement map and use the dicing (but then you end up losing the vector aspect and you could’ve just ‘sculpted’ by painting a greyscale map manually).
Anyway, to get deeper into what the fate of Multires should be belongs to another thread (to avoid muddling the purpose of this thread which is to track the progress of Cycles render-time displacement).
Aghhh come on, You always crack me up. 130 Million tris is pretty high res, Without that modifier that would be impossible. You do get issues but like everything in Blender you find a hack or fix. I would love for things to work perfectly as they are, but with a little grey matter and persistence you can fix most those problems.
Would rather have the modifier than not, If something better is soon available all the better. But clearly you have never tried using the sculpt tool with such high tris counts. You need to keep to your little dragon models, Leave the real work to others who do it every day. Don’t try to push for removing something you never understood or used correctly in the first place.
I do agree with 3DLuver. He is right. Don’t need to panic with unused method if you didn’t used it yourself. Try to understanding the people which was been able done.
I am wondering if it is possible to improve this principle. Problem occurs because camera is moving.
A fixed dicing camera just means a dicing from one point of view. It means dicing would be optimal for one position of the path of animated camera.
Could it be possible to use a fixed dicing based on path of animated camera instead of just one point ?
Could dicing be fixed by a field based on the whole path or just few points (2, 3 or 4 key positions of animated camera) ?
Of course, it will end up with a more dense mesh for same dicing rate but it would be up to the user to deal with it and a higher dicing rate or only use one fixed point.
I suggest a “lazy” un-dice behaviour in case of animation of the camera.
That means: if a poligon is diced up to 1px but due to the camera movement in next frame it should be diced 2X, lets wait and keep 1x for a few frames. The laziness could be set by a single parameter then.
This leads to a heavier mesh too, but probably less dense than your suggestion
edit: this was sillyness! what should happen when dicing is reversed? from 2x to 1x? The whole process should be path-aware, lens aware rotation aware… ok let’s forget it