News | Forum | People | FAQ | Links | Search | Register | Log in
Dynamic Texture Change
Hello all!

I'm currently working on an outdoor map for Hexen II (Quake 1 based game).

I'd love to see flags, towels or that kind of things floating in the wind to soften the static architectures and make the map more "alive" (without counting only on monsters and skys for seing some movement). One might consider it eye candy, but just as lighting I'm deeply convinced it can make a whole difference in the map atmosphere.

The problem is: I don't feel like building models for such floating items. I don't know how to build models at all, and it seems to me that learning would require so much time and efforts, and would take me so far from actual map editing (which is basically what I like doing)...

More, if I'm correct a model is a pretty rigid structure which cannot be so easily scaled, stretched, put upside down or at any angle to fit specific locations in a map. It's less flexible and easily editable than textures anyways.

Textures are obviously what I need BUT a texture can be either animated (its name starts with "+") or transparent (its name starts with "{").
A texture name's first character unfortunately cannot be "+" and "{" at the same time.
If it's "{" it won't be animated (so won't "float in the wind").
If it's "+" it will be animated but will fall down into the uncanny valley because of the fixed contours of the brush which cannot be faked with transparent pixels.

From my exchanges with Eric W, animated transparent textures would not only require BSP improvements but game engine evolutions too. Wow... Too bad.

Yet my idea is: what if a func_detail_fence had a (non animated) transparent texture that would be switched programmatically in HexenC every n millisecond to the next texture in a series a la "{+0flag", "{+1flag", "{+2flag", etc.? It would end up remaking a self version of the classic animated textures mecanism, but this time compatible with transparency, and with no dependence to BSP or game engines.

The problem is: is it possible from HexenC to access brush properties ("frame"? "model"? other?) to change a texture dynamically? How do such low level properties work actually???

(I talk about HexenC but please feel free to consider I speak about QuakeC if you're more comfortable with it, it's basically the same!)

Thank so much in advance for your expertise and insightful advice!

Use the animated flag models that already exist in custom Quake maps. 
Rotation of models is easy, unfortunately you can’t scale in most engines, so for rubicon 2 flags I made a large and small version in the model editor. Anyway try using those, they are pretty easy to reskin.

Also I agree it’s too bad that you can’t use + for animation and { for transparency mask in the same texture. That ought to be supported, but I would recommend the + come first for legacy engines. 
I don't know how to build models at all, and it seems to me that learning would require so much time and efforts

Just use QME. It's dead easy to use, and it was made for editing Quake models. In a few minutes you can get the job done.

IIRC, using Ctrl+click with the vertex editor allows you to create a new vertex in 3D space. Place the vertexes, create the triangles out of them, put the model flat-posed in a frame called "base", generate the skin vertices from it, paint the skin, create the animation frames, and you're done. 
Not So Fond Of Models 
Actually I'd like to have specific shapes of flags...

What makes me especially want to know more about how textures work is the ridiculously simple func_wall_use function:

void() func_wall_use =
{ // change to alternate textures
self.frame = 1 - self.frame;

It's what makes the func_wall texture switch to an alternate texture when its targetname is fired. It works as long as the initial texture set in the level editor is a "+0something". When the func_wall is activated, the texture switches to the "+asomething".

It even works in toggle mode by the way: you activate the wall and the "+0" switches for the "+a". You activate again then the "+a" switches back for the "+0", and so on.

Obviously from the code above, the "+0" is put in frame #0 and the "+a" in frame #1.
My deduction is that due to texture name's trick (leading "+") "someone" (is it actually the bsp compiler or the game itself?) automatically builds a frame set made of 2 frames, which can then be refered to in the code thanks to the func_wall's .frame property.

If instead of this automatic frame set building I could explicitely build it myself manually, telling how much frames there are and which "{" texture goes into each of them, then I could easily code a function ++ing the .frame property every n milliseconds.
And if I'm correct that would make an animated transparent texture indeed. 
So you want to become an engine coder. 
Redfield Is Already Working On Something Similar 
Not Bad 
nod butt it all 
Wow, it seems like there's suddenly a Hexen 2 renaissance, there's a surprising amount of people working on maps now. 
Wowwww!!! OoO;

What Redfield did is just astounding! :-0
How could I expect to achieve something even 1% as realistic as his curtains?! X-p
I have definitely to ask for his help! Thank you for the tip Icaro! :)

Anyways I would really be interested in understanding how .frame and .model entity properties intimately work, for the sake of knowledge. If anyone can tell more about them... :)

@anonymous: actually I have historically a special affection for Raven's fantasy series (Heretic/Hexen) and I recently discovered a full H2 missionpack mad by an Italian guy called Rino. He really involves into his projects and I love the freshness and personality of his work. He is definitely a source of inspiration for me and that's why I decided to work on H2 too. :-) 
Redfield did it with custom models. 
Which is what I tried to help Inky with. 
Hello All 
Thank you for your advice. I contacted Redfield, indeed, who kindly realized a really awesome job. I am looking forward to showing you the result but the map won't be ready soon! :-)
Nevermind, I wanted to publicly thank Redfield for his (her?) kindness, patience and impressive skills! 
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.