A specific setup problem

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: A specific setup problem

Postby misho » Wed Feb 15, 2017 2:38 am

Hi Julio!

I assume you got your system going and are now back on the dev track :mrgreen:

So, back to the topic on hand - have you had a chance to put together a tornado/coriolis demo?

Thanks!
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: A specific setup problem

Postby Julio Jerez » Wed Feb 15, 2017 12:49 pm

oh wow, this has going for almost a year, I will try to do it this weekend.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A specific setup problem

Postby misho » Wed Feb 15, 2017 12:55 pm

Excellent, thanks Julio! I know you have a lot on your plate, but if it is something relatively simple, I'd love to see how it is done.
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: A specific setup problem

Postby misho » Mon Jul 03, 2017 4:27 pm

misho wrote:Hi Julio,

I'm hoping you'll have time to put together a Tornado example this weekend :mrgreen:

Along the same lines, if you remember, a while ago we also spoke about implementing a method for applying a force to a body on a point other than its centre of gravity, something similar to a method already in Newton Dynamics:

Code: Select all
void NewtonBodyAddImpulse( const NewtonBody* bodyPtr, const dFloat* pointDeltaVeloc, const dFloat* pointPosit)


This function forces a point on a body to achieve the specified instantaneous velocity. pointDeltaVeloc is the desired increase in velocity at point pointPosit.

Any chance you can take a look into implementing this as well?

thanks,
Misho


Hi julio,

This is now about six months old... :mrgreen:

You were talking about addressing two issues: A coriolis force demo scene (tornadoes),

and,

a force-to-body-point (instead of on body cg) function

Any chance of this going in a pipeline anytime soon? If I had to choose, I'd like to see force-to-body-point function :wink:

thanks,
Misho
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: A specific setup problem

Postby Julio Jerez » Wed Jul 05, 2017 1:51 pm

Oh yes, Misho, I am so sorry about that.
let us do this I am about to close newton 3.14 and start 3.15 which will focus on three things.

1-It will recreate all project and all project will have the double config (done)
2-parallel solver for many cores CPUs
3-I will add the smart self balancing character
4-complete the particle system
5-eleborate more the vehicle system.

The part that I stop there demo was gravity tornado demo was because has no complete the particle system, I can of course do this with rigid bodies, but it will no be too impressive because rigid body are too expensive for that.
here is where the lien 2 of the list is important, because I will refactored the solver to use a new algorithm base on least constrained acceleration that allowed for joint set be resolve in parallel without having to reorganize then in batches, so that will let me do the demo with rigid bodies even if I do no have the particle.
Her is where I will use the tornado demos to show up the improvements.

is that ok?
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A specific setup problem

Postby misho » Wed Jul 05, 2017 2:45 pm

Julio Jerez wrote:Oh yes, Misho, I am so sorry about that.
let us do this I am about to close newton 3.14 and start 3.15 which will focus on three things.

1-It will recreate all project and all project will have the double config (done)
2-parallel solver for many cores CPUs
3-I will add the smart self balancing character
4-complete the particle system
5-eleborate more the vehicle system.

The part that I stop there demo was gravity tornado demo was because has no complete the particle system, I can of course do this with rigid bodies, but it will no be too impressive because rigid body are too expensive for that.
here is where the lien 2 of the list is important, because I will refactored the solver to use a new algorithm base on least constrained acceleration that allowed for joint set be resolve in parallel without having to reorganize then in batches, so that will let me do the demo with rigid bodies even if I do no have the particle.
Her is where I will use the tornado demos to show up the improvements.

is that ok?


No problem, and that's perfect, thanks! Like I was saying, the more important feature would be #2 on my list, Force on arbitrary point on the body, not on CG (which would introduce momentum). If you can squeeze that in, that would be great!

Misho
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: A specific setup problem

Postby Julio Jerez » Wed Jul 05, 2017 3:17 pm

regard point 2.
about ten year ago a made a prediction that the future of discrete GPUs was a dead end, and ove the year that prediction seem to fail.
now I believe my prediction was too much ahead of it time.

at the moment if you look at any computer for a mobile phone to a game consoles to a PC, the all have from four to 8 cores. xbox one and PS4 both have eight cores,
and the use the same CPU that PC are using.

now AMD and Intel announce 8, 6, 10, 16 cores CPU hyper treaded, which means 32 or more hardware thread.
an AMD ryzen 1700, cost 300 bucks, and has 20 Mgbyte of cache, 8 cores hyepreadeds. and the also come with the GPU builds in.
these CPU with some tweak are the same CPU use on xbox and PS4.

My PC, has two HDMI port that if I remove the GPU they provide the same graphics that using the expansive and power hungry GPU.

to me this mean that Discrete GPU are on the last gas, I am now predicting that with the silicon dice shrinking to 14 nanometer as we have now, we already have GPU build in on the CPU that can rival descrete GPUs, and bothe Intel and AMD say they are moving to 10 nanometers, at the point a descrete GPU will be far slower that a build in GPU, and that will be the dead of Discrete GPU.

The reason for this is that, descrete GPU communicate with the CPU using DMA and we already see how CPU come with 30 and 40 PCI ports (DMA) with is just ridicules, so what is going to happen is that with more silicon, the GPU and the CPU will unified an will no need DMA channels for internal communication, only for external memory and a discrete GPU can no do that.

on top of that we have 8 core becoming eh entry level, and Intel say that their top 18 cores CPU is capable of 1 teraflops, which mean a mid level is about 500 gigaflops.

The mean we do no really need GPU physics, what we need is parallel algorithm, so I am back in the horse working on a parallel solver.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A specific setup problem

Postby misho » Wed Jul 05, 2017 4:28 pm

What you wrote is WAY over my head :mrgreen: But I get it on some level...

I think you were talking about point #2 on YOUR list...

I was talking about point #2 on MY list :wink: : A "simple" Force-to-point on a body function (instead of force to body CG point). I think that would be a simple task, as you already have something similar:

Code: Select all
void NewtonBodyAddImpulse( const NewtonBody* bodyPtr, const dFloat* pointDeltaVeloc, const dFloat* pointPosit)


So basically something like:

Code: Select all
void NewtonBodyAddForceAtPoint( const NewtonBody* bodyPtr, const dFloat* pointForce, const dFloat* pointPosit)


Wouldn't that be simple to add?
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: A specific setup problem

Postby JoeJ » Wed Jul 05, 2017 4:40 pm

Both AMD and NV prepare to build modular GPUs where each module has a smaller number of cores. The modules are attached to some interposer which is much faster for communication than a mainboard.
Probably we will see CPU and GPU modules together, get higher yields, cheaper hardware and keep Moores law alive this way.

I don't think GPUs will or should die soon. Whenever you can parallelize a inner loop they are so much better than a CPU. CPU Simd can't compete with this. We would need a drastic change in CPU architecture with much more registers, an additional small cache level to serve as LDS, and high latency but large bandwidth access to memory.

I guess it's more likely GPUs (or just APIs) will evolve faster and bring proper async compute to GPUs so we can saturate them properly. AMD can reserve a small number of compute units to acclerate audio processing. Unfortunately something like this is not properly exposed by those so called modern APIs - i would get a 50% speed up... :roll:

At least we can do almost all graphics work on GPU now if we want so.
So you get more CPU time for particles and soft bodies :)
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: A specific setup problem

Postby JoeJ » Wed Jul 05, 2017 4:45 pm

misho wrote:So basically something like:

Code: Select all
void NewtonBodyAddForceAtPoint( const NewtonBody* bodyPtr, const dFloat* pointForce, const dFloat* pointPosit)



Wouldn't that be simple to add?


See at the bottom: http://newtondynamics.com/wiki/index.ph ... _engine%3F
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: A specific setup problem

Postby Julio Jerez » Wed Jul 05, 2017 4:47 pm

I do not want to add this kind of thing that can always be done but using other functions.
I believe there are utility function to do that already, if no I will check tonigh and add one.

The reason there is NewtonBodyAddImpulse si that the is a very, very different function than adding a force an da torque.

the at the same with they are applied to a single insulated body, but when the body is colliding or jointed to other bodies, the NewtonBodyAddImpulse take the linked bodies into consideration.

imagine you have to ball each of 1 kilogram connected by a rigid joint.

if you apply a force of one newton to one body, the force is applied to that body.
if you apply an impulse to one body, and there impulse is apply to a single body, is case lot of undeniable problem because one body will change velocity so the function have to iterate to see how the impulses propagate to other bodies. NewtonBodyAddImpulse is a much complex functions.

I will see if there is and add force at a point in the utility.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A specific setup problem

Postby Julio Jerez » Wed Jul 05, 2017 5:06 pm

JoeJ wrote:I don't think GPUs will or should die soon. Whenever you can parallelize a inner loop they are so much better than a CPU. CPU Simd can't compete with this. We would need a drastic change in CPU architecture with much more registers, an additional small cache level to serve as LDS, and high latency but large bandwidth access to memory.


