Architecture AI Pathing Project: Selecting Spawn and Target Positions from Objects in the Model

November 23, 2020

Spawning and Pathing System

Architecture AI Project


Updated Spawning System to Use Objects within Model as List of Options

We wanted to update the spawning system so that instead of being arbitrary points, both the spawn location and target location were tied to objects that could be found throughout the entire model. The system is already creating a list of all the objects within the model for applying colliders and various other components, so that could be accessed for this purpose as well. This list of objects was then put into a UI dropdown for selecting both the spawn position and the target position. The transform of the selected object was then used for that respective part of the pathing.

Highlighting the Spawn and Target Locations

I wanted to highlight both the spawn and target objects to make it more apparent where the agents would be aiming to path. The first implementation I went with for now changes the material of the object. The spawn object becomes an orange color, and the target object becomes a green color. This however is not very clear with many objects, because some such as windows and doors are within the walls, which are hard to see from the angle we are using currently. I will be exploring better options such as spawning an extra object or UI element around the area to make it more apparent.

Example Images Showing a Few Paths with Varied Spawn and Target Positions

Next Step

We want to determine how we want to narrow down the list of options to select as spawn and target locations since we generally will not need access to every single object. We have to decide how flexible the options need to be, as the more rigid it will be the more we can automate it and narrow the options down to a select few.

via Blogger http://stevelilleyschool.blogspot.com/2020/11/architecture-ai-pathing-project_23.html

Architecture AI Pathing Project: Automating the Sizing of the Node Grid

November 17, 2020

Automated Node Grid Size

Architecture AI Project


Title:
Unity Bounds Documentation

By:
Unity


Unity – Informational

Description:
Unity’s documentation on their Bounds class and its methods.


Automating Process of Sizing the Node Grid

The A* pathing uses an underlying grid of nodes to inform the agents how to move through an area. A value must be input to tell the grid how large of an area to cover with these nodes. Originally these values, which are two dimensions of a rectangular area, had to be input manually. Since this grid will always be covering a full architectural model, it made sense to be able to access the model and automate the sizing process through the size of the model.

Encapsulate Bounds of All Children Objects

Since we are dealing with models in Unity, I looked to the Bounds class to help with automating this grid creation process. Immediately, Bounds can be used to find the bounding volume of a single mesh/renderer/collider. The architectural models however are complex models made up of many children models, including both small elements like windows and entire structural elements like the walls. Needing to create bounds that made sure they contained every bit of the architecture, I created a method which looks through all the children of the overall parent architectural model object and uses the Bounds.Encapsulate method to continually increase the size of a single bounds reference until it contains the entirety of the model.

Using Bounds for Sizing

After creating a set of bounds which encompassed the proper area of interest, they needed to be used to set the node grid. The Bounds.Size property returns a Vector3 which gives the dimensions of said bounding box. Because of our current frame of reference, we could use Bounds.size.x and Bounds.size.z to find our two dimensions for our 2D node grid area.

The following image shows an example model with the created bounding box around it (shown as a yellow wire box). The node grid can be seen as all the small red cubes. It can somewhat be seen that the node grid is about the size of the bounding box using the above approach, but it is still tied to the origin since the repositioning logic has not been added yet.

Example of Model Bounding Box with Resized Node Grid

Next Step

The size gives us the dimensions of the node grid, but to fully automate it it still needs to find the proper position of the node grid. Just for now the node grid is still starting at Unity’s origin and building out from there, regardless of the position of the model. Positioning the grid will either use Bounds.center to find the center of the model and build out from there, or Bounds.min or Bounds.max to find one corner of the model and build out from there. Either of these options should give similar results.

via Blogger http://stevelilleyschool.blogspot.com/2020/11/architecture-ai-pathing-project.html

Architecture AI Pathing Project – System Manager and Automating Component Application to Imported Models

October 29, 2020

Automating Component Application and System Manager

Architecture AI Pathing Project


System Manager and Initialization

The integration of several classes and adding more has started to create a lot of necessary references becoming difficult to time properly. To make sure a certain class has already initialized or some other class has performed its Awake() method I end up making extra references and method calls within other classes so the proper references are set before peroforming those methods.

In an effort to organize this better and make the timing more understandable, I am looking at making a SystemManager gameobject to replace the DemoManager, and either add an Initialization class to this or make it its own class if it does not require being a monobehaviour. This Initialization class will be responsible for calling all the major system classes initialization methods in the proper order to ensure references are met. This will also require moving some Awake and Start methods from other classes to some Initialization method.

This could also be a good case for an interface dealing with initialization. I could then make all the major system classes implement this interface and then plug them into an Initialization Manager class that calls each of the interface implementing objects’ Initialization methods.

Automating Component Application to the Imported Architecture Models

To make the system more user friendly, the more it can automate the better. The system uses Influence objects as the basis of many of the architectural elements applying their effects to the surrounding area, but these are components that must be added to the objects themselves. Since the objects are coming in as part of a large scale model from software like Revit or 3DS Max, they have nothing on them ahead of time. Right now specific objects need to manually be found and have the proper components applied, so we would like to automate that process.

Approach 1 – Gather All Children of Imported Models and Apply Components and Layers by Name

The first approach I will try involves manually adding a reference to an imported model object in Unity’s inspector, and this will give the new class (named ApplicatorManager) a reference to create a gameobject list of all the children objects. From here, ApplicatorManager can go through each object and check if its name contains a certain string to determine which objects to apply the designated layers and components to.

To create this connection of strings and components or layers, I am creating a new small data class called Applicator. This will hold: a string (search term to look for in names of objects), an enum (either “component” or “layer” to determine which thing it will be adding), and either an Influence object (for component) or a layer integer value (for layer). The ApplicatorManager will have an array of these Applicator objects which the designer can add/remove from in the Inspector and fill in the search term, whether that should add a component or layer, and which one for each element in the array.

Summary

I think organizing all of the initialization processes for the several main system core classes will be beneficial for controlling the reference timings as well as thinning out some of the larger classes. The Applicator approach I am looking at adding may not be terribly efficient, but it only needs to be run once at the start of setting up a model each time so it will be good for getting the connections setup for now. Since I am looking at a component application method, it could be worth looking into an option that can do this in the Unity editor so it only needs done once a model is imported and not each time the project is actually run. This could be a good way for reducing load times of the system.

via Blogger http://stevelilleyschool.blogspot.com/2020/10/architecture-ai-pathing-project-system.html