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

[Ton Roosendaal]

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