Scrolling Textures

[4LT]

I wanted gauge interest in a scrolling texture feature. This would allow applying a scrolling effect on either a per-material or per-entity basis.

Proposal 1: Materials similar to Source .vmt or Quake 3 shaders

Materials could be paired with textures to apply effects, such as scrolling

e.g.

{
    "texture" "lava1"
    "scrollv" "0 -100"
}

Pros: Extensible with other effects, consistently re-usable
Cons: Complicated

Proposal 2: Per-entity scrollv scroll velocity parameter

Scrolling is controlled via a key scrollv with a vector value (third component can be ignored)

Pros: Simple, ergonomic for mappers
Cons: Affects entire brush instead of single surface

[4LT]

I'm partial to the per-entity solution myself

[4LT]

@andrei-drexler is there any condition under which you would consider accepting a pull request for adding scrolling textures?

[4LT]

Looking at the alpha and scale code, seems that this would require changing the network protocol to get this to work. :/

[andrei-drexler]

Hey! I appreciate you wanting to help (especially since it's not the first time), and I do think that for a Quake engine also targeting stand-alone projects this would make a lot of sense, but I'm not sure there's a compelling use case for it here when the most popular source ports used to play Quake content (QS, KEX) don't have it. I see this as an alternative to the current practice of using animated textures to emulate the effect, but I don't think mappers would want their waterfalls and conveyor belts to scroll smoothly in IW and not at all in all other engines.

[4LT]

I think there's a perception that IronWail is the the spearhead for new features among many in the community, especially among the QM discord. (As a moderator of said discord, I'm biased, and I recognize that it does not represent the entirety of the Quake nor Quake mapping community). The recent release Dwell v2 recommends IronWail over other engines, and doesn't even mention Kex. Besides, I think if something takes root in IW, there's a good chance it may be backported to VkQuake and QS, e.g. lit water.

And no offense to the Kex port developers, but its had its days numbered since release. It played its part in bringing in new players and adding some cool new levels, but because it utilizes the Kex platform it's permanently locked out of the FOSS ecosystem, and it's not commercially viable to maintain it indefinitely.

Anyways, I don't have much skin in this game, just something I thought would be low-hanging fruit to implement, and it's the one feature Doom has over us Quake people ;) though I was spurred to create this discussion topic after reading a discussion bemoaning the slow speed of animated textures for about the 100th time.

[lavenderdotpet]

please please please add this in!

[perondeidad]

Proposal 1: Materials similar to Source .vmt or Quake 3 shaders

Dude, FTE already has this function since 2009

[hemebond]

And DarkPlaces since ~2004. If people want these advanced features why not attempt to use them at least for the engines that already support them?

[mhQuake]

The traditional way of making special texture-based behaviour in Quake is by having a special character at the front of the texture name: *,!, etc.

That won't work for scrolling textures because the first thing that people are going to want to scroll is water textures, so they can make rivers.

Then for scrolling textures you're also going to want to define the speed they scroll at, as well as the direction.

Then people are going to want a way to switch the scrolling on or off, change the speed, or change the direction via QC.

Then if somebody makes a river they're going to want current and drag, but that's going into physics code now.

At that stage you're implementing a full programmable materials system for something that's a niche feature and that many mappers wouldn't even use.

If you were already adding support for Q3A maps this makes sense, but if you're not then that's a lot of disruptive work for one niche feature. Carmack once wrote that complex features have a cost beyond the time taken to implement them, and he was right. Every future IW development that needs to touch any of the same codepaths would need to take scrolling textures into account and would need to integrate with them. Scrolling textures could wind up becoming a barrier to implementing some future developments, including ones that might be more desirable.

Q3A can do this because Q3A is designed from the ground up for it. But retro-fitting it to a regular Q1 chassis is another matter.

[lavenderdotpet]

Q3A can do this because Q3A is designed from the ground up for it. But retro-fitting it to a regular Q1 chassis is another matter.

this does make me wonder how retroquad does it

[mankrip]

Q3A can do this because Q3A is designed from the ground up for it. But retro-fitting it to a regular Q1 chassis is another matter.

this does make me wonder how retroquad does it

Retroquad uses a very flexible texture naming convention, but most of the downsides mentioned by mhQuake still applies. Even though Retroquad's naming convention supports direction and velocity (and turbulence, and animated frames all together), you need a different copy of the texture for each direction and velocity, which is a waste of RAM and storage.
I do have some plans for a more optimized and flexible scrolling texture system, but as mhQuake pointed out, such a thing requires a lot of work.