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

[Juan Pablo Bouza]

I Forgot to copy the link to the rig :p

http://www.zshare.net/download/60908072098fa1ae/

http://www.jpbouza.com.ar/ESP2/descargas/blenrig-3/

> From: jpbouza at hotmail.com
> To: bf-committers at blender.org
> Date: Sat, 19 Feb 2011 22:04:54 -0300
> Subject: Re: [Bf-committers] Inverse Shrinkwrap? (only "keep above surface")
> 
> 
> 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
>  		 	   		  
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers