On this model(cone) yes, I have, but I never use ngons for real sculpting models. Zbrush also do not work with Ngons. So for me this is not important. But @Rimasson showed example where he have bug with 3 quads meet, and I use such topology. This bug need to be fixed if we can reproduce it. I will try to reproduce it with my model on weekends and make some extreme changes around “3 quads meet” on lower and base mesh levels. If I will have the same bug I will create bug report.
Yes you are right that an ngon is not the expected topology. Its indeed worse that this is happening on quad topolgy, but I am not that sure if these dont relate. The valence of 3 vert is also definitely a border of a patch and thats always the place where these bugs appear. But yes its indeed hard to replicate that.
If you add spikes pointing to opposite direction on a convex surface ; when you transform this surface into a concave surface, you should expect those spikes to intersect.
From this description of an ugly result obtained by applying to a basemesh an interpolation thought for another ; I am not sure we are dealing with a problem fundamentally different.
For small relief, some issues can probably be minimized by edges sliding. But edge sliding is bounded to poles. So, that seems coherent to experiment problems at poles.
Current situation looks like Blender does not have the answer about how to preserve and correct old interpolation, at same time, for new basemesh for all possible shapes sculpted at highest levels.
If you do weird things in edit mode, you can also obtain incoherent surface with a subdivision surface modifier.
I would not be surprised that is considered as a known limitation by Pablo.
That would be a major issue if you could not get rid of those spikes by using Multires Displacement Eraser or Smooth Brush.
But if you can, that is a lot less annoying than old spikes problems that were frequent, unpredictable and often, unsolvable like spikes from Ngons.
Poles are not supposed to be numerous. And when they are identified, user could avoid to tweak them. We could imagine that Pablo could improve Grab Active Vertex preview to show poles vertices colored in red, for example.
That’s a vertex singularity (3 valence vertex, a vertex with 3 edges instead of 4) which in a “perfect” topology you want to avoid. Indeed it is known that singularities can cause artifacts when using subdivisions algorithms… could even be a thing which cannot be fixed.
I tried to reproduce it, but for now seems I can not. I moved “3 quads meet” in edit mode , moved a lot from original position, rotated it, scaled it . Also sculpted it in 0,1,2,3,4 subdivision, moved a lot and far away. Still fine in last subdiv. I do not know what to say, maybe it hapens very rarely and very unpredictable. I used 2.91 to test it, but most part of my new artwork Goblin I have done in 2.90 and there also I did not have this problem. Maybe you will find exact steps to reproduce it constantly. There is nothing more I can do at the moment to help.
Artifacts will occur at high valences,what you say rather refers to valences greater than 5, but whats happening to @Rimasson here is just the result of a bug, not bad topology. Catmull Clarks algorithm is very well capable to compensate positioning extraordinary vertices on the limitsurface. “Perfect” topology has a good edgeflow and there avoiding valence 3 and 5 is practically not possible as its a byproduct of any adapted edgeflow like eg for localizing mesh density.
guys i think is oblivious that a ngons like that in the cone, its gonna get artifacts, since is quite “illegal” topology in there for the modifier…
A basic cone is about the worst possible case for things like smooth shading and subdivision, why wouldn’t it be more prone to issues when you have such shapes in multires?
The one time I had a spike, I fixed it in editmode and spikes never occurred again (even though I didn’t touch that area with the brush). The displacement eraser can also help avoid issues by making sure you are not deviating too far from the base mesh (assuming you didn’t start from a cube).
Now I don’t know what a ‘true rewrite’ is and how different it is from when Sergey rewrote the modifier.
@MichaelBenDavid sure is the ngon case perhaps a misfit as its problems may be caused by another reason. But its not that unlikely that these spikes are caused by the same faulty code. Catmull Clark is in principle defined on triangles and quads and always produces pure quad meshes. So it may be useful to start debugging with the ngon case, especially if the input to the modifier is processed to be triangles and quads beforehand internally. Btw. there is no valence or something like that, that would cause the catmull clark algorithm to fail and produce such spikes. Thats a bug in the mulltires modifier not a builtin limitation of the original algorithm.
But the case @Rimasson was talking about was not about that cone example. He’s describing a case that happens with “valid” mesh parameters.
It’s a triangle fan and an ngon. If the structure is eg converted internally to be all triangles/quads there is nothing there where it should fail. It’s an ugly input still, but not one that is beyond what is allowed. Triangles are not ideal for catmull clark for a beautiful edgeflow of the resulting mesh and the high valence isnt nice either, but hey its still twomanifold and closed - could be worse.
There is nothing complicated about subdividing an ngon. These spikes are a Blender only issue that has been lingering for well over a decade at this point. I can’t believe the kinds of things some people will try to defend here.
Here’s the related report and it’s marked as confirmed:
So if you have a similar mesh that gives the same problem, you could perhaps share it in that report as well.
Laughing hard right now. At last there is tilt support.
The difference is that with a proper code/rewrite, those spikes won’t happen…
At this point, those spikes are a feature exclusive to blender lol… Blender Spikes®
I can’t reproduce the error here in 2.90 or 2.91, and luckily haven’t encountered the issue in a while, but I do remember having some occasional random spikes on older versions, and almost always the problem was caused because I didn’t hit the Apply Base button if the lower subdiv level was too different from the original mesh. Maybe that’s the cause in your case?
IMHO the Apply Base thing should be always automatic, and if it’s going to be kept as an option then at least this spike issue should be a priority, before adding any new features.
So true, in fact its such a fundamentally important feature, that they decided the blender logo to resemble a torus with Blender Spikes®
2.91.0 doesn’t have any experimental option
Where can I test the hidden sculpting brushes?
I think you may have misunderstandings about development that lead to this idea of “true rewrite” : code does not rust, it is not some unwieldy old cranking machine that needs to be oiled to function correctly. Code is split into parts (if done correctly, of course) that allow for replacing of very specific parts without touching the rest. In the case of multires, Sergey and Brecht came up with a method for interpolating displacement values on multires grids that may not be perfect, but is “new” (although came from papers on the subject), and completely replaced the old one. The multires modifier is new, it’s just not completely foolproof in any situation yet and that’s fine as long as we keep reporting bugs, so it can improve. It has to deal with ngons (which are actually a mess of triangles under the hood), and I wouldn’t expect good results from that. Obviously @Rimasson’s issue here is a proper bug, happening on perfectly good topology that should just work.
Ah this is what I missed, thanks
@mib2berlin I didn’t have that because I needed to check the Developer extras first