Tutorial: Rotating Brush Models for QuakeWorld

[goldenboy]

>So LordHavoc sort of bypassed everything and went straight to the end result. Am I right so far?

Nice job Baker.

What happened so far, I think, is about this:

Urre used me and avirox to experiment using a rotate_* and a point entity (ie no oigin brushes, origin taken from a point entity) and demonstrated that it was already possible, we got stuff rotating this way in Darkplaces with collision. Dunno what QC avirox used. The important part is that the bmodel's name has to start with rotate_*.

Then what LH did was fixing a compiler bug (my testmaps were not working correctly although they compiled fine) to make this work more reliably. Apparently a similar bug exists in treeqbsp (AguirRe's and Tyrann's versions). I don't know which compiler introduced this bug, or if all of them have it. Then LH kept experimenting using a func_wall (ie no rotate_*) with avelocity set and origin set manually (no point entity, no origin brushes).

My point was that using either a point entity or origin brushes is more user friendly because origin brushes are basically how it's done everywhere else, to which Urre and Xavior agreed in principle.

Origin brushes indeed are only used to set the origin for the rotating bmodel and are stripped out (or simply not displayed) when no longer necessary (how you do that is up to you, I guess, from what I saw looking at a Q2 compiler, it did this via having a content type for origin-textured brushes (so they're just invisible and nonsolid in the game I guess). All that matters about origin brushes is that a mapper can use them in a map editor, how and when they're removed (map compiler, engine) is pretty irrelevant AFAIK.

that's my limited knowledge, IDK how LH does it atm in the engine.

Edit: In Half-Life, the rotating brush and the origin brush belong to the same model / entity. Unlike with Hipnotic rotating entities, no target/targetname setup is used. Like this:

http://halflife.qeradiant.com/halflife/bthl6.htm

An origin brush is simply defined as a brush textured on all sides with an origin texture. An origin texture is a texture whose name is "origin". Works like a sky brush.

[Baker]

Avirox, you kick ass in so many ways I'm at a loss for words [like usual] ...

NetQuake prototype adaption from this tutorial:

FitzQuake085 with rotating brush support: download [@Rook --- Download fixed]

Sample rotating object (rotate.bsp and rotate.map compiled with LordHavoc's new version of hmap2): download

The ancient engine rotation tutorial resulted in grenades and rockets not properly colliding and would go thru the entity half the time.

I did NOT do anything equivalent of PM_PlayerTrace (or whatever). That seems to be a prediction related function as far as I can tell and there wasn't an NQ equivalent as far as I can tell.

(One of the superior powers-that-be correct me if I'm wrong ^^)

The Avirox modification version the rockets collide properly. I am concern that the player might not collide properly due to the above but I'm not 100% sure at the moment where I go to fix that.

[Baker]

More notes ...

In the Fitzquake085_Avirox, the ride aboard the rotating entity is a little jerky.

In DarkPlaces, it is not.

So I switched DarkPlaces to the Quake protocol and restarted the map. Jerky.

A guess: MH said something about smooth rotation on his blog, something about changing an angle from a byte to a long and I'm guessing DPP7 has this as well.

Any "QSB standard" implementation should have that protocol modification for smooth rotation.

[LordHavoc]

More notes ...

In the Fitzquake085_Avirox, the ride aboard the rotating entity is a little jerky.

In DarkPlaces, it is not.

So I switched DarkPlaces to the Quake protocol and restarted the map. Jerky.

A guess: MH said something about smooth rotation on his blog, something about changing an angle from a byte to a long and I'm guessing DPP7 has this as well.

Any "QSB standard" implementation should have that protocol modification for smooth rotation.

DarkPlaces uses float origins (no limits) and short angles (256x more precise than quake).

This is all in the DP7 protocol, which offers enough compression to make up the difference in bandwidth - Quake protocol using about +80% bandwidth would not be good, packet overflows would happen much sooner, because the packet size limit can not be increased more than 40% while remaining viable on the internet - 1400-1450 bytes is the highest limit one can expect to survive on the internet, beyond that is likely to be culled by a home router without Jumbo Frames.

[r00k]

the download link to the fitzquake is 404

[Baker]

Download link fixed.


More testing ....

Slight jerkiness aside in FitzQuake085_avirox due to byte angles, player collision with the rotating entity appears super.

Oddly enough, in DarkPlaces if you push against the rotating object enough you can eventually end up passing thru it sometimes. At least in DPP7.

Sample map: rotate2.bsp

More random info ... from Half-Life map c1ao (one of the first ones) here is a random func_door_rotating entity info:

Code: Select all

{
"model" "*36"
"origin" "334 242 -234"
"distance" "148"
"unlocked_sentence" "0"
"locked_sentence" "0"
"unlocked_sound" "0"
"locked_sound" "0"
"health" "0"
"dmg" "0"
"lip" "0"
"wait" "4"
"stopsnd" "6"
"movesnd" "1"
"targetname" "doorwheels"
"rendercolor" "0 0 0"
"renderamt" "0"
"rendermode" "0"
"renderfx" "0"
"angles" "0 0 0"
"_minlight" ".05"
"speed" "55"
"spawnflags" "96"
"classname" "func_door_rotating"
}

Me is looking @ Avirox's Quake-Life qc source and thinking of seeing if I can make a test case func_rotating_door for use with fitzquake085_avirox.exe and DarkPlaces with a Quake 1 test map:

Quake-Life: https://customtf.svn.sourceforge.net/sv ... fe/ql_src/

DarkPlaces uses float origins (no limits) and short angles (256x more precise than quake).

This is all in the DP7 protocol, which offers enough compression to make up the difference in bandwidth - Quake protocol using about +80% bandwidth would not be good, packet overflows would happen much sooner, because the packet size limit can not be increased more than 40% while remaining viable on the internet - 1400-1450 bytes is the highest limit one can expect to survive on the internet, beyond that is likely to be culled by a home router without Jumbo Frames.

Sounds like this is also why pushables are jerky in standard Quake. Not the angles obviously, but the location. [I need to play Nehahra or something with pushables in DP.]

[LordHavoc]

An origin brush is simply defined as a brush textured on all sides with an origin texture. An origin texture is a texture whose name is "origin". Works like a sky brush.

Always processed by the map compiler, engines don't care - the map compiler stores the origin in the bsp file (and oddly enough, q1bsp had an origin vector in the bsp file for exactly this purpose, even before hipnotic mission pack came out, so its hipqbsp compiler already had a place to store the origin).

The map compiler deletes the ORIGIN textured brush automatically, it never makes it to the engine, it is invisible because it does not exist at that point.

Now I must note something - to use an ORIGIN texture, it must exist in the wad file, so someone must add such a texture to one of the wad files they use in compiling each map for it to be available, even though it never actually gets used in the output.

[metlslime]

Now I must note something - to use an ORIGIN texture, it must exist in the wad file, so someone must add such a texture to one of the wad files they use in compiling each map for it to be available, even though it never actually gets used in the output.

Actually you could probably detect the name "origin" and flag it without bothering to dig it out of the wad file, however it makes sense to put it in the wad so that editors can display it in the 3D view (just like clip and trigger, the distinctive image makes it easy to spot)

[Baker]

I compiled a FitzQuake 0.85 "Avirox" with the angles communicated via floats and it was DarkPlaces smooth [a quick research purposes test -- changed ReadAngle and WriteAngle to send floats -- more for 3rd party reading].

Btw ... in my testing, collision with the player is rather solid and generally the few times in FitzQuake 0.85 "Avirox" that interaction with the rotating entity "fails" is when the rotating entity comes down on the player when the player is right up against it and the entity is on the downward rotation at an angle.

Without a doors example map and QuakeC, there isn't really anything to test to see how revolving doors fare. In the early stages of Quake-Life the doors were a bit imperfect, I never got to see the final state of where Avirox got the doors to.

As far as the "jerky" goes ... with FitzQuake protocol 666, the rotating brush doesn't look jerky except if you are standing on it (and not at all if angles are changed to floats). So for rotating map components surrounded by, say, clip [or a trigger_hurt 9999] this would be a total non-factor.

func_door_rotating

{
"model" "*36" // The in-bsp submodel
"origin" "334 242 -234" // Pivot point "hinge" of the rotation
"distance" "148" // Amount that it moves? degrees that it opens?
"unlocked_sentence" "0" // don't know ... ignore
"locked_sentence" "0" // don't know ... ignore
"unlocked_sound" "0" // sound it makes if opened?
"locked_sound" "0" // sound it makes if can't be opened?
"health" "0" // Amount of damage to open if triggered by damage?
"dmg" "0" // Amount it hurts you if in the way?
"lip" "0" // I forget what this is, thinking it is the "overlap"
"wait" "4" // How long after opened that it closes again
"stopsnd" "6" // Sound door makes when done opening?
"movesnd" "1" // Sound the door makes when opening?
"targetname" "doorwheels" // Maybe what opens it?
"rendercolor" "0 0 0" // colodmod ?
"renderamt" "0" // Half-Life equivalent of "alpha" transparency field in Quake
"rendermode" "0" // No idea
"renderfx" "0" // Indicates additive or such?
"angles" "0 0 0" // Angle of door?
"_minlight" ".05" // ??
"speed" "55" // Speed door opens at?
"spawnflags" "96" // ??
"classname" "func_door_rotating" // classname
}

[LordHavoc]

Now I must note something - to use an ORIGIN texture, it must exist in the wad file, so someone must add such a texture to one of the wad files they use in compiling each map for it to be available, even though it never actually gets used in the output.

Actually you could probably detect the name "origin" and flag it without bothering to dig it out of the wad file, however it makes sense to put it in the wad so that editors can display it in the 3D view (just like clip and trigger, the distinctive image makes it easy to spot)

Yes, hmap2 would be capable of such, but only because I rewrote the wad handling from scratch, the qbsp wad handling was... poor

[mh]

Yeah, it's definitely the Angles field in everything I've tested; that quantization to 1 byte is just killing the smoothness. It may be possible with some clever rounding/dithering to improve it and still retain protocol 15 compatability, but full removal would require at least going to shorts.

[Baker]

By the way, writing plug and play QuakeC for progs 1.06 to support for ...

1. func_door_rotating
2. func_wall_rotating (or whatever a better name for this is)

.... is a Quaddicted bounty item now ($25) . Spirit said he is going to work with someone to draw up the "specs".

[Spirit]

Yes, if someone could suggest a decent goal, that would be nice.

[Baker]

Yes, that's the origin brush marker. And no, the traditional Quake compilers don't support it yet. STILL, the origin brush's center X Y Z can be typed into the origin field. The QuakeC followed by an fgd for Worldcraft plus a tutorial or 2 and a sample map is my main priority since this is so close now.









Trying to get there ... this engine modification combined with LordHavoc's modifications to his compiler work very well together.

I noticed that rotation and txqbsp does not entirely. But neither does it not. Txqbsp seems to be compatible with the doors, but not stationary rotating objects that spin.

I did look at the changes LordHavoc made to the compiler to see how extensive the changes were. I about half understood it.

But the QuakeC is the true barrier, atm. Not only does LordHavoc's hmap2.exe compiler support rotation, so does Half-life BSP and txqbsp seems good to go for doors.

And an adaptation of Avirox's QuakeC for Quake-Life plus looking at how Quake 2 handles rotating doors makes the rest of the road map on this clear ...

And for the byte angle versus float angle thing, I have a hilarious solution for a 90%/10% solution to make the jerky be silky smooth for single player without messing with the protocol or the demos (it's kind of like how JoeQuake deals with maxfps )

[Teiman]

this looks seriusly cool.