@pspeed
In relation to the Sim-eth-es example:
Is there any way to hook into the EtherealClient and get information on the watched zones ? I’m trying to cull zones that are not active on the client, so I’m ending up doing some of the same logic (I guess) where I have to keep track of the current zone and the surrounding zones (according the zone-radius) and cull those we are not receiving BodyPosition updates for (at least that’s a starting point for culling my static map objects. Would it make sense to make this information available to the client session as public methods?
Does my approach make sense?
What are you culling? The managed objects should already being added/remove/visible/invisible as needed.
Or if you mean static stuff not managed by sim-eth… then no, that’s up to you. It’s after all only a coincidence that you want the zone filtering to be the same. It’s not typical.
Allright. What’s your approach to culling if this is not typical ?
I’m culling map/level view objects (moved out of the entity data for now since my game is tiled based it ended up being alot of tiles). I’m new to culling, so I’ve only recently dived into it. For now, I’m setting cull Always on BatchNodes in zones not in my radius and cull Inherit on those inside the radius.
When I said “not typical” I mean that it’s relatively rare to have the culling distance of your mobile physics objects (ie: the ones managed by sim-eth) be the same as the culling distance for your level. Even in the case of a 2D top down view, there may be reasons you load larger parts of the level and/or a wider area for sim-eth. There are many good reasons that the radius or conditions will be different.
One approach, and the one I use for Mythruna static objects:
For your static Position components, include a calculated grid cell ID/number as one of the fields. When you setup the entity set that is watching for static objects, give it a filter on a set of cell IDs. If you update that filter whenever the view crosses a grid boundary then the entity set will automatically purge/add tiles as needed.
I mean, quite often, level geometry is not even handled at the same grid level as physical objects. You might have chunks that are already well-binned, or tiles that are much larger than what your physics ‘zones’ will be… or even an FPS where you load the whole level and then use PVS (potentially visible sets) to show/hide sections based on camera position… that has nothing to do with what you are sucking down from the client.
So the fact that you want your static level to be bound by the same filter as your dynamic objects is just a relatively rare coincidence.
Thanks for the input. I hadn’t considered a ‘dynamic’ ES-filter.