Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Tutorial: Rotating Brush Models for QuakeWorld Goto page Previous 1, 2, 3, 4, 5, 6 Next

| Inside3d Forums Forum Index -> Programming Tutorials

View previous topic :: View next topic
Author | Message
--- | ---
goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Mon Jan 18, 2010 2:49 pm Post subject: |

Quote:
>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.
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jan 19, 2010 2:50 am Post subject: |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Last edited by Baker on Tue Jan 19, 2010 3:31 am; edited 1 time in total

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jan 19, 2010 3:20 am Post subject: |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Tue Jan 19, 2010 3:23 am Post subject: |

Baker wrote:
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.

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Tue Jan 19, 2010 3:26 am Post subject: |

the download link to the fitzquake is 404

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jan 19, 2010 3:40 am Post subject: |

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:
{ "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/svnroot/customtf/quakelife/ql_src/

LordHavoc wrote:
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.]
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Tue Jan 19, 2010 6:51 am Post subject: |

goldenboy wrote:
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.

Back to top |

metlslime Joined: 05 Feb 2008 Posts: 177 |

Posted: Tue Jan 19, 2010 7:10 am Post subject: |

LordHavoc wrote:
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)

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jan 19, 2010 7:37 am Post subject: |

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

Quote:
{ "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
}

_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Wed Jan 20, 2010 3:30 am Post subject: |

metlslime wrote:

LordHavoc wrote:
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

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Wed Jan 20, 2010 11:49 am Post subject: |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Sat Jan 23, 2010 3:51 pm Post subject: |

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".
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Sat Jan 23, 2010 6:10 pm Post subject: |

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

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Fri Feb 05, 2010 11:46 am Post subject: |

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 )
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Fri Feb 05, 2010 1:52 pm Post subject: |

this looks seriusly cool.

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Programming Tutorials | All times are GMT Goto page Previous 1, 2, 3, 4, 5, 6 Next
Page 4 of 6

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group