Thanks Monster, this is a WIP and we appreciate any input to help develop this further.
Surely not. Frustum culling belongs to render only. As empties have no mesh they are not visible at all. So no need to even take them into account.
Be aware adding objects to the scene eats quite a lot of processing time. I noticed that while running some benchmark tests for other purposes.
We figured as much, but what about a single vertex? A vertex would fall into the render category and be subject to culling checks, but at the same time not use any rasterizer as there is no poly to draw. I have found this to work similarly to empties, if only slightly more costly. The end game here is to use the empties/vertex position to build a point list and the camera culling as a sort of search algorithm to determine which objects should exist. My thought is to use a wide lense camera to perform the searches and a narrow lense camera as the active, this way the popping should only occur outside the active view. Barring that method, we would resort to using the empties to generate the list, the KD tree to manage the positions, and the spawn code to generate the environment as you go for a sort of streaming technique. Indeed adding and ending the objects uses up quite some time but we have found it becomes tolerable with batch processing.
The idea to end objects when not in frustum has some flaws:
A) you need to add a lot of objects when turning the camera
B) the current visibility check will be one frame to late causing visible popping
C) it requires constant checking
These are the same issues we ran into with the initial proof of concept, which eventually led to the batch processing test. We can significantly reduce the amount of checks by batching empties, but it is still a bottleneck. This is why we thought to use the culling code to perform the checks, it constantly happens anyway. If we could modify it to manage the adding and ending of objects, we should see a performance increase.
The following points belong to objects with logic, which you might want to exclude:
D) Objects out of sight will not perform logic
E) The state of objects out of sight will not be preserved (e.g. an animation)
The following point belong to objects with physics, which you might want to exclude:
F) Objects out of sight will not perform or influence physics calculation.
I suggest you better look for an LOD solution. It keeps at least the scene around the camera running.
I am concerned about the same issues, however the spawned objects are all static terrain features with little to no logic or animations. Ideally this system will work along side the trunk LOD to manage really big environments.
Remarks to the implementation/code:
A) I recommend to use module mode
B) “own.attrDict[SpawnInstance]” is not necessary you can perform key access on the game object directly: “own[SpawnInstance]”. Interestingly you use both ways. Better be consistent with only one.
C) The variable name and its pretty long description in the comment do not seem to match. You name it “object” but say it contains a property (and gets filled with a property name). This is confusing.
How about “PropertySpawnObject” or something similar?
D) You can use “own.get(property-name)” to avoid a KeyError. It will return None instead.
E) checking if the origin of a mesh is within the camera frustum is not sufficient. The mesh should be visible before!
F) It looks like you want to run this code at each single place holder. This will kill your logic frame. Better use one object processing all placeholders. The code is always the same. You can even throw the placeholder away after adding the mesh object.
G) To reduce the amount of object within the scene, you can store the location/orientation/replaced-object-name of the placeholders in a sufficient data structure and remove all the empties.
H) Please remove these comments. If you think you need to comment each line, your code is not clear enough. The majority of them do not add any value to the code. I can rephrase your code just with comments:
Do you really want to keep the comments up-to-date with any code change?
I hope it helps
To be clear, I am not the author of this code, I am the benefactor. I understand enough to be able to discuss, but I rely on iPLEOMAX to make changes. We will revise to make use of modules and be more consistent. The variable names are a property that determines which object the empty spawns, we will have to make this less confusing. The batch processing test makes use of the single master spawner and I hope my idea of using 2 cameras to eliminate popping will be efficient. The commenting is more for the benefit of discussion and will eventually be reduced to reflect “important” comments. I want the code to be usable by any beginner, while not being bloated with unneeded comments. I will have iPLEOMAX take a look at your suggestions and have him revise as necessary. Thanks again for your candor.
My main goal is to be able to do something similar to what Euclideon did with their Unlimited Detail tech. Do you have any further suggestions that might help us evolve to reach that goal?