Is it expensive for many IgnoreCollision()?

I have a tank with collider. Every time it fire a bullet, i set the bullet collider ignore the tank. Of course, the bullet will destroy later, and many many bullets are fired in game.

My problem is, will all ignorecollision() store in the physics system? After long game run, will it cost performance issue? If so, any way to solve?

Thanks.

 

Actually, it is a single player rts game, there are many player's units, which bullet may hit any thing in scene, except itself, i.e. player unit A may damage player unit B by mistake.

If i do it with layer ignore, every tanks need to have its own layer? I may have 20 to 40 tanks in game.

 

@MelvMay That is not accurate or feasible as Unity only supports a limited number of layers. Also that normally how its done in. That type of thinking only works with small single player games of a specific type and tech demos.

As S***man says you can't have every tank on a different layer. Splitting things onto layers isn't feasible for most mid to large size games.

@MelvMay I'd really like to know if your comment about IgnoreCollision is based on a performance issue with the system. If so that would be a huge disappointment as we waited for months to get this issue fixed and are about to move our system back over from the trigger hack described below.


@S***man
I have not profiled ignore collision yet. I had to rip it out previously due to a bug were it was resetting trigger states when used (look up my posts on ignore collision) but this was fixed in 5.5.

My hack to get around the bug currently has all my projectiles with triggers, so I can early out in code. (they collide with there own hitboxes but know to ignore hit boxes from their owner) Sadly this meant that all my collisions impulses are manual.


Now that Ignore Collision is fixed we will be moving over to this system, I'll let you know what we find though it may be a few weeks before we have the time.

I would suggest the following (I have not tried this yet but hopefully the physics system remembers ignores when an object is disabled):
I would pre-create a bunch of tanks and units on startup. Then disable the gameobjects (pool them).
Do the same for their projectiles.

Now assuming you can't pre-pool projectiles for every tank ( maybe you can if each tank only would have one or two shots in flight at a time. If you can then just have the projectiles ignore tank collision on startup.)

-when a tank is being created I'd "assign it" a set of disabled projectiles and have them ignore its collision. You can space this out over several frames if performance is an issue.

-Then when shooting the projectiles simple enable them rather then creating them.

-When they hit disable the projectiles, reset their values and have the tank reuse them.

Hopefully the projectiles will remember the ignore collision on disable and you wont have to re-create. If they don't remember the collisions I'd open a bug as the system was implemented in a way that wont really fix the issues its meant to fix.

 

So, do the colliders in this hash table will be automatically removed if their parent gameobjects are destroyed?

If not, can i remove specific colliders in this hash table?

 

Thanks.

Can i assume it apply to 3d too? My game is 3d.

 

@MelvMay
Sorry If I came off as attacking you, when you responded to the original post by saying "this is how it should be done" it was upsetting as its often not. I've worked on some large projects, where we had to hack around Unity's implementation of physics to get around issues like those identified by the original poster.




Long story short. IgnoreCollision would reset trigger states for both the ignored and ignoring and the entire hierarchy. (This functionality was actually in the manual as expected behavior)

So for example, if a character holding a gun was standing on a pressure plate that opened a door and a bullet was told to ignore a gun in there hand, the gun, and the character holding it would trigger OnTriggerExit and OnTriggerEnter events. The door would play a closing and then opening sound.

Two threads about the original problem with ignore collision.
https://forum.unity3d.com/threads/p...tate.340836/?_ga=1.3628534.7558082.1478057180

https://feedback.unity3d.com/sugges...rigger-state?_ga=1.3628534.7558082.1478057180

Again sorry to come off as aggressive but your response "this is how it should be done" sent off alarm bells for me that hearkened back to how a feature (that was in the manual as expected behavior) was implemented in a way that did not support medium to large size games.

Thanks for taking the time to respond.

 

Sorry to chime in, but I don't think this is a proper reply either. Most of us are trying to do games, not just tech demos or single scenes for fun. I think it's easy to figure out that the guy asking the question needs a generic and scalable solution to build a game with tanks, not just a way to to have a single tank firing a single bullet.

 

Why would you think it's easy to figure out the op needs a generic and scalable solution to build game with tanks, while all and any information about the game was:

 

I think there is a bit of frustration in the community around Unity as a company not having an internal Dev team doing full sized games. The recent release of the Seattle based team has added to that frustration, and seeing how the "unity 5 Adam" video was made increased that frustration even more. (It was incredibly misleading, was barely in engine, and didn't even use lighting that existed in unity 5 at release)

My alarm bells went off but the current state of affairs isn't really Melve's fault. Unity needs an internal dev team doing full sized games. That way the default thinking inside the company will match the customers. Its super important for the people that make the tools to use the tools the same way the customers do and all that.

That said I think we need to be careful not to take this frustration out on an individual employee that is trying to help. It will just result in those employees posting less. I should have taken a better tact ,lets be careful not to scare the help we have away.

 

It is not Unity's responsibility to make games, they provide technology and other developers use that technology to create a wide variety of products not limited to games.

As in the case of this topic's misguided 'frustration', its the same with apparent shortcomings of the technology - users must communicate concerns clearly in order to facilitate corrections by the tech team.

 

My philosophy is the best toolmakers always use their tools as the customer does. We will just need to agree to disagree about that one.

 

I guess all the problems wouldn't be an issue in this post, if we would have more layers. 32 - 8 = 24 layer for an RTS is a pain. We simply cannot have for each player different layers, so we have to fix it by using ignore collider. In C++ the type can be very long, ( https://stackoverflow.com/questions/5242819/c-128-256-bit-fixed-size-integer-types/5244091 ). A uint1024_t would give us 1024 - 8 = 1016 layers. The CPU can handle it very fast, I don't belive that there would be a big impact in CPU performance.

The collision matrix UI would be an issue in the state as it is, but anyway, that UI solution doesn't scale.

 

Agreed. Imagine a baker not tasting its own cakes and saying 'It's not my job to check if it tastes good, my job is to make cakes'

Broken logic right here.