How many layers in 64-bit version?

This might be a dumb question, but I was under the impression that we could only have 32 layers in our games because Unity was 32-bit. Now that Unity 5.0 will be 64-bit, does that mean we can have 64 layers in our games?

I may not be understanding it correctly or I could be wrong about the layer limit too. Thanks for any info.

 

64 Bit to simply put it, is how much memory Unity can use. It has nothing to do with the layer amount.

 

Thanks landon! And thanks for the clarification Aras

So as a follow-up question, is there a layer limit right now in 4.0? If so, why?

 

What do people use layers for? Isn't their intended use to reduce the number of items the physics system has to interact with? I can't imagine using anywhere near 30 layers at once

 

Ya that's pretty much the reason I use them Tomnnn. It also helps with determining what things can be "Raycasted" against as well. I'm building an RTS though, and I'm getting close to 32 layers right now. It didn't seem possible to me either, but I'm there right now

 

Then I suggest using better practices. It just seems difficult to reach that many layers, unless it is an absolutely massive project.

 

It's pretty big landon. Have you done an RTS before?

Basically, it's the fact that some units can interact with some things that others cannot. Some units can use terrain that others cannot. Some things need to collide with other things, which cannot collide with other units, but can collide with these objects......etc etc etc.

Resources, buildings, terrain, units, .......the list goes on. Not to mention, one main portion of my games' mechanics is heavily based on physics, on top of it being an RTS to begin with.

Anyways....yes, I've filled the layers and feel like having even more would give me some breathing room. I'm having to make use of existing layers that fulfill most of my requirements, but can't fulfill all of them right now.

The good news is, I'm close to finishing most of the features in my game, so I should be somewhere around 32 layers....having a few extra would be nice though.

 

How about taking advantage of monobehavior components? I imagine there's a few things you're using layers for because you need some kind of uniform property system, yes? If that's the case, have a property component with a handful of flags in it.

I don't recall when I needed this, but it was better than having a million layers or tags.

--edit

I can see in another reply of yours that it is indeed the case! Not for the physics stuff, but for the interaction stuff. You can make a property script that every unit has on it that you can use to determine if said unit can interact with whatever.

I think if you're good with bitwise operations and enums, you can make a very efficient flag system instead of a handful of bools. Like...

9th bit = 1 means air unit
8th bit = 1 means the unit is flying

So your property bit would look like 1001 and mean those things.

 

I'm not sure what you mean by "uniform property system" Tomnnn. Could you elaborate?

 

Wouldn't it be nice if you could set a property on some units to determine what they can do instead of layers? Like no matter what kind of enemy it is, have some ".isFlying" variable that you can access? Make a property script, then. Make it nothing but a few boolean definitions like

Code (CSharp):

1. public bool isFlying;
2. public bool canUseRoadTypeB;
3. public bool isOnFire;

and other stuff you might otherwise need layers for. Then you can do something like...

Code (CSharp):

1. PropertyScript prop = gameobject.getComponent<PropertyScript>();
2.  
3. if(prop.isFlying)
4. {
5.     //whatever
6. }
7.  
8. if(prop.isOnFire)
9. {
10.     //whatever
11. }

and so on. I don't know how performant that is because I've only used it in small projects. I think the bit flags would perform best. But it'll remove your layer limits ^-^

 

Hmmm, I'm still trying to grasp how that would be useful though. I guess, what do you mean by "interact" here as well? Because to me, it's all about knowing if they can "collide" or be "detected" by physics functions and Unity's physics API.

Most of my physics needs are for "detection" purposes -- as my current "detection" system is physically based. So I guess my question is how could coming up with a new flag system tie in with Unity's physics system?

I also could have up to 4 different "teams", and to save on performance, each team can only detect "enemy" teams' units -- excluding their own team. So each team needs their own layer. I think the key for me, is performance. By only allowing units on any given team to not have to detect certain things, it saves big on performance.

I'm not saying I don't need the property system you stated, but simply that I don't understand currently how it would work for things like detecting enemy team units, detecting air vs. ground objects, detecting resource locations, obstacles, buildings, etc....

 

I think the biggest culprit here is the Physics.OverlapSphere function makes an array no matter what, and not only that, it creates an entirely new array each time. So, it's terrible for performance when detecting large numbers of units in my game. So to try to compensate for the terrible performance, I had to create more layers to cut down on the number of objects detected by the function each time it is called.

I could leave a lot of things on one layer and use flags/properties to determine what it is........but then the performance in detecting them initially would be catastrophic.


** Unfortunately I have not yet built a detection system based on quad-trees or oct-trees or some form of spatial partitioning yet -- although I know for most rts games this is probably how it's done. For now, I'm using physics.

 

I wonder if the layer system shouldn't be separate for physics and rendering? I mean, how are those two related?

 

That has been requested before several times, Devil_Inside. And I agree with you. Especially on deferred rendering the amount of layers was insanely limited in the past - though I don't know if this has changed.

 

That's a good point. I have never thought about that haha. So far my game only uses 6 layers so I don't have the need to think about something like that ahha.

 

I actually make heavy use of layers in my application, which is a real-time engineering visualisation tool. I use layers for camera culling and to perform the same functionality as layer tools in things like 3ds Max and AutoCAD - turn certain layers on and off, isolate etc.

