How many layers in 64-bit version?

News & General Discussion
1

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.

2

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

3

No, that has nothing to do with 32 or 64 bit. I don’t think we’ve changed the layer count in 5.0.

4

Thanks landon! And thanks for the clarification Aras :slight_smile:

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

5

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 :o

6

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 :hushed:

7

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

8

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.

9

How about taking advantage of monobehavior components? :stuck_out_tongue: 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.

10

I’m not sure what you mean by “uniform property system” Tomnnn. Could you elaborate? :slight_smile:

11

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

public bool isFlying;
public bool canUseRoadTypeB;
public bool isOnFire;

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

PropertyScript prop = gameobject.getComponent<PropertyScript>();

if(prop.isFlying)
{
    //whatever
}

if(prop.isOnFire)
{
    //whatever
}

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 ^-^

1 Like
12

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…

13

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.

14

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

4 Likes
15

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.

16

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

17

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.

18

Have you tried enabling/disabling the MeshRenderer components, rather than activating/deactivating the entire objects?

2 Likes
19

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.

1 Like
20

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.