Is culling working for big scenarios?

[shalafi]

Hi,

I am trying to use jPCT-AE for a game and we are doing some stress test.

We load a small room and the game works fine,but when we go into a large one (much bigger than the screen) it lags a lot.

I have run the profiler and it shows that World:renderScene and Word:draw take a lot more time than before.

I was expecting the culling to take care of that and performance not being impacted, but it looks like is not working properly. I have dig into the documentation searching for ways to enable it and I have tried all I have found.

Am I missing something or is this feature not working as expected?

Thanks

[Kaiidyn]

try adjusting Config.maxPolysVisible and Config.farPlane

[shalafi]

I did, the far plane is as near as it can (500) and the max polygons is set to the maximum a G1 seems to be able to move (2000)

Just for the record our scenarios are mainly rooms viewed from a side. The 3rd dimension is not used in the game controls, just to give perspective on the rooms.

Our map is quite bit right to left and up to down, not a deep one, that may impact on the expected behavior of the culling algorithm.

[EgonOlsen]

Culling in jPCT-AE is simple backface culling. It doesn't help for complex scenes. Try to use an octree or, even simpler, split the level into several objects. Objects will be culled on their bounding boxes. But remember that the G1 really sucks performance wise. You really can't expect much from it.

[shalafi]

Ok, thanks for the info.

I was creating sort of a QuadTree by hand, adding and removing objects from the world on demand.

It works quite Ok, but it lags a bit when loading the new objects, I assume it is my own fault since I did not optimize it properly,

Something I also noticed is that removing the object from the world is much more efficient than setting it invisible. Does it sound reasonable?

I am targeting Nexus One level hardware, but I want it to "run" on a G1, I know it is terrible for performance.

[EgonOlsen]

I don't see why removing them should be more efficient unless we are talking about dozens of objects...

[shalafi]

Well, the world we are testing has around 175 Objects, which of them roughly 10 are visible at a time, so that may explain it.

Just to be clear, when I say faster I mean more FPS, not the process of removing them.

[EgonOlsen]

I'll take a quick look to see if invisible objects aren't causing unneeded calculations by accident when i'm back home. I'm on a Shorts holiday right now and i'm surfing the net at gprs speed here...

[shalafi]

Don't worry, adding and removing objects on demand is working fine, the only performance problem I had is that I was not building them until they were added to the world for the first time.

Now I am pre-building all objects and it works fine.

An unrelated question I have is:

Why an invisible object is not checked for collisions?

It can be used to detect an object entering a room, for example, where there is no door (an invisible object)
Right now you can do this by setting the transparency to 0, but I don't understand (from a logical point of view) why making it invisible does not work

Thanks.

[EgonOlsen]

That's because invisible object are not designed to be trigger objects or similar but normal objects that just aren't active at the moment. If you want use them as trigger objects, make them visible before the collision detection and invisible afterwards

[shalafi]

Ok, so it is made like that by design.

Having them with 0 transparency works fine, but thanks for the tip.