Some of my projects have started to rub up against the layer limit and I was really hoping it would be increased for version 5, but unfortunately not.

BTW, if anyone asks why I don't just cache arrays of objects and turn the objects on and off, it's because some of my objects can be quite complex and enabling them causes a significant pause, whereas camera culling is instantaneous. If there's any better way to handle this I'm all ears, but the simple fact is that camera culling does this very easily and dare I say elegantly.

 

I ran into a similar situation a while back, what I ended up doing was just moving the objects out of the camera view. It was a UI visualization so the 'layers' didn't interact or do anything other than display information. As yours, there were a lot/complex elements. Just adding/subtracting 1000 from the parent's Y ended up being more performant than turning it on and off. Might be worth a try.

 

For the RTS elements couldn't you use your own tag system, to get more tags? I still think you could trim a few though, with some careful design.

 

Thanks Superpig and Zombiegorilla, a few ideas to try out. I'd need to see how each of your suggestions works with colliders (all my objects have a mesh collider) and culling (for mobile performance).

It would be a lot easier though to just have a few more precious layers!

 

But with tagging you can't ignore "tags" on the physics calculations the way you can with layers, can you?

I've only ever used a handful and a couple are just for culling or lighting optimization.

 

The 32 bit limitation is from PhysX itself (unless newer versions have higher limit) I'm with velo, I use physics layer quite a lot and they should be separate from rendering. Which means I cannot use deferred rendering. And I know this has been requested multiple times.

 

Think ive got about 5-6 layers in my RTS currently, and I dont for see a need for that many more... im 100% physics
(pretty much in all the games ive worked on.)

 

With additive scene loading and lightmapping some more layers would be nice, so one scenes Directional lights don't affect another sub-scene.

 

32 layers limitation is absolutely ridiculous, remove that at once

 

it is absolutely not okay to force people with limitations, or else we better leave unity and see other game engines

 

Why necro a thread this old just to add pointless complaining? Dont necro threads, and especially dont do it just for this.

 

Guess you'll be moving to Unreal Engine because that's the only one to my knowledge that supports an unlimited number of layers. That said there are restrictions you will want to be aware of. A light can only have three layers affect it at once which is a restriction that does not exist in Unity.

Finally be aware that there are performance costs associated with layers. Increasing the number of layers you work with will increase the number of checks that the engine has to do behind the scenes for everything using those layers. Nothing is free. You want more layers be prepared to pay for it in performance.

 

Well, go ahead and do just that.

There are 32 layers because it is 32 bits in an int. There's no deeper meaning.

 

I wonder on what specificity in the Unity implementation, or on what technical/performance requirement is based this restriction. I know that unary "&" operator for bitmasks on native registers sizes is only one CPU cycle but that doesnt tell us why multi-ints bitfields are so detrimental to Unity even with intrinsics. Not that I complain about the restriction since 32 layers is generally more than enough, but just out of pure curiosity (and to tease Unity devs).

 

One of Unity's primary goals: easy multi-platform support. Some of these restrictions have eased over time. An easy example is how mesh index buffers used to be 16-bit only.

For which CPUs though?

 

Ah found my answer: It depends on how the Nvidia Physx integration was made by Unity and the lowest common denominator of other modules:
https://docs.unity3d.com/Manual/PhysicsSection.html

 

Ah I miss the old 8-bit games with only 8 layers...

 

@Ryiah :most CPUS, always has been. http://ithare.com/wp-content/uploads/part101_infographics_v08.png
You can retrieve cycles per instruction in constructors data-sheets, or dive in your old technical docs from when we were fighting to generate thumb instructions (Nintendo DS https://problemkaputt.de/gbatek.htm) when we were limited to 4MB for games.
The first graph erroneously state <1 for data op (means register to register) but that's because the ARM for exemple can affect more than one register in one cycle. You can not start another instruction before the next clock.

 

i dont care about the performance im not building a huge game so whats the problem

 

Oh, the "why I can't build software however I please already and just magically works" tirades again. It must be Tuesday or something. And a couple of swear words because we have to be super-fokkin'-edgy or something.

Edit: BTW, most people who are complaining about layers are using layers as enums. I don't know if this is a case like that, if it is, use enums. There are some cases where many layers would be beneficial, but I haven't seen any where it is not possible to help the situation with proper compartmentalization.

 

Good luck with your endeavors. Don't forget to sleep, personal well-being is important and sleeplessness inhibits your ability to learn too. BTW, if you enter into a public space and you don't open with "m**f**ckers, do what I say", people will be more open to hear you out in the future. Just sayin'. Especially when you want to sound authoritative meanwhile you're merely learning.

 

Just don't swear, but game making is a lot about finding improbable solutions to impossible problems, unity or not you gotta love solving these problem or else you might as well quit for your sanity. Or do a project suited for unity OR your engine /language of choice, because they all have quirks that will drive you mad. Can't wait to read you raging about the next engine! We all do.

 

Well, you said "change it or I'll leave". They didn't change it. You didn't leave. Were your words a bluff?

-------

If you are not "building a huge game" you also do not need more than 32 layers in it. This problem of yours implies that in the first place you might be doing something really odd. A huge world can be made with 12-14 layers, easily.

You are aware that one object can belong to multiple layers at once, right?

 

If you're not creating a complex game then you don't need that many layers.