Physics
Options
I have a room, i have a physics world created by room at start
All's good
I want to do those things with 10hz:
Take input from clients inside room (not lockstep, just as fresh as possible)(Clients update those with ~10hz also).
Do physics step with those values.
Send new positions to clients.
So what is better solution?
1)Queue that UpdateAndSend method into room's fiber
+ : no locks, just works, no new threads, scales
- : can be delayed
2)Create another fiber specially for that method and schedule there (so it will be called with exactly that delay (0.1s)
+ : can't be delayed, no new threads, scales
- : should use ReadWriteLockSlim on positions and inputs
3)Create async Task and while loop inside with use of cancellation tokens
+ : can't be delayed, no new threads, scales
- : should use ReadWriteLockSlim on positions and inputs
4)Explicit thread
+ : can't be delayed
- : not scales, should use locks, explicit thread creation,
The reason why i want to send resulting positions right after calculating physics is to not do irrelevant calculations
All's good
I want to do those things with 10hz:
Take input from clients inside room (not lockstep, just as fresh as possible)(Clients update those with ~10hz also).
Do physics step with those values.
Send new positions to clients.
So what is better solution?
1)Queue that UpdateAndSend method into room's fiber
+ : no locks, just works, no new threads, scales
- : can be delayed
2)Create another fiber specially for that method and schedule there (so it will be called with exactly that delay (0.1s)
+ : can't be delayed, no new threads, scales
- : should use ReadWriteLockSlim on positions and inputs
3)Create async Task and while loop inside with use of cancellation tokens
+ : can't be delayed, no new threads, scales
- : should use ReadWriteLockSlim on positions and inputs
4)Explicit thread
+ : can't be delayed
- : not scales, should use locks, explicit thread creation,
The reason why i want to send resulting positions right after calculating physics is to not do irrelevant calculations
0
Best Answer
-
well, first i would say that during high load all options may have delays
second, that 1) and 2) basically are same. in new version sdk we added Enqueue method, which can be used to enqueue something to rooms fiber. this will hep to get rid of different locks. You also should understand that when you send something. we hand over this to system. it may have its own delays.
so, i would start with 1). and because delays are just part of this world, i would try to consider this. i mean that when we call Physcs.quant, we should pass there not just 100 ms, but something different like 105 ms. do you know what i mean?
best,
ilya5
Answers
-
well, first i would say that during high load all options may have delays
second, that 1) and 2) basically are same. in new version sdk we added Enqueue method, which can be used to enqueue something to rooms fiber. this will hep to get rid of different locks. You also should understand that when you send something. we hand over this to system. it may have its own delays.
so, i would start with 1). and because delays are just part of this world, i would try to consider this. i mean that when we call Physcs.quant, we should pass there not just 100 ms, but something different like 105 ms. do you know what i mean?
best,
ilya5 -
yep, we need to increase step by delay between it's estimated time and time when we actually starting step
Hm, is it true only when "tasks" in room's fiber executes very fast? I mean if some of queued "tasks" will take 1 second (impossible, but still), then second fiber will still call physics with relatively same delays , so they are not so same.. But i guess those 1s long "tasks" will never happen in real world with good architecture, so i'm overthinking itchvetsov said:1) and 2) basically are same
thank you, Илья
0