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 <ra...@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.oelga...@googlemail.com >>> To: bf-committers@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.oelga...@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@blender.org >>> >> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >>> > >>> > >>> >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers