koobas.hobune.stream
How do you create a continuous physics simulation in Unity?
So I want to make a game with planets (and other celestial objects) orbiting stars (and other stuff).
I want to be able to predict the path of an object in the future and display where it is going to move. I know that the 'n-body problem' is unsolved, so only small objects that won't exert any force of gravity will be actually move - all other objects will have fixed positions.
So basically the force (and therefore the acceleration) of any of my moving objects will be a function of position. But now I want to predict their paths. I want to do this with calculus, so that I can get an exact value for an object's position at any given time, without making lots of expensive calculations.
However, since Unity does not have built in functionality for this kind of simulation, I am going to have to set the force on the moving objects each frame in FixedUpdate() based on their masses and positions relative to the gravity-exerting stars. This means there will always be a constant force on an object throughout a single Physics Time-step. Therefore, my calculation that predicts the position of the object at any given time using calculus will not be accurate because it assumes a continuous change of force based on continuous movement.
Is the only solution to essentially create my own physics system that uses calculus to work with continuous gravitational forces from the stars and use this to set the position of each moving object directly each frame?
/*Side Note: I was also thinking about other possible scenarios in the physics engine and I was wondering how this issue is solved in other cases.
Presumably Unity's physics engine sometimes has to work with forces (and torques etc.) that should change throughout a Physics Time-step. (Eg. Collisions?)
How does Unity handle this? Does it just approximate that the force would stay constant through out the Time-step and calculate what would happen with constant values of all the variables.*/
OH $$anonymous$$Y GOD!!!! FFINALLY SO$$anonymous$$EONE ELSE SHARES $$anonymous$$Y PROBLE$$anonymous$$!! I have BEEN WONDERING HOW TO CREATE A CONTINUOS FYSICS SI$$anonymous$$ULATION FOR SO LONG. I really hope some brave brvae sole has the knowledge requiered to answer this BEAUTIFULL question. PLEEEEEEESE CAN YOU PLASESSSE ANSWER THIS A$$anonymous$$AZING QUESTION PLEASE!!! :):):):):):):):):) feeling happy
Physics in Unity is implemented using the NVidia PhsyX engine. You can read all about it at http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Introduction.html, but one section you might want to note (in the "Physics vs PhysX" section) reads as follows:
"PhysX is best suited for quasi-real time interactive 3D applications where performance and scalability are more important than precision. Here "quasi-real time" means that advancing a PhysX simulation by a given time step, say 1/60 second, will take less than that amount of time on an observer's clock if the performance of the hardware platform is sufficient for the complexity of the simulation. That the PhysX SDK is more widely used in computer and video games than in scientific or engineering applications is both a cause and an effect of these design choices."
So, to answer your other question, if you want to implement a continuous system, yes you'll have to code it yourself.
Thanks very much for your answer (sorry I took so long to respond - I had an exam :) )
That's definitely an interesting read
In contrast, time in a PhysX simulation is discrete, not continuous, and it runs only 'forwards'. That is, the state of the simulated system is known only at specific instants in time, usually referred to as 'steps', and the simulation may only step forwards in time, never backwards. The state of a PhysX system in between time steps is not precisely deter$$anonymous$$ed.
I think that's the key info. It seems that PhysX is basically a bit different from real physics. I'm still not entirely sure about how 'continuous vs discrete' works in general with the engine, because it does have a feature called 'continuous collision detection'.
But yes, it looks like I'll have to make my own physics for this problem :)
