[Request] Preserve Brush layers, tags and scripts in generated meshes

[f1ac]

It would be great to generate multiple meshes based on brush layers, tags and scripts, like it is done now with material on per-surface level. It would be useful for a ton of use cases, for example one can implement different footstep sounds per surface type, or different interactions with different layers (climb brushes marked with specific layers, shoot through another ones, SteamAudio uses attached scripts to determine acoustic material). Lots of assets already use one of these three methods to customize geometry interaction.

[LogicalError]

Interesting idea!
I've been working on a new low level interface to the CSG algorithm and I reworked some stuff, that luckily would make something like this relatively easy to do (from a technical point of view at least, ux wise it's still quite a bit of work)
Thanks for the suggestion :)

[LogicalError]

One thing I've been thinking about is this ..
Right now the model is both a complete csg-tree, containing all the brushes and operations that interact with each other. But it's also the definition of which brushes end up in the meshes generated for that csg-tree.
I want to split them up into two pieces .. one is the csg-tree, and the other are 'selections' or 'views' (I have no name for this yet) into the csg-tree, which define the scope of the meshes that will be generated.
The idea was that you could put rooms behind windows in different meshes than the outside of a building, which is better from an occlusion culling point of view, yet all the brushes would still interact with each other.
.. not completely sure how to easily combine this with layers/tags/scripts in a simple ux though
we don't want to accidentally end up with loads of tiny meshes after all

[f1ac]

By default brushes are untagged, in Default layer and contain no additional scripts, so they won't be split. If someone changes something i think it would be a good idea to add a big red warning to shape inspector and/or model inspector. In the latter case it could be a warning with stats on generated meshes. Oh, and while I was writing these lines I had a thought that it would be good to incorporate static flags into this logic too.

[LogicalError]

Right now I'm pretty sure the brushes are automatically kept up to date with the layer/tag/flags of their model. Might make sense to separate them this way? But it needs to be easily debug-able though ..

[f1ac]

On the second thought, it will probably be enough to preserve layer/tag/flags for ['selections' or 'views'], if they work as a root for several brushes and a separate mesh is generated from them. This will allow to avoid implementation complexity and mesh count explosion. Not sure about the scripts though, the only thing that I can think of is to create a script which could be assigned to these views and add specified scripts to its meshes along with a preset.

[LogicalError]

(I just deleted the comments where you changed the text into "[deleted]")

[LogicalError]

I'm not entirely sure what you mean with scripts in this case, can you elaborate what you mean with scripts in the context of generating meshes?

[f1ac]

I mean adding components for generated meshes based on 2018.1 presets. Something like this:

public Preset preset; //somewhere in 'selection' entity or where applicable, users specify this
...
preset.ApplyTo(generatedMesh); //during mesh generation, adds the component along with values from the preset