Ancestors

Toot

Written by velox_vulnus@lemmy.ml on 2024-10-18 at 12:02

How to deal with broken collision detection on a deterministic physics engine?

https://lemmy.ml/post/21528048

=> More informations about this toot | More toots from velox_vulnus@lemmy.ml

Descendants

Written by CarbonScored [any] on 2024-10-18 at 12:20

If I understand this right, you’re looking for Continuous Collision Detection

i.e. rather than calculating collision by looking at the intersection of objects in every frame, instead calculate collision by drawing out the path the object will go, and looking for collision along it.

=> More informations about this toot | More toots from CarbonScored@hexbear.net

Written by velox_vulnus@lemmy.ml on 2024-10-21 at 18:45

Say, if I were to use a fixed gravity, and ensure that the speed is slow enough, should I have to pad numbers? I am worried about precision inconsistencies in different browser.

=> More informations about this toot | More toots from velox_vulnus@lemmy.ml

Written by deegeese@sopuli.xyz on 2024-10-18 at 16:37

Is this for a game where it needs to be fast, or for science where it needs to be accurate?

Is the gravity constant, or does it vary as the objects move closer together?

=> More informations about this toot | More toots from deegeese@sopuli.xyz

Written by velox_vulnus@lemmy.ml on 2024-10-18 at 17:18

Accuracy does not really matter here - it should be fast. But there has to be no compromise on collision. Gravity is constant for now, but it may change - not a strong requirement for now.

=> More informations about this toot | More toots from velox_vulnus@lemmy.ml

Written by deegeese@sopuli.xyz on 2024-10-18 at 17:33

Compute the bounding volumes of the objects during the step. If the bounding volumes intersect, it’s a possible collision.

You can then use a root finder such as bisection to determine if, and at what position and instant the objects collide. This is slow so you only want to do it for pruned object pairs.

If gravity varies during the simulation, you would need to use a dynamic time step and the problem is a lot harder.

=> More informations about this toot | More toots from deegeese@sopuli.xyz

Written by Breve@pawb.social on 2024-10-18 at 17:07

I think you need to be more explicit about what you mean by “not dependent on time”. Setting t = 1 for that formula doesn’t eliminate time, it means you’re advancing time by 1 unit for every iteration of the formula defined by units used to measure the velocity and acceleration (i.e. if v and u are measured in meters/second and a is meters/second^2 then t = 1 means you are modelling 1 second passing).

=> More informations about this toot | More toots from Breve@pawb.social

Written by WolfLink@sh.itjust.works on 2024-10-18 at 17:58

A few ideas:

I’m not sure what you mean about decimal point handling - that’s always going on (unless you are trying to work with purely integer variable? Even then, there’s rounding involved whenever you need to divide…)

I’m also not sure what you mean by the engine becoming “nondeterministic”.

=> More informations about this toot | More toots from WolfLink@sh.itjust.works

Written by velox_vulnus@lemmy.ml on 2024-10-18 at 18:21

Here’s what I’m trying to implement - a plinkoo game. Disclaimer: I’m not into, or promote gambling, just wanted to use my knowledge of Monte-Carlo simulation on a toy project to figure out the pre-computed starting points, because client-side physics engine can be spoofed.

Now, this engine has to be “deterministic” at all cost, even at the cost of frame rates. Now, in my current scenario, gravity is fixed, however, the issue with faster gravity is that the object just phases through the obstacles.

This is why I was looking for a better solution, at least something that isn’t CPU-bound, because as I create more more object, it hogs the memory, although not a lot, but it would hurt mobile devices.

So far, I’ve considered using VanJS to avoid the ReactJS virtual DOM overhead.

=> More informations about this toot | More toots from velox_vulnus@lemmy.ml

Written by WolfLink@sh.itjust.works on 2024-10-18 at 23:54

So here’s the thing that confuses me about your use of the word “deterministic”: even if you have balls phasing through collision objects, the game will still be deterministic in the sense that the same initial conditions for the ball will result in the same final location of the ball.

Ways that it can become non-deterministic are usually either intentional randomness, race conditions from multithreading, or using a variable time delta for your update cycle, such that the time delta is dependent on the operating system, physical device, etc.

As long as you aren’t doing any of those things, the game will still be “deterministic”.

=> More informations about this toot | More toots from WolfLink@sh.itjust.works