Incorrect CapZones dimension when it has a ingame rotation applied

[sh4rkman]

In the current extraction process, capzones are exported along each objectives objects in objectives.objects[]

"04-Souk": {
    "name": "Souk",
    "objectName": "04-Souk",
    "objectDisplayName": "04-Souk",
    "location_x": 8893,
    "location_y": 34537,
    "location_z": -12987,
    "objects": [
        {
            "location_x": 7217,
            "location_y": 35381,
            "location_z": -13436,
            "sphereRadius": "5703.507812",
            "boxExtent": {
                "location_x": 5126.16064453125,
                "location_y": 3333.14306640625,
                "location_z": 2500
            }
        },
        {
            "location_x": 13934,
            "location_y": 33595,
            "location_z": -13436,
            "sphereRadius": "3672.873535",
            "boxExtent": {
                "location_x": 2000.001953125,
                "location_y": 1800.0020751953125,
                "location_z": 2500
            }
        }
    ],
    "pointPosition": 5
},

Each capzone (a single objective can have several capzone) have a location x/y/z, a sphereradius (that doesn't really represent anything ingame) and a boxExtends[]. That BoxExtends[] holds the dimension of the rectangle capzone. When applying this dimensions to the position we can properly determine and draw it :

Example for the boxExtends[0] for Souk in Sumari_AAS_V1 :

{
    "location_x": 13934,
    "location_y": 33595,
    "location_z": -13436,
    "sphereRadius": "3672.873535",
    "boxExtent": {
        "location_x": 2000.001953125,
        "location_y": 1800.0020751953125,
        "location_z": 2500
    }
}

Values are the same from the SDK, i can use them :

But for boxExtends[1] the dimension are different than ingame :

{
    "location_x": 7217,
    "location_y": 35381,
    "location_z": -13436,
    "sphereRadius": "5703.507812",
    "boxExtent": {
        "location_x": 5126.16064453125,
        "location_y": 3333.14306640625,
        "location_z": 2500
    }
},

It looks like the BoxExtent are exported with its Transform property applied : when there is a rotation applied to the capzone, the box exported is a non-rotated box that will hold the rotated capzone. Here in red is what the capzone is ingame with correct dimension :

---

In conclusion this is already working well for me but can be imprecise if my users want to determine precisely where they can stand to be in the capzone in some cases. What would be perfect is to export the raw boxdimension found in the sdk along the rotation vector that is applied to that box.

Something like :

"04-Souk": {
  "name": "Souk",
  "objectName": "04-Souk",
  "objectDisplayName": "04-Souk",
  "location_x": 8893,
  "location_y": 34537,
  "location_z": -12987,
  "objects": [
      {
          "location_x": 7217,
          "location_y": 35381,
          "location_z": -13436,
          "sphereRadius": "5703.507812",
          "boxExtent": {
              "location_x": 4800,
              "location_y": 1800,
              "location_z": 2500,
              "rotation_x": 0, <-
              "rotation_y": 0, <-
              "rotation_z": -19.9999 <-
          }
      },

[sh4rkman]

same thing goes with the map.mapAssets.protectionZones objects : if the protection zone is rotated, their box data is way too big :

[Shanomac99]

I believe I have fixed this.

To go over everything from the post:

sphereradius Is used when the object is a Sphere (Usually mains):

The main issue stems from how I used to be grabbing the boxExtents info. I used Get Component Bounds

Which does exactly like you explained, it imagines it's not rotated and gets the furthest extents of the object.

To fix this, I've added a check to see if the child object is a box:

If it is, it can pull the box extent from the box itself, and get the rotational info. Otherwise, it keeps the old method.

I've added a boolean to the code to indicate whether it is a box, sphere, and or capsule.

Here's how Souk Looks now:

"04-Souk": {
	"name": "Souk",
	"objectName": "04-Souk",
	"objectDisplayName": "04-Souk",
	"location_x": 8893,
	"location_y": 34537,
	"location_z": -12987,
	"objects": [
		{
			"objectName": "Box",
			"location_x": 13934,
			"location_y": 33595,
			"location_z": -13436,
			"isSphere": false,
			"sphereRadius": "3672.873535",
			"isBox": true,
			"boxExtent": {
				"location_x": 2000,
				"location_y": 1800,
				"location_z": 2500,
				"rotation_x": 0,
				"rotation_y": 0,
				"rotation_z": 0
			},
			"isCapsule": false
		},
		{
			"objectName": "Box1",
			"location_x": 7217,
			"location_y": 35381,
			"location_z": -13436,
			"isSphere": false,
			"sphereRadius": "5703.507812",
			"isBox": true,
			"boxExtent": {
				"location_x": 4800,
				"location_y": 1800,
				"location_z": 2500,
				"rotation_x": 0,
				"rotation_y": 0,
				"rotation_z": -19.999994277954102
			},
			"isCapsule": false
		}
	],
	"pointPosition": 5
}

As a side effect, this will apply to all child objects, which should fix the protection zones also.

I made a test commit for Sumari AAS v1 here: 4778d1f. If you could take a look over it then I can run it over the entire map pool and we can test again.

[sh4rkman]

Flag boxes dimensions/rotations looks great !
Sumari_AAS_v1 mostly have rectangles (only main protection 2 is a circle) so i was not able to test circles/capsules.
(if you are looking for a layer with a mix of those object, Kohat_RAAS_v1 is a good candidate if i remember correctly)

Only thing missing for sumari_aas_v1 is the same information for mains protections : they can also be circles or rectangles with rotation (see Kokan in my previous message) :

"mapAssets": {
"protectionZones": [
  {
  {
    "displayName": "Team1 Protection Zone",
    "deployableLockDistance": 10000,
    "teamid": "1",
    "objects": [
      {
        "sphereRadius": 9110.43359375,
        "location_x": -52432.12890625,
        "location_y": 30085.26953125,
        "location_z": -13178.2861328125,
        "boxExtent": {
          "extent_x": 5000,
          "extent_y": 7000,
          "extent_z": 3000
        }
      }
    ]
  }
],
...

[Shanomac99]

Looks like it wasn't using the child logger like I thought, I forgot I had to fix a scaling issue with it. I've gone ahead and changed it:

"protectionZones": [
	{
		"displayName": "Team1 Protection Zone 1",
		"deployableLockDistance": 15000,
		"teamid": "1",
		"objects": [
			{
				"objectName": "Protection Zone",
				"isSphere": true,
				"sphereRadius": 20000,
				"location_x": 181013.640625,
				"location_y": -136541.21875,
				"location_z": 23217.8984375,
				"isBox": false,
				"boxExtent": {
					"extent_x": 20000,
					"extent_y": 20000,
					"extent_z": 20000,
					"rotation_x": 0,
					"rotation_y": 0,
					"rotation_z": 0
				},
				"isCapsule": false
			}
		]
	}
]

I've also fixed staging zones and changed the child logger to use extent_x instead of location_x in the box extent object. It was supposed to, but it looks like I forgot to change the text within it.

I've run both Sumari_AAS_v1 and Kokan_RAAS_v1 so give them a try and let me know.

[sh4rkman]

It looks great !

• Rectangle, Circle, Capsule capzones are on point, rotated or not
• Main Protection Zones looks also perfect. They were no rotated-rectangular capzone in those two maps so didn't test it but no reason it doesn't work.

I can test a full extract if you commit the changed MapGrabAsset, i will test it the incoming week and check most layers

[sh4rkman]

Bump!

Can you share the .uasset grabber so i can make my computer work during the night ? I'll review the final export and commit it into dev

[sh4rkman]

Thank you, after playing with the 618274e mapgrabber with pretty much all map it looks 99% perfect.

I can see two problems :

• Capsules have the same rotation x/y/z both in the object and the boxExtent object, it looks like a duplicate but i'm not sure. Sometime the data is exactly the same from the SDK, sometimes it looks like the DefaultSceneRoot and the capsuleRotation have been added together. Not that problematic, i can test if the capzone is rotated -90 on Y and deduce if i should take rotation_z or something else into account, but that's unclear

• More importantly, some box capzones have very little boxExtent size (32cm!), it seems that sometimes OWI created the box small and scaled them. Which means now we're missing a scale object in x/y/z in some rare cases..

Example : Souk on Sumari_RAAS_V1 (also seen that a lot on Anvil Layers)