About the problem with shrinkwrap modifier

[Sanctuary]

Shrinkwrap is a very usefull modifier when you retopo a sculpt, as for the retopo to recapture the details of your original sculpt , you add subsurf to increase the facecount then add a shrinkwrap to have the vertices reprojected on the target sculpt.
But when you get higher in subsurf level, the shrinkwrap can do some really bad job.

NOTE : you can download the .blend of this example (contain both the sculpt and the retopo) to test by yourself :

Legobet88: Daftar Link Alternatif Bet88 Slot Login Situs Gacor Terbaru &...

I made this dragon head in Sculptris last year and imported it into Blender

It’s not very high poly due to it being made with Sculptris, but it’s full triangles with topology not really exploitable, due to being made in Sculptris.
So in Blender 2.6x i did a manual retopo, a simple one with each vertices moved manually and “snapped to surface”.

Now let’s add 1 level of Subdivision Surface modifier and a Shrinkwrap modifier so the subsurfed model recapture the details

That’s actually very nice

Let’s go with another level of Subdivision to get better details

It looks good, but it seems at the upper right part of the brow, something odd is going on.
But more subsurf levels are needed to get the same level of details as in the sculpt
So another level of subdivision

Ok, now the problem in the brow become more and more obvious :

Other level of subdivisions makes this problem really clear :

Very very bad.

Let’s try in the Shrinkwrap modifier to use “Project” instead of “Nearest Surface Point”, after all my vertices due to the retopo being manually done are all snapping to surface, so projecting them should then be good.

And it seems, the brow is very good if i switch the Shrinkwrap to “Project”, unlike with “Nearest Surface Point” :

But that’s for only the brow, because if i now look at the whole model using “Project” :

Results even worse.

Any other example guys ? Any hints at how to obtain good results with shrinkwrap everytime ?

[Richard_Marklew]

If some specific areas require project use two shrinkwrap modifiers with vertex weight controlling what needs to use project

Attachments

[ng-material]

gah,it seems project only works well on simple meshes,with no spikey parts coming out.

I think the main use of shrink wrap is for clothing,so perhaps these complex things won’t really work

[Sanctuary]

@Richard Marklew

If some specific areas require project use two shrinkwrap modifiers with vertex weight controlling what needs to use project

Amazing ! thank you very much.
I never thought about the vertex groups then playing with the weight.

I’ll have to test with other sculpts that delivered similar problems, but from my quick test on the dragon it looks like a very good solution.

[Sanctuary]

gah,it seems project only works well on simple meshes,with no spikey parts coming out.

Yes, i start to believe so, after trying Richard Marklew solution, i ran into the spikey part that exhibited the same problem as in the brow, but trying to use vertex groups/weight paint in those locations do not result in desired projection, unlike for the brow area (that is much simpler) in which it worked perfectly.

But even with the problem located in the most complex part of the model, it’s already much better.

though, i don’t understand when setting up “Project” in the shrinkwrap modifier, why is a vertice going to project itself to the complete other side of the model, ignoring every surface that are very close it, creating those ugly bad spike .

oops added a reply insted of edit

[Sanctuary]

No edit, new post because i made further test, and now i think the “Project” setting has in fact a real bug.

See in 2.64a :
subsurf is set to level 4
shrinkwrap set to Project, both positive and negative and no culled face.

Now in 2.49b (save the blend with “legacy mesh format” enabled if you accept to try)
Same subsurf level, same settings (projection, both negative and positive and no face culling)

result :

while there’s something odd going on in one of the dragon spike, the huge melted vertices explosion does not happen.

If you guys can confirm you observe the exact same problem, i’ll fill a bug report (assuming none else may have filled one already as this bug may be here since a very lot of time).

edit : uploaded the blend with “save legacy format” enabled, so you can just load it in 2.49b without having to do it first in 2.6x

Legobet88: Daftar Link Alternatif Bet88 Slot Login Situs Gacor Terbaru &...

[Atom]

@Sanctuary: I turned on Cull Faces Front and that helped with the spikey problem while in Project mode. I did this after I ran a Tri-Quad operation on the original sculpt mesh.

[ng-material]

i’ll download 2.49b and try.I’ll edit my post with the result.

edit: I can confirm that I get that result too in 2.49b,I think you should send the bug report.

not sure whats causing the weird spikey part in 2.49

[Sanctuary]

@Atom
Yes, but if you turn cull face for front or back, you’ll notice there are plenty of areas of the model that are not “shrinkwrapped” anymore, and so you lose lot of details (defeating then the point of using the shrinkwrap) :

instead of

edit : tested in 2.62 and the problem is similar to 2.64a with the exact same projection settings, unlike 2.49b it still create the vertice explosion, so at least that’s not something introduced by the bmesh code.

[Atom]

Have you thought about just creating a normal map from the original and then use that on a lower poly version? It seems like for rendering purposes you don’t really need all that geometry anyway.

[Sanctuary]

Yes that’s what i usually always do as i work with low poly models that i usually make game engines friendly
But still there are several situations in which to bake optimally or render with texture set to “Generated” you need the high poly version being rather high density and if possible with faces roughly even.

Something you can’t really obtain through Sculptris or Dyntopo and retopo, while with using the retopo+subsurf then shrinkwrap you can do.

[ng-material]

@Atom

Have you thought about just creating a normal map from the original and then use that on a lower poly version? It seems like for rendering purposes you don’t really need all that geometry anyway.

A dyntopo mesh is triangulated,the shrinkwrap is for converting it to quads for higher (multires) sculpting with correct topology/unwrapping.The normal map process would take place after.

dyntopo is a lot more comfortable to work with as a starting point,which explains the dyntopo>retopo>shrinkwrap>Uv unwrap>Multires>Bake displacement/normal workflow, that a few of us are experimenting with.

[RickyBlender]

one note here

when you have a dragon head with many weird shapes like that
i think in a case like that using shrinkwrap is not appropriate anyway!

shirnkwrap works well for simple shapes !

so best thing i guess would be to use the group weight and use several shrinkwrap to do it !
or use several shrinkwrap on different parts of the model

happy 2.6

[Sanctuary]

@ng-material

Thanks for confirming the result in 2.49b similar to what i observed, i’ll fill a bug report.
edit : reported here
http://projects.blender.org/tracker/index.php?func=detail&aid=33081&group_id=9&atid=498

@RickyBlender

Yes , the only workaround for now is to use several shrinkwrap and vertex groups as Richard Marklew suggested
But the good projection result in 2.49 vs the bad one in 2.64a seems more like a bug.

I searched on the tracker and with time several shrinkwrap bug have been reported and got some fixes, so it’s possible one of them lead into this bug.

[RickyBlender]

shrinkwrap will never be able to work on such a complex shape

a new modifier might be needed
to shrinkwrap the different parts and apply different shrinkwrap automatically
but need a genius to do that !

salutations

[ng-material]

still waiting on michalis to try the project method on his sculpt.

@rickyblender,but how do you explain the weird stuff that happened with the brow when he wasn’t using project?

that was a relatively simple part of the mesh,that still messed up badly,there is definitely an issue.

[RickyBlender]

as said in post the distortion has nothing to do with shrinkwrap but more with subdivisions!

the orignal high res head has around 71000 verts + mirror
i mean this is a very dense mesh and should have anough faces to allow the shrinkwrap to work properly !

salutations

[ng-material]

that sucks that the developer is no longer around.

[michalis]

a new modifier might be needed
to shrinkwrap the different parts and apply different shrinkwrap automatically
but need a genius to do that !

Or just buy zbrush. LOL
Joking.
Now, seriously.
I don’t intent to use the vertex groups method as it’s complicated, meaning that it’s not right.
I can confirm that blender 2.49b works almost fine. Actually, I came on this workaround using 2.49b or / and zbrush some years ago.
dyntopo>retopo>shrinkwrap>Uv unwrap>Multires>Bake displacement/normal workflow
I’ll add some more on this:
dyntopo>retopo>shrinkwrap>Uv unwrap>Multires>more serious precise sculpting up to millions of poly>bake from multires.

We don’t have to discuss the “selected to active” baking method here for two reasons.

1. It’s irrelevant, as the goal is to have a multires detailed mesh for more precise sculpting.
2. It’s an approximated baking method, resulting to blurred low quality displacement maps. The “bake from multires” method is precise and of high quality. Approximated methods are good for baking normal maps only. In this case, normal maps are and will be useless under cycles, for long time. (they have to implement nor-maps support and find a solution on the termainator issue)

I mostly agree that we need a completely new shrinkwrap modifier from scratch. As we need a new (from scratch) multires modifier. Capable to rebuild lower subdivisions and some other goodies. ZBrush users can understand better what I’m saying.
You know, I can’t accept that shrinkwrap is made for cloth simulation or retopo tricks, only.
Shrinkwrap is made for lot of things. The 2.49b shrinkwrap I mean.
Of course shrinkwrap is buggy under 2.5x - 2.6x.
A report, has to include the following:
dyntopo>retopo>shrinkwrap>Uv unwrap>Multires>more serious precise sculpting up to millions of poly>bake from multires. There’re more: Bake quality displacement 32 bit maps to use them in cycles. (Cycles suppose to be the official render engine now, right?)
The “project” method fails under 2.5x 2.6x. it works under 2.49b.

Devs have to understand that the only decent sculpting workflow, is broken. It is the only sculpting-with-precision way, you know…

[ng-material]

well,there are two workflows.

one of them doesn’t include dyntopo at all.