.float scale

Discuss programming in the QuakeC language.
Post Reply
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

.float scale

Post by Seven »

Hello Spike (or anybody who can help me),

I could not find documentation about how .scale is handled in FTE.
fteextensions has not much comments (which a beginner like me needs).

Does FTE also has .scale accuracy steps of 1/16th, like DP does ?
Or is FTE free to produce whatever .scale you want ?
That would effect fluent morphing quite much, which is a bit choppy in DP.


Do other engines also support .scale ?
Anybody knows of any ?

Thank you very much for your help.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: .float scale

Post by Spike »

aye, 1/16th precision. a byte that scales up to 15.9375 or so.
if you want more precision, use csqc. you should get full float precision then.

I think nehahra might also support scale. I don't know what it uses it for, but I'm sure the demo format has lots of nice large floats on every single entity that are never really used...

hexen2 support added a drawflags field:
self.drawflags = SCALE_ORIGIN_BOTTOM; //=32
this setting will keep the bottom of the entity at the bottom of the bbox, so it won't float around, etc.
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: .float scale

Post by Seven »

Thank you Spike.

Unfortunately I have 1 more question:
There is this multiskin/multimodel feature, that you maybe know from the mod, which aims to have some more enemy variations.
I had the idea to further increase the variation by adding random monster sizes. That is why I asked for .scale (as it is independent to the used monster model (vanilla or replacement)).

As far as I understand your words, scaling with ssqc is only possible in 1/16th steps.
Which is around 7%.

So, I tried to go up to a .scale value of: 1.21 (which is 21% bigger).
Most important is the bbox, as all calculations is done against the bbox.

I chose max. 21% because:
a) further monster size-increase doesnt look 'realistic' compared to original size
b) the original bbox can still be used as its size still covers the model quite good

I didnt want to use the FTE extension (self.drawflags = SCALE_ORIGIN_BOTTOM), as my main engine is DP and this way it still works in both.
I moved the bbox z-values to compensate the .scale factor:
Scale of each 7% has a fixed bbox compensation of 7% as well.
This can nicely be done via qc.

So I can have 4 random monster sizes (which all have the same bbox size):
1.0 % (original size)
1.07 %
1.14 %
1.21 %


So far I played/tested Quake with the resized monsters and there seems to be no issue.
bbox size is identical, so no clipping problems occurred.

But back to my question to you now:
1.) Is there an issue when playing with custom bbox sizes ? (as I had to move the negative and positive z values to keep the monsters on the floor) ?
2.) Is there an issue regarding the slightly upwards moved center of the bbox ? (as I menioned I move it upwards max. 5 Quake units --> 21%)
So far I could not find any... but maybe engine-wise there are some serious ones ?


These are my code lines for a soldier type bbox (i left out the random code to make it easier to compare):

Code: Select all

//  setmodel (self, "progs/soldier.mdl");
//  setsize (self, '-16 -16 -24', '16 16 40');

    setmodel (self, "progs/soldier.mdl");
    self.scale = 1.21;
    setsize (self, '-16 -16 -24' - '0 0 5', '16 16 40' - '0 0 5');
These are my code lines for a demon type bbox (i left out the random code to make it easier to compare):

Code: Select all

//  setmodel (self, "progs/demon.mdl");
//  setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX);

    setmodel (self, "progs/demon.mdl");
    self.scale = 1.21;
    setsize (self, VEC_HULL2_MIN -'0 0 5', VEC_HULL2_MAX -'0 0 5');

Here are comparism screenshots which shows original size against max size of 1.21 % :
Image Image


Thank you very much for your time reading this.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: .float scale

Post by Spike »

.scale doesn't affect collisions. which is the problem. because it means that with a scale of 2 or so, the feet of the enemy are clearly inside the floor.

You can fix that with something like the following

self.scale = floor(self.scale*16)/16; //match the engine's scaling.
minz = self.mins_z * self.scale; //determine the new model mins
sizez = self.size_z * self.scale; //determine the new model size
self.origin_z += minz*(1-sizez); //move the monster around to keep its mins_z constant despite the resize
setsize(self, [self.mins_x,self.mins_y,minz], [self.maxs_x, self.maxs_x, sizez-minz]); //and resize it.

bsp/bbox collisions are aligned to the bbox mins value. this means that the mins_z needs to be correct for the new position, and the maxs_z can be almost whatever it wants (although if the scale is too high, you might notice the monster's head passing through walls - which you can generally get away with with good map design). but you can't get away with changing the x+y mins without offsetting that so noticably.

anyway, that's the idea.
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: .float scale

Post by Seven »

Hello Spike,

I am not sure if I understood your answer correctly.

Do you say that this will not work ?

Code: Select all

    setmodel (self, "progs/soldier.mdl");
    self.scale = 1.21;
    setsize (self, '-16 -16 -24' - '0 0 5', '16 16 40' - '0 0 5');
Visualy the feet are not inside the floor as I raised the negative z-value to match the scale value (as shown in screenshot).
The complete model is still inside the bbox as well (which has the overall size of original).
Due to the fact that I do not want to get higher than scale of 1.21 (21%) like mentioned above, I can add
each z-value-correction by hand in qc (for 1.07, 1.14 and 1.21), there are only 3 of them (due to 7% steps).
Your code looks of course much more proffessinal as it calculates the values automatically.
My manual (poor man´s) way will not work, because you gave me an alternative code ?
Or will both ways work ?

Please excuse my question as I am not sure that I fully understodd your last post, as you didnt gave me a clear yes or no.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: .float scale

Post by frag.machine »

Both solutions will work, but Spike's *theorically* avoid trial-and-error adjusts.
Is there any Quake engine that supports multiple/composite bound boxes ?
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: .float scale

Post by Spike »

seven, your code potentially allows people to shoot through the monster's head.
note that your monster's bbox is already 8qu taller than the hull size.
hardcoding is fine if you want less code. its just that you need to hardcode every case and thus quite likely more code in the end.

frag.machine, while it would be possible to simulate larger hull sizes from smaller ones, doing so would require 8 times as much work, and would not aid with crouching. enabling such a feature would likely break a load of mods (like any monster that's defined to be 64qu high placed a qu or two above the ground in a small passageway, for instance).
q2+q3 use brush collisions and thus do not require descrete hull sizes. this is the preferable way to do it, especially as this also potentially allows support for capsules too. taniwha added some poly collision code to quakeforge a while ago which would have the same effect, while tonik has previously made a direct q1bsp->q2bsp converter. the problem with these automatic methods is that they ignore clip brushes, which means the player suddenly gets stuck on all sorts of sticky out bits of the map.
as bbox sizes increase, the axial nature of bboxes gets more and more goofy, so anything that allows ditching aabb collisions completely is a good thing.
I really do wonder what would happen if a qbsp were to generate capsule-shaped hulls instead of bbox ones. theoretically it would be possible to support any convex shape from the qbsp...
Post Reply