Rotation Origin Point

[MadGypsy]

I am working on some QC. I know how to make something rotate and I know how to mathematically figure out what point in space I want it to rotate around. What I can't figure out is how to tell QC that I want it to rotate around that point.

If anyone knows the script/equation to produce rotation around a remote point in space I would be hella appreciative for the info.

Note: No info_null or rotation_info's. I have another way to get my origin already, I just don't know how to add that origin into the rotation.

thanks.

[Baker]

http://www.quake-1.com/quakec-gallery/RQP_0.5.4.zip

Has a rune called "missile shield" which has at least one rocket that orbits the player.

[That mod also has a power-up that causes ammo is to seek an enemy. Like throw a grenade towards a corner and the moment it "sees" an enemy, its next bounce it curves.]

[Seven]

Hello MadGypsy,

First of all, try what Baker suggested.

If that doesnt help, I think I found a good thread for you to read:
The thread-title might be misleading, but the thread itself discusses exactly what you want to achieve: click
It will guide you through several ways of doing it.
As you already know, reading is fun and entertaining and especially when you read posts from those amazing people at inside3d.
(By the way, posting your questions there directly will most probably lead to faster and specific responses)

Also be sure to read and understand Orion�s way of coding a spiral: click
Maybe this helps you to do it for a 2D movement (with fixed "offseted" origin).

At the end:
If all of these do not help you and desperation is big, you can always do it like I did it in the SMC. Please look at the animated 'heart'-megahealth-model movement or even better at the custom Enforcers backpack movement.
I did this with an offset inside the models origin directly, and call different 'avelocities' to make them spin randomly (you do not need the crandom function of course, because you want a constant movement)

It depends on your desired final solution, if movement parms should be fully customizable or if you need only a handful different rotating models with several fixed offseted spin origins.
Depending on this, you shold choose your way of doing it...

Good luck,
Seven
[ame=http://www.youtube.com/watch?v=J8cEK5P0wJk]Quake custom backpacks - YouTube[/ame]

[Spike]

position * inverse reference matrix * rotation matrix.

of course, if you have any sense at all, you'll just use origin brushes or whatever so the inverse reference matrix basically ends up as an identity matrix. Then you can just set avelocity and have the engine do the rotation matrix for you too.

hipnotic-style rotation is frankly disgusting (due to limitations of quake's physics code at the time). The only merit to it is that the code for rendering matches physics... Which is NOT a good thing if you're not already forced to suffer from the physics hacks.


Assuming your entity has a sensible model origin (ie: you used a decent qbsp with origin brush support, or an mdl) you can use this logic to position one entity upon another:
makevectors([other.angles_x*-1, other.angles_y, other.angles_z]);
setorigin(self, other.origin + v_forward * self.offset_x + v_right * self.offset_y + v_up * self.offset_z);
You can then set self.angles however you want in order for 'self' to rotate around the 'self.offset' point relative to the parent's position+orientation.
If you're using a dodgy qbsp and self.angles='0 0 0', it should be enough to just set self.offset -= (self.maxs + self.mins) * 0.5; inside your spawn function. If your attached entity rotates, you'll need to do a full matrix inversion instead of that -= simplification.

[MadGypsy]

awesome! Thank all of you, even if I don't use your method in the end, thank you for the data.

@origin brush - I know that method, but it leads to 2 things to create one thing. I want to pop my rotate brush in radiant, check some origin point flags and call it a day.

[Spike]

what an origin brush means is that you don't have to change some field every time you copy/move the entity.
if you're just going to find the midpoint of the brush entity, then you're limiting yourself to symetrical shapes, rather than more interesting stuff.

[MadGypsy]

everything you say is true, but irrelevant to my code .

1) fields are the backbone of my entire QC rewrite
2) I'm not just gonna find the center.

I can find any combination of TOP MIDDLE BOTTOM LEFT RIGHT CENTER
or override it completely with a custom registration point. In short, positioning an info_(null/rotate) for every rotatable object is prehistoric at best. An object should have a personal registration point that is customizable and doesn't rely on a second entity. For 9 slice the registration is easy and can be done with a flag that sets off the proper equation. For anything else the registration_point field should be used.

This is actually one of the reasons that I am rewriting the entire QC from the ground up. QC is full of some retarded bullshit. The code attempts to imply that doors/plats/buttons and trains are all something different and repeats itself constantly in trying to prove this. These are all brushes that move, that's it. I have already rewritten all of that code and combined 4 repetitive classes into one class that is like 1000 lines shorter (and much cleaner). Adding rotation to my move brush based on a custom registration point is the last touches of move_brush. It can move in any direction or angle you want, towards a target or based on movedir. I also coded in 2 phase movement. Touching a move_brush can activate any "use"able function in my code that the mapper decides.

I know what you may be thinking "That's horrible, so you have an entity in radiant with 4000 fields to fill out"

Yup, I do have that, if you want to go that far down the chain to make something. But let's not forget this all started with inheritance. So whereas I do have a radiant ent that can be any type of moveable brush you could imagine. I also have wrapper code that defaults some of the stuff and passes it to movebrush. Meaning I still have (func_plat, func_train, func_button, etc) but these are not hard coded into my QC as them self. If you chose one of these things you would be utilizing the equivelent of

void() func_plat
{
//set the necessities to be a plat type
move_brush()
}

Honestly, when I'm done I doubt I will release the QC to the masses. There is not a tutorial out there that could explain how to mod my complete rewrite and the whole point is to eliminate the need for QC manipulation by bringing the mod to the map. It's not a matter of me not sharing, it's a matter of forcing people to focus on the point. The point is what you can do in a map (QuakeEd) and I'm already to a point where I'm gonna need to write a book to explain it. Also, my code has a very strict structure, I wouldn't trust anyone to follow it, but if they don't none of their stuff will work.

Now, would I give YOU (+r00k, gb, seven, others) a copy of the code. Of course. I'd be excited to, I just don't think releasing the code to the world is a good idea. It's not Quake and it's almost not even QC anymore.

side note: I tried gelling what I have with FTE but FTE doesn't like me at all (I think my computer is too shitty). However, I don't intend to give up. Imma keep going in darkplaces and when I have a finished version 1, I'm going to go back to FTE and try again. So far all of my code is pretty vanilla Quake, there are a few extensions used but FTE supports them, so it should all work in the end. Qrack however might be impossible, if it's not, I'll make it work in that too.

[Spike]

well okay then. let me put it this way, either:
a) you have the qbsp set up an .origin field automatically for you via an origin brush or (more awkwardly) target some entity.
b) you have the mapper figure out which value out of 18 possible values maps to the corner/edge/face/center that they want it at, preventing things like cogs attached to drawbridges, or coding in exact offsets in some vector field and hating you for making them do lots of maths. Not only this but the qc then has to deal with non-linear velocities and angle changes in order to keep the object appearing to rotate linearly without moving. With really really small think increments to ensure it stays fixed to its pivot point (which with this option is NOT its origin).

origin brushes that are an actual part of the rotating entity are simply the most sane way to do it - assuming the qbsp 'you're' using supports it. they're what halflife, q2, q3 etc all use, for instance.
anyway, your choice.

[MadGypsy]

Hmmm, I see.

OK, new plan. Rotation is not an option, it's a gnome. Problem solved.

Gnomes are entities that hold information that an entity may or may not need. For instance, animation is a gnome. Just because you have a model it doesn't mean it's animated. So rotation will work the same way and by simply calling it a gnome (which is the name of my entire project) having that extra little brush hanging out makes sense. Now I need to go strip move_brush of rotation conditions and make all that info it's own gnome.

I saw a little "Listen up dumbass" in the first sentence of your reply I'm just trying to make stuff, bro. I could never try and pretend I know as much as you or even that I understand you all of the time, but that's not going to stop me from making something awesome. Actually while we are on the subject of not understanding you all of the time.

Could you explain what struct actually does? Maybe even use some [.code] blocks in the explanation so it is easy to read and understand?

[Spike]

typedef struct
{
float foo;
float bar;
} mystructtype;

mystructtype foobar;

foobar.foo = 5;
foobar.bar = 9;

its just a way of boxing things together.
note that you can define foobar as an array too, which makes things a little cleaner as it means you technically only have one array instead of 5, but they become their most useful when you have pointers or embedded arrays within the structs and things like that.
I've included a typedef so you'll find it easier to reuse specific structs. note that structs and unions are basically the same thing, except that unions are far more evil as all members have the exact same memory location.

[MadGypsy]

oooooh, I get it. ok, thank you as always, Spike.