[FTE] Auto adjust collision after .scale in CSCQ

[toneddu2000]

Hi guys, I read this post by Spike that said that, in ssqc .scale has 1/16th precision, instead in csqc it should be fine

I'm trying to scale entities in CSQC according to player distance from them (player far -> bigger, player near -> smaller)

Code: Select all

void  entitythink()
{   
local float limit = 200;//without this, entities are scaled toooo big
   self.scale = vlen(self.origin - player.origin) / limit;
   self.nextthink = time +2;
   self.think = entitythink;
}


And it works, but if I use traceline, trace rays intercept original size of entities, as they were never scaled.

I tried also Spike's workaround (a little modified to work in every direction), but with no luck

Code: Select all

void  entitythink()
{   
local float limit = 200;//without this, entities are scaled toooo big
local float minx,miny,minz,sizex,sizey,sizez,s;
   self.scale = vlen(self.origin - player.origin) / limit;
   s = self.scale / 2;
   minx = self.mins_x * s; //determine the new model mins
   miny = self.mins_y * s; //determine the new model mins
   minz = self.mins_z * s; //determine the new model mins
   sizex = self.size_x * s; //determine the new model size
   sizey = self.size_y * s; //determine the new model size
   sizez = self.size_z * s; //determine the new model size
   self.solid = SOLID_BBOX;
   setsize(self, [minx,miny,minz], [sizex-minx,sizey-miny,sizez-minz]); //and resize it.
   self.nextthink = time +2;
   self.think = entitythink;
}


Now bboxes become bigger and bigger (while objects scale correcly), than smaller and smaller and then disappear (even if I don't move player farther or nearer)

Thanks for any input!!:)

PS: I used .think instead of .predraw just to control things step by step, in a temporal range of 2 seconds, which is easier to debug

[toneddu2000]

really anyone? Even Spike can't think of a workaround? It's quite frustrating to me to fall on this trivial glitch.. I COULD use a different approach but it wouldn't be so satisfying as this one!

[Spike]

if you're calling that repeatedly then you're accumulating those scale changes. which is probably not what you want...

[toneddu2000]

yeah, you're right, but still I don't understand why it increases size even if I don't change player position. And then, it gets smaller and smaller, becoming invisible after some sec.
calling setsize after every .scale operation, shouldn't clear things up?

[Spike]

self.scale = vlen(self.origin - player.origin) / limit;
s = self.scale / 2;
minx = self.mins_x * s; //determine the new model mins

so .scale is set according to the distance to the entity.
and that's fine...
but if your scale is *2, why are you calculating mins as though its scale 1?
and then, why are youreplacing .scale, and yet rescaling mins+maxs since the last call? if you're setting .scale directly you really ought to be setting the mins+maxs relative to their original values like you're rescaling .scale relative to its original value of 1.
also, why use .size when .maxs is easier and more consistent?


one thing you might want to try is using a mins_z of 0. this means you don't have to move the entity up/down as it gets resized. but will need to adjust your model too.
that said, you will need to use tracebox to see if the spot is empty enought for a slightly larger model to fit there.

[toneddu2000]

well, I tried almost everything but nothing changed. I guess I'll go for a static pre-defined increase / decrease way (a thing like "if distance > x setsize(blah)")
I think that a new way of determine collisions (possible via collision meshes) in FTE, would need to be taken in consideration one day, Spike, because it's a really pain in the "@X to manage dynamic collisions in real time (I did my best with tracebox but collision meshes are a MUST, IMO).

Could you please tell me where collisions are handled in engine?

[Spike]

fte still uses world.c to determine when something may need to collide, while pmovetst.c does the job for player prediction colliding against other stuff. its these files that decide which objects need to collide against others. however, the actual collisions themselves are done on a per-model basis, with callbacks specified via impactee->funcs.NativeTrace. If null then only bbox/bbox colisions can happen thanks to fallbacks, while if its set then hitmodel or bsp collisions can be used.

[toneddu2000]

As always I made a mistake in writing my question! My correct question should have been (and also the title of the thread): how engine sets bounding boxes for meshes? Did engine updates bboxes per-frame?
I read World_InitBoxHull () and World_HullForBox() in world.c but I wonder if it's possible to replicate a Bbox set function in a "update" function to re-update every x frame bounding boxes.

Collisions are not my problem, as long as I use tracebox, but I neet that bbox encompass totally model, as csqc defs defines.

[frag.machine]

I don't know if what I'll say applies to your use case, or even if it's valid or recommended in CSQC. But when I made a shrinking gun/attack some time ago I ensured that the .mins and .maxs vectors were directly proportional to .scale (obviously, like Spike already said, I stored the original values to be able to recalc with precision and to restore the entity back once the effect worn off). BTW this allowed me to implement inclusive the "stomp over" a monster attack, Duke Nukem style. From what you say it seems to me your intention is to make the entity look approximately the same size to the player, regardless the distance, right ?

[toneddu2000]

From what you say it seems to me your intention is to make the entity look approximately the same size to the player, regardless the distance, right ?

No, quite the opposite. My intent was to increase entity size if player is far and decrease entity size if player is near, but your help is quite preciouse anyway, frag.machine. I have to try to store .mins and .maxs in temp vars and then use linear proportion according to size to increase / decrease.
The problem is with .maxs; not understanding it very well and with very little documentation, I'm not sure, for example, if to use, self.maxs_x or self.size_x - self.maxs_x to calculate largest size on x side

Of course, being inside of a loop think function, I had to store in a global var the old scale var, compare it to new scale var and, if new, then store mins and maxs var and use setsize, if old scale is the same don't do anything (anyway it will keeping get smaller and smaller or bigger and bigger)

Thank you too for your help!

[frag.machine]

Let's say this entity can be at most at 4096 qu (Quake units) from the player in any dimension. (change at your please)

Also, let's say I want to cap the min and max sizes to 5 and 0.5, respectively. (optional, change at your please)

First, let's create some fields to hold our original values:

Code: Select all

.float old_scale;
.vector old_mins, old_maxs;


Be sure to store the original values as soon as possible (for example, at the end of the entity spawn function).

Now, every thime we want to resize the entity, we do something along this lines
(assuming self as the player and ent as the affected entity):

Code: Select all

local float factor;

factor = vlen (self.origin - ent.origin) / 4096;
factor = 5 * factor;
if (factor < 0.5) { factor = 0.5; }      // clamp the minimum scale
if (factor > 5.0) { factor = 5.0; }      // clamp the maximum scale

ent.scale = ent.old_scale * factor;      // the visible model is scaled accordingly

ent.mins_x = ent.old_mins_x * factor;
ent.mins_y = ent.old_mins_y * factor;
ent.mins_z = ent.old_mins_z * factor;

ent.maxs_x = ent.old_maxs_x * factor;
ent.maxs_y = ent.old_maxs_y * factor;
ent.maxs_z = ent.old_maxs_z * factor;   

setsize (ent, ent.mins, ent.maxs);      // the collision hitbox is scaled accordingly


DISCLAIMER: Untested, and assuming this won't break CSQC in any way.
Good luck.

[toneddu2000]

Thanks a lot frag.machine, it worked! I know now where I was making a mistake with my old code.
I forgot, when entity is spawned, to save oldscale, oldmins and oldmaxs. Without them, the mins and maxs value will be set to 0, and, in think function, when multiplied * any value, they will produce only 0;
The clamp check it's also a great thing because it prevents over and down scaling

Many thanks again man!