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

Harrison Nordby fishcreekblend at gmail.com
Thu May 29 22:54:48 CEST 2014

Thanks for the reply Ton.

Apologies, I left some things unclear in my first post, so I want to

1) BEPUik is a very small subset of a much larger BEPUphysics, and it is
only BEPUik that I've integrated into my custom build of blender. I agree
that putting the entirety of BEPUphysics into Blender would be unnecessary.
My goal would be to have BEPUik as another option for riggers.

2) My custom BEPUik/Blender build on github (
https://github.com/Squashwell/bepuik/releases) does NOT contain ANY C#,
mono, XNA, or anything like that. It is pure C and C++ using the same GPL
license as blender.

3) In contrast to the existing IK options, BEPUik is a full body solver.
The entire armature, or any part of it, can be taken as input. In addition,
the solver can handle arbitrary connectivity. For example, parental
hierarchies are not required and cyclic dependencies are acceptable. The
reason I implemented BEPUik in Blender was to find solutions to some
animation problems/workflow issues that otherwise Blender doesn't solve.

4) Mostly though, I just wanted to make sure the Blender Foundation had it
on their radar for the future.  I think nodal rigging would offer a much
better synergy with BEPUik than the current constraint stack. With nodal
rigging, BEPUik could be a useful tool for any rig that needs help solving
a difficult problem. Designing the rigging process such that the user can
define the flow and interaction between different systems, such as ik,
blender constraints, or any other arbitrary functionality would be greatly
helpful. Of course, I understand that we may be years away from that.

Also, can I ask which examples you didn't find encouraging?

Here's a link to a video of the current implementation, viewers seem to
think it would be useful:

I can respect your opinion if you didn't think of much of that, I just want
to make sure we are on the same page.


On Thu, May 29, 2014 at 3:57 AM, Ton Roosendaal <ton at blender.org> wrote:

> Hi,
> It's always cool to see people work on physics, solvers and engines.
> Blender unfortunately isn't very flexible here, you can't just plugin
> another solver so easily. We tried it with Itasc, but thats not very
> succesful either (and I doubt there's more than a handful people using it).
> Same is for BEPU engine. It looks nice... but I don't see any real
> breakthrough or benefit for Blender. Especially not to add it alongside our
> current armature IK system.
> Instead, I would suggest to work on Blender in ways that expands our
> functionality in compatible and design-compliant ways. Same goes for
> physics in Blender, which is heavily relying on Bullet for example. To just
> add another physics engine might not be the best way forward I'm afraid.
> On our roadmap there's node systems planned for
> constraints/modifiers/particles, but I am not sure yet how rigging would
> fit in. We also want to unfify physics, and/or make solvers "pluggable".
> This might well take a half year to a full year to mature. Lukas Toenne and
> Antonis Ryakiotakis are coordinating this and will be working on this. I'm
> sure they will welcome people who know phsyics well to help out.
> I also have to admit that the quality of examples on your webpage are not
> very encouraging. And: reading things about XNA (Microsoft) and C# is quite
> scary.
> -Ton-
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> On 25 May, 2014, at 20:53, Harrison Nordby 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