[Bf-committers] Inverse Shrinkwrap? (only "keep above surface")

Juan Pablo Bouza jpbouza at hotmail.com
Sun Feb 20 02:04:54 CET 2011


Here is a rig I did that has full body muscle simulation (or sort of) made with shrinkwrap. It's blender 2.49. I had to use nearest surface point in most cases, combined with a subsurf modifier in each muscle object.

The feature Campbell agreed to do would be cool, but in my opinion, if we are talking of complex surfaces, the shrinkwrap modifier needs a full refactoring and I don't know if there is any dev willing to that at this moment...

> Date: Sat, 19 Feb 2011 14:42:32 +0100
> From: tobias.oelgarte at googlemail.com
> To: bf-committers at blender.org
> Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only "keep above surface")
> 
> If you reduce the "offset" to 0.0 then the problem is not visible. It 
> only happens with offset different from 0. Offset is ignored, until 
> original mesh, without offset, is reached.
> 
> Am 19.02.2011 14:24, schrieb Tobias Oelgarte:
> > Currently i did some tests and it shows that the behavior of 
> > projection and  and nearest surface point is way different. Projection 
> > also makes the vertices jumping. I tested it with svn rev34989 and 
> > appended an very simple example. Just use the shapekey-slider (Key 1) 
> > of the red inner object (something like a muscle) and you will see 
> > that the skin is snapping. First nothing, then a jump, followed by a 
> > smooth further transition. That is unacceptable for muscles and in 
> > many complex cases even worse.
> >
> > Example file: http://www.pasteall.org/blend/5290
> >
> > Am 19.02.2011 10:16, schrieb Campbell Barton:
> >> Found this can be done already (sort of),
> >> Project negative then cull front or back.
> >>
> >> There was a bug where rotating the object made culling fail, fixed 
> >> r34986.
> >>
> >> This works ok with a sphere/cube and sphere/plane so in real usage
> >> there may be some other options needed.
> >> If this isn't working well I'd be interested to see an example blend 
> >> file.
> >>
> >> On Fri, Feb 18, 2011 at 8:02 PM, Daniel Salazar - 3Developer.com
> >> <zanqdo at gmail.com>  wrote:
> >>> Thumbs up for suggestion. For group behavior lets just wait for nodal
> >>> modifiers, this will be a no brainer with a forgroup loop node
> >>>
> >>> cheers
> >>>
> >>> Daniel Salazar
> >>>
> >>>
> >>> 2011/2/18<raulf at info.upr.edu.cu>:
> >>>> Hi
> >>>>
> >>>> May be my recent released relaxation patch can help
> >>>> http://www.box.net/shared/ddhtfnsq75
> >>>>
> >>>>
> >>>>> HI guys!
> >>>>>
> >>>>> As I see it, shrinkwrap is lacking of two things that would make 
> >>>>> it even
> >>>>> better.
> >>>>>
> >>>>> 1_ A Neighboring vertexes smoothing factor. This would be done by 
> >>>>> applying
> >>>>> a kind of falloff to the affected surface like in these examples:
> >>>>>
> >>>>>   http://chrisevans3d.com/tutorials/maya_muscle.htm
> >>>>>
> >>>>> 2_ An algorithm that determines that if a vertex movement goes out 
> >>>>> of a
> >>>>> certain distance range, those vertexes should be smooth out or its
> >>>>> movement averaged with the movement of the neighboring vertexes. This
> >>>>> feature could avoid vertex artifacts with an articulated object, 
> >>>>> specially
> >>>>> in projection mode.
> >>>>>
> >>>>> Maybe this is too much to ask from Campbell's weekend quick fix, 
> >>>>> but you
> >>>>> never know when Jaguarandi is reading :p
> >>>>>
> >>>>>
> >>>>>> Date: Fri, 18 Feb 2011 14:26:55 +0100
> >>>>>> From: tobias.oelgarte at googlemail.com
> >>>>>> To: bf-committers at blender.org
> >>>>>> Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only "keep above
> >>>>>> surface")
> >>>>>>
> >>>>>> Using a group of objects could be useful, but if it's not done for
> >>>>>> multiple objects, you still can just apply multiple shrinkwraps 
> >>>>>> in "keep
> >>>>>> above only" mode to achieve more or less the same result. In many 
> >>>>>> cases
> >>>>>> it would be just one "collision" object and fine. Of course 
> >>>>>> groups of
> >>>>>> objects would move the vertices more correctly. But as you said: One
> >>>>>> step at a time. The first one alone would already be great.
> >>>>>>
> >>>>>> Am 18.02.2011 14:14, schrieb Campbell Barton:
> >>>>>>> You're right that this is simple to add and agree it seems very
> >>>>>> useful,
> >>>>>>> quick way to reducing intersections without physics errors.
> >>>>>>> The main downside I can see, as the verts slide over large 
> >>>>>>> variance it
> >>>>>>> could give visible popping in some cases, though this is no 
> >>>>>>> difference
> >>>>>>> then shrink-wrap for other uses.
> >>>>>>>
> >>>>>>> Though it makes me think for this feature it would be even more 
> >>>>>>> useful
> >>>>>>> in production is if the modifier could select a group of objects to
> >>>>>>> 'not pass through', rather then a single one.
> >>>>>>>
> >>>>>>> But one thing at a time, this seems reasonable and if theres no
> >>>>>>> objections I can add this over the weekend since I made some 
> >>>>>>> changes
> >>>>>>> to this area recently.
> >>>>>>>
> >>>>>>> On Fri, Feb 18, 2011 at 12:43 PM, Tobias Oelgarte
> >>>>>>> <tobias.oelgarte at googlemail.com>    wrote:
> >>>>>>>> Shrinkwrap is designed to force vertices onto the surface of 
> >>>>>>>> another
> >>>>>>>> object. In Nearest Surfacepoint mode it moves vertices either 
> >>>>>>>> to the
> >>>>>>>> surface or optionally let it also move outward until they are 
> >>>>>>>> on the
> >>>>>>>> surface. So you can work with essential two options. But 
> >>>>>>>> wouldn't it
> >>>>>>>> make more sense to include also the possibility that vertices can
> >>>>>> also
> >>>>>>>> only be moved up onto the surface and and not moved toward it?
> >>>>>>>>
> >>>>>>>> It would allow you to throw a ball against a window, making the
> >>>>>> vertices
> >>>>>>>> stop that would pass trough it. There are many possible usages i
> >>>>>> could
> >>>>>>>> think of: Bubbles in a glass. Shoes that not sink slightly into 
> >>>>>>>> the
> >>>>>>>> ground. Body parts that "collide" with each other, and many more.
> >>>>>>>>
> >>>>>>>> Since the algorithm seams to handle this case already -- 
> >>>>>>>> knowing if a
> >>>>>>>> vertex is inside or outside the target, for "Keep above 
> >>>>>>>> surface"  --
> >>>>>> it
> >>>>>>>> should be just an additional option. Am i right?
> >>>>>>>>
> >>>>>>>> Cases (now):
> >>>>>>>> * Shrink to Surface
> >>>>>>>> * Shrink to Surface and move outward for "keep above"
> >>>>>>>>
> >>>>>>>> Cases (desired):
> >>>>>>>> * Shrink to Surface
> >>>>>>>> * Only "keep above"
> >>>>>>>> * Shrink to Surface and move outward for "keep above"
> >>>>>>>>
> >>>>>>>> Hope this is a little inspiration. It would make shrinkwrap 
> >>>>>>>> much more
> >>>>>>>> awesome.
> >>>>>>>>
> >>>>>>>> Greetings from
> >>>>>>>> Tobias Oelgarte
> >>>>>>>> _______________________________________________
> >>>>>>>> Bf-committers mailing list
> >>>>>>>> Bf-committers at blender.org
> >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Bf-committers mailing list
> >>>>>> Bf-committers at blender.org
> >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>> _______________________________________________
> >>>>> Bf-committers mailing list
> >>>>> Bf-committers at blender.org
> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Bf-committers mailing list
> >>>> Bf-committers at blender.org
> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>>
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >>
> >>
> >
> >
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
 		 	   		  


More information about the Bf-committers mailing list