Lighter Collision Element?

Hello! I have a forest, filled with about 8000 trees, and the seems to be working kinda hard on it. I was hoping to reduce that impact.

One of the problems I see is that I need two collision polys for each tree. The outer collision poly matches the visual tree, and detects whether the player is behind the tree or in front or whatever, for visual reasons. The inner collision poly matches the stump of the tree and just has the Solid behavior. I have each tree represented by two sprites, with the second being invisible and immobile. C2 seems to be doing about 60k collisions per tick whenever the player moves....

Is there a collision only object, or perhaps a cheaper method than a collision poly for determining whether a charachter is behind a tree? I am trying to maybe collapse this tree down to a single object and avoid the overhead of 16000 sprites. Thanks!

Dunno, you can try the collision-only empty sprites+tilemap object with trees in front of the sprites, but 8000 collision sprites still sounds really hard. Maybe you see a little improvement if you gonna test for player overlapping only on-screen objects.

Probably you'll have to do something to decrease the 8000 trees, make some parts of the forest solids and only use tree objects around that part.

For the two object thing I would suggest you to use a 4 point polygon collider on the base of your trees and an image point 0 some pixels above the base so you can arrange your z ordering with Object.Y

Stop using On Collision and use Is Overlapping / Trigger Once. That might help - providing you are careful how you manage subsequent results...

I suggest you have a read through this thread for a good discussion about the merits of using On Collision and Is Overlapping.

8000 is rather a lot....!!

Since the trees aren't moving you could setup some kind of spatial partitioning so you only check for collisions around the player. Basically the idea is to divide the layout into say 100x100 squares and keep a list of all the uids of the objects touching the squares. You could use a 2d array with a 1d array for each cell to do this.

After that's setup you check for collisions only with trees that in the cells the player is touching.

The idea is elementary, implementing it with events is doable, although tedious for most.

8000 is indeed quite a lot, and at some point I am going to implement something where groups of small trees get replaced with larger ones. Part of me wants to tune performance now, so reducing the number of trees later on will be an even bigger boost, or I can have a larger level or something. I guess what i really want is for trees offscreen to go to sleep.

Ok that Is Overlapping/On Collision thing is super weird. I would have figured the opposite. Thanks for the heads up!

It seems like I could keep the origin at the bottom of the tree and use an image-point at the visual center, then check the player's distance from that imagepoint. Is that likely to be more efficient than collision? I imagine if I require trees to be onscreen that would help. I kinda wish there were a way to set the SOL to "everything in the collision cell with the player" Edit: I just realized that this needs to be done for every onscreen Tree + Charachter combination, since I want trees to go transparent for ANY charachter walking behind.

R0J0hound that seems like the Collision cell thing that is supposed to be already in the engine?

I tried Zsorting everything on the layer by Y, but that turned out to be terribly expensive, so I'm really using collisions on the Outer tree so I know what to sort. I'm also doing a funny transparency thing with trees when you walk behind.

Am I no longer allowed to attach stuff?

Yeah, I guess it would be. Smaller cell size, but basically the same. I'd have to look up the blog post about it.

So I did some actual profilling and it turns out the 60-70% CPU in "Engine" wasn't spend doing collisions, it was something else I didn't have any trouble taking care of. oops lol. That'll teach me to rely on the C2 debugger.

I ended up starting with every onscreen obstacle and grabbing the nearest charachter and comparing distance. It seems not too bad to use Is On Screen, since I only do it once per frame. I'm not sure how good "Pick Nearest" is, but it doesn't seem to be giving me any trouble. The main good to come of this I think is that I don't have a separate collider for each tree/obstacle.