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: [email protected] > To: [email protected] > 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: [email protected] > > To: [email protected] > > 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 > > >> <[email protected]> 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<[email protected]>: > > >>>> 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: [email protected] > > >>>>>> To: [email protected] > > >>>>>> 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 > > >>>>>>> <[email protected]> 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 > > >>>>>>>> [email protected] > > >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers > > >>>>>>>> > > >>>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Bf-committers mailing list > > >>>>>> [email protected] > > >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers > > >>>>> _______________________________________________ > > >>>>> Bf-committers mailing list > > >>>>> [email protected] > > >>>>> http://lists.blender.org/mailman/listinfo/bf-committers > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Bf-committers mailing list > > >>>> [email protected] > > >>>> http://lists.blender.org/mailman/listinfo/bf-committers > > >>>> > > >>> _______________________________________________ > > >>> Bf-committers mailing list > > >>> [email protected] > > >>> http://lists.blender.org/mailman/listinfo/bf-committers > > >>> > > >> > > >> > > > > > > > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
