As some of you have guessed, I have grown tired of the constant complaining about the current sculpt workflow and I’m sure the devs. are too, but the solution to resolving complaints is not to complain louder, but instead break things down into smaller components and use those to write up a clear list of things that can be done to improve the situation.
For this thread, I will take what I have gathered so far and use them to produce a clear and simple list of things that Campbell and other developers can do right away to improve the situation (this may not cover every possible issue, but it would be a start).
ERROR CONTROL::
-Introduce an automatic recalculation of mesh normals when multires is activated or when the multires mesh is being edited, if the normals cannot be made consistent in spots, then there should be a warning that tells the user that that there is inconsistency in the normals and that the mesh should be looked over.
-Introduce a warning color for faces, so in the case there are inconsistent normals because of non-manifold faces, highlight the faces in the warning color so the user can see right away where the problem area is. (See Figure1)
-If the user is sculpting around these non-manifold faces, then Blender should handle it in a more graceful manner by having the sculpt tools fail to do any displacement in the immediate vicinity (using data from the level 0 mesh propagated upwards to the current mesh). This will avoid situations where we see things like infinite faces (see Figure 1)
-------------------------------------------------------
GENERAL WORKFLOW IMPROVEMENTS::
-creating new faces in a mesh using the modifier currently just copies the displacement data of the faces being copied from, but this is not ideal in many situations, instead, it might make things easier by interpolating from the edge of the existing displacement data to no displacement data in the new faces bordering the displaced ones. Another possibility is to have a full-on interpolation zone that comprises any edge bordering one of the new faces, but that might be a little trickier to code.
-Subdividing faces with current multires data can also create certain ‘splints’ that may not be desirable, a possible solution would be to create a zone that surrounds the affected edges and do an automatic smooth operation in those regions.
Shrinkwrap modifier - create a new, simplified projection method that utilizes a simple raycast from the face center to wrap a retopology mesh around an object (casting in the opposite direction of the face normal), the theory would be that this simpler method would not be as prone to positioning errors (and would be a lot more usable than the existing ‘project’ method). This idea is shown in figure 2, though there could also be an optional offset feature that moves the face center to a position on the ray above the target object.
Hopefully this can be seen as a start, and please, if you have something extra to propose or you would like to comment, try to keep it clear, concise, and understandable and try not to fill it with sarcasm and drama. I know some of you have some pretty strong feelings on this sort of thing but I think it would be nice to try toning them down.
Also, if the devs. can indeed take a look at these points, I hope that they can act as a starting point for at least some of the improvement.
Honestly, as a veteran user, I can’t understand what you are writing here without some mock ups and visuals. I would encourage that you solicit as much info from the very users that you consider to be ‘complaining’ and utilize it for its value. The workflow that the sculpt users have documented while trying to use the multires modifier and shrinkwrap, retopo, etc. would be the best starting point to show what is now, and then take suggestions on what it should be, with mock ups and explanations. I would point to the UI thread davesf started as a good example of how this discussion could grow.
I think the “error controls” have been presented as if we know what the cause of those errors are,which we don’t.They are random.So we’d be adding “warnings” to areas we don’t even know are the cause? For instance,it was said that inverted normals create spikes,well,I got a mesh,flipped some normals,subdivided,and got no spikes.All that happened was the sculpt displaced in the opposite way on those particular normals.Thats expected behaviour.
But with the spike thing,thats the main issue with multires,unpredictability.
Now in saying that, for reference,these are the main issues with multires as listed by sanctuary,gathered from people who use sculpt quite frequently.I’ve bolded some key points.
-Bake from Multires does not bake on the lowest multires (the base mesh), it can only bake on the 1st level
Vertex Painting (and the Dirty Vertex function too) is only able to vertex paint on the lowest multires level (the base mesh), dealing then very bad results unless you apply the multires, while Texture Paint works great with multires.
Performance at high multires can be near crippled (of course result vary if you have some supercomputer or not but the performance hit should still be noticable) depending if your base mesh is over 1000 faces, making it then difficult to use it for characters (that base are usually over 1000 faces) , while less than 1000 faces can go very high without that much performance hit (again depending on the system)
Sometime when sculpting at a certain multires level, if you want to go into a lower one, spikes can suddenly popup out of the mesh (reminding of what can happen with shrinkwrap going wrong when it happens around a hole, in which the vertices will simply go insane and either project on the wrong side of the mesh or jump out in the Blender view stratosphere), this one is very random as i have not been able to reproduce it reliably, but anyone using multires will certainly have run into it one day
My points on error control were in part inspired by the post I saw in Doris’ sketchbook thread, to quote…
i learned however, that most of the spikes were caused by mistakes in the mesh: for example, i had polygons inside the horse, that were connected to the horse with one edge. these polygons made lots of spikes… i also had areas that looked like “only quads”, but there were double vertices and so the polygons had more sides and overlapping. shrinkwrap does not like that either… (maybe the programmers could build in a check if the mesh is ok for shrinkwrap? and give a list of problems if not?.. just an idea, since hunting the mistakes by hand is quite a taks…) …
Now I read it again to find that she was mainly referring to use of the shrinkwrap modifier, but as seen with the non-manifold mesh image I posted, I can’t imagine multires liking that in many cases either.
Multires needs a lot of love. After we fix our Cat-Clark implementation the ability to reconstruct subdivisions would be great first step, IMO. The unsubdivide option in the decimate modifier just doesn’t cut it. A better reprojection algorithm wouldn’t hurt either, one that handles interior cavities better and includes poly painting.
I found that out too, I fixed the normal, deleted the multires modifier, made a new one, and sculpted there and there was no spike. (which seems to lend credence to my error control idea of doing an auto-recalculation of normals when multires is being used). It seems to be in this case that one of the possible causes for spikes at some point during the workflow is that it’s sometimes almost too easy to accidentally get an inconsistent normal in spots while modeling (which multires apparently doesn’t like).
Note that the spike bug can happen in multires sculpt for which the base model does not have any error, no wrong normals, no double vertices, no modifier that shouldn’t be there, that’s why it is unpredictable and none until Doris actually managed to produce a blend featuring it , even if in that case it’s the wrong normal that can cause it, because none found a pattern to reproduce it 100% (even creating wrong normals on purpose does not always lead in spike as ng material mentionned) so there’s certainly more than wrong normals involved.
edit : unless some brush code in specific condition can alter a face normal
@Ace - are you just asking for a quick visual way to show when you are looking at the back of faces?
Currently you can switch to Blender-Game / Textured mode, and then turn on “backface cull” in the material/game-settings panel, though I could imagine making an easier-to-use way to quickly highlight the backs of faces in a highlight color.
Okay, I spent quite a few minutes doing random sculpting with random brushes on a cube subdivded to level 7 (later to level 8 and level 9), and even when I tried to create bad geometry on purpose with the brushes and pressed ‘apply base’ (allegedly a source of many problems), I couldn’t get spikes to show up anywhere. I tried to make overhanging faces, long faces, ect… and nothing showed up. (this using brushes like clay strips, blob, pinch, polish, grab, smooth, ect…)
Just to note, that test was a bit more thorough than my previous ones, but I couldn’t get the error to show up.
Currently you can switch to Blender-Game / Textured mode, and then turn on “backface cull” in the material/game-settings panel, though I could imagine making an easier-to-use way to quickly highlight the backs of faces in a highlight color.
In general, you can turn it on in ‘Blender render’ mode for the entire object and backfaces will be invisible, but if you have a complex model then you might need an assist to help you find the faces you missed.
edit : unless some brush code in specific condition can alter a face normal
On top of this, think back to what tools you were using and the type of strokes you were making when you started noticing spikes, is there any apparent pattern in the usage of the sculpt tools, the tool you were using, the layout of that section of geometry, and multires modifier usage that comes up?
Actually, Backface culling is availeble near the mocked hidden-wire option in the display settings. It’s right underneath the matcaps.
I was thinking, would it perhaps help tracking down the error if someone attempted to make a ‘sculpt-logging’ build of blender? Basically, if you pull down the file-bar from top, there’s the console. Can we use the console to log the activity in sculpting? Then we get the sculpting people to sculpt till they develop an error, and then we have an idea of what blender thinks it did.
Chances are it’s not just one bug, but a couple of them, perhaps combining to form this error.
And that’s why we say it’s unpredictable, i have been able to sculpt in multires without problems most of the time, and i don’t talk of only sculpting a subdivided cube but much more complex shapes and characters, representing dozen and dozen of hours with absolutely no problem at all with multires.
Until one day in which still no problem then going back to a previous multires level … a spike.
Smoothing it (with the smooth brush) then going back to the multires level i was in (and in which there was nothing wrong), the spike is back and is even worse, smoothing it is more difficult , but can be done, curious i got back to previous level, and … the spike is back.
And to add to that oddity, i was using the same base model that i had already used previously without any problems, so it couldn’t be a wrong normal on it (and it had no such problem indeed).
On the support boards you can find a few threads in the last couple of years from people mentionning something similar.
That’s why this one is frustrating, because you can’t find a pattern to make a reproducible case, and when it happens it’s not fixable by your brushes
At some point i was wondering if the normal recalculations the viewport/the sculpt engines, whatever codes are running in the Blender backbone could do somehow during multires could be screwed up by usage of Crease and Pinch brushes that by nature tend to pull vertices very close to each other, possibly then creating some accidental overlap case, that could puzzle a normal recalculation algorithm and explaining why this could happen with a perfectly clean base mesh.
Because overlapping faces can be responsible of many modelling normals problem. But as a simple user that has 0 idea of what’s really going on with the brushes, sculpt mode or display code, i can’t be sure of anything
I guess then it could be just a matter of someone going through the code and editing the parts that might look dubious either in terms of design or in terms of being brought up as a potential trouble spot when profiled.
Campbell does this all the time in many other areas of Blender, but if there is anything that just breaks down in the code after a while, there’s no guarantee that will fix things.
even if we have “solved” the bug in doris’s file,is there a chance that the “bug” could still be in the file? would it be worth reporting it?,along with an explanation of out past issues with spikes?
I have also had the spike bug when sculpting - it was around the join in the middle of the mesh and using an x mirror - so possibly where verticies were very close or overlapping. I think it came when I went down a multi-res level. This was also after many hours sculpting on the mesh without problems. I have also tried to reproduce and have not been able to.
There was one other weird thing that may help that I haven’t heard mentioned:
I smoothed out the spike, and then hit ctrl+s to save - the spike came back (but slightly smaller)! Smoothed it, hit ctrl+s - spike back but much smaller. Did this a few more times and finally it was gone for good. So - what code is run during save that could cause that to happen? Maybe some code that is also run when changing level or going into edit mode. Just a thought that it may provide a clue.
The key point is going up and down subdivision levels. The bug is in the code that reconstructs displacements from the tangent space of faces across multiple subdivision levels.
Generally for other cases my suspicion goes to that same tangent space going nuts, either because of faces being too close to each other or some other floating point or mathematical error.
I would think so,michalis had this happen a while back when using a apply base,that one is actually easy to reproduce.
1.take a cube and add a level 3 subsurf ,apply modifier.
2.Then add a multires modifier ,subdivide it twice,use the twist brush on it,then click “apply base” go down a level and you definitely get spikes
My theory was, it simply doesn’t know how to estimate geometry on the lower levels and just flips out.I attached a file with that issue.Just lower the level.
apply base just trys to match the base mesh as close it can to the highest level (maybe too much so) so perhaps the apply base function is flawed itself.or at least there should be a warning that it can’t be used when the displacement it too “extreme”
heres a file with the issue.Just lower the level.
[ATTACH]249063[/ATTACH]
but again this doesn’t explain randomly getting spikes on “good” topology,but could be a clue.
Being so tired… after the last events. I’ll keep watching this thread.
Thank you all for starting it.
Just an observation. Bad performance of multires doesn’t always depend on the density of the retopology cage. The base mesh.
I tried hard and it still is impossible for me to understand what else troubles this modifier.
On the other hand, having a couple of possible workflows in mind, I would ask for some more capabilities in multires.
The most important, from my point of view, is to be able to reconstruct subdivisions from an imported mesh (which already is a subdivided mesh). Something like what the decimator Modifier (Unsubidive mode) tries to do. But not this algorithm at all. Something accurate I have in mind. This is just my wish list. But, it may be the key for a better functioning multires modifier. Memory free.
That file has a basic error, inconsistent normals. If I fix that error before adding the multires modifier it doesn’t spike for me.
You are right! the file had basic errors indeed. Confirmed.
(unfortunately) LOL
Because such errors are happening randomly.
An automatic fix could be nice.
In the middle of such complicated workarounds, a mess is always possible.
The artist has too many to fight with.
We all have to keep this in mind.
It is after all, the most important.
A developer should have this in mind always.
As the artist always has in mind the critics.
So there is some movement, this doesn’t specifically address the spike bug (or multires), but you should see at least some of the sculpting area be a little more stable.
