Devblog Post #8

November 1, 2014

 

Since the first release Tihomir has officially integrated the project with MonkeyBrains. Tihomir has been working with naming, style and structure conventions in order to have an uniform project.

I have improved the wander behaviors: Wander behaviour has been redesigned (Now called wander area), It's a clearer and simpler version; Simple wander behavior has been included and relative wander now extend from simple wander.

The license has been updated with a jMonkeyEngine license header. This allows jMonkeyEngine to do modifications and maintain the code.

Finally, I have updated the documentation and website.

Devblog Post #7

August 20, 2014

 

I have finished the project, polished all the code and created the proper documentation.

I have also created a website where you can find all the information about the project.

Devblog Post #6

August 12, 2014

 

I have included the following behaviours:

  • Containment: Remain within a certain region
  • Path Follow: Steer along a predetermined path
  • Wall Approach: Maintain a certain offset from a surface
  • Queuing: Leave through a narrow "door"

In addition I have improved the compound steering class:

  • Priority steer components
  • 2D Steer behaviours support

If you have issues related with components cancelling each other out, that "can be addressed by assigning a priority to components . (For example: first priority is obstacle avoidance, second is evasion ...) The steering controller first checks to see if obstacle avoidance returns a non-zero value (indicating a potential collision), if so it uses that. Otherwise, it moves on to the second priority behaviour, and so on."


Downloads:

Devblog Post #5

July 26, 2014

 

The "unaligned collision behaviour" is similar to the "obstacle avoidance" one but the implementation is different.

Basically we have predict the agent future position and the future position of any obstacle. Once we have predicted those positions we select the more dangerous threat (If it exist), that is the one that need less time to collide with the agent.

To avoid that obstacle we have two situations:

  • The velocities of the agent and the threat are perpendiculars
  • They are parallel or antiparallel

If the velocities are perpendiculars we will check the predicted collision positions and we will create a force that evade this collision, that is the offset between both positions. However if they are parallel or antiparallel we just need to move to the side to separate from the other object path.

Here you have a video from the demo (Also you can see the obstacle avoidance updated):

Again, you can check the demos here out , and download the source code here.

Devblog Post #4

July 9, 2014

 

I been focusing at the obstacle avoidance behaviour. The original idea is to create a cylinder oriented to the agent moving direction and base radius equal to the agent bounding sphere radius:
basic explanation

Before that We check if the cylinder is in collision with any obstacle, We will check if any obstacle bounding sphere is inside the collision area of the cylinder:
basic area explanation

Finally, If we find that the the cylinder is colliding with an obstacle We create the steer force perpendicularly to the agent moving direction.

Here you can see how the behaviour, based on this idea, works combining it with "seek":

As always you can check the demos here out . Furthermore If you are interested, you can download the source code here.

Devblog Post #3

June 25, 2014

 

I have made important changes in the "Leader Following" and "Arrive" behaviours in order to improve the implementation. I have added a new "auxiliary" behaviour: "Slow"

The "Leader Following" behaviour is similar to pursuit behaviour, but pursuers must stay away from the pursued path. In order to stay away from that path the pursuers resort to "evade". Furthermore pursuers use "arrive" instead of "seek" to approach to their objective.

Because of that changes at "Leader Following" and "Arrive" behaviours I had to make some changes at "AbstractStrengthSteeringBehaviour" and "CompoundSteeringBehaviour". This changes allows me to increase or decrease the final velocity produced by a steer behaviour. Furthermore I have included the option to use a 3D position instead of a agent for the target at the "seek" behaviour.

I have improved and/or fixed some issues at "Agent", "SimpleMainBehaviour", "BalancedCompoundSteeringBehaviour", "EvadeBehaviour" and "PursuitBehaviour" source files, making some minor changes.

Finally; I have updated the "Leader Following" demo so now it is more dynamic, and added a "pursuit" demo.

If you check the demos here out , you will understand everything better.

Devblog Post #2

June 9, 2014

 

These two weeks I have added the following behaviours:

  • Slow
  • Move
  • Arrive
  • Cohesion
  • Alignment
  • "New" Pursuit (I have renamed the old to LeaderFollowing)

In order to include these new behaviours I had to make some changes in the Agent and GameObject classes. In agent I have added an radius attribute so that we can set up the size of bounding sphere (Used for example in the arrive behaviour).

In addition I added a velocity attribute in GameObject so that you can update that attribute each frame. This attribute is useful for the slow behaviour.

In this video you can see the Cohesion and Alignment demo:

The move behaviour is similar to the SimpleMoveBehaviour but move extends from AbstractStrengthSteeringBehaviour.

Here and here (Demos) you can see the differences with the last version.

You can download all the demos here .

Devblog Post #1

May 31, 2014

 

Basically these weeks I have been integrating all the already developed code into MonkeyBrains and making some demos.

First of all I added the behaviors already developed to MonkeyBrains:

  • Separation
  • Pursuit
  • Evade

Then I started testing the steering behaviors developed in MonkeyBrains so I realized that when you try to add several steer behaviors to an SimpleMainBehaviour object (Container for behaviors in general) the rotation don’t work well:

looking bad

The solution is to create a new class (CompoundSteeringBehaviour) that can contains steer behaviors. So you can add several behaviors to an object of that class and then add it to SimpleMainBehaviour.

Furthermore I have extended CompoundSteeringBehaviour with BalancedCompoundSteeringBehaviour so that each force added to this container is reduced in relation with a proportion factor. Where "Proportion factor" = "Partial Force" / "Total container force".

forces example

BalancedCompoundSteeringBehaviour is useful per example with the evade behaviour: We have an agent with the evade behavior applied, 100 other with the pursuit behavior and the movement speed is the same for all; Then if the maximum speed it's not correctly applied to the evader or we don’t want to modify it, the evader can gain an unwanted extremely high speed.

composed diagram

If you have several steer behaviors in the same agent, you may want to set up which behavior is stronger. For this reason I extended AbstractSteeringBehavior with AbstractStrengthSteeringBehaviour so that you can set up the length of the steer vector or only modify one axis (This is useful If you want the behaviors only work in a plane).

In the pursuit and separation demo you can see how the compound and strength behavior works (Left mouse press to rotate the camera).The behaviors applied to the demo were pursuit and separation (In a balanced container) for the pursuers, and simple move for the target.

The evade demo uses seek behavior instead of pursuit for the pursuers.

Download the .jar executables (Double click) demos here. Be sure that you have java (jre) installed.

You can download the source code here (BSD License)

Groundwork

March 3, 2014

 

These weeks I have been reading and seeing examples of jME. Then I started checking the java steer behaviors library.

First of all you can see that the pursuit function do not work well, some pursuers stay in front of the pursued. Instead, they should evade this situation like is shown on the picture.

get out of the way

Furthermore, the “avoid” behavior is really bugged, the vehicles are trying to change the trajectory but “other forces” impede it. This should be further investigated in detail.

In order to fix the pursuit behavior it is needed to follow two “rules”:

  • If the vehicle is near the objective change his target from the predicted location to the real location.
  • If the vehicle is near the objective and is in front of the objective push it away.

Before:
before example

After:
after example

Video:

The ideal solution consist in implementing a blend of forces: Some forces will have more strength than other depending of non finite circumstances; and If you blend the forces, you have the final result.

Instead of this:

//See if the vehicle is far away from the target 
float distanceFromTrueLocation = location.distance(targetTrueLocation); 
boolean isFarAwayFromTheTarget =  distanceFromTrueLocation > distanceToChangeFocus; 
				
if(isFarAwayFromTheTarget) //Two (finite) solutions 
  seekingLocation = targetPredictedLocation;    
else //If its near of the target then focus the target and not the predicted location 
  seekingLocation = targetTrueLocation;

We can do this:

//Change the focus, non finite posible solutions
double focusFactor = this.changeFocusFactor(distanceFromTrueLocation);
seekingLocation=targetTrueLocation.add(targetPredictedLocation.subtract(
  targetTrueLocation).mult((float) focusFactor));

Using the “changeFocusFactor” auxiliary function:
    private double changeFocusFactor(float distanceFromFocus){  
        double factor;
        
        if(distanceFromFocus > this.distanceToChangeFocus)
            factor = 1;
        else
            factor = Math.pow((1 + distanceFromFocus/this.distanceToChangeFocus), 2);
	      // Real number:infinite results 
            
        return factor;
    }

However, a finite circumstances solution can be useful for some purposes. Per example, We can add some extra forces depending on a finite combination of basic steer behaviors: Avoid-Pursuit, FollowPath-Avoid, etc. The extra forces will allow us to merge the behaviors nicely.

Independently, the user should be able to change the “distanceToChangeFocus” variable with a proper API.

In the previous video you could see some “Wiggling” and “Jittering” problems. It is very important to identify the origin of the bug, taking the time needed, and make a proper fix. In this case we will need to add another settable variable and improve the algorithm. In this video you can see the difference (Notable):

However, It still can be improved and is needed to be developed further.

Finally, custom models can be used easily as you can see in this video:

Download the source (pass: jmonkey): here

Proposal

Proposal - short version

 
 

Original design by Free CSS Templates.