I do not think so, cpu are far superior in every way than GPU, branch prediction, super scalar, pipe lined, way associative cache lines, and goes on an on.
the reason GPU are faster that CPU is because they are so many, once that advantage vanishes, GPU can't come even close to a CPU for general high performance computing, you can have a ratio of 4 GPU cores to one CPU core in order to start seeing the GPU breaking away for a CPU.
The second reason GPUs are better at rendering is that GPUs has dedicated hardware for doing thing like rasterization, texture addressing and texture interpolation. which why Intel failed doing the Larrabee. once you do not use the CPU for rendering and you have a number of independent cores in the CPU, then GPUs no longer have an advantage.
take for example the case of calculation two contact pair, one pair is two spheres and the other is a sphere and a box. This is a nightmare to do efficiently on a GPU, but is trivial if two cores can run independent of each other in a CPU.

I am not saying GPU will go away, I am saying that discrete GPUs will go away and integrated graphic will take their place.
if you buy a laptop today, you will be hard pressed to find one with a discrete GPU, they almost all come with GPU integrated on CPU. and my point is that as technology moves from 14 nanometer, to 12 or 10 then the cost of making meanstream GPUs can not be justified, so at some point they will move on to the PC as well. This is already the case for all game consoles, phones, tables and laptops. the only thing remaining are high end PCs.

My prediction is that discrete GPUs in a year or two, will go the way beeper or tubes TV went.
I know I have been wrong many time, but this is my justification to spend time on a parallel version of newton made for CPU instead of try to bend up backward organizing data to run on GPU shapers or kerners.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A specific setup problem

Postby misho » Wed Jul 05, 2017 7:26 pm



Thank you sir! That is exactly it! Although - in the wiki writeup, I simply do not get the helicopter example? It says:

Say you have an helicopter in real life, every one knows that to push the helicopter forward we need thrusters on each side


That is NOT how helicopter goes forward. Helicopter tilts its main rotor downward (called "cyclic") to move forward. To control height, a control called "collective" is used. Finally, to keep helicopter straight and to counter the torque of the main rotor, pedals are used to control the tail rotor.

Back to the topic, the pseudocode offered here:

Code: Select all
AddGlobalForce (Force, Point)
{
   R = Point / BodyMatrix.Position;
   Torque = CrossProduct (R, Force);
   NewtonAddForce (Force)
   NewtonAddTorque (Torque)
}


...simply breaks down the offset force into 2 components: Force at a CG, and momentum created by the offset force. That is fine, I understand that perfectly, and when I originally asked for this functionality, I was going to implement it just like the above pseudocode.

However, I remember Julio specifically saying that is NOT how it should be done, and that he will implement it "correctly". I also remember you (JoeJ) arguing with Julio that this IS the correct and only way to implement it.

I can go and dig for the post in question if you want to see it... after that argument, I've been waiting for Julio to implement it "correctly", but if that implementation is simple breakdown of force and moment, I can definitely handle that, as was my original intent :wink:

So - which is it? :mrgreen:
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

Re: A specific setup problem

Postby Julio Jerez » Wed Jul 05, 2017 7:41 pm

misho wrote:....However, I remember Julio specifically saying that is NOT how it should be done, and that he will implement it "correctly". I also remember you (JoeJ) arguing with Julio that this IS the correct and only way to implement it.

if I said that, I was wrong, there are different way to do the same, and as long as you get the same torque and the same force it all you be fine.
I forgot about that heli help, do no worry about the helic, it is just a sample of how to apply forces at a point.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A specific setup problem

Postby misho » Wed Jul 05, 2017 7:53 pm

Julio Jerez wrote:if I said that, I was wrong, there are different way to do the same, and as long as you get the same torque and the same force it all you be fine.
I forgot about that heli help, do no worry about the helic, it is just a sample of how to apply forces at a point.


No problem Julio! just for reference, I did track that thread down here: (More than a year ago now)

viewtopic.php?f=9&t=8906&hilit=force+at+point+misho&start=60

There is a lovely had-drawn diagram I did a few posts before that :mrgreen:

Your first post and subsequent posts by JoeJ and me argue back and forth on the approach. Basically, you were saying "don't use torque, I'll write a function that avoids using torque", and JoeJ was saying "At some point, you WILL have to use torque". :wink:

So anyway - I will use the pseudocode that JoeJ provided a year ago AND again a few posts back (again, thank you sir!)
Misho Katulic
CTO, FSX SpacePort
TerraBuilder
www.terrabuilder.com
misho
 
Posts: 673
Joined: Tue May 04, 2010 10:13 am

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 13 guests

cron