You could just propagate the difference in deltas during bake time from any given state as long as you maintain the subdiv relation right? I don’t see why anyone would switch that on and off while working if the main point is to keep the original base anyway.
I can only talk about my experience here. I’ve seen a couple of cases at Framestore where they used them, maybe 1-2 cases at ILM, and I’ve not seen a single case at Weta where VDMs were ever used. I imagine the practical reasons for not propagating the deltas to the lowest level is narrowing down the use cases significantly. It’s certainly not practical for characters, nor can I see how it’s particularly useful for other departments.
I’m genuinely interested in production examples though, ones that would justify disrupting a semi-fluid sculpting workflow because of their frequent usage.
Might definitely be varying across companies though. I see myself all to often getting tunnel vision and not considering other fields so I might be wrong.
If you do not like it, why not share Your idea how Multires panel could be organized. My main problem with proposed panel layout, it does categorize several parts without bring out what is important.
Imo, area “Subdivide” and “Levels” are the most important ones. I am not sure it is that good idea to split both into distinct panels and scatter them among other less important panels.
I never mixed linear and curved subdivision levels. Do you have experience with this kind of workflow?
The double way to do subdivisions also does add a pitfall. After one choose to do manual/flexible way, other way is disabled. And other way around.
I would prefer an option like “Subdivision progression mode”, where people choose which path they like to go. Instead of forcing them into one direction, depending of operator used.
Subdivision progression mode <- flexible | uniform
flexible <- each subdivision level could be simple|linear|curve
uniform <- choose subdivison method on beginning
If subdivision progression mode is flexible, ‘uniform’ properties disappear. And the other way. So 2 ways of subdividing which exclude each other do not mix up in same panel.
Why forcing developer to complicate UI just to add a mode that would remove 2 buttons and force user to precise a type of subdivision ?
UI of flexible workflow allows to follow an uniform workflow by always pressing same button.
Hiding of 2 buttons to replace them by 2 lines ( one for choice Flexible | Uniform and another one for choice between Simple | Linear | Curve ) will not fundamentally improve Multires modifier Layout.
zeauro,
I remember, it is the second time you twisted my idea into “forcing developers to do something”. It is not constructive and gets annoying. Please, keep away with this polemics and keep focus on what matters.
Currently, if you try different subdivision methods, you might notice that there are 2 ways which exclude each other. If you do flexible subdivision, the other one greys out and cant be used. It has nothing to do with adding an option, it is how it works atm.
Making this difference better understandable was all I asked for.
Sorry. I did not want to express that you were not respectful to devs.
But just that, to me, it looks like an unnecessary amount of work for no gain.
I don’t follow you.
Currently, user has access to Subdiv | Simple | Linear buttons.
What you describe as Flexible workflow would correspond to exposing those same 3 buttons.
At that moment, nothing would ever prevent user to always press on same button.
That attitude would correspond to an Uniform workflow.
So, no. A Flexible workflow UI can’t exclude Uniform workflow.
I don’t see how it makes things more clearer. OK, buttons are new.
But really, I think anybody can quickly realize by himself that if he wants to follow an uniform workflow : he just have to continue to press same button.
And if a mistake is done , well, problem would be easily fixed by delete higher button.
2.90 added more flexibility.
You can layer different methods of subdivisions. The moment you do first subdivision, the subdivision type greys out and cant be changed.
That Subdivision Type line became useless. It is no more decisive in 2.90.
Pablo coded new buttons for subdivision to work with Catmull-Clark type as default.
But he wanted to remove it when introducing new subdivisions buttons.
Pablo asked to Hans to remove it from main settings to advanced panel. Because of uncertainty about compatibility issues with previous releases.
That stayed as is only because they are not sure that old .blend files will be broken or not.
But with new ability that does not make sense to keep it.
Mh … removing “Subdivision Type” option would also fix the situation I tried to describe.
Once Subdivision-Type set to “Simple”, there wont be a non-destructive way back. After first subdivision, we wont have a smooth subdivision operator. It does make reason to keep it a smooth Catmull-Clark subdivision and remove “Subdivision Type” option.
Ok that’s what I thought. Thanks for explaining why they kept that dropdown, it did seem redundant to me. It’s a bit puzzling in that state though, especially for people who haven’t watched development closely.
Just had some fun today with Sculpt Mode and decided to do a head and a torso practice test while using the new vertex painting system. It has a lot of room to grow and develop, but I think the potential is already showing its colours.
VDMs never really took off, especially for characters/creatures. Instead Mesh density topology got much higher so the details VDMs were designed to capture became part of the geometry. Traditional displacement maps are still very much the standard.
I think your both are talking from different backgrounds a lot of game developer Small teams don’t have the time or resources to optimise a game engine to handle high poly count so they use vdm , while you are talking about a different audience of big teams and movies production…
VDMs are not very popular because the tools to create and manipulate them are not quite there. Chicken and egg problem. Nonetheless, Cycles supports VDMs, so it would be kind of a shame if we couldn’t bake them. Once you can bake them, they’d also be awesome as brushes for sculpting.
In theory, yes. In practice, I almost never use VDM brushes in ZBrush. Regular alpha-based brushing works sufficiently, and VDM brushes cause instant polygon stretching, so you always have to adjust the result, unless you’re working with many millions of polygons, but that’s usually only in the fine-tuning / tertiary detailing stage, because sculpting major forms becomes hard with many millions of polys.
To me, VDM brushes haven’t passed the gimmick stage up to now. It might change with new developments, such as VDM brushes working with dynamic topology, adding polygon detail on the fly.
