I NEED HELP

[severe moon]

MY QUERY:

Is performing a gravitational calculation and referencing an objects position optimisable by spatial partitioning and applying the force vector calculated at the centre of each cell? i.e. caching vs calculation - if so when does caching the force vector become the less optimal method?

ASSUMPTION:

All gravitationally pulling objects are anchored (small objects dont exert a gravitational affect on other objects).
There may be more than one gravitational influence.

OBVIOUS TRADEOFF:

Precision and a large initial force vector "rendering" time (calculating all force vectors.

SUMMARY:

What are the pros/cons and would it be feasible/practical?

[subtle hornet]

Bro made a whole ass research report

[severe moon]

i just need answers dawg

[severe moon]

@tribal remnant

[tribal remnant]

NVM I thought it was ranking bye

[severe moon]

BRO

[neat veldt]

You could precompute the entire grid ig?

I don’t think you’d need this in any reasonable case tho

There’s not a lot of heavy operations on each calculation

And you’d have to have a pretty tight grid or the error would get pretty large

[neat veldt]

^

[severe moon]

i was thinking for something like 100 gravitational bodies exterting force vectors on 100 parts

instead of performing all the calculations every iteration id just use a table containing every force vector in that region of space

(as in the average force vector after calculating each gravitational objects influence on the centre of the region) but yes you are correct it may require a tight grid

its mainly for the sake of having done it though, i could use it for a game concept

[neat veldt]

Must they all be simulated at the same time?

[severe moon]

yes for my intents and purpose

[neat veldt]

A pairing up of parallel lua and splitting the calculations across multiple frames would probably help ig?

I mean

[severe moon]

its. not. true. parallel.

[neat veldt]

You could avoid the heavy sqrt operation in magnitude because the gravitational force equation uses r^2

[neat veldt]

Parallel lua is true paralllel

Actors

[thorn mango]

actors are true parallel

[severe moon]

oof ok

[neat veldt]

Finally you’re s3

[severe moon]

ayo pyro fire come to help

[thorn mango]

what is your definition of optimal in this situation?

[severe moon]

another suggestion that was made to me is by decreasing the grid size closer to the influence of gravity

[thorn mango]

you can either have it fast and inaccurate, or slow and accurate. pick one

[severe moon]

most efficient to calculate force vector applied to 100 parts at the risk of precision loss

with 100 gravitational bodies

[neat veldt]

You’d likely need to have a few hundred thousand total objects just for a space the size of 1000 of the objects affected by gravity

[thorn mango]

efficiency is irrelevant here. you can either have it fast and inaccurate, or slow and accurate. pick one.

[severe moon]

fast and inaccurate

[neat veldt]

There’s an immaculate algorithm?

Or do you just mean not calculating every frame or something

[thorn mango]

then yea probably go with the spatial partitioning technique and sum the gravity of each cell to other cells

its not going to be super accurate but it is faster than calculating every object

[severe moon]

would it be s2 worthy 👀

if i use collection service

[neat veldt]

For just decent accuracy wouldn’t you need a huge grid

[thorn mango]

maybe idk

[neat veldt]

Or perhaps the accuracy loss is less than I expect idk

[thorn mango]

smaller cells would increase the accuracy up until the grid is infinitely small and you are calculating every object and ignoring the grid entirely.

[neat veldt]

Well yea

[severe moon]

but thats a lotta cells

[neat veldt]

No I meant that a reasonably sized grid would probably cause a decently high loss no?

Say a 1x1x1 grid size

[severe moon]

1x1x1 is pointless anyway

[neat veldt]

That would require a million indices for a 1k sized space

[thorn mango]

depends on the scale you're working with, 1x is too small

[neat veldt]

Eh

[severe moon]

i was thinking more like 50x50x50

[thorn mango]

so use a quadtree

[neat veldt]

Yea that’s what I’m saying
I’m not sure if I’m overestimating the loss

[thorn mango]

or octree

[neat veldt]

Huh

How would that help in this case

From what I can tell the gravity from a nearby point cannot be used to calculate the gravity at this point

[thorn mango]

something tells me you dont understand what quadtree/octree is for

[neat veldt]

You can’t just ignore some of the gravity influences?

[severe moon]

id use a hash table

[neat veldt]

So I don’t see how that’d be helpful in this case

[severe moon]

ik hash tables arent as specialised as trees for this job but its just as reasonable

[neat veldt]

Since the point here is to cache the previous results to prevent extra calculations

[neat veldt]

Bru come back

💔

[severe moon]

vro is tantalising us

[thorn mango]

i thought this was stillnos2's question? are you both asking now?

[neat veldt]

I’m just curious as to what you mean by octrees

I don’t believe they apply in this case

So I want to know what you’re suggesting

[severe moon]

i could also just create a region of calculations so if any object strays outside of the region is starts generating the calculations for neighbouring cells

[thorn mango]

that's what octree is for

[severe moon]

hashtables are equally as valid but just not specialised for that

hmm maybe ill try using an octree for it though

ill have a little research

though the plan seems efficient

[neat veldt]

Precalcating the region at runtime?

[severe moon]

yeah or even calculating it pre runtime could be feasible since nothing is moving idk

[thorn mango]

you also said all gravitationally pulling objects are anchored?

[severe moon]

yes

[thorn mango]

do you have any intention of moving them or creating them during runtime?

[severe moon]

no

[thorn mango]

coz i'm considering moving them

[severe moon]

that will reduce the effectiveness

[thorn mango]

how many of these objects u want

[severe moon]

i mean you can move them and store each acting vector on the region then negate the difference from that particular gravitational objects effect

i was thinking of 100

i was considering building a planetary system and having people throw parts into it

[neat veldt]

If you’re precalculating at runtime why don’t you just cache it after an object has reached that area

[severe moon]

or like fly a little rocket 😭

[neat veldt]

So you don’t calculate any area that you don’t need to before you do

[severe moon]

i think thats where octtrees come in handy

[neat veldt]

I still don’t see how octrees help for that

Splitting space in recursive chunks don’t seem helpful imo

[severe moon]

i mean you can also distributed the workload of creating the massive cache table by asking clients to perform calculations too

[sacred granite]

** You are now Level 32! **

[thorn mango]

hm, i'd still probably use an octree and calculate cell forces as you drill down.

[severe moon]

space efficiency i guess, only pass a specific chunk to client for clientside fluidity

[neat veldt]

A small cell’s force needs to be fully recalculated when a large cell is split

[thorn mango]

there's probably a way to do partial calculation

[neat veldt]

Unless you know an algorithm to calculate the gravitational force of a point given that of a nearby point?

[thorn mango]

so splitting is cheaper than iterating over every gravity object

[neat veldt]

Unless there is, octrees aren’t helpful, that’s my point

[severe moon]

i was considering culling out of range objects with minimal influence

[neat veldt]

And I don’t believe there is

Actually

Lemme think

Oh wait

[severe moon]

unless you want a huge region of space to be sent to the clientside so they have that region

[neat veldt]

If you don’t do the division you might be able to do a partial calculation

[neat veldt]

Huh?

[thorn mango]

that's not what i was talking about

[severe moon]

hmm ok

[neat veldt]

That would defeat the premise of all objects being acted at the same time

Plus you could cull those way more easily

[severe moon]

im thinking about latency purposes

if a player flies a ship through the field then they dont want to have unresponsive controls

[neat veldt]

Obviously the player’s ship’s gravity should be done by its client

[severe moon]

they want to calculate the region on their side and retransmit their position for authentication

i mean yeah actually thinking about it, hash tables are the way to go

fuck octrees we dont want them here

[neat veldt]

If you find a algorithm for partial gforce calculation then octrees are much better

Especially if you’re considering a much larger area

[severe moon]

yeah

[neat veldt]

I was assuming you were talking about a decently fixed area with no player-controlled stuff

[thorn mango]

this is probably how you would do it partially, so you'd only have to know nearby gravity wells that have enough influence to noticeably change the subdivided cell's gravity direction

[severe moon]

yeah

since ^2 is used id imagine it could result in completely dead zones with no gravitational influence though

[neat veldt]

Actually tho

Other question

Are you using realistic big G

[severe moon]

no 💀

[neat veldt]

Oh lol

[severe moon]

i wasnt intending on doing that

i could do though

[neat veldt]

I was gonna say if you were gonna have realistic gravity

Then nothing would be massive or far enough for the gravity to change much

And you could just use near constants

[severe moon]

hm

hmmm

this is a mind boggle

km glad i asked for help

[neat veldt]

Actually I found this

https://youtu.be/tOlKLJ4WmSE?si=9NSLMUlaHU_ssET4

[severe moon]

yooo?

[neat veldt]

I think I see what pyro meant for octrees for unanchored simulations

Not actually sure how helpful this would be for your anchored gravitational sources

Since the contruction of the quad tree might take more time than it saves lol

The issue is that this mainly saves time via clustering, and your anchored objects obv won’t really cluster

[thorn mango]

also saves memory ;p

[neat veldt]

That’s assuming we use hashmap

If the map is spread out, the hashmap solution would become way worse

[severe moon]

unless specific regions were hashmapped

[neat veldt]

If

[sacred granite]

** You are now Level 36! **

[neat veldt]

*ig

[severe moon]

yeah quadtrees/octtrees are best for moving parts