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

[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
>>
>
>