How to create rotating doors?

[Nash]

I've implemented the QC from http://ru1337.com/forums/viewtopic.php?t=18 - after that, I created a brush, turned it into an entity and set it to func_door_rotating.

It rotates, but I have absolutely NO idea how to set the rotating pivot (the hinge).

I've scanned every line in that thread, and the code in that QC over and over again, but I still couldn't figure it out.

Can somebody please help me because I've spent two hours trying to figure it out, but achieved nothing.

[Spike]

The door thingie will rotate around its origin. It's origin is at '0 0 0'.

You can add an origin field to the door entity in the map editor, but then your door will just be displaced and will rotate wildly.
Q2 gets around this issue by the use of 'origin' brushes. The center of the brush is used as the entity's origin.
QBSP doesn't support that though...

lhmap should have something in it somewhere that can be used.
Failing that, just place your door in the editor as if it rotates at '0 0 0', and give it an origin to offset it to where it should really be. This method will give proper rotation, but will make the map look horrible in the editor, and will give inconsistant lighting too.

[Dr. Shadowborg]

You can also do it the oldskool hipnotic(ritual entertainment) / Custents way.

Custents
http://www.3ddownloads.com/telefragged/wartrench/

Scourge of Armagon (Quake Mission Pack 1) QuakeC Source code
http://www.gamers.org/pub/idgames2/more ... /hipnotic/

[Nash]

You can add an origin field to the door entity in the map editor, but then your door will just be displaced and will rotate wildly.

Using Worldcraft 3.3, I selected the door brush, Alt + Enter, added a new key called "origin" and for the value I entered the coordinates of where I want the door to rotate. It doesn't work; the key just disappears and the brush remains unchanged.

Q2 gets around this issue by the use of 'origin' brushes. The center of the brush is used as the entity's origin.

This seems to be the most ideal solution. How do I setup an origin brush in WC 3.3? How would I bind my door brush to this origin brush?

lhmap should have something in it somewhere that can be used

I'm assuming you meant LH's hmap2 utility? I scanned through the readme but I didn't really learn anything about how to setup rotating doors properly...

[Preach]

I find it's usually easiest to make a separate map file for each rotating entity in your map, built so that the origin of the new map is the axis you want it to rotate around. Build it there, light it and texture it, then compile it and stick it in a new directory in maps corresponding to the name of your map. So if you're making e4m1rmx, put the bsp of the door in maps/e4m1rmx/rot_door.bsp.

Then load it into you main map by putting a point entity where you want the axis of rotation, and give that a model key of "maps/e4m1rmx/rot_door.bsp"
Finally, make sure that your code for the rotating door entity precaches whatever is in the "model" field before it sets the model. Normally you don't have to do this as any models built into the bsp are precached automatically.

The advantages to this method are that it gives you good control over the lighting and texturing of the model. The hipnotic method does a similar trick on the compiler side - displacing the brushes by the correct offset so that the axis of the model is moved to the origin, then moving the origin of the entity in the opposite direction. The problem is that it doesn't take care with the texture alignment when you do this, so your model can look broken. The lighting control is important because the lightmap is static, but the object rotates. If the map casts a long shadow across your object, then the shadow won't correspond correctly once your object starts moving. Best to just give the model very uniform lighting that matches the rough levels of light in the map at that point, which is easiest if there's no other geometry.

The downside to this method is that you have more files to keep track of, and if you're trying to place a door that fits seamlessly with the world when closed, you have to work harder to get it set up correctly. At least with worldcraft you can have multiple windows, so construct the door in the map. Then place an info_null on the axis of rotation(for your own reference), copy the door and the info_null to the clipboard, then paste into a new map. Then move the whole group until the info_null is on the origin. Delete the info_null in the new, the original door in the old map, and rename the old map's info_null as func_rotate_door, or whatever classname it had. Then texture, light and compile, good to go!

[Nash]

I think I understand your suggestion... but would that mean if I wanted to make a hundred rotating doors in the map, I would need a hundred separate maps? That doesn't sound very efficient...

[frag.machine]

I think I understand your suggestion... but would that mean if I wanted to make a hundred rotating doors in the map, I would need a hundred separate maps? That doesn't sound very efficient...

Only if you want a hundred different looking doors. It's the same idea behind the regular medikits and ammo boxes: reuse the same .bsp over and over. The only problem I really see in this approach is the already mentioned unrealistic lighting, but I personally could live with that.

[Preach]

100 doors sounds pretty excessive, perhaps you should scale the map back/split it into multiple maps. As frag.machine says, the external bsp method does have the benefit allow you to reuse models. The more standard method of compiling each door into the bsp would usually result in 100 unique model precaches just to deal with your doors. Which isn't to say there's no way to reuse models within maps, just that it's more fiddly than the external file method.

[Sajt]

You could use an invisible BSP push entity for the collision, then a similarly sized reusable MDL on top for the visible stuff.

Advantages:
- model lighting (sampled from lightmap below the model origin)
- you could use different model frames, for an example a metal door that gets dented, or a wooden door that gets splintered (if you want the denting to be instant, you may want to use separate model files rather than animation frames, so it doesn't get interpolated)

Disadvantages:
- if you aren't using real-time lighting, it will probably be obvious that it's a model and not a BSP entity, which might be distracting?
- on old engines you will get the nasty non-perspective-correct texturing
- on old engines you may get the 'disappears when looking up or down' bug? (not sure how that bug selects its victims)

[leileilol]

This seems to be the most ideal solution. How do I setup an origin brush in WC 3.3? How would I bind my door brush to this origin brush?

Tie both the 'origin' brush and the door brush to entity.

That's how it's done in HL and HL2.

[Nash]

This seems to be the most ideal solution. How do I setup an origin brush in WC 3.3? How would I bind my door brush to this origin brush?

Tie both the 'origin' brush and the door brush to entity.

That's how it's done in HL and HL2.

So how exactly do I "tie" an origin brush to the door brush? There's no "tie" function in WC 3.3.

Beyond that, how do I actually create an "origin" brush? Do I create a brush then turn it into an entity brush? What keys do I have to fill in for it to be recognize as an "origin" brush?

[leileilol]

an origin brush is simply a little brush that has the 'origin' texture

To tie it, you'll have to select both your door and this origin brush then make both into a func_door entity together

[Nash]

I had to do some ugly hackery to get my little brush to have the name "origin" (because the texture pack that came with WC3.3 doesn't have such a texture) but I finally did, tied both it and the door brush to func_door_rotating but it's still not working.

The little brush appears with the checkered texture (probably because it thinks a texture is missing) and the door still rotates at the world's origin. :(

Any more ideas?

(Using DP, by the way)

[Preach]

Use the hipnotic code along with http://czg.leveldesign.org/q/czg_rotate.txt, use radiant like your link hints at, or write new code using any of the above ideas.

[Urre]

Nash: uh, if you're using DP, there's no need to use any awful hipnotic rotation code, since DP supports *real* rotating BSP brushes. Just have the door be SOLID_BSP, and rotate it by avelocity in the code, and skip the solidity entities.

I've never had problems making rotating doors using an origin texture.