Start work on full body inverse kinematic animation system

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Wed Jan 02, 2019 7:09 pm

JoeJ wrote:BVH is currently blackboxed, but if you only need to trace rays it might work.
I don't know if you could intersect a box against the BVH, but i guess not.

but that has been the story with nvidia and their dubious dishonest tactics, it is not?
They do that kind of shenanigans all the time. Speaking of nvidia they are in the news again with another player they over promise, and not surprising the screw up as usual.
https://hothardware.com/news/nvidia-fac ... -implosion
The complain say this.
[NVIDIA] made false and misleading statements to the market. NVIDIA touted its ability to monitor the cryptocurrency market and make rapid changes to its business as necessary. The Company claimed to be 'masters at managing our channel, and we understand the channel very well'.


"Based on these facts, the Company’s public statements were false and materially misleading throughout the class period. When the market learned the truth about NVIDIA, investors suffered damages," the complaint continues.

sound very much like my opinions about Nvidia does it not?

I can only imagine those poor investors salivating when Nvidea approach them promising some brand new law of economic in the from of a shader or some * like that, until they figure out it was all façade.
The next shoe to drop is the NVidia AI driving cars, it will only take people start getting into accidents possible even dying on those Nvidia powered self driving car, and when the layers find out that the thing in common is Nvidia GPU that will probably be the last draw that will break the camel back, and some action will reign in nvidia unethical and dishonest practices.

The problem with nvidea is that they are not honest brokers, they do not play by the same law honest developer play by, they keep making new rules and real the real word is not the same as video games.
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby JoeJ » Thu Jan 03, 2019 2:12 am

'masters at managing our channel, and we understand the channel very well'

Haha, yeah, that's exactly that NV thing. You could just replace 'channel' with raytracing here.
The problem i see is the fixed function RT core - limited to classic RT tied to static triangles, but no options for data structures that combine tree, LOD and geometry (like voxels or the sample hierarchy that i'm using).
On the long run they do more harm than good on progress with such a restriction. Improving GPGPU so raytracing can be implemented efficiently and tailored to specific needs would have been better. And as it shows, older TitanV (already has improved compute sheduling options but no RT cores) is not much slower than RTX. Fixed function is not justified at all.

But the harm has been done, other vendors will likely follow and it will take much more years to get rid of those restrictions than it would have taken to catch up with compute. (guess 10 vs 2 years)

It's a step back, but nobody agrees with me so i must be wrong :) At least NVs dominance is secured.

I've resent the docs...
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Thu Jan 03, 2019 7:28 am

I totally agree, a fix function is a backwork thinking.
I can see the appeal of having dedicated hardware for cooling the rays which if I am not wrong is as what they are doing and try to corner the market with.
But that just Nvidia trying to bully the major api and hardware vendor, the same way they try to redefine a lane of a Simd architecture by calling it cuda core.

If my intuition is not wrong, my guess is that this is what they are doing.

1 they insert a new stage unit in the pipe line, similar the the triangle rasterization, geometry, compute, etc.
2 the draw a regular grid using a boxer technique over the scene similar to mind craft. This will be akin to take the screen a divide in regular size blocks for rasterization.
3 the for each cube, you can use the Simd to trace the cube in group, getting a cooling of the long rays.
4 for rays the internet the cube are clipped creation a new set of shorter rays.
5 the shorter ray as re the traced again the infinite set of implicit triangles inter section the boxes.
6 this hits are recurtion level zero.

7 if recursion level is not reached,
The regroup all the new intersection and start a new trace of the same scene again repeating the same process. Until the max recursion level is reached.

8 some predication is apply to zero the rays that vanish,

All that can be done with any special hardware, but so triangle rasterization, it will just be slower because of the nature of the operation.

My guess is that what Nvidia did, been a hardware company is the the dedicated special hardware just for that, try to corner the market into a new standard and set all other developer back for 20 years just because the position they are been a hardware company.

I hope it do not catches up, but in the world that we live not every thing is fair, and my guess that is quite possible that amd follows sue and do the same giving it a different name. The speed gain by dedicated hardware can't be match by compute units,
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby JoeJ » Thu Jan 03, 2019 12:55 pm

phew... feels good to hear at least one man shares my thoughts. I already started thinking i must be just wrong. Thanks for this consolidation! :mrgreen:

I suspect it to work similar, but i do think they use a proper MBVH not a regular grid. Maybe they cache a larger branch of BVH into fast on chip memory and then process all rays that intersect the parent bbox, and after some time remove terminated rays and compact.
That's how i would do it at least. I doubt all that binning and work distribution logic is fixed function but just compute, and only the intersection stuff is FF then. (They also need to sort hits locally to the same material shader... would become pretty complex for FF i guess)

However, we'll surely never know :roll:
There's a bit of hope AMD / Intel would not follow the fixed function path, but i doubt it.
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Fri Jan 04, 2019 12:58 pm

now this star to be ridiculous.

notice that these towers aren't the type of demo that the moment any piece is touched, the whole structure collapses, the is all legitimately simulated. :mrgreen:
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby JoeJ » Fri Jan 04, 2019 4:55 pm

When a was a kid i looked at the Asteroids cover from the Atari cartridge and i knew: Once those colorful boxes on screen will look like this cover, and all will be as if it would be real.

We are very close to this, guys! :mrgreen: :mrgreen: :mrgreen:
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Fri Jan 04, 2019 6:55 pm

Joe, you think those are lot of boxed, I think Dave lose all his marble with this one
https://www.youtube.com/watch?v=stExKafndWE

go to 17, 30000 stable tower 300 level high at about 1 fps.
even rendering this kind of scene is hard in real time without using tricks like instances.

then he ratchet it up to 100,000 thousand, not sure what the shows but it works at iterative time :shock: :D :o :lol: :mrgreen: with everything put together.
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby Dave Gravel » Fri Jan 04, 2019 8:56 pm

I don't use object instancing for now, Surely later.
Currently my only trick, In my system I compare the created object with the last created object and if it use the same properties the system make a clone object.
On this way all box in the tower is rendered from the same gl buffer copy.
When the parent object have clone childrens it can't be deleted from the normal method.
The parent is placed in a special list for become deleted later.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 667
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: Start work on full body inverse kinematic animation syst

Postby JoeJ » Sat Jan 05, 2019 1:30 pm

Julio Jerez wrote:then he ratchet it up to 100,000 thousand, not sure what the shows but it works at iterative time :shock: :D :o :lol: :mrgreen: with everything put together.


The most impressive here is that is is stable. I remember when i tried Bullet, one box on top of another already jittered quite a lot. (Yes, just two boxes :) )
That was shortly before i came here, to be fair - they may have improved.

