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

Jacob Merrill blueprintrandom1 at gmail.com
Mon May 26 02:04:08 CEST 2014


If I may chime in, it would also be a excellent time to research armatures
that are made of rigid bodies (not by default) The Rigdoll I have been
researching for my own project is nearing usability, however I realize that
I am a armature coder, animator and game designer ... looking at the
progress I have made leads me to believe that some of the geniuses at the
foundation could do much better.

https://m.youtube.com/watch?v=eksALjTD8E4
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


More information about the Bf-committers mailing list