I see you are using CollisionHandlerQueue for your collision events. Is the code that handles the entries in the queue is too heavy? E.g. has a lot of loops. Try disabling the collision handler code and see how it goes.
@maxxim
So deleting the “base.cTrav.addCollider” for both the third and fourth nodes brings the FPS up to 30 fps
So it definitely fixes a portion of it!
So when you say too heavy, basically I need to simplify how the code handles the collisions?
By “too heavy” I meant there might be Python’s bottleneck, e.g. you have a loop
for x in range (0, 100):
for y in range(0, 100):
callSomeCFunction()
In your queue handler. So it’s not the collider node itself slowing the program down, but the code in the collision event handling task. I hope I worded it right.
P.S. and another suggestion. rdb mentioned that colliding with visible geometry is slow. Your level model (the brick walls) definetely has too many triangles for the collision traverser to run collision tests against (121474 triangles with no enemies as you posted above). So, try to remove static geometry and test the performance.
How are you using those two line-of-sight spheres, if I may ask?
And looking at your screenshot, are the walls and the pill-shaped objects on the right collision-objects in and of themselves?
Finally, it might be worth seeing the code that handles those queues, just in case there is indeed an issue there.
[edit]
You say that you have “collision polygons”–do you mean polygonal collision geometry, or are they just built-in collision shapes (like CollisionSphere)?
ughhhhhh, so it was the map this whole time! Y’all were right. So I was generating built-in collision shapes for all of my colliders; however, I did not design the map. My brother designed the map and on this edition, rather than making one collider for each wall etc, he did polygon descend on the geometry, meaning all the little bricks and whatnot are colliders, which obviously overwhelms the collision queues. This fixed it all!
So, this is off-topic, but I am using these to check for different line of sights. Basically, I “shoot” the node to detect if the player is behind an obstruction or not. But honestly, while Ive been speaking with you all on this forum, I realize now I could probably just use a different geometric collision like a line then I dont have to shoot and updates nodes. Then with that, I can just pull the closest collision to the line within a given length for the line and that will give me a lot faster reaction time for the enemies.
P.S. I dont think I know who to give the solution to because you have all helped me a lot haha.
Ooof, no wonder indeed! >_<
Well, I’m very glad that you found the source of the problem, at least!
Ah, I see–thank you for the explanation!
Indeed, that seems like a good idea–and quite possibly more reliable, too!
Eh, I’d suggest marking your most recent post (i.e. the one that I just quoted) as the solution. That solves the problem of figuring out who to select, and it does indeed contain the answer to the problem.
Wonderful idea!
Thank you! and thank you again for all the help!