Extend Unity's 2D Physics for use in 3D game

In a lot of games, 3D physics are just confusing and unnecessary. In an RTS, range detectors don't need to worry about height. In a top-down shooter, bullets don't need to worry about flying over an enemy. If these games could use 2D physics, their performance would be optimized by many-fold and it'd be so much easier for the developers.

Currently, from what I've researched, Unity's 2D physics can't be used on the XZ plane which is what most 3D games are built upon. Thus, 2D physics often can't be used for top-down 3D games, or at least are very difficult to use. At the very minimum, the editor camera should be able to operate considering the Z-axis as vertical so a 3D game can be built on the XY plane.

Other games that come to mind in which 2D physics on the XZ plane would be useful are Tower Defense, MOBA, RPG, and many more that have AI-controlled units.

If there is a clean solution, please let me know. If not, make this essential feature happen by voting up the suggestion: http://feedback.unity3d.com/suggestions/extend-2d-physics-to-xz-plane.

 

Anyone have ideas of how to implement this? Or maybe how Unity could change their system to implement this.

 

What would make you want to use a xz plane? Basically in a 2D game, there is only a XY coordinate system.
Did you try changing your Properties in Edit->Project Settings-> Physics 2D to fit your needs ?

I don't quite get the problem here...

 

2D physics can only be used on the XY plane. In a 3D environment, that would be vertical. Many 3D games need 2D physics horizontally, not vertically. A simple example I noted in the first post is for range detection where an air unit should not have to be any farther from a ground unit to attack than another ground unit (height is not considered). Also, using 3D capsule colliders with extended heights for such a task would simply be inefficient. As of far, I haven't found a method to do so.

I would be okay with building my game on the XY plane but the camera would still operate on the XZ plane as horizontal (you can see how this can get very frustrating). At the very minimum, the editor camera should have the option to change axes.

 

Just rotate your models 90 degrees.

 

Yeah. I was testing a similar idea in a prototype. Rotate everything 90 deg around X. so positive Z is up and positive X is right.

 

It feels extremely weird because your editor camera and grid operates on the wrong plane. Also, it's a big day-ruiner when you have to change all your scripts to use the XY plane. I wouldn't use the default navigation system and would have to really dive into the code for navigation assets.

This is a lot more hassle than simply assigning different inputs and outputs for the physics system.

 

This is analogous to saying "I built my furniture this way because I intended for it to rest on the ceiling. It's going to be a big hassle to retrofit it to fit on the ground. I would prefer if we could just turn the house upside down."

You're going to have to change your existing code. The functionality of changing the axis for the physics system doesn't exist.

 

What? It's analogous to saying the capsule collider should be able to operate on different axes which it does. Also, have you tried building a 3d world with a camera operating on the wrong axis? I have, and it's like building all the furniture on the wall which is a lot harder than simply flipping everything.

 

I've had no problem using 2D physics for top down games. Just turn gravity off and you are good to go. Really don't see the problem here.

 

You've made a top down 3d game on the XY plane? How did you edit your map's terrain and design your structure layouts? How did you manage to get the navigation working? How did you deal with the awkward camera rotations? If I knew these things, I'd child everything and type in that 90 right away.

 

I would just advice you to stick to 3D physics. You'll be glad you did if you ever want to add particle effects that bounce off the environment, friction, ragdolls, debris from explosions bouncing on the ground etc. etc. I doubt any of the 3D games in the genres you list here use 2D physics. They would lose out on way to many interactions that way.

The performance difference between 2D and 3D physics in Unity is minimal.

 

2D and 3D physics run on separate systems also. They don't work together well/at all

 

I only need 2D physics for range detection, and the performance difference is about 3x. I'm kind of uncomfortable making gigantic capsule colliders to make sure everything collides on the same plane so I'd rather not have range detection be in 3D.

Also, particles, ragdolls, etc. can still all be used for fancy effects but I don't plan on ever using them for simulation of actual values in the game. There's no reason why 3D physics can't be used for effects. Besides, I never said I would use 3D physics anyways.

 

Personally, I've at most seen a 10-20% performance increase for 2D physics over 3D physics.

And I don't understand why you're using capsule colliders. Sphere colliders are cheaper. Can't you just have sphere colliders and just make sure they are all positioned at the same height if not registering collision on the same plane is an issue?

Also, if all you're doing is range detection then surely there are cheaper ways? Like just maintaining an array of objects and doing distance checks against them or something? If performance is the main issue.

I see where you're coming from, but I doubt the 2d physics system will ever support the XZ plane. It sounds complicated to implement and it would also complicate all the documentation, unnecessarily in my opinion.

But I agree with out about the editor-camera. And I think I voiced my support for in the other thread that you made. Post it here http://feedback.unity3d.com or upvote it if someone has already posted it.

 

Sphere colliders would mean that units at different heights would have to be detected by different ranges, sometimes not at all.

That's disappointing to hear though. Maybe I'll just compromise and use the XY plane but this feature at least has to be implemented. Currently, XY means no pathfinding or terrains.