Sender: |
|
Subject: |
|
From: |
|
Date: |
Tue, 8 Jan 2013 15:03:50 -0800 |
Content-Type: |
multipart/alternative; boundary=e89a8fb206e47cd1ea04d2cef566 |
MIME-Version: |
1.0 |
Reply-To: |
|
Parts/Attachments: |
|
|
I've just committed an important update to GeoMason. For GeomVectorField
instances that contain dynamic geometry -- e.g., corresponding to moving
entities -- the spatial index no longer is updated for each geometry
update, particularly those effected via setGeometryLocation() invocations.
This is because updating the spatial index for every single geometry
change is computationally burdensome. It's more efficient to move all the
entities first and then update the corresponding spatial index in one go.
And so there are two new GeomVectorField member functions:
updateSpatialIndex() and scheduleSpatialIndexUpdater(). The former
rebuilds the spatial index from the current set of geometry stored in the
field. The latter is a convenience function for returning a Steppable that
you can schedule to invoke updateSpatialIndex() with each time step.
The following is an example pulled from the modified CampusWorld demo:
public void start()
{
super.start();
agents.clear(); // clear any existing agents from previous runs
addAgents();
agents.setMBR(buildings.getMBR());
// Ensure that the spatial index is made aware of the new agent
// positions. Scheduled to guaranteed to run after all agents
moved.
schedule.scheduleRepeating( agents.scheduleSpatialIndexUpdater(),
Integer.MAX_VALUE, 1.0 );
}
Yes, this hints that a new minor release of GeoMason is forthcoming. I've
a few more loose ends to tie up before I finalizing it, though; I'm hoping
to have it out the door by the end of the week.
--
[log in to unmask]
|
|
|