reported world.searchObjects appears to search bounding box instead of specified sphere volume

[[HOUNDS] CptTrips]

I ran into a problem with some Moose functionality.  In debugging the issue, it appears to originate in the SSE.  So, I wrote a test using only SSE and duplicated the underlying issue.

I am attempting to scan the area defined by TestSphereZone.  Here is the test code:

local foundUnits = {}

 local sphere = trigger.misc.getZone('TestSphereZone')
 local volS = {
   id = world.VolumeType.SPHERE,
   params = {
     point = sphere.point,
     radius = sphere.radius
   }
 }
 
 local ifFound = function(foundItem, val)
    foundUnits[#foundUnits + 1] = foundItem:getName()
    return true
 end

 world.searchObjects(Object.Category.UNIT, volS, ifFound)
trigger.action.outText("Number of units found: " .. #foundUnits, 20)

 

Note a volume type of "SPHERE is specified.  (Really should be called Cylinder IMHO, but whatever.)

I would have expected a count of found objects to be 6.

What is returned in this case is 18 objects (i.e. appears to include objects outside the cylinder but inside a bounding box corners.  

On a 10 nm radius zone the error at the corners is 4nm or 140% percent of the intended radius.

(Test miz attached.)

Thanks in advance.

 

 

 

 

 

TestShereVolume.miz

Edited April 19, 2023 by [16AGR] CptTrips
added tag

[funkyfranky]

Can confirm this.

BTW, it is really a spherical not a cylindrical volume that is searched (if it worked correctly). You can see this by moving the center high into the air with sphere.point.y=sphere.point.y+10000. Then it does not find anything.

[[HOUNDS] CptTrips]

2 hours ago, funkyfranky said:

Can confirm this.

BTW, it is really a spherical not a cylindrical volume that is searched (if it worked correctly). You can see this by moving the center high into the air with sphere.point.y=sphere.point.y+10000. Then it does not find anything.

 

Ah, I stand corrected. Hmmmm.  Now I wish I had a Cylinder volume. Don't really want the boundary to curve in with alt.  I just want to have a cylinder of infinite height.  Oh well, that is a wishlist item. 

But a square ain't a sphere or a cylinder. 

[edit] 

I could see the benefit of doing a computationally cheaper bounding box check first as a trivial reject, and then do a more expensive 3d radius check on those found in the bounding box.  Maybe they just forgot the second step.

Edited April 20, 2023 by [16AGR] CptTrips

[Pikey]

I can confirm sporadic comments over the years about this phenomenom. It messes up a lot of in/out detection.

ALso... Ive never seen a world search done with a square

 

world.VolumeType.BOX

 

any takers to see if this is reliable?

[[HOUNDS] CptTrips]

2 hours ago, Pikey said:

Any takers to see if this is reliable?

 

I tried adding some helper zones at the corners as per https://wiki.hoggitworld.com/view/DCS_volume_box. Here is my test code:

local foundUnits = {}

local sw = trigger.misc.getZone('SW')
local ne = trigger.misc.getZone('NE')

local volB = {
    id = world.VolumeType.BOX,
    params = {
        min = { sw.point.x, 0, sw.point.z },
        max = { ne.point.x ,10000, ne.point.z }
    }
}

local ifFound = function(foundItem, val)
    foundUnits[#foundUnits + 1] = foundItem:getName()
    return true
end

world.searchObjects(Object.Category.UNIT, volB, ifFound)
trigger.action.outText("Number of units found: " .. #foundUnits, 20)
env.info("Number of units found: " .. #foundUnits)

It kept coming back with 0 objects found.  I assume I am missing something simple.

(attached test miz)

 

 

TestBOXVolume.miz

[Grimes]

Are those ship icons? Try -20  altitude for the min value or doing it with ground vehicles above sea level. 

[[HOUNDS] CptTrips]

34 minutes ago, Grimes said:

Are those ship icons? Try -20  altitude for the min value or doing it with ground vehicles above sea level. 

Yep.  Those are tugs on the surface.  I saw in the editor the cursor on the water siad "-100"  (?)  I tried -10000 but still didn't get a hit.

Y is alt, right?

 

[[HOUNDS] CptTrips]

Also put it on land with m113.  Tried alt of both 0 and -10000.  still no hits.

(See altered example)
TestBOXVolume2.miz

[Grimes]

local foundUnits = {}

local sw = trigger.misc.getZone('SW').point --- might as well be point
local ne = trigger.misc.getZone('NE').point -- again

ne.y = 10000
local volB = {
    id = world.VolumeType.BOX,
    params = {
        min = sw,		-- you were doing {[1] = sw.point.x, [2] = 0, [3] = sw.point.z} instead of {x = sw.point.x, y = sw.point.y, z = sw.point.z}
        max = ne,		-- again
    }
}

The vec3 table was being indexed numerically rather than x, y, z. Took me longer than I care to admit to realize that. Then when I did I just directly called the sw and nw tables while forgetting to specify point. Anyways it works. 

[[HOUNDS] CptTrips]

(Do you see anything wrong with the first sphere example?  That's the one I am really interested in.)

Hmmm.  I'm still screwing up somewhere.  Still getting 0.

This the code now:

local foundUnits = {}

local sw = trigger.misc.getZone('SW')
local ne = trigger.misc.getZone('NE')
ne.y = 10000

local volB = {
    id = world.VolumeType.BOX,
    params = {
        min = sw,
        max = ne 
    }
}

local ifFound = function(foundItem, val)
    foundUnits[#foundUnits + 1] = foundItem:getName()
    return true
end

world.searchObjects(Object.Category.UNIT, volB, ifFound)
trigger.action.outText("Number of units found: " .. #foundUnits, 20)
env.info("Number of units found: " .. #foundUnits)

(see attached)

TestBOXVolume3.miz

[Grimes]

Your function used this
local sw = trigger.misc.getZone('SW')

Mine was:

local sw = trigger.misc.getZone('SW').point

 

 

[[HOUNDS] CptTrips]

4 hours ago, Grimes said:

Your function used this
local sw = trigger.misc.getZone('SW')

Mine was:

local sw = trigger.misc.getZone('SW').point

 

 

 

Doh!  It was late.  My brain was shutting down. 

So, BOX seems to work fine.  Makes sense.

 

My original problem is, that BOX search works fine, except I asked for a sphere. 

 

[[HOUNDS] CptTrips]

A similar unexpected result on field capture zones (slight twist).  I suspect under the covers it is related to my original post somehow.

I ran across a situation where a static can capture an airbase even when clearly outside the airfield zone.

Aside from the oddity that a tent can capture an airbase (hint: it works with an Orca whale too ), it is clearly outside the airfield zone.

Yet when run, the tent has flipped the field blue.

Of course, if I move the tent to the 3 o'clk position it doesn't capture the field even though even closer.

Oddly, if I change the tent to an Abrams tank in the corner, it doesn't capture the field.  

Ground units (in this case) must be using a different algorithm than statics.  I bet a dollar, statics here are using something similar to the sphere volume like in my original post.

However, when calling world.searchObjects, it finds ground units within a bounding box not the specified sphere.

I hope that the answer isn't that this is intended.  I understand that searching a sphere is more expensive than searching a box.  But it is not something likely done every frame, and it certainly could be written as a two pass search, first using a box to get a selection of possible candidates and then only apply the more expensive sphere search on those for the final results.  That would reduce the number of objects needed to evaluate with the more expensive calculation. 

Otherwise it can lead to various confusing and apparently broken, almost random seeming results.  It will give false positives on things at a distance of 140% of the intended radius.  If you compare a sphere volume with its bounding box volume, 48% of the box volume will be giving a false-positive hit result.  Almost worth flipping a coin to decide if you trust the result or not.  

 

Edited April 27, 2023 by [16AGR] CptTrips

[[HOUNDS] CptTrips]

Has anyone at ED been able to reproduce the OP issue?

Were the miz files I attached sufficient?  Is there any more information I can provide to assist?

 

Thanks.

[Grimes]

Yeah it has been reported.