Feature Request: Prefabs

[ijed]

This is an idea to introduce a prefeb system that, in theory, should be open-ended for the user and allow for the creation of extremely complex geometry with less manual labour.

I'm not proposing what people might assume for a prefab system, although it is also capable of making lots of complex objects as well.

So, here's the idea:

Most 3d editors allow for the creation of various objects as their base primitives - squares, cylinders, prisms and so on.

TB only has rectangles so far. It'd be nice to include things like prisms, 8 sided cylinders, 24 sided cylinders and so on.

So that when you create a new brush (to whatever scale, as per the current behaviour) you can choose for it to be of various forms.

The most direct interface I can think of for this would be a drop down list - which would also be expandable for the second part of the idea.

Most if not all editors have pre-set primitives that the user cannot modify. This is all fine and well as long as the list is big enough but doesn't allow the editor to grow with the user's skill level.

All the time I'm opening older maps and scraps and copy pasting between them to quickly generate complex yet repeat-use shapes like bending pipes or whatever, it'd be great to be able to automate this process.

So - would it be possible to reference simple .map files (with very few brushes inside) as prefabs?

This is the idea written as a list:

1. There's a new folder inside TB called /prefabs
2. The drop-down list inside the editor allows selection of any of the .map files inside
3. Whilst selected all click and drag created brushes will use that mapfile as a template
4. TB is supplied with four starting prefabs (.map files in the prefab folder) prism, 8-sided circle, spike and arch
5. Rectangle remains the hard-coded base and cannot be edited
6. It is not necessary for new users to do anything with these files
7. Little to no after care is required - if a user makes a prefab that explodes when created then TB returns 'invalid prefab' and creates nothing
8. Prefabs made of multiple brushes become seperate once created
9. Creation of func_ or grouped prefabs is a possibility

A valid prefab will have to follow certain rules, like being on the grid, mainly so that they can be drag created to any size the user wishes. Being an expert user feature a .txt readme in the prefab folder can say something along the lines of 'add new prefabs only if you know what you're doing'.

Returns:
Faster mapping
More complex forms easier to create (eg. CZG style curves)
Ease of format usage - users can drag and drop new prefabs in for individual projects
Low upkeep
Editor grows with user
Should work in parallel with any other system added (eg. grouping) thanks to simplicity

Risks:
Repetitive maps
Users getting frustrated by making multiple bad prefabs (offest by it being an expert feature)

[kduske]

This is exactly the prefab system that TB had in the initial Mac only release ;-)

[ijed]

Bulls-eye!

So, is it going back in?

Obviously you've got a lot of other stuff on your plate to take of first.

[kduske]

Probably not in this form. I would really like to have some notion that will handle groups, instances, layers and prefabs together. Otherwise it be a mess.

[ijed]

Those are a lot of diverse tools you mention, but an overall control for everything should be possible.

Speaking from a WC point of view it has primitives, prefabs and groups as separate tools and works reasonably well. Although I never used the prefab system much.

Primitives I use constantly to shave a few seconds off each object creation process - which is what made me think of combining it with prefabs.

I think the first choice to make that list easier to manage would be to choose between prefabs or instances. They do pretty much the same job. Granted there's some tricks you can do with instancing that prefabs struggle with, but if prefabs were also grouped objects then that's solved.

Question being where would you save group information without making a new map format.

Using Instances in 3dsmax was never very comfortable though. The hierarchy gets broken pretty quickly because its very hard to envision when in the creative process what you'll be using any given object for.

What was useful were instancing-type tools, like Array, which created instances from a selection around a rotating central point, or offsetting them along an axis. I always turned the 'instance' function off there though and just used it when generating repetitive geometry - lines of pillars and so on.

If it was a vote, mine would be for prefabs over instancing. The third option, just doing both, sounds over-complex for the objective.

Musing it over, it's probably best to solve grouping / layers first, since that enables a prefabbing or instancing system and should suggest which of the two is the better option.

</Pre-Coffee Ramble>

[victorfeitosa]

We could start off with brush presets export/importing. Having the ability to export brush prefabs such as stairs, rocks, doorways, terrain, etc, and making it possible to import them in other projects. With the current CSG operations, making complex geometry is a little easier, hence imo the preset feature could be the most realistic right now, since it would fit well and seamless with the current renderer and it would be easier to build within the compilers.

[kduske]

What you're suggesting is already easily done with copy and paste, though. Just store your prefabs in one map file and copy / paste them from there into your actual map.

[victorfeitosa]

Yeah i know, but it's not really usable is it? This method has little control over where we paste it, the presets we have in the map, etc, besides forcing us to have multiple maps open when starting a new map from scratch, selecting the brushes (that can be quite a few for stairs, cilindrical columns, terrains, etc) and then trying to paste them correctly.
It's just an workflow enhancement opinion though, we can stick to the existing workflow with no major issues.

[kduske]

Exporting / importing brushes via map files actually gives you less control than copy and paste. Agree on the selection issue though, that's a bummer. You could mitigate that somewhat by wrapping a preset in a group or layer, though.

[kduske]

@victorfeitosa just wanted to mention this quickly: If you're having issues with quickly selecting a bunch of objects, have a look at the docs (in the latest build). There are two ways of doing this: Selection painting and the new "Select Tall" command in the 2D views. Both are described in detail in the section about "Selecting Objects".

[victorfeitosa]

Thanks! I'm actually doing the grouping method for now, it works well
enough and i can build an asset library .map and then copy/paste as needed
in new maps.

On Fri, Jan 8, 2016 at 7:10 AM Kristian Duske notifications@github.com
wrote:

@victorfeitosa https://github.com/victorfeitosa just wanted to mention
this quickly: If you're having issues with quickly selecting a bunch of
objects, have a look at the docs (in the latest build). There are two ways
of doing this: Selection painting and the new "Select Tall" command in the
2D views. Both are described in detail in the section about "Selecting
Objects".

—
Reply to this email directly or view it on GitHub
#558 (comment).

[motorsep]

Bringing this issue back from the dead, I don't see how copy/paste is a prefab system.

From another issue that was just closed I proposed the following:

For example, a designer should be able to make a prefab (an archway with a door for example) and save it as prefab. Then this prefab (could be just a .map file I guess) is imported into a main .map where it can be cloned and used where needed.

If prefab .map file is changed (changed geometry or textures or triggers or lights or other entities), it should be updated in the main .map automatically (or have a manual button ).

Note that in the main map a prefab would be selected and moved as one entity/group/etc. - it wouldn't be editable or selectable per components that comprise the prefab.

What this allows is multi-user editing. Someone makes prefabs and someone else assembles the main map. It also provides better workflow than copy/paste routine.

[kduske]

Bringing this issue back from the dead, I don't see how copy/paste is a prefab system.

Noone claimed it was. In fact, what was said was that import/export is not a prefab system, because that could just as easily be achieved with copy and paste.

For example, a designer should be able to make a prefab (an archway with a door for example) and save it as prefab. Then this prefab (could be just a .map file I guess) is imported into a main .map where it can be cloned and used where needed.

I don't know if you have read the initial post by ijed, but it explains how a prefab system in TB would work, only I would propose having a prefab browser similar to the entity and texture browsers.

If prefab .map file is changed (changed geometry or textures or triggers or lights or other entities), it should be updated in the main .map automatically (or have a manual button ).

This is called instancing and it's difficult due to three problems. First, entity links, but t his can be solved by automatically renaming all links that have both their source and their target within the prefab. Second, texture alignment, and this is the hard one for map formats like Quake, Quake 2, and Hexen 2 that don't have parallel texture projectionlike Valve 220 maps. I'd like to support those games, however. And third, there's the question how instances should be represented in the map file in a way that doesn't require special compiler support. This could be done with a special type of group (as in, TrenchBroom group), so it can be solved.

What this allows is multi-user editing. Someone makes prefabs and someone else assembles the main map. It also provides better workflow than copy/paste routine.

This is not the main benefit that I see, but if that's what you need it for, then more power to you. I don't see how the prefab designer could make any changes to their prefabs without complete knowledge about every place where they are used though.

But either way, these are all quite difficult problems to solve. This feature is relatively high on my todo list, but I think it will be done in several steps. First only prefabs, then instancing.

[motorsep]

Got it.

Well, technically (and without instancing) I could already group brushes into a prefab within a map, right? (I remember discussing grouping and layers with your early in TB 2.0 development days)

I don't recall if I can group brushes+lights+entities into a prefab (for example, door frame made with brushes, door itself as func_door, torches, lights next to the door frame for torches). So if that's already possible, it would be awesome :) With that, a browser that shows only prefabs (or a filter for regular browser?) would be an awesome addition.

[kduske]

Yes, grouping is done, and you can also include entities and other groups within groups. The browser thing and proper support for creating / editing prefabs would be included in this here feature request.

[kduske]

And groups can contain brushes, of course ;-)

[kduske]

Some more thoughts about instances:

The idea is that you create a group and then duplicate it (with a special command). You can duplicate the group or its duplicates as often as you like, creating new instances as you go. If you edit one of these instances, all of them change. Each instance is saved as a func_group with a special property to identify all "shared" instances. That way, what the compiler sees is a regular map file and you won't need external tools.

When the map is loaded again, the editor collects all instances that belong together (share the same contents), and checks whether they are truly identical. If they are, it discards all but one of them and uses the one as the "master". If they are not, then they have been tampered with using another program, and the editor will warn you about it.

[hrehfeld]

Second, texture alignment, and this is the hard one for map formats like Quake, Quake 2, and Hexen 2 that don't have parallel texture projection

Can you elaborate? I don't quite get what the problem is here. In the end you have a bunch of uv coords per vertex for rendering? How does this cause problems?

[kduske]

Because we're talking about map files. Ever see properly working texture lock for anything but translation in abQ1 editor? That's why.

[JosiahJack]

I have! Worldcraft 3.3 using the QuakeAdapter. J.A.C.K(hammer) editor does as well (still has a few bugs with brush flipping code). These all default to the 220 .MAP format. The following compilers support 220:
ericw's modified Tyrutils 2016
Tyrutils 2014
Bengt Jardrup's enhanced txqbsp 2006

With over a decade of support for the improved texture alignment and better precision UV, I propose that TB2 default to the Valve 220 .MAP format to provide the best experience that Quake mapping has to offer.

[kduske]

With over a decade of support for the improved texture alignment and better precision UV, I propose that TB2 default to the Valve 220 .MAP format to provide the best experience that Quake mapping has to offer.

It doesn't matter what it defaults to. It still has to support the other formats. It's possible that we have to live with inferior support on those legacy formats, though.

[hrehfeld]

Again, can you elaborate?

quake map specs just says

x_off - Texture x-offset (must be multiple of 16)

y_off - Texture y-offset (must be multiple of 16)

rot_angle - floating point value indicating texture rotation

x_scale - scales x-dimension of texture (negative value to flip)

y_scale - scales y-dimension of texture (negative value to flip)

How does this work? Is converting to uv a non-invertable function?

[kduske]

The textures are projected parallel to the the axes of the world coordinate system. That's why they get distorted when projected onto slanted faces.