NikiTo said:
Link?

Where do you live? The moon? :D

NikiTo said:
If they buy your GI, they could tell you - it works great, goodbye, take the money and get lost.

I try to make it that finished. Because otherwise nobody would buy anything that depends on maintenance from a single guy. Too risky. https://en.wikipedia.org/wiki/Bus_factor​

NikiTo said:
My boring CV

You could start work on AI while still improving CV further.

But i stick at my boring geometry processing as well until finally done. :(

Calin said:
You need units to understand the space they`re in. You need an upgraded form of LOS, which probably is also what you`re saying. As for the cost in terms of CPU on a 3d terrain you have to do CD checks for every tile, which I think is expensive even with an optimization tree.

LOS = line of sight? Yes, i mean it. A single ray does just that and is much faster than a whole framebuffer would be.
That's no problem, but detecting all obstacles, options to take cover, find holes to shoot through, etc is. A small framebuffer could help here. Maybe still use RT but update only few pixels of this frambuffer. After a second the NPC / Unit would have a better visual sense of the scene.
But then the AI system also needs to process each pixel of those framebuffers. It seems a waste to have a computer vision algorithm in a game, although we already have the data that defines that scene.
It will remain better to use that scene data directly. NPC just querying nearby objects, and memorizing them for motion planning makes most sense.

CD = collison detection? You are worried sensing the scene for AI would be expensive?
I don't think so. You can timeslice this. Updating just few units per frame, etc. Physics engines can simulate thousands of bodies, which gives impression of how fast this stuff is.

I don't know from experience, because i always had smaller games with small number of characters in mind.

JoeJ said:
You could start work on AI while still improving CV further. But i stick at my boring geometry processing as well until finally done. :(

I started something, i want to finish it. Never finished nothing.
And my AI is on the CPU and my CV is on the GPU, i need a huge mental switch. I am bad at switching.

Finish your current GI too. Just faster.

Anyways, world is ending -

CD checks for every tile

I`m thinking in RPG/RTS terms where there is a corespondence/overlapping between terrain mesh vertex spacing and walking path nodes. The terrain is a 3d mesh so the collision detection is with a 3d mesh.

Calin said:
The terrain is a 3d mesh so the collision detection is with a 3d mesh.

If you use heightmap it's technically 2D even with 3D physics. No need for acceleration structure, just a simple lookup. Fast as hell. Mesh resolution does not matter at all. All physics engines support this.

JoeJ how big is your setup for this? I`m trying to get a sense on the scale of what you`re doing.

Setup for what? The ragdoll? I did this only within a typical physics test environment (like stacks of rigid bodies), so no game level or something.

Setup for what? The ragdoll?

All your custom code, stuff that does not come in the Newton package

Newton has a very flexible custom joint system. Instead of offering basic joints like ball and socket or hinge, it allows to implement this yourself. So you can set up your joint limits with custom callback code, e.g. to model a cone limit.
And you can also add motors which you control by setting target acceleration. Additionally you can set the max force / or torque such motor is allowed to generate to achieve this target.
Newton then solves for torques and forces. The results are very accurate, the joints are stiff and exact. Meanwhile there is almost no error left - in my video the joints were much softer than they are now.

And that's what Newton gives me. The rest (all that i talked about here) is my work. Starts with creating rigid bodies for each limb, and connecting them with joints so you get a ragdoll.

Meanwhile Newton has a new WIP feature for robotics, walking ragdolls etc. I have not used it yet. But IIRC it works by adding a virtual joint to the end effectors (e.g. hands and feet). Then you can controll those limbs by pulling the virtual effector target.
The solver solves for the full pose and joint forces, and it cares for balancing as well. No need here to use motors or calculate target joint accelerations. So this should be very easy to use in comparison to my approach, but it is still complex to learn and setup i expect.

Other physics engines also have similar functionality. Havok has (or had) ragdoll animation system, PhysX has accurate robotic joints now.
Personally i tried ODE, my own, Havok, and Bullet. Havok was quite good, but you can not expect so much accuracy from any of those. Natural Motion uses it's own solver to get joint torques, for example.
Newton blew me away. I expected nothing from a small engine made from one guy. But contrary to the others, it really works. Accurate, support for big mass ratios, flexible and fast. Has no soft bodies and cloth yet, though.

No matter what, what you need in any case is hierarchical skeleton data structure. The same thing we use for animation, basically a tree of transform nodes, using matrices etc. That's already quite some stuff to learn, if you never did yet.

related to using physical animation for `motion pictures` it would probably have limited use. The only area I can think of is for depicting agumented robotic suits like those from Matrix or Alien or for proper robots. Movies today use ray-tracing to render robots and the result looks good in a still picture, however the movement is not realistic. Using physics driven rag dolls to play as humans in a movie is not interesting as long as you can have real (human) actors to do the work.