[Bf-committers] Thoughts on possible future merge of full body ik solver into trunk?

[Daniel Salazar - patazstudio.com]

Ok, I'm asking because of iTaSC IK (btw I'd really recommend dropping
the acronyms). iTaSC is a per armature setting, if you would like to
use an iTaSC feature you need to turn your entire rig into that
technology which always causes problems. But you mention this is more
like a new constraint?

Daniel Salazar
patazstudio.com


On Sun, May 25, 2014 at 6:03 PM, Harrison Nordby
<fishcreekblend at gmail.com> wrote:
> There should be no issues with non-BEPUik constraints.  The BEPUik auto
> rig, seen in the video, actually uses a couple default blender constraints.
>
> >From what I can tell, Rigify would have to be significantly modified to use
> BEPUik.
>
> If blender had nodal rigging, it would be a lot easier for any rig to
> utilize the BEPUik solver.
>
>
> On Sun, May 25, 2014 at 6:23 PM, Daniel Salazar - patazstudio.com <
> zanqdo at gmail.com> wrote:
>
>> Interesting. How does this integrate with the default current IK
>> system and constraints? Could it work as an addition to current rigs
>> or do we have to design for this from scratch? Is it fully compatible
>> with all the constraints and have you tested with full available rigs
>> like Cessen's rigify?
>>
>> best regards,
>>
>> Daniel Salazar
>> patazstudio.com
>>
>>
>> On Sun, May 25, 2014 at 12:53 PM, Harrison Nordby
>> <fishcreekblend at gmail.com> wrote:
>> > Hi everyone, my name is Harrison Nordby. My brother, Ross, wrote
>> > BEPUphysics, an open source physics library for C#.
>> > http://www.bepuphysics.com/
>> >
>> > We decided that blender was the best solution for creating our game's
>> > content. So, I integrated BEPUik (a full body inverse kinematics library)
>> > into my custom build of blender.
>> > https://www.youtube.com/watch?v=lG3uKYQTVj4
>> >
>> > http://wiki.blender.org/index.php/User:Squashwell
>> >
>> > I've used a few sloppy hacks to get it situated. Even so, it does "work."
>> >
>> > Would the blender foundation be interested in something like this for
>> trunk?
>> >
>> > Are there plans to "node-ify" rigging? If so, I think it would be a good
>> > idea to wait until then to integrate BEPUik.  My current implementation
>> > places BEPUik constraints on the constraint stack, but this isn't
>> analogous
>> > to how BEPUik constraints work. Conceptually, BEPUik constraints are
>> > evaluated simultaneously.
>> >
>> > Also, I've hard coded the solving order like this:
>> > Animation data -> Solve All bepuik constraints -> Solve other blender
>> > constraints
>> >
>> > This is an arbitrary ordering, and it "works" in most cases, however
>> there
>> > are places where it doesn't give as good effect as it could. A proper
>> > implementation of nodal rigging would give the user the ability to define
>> > these arbitrary relationships.
>> >
>> > There are a lot of other areas to discuss, but I'll leave it there for
>> now;
>> > thanks for your time.
>> > _______________________________________________
>> > 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