The functionality of func_group

[Spooks]

I've browsed through several of the topics here mentioning the func_group entity. Basically, it's supposed to group brushes in DR like func_static does, but at compile time it turns them back from func_group to worldspawn. The one mention of it from the first page of Google is from a 2006 post on a Doom forum that states func_group was used back in the quake days but it's useless in Doom 3, and the two threads from here confirm it's broken.

 

My question is, does anybody know why func_group won't convert the brushes at dmap? The functionality is supposed to be in the engine code. I think inlining is okay as it is, but func_grouping could be extremely useful for certain situations where you don't want FS brushes to remain entities in-game, but you still need to group them in DR in some way.

 

[Obsttorte]

You can group them using layers.

[Spooks]

Suppose I have four different brushes I put into a layer, and then I want to clone them 100 times around the map while still being able to select each one of those 100 groups. That's 100 superfluous layers right there. Selection sets are the same deal, but even worse, since you have to go through a typed list and there's no way to delete an individual selection set.

 

If you wanted just the same brushes over and over, you obviously export them as a model, yes, but the biggest drawback is that those things are entities and not worldspawn, and there is no way to turn them back to worldspawn without inlining, which spits them back out without collision, among other caveats already discussed in the topics I linked.

 

Layers are for higher-level structuring while func_group is (supposed to act as) low-level organization. I wouldn't even be complaining about the prospect of 100 layers if DR's layer window had some sort of folder structure in, because even that would alleviate some of the problem, if in a non-elegant way. (Layers aren't exclusionary so this is already sort of present, but nowhere in the GUI) Right now the way selection is in DR is Filters > Regions > Layers > Selection Sets > Hide/Unhide. None of those quite fit in the niche that something like func_group would fill. edit: forgot to mention prefabs, we can count those in too, but again, not quite the same

 

We can split hairs about how useful grouping with func_group would be in practice: limited to brushes and not models, same inherent problems func_statics of brushes have with their origin points/rotation, limited usage scenarios - even though you could say the same about selection sets and Region view tbh - and so on. Regardless, I still don't know why it's broken and if it's a trivial enough fix to get it going I think it definitely should be resurrected from the dead.

Edited April 9, 2016 by Spooks

[SteveL]

I've had a look and it's only partly broken. You need to set a spawnarg on worldspawn to activate it: moveFuncGroups 1

 

It's broken because it ignores the entity origin when recreating the brushes as worldspawn. So all the func_groups get centred around the map origin.

 

I'm just having a crack at fixing it in my dev build.

[SteveL]

Now working ok. I only tested basic functionality: cloning the group in DR, the visible model and CM. But it all seems to work as intended. DR handles them ok, at least as far as cloning, retexturing, and manipulating the brushes within the group. The entitiy doesn't spawn, although it issues a console warning that we can suppress. It works for combos of brushes and patches too.

 

I've not tested everything but I'll put in on the tracker for us to try in 2.05.

[Spooks]

Thank you, Steve. It's good to know it's in the pipeline. Whenever I get around to it I may post some examples of practical applications of func_groups in a mapping workflow.

 

Edit: Though, off the top of my head, the biggest advantage would be func_static-like flexibility in the editor, with the option of drastically decreasing entity counts inflated by architectural pieces, allowing for a lot more leeway when it comes to modular building.

Edited April 9, 2016 by Spooks

[SteveL]

Good news, after discussion with grayman (who's curating the 2.04 beta build) we can include this fix in 2.04. It sounds like a useful tool to me, for big maps anyway. Mappers can create their own modules in DR and clone them like any entity. In game, they won't increase the entity count, and you can have as many copies as you like in a visleaf without adding any draw calls.

[Geep]

@Spooks

Sorry for posting to this old thread, but I'm using it as a basis for a wiki page about func_group. Could you take a look at it and see if it needs changes? Thanks

https://wiki.thedarkmod.com/index.php?title=The_Parts_and_Whole:_Func_Group

[Spooks]

I may see about it in a day or two but right off the bat I am pretty sure func_group never got around to being implemented. SteveL stopped posting on the forums altogether about a year after that post and I've not heard hide nor hair from the feature. I remember testing it, though after five years it's difficult to recall whether it was in 2.03 or 2.04. It "worked" in a very gimped way and I've not touched it or used it in my mapping since.

The whole functionality of it has largely been superseded by Dark Radiant's grouping feature, though of course my hope was that this was going to be a wedge for the possible implementation of instanced map regions/map section nesting, like Valve's Hammer editor had (and there's been discussions of that very thing in the forums, recently too I think). The wiki article might simply be useless but you or I could give the func_group thing a whirl in-game and actually check to what extent it works. This week's busy though so unless there are any brave experimenters it will take me to the weekend to get to it.

[Spooks]

Okay, @Geep , I did a quick test and I've remembered it wrong, it seems to work for what it was supposed to do. It must be that DR's grouping was just sort of "good enough" for me and I forgot about these. I also re-read what I had written in the thread and I remember that my "100 groups" comment was clearly meant not as a wedge for instancing but as an aid in modular building. Because models don't seal geometry func_groups can be a good way to make brush-based kit pieces or at the very least standardized sets of caulking and monster-clipping brushes. If you have a good idea of what the scale of your map is going to be, you can copy-paste func_groups and conceivably greybox more efficiently, too.

The one thing I figure you can add in the wiki page is mentioning that you can use func_groups to set a permanent rotation origin point on a bunch of brushes and do more advanced rotation that way. The bit about the entity filtering is also true but all the while I do still have, from back in the day, a custom filter that only shows func_groups. "Entity class .* hide", "entity class func_group show". Don't remember how useful it was, but it may also be worth mentioning that a user can just have a custom filter that shows only them and worldspawn (effectively "Filter All Entities Except func_group") - you only need to add a third rule that says "entity class worldspawn show".

Edited April 7, 2022 by Spooks

[Geep]

9 hours ago, Spooks said:

The one thing I figure you can add in the wiki page is mentioning that you can use func_groups to set a permanent rotation origin point on a bunch of brushes and do more advanced rotation that way.

I think you're saying is, with Groups, the rotation point (origin) is automatically determined and can't be changed, but with func_group, it can be.

My chief concern about func_group is that you would move a func_group around loosey-goosey as an entity, but then it would end up off-grid when auto-converted to worldspawn, causing headaches. Unless you can snap a func_group to a grid? Otherwise, limits use in, say, modular building.

Thanks for the feedback. I can add something about the custom filter, too. I'm not going to over-sell func_group