Allow Linked Groups to Reuse Mesh Resources

[RhapsodyInGeek]

I've been looking into how Linked Groups are treated in the Map File, along with Groups, and I'm thinking we should think of them as separate features even though they're intrinsically... linked.

I've come up with some ideas after studying map files generated by Trenchbroom. One of my observations is that it's important to differentiate between Groups and Linked Groups, despite Linked Groups' requirement of being in a Group.

• Groups should be optionally about Node Tree hierarchy
• Linked Groups should be about Mesh Resources.
• Both Group and Linked Group implementations should not care about any other entity properties (including protected properties) beyond what is needed for Node Tree Hierarchy and Mesh Resources respectively. Qodot doesn't need to know a property is protected in a Linked Group for these purposes.

I made a basic map file that uses 2 different Groups, with one of the groups being duplicated as a Linked Group. The Group contains a structural brush and a func_detail brush entity with a single brush. One of the Linked Groups has been rotated 45 degrees on the Z axis.

This is the generated map file:

// Game: Quake
// Format: Valve
// entity 0
{
"mapversion" "220"
"classname" "worldspawn"
"wad" "wads/id1.wad"
}
// entity 1
{
"classname" "func_group"
"_tb_type" "_tb_group"
"_tb_name" "TestGroup"
"_tb_id" "5"
"_tb_linked_group_id" "{0de2d1ec-0720-4e0a-b8ab-b4acfc3b9f7a}"
"_tb_transformation" "1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1"
// brush 0
{
( 0 -192 -96 ) ( 0 -191 -96 ) ( 0 -192 -95 ) floor01_5 [ 0 -1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 0 -192 -96 ) ( 0 -192 -95 ) ( 1 -192 -96 ) floor01_5 [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 0 -192 -16 ) ( 1 -192 -16 ) ( 0 -191 -16 ) floor01_5 [ -1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 192 0 0 ) ( 192 1 0 ) ( 193 0 0 ) floor01_5 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 192 0 0 ) ( 193 0 0 ) ( 192 0 1 ) floor01_5 [ -1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 192 0 0 ) ( 192 0 1 ) ( 192 1 0 ) floor01_5 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
}
}
// entity 2
{
"classname" "func_detail"
"_tb_group" "5"
// brush 0
{
( 80 -112 0 ) ( 80 -111 0 ) ( 80 -112 1 ) metflor2_1 [ 0 -1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 80 -112 0 ) ( 80 -112 1 ) ( 81 -112 0 ) metflor2_1 [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 80 -112 0 ) ( 81 -112 0 ) ( 80 -111 0 ) metflor2_1 [ -1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 112 -80 32 ) ( 112 -79 32 ) ( 113 -80 32 ) metflor2_1 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 112 -80 16 ) ( 113 -80 16 ) ( 112 -80 17 ) metflor2_1 [ -1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 112 -80 16 ) ( 112 -80 17 ) ( 112 -79 16 ) metflor2_1 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
}
}
// entity 3
{
"classname" "func_group"
"_tb_type" "_tb_group"
"_tb_name" "TestGroup"
"_tb_id" "6"
"_tb_linked_group_id" "{0de2d1ec-0720-4e0a-b8ab-b4acfc3b9f7a}"
"_tb_transformation" "0.7071067811865468 0.7071067811865483 0 -127.99999999999983 -0.7071067811865483 0.7071067811865468 0 263.76450198781714 0 0 1 0 0 0 0 1"
// brush 0
{
( -263.76450198781714 128 -96 ) ( -263.0573952066306 128.7071067811867 -96 ) ( -263.76450198781714 128 -95 ) floor01_5 [ -0.7071067811865482 -0.7071067811865467 0 32 ] [ 0 0 -1 0 ] 0 1 1
( -263.76450198781714 128 -96 ) ( -263.76450198781714 128 -95 ) ( -263.0573952066306 127.29289321881362 -96 ) floor01_5 [ 0.7071067811865467 -0.7071067811865482 0 21.019333 ] [ 0 0 -1 0 ] 0 1 1
( -263.76450198781714 128 -16 ) ( -263.0573952066306 127.29289321881362 -16 ) ( -263.0573952066306 128.7071067811867 -16 ) floor01_5 [ -0.7071067811865467 0.7071067811865482 0 -21.019333 ] [ -0.7071067811865482 -0.7071067811865467 0 32 ] 315 1 1
( 7.764501987817141 128 0 ) ( 8.471608769003694 128.7071067811864 0 ) ( 8.471608769003694 127.2928932188133 0 ) floor01_5 [ 0.7071067811865467 -0.7071067811865482 0 21.019333 ] [ -0.7071067811865482 -0.7071067811865467 0 32 ] 45 1 1
( 7.764501987817141 128 0 ) ( 7.764501987817141 128 1 ) ( 8.471608769003694 128.7071067811864 0 ) floor01_5 [ 0.7071067811865482 0.7071067811865467 0 -32 ] [ 0 0 -1 0 ] 0 1 1
( 7.764501987817141 128 0 ) ( 8.471608769003694 127.2928932188133 0 ) ( 7.764501987817141 128 1 ) floor01_5 [ -0.7071067811865467 0.7071067811865482 0 -21.019333 ] [ 0 0 -1 0 ] 0 1 1
}
}
// entity 4
{
"classname" "func_detail"
"_tb_group" "6"
// brush 0
{
( -150.62741699796953 128 0 ) ( -149.92031021678298 128.70710678118658 0 ) ( -150.62741699796953 128 1 ) metflor2_1 [ -0.7071067811865482 -0.7071067811865467 0 32 ] [ 0 0 -1 0 ] 0 1 1
( -150.62741699796953 128 0 ) ( -150.62741699796953 128 1 ) ( -149.92031021678298 127.2928932188135 0 ) metflor2_1 [ 0.7071067811865467 -0.7071067811865482 0 21.019333 ] [ 0 0 -1 0 ] 0 1 1
( -150.62741699796953 128 0 ) ( -149.92031021678298 127.2928932188135 0 ) ( -149.92031021678298 128.70710678118658 0 ) metflor2_1 [ -0.7071067811865467 0.7071067811865482 0 -21.019333 ] [ -0.7071067811865482 -0.7071067811865467 0 32 ] 315 1 1
( -105.37258300203047 128 32 ) ( -104.66547622084393 128.70710678118652 32 ) ( -104.66547622084391 127.29289321881345 32 ) metflor2_1 [ 0.7071067811865467 -0.7071067811865482 0 21.019333 ] [ -0.7071067811865482 -0.7071067811865467 0 32 ] 45 1 1
( -105.37258300203047 128 16 ) ( -105.37258300203047 128 17 ) ( -104.66547622084393 128.70710678118652 16 ) metflor2_1 [ 0.7071067811865482 0.7071067811865467 0 -32 ] [ 0 0 -1 0 ] 0 1 1
( -105.37258300203047 128 16 ) ( -104.66547622084391 127.29289321881345 16 ) ( -105.37258300203047 128 17 ) metflor2_1 [ -0.7071067811865467 0.7071067811865482 0 -21.019333 ] [ 0 0 -1 0 ] 0 1 1
}
}
// entity 5
{
"classname" "func_group"
"_tb_type" "_tb_group"
"_tb_name" "TestGroup2"
"_tb_id" "7"
// brush 0
{
( 0 0 -16 ) ( 0 1 -16 ) ( 0 0 -15 ) metflor2_1 [ 0 -1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 0 0 -16 ) ( 0 0 -15 ) ( 1 0 -16 ) metflor2_1 [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 0 0 -16 ) ( 1 0 -16 ) ( 0 1 -16 ) metflor2_1 [ -1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 192 192 0 ) ( 192 193 0 ) ( 193 192 0 ) metflor2_1 [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 192 192 32 ) ( 193 192 32 ) ( 192 192 33 ) metflor2_1 [ -1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 192 192 32 ) ( 192 192 33 ) ( 192 193 32 ) metflor2_1 [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
}
}

As you can see, even though the func_detail is grouped with the structural brush, they get split into two separate entities: func_group and func_detail. However, the func_group has a _tb_id property, and the func_detail has a _tb_group property with a matching value.

The linked func_groups are interesting in that they have both a __tb_linked_group_id and _tb_transformation, while the unlinked func_group omits these. Despite having the _tb_transformation property, the brush coordinates are still different, which makes sense as a BSP compiler is not going to have any idea what those things are and only wants the brush plane values.

That said, we can use these key values to find links between the groups. Qodot builds meshes and collision on the request of the entity being generated, meaning we should be able to request key value pairs of that entity prior to mesh generation. An array or dictionary could be used to keep track of the Groups as they come. Each brush entity could then check if it has a matching _tb_group value with the Groups Array, and if that Group entry has a _tb_linked_group_id then try to reuse the saved mesh resource.

This would probably work fine for structural / worldspawn brushes, but I'm not sure how to identify which sub entities match with a previous group.

Say you have 1 func_group with its own mesh and 2 func_details with their own meshes. Since the func_details have no other identifiable information and you can't guarantee entity order in a generated map file, how do you identify which func_detail mesh resource gets applied to which func_detail in another Linked Group? Only thing I can think of is matching brush count and brush attributes, which means we'd still need to generate the meshes, but we'd still be able to replace them after the fact and unused unsaved resources are freed / deleted.

That's really the biggest hurdle in all of this I think. The transformation matrix is more a matter of coordinate conversion like we already do between origin and angles, but it handles us modifying our MeshInstance3D's local transform (that way we don't lose the transform in the parent entity). Everything else is doable, just a lot of work.

Unfortunately, we can't simply duplicate the collision Shape resources. While position and rotation aren't problems, CollisionShape scaling isn't really supported in Godot (causes problems) so we shouldn't use it with Qodot.

A simpler solution I suppose would be to "just reuse func_group mesh resources", but it feels rather incomplete to leave it at that.

Anyway, those are probably most of my current thoughts on the subject.

[yankscally]

Just to add something -

It would be amazing if we could decide somehow when linked groups use multimesh. There's some cases when using multimesh will cause performance problems if you are trying to render stuff that is far away from each other.

It really makes sense to use multimesh for small repeatable detailing like the posts in fences, bars in a jail cell, a bunch of window frames, lots of neighbouring columns - the entire linked group set being all of 1 multimesh instance. But there may be lots of other uses for this, even for large meshes (thinking of distant modelled skyscrapers at the boundary similar to a cs2 map). Having the choice to use multimesh would be better than making it a default behaviour for all linked groups

[EMBYRDEV]

Another thing to add that might slightly complicate things is that I plan on adding the ability to split the CollisionBodies generated as a part of the map building process by the material that is assigned to them (ie, the arraymesh surfaces) so whatever kind of resource sharing that goes on will need to be capable of handling that too. (this is important so that developers can detect which kind of surface they hit)

I think an initial first step that doesnt even take into account the concept of linked groups is to do this automagically behind the scenes where we take all the non worldspawn brush entities and hash the arrays of the mesh and if it matches one we already have then make them share that resource but as you say that is rather incomplete.