Origin Brushes

[Baker]

[leileilol]

[Baker]

[goldenboy]

Interesting, thanks.

I can see that neither treeqbsp nor txqbsp support any "weird" content types, only clip. Oh well, after reading your post, a couple light bulbs went on.

How much does the engine have to support? I guess quite a bit more?

Hopefully, we can switch RMQ totally to origin brushes instead of hiprotate one day. We'll have to include the map compiler as well as the engine, but there's not really a problem with that.



Treat origin brushes like clip brushes, it seems:

Yeah, or like hint, skip... what have you.

Apparently, an origin brush is actually part of the rotating object entity:

Yes, that was clear to me before, because of the way you construct them in a map editor. You select both the origin brush and the (door, whatever) and turn both into an entity. Yep. And when the map loads, all that remains from the origin brush is its ... origin, I guess, because it's treated like a special content type. Or maybe it's indeed stripped by the map compiler. Too tired to think about that now.

identifying the center point for rotation

Yeah, that must be done so the engine knows what to rotate the brush around - otherwise it rotates it around '0 0 0'.

It's all a big hack, but a much better one than the hiprotate business. Just thinking about func_movewalls makes me sick.

[metlslime]

well, if you want to get rid of func_movewalls, you need more than just implement origin brushes, you also need collision of AABBs against rotated BSPs hulls.

However, even with the collision hackery, origin brushes would still be a quality of life improvement for mappers.

[Baker]

[MeTcHsteekle]

[goldenboy]

RMQ has the func_door_rotating from Quakelife, and for the rotation testing I used FTE (there is a testmap, of course not compiled with a proper map compiler yet). It does rotate, just not around the right origin. Don't know if FTE supports origin brushes though, might have to use that (cool) tutorial.

Unless someone is faster, I'll start the map compiler hackery in the new year. I'll use bjptools, because I hope it compiles on both Linux and Windows.

The collision is hopefully someone else's problem (looks at engine coders) ... You can get squished all right in FTE, though, thus I thought this wouldn't be a big issue. I'm often wrong though.

[Spike]

Every engine is compatible with origin brushes. There isn't any special code there regarding them.
The only thing engines lack is physics. (some software renderers can be a bit picky about some rotated bsps too however).

Baker, you missed the bit where it offsets all other brushes by the origin.
Or maybe that's already part of the code?

[Baker]

[Spike]

[goldenboy]

http://www.quaketastic.com/upload/files ... otation.7z

There is a bsp, map, wad and progs.dat with source. Good luck hacking the map compiler. I'll gladly join the fray, but not now.

May I suggest Treeqbsp as a basis for the hackery.

May I further pimp bjptools:

http://qexpo.tastyspleen.net/uploaded/1 ... 090908.zip

Um, and to explain a bit better how to make a func_door_rotating without a .def or .fgd file, simply create a func_illusionary instead, change the classname to func_door_rotating, and create a "distance" key and set it to like 100.

There is a QUAKED definition in the code though, which can be copy/pasted and saved as a .def.

gb

[Baker]

[Baker]