Embedded Files
This tab is where you can test and investigate issues with your volumes
You're able to manually trigger a standalone tester, either in piloting or drone modes. It's important to note that as these are standalone, they don't have a context for what you're tesing for. They by default are searching for areas that have NO volume of your current volume class in them.
If they detect an area with no volume they display it as either a warning (the area is colliding with an object) or an error (the area is in open space, not colliding with anything).
You can also enable 'multi-volume' tests in settings, which will also test for areas of overlapping volumes, which can inform you of areas where volumes are overlapping into adjacent rooms.
With the 'Test Volume For Geometry Changes' button you can specifically test for potential geometry changes in the level since the volume was built. This is a simple one-click operation unlike the above.
Finally, you can also teleport to the various warnings and errors that the system has discovered, allowing you to easily see what and where potential problems are located and therefore how to resolve them.
In addition to the features listed here, there is also the 'Quick Test' button in the bottom toolbar that runs some basic tests.
As a reminder, each setting mentioned on here will have more detailed information in the appropriate Settings page elsewhere on this site.
Test Tutorial
Start Test Piloting
Just like build piloting, once started you simply fly around the area and the tester will fire line traces around you.
Each line trace is checked to see if it has one of your chosen volume classes occupying that location.
As you fly around, you'll see the debug of some line traces around you, changing colour depending on if they're currently colliding with anything.
If an issue is discovered while piloting a small debug point will spawn for a short while as you can get a sense of issues as you pilot. You'll also see a counter increment and a small sound play, giving you feedback.
Once you press Stop, scanning stops and any warnings/errors found will appear as sprites on the tester actor, called 'Volumator_Tester'.
On the right you can see some tester piloting, in this case with a large number of detection rays. This is set in the Detection Settings and can be increased from the default of 11 up to 100 rays.
Start Test Drone
Again, like the drone builder, position the camera to the middle of an area enclosed by geometery and/or barriers and press Start Test Drone. A tester will spawn and scan the area, turning around if it bumps into anything.
As with piloting it will by default search out areas with no volumes.
The testing process is usually less CPU intensive than building, so the drone can operate very rapidly. The debug visualisation will help inform where it's going and you can of course slow the drone down in Drone Settings if you want to see what is happening to it.
On the right you can see the visualisation of the drone, with gree lines being line traces with no collision, red with collision and debug points (on the right) showing warnings/errors briefly.
Feedback
While piloting or droning, you will get feedback as to the number of warnings and errors detected. In the case of drones you will also get two progress bars that fill, when either reaches max the drone with stop:
Progress: This is the max number of total scans set in Drone Settings: Max Drone Scans
Auto-stop: This is how many scans it's been since an error was last detected, set in Drone Settings: Auto-Stop-Testing
Both exist to stop the drone running forever and so you can be alerted as soon as a threshold has been reached.
Test Volume For Geometry Changes
With a volume (or depot) selected you can check to see if the geometry that originally determined the volume shape has changed by using the Test Volume For Geometry Changes button.
This is done by testing all the originally detected collision points to see if they are still colliding with something. If they are not, it means something in the level has changed. Moving the volume doesn't impact this test as the locations are stored in world-space, meaning they are independent of the volume.
This can be an easy way to see if anything has drastically changed in your level.
The test done here is distinct from other tests like warnings/errors, as other tests are checking to see if an area is covered by a volume. Instead here we are checking to see if points that were previously colliding with something are still colliding with something. Instead of checking the volume, we are checking the world.
They are not necessarily issues, and the normal tests are more important, but are worth investigating to see why this is happening and if it's important.
Note, the standalone testers cannot check for this specific issue type as they don't have context or 'history'. The data used for this test comes from the Volumator_Data component that stores the original scanning points.
On the right you can see the result of moving the wall on the right furher to the right, causing the volume's detected collision points to no longer collide with the wall. This has created a string of Geometry Change warning sprites (the ? icons).
Teleporting To Warnings and Errors
Here we can teleport the camera to the various issues that have been discovered by testing. We attempt to find a good camera angle to see the sprite, but it can be difficult with tight geometry, so we also flash a debug sphere and point to highlight where the sprite is.
Each of the four issue types has it's own set of teleport buttons and each can be cycled through next/previous to work your way around the various locations.
This feature is especially helpful in large, complex or obscured areas where finding the sprites can be challenging.
What you have selected is important to what is available for teleporting. If you have a volume or depot selected, a quick test is run first, thus showing only results that come from the quick test. If you have run and have selected a standalone tester (the testers discussed on this page) then it will cycle through those results, which will be more thorough. If you have nothing selected it'll check if there's a tester actor in the map somewhere and use that. If you have nothing selected and there's no tester, it'll check if there's a Volumator_Billboard actor in the map, which is used to temporarily display errors, and it'll use that. So hopefully you should be covered!
On the right you can see a Geometry Change warning flash as we teleport to it.
Quick Test
The Quick Test in the bottom toolbar is handy to quickly test a volume or depot. It works differently from the standalone pilot/drone testing discussed above as it only uses previously stored detection data.
When a volume is originally scanned in the detection phase, all the detection points are stored in the Volumator_Data component. We use the originally detected collision points as warning test locations to check if our volume is still covering them. We use the non-collision points (which will be in open space) as error test locations to also check our volume. We also run geometry change tests too. Multi-volume tests are not run on quick tests, but a simpler 'overlap' test is run.
How could a volume not cover detected locations if they were detected and used to generate the volume? Perhaps you generated the volume with not enough Resolution and curved sections are not inside the volume, or perhaps you moved the volume's location, or perhaps you simplified the volume too much, there are a few potential reasons.
While useful, it's important to note that the quick test uses the detection data from when the volume was originally built... this data may be out of date and the world may have changed, also the detection data is limited by the MinPointDistance, unlike standalone testers. So it's always best to do a proper standalone test if you want thorough test results. This is why the Automation/Depot system always does a proper standalone tester rather than relying on a quick test when evaluating volumes.
However, the quick test is still really helpful to gauge the integrity of a volume, especially while you're perfecting a newly detected volume as you know the test data is good. In fact, we automatically run a quick test on generation of any volume so you can see where errors may be. But it is important to know the limitations of these quick tests.
On the right (middle) you can see the result of a quick test on a volume after regenerating it with too high a resolution value, resulting in the curves not being covered by a crude volume.
Quick test will output it's findings to the log, as shown on the right (bottom). In addition to the number of warnings, errors and geometry changes it detected, it'll also report if the volume overlaps with any other volumes of the same class in the map. While this isn't a replacement for full multi-volume tests, it's helpful at a high level.
The log output also shows if the volume has been moved from it's original location, as also shown on the right (bottom). Whether the volume has been moved will factor into the tests as it indicates the volume is no longer where it 'should' be, which could be the cause of some errors.
Show Report
Again not strictly part of the Test panel, but tangentially related, the Report button will run quick tests on selected volumes (or ALL volumes in a map if nothing is selected).
The report will show you a large and helpful amount of data about volumes, as well as the results of the quick tests.
You can read more about this in the Toolbar section of this guide. There is also a Depot report that gives information related to depots.
Testing and Reloads
Testing works by taking input location vectors and testing to see if a test location is inside of the volume's brush component shape.
If a volume has been Regenerated in any way (i.e. changing the shape of an existing volume using volumator's tools) then the brush gets updated on the volume and the standard method of testing no longer works as Unreal doesn't update the brush correctly.
Volumator detects this scenario when running a test, and switches testing on that volume to an alternative testing method which involves generating a bounding volume hierarchy for each impacted volume. This method works perfectly as well, but it does require more CPU.
Therefore if you are finding testing to be sluggish after regenerating volumes, you can 'fix' this by simply saving and reloading the level. In worst case testing the BVH testing method takes around 25% longer to complete and can make your PC sluggish while testing, but this is usually only noticeable in levels with lots of volumes and multi-volume testing enabled. Usually it is not a factor but I wanted to mention it in case it's noticed.
Volumator will report on volumes that would benefit from a level reload, in the mini-log when generating and there's a column for this in the Report called 'Reload'. Both of these are shown on the right.
None of this impacts runtime in any way, it's entirely editor only.
Google Sites
Report abuse