So why only one Box Collider per GameObject?

These kinds of restrictions just kill me sometimes Anybody have any insight into this?

EDIT: Having one gameObject per collider kills performance if you have too many.

 

If you want extra colliders, add child objects with colliders. They will be `tied to` and affect the parent object and all children. So it's not really a limitation? It just sort of makes sense to say that one object has one collider, as a general case.

 

Compound Collider

http://docs.unity3d.com/Documentation/Components/class-Rigidbody.html

 

Oops, I probably should have added that I tried this and it's not a very good solution. (I mean, it's like the only one out there but it's slow when you have too many.)

 

if compound colliders and mesh colliders are getting to slow, it's likely you're just taking an entirely wrong approach towards it. Can you share what you are doing - perhaps there's better workarounds.

 

Basically I have a large amount of objects that I need colliders for. Like a large amount of objects. It has to be dynamic as well, so there's no way to pre-calculate much.

 

Is the parent object a Rigidbody?

 

Nope, all static. I just need a way to have a lot of colliders without having tons of gameObjects. (Mesh colliders work decently, but recalculating them each time you change something is quite painful)

 

Ok, you might need to go into more detail here. If all the colliders are static then what exactly is dynamic in your scenario? What is being changed at runtime? What is a "large amount" of colliders?

 

Static as in they never move. The mesh colliders need to change as I add and remove "box" meshes from it. Recalculating the mesh collider is costly though and it would be a much nicer solution if there wasn't a one-box-collider-per-gameObject restriction (Why is that?). The goal is 500,000+

 

You would have issues with that many colliders anyway, so one box collider per game object makes no real difference. You can use mesh colliders with fewer vertices so that recalculating isn't so costly. It would probably be a lot more costly to have 500K box colliders, since removing or adding one would cause the scene graph to be recalculated, which won't be cheap with so many.

--Eric

 

Thanks for your insight! Could you explain more about this "scene graph" thing? Where do you learn about this stuff?

 

Osmosis. In order to do collisions efficiently, the physics engine has to do some fancy computing so you don't end up comparing every collider to every single other collider every frame. This computing has to be redone when you add or remove colliders.

--Eric

 

Is it for a minecraft style game?

Regardless, this is a good fit for either: pooling local colliders that move to an area around the player OR rolling your own collisions which use a quadtree. Both will get you back up to 60fps or whatever within reason if done wisely. There is no magic bullet so you'll have to either do it or just share more of what you're doing so we can be more specific in turn.

While physx is optimised, there is an overhead in unity for having too many objects being processed.

 

If it is a minecraft game, you'll have to handle colliding a bit different.

 

The more information you give us about what exactly you want done, the more likely it will be that we can help.

I can't see why you would think that 500k game objects with a box collider each is slow but one object with all of the colliders on it would magically be faster. Its the colliders that are slow, not the game objects. The game objects should have virtually no impact on performance.

If ever you have an object with a collider that you are moving (or creating/destroying), it should have a rigidbody on it marked as kinematic. As far as I know, that tells PhysX that the object is dynamic so it can skip a lot of the things it does to optimize static geometry.

 

It recalculates the entire scene graph? You'd think it would be better just to "add" to the scene graph, but I don't really have any background on those I guess.

Not minecraft, all the "blocks" are of different shapes and sizes. Think "an online lego" kind of game. Is an external physics library really a good idea? I'm already pooling large groups of objects as mesh colliders so instead of 50 box colliders I have one big mesh collider for each of those groups.

Ok, see my reply to Hippo for some more info. In my experience (I've done tests), adding a gameObject to the scene gets slower as you add more. Up until now I didn't know about the "scene graph" thing I guess. I just thought if I had less gameObjects that it wouldn't lag as much.

EDIT: I'm trying as hard as I can, but I really think Unity is unfit for the game I'm trying to accomplish Gotta tread lightly when asking this I guess, but does anybody know of any good engines with a Mac editor that would better suit my purpose?

 

A better game engine than Unity that has a Mac editor... good luck with that

How long have you been trying to solve this? Have you tried the Kinematic Rigidbody approach yet?

Again, you're not giving us all the details so it's hard to give specific solutions to your specific problem.

 

Probably explains why I've stuck with Unity this whole time :S

About 2 months on and off. Having 500,000+ rigidbodies doesn't sound like a good idea. Do you mean to only create colliders around the player or something like that? I want to stay away from that approach since I'd need to have rigidbodies made dynamically around other physics objects like bullets.

What about something like bullet physics? Perhaps that's octree based and it allows 500,000+ box colliders with no issues?

 

I doubt you'll find anything that can handle 500K box colliders "with no issues".

--Eric

 

A GPU accelerated windows physx 3.0 would handle it no problem. For the mac you're bang in trouble and there's no quick solution. How many of these need colliding at the same time? How many are MOVING at the same time?

likely the solution is mesh collider, in batches of say, 256 quads at a time updated based on region, that sort of thing. I think its fairly absurd (and lazy programming) to insist that 500k objects have to be moving at the same time. It's likely in your case only a few move at the same time. If not many move at the same time, then the most efficient will likely be several mesh colliders, which update to geometry when they need to, if they don't move much.

Also, are you sure it's the collision slowing things down? 500k objects is an awful lot to draw and physx would be asleep for a lot of them.

 

Oops, I guess you missed my reply that the meshes were dynamic, but the objects themselves are static. So they actually never move. I just need to have collision for all those objects.

 

Someone above mentioned compound colliders. If you have one, you only need one rigidbody on the parent/root object, not one on every collider.

500k rigidbodies is no worse of an idea than having 500k colliders. If you want something that can handle 500k colliders with no issues, you'll probably have to wait a few years. The best way to currently have 500k colliders is to not have 500k colliders and instead just spawn them when needed. The technique you mentioned where you only spawn stuff around the player is a very common one.

Have you tried profiling what exactly is killing your performance? It's pretty obvious that it's physics, but it might say something like "optimizing static geometry" (I can't remember exactly what it says in the profiler). If it does, then adding rigidbodies should definitely help.

 

Making rigid body cubes vs static is actually worse for performance. I just did some tests. Making about ~620 of each took these times. (Using System.Diagnostics.Stopwatch)

Static: 27 ms

Rigidbodies: 36ms

Thanks for your input though!

 

I wasn't saying that creating them would necessarily be faster, its updating them that should be faster.

In your test, did you create the rigidbodies before or after the colliders? Because if you created the colliders first, then Unity might have optimized them as static geometry straight away. I don't know if that would actually happen, just a possibility I thought of.

 

Oh, I see what you mean now.

I did them in separate "plays" in the editor. I used prefabs for both, so there was no adding of components. I haven't tried a removal test though...