Dave Gravel wrote:On this way all box in the tower is rendered from the same gl buffer copy.

I tried to render many boxes when moving to Vulkan and wanted each box to have its own shape, so a huge vertex buffer and nothing shared.
I also had a huge buffer with a million matrices one for each box. (So no uniforms to constant memory as usual.)
In the VS, i used the w position component as integer index for the matrices, and each thread did load the proper matrix to transform the vertex into thread registers. (not scalar registers shared for the whole wavefront as usual.)

It worked quite well, can't remember but i think 1 million boxes had 80 fps maybe.
The whole scene was one drawcall, so there should be no difference between VK and GL here.
Updating the matrices each frame was the bottleneck.
For small objects with less vertices than threads this might be useful, but i think instances also can utilize all threads in that case and may be faster.
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Start work on full body inverse kinematic animation syst

Postby Dave Gravel » Sat Jan 05, 2019 5:34 pm

I have some parts write in vulkan for my engine.
I have already test compute shader, geometry shader, simple shapes, object instancing.
I have test big uniforms,matrixs buffer too, I get nice result but my knowledge is better with GL.
My current vulkan code use newton with all default newton shapes, I let's it on pause for now when I get my engine more ready to use in GL I can try to resume my work with vulkan.

With vulkan some parts is very logical and easy to use, but some other parts coming quickly complex when you try to get some more features.
With vulkan you need to think a lot more on how you do the engine logic and think to all barriers logic too.
You need to think differently for some features, Because if you try to use it like GL you can't get more that what GL already give to you.
You can surely see a big different from a engine totally write in vulkan with vulkan logic, If you compare it with a engine GL + Vulkan trying to reproduce all GL logic under vulkan.
I have seen too, Many old app that I have build with vulkan crash with newer vulkan dll.
I need to reopen the project and recompile the project and it work ok after.
In general all my old GL app running without need to rebuild it.
It's not a very big problem, I just find it a bit strange I don't have search more to find what the cause of it.

I love what I have test with vulkan the only problem I find it very long to code and it's not easy to progress, I need to learn more about.
Many times when I pause something and when I comeback later I start to understand it better without any efforts hehe.

In my little engine the box for the tower is a editor object.
This object class have a lot properties for rendering, newton + material, visual + update for animation or script execution and it is implemented as a class in lua too.
My idea in my engine is to use this object like a configuration object only.
In the editor it give a good visual for edit the scene or make quick demos.
Later when the engine compile the final release script it can use this editor object just for configure the real optimized objects for render.

Thanks for sharing your test infos.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 667
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Sat Jan 05, 2019 6:19 pm

hey Joe and Dave now that the amort all area of is multithreaded, loa leve collsion, solve, integreation and broad Phase, and even listener in I run teh profile is a scene with 10 ten thousand bodies or more, you are not going to believe what become teh bother neck. Sorting!!!

parallelizing quick source, in experience has never yield better performance that the single treaded sequential version. so I wrote a multithreaded dgRadixSort version.

Radix sort is easies to parallelize than quick sort by because if far the inner loop is far more expensive that quick sort plus does no work in place, is never faster that teh play quick sort.

that not longer the case with you are talking of tenth of thousand of elements to sort. at that point the theory dominates, and teh alrgirith with lowe time compklexity wins. In this case quick sort is still teh winner so I am try a paraller quick source now.

I always though that teh reason why paraller versions of sorting aren't faster than the single threaded was because sorting is about memory bandwidth, but that's onel true if the cpu only has one memory channel. these day CPU have many memory channels, so the memory band width of a multicore cpu is higher that that of a single core, because there is a chance that some date can be fetch form diffrent channel form different cores.

anyway the point is that now the bottle neck for very high core count of bodies and joints is not the solve is sorting that the joints.
It is not that it will make a major difference but a bottle neck is a bottle neck, so if whe can make that scalable with core count that the teh engine because scalable with cores count overall.

if Dave can get that kind of performance with 8 cores hyper threaded imagine what 16 or 32 cores can do. because of that I will make teh Max thread count to 64 :shock: :D . yikes!!!!
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Mon Jan 07, 2019 11:26 am

on a lighter note, I did some work on the fbx loader to get the gorund work for the animation.
The was tree phases:

1-Get the mesh loader to ngd (this was partially done but that is completed)
2-Get the skin mesh loader(done now)
3-Get the animation curve loader (lot of problem here)

I did no expect to have so many problem loader the animation, for some reason the animation do no math the model in some nodes. so IU have to do a degug section on that.

one of the probkems that I had was that the model I have the animation and the model have different cordinate system, that took me two days of debugging because they work on max but when I load them is does not. Now I think I figured out what is happeing, they in fact do not match, what happen is the max does a match animation proccess, if I just load the animated skeleton, as a separate mesh and I also import the animation onto the skin mesh, the imported model work fine but the animated skeleton is orienetd differently.

I need to figure out how to do that using the FBX SDK, but to take a shortcut, I simple exported the animated mesh with the model.
now at least they match.
There are still lot of other problems, for example only one leg seems right, but the arms and left leg is wrong, so I have to debug that.

I never expected so much work, but I has almost nothing, and I under estimated it.
and all this is before we start the inverse kinematics. but anyway, what has to be done has to be done.
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby JoeJ » Mon Jan 07, 2019 12:36 pm

3-Get the animation curve loader (lot of problem here)


I am surprised - is it common to import curves and not just final quaternion or euler keys?
Maybe you have some export options to make it less error prone this way.

I remember similar problems. Once i've had to figure out which euler order was used for each joint :(
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

Re: Start work on full body inverse kinematic animation syst

Postby Julio Jerez » Mon Jan 07, 2019 12:52 pm

You are going to be suprice, but animationation packages do not use quatertion or matrices for key frames, the use Euler angles.

That make sense because the component of a quart aren't dependent variables while Euler angles are.
Entire quart are independent but for an animation that's not intuitive. Quay are good for playback but not for editing.
Euler has the gimbal problem, but that's really does not happens when doing interactive work. Beside thats not different than a position losing one dof

The first problem was that I was reading the keys, but they are stores as Bezier curve and each curve has different set of control points. It is quite involved.

But at the end I found a two functions.
Evaluate(t) and evaluatekey(t)

That allow for sampling the animation at any arbitrary point on the time line, rather than second guessing the internals of the format.
So that was a bit of progress. But there is still work to do.
Julio Jerez
Moderator
Moderator
 
Posts: 10718
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Start work on full body inverse kinematic animation syst

Postby JoeJ » Mon Jan 07, 2019 1:25 pm

Julio Jerez wrote:You are going to be suprice, but animationation packages do not use quatertion or matrices for key frames, the use Euler angles.

I know, but for export there is often an option to convert to quat at a given interval. (Havok plug ins did this for example)
However you can do this yourself now using those functions.
User avatar
JoeJ
 
Posts: 1147
Joined: Tue Dec 21, 2010 6:18 pm

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests