Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

Separate Physics and Rendering layers

Discussion in 'Physics Previews' started by varfare, Nov 21, 2017.

  1. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    158
    Yes, and fixing this for DOTS does absolutely nothing for the overwhelming majority of developers who use the built-in pipeline to ship commercial games. This is why people are jumping ship to Unreal. @yant
     
  2. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    681
    Wow! I can't believe this is still not being addressed. Rendering and Physics are totally different animals yet they still share the same layers. Does it require rocket scientists to separate them?
    Physics requires a collision matrix and Rendering does not. Why add Rendering into the same layer that makes the matrix configuration so complicated. It's beyond me.

    I understand that the Engine is designed in early 2000 but ~15 years have passed, so let's move along.

    While I'm at it, I have similar issue with Tag. Please change Tag to Tag list. Tag in real-world works with more than just a single tag.
     
    rboerdijk and kvfreedom like this.
  3. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    1,541
    if you really have to have this today... you can do it today. Just make a separate hierarchy / scene for your physics and your rendering and sync the rigidbodies to meshrenderers gameobjects via code.
     
  4. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    681
    I use layers for camera stacking and I don't have much control over rendering.

    Besides, 32 hard-limit for physics alone is not enough. Expanding to 64bit will not break anything, would it?
    Make 32bit as default and make 64bit as an option if devs choose to. It will solve our problem.

    Yeah, there is Physics.IgnoreCollisions() but it works per collision base and it's a cumbersome workaround. Workarounds, workarounds... as if there aren't any issues here.
    Don't we already have enough workarounds to deal with?

    We can code everything to ourselves, my question is then, why do we need APIs?
    APIs, in my opinion, is a convenient set of functions and prevents us from reinventing the wheels over and over again.

    Unity needs to sit down and think hard what needs be done. They won't even fix simple problems laying for years. They are either Lazy, Stubborn or Incompetent. Or all of the above.

    If they are not going to do anything, they should give us buildable(not full) source codes so that we can continue working.
     
  5. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    1,541
    We do get full c# source of Unity Physics package (DOTS) and we can sim that in separate worlds already if we want. DOTS isn't production ready yet but it does show that Unity IS actually doing something about this.

    Whether users like it or not, it doesn't seem likely that there is going to be major workflow changes on old systems like built-in physics as major changes could break backwards compatibility and thousands of projects. Right now it really looks like they focus bigger changes like these for the DOTS.

    There's only few people maintaining the built-in 2D + 3D physics afaik and there's still updates, like we saw with PhysX 3.4 and now 4.1 upgrade and articulation support, or ability to sim physics per scene. Calling people lazy is just harsh and ignorant IMO when there are constraints on what level changes people can make to these "legacy" systems.

    Also if you look at other game engines you can get access to, it's not like they separate physics and rendering any better. This of course doesn't mean it shouldn't happen (I really am all for it) but things like these really boil down on priorities and what is feasibly to change.

    Just think about the DOTS setup for a second, if they keep adding lots of feats to old and new (DOTS) at the same time, this will just add more confusion among users, what to use, why there are parallel systems that don't compliment each others etc. It really doesn't make much sense in the bigger picture.
     
  6. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    681
    DOTS has nothing to do with the issues here and we can talk about DOTS when it's ready, I mean really ready.
    Don't get me wrong. I love DOTS but honestly, it will be irrelevant for the many at least a couple of years and somehow we need to keep working. Pushing everything after DOTS is just another excuse for their Laziness.

    If they are not going to do anything until DOTS, what are they afraid of providing buildable source code so that we can solve our own problems? Afraid of someone who can make better engine then theirs? Insecurity from Incompetence?
    Unreal Engine has been open source from the getgo and I don't think they are worried at all as no one can keep up with the pace of Unreal development team.
     
  7. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    1,541
    We've hoped for Unity giving engine core source code for years, especially after UE4 and Cryengine did open theirs for their users. But the bottom line here is that the Unity core holds a lot of licensed 3rd party solutions which prevent this from happening easily.

    If you followed what happened with both UE4 and CE, both had to get rid of lots of handy 3rd party libraries before they could do what they did. This made UE4 pretty half baked solution especially for the first year as it simply lacked many basic systems Epic hadn't time to redo yet.

    There's really no motivation for Unity to do this as they are essentially doing their replacement already which - like it or not - is DOTS. DOTS gives us c# package source code and DOTS runtime c# sources, which will essentially be ~90% of the engine. They also license current Unity engine source code access for $$$ for Unity Pro subscribers. If it comes down to not wanting to spend that money and need for source code access for everything, it's pretty clear Unity is not the alternative you should be looking at (unless you are willing to wait for DOTS to mature).
     
  8. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    1,541
    I'd like to add that IMHO lack of current Unity engine source code makes using Unity a big risk to any dev team atm. I've faced countless bugs / regressions I could have fixed / reverted breaking changes in matter of days, instead of having to wait for Unity to fix the issues after I've reported them - which usually takes at very least multiple weeks until I get hands on the fixes (and potentially new issues along with the new version).

    Also there's been bunch of feats that I really would have wanted to have and with full source access I could have added them in few days myself (like I've done in Unreal) and at the same time Unity simply doesn't implement these features despite users requesting them for years.

    I'm only writing this to make it very clear that I'm not against source code access, I'd very much LOVE to have it but there are realities to face here (simply Unity publishing their existing source code for all users isn't possible nor does it make sense for them considering the path they are moving towards atm).
     
  9. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    158
    Could you provide some additional detail around this approach? It sounds like you are suggesting a scene for physics objects and a scene for mesh renderers -- I'm not sure that is a workable approach for a sizable game.
     
  10. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    1,541
    Basically yes, it's not going to scale well if you are already bound by dynamic objects/transforms perf but would be still suitable for most online shooters etc. Do note that you only need to do double GO's for actually dynamic physics objects, rest can stay like they were normally as there's no gain for separating rendering and physics for things that never move.

    And most online games try to minimize the dynamic parts anyway to minimize the networking traffic, I can't think many online games that would even deliberately try to sim so many dynamic objects that you'd run near the limitations of Unity's physics engine/transform system

    Edit. Afaik you could also use TransformAccessArray and Unity's job system to sync transforms in multithreaded jobs so the perf impact of this operation wouldn't be that big (or at very least wouldn't be bound by main thread perf).
     
    Last edited: Feb 17, 2020
  11. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    158
    Thank you for your thoughtful reply.This sounds like a solution worth exploring.
     
  12. andyz

    andyz

    Joined:
    Jan 5, 2010
    Posts:
    1,279
    Just like to add this is still mad! Physics and rendering are separate systems which different limits!
     
    reinfeldx likes this.
  13. rboerdijk

    rboerdijk

    Joined:
    Aug 4, 2018
    Posts:
    25
    Wanted to avoid multiple bullets/projectiles (sprites) hitting themselves via putting then in a separate "userlayer". The moment I did, they stopped being rendered. Googling turned up this thread and, quickly skimming through it, it seems indeed strange to have rendering and physics connected via layers (and also a 1 tag limit per go ^^ ).

    Why not create a parent object which has the RigidBody and box2d/3d-collider in a "Noncollidable dynamics" user-layer, and add a child-object having the sprite/mesh in the "Default" layer to have it be rendered.
    I'm sure I'm not the first to come up with this idea - so is there a reason this isn't a viable?
     
    Last edited: May 10, 2020
  14. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    681
    Unity's stubbornness, laziness, and incompetence will continue throughout the 21st century.
    The only argument I hear is that they don't want to break the existing codes.
    It's the proof of their laziness and stubbornness, and perhaps they don't know how to do it properly.
    My honest opinion is that they shouldn't be in Engine business if they are afraid of breaking things.
    Oh btw, they are already doing that with URP, DOTS, and many others, aren't they?
     
  15. reinfeldx

    reinfeldx

    Joined:
    Nov 23, 2013
    Posts:
    108
    It's 2.5 years later and I'm in need of a solution for this. My game is physics-based and I'm using at least five virtual Cinemachine cameras at all times.
     
  16. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,018
    Yep, I struggle with this A LOT, since my game is a rather large game with a large amount of systems and logic.
     
unityunity