featherstone and bullet multithreading,

The most recent version of bullet physics has a intresting gpu based 6dof solver, is this planned to be integrated? Blender robotics and walking ragdolls etc could become very powerfull with this…


Bump Bump, Bump



I think the GPU is already working hard enough on rasterizing. Passing the physics to it as well will make the game engine slower.

Blueprint, may I suggest you do research into what technology actually is and it’s implications before discussing it. Quite a lot of your threads/posts are about threading (which we have already told you will not help anything), or some other feature/optimization. Here at BA, people are happy to help with questions on how to do things, but get tired of responding to poorly researched feature-requests.
Actually, I have a suggestion. Go learn C++ and implement all these optimizations and features yourself. The community would appreciate that.

That’s a silly thing to say. PhysX is used in a ton of games, and things like fluid sims and tessellation are evaluated alongside rasterization on the GPU all of the time. Both next gen consoles have been shown to be able to leverage compute cores for things like physics calculations as well, and they’re not even sitting on cutting-edge hardware. You should also think outside of the game engine. GPGPU accelerated physics calculations would be a huge get for all parts of Blender.

For the BGE, any speedup in bullet is virtually insignificant; It’s already insanely fast, and people who encounter “performance issues” are typically trying to do something very stupid (like making a minecraft clone).

Or use 6dof solvers to handle animation and allow for force and torque to animate 100’s of actors, with no pre-made animation keys. I am not 100% sure, but since this is on the GPU, and not the hard drive or ram, it may actually be the fastest way to animate…

Something silly like that,

Or maybe allow players to use razor hydra/3d mice to “animate” actors with precision,

I think that the point being made here is that there are far greater performance drains than the physics simulation. Whilst gpu accelerated physics may be a useful addition, a faster / more comprehensive shader pipeline is in much greater demand, and arguably need.

Sent from my Nexus 5 using Tapatalk

I don’t argue that the shaders/lighting etc are not needed, It’s just I noted that bullet was in the at the heart of the bge,

So bullet improvements might be easy to implement,


I want to try and reduce the frame time on this…

The physics of that scene was only using between 3% and 10% of the time for your frame which was running at a steady 60 fps already. Even if you made Bullet a billion times faster than it currently is, you won’t notice any performance changes.

I see, I was thinking that 30 or so actors would be to much,

Secondly, I have been looking into using a python based featherstone solver.

I see, I was thinking that 30 or so actors would be to much,

Secondly, I have been looking into using a python based featherstone solver.

Rule #1 for optimizations: Optimize after you know there is a problem and you have measurements that prove it.

Unless you have a sceen with 30 actors in it and you can show that the physics is slowing it down then you should worry about other things. If you are worried that it might cause a slowdown, then you should setup a test frame and test the scalability of your setup so you know what you should worry about.

Well for one thing, I am sure I could have a tremendous speed up if I put all the python in 1 file, and then just used functions, I need to do that more often, other then that
I could use help if someone could look it over, its a mix of logic and python.

But featherstone can aparently be used to calculate torque apllications needed to reach a 6dof chain alignment, position etc.

How would that give you a “tremendous speed up”?

Be aware that while it may be that having larger, more centralized Python files may open more avenues to optimization, you still for the most part would still be running the same amount of Python logic.

In your game’s situation, it might be that piling all your code into one file may end up making the code a lot messier while providing little speed benefit, it may not be worth it.

Premature optimization the root of all evil:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

One of Python’s main strengths is readability so take advantage of it.

I don’t see the real benefit of your character setup as hard to do as it might be. For robotics it has way too many joints and solving is just overly complex. For games you would just use keyframe animation with better results.

Reminds me of something I made in HL2 engine years ago. I actually replicated a working safe with the cogs and turn dial input using complex physics setup. It was a bit glitchy, used so much resources, was big and bulky because physics couldn’t handle small details, but it was essentially a working safe you could open with turn dial and combination. But it has no purpose. HL2 wasn’t meant for this and I couldn’t see much relevance to other peoples projects. You could just replicate the safe mechanics with couple logic entities (source has a certain kind of I/O system for it’s objects aka “entities”) and skip the whole lot of problems altogether.

Many of your posts seem pretty theoretical and marginal but still it seems you don’t have the real technical knowledge to be talking about these things. Perhaps you should focus on either making your games within BGE boundaries or grow your expertise to be able to actually discuss expanding BGE boundaries rather than just get constantly tangled up with them. I say it meaning all well :slight_smile:

My rig, can have any character dragged and dropped in,

Each 6d0f Solver represents a bone, and the armatures target them,

I have a project that progresses as I learn more, the torque rig / is just a piece of the puzzle

Right now I have -

Modular robotics systems - (no 6dof) - pass data using hierarchy (find root, do childrenList = root.childrenRecursive) see attached file

Modular puzzle systems - No 6dof - Pass data using rays and “face terminals” linked to properties

Torque Rig- Walks using torque and forces - http://www.pasteall.org/blend/25078 This is where I need help - Can the community try and improve it? If there is anything that does not make sense just pm me?

this is all going to add up to a game but I need the community to tell me what is smart, what is not,
and what should be redone.

The game is about 70% done as far as “Base” coding goes. however the modular components still need to be built, and a in game level designer is also on my list of things to do.

One issue I have is when a dynamic is parented as a child, and you remove the parent the dynamics can not be restored, so instead I have it parent the 1st frame, allowing for disassembly, but this will be annoying eventually.


Powerandtargetpassing.blend (1.22 MB)