#Ghost optimization, snapshot rate alteration

1 messages · Page 1 of 1 (latest)

tropic tinsel
#

Is there any way to meter the rate at which snapshots are sent for particular ghosts/ghostfields? I'm working with very high counts of fairly complex-behaving projectiles, but they are fairly deterministic and I could probably afford to let clientside prediction do a lot of the work, and actually synchronize the projectiles at a much lower rate. How might I go about that? I am already quantizing their various ghostfields to decent effect, but I want to eek out all the headroom I can.

As an aside, are there any "tricks" to optimizing fields? Is it significantly better to build the fields into a struct and replicate that? I'd just try it, but I'd have to do a fair bit of code alteration to check.

tropic tinsel
#

Got a sort of hacky solution right now that effectively lowers the tick rate applied to the projectile by iterating a uint a few times before updating the heavier ghostfields and then resetting the uint. That does lower my network overhead measurably, but it's a pretty ugly solution, and also means I interrupt actual simulation and not just replication

broken sapphire
#

if snapshot is full, ghosts will be updated based of their importance

#

there's also this, which may be a way for you to setup custom importance dynamically

#

alternatively, you could just disable syncing of anything you don't care about and instead sync only a value that actually triggers recalculation of prediction

#

so no transforms is synced, while some custom component with tick and position will help prediction determine where projectile is

tropic tinsel
#

The exact situation is I'm verlet-integrating my projectiles, so they have a Velocity float3 on them that is modified in realtime and is used to update the position. Both the predicting client and server update Velocity, but 9 times out of 10 their results will be extremely close

#

I could get away with correcting Velocity very rarely

#

I'll have a look at importance. I've been trying to keep the baselines reasonable so they aren't yet competing with much else soas to see importance at work

broken sapphire
#

you could just make it quantized

#

so if it changes by a small margin, it won't be networked

#

well, you already should have it quantized

#

just make it much smaller ig

tropic tinsel
#

ooh yeah, that makes sense. Just let the information get clipped by quantization

#

I am correct in my understanding that 1 is the coarsest possible quantization, right?

#

basically I would be rounding my float3 to the nearest integer?

broken sapphire
#

quantization works like this

#

originalFloat * quantization

#

the result gets casted to int

#

and this value gets compared against previous values

#

if you have quantization of 1, that would just mean you are syncing ints

#

oh wait

tropic tinsel
#

Running with 10 right now, but I did try 1 and it wasn't as noticable as I would ahve expected

broken sapphire
#

it's multiplied, not divided

tropic tinsel
#

but I guess that makes some sense since I expect the prediction values to be mostly accurate

broken sapphire
#

division happens during deserialization

#

10 means it has precision of 0.1

#

100 - 0.01

#

1000 - 0.001

#

and etc

tropic tinsel
#

okay gotcha, that was my understanding

#

Between that and GhostAuthoringInspection (which I just discovered), I'm down to 56 bits per entity from 150

#

so I'm reasonably happy without doing anything too creative

#

While I've got you: is there anything obvious I can do to optimize entity creation and destruction? My projectiles spawn impact effects, and since optimizing the projectiles themselves, the creation and destruction of impacts is more network-heavy than the projectiles themselves

broken sapphire
#

vfx generally can be done from within one particle system/vfx graph per vfx kind(prefab)

#

so you can have like 1000 particle emitters all using same particle system

tropic tinsel
#

ah, I guess I can get away with that

#

thanks again