Feature Request: WorldSpawn Patch Definition support

[fhomolka]

Hello!

This feature request might seem as a bit of a word soup, so I'd like to preface that in this context, WorldSpawn refers to this map editor.

Folks over at Vera Visions have extended patch definitions in order to use them for texture blending. Eukara, one of the devs, recently wrote a specification for patchDefWS which is available here.

The only engine that I'm aware that supports this is FTEQW (also available here).
This is also where my personal interests lie in, since I'm using FTE for my own games and would love to use this feature, but avoid using WorldSpawn. Folks at Vera Visions would also jump over to using NetRadiant-Custom if it supported this.

NR-C already supports the rest of the features, and will load any map that doesn't use WorldSpawn patches.

An example map that won't load is available here.

Now, I don't want to just dump this onto you. I'm willing to participate in helping out to see this come to life. However, I'm not familiar with codebase of any Radiant, so if you're fine with helping out in implementing this, I would be very grateful!

[Garux]

Patch import/export is more or less modular https://github.com/Garux/netradiant-custom/blob/master/radiant/patchmodule.cpp#L153, so you can add this relatively trivially.
However i see way more engine specific mods in WS, which likely wont let NRC to be comfortable replacement.

[fhomolka]

Unless I forgot about something important, patches are the only necessary feature. Did you have anything specific in mind?

[Garux]

Materials and models out of highlighted features.
From patchDefWS description i don't get why it is better than using alphamod/colormod brushes. They have more preview points and work for patches, brushes and models. With proper tooling and preview it would be cool to have, but with sensitive drawbacks: being patch only, which are rectangular only, and breaking .map compatibility.

[Xylemon]

@Garux Hi, I'm one of the developers at Vera Visions, specifically the level designer. I wanted to express why we developed this patch format:

We ourselves used brushes with texture blending in our game, the same that Quake 3 provides. This "worked" but it was down right awful for scaling large levels. If you have a ton of large terrain, managing and blending tons of brushes is down right inefficient in terms of volume and user management. That's why we created PatchDef3WS, to give you Source and IWEngine style texture blending on patches (displacements in Source). Now you can have a giant open outdoor areas, with floors or mountains being made of patches that are easier to manipulate, texture blend, and manage. Especially today, Valve has started using displacements on walls as well with nodraw brushes now being used more often for VIS calculation.

I hope that clears up our reasoning for this. As a level designer myself, I do not miss managing hundreds of brushes for these kinds of situations.

While supporting PatchDef3WS itself is easy, the bigger challenge would be things like how the UI in NRC is going to even support such a feature, and how invasive our needs could be to your project. If you're interested, we would actually like to talk to you @Garux more directly on our IRC or Matrix about what we've been trying to do with our editor, tech, and games. We're trying to achieve certain goals with id Tech, and ideas/feedback from others is always useful for achieving sensible standards and avoiding reinventing the wheel.

[Garux]

I mean using Doom3 patches + alphamod brushes looks more optimal, than current thing w/o preview and tooling, unless you are modifying your terrain daily.
There is general idea to simplify terrain creation and blending for supported games, but none of implementation ideas is perfect:

• storing alpha values w/o dirty tricks, like data in comments or separate file breaks compatibility
• usable atm patch+patchmeta+subdivision control: bad lightmapping and patch subdivision overflow in engine, when is huge
• reviving id's terrain primitive: matrix of points, turned to brushes by compiler, would allow deleting some triangles; -compatibility
• process patches inside entity with special flag like terrain primitive: what about alpha and max 31x31 matrix
• compiler-side autoblend and autoshaders for brush terrain based on painted textures: even with greatly simplified editing in NRC, mesh is still simpler and safer to work with, also lower degree of blending control

I'd like to talk with you guys too, is this correct chat? irc://irc.frag-net.com:6667/#wastes

[fhomolka]

That's one of them, yeah
irc.quakenet.org/#fte is another one, that one is engine related.

[Xylemon]

Yeah either of those servers work. Spike (the creator of FTE), eukara (the other developer at Vera Visions), and I will be on either IRC server, and while we have a bouncer setup in those channels, we're usually active from 20:00 to 08:00 UTC. Look forward to talking with you!

[MoritzJT]

@Xylemon if you're interested - I made a Blender Geometry node Setup that generates a trisoup mesh for FBX export with prebaked vertex RGBA or alternatively can export as brushwork with color/alphamod volume brushes generated from the vertex colors on export - I need to dig it out but if this can help you along, let me know - If the IW format ever ends up in NRC I'm of course looking forward to it - same as the one from ubertools branches.

[fhomolka]

It's been a while, I've been working on and off on this for a while. @eukara and @Xylemon helped out a lot with the process.
The only thing remaining, I believe, is the editor for the values inside patch vertex. Worldspawn uses the Patch Inspector window to manage that, as it just adds RGBA values next to the pre-existing XYZST. However, I am unable to find that inspector in NR-C.
Was it removed? Merged into another window?

[Garux]

Functionality was mostly merged to Surface Inspector. STs are editable in 3D view.

[fhomolka]

In that case, I'll have to think about how to non-intrusively introduce that into NRC.
I mostly just need the detail part (just the RGBA fields):

Would it be weird to put that into the surface inspector as well?
If I can get the map type, I'm guessing I could not draw that part if the map type isn't ws?

And if this is something that's just too big of a change for NR-C, I suppose it'll stay on my fork,

[Garux]

Optional drawing in SI is okay. There are many possible ways to represent and interact with this property, i think synergy of implementation simplicity and usability would be RGBA field with color chooser showing/applying color of selected vertices.