New Feature: Layers

[Domarius]

@greebo - that's exactly what area's solve

@orb - hm, well as long as you can select a large box of things and assign them to a layer, then the functionality is the same.

 

Big question though - do mappers desperately WANT to select groups of objects in different regions? Because AFAIK, the doom 3 level editor already has the "area brush" functionality, which works just like DromEd's - not only filters things visually but also filters them from the BSP compilation process, speeding up development times when you're just working on one segment - don't have to wait for the ENTIRE map to compile just to see one room.

[sparhawk]

It doesn't matter if the individual objects are in different regions, because as soon as you want to select individual objects you can't use the area brush method effectively, and YES, this is definitely wanted.

[Komag]

In Dromed you could filter stuff out, like all objects, all lights, all room brushes, etc, and I remember finding it helpful in addition to using area brushes for sectioning parts off. They're both useful I believe, in perhaps similar but distinct circumstances.

[OrbWeaver]

You can already do that with the current filter system.

[Komag]

So then the layers thing would be like a custom filter system you can define yourself? I see it being useful for the advanced mapper

[OrbWeaver]

So then the layers thing would be like a custom filter system you can define yourself? I see it being useful for the advanced mapper

 

No, they have different functions. The filter system shows objects based on their class or texture (e.g. hide all patches, show only the worldspawn etc), whereas layers allows user to define their own arbitrary groups of individual objects (irrespective of type or class) to be hidden and shown.

[sparhawk]

Currently you can only select individual objects and hide them. When you unhide them, ALL objects are shown again, no metter how you hid them. The layers would allow you to put groups of items into different layers and then switch them on/off individually.

 

For example, I use to have all lights in one layer in Blender, so I can switch them off all at once. You can also put objects in more then one layer, so they will appear whenever one of the active layers is visible. When this feature gets implemented, I would really love it if it were implemented similar to Blenders layer system. The rule would be pretty simple IMO. An object is visible, when it is at least in one layer that is visible, regardless of how many layers it is in.

 

http://de.wikibooks.org/wiki/Blender_Dokum...:_layer_manager

[greebo]

Moving objects to more than one layer? And how would this be easily assigned / or removed again from all its layers? Sounds a bit too complicated IMO.

[sparhawk]

Same as in Blender. Select an object, and when you call the layer config dialog, it shows in which layers they are currently assigned. Then you can switch on/off the layers that you don't like.

 

Implementation wise, you can set a userconfigurable number of layers. Doesn't really matter, you can also hardcode it. Each object gets a pointer to a boolean array which is set to NULL, which means that the object is not assigned to any layer. When the user adds an object to any layer, you can allocate an array with the number that is defined in the options and initialize it to false. Then the user can set the layer flag individually.

 

When the user changes the number of possible layers, it only takes effect after the aplication is restarted. This shouldn't happen to often anyway, and you don't have to worry to update the arrays in the already assigned objects. Layers are saved to the mapfile (or the secondary option file). If the user changes the layers to a higher number then before, the extra layers, that were added, are unassigned. If the user lowers the number, then the extra layers are simply removed.

Seems pretty straightforward to me IMO. For the dialog to configure the layers, you can simply use a listbox kind object. That's why I said it doesn't really matter wether the user can change the number of layers or wether the are hardcoded, because you wil have a variable somewhere that tells how many layers are available, so this wouldn't change the code one bit.

 

For faster access, when displaying the objects you can consider to add an additional boolean variable to an object, that determines wether the object has ANY layers activated or not. Or you might free the layer array when all layers are deactivated and set the arraypointer to NULL, which will save you the extra boolean and has the same effect.

 

So it should work like this:

LayerNum = N

1. User clicks on button to add object to a layer.

2. Dialog shows N elements with checkboxes.

3. User clicks on checkbox to add the object to this layer.

4. If the arraypointer is NULL, allocate an array with the size of N

5. Set the index of the checkbox to true.

6. When the user presses OK and discards the dialog, check wether the object is still in ANY layer. If yes, you are finished, if no then free the array and set the arraypointer to NULL.

 

When displaying the objects you simply loop over all the objects and check if the arraypointer is NULL. If yes it is to be displayed, if not then you must loop over the array and check wether the active layer is visible and this object belongs to it.

[greebo]

I'm a bit sceptical, because having an array for each and every object could have an impact on rendering performance which is already lame, even without layers.

 

Seems pretty straightforward to me IMO.

Please try to take a look at the DarkRadiant source and tell me that again.

 

Anyway, apart from assigning an object to layers, which could admittedly be implemented relatively easy (boolean array or not), this entails changes to the selectionsystem as well and that's where the fun starts. I would definitely not consider this easy, but feasible nonetheless.

[sparhawk]

I'm a bit sceptical, because having an array for each and every object could have an impact on rendering performance which is already lame, even without layers.

 

Yeah, that mgiht be the case, But if you implement the layers at all, you already have that problem. It doesn't matter so much if an object is in more than one layers, because this is just an indexed access. You don't need to loop over the layer array as you should know which layers are visible at any given moment. So the user selects which layers should be visible, then you can do

 

obj = invisible;
for(i < layers;)
{
  if(mLayerArray == NULL && mLayerArray[layer] == true)
  {
  obj = visible;
  break
  }
}

 

Well, I know that it might invovle a little bit more, but checking the objects should not be more than this.

 

Please try to take a look at the DarkRadiant source and tell me that again.

 

After seeing the constant stream of complaints from Orbweaver, I rather not .

 

I'm quite happy that the SDK is rather well designed. Something that is not taken for granted on all commercial code.

 

Anyway, apart from assigning an object to layers, which could admittedly be implemented relatively easy (boolean array or not), this entails changes to the selectionsystem as well and that's where the fun starts. I would definitely not consider this easy, but feasible nonetheless.

 

Well, I can't say much about that. I assume that there is already an selection system, but how much work such a change involves I can't say.

[greebo]

Yeah, that mgiht be the case, But if you implement the layers at all, you already have that problem. It doesn't matter so much if an object is in more than one layers, because this is just an indexed access. You don't need to loop over the layer array as you should know which layers are visible at any given moment. So the user selects which layers should be visible, then you can do

It would also be possible to cache a bool visible that gets updated as soon as any change to the layering system is made. All the nodes get updated as soon as one node changes its layer status.

 

obj = invisible;
for(i < layers;)
{
  if(mLayerArray == NULL && mLayerArray[layer] == true)
  {
  obj = visible;
  break
  }
}

You probably mean mLayerArray != NULL, don't you? Anyway, I get your point.

 

I'm quite happy that the SDK is rather well designed. Something that is not taken for granted on all commercial code.

If you still need more coders after I'm done with my diploma, I'd be happy to take a look at SDK coding. If you'd let me, that is.

 

Well, I can't say much about that. I assume that there is already an selection system, but how much work such a change involves I can't say.

It won't be long and we will know.

[sparhawk]

It would also be possible to cache a bool visible that gets updated as soon as any change to the layering system is made. All the nodes get updated as soon as one node changes its layer status.

 

Yeah. I think there is definitely some room for optimization. My proposal was only a first draft anyway.

 

If you still need more coders after I'm done with my diploma, I'd be happy to take a look at SDK coding. If you'd let me, that is.

 

Sure! Why not?

 

It won't be long and we will know.

 

[OrbWeaver]

How about this:

 

A GlobalLayerManager object maintains a map of named layers (with names held as strings) to the list of scene::Nodes which are in those layers. Simultaneously the scene::Node object is extended to maintain a list of layers that the object is a member of, so you have a two-way mapping.

 

When you select an object and activate the "Layers" command, a dialog is displayed which lists the current layers the object is on, and the available layers. The status can be changed for each layer to allow the object to be added or removed from that layer, and layers can be added or removed also. When an object is added to a layer, the GlobalLayerManager's list for that layer is appended with the new object, and the object's own layers list is appended with the new layer. A similar process is used for removing an object from a layer.

 

During rendering, each object knows which layers it is on, and queries the GlobalLayerManager to check whether each layer is visible. If at least ONE layer is visible, the object will be rendered, whereas if NONE of its layers are visible it won't be. A second dialog is needed to configure the visibility of each layer during rendering.

 

This requires no fixed-size arrays or preference options to configure the number of layers, and allows users to create layers named however they wish according to their mapping needs.

[sparhawk]

Yup. Sounds even better. If theobjects all derive from the same base, this should be the best solution.

[greebo]

Yes, this sounds convenient. I would still consider caching the visibility flag of each node to speed up the node traversal.