CullingGroup API with -batchmode?

The documentation is not quite clear on what is required for the CullingGroup API to work properly. I have setup a number of CullingGroups and am successfully using the QueryIndices methods in the editor and in built servers. However, if I launch my server headless via -batchmode the CullingGroups do not work; is this intended behavior?

 

Case 1154391 filed. Thank you.

 

Hi -

Has there been any update on this? This is the behaviour I am seeing as well. I've had to revert to a fallback implementation doing simple distance squared. Am using 2018.4.5.

Has anyone else found CullingGroups a bit awkward?

1) The documentation implies they can be used for distance tracking only. But even so, you are required to attach a Camera, and it always publishes frustum changes no matter what. When using just for distance tracking you will end up getting tons of callbacks for the same distance band (but because of frustum changes). So I've had to put my own abstraction on top that filters this out and only publishes legitimate changes for distance bands.

It seems more intuitive that if I don't attach a Camera than it should simply do distance band tracking and no frustum checks as long as there is a reference transform. I would also assume that if it could skip the frustum calculations in this case internally.

2) It doesn't always publish a callback when adding a new entry. I suspect since it only publishes callbacks on changes, it is internally storing the last state of each sphere index and using that logic for new entries. This is non-intuitive IMHO. It should really publish a callback (at least optionally) always when a new sphere is added for that first frame (and ideally, include in the callback if this is a new item or just a delta from an existing item). I've also had to put some abstraction on top of this to make this work as well.

 

I got this email from QA on September 17th:

Have given up on this one; really disappointed in their bug department here...

 

How is this possibly being marked as "won't fix" for headless? The use cases for distance banding clearly apply to headless-centric scenarios such as area of interest, etc. Nowhere in the documentation does it mention that it doesn't work in headless, and some of the use cases mentioned for it even include clear AoI cases. At the very least, distance banding should work in headless since a Camera is not relevant for that scenario.