What should be the unit radius?

[gajop]

Spring.SetUnitRadiusAndHeight New in version 89.0
( number unitID, number radius, number height ) -> boolean success

Unit radius is a pretty important attribute that in combination with collision volumes controls everthing from drawing, physical/projectile collision to mouse hovering and selection. That's also probably too much and I'd like to see it reduced eventually.

The objective of this thread however is to find out exactly what radius has impact on and what the setting should be (and preferably edit the wiki once we figure it out).
I assume it should be greater than the object's drawing size so it's always drawn correctly, but what about collisions? Should it be greater than all colvols dimensions or smaller? Or something arbitrary?
How do collisions work if there's both a radius and a colvol specified?
Any feedback you can share on this is appreciated.

[jK]

I assume it should be greater than the object's drawing size so it's always drawn correctly, but what about collisions? Should it be greater than all colvols dimensions or smaller? Or something arbitrary?

That's why there is a `drawRadius`

[Anarchid]

How do collisions work if there's both a radius and a colvol specified?

Afaik radius is used in unit-unit collisions, units pushing each other (at least with gunships), getUnitSeparation, and (possibly) explosion aoe.

That ideally should all be colvols, but then intersecting that many colvols might be taxing without some proper algorithms and/or bullet.

If there's a drawRadius, i would prefer the cludgeRadius to not exist at all.

[gajop]

That's why there is a `drawRadius`

This is the first time i hear about it too.

It doesn't seem it can be set in Lua:

Code: Select all

/rts/Lua (git)-[develop] % grep -rni drawRadius
LuaUnsyncedRead.cpp:754:        float testRadius = WORLDOBJECT_DEFAULT_DRAWRADIUS;
LuaUnsyncedRead.cpp:846:                        if (!camera->InView(unit->midPos, testRadius + (unit->drawRadius * !fixedRadius)))
LuaUnsyncedRead.cpp:881:        float testRadius = WORLDOBJECT_DEFAULT_DRAWRADIUS;
LuaUnsyncedRead.cpp:947:                if (!camera->InView(f.midPos, testRadius + (f.drawRadius * !fixedRadius)))
LuaUnsyncedRead.cpp:1003:                               if (!camera->InView(pro->pos, pro->drawRadius))

But it does seem it exists, and this is how the value is obtained for different types:

Code: Select all

Rendering/Models/3DOParser.cpp:149:     model->drawRadius = float3::max(float3::fabs(model->maxs), float3::fabs(model->mins)).Length();
Rendering/Models/AssParser.cpp:713:     model->drawRadius = model->radius;
Rendering/Models/S3OParser.cpp:48:      model->drawRadius = float3::max(float3::fabs(model->maxs), float3::fabs(model->mins)).Length();

All projectiles also seem to have it and it's obtained from a combination of the weapon size/collision size/collision radius depending on the weapon.

Would it be OK if I made a Lua interface to set this and untangled it from the existing Lua interface used to set the collision radius?

If there's a drawRadius, i would prefer the cludgeRadius to not exist at all.

I think I heard jk say once that cludgeRadius is there to optimize collision calculations, and it was used before making any collision checks based on colvols. In a sense one would ignore collisions on all objects that haven't passed the radius check.
However, it doesn't seem like it does that at all -> In Gravitas and I think Area17 too with AoE weapons it would often override colvols in calculating collision checks, basically invalidating them.
So I could be wrong, and that's why this thread was opened to clarify things.

Anyway, I would agree with you. If cludgeRadius must exist for optimization, it should be invisible to the user and just be max(colvol dimensions).

PS: I also don't think we should need to set any collision settings for prefab models by default. It seems to me like we're doing premature optimization there.

[jK]

Would it be OK if I made a Lua interface to set this and untangled it from the existing Lua interface used to set the collision radius?

No, it wouldn't be okay. You already see at unitRadius that such values shouldn't be user-configurable at all (when possible).*
Only reasons for runtime updating it would be:
1. when lua overrides rendering and changes the render size massively
2. when the unitscript moves pieces far from center and so increasing the render size

Still I don't see any lua coder updating it after such changes (esp. cause calculating such values in lua is everything else than trivial). Instead I am just seeing lua coders misusing it and getting further confused. So imo such a function would just do harm without any advantages.



[*] I told ZK devs multiple times that unit radius _must_ be larger than colvol, but they ignore that fact. So such soft conditions are a failure from the start. -> Solution: skip unit radius for colvol and replace with an auto-calced colRadius.

[raaar]

(stuff)

[*] I told ZK devs multiple times that unit radius _must_ be larger than colvol, but they ignore that fact. So such soft conditions are a failure from the start. -> Solution: skip unit radius for colvol and replace with an auto-calced colRadius.

what happens if it isn't?

[Silentwings]

Probably it would help to write a clear explanation of which bit does what somewhere and then see if game devs continue to mismanage it! I never really knew what all the different radii affected either. The fact that unitRadius should be larger than colvol is in https://springrts.com/wiki/Gamedev:CollisionVolumes, though.

[gajop]

I told ZK devs multiple times that unit radius _must_ be larger than colvol, but they ignore that fact. So such soft conditions are a failure from the start.

Seems I was right about this part.
So radius should be larger than the colvol, but I think this caused issues (it wasn't a soft but rather a hard condition).
I went with this idea when making new unitdefs but I often had to change and make the radius smaller than the colvol, example: https://github.com/SpringCabal/Area-17/ ... 53e3788648

I'm also not sure if the radius is affected by the colvol offset or not. Should it be greater than offset + max(dimension)?

-> Solution: skip unit radius for colvol and replace with an auto-calced colRadius.

I like this idea very much for all cases where radius is used as an optimization (soft condition), but for cases where it's a hard condition (like drawing), it makes sense to configure & document it. I can imagine doing crazy Lua things that would require it (e.g. scaling the unit in a shader or drawing some type of effects).

Probably it would help to write a clear explanation of which bit does what somewhere and then see if game devs continue to mismanage it! I never knew what it affected either, not even when we had to re-make colvols after ellipsoids were abolished.

That's the goal of this thread! Instead of reading the source the best thing is to ask because desired and implemented things are different I think!

[Google_Frog]

I told ZK devs multiple times that unit radius _must_ be larger than colvol, but they ignore that fact. So such soft conditions are a failure from the start. -> Solution: skip unit radius for colvol and replace with an auto-calced colRadius.

Doing this resulted in bugs such as planes being unable to land on airpads (engine airpads) and air transports which cannot fly low enough to pick up units. Ideally the engine would automatically calculate a good value from the hitvolume, one that does not cause any bugs.

Here is a controlled example. The UFO in Area 17 had a bug which caused it to jitter vertically. I discovered that it had unit radius set such that the colvol was encompassed. This radius was larger than the units cruiseAlt and for some reason the sphere defined by radius collides with the ground. So the UFO was constantly trying to fly down to its cruiseAlt while the large radius was pushing it upwards.

The thing I hate about Spring.SetUnitRadiusAndHeight is that it does many different things. Working around one bug leads to others. I would really like to be able to set draw radius because then it would not be part of this tradeoff. We were lucky that the UFO in Area 17 never left the view because the small view radius would have looked weird.

[hokomoko]

Doing this resulted in bugs such as planes being unable to land on airpads (engine airpads) and air transports which cannot fly low enough to pick up units. Ideally the engine would automatically calculate a good value from the hitvolume, one that does not cause any bugs.

This is fixed in the next version as part of the transport tweaks.

[gajop]

The thing I hate about Spring.SetUnitRadiusAndHeight is that it does many different things. Working around one bug leads to others.

This is what I experienced with Gravitas walls and patching collisions, and Area17 AA and weapon AOE and projectiles passing through units.
I think this is because it's sometimes a hard check instead of a soft one.

[code_man]

So what is a unit radius?
I gather it is the radius to keep units at a distance from one another, but i think nobody mentioned it explicitly here.
I managed to figure out how to set selection boxes, which i assume are also the hitboxes, correct me if im wrong.

Incase i am correct i would say the unit radius should default to the largest hitbox axis length, or sum of all hitboxes along a axis if per piece colvols are used.
Sorry if this is offtopic but how do i set the unti-unit collision stuff? I have a huge problem with units clumping together and refusing to fire, really need advice here.
Also is it possible to have custom hit zones, like special hitboxes that can trigger a lua callin. Say for example i want custom hp on the turret of a unit.