[HELP] Efficient Nearest Neighbor polling of Large Sparse Worlds

Troubleshooting General Help
21
@zarch said:
I would organise it the other way around: Only put the data in one cell, the client listens to all interested cells.


How do you handle the physics support in that case tho? Im having trouble seeing how the headless server would avoid the precision issue this way.
22

Co-ordinates are local to each cell. Objects transition between cells as needed. Separate physics sim for each cellā€¦



ā€¦or port the physics engine to 64 bit (as has been done at least once by someone just by replacing float with double in their own build of the engineā€¦Iā€™ve no idea how well that works out long term though)



There is one big ? here thoughā€¦which is that we donā€™t really know what sort of game you are making. How many players? your server? player server? Basically there are a lot of scale questions and we canā€™t make good suggestions without knowing a lot more about your game.



We donā€™t know how experienced you are, what youā€™ve done before (although the way the question is phrased implies a certain level of knowledge!)



My recommendation would be to start with something very small - single player, one grid (Maybe an asteroid field or whatever). Take what you learn from that and then build something the next complexity level up and so on.

23

Yeah, a physics engine using double will be 100x easier than trying to constantly work around the other issues. And if thatā€™s too hard then you may want to scale back your goals.

24
@zarch said:
Co-ordinates are local to each cell. Objects transition between cells as needed. Separate physics sim for each cell....

...or port the physics engine to 64 bit (as has been done at least once by someone just by replacing float with double in their own build of the engine....I've no idea how well that works out long term though)

There is one big ? here though...which is that we don't really know what sort of game you are making. How many players? your server? player server? Basically there are a lot of scale questions and we can't make good suggestions without knowing a lot more about your game.

We don't know how experienced you are, what you've done before (although the way the question is phrased implies a certain level of knowledge!)

My recommendation would be to start with something very small - single player, one grid (Maybe an asteroid field or whatever). Take what you learn from that and then build something the next complexity level up and so on.


Haha yeah I'm a Computer Scientist, concentrated in cyber security, thats why precision and networking load are so obviously a concern in my mind.

Ive considered simply changing the engine to use doubles, but since im new to this engine ive been worried about tweaking it much cause i dont know what all it may affect.

Im trying to make an FPS space sim. the players are an individual person crewing a ship, battling each other, boarding and stealing each others ships, building space stations, etc. Ideally any solution will scale easily, allow for low server load, and low latency. I plan for it to conceivably handle thousands of players(why not hope for the best ;) )

I am starting to see through the fog as to why you've been so adamant about simplifying the cells. Since functionally there's no difference, increasing grid size allows for less overhead maintaining the world.

My biggest concern this whole endeavor is that i want a seamless world, yet its next to impossible to keep precision without sectioning it off. Especially considering the float problem.

@pspeed said:
Yeah, a physics engine using double will be 100x easier than trying to constantly work around the other issues. And if that's too hard then you may want to scale back your goals.


Again, my only concern with this is what potential hardware issues this may create. Who knows i may just go ahead an do it and see what happens.
25
@stephanator said:
Again, my only concern with this is what potential hardware issues this may create. Who knows i may just go ahead an do it and see what happens.


I'm pretty sure modern hardware does FP in 64 bit anyway. It's just the extra size of the variables that will have an impact. I think: use double for physics if you can and use float for the scene graph. It should be fine and then you will easily spot your precision bugs that would otherwise crop up in OpenGL anyway. Physics in world space doubles, scene graph in camera-relative space float.
26

Well, adamant might be a bit strong. There is nothing inherently wrong with either approach. I just find simplicity pays dividends in the long run and it felt like the fewer switches/cells/etc would be simpler to deal with. Go with whatever way works best for you :slight_smile:



Be aware though that running more than 20 or 30 people in the same space in any sort of real-time combat is going to be a nightmare in terms of server load.