Sorry if I led you in the wrong direction with my comments about
`org.nlogo.mirror.Mirroring`. Your mention of tying turtles to "an
agent object in Java that carries the read in variable updates from its
NetLogo counterpart" in the initial post led me to believe that you were
interested in update-based rendering.
If I follow a similar method for Links, I know I can do as Jason
suggested and pull down the AgentSet of links, using
.world().links().agents()., but would I similarly need to cast each
element as something to access the methods, such as (Link) or (Patch)?
Yes. `workspace.world().links().agents()` will return you a collection
of `Agent` objects. But in order to draw patches and links, you'll need
access to link- and patch-specific information, so you need to convert
your `Agent`s to `Link`s and `Patch`es in order to access to their
type-specific information (for example, `pxcor` and `pcolor` for
patches, and `end1.xcor`, `color`, and `shape` for links).
I had been intrigued by LinkManager because it seemed the most
convenient where I could get an agent list of Turtles linked to/from a
particular turtle and conceptually allow me to, in the Processing
sketch, have an up-to-date list of turtles that each Java agent should
draw link lines between.
It /is/ true that `LinkManager` allows you to look up other turtles
linked to a particular turtle. However, it's not clear to me how that
might be helpful for rendering. If you iterate over the links, you
immediately have all of the link objects, which you need for figuring
out shape and color, and they also give you easy access to the
coordinates between which to draw the link. If you use
`LinkManager.findLinkedWith`, you have to iterate over your turtles to
find connected turtles. This will get you pairs of turtles that have
links between them. But you probably want to weed out the duplicate
pairs (that is, for undirected links, the pair `(turtle0, turtle1)` is
redundant with the pair `(turtle1, turtle0)`), since you likely don't
want to draw a link twice. After that, you've still basically only
obtained the x and y information about the links' ends. You still
likely want color, shape, and label, so you then need to convert your
turtles into links anyway by using `LinkManager.findLink`. So you can
go through that extra effort to get the same effect, but the most direct
path to getting the link information is just to iterate over the links
from `workspace.world().links().agents()`.
On 05/20/2014 08:50 AM, Brant Horio wrote:
Seth,
Many thanks for your input/insights as well. The process you've
outlined is actually exactly what I am executing. My Processing sketch
is successfully drawing all agent movements and updating
appropriately. It's the rendering of appropriate Links and Patches
that have me confused. Earlier in this thread I gave a little snippet
for how I'm iterating through the AgentSet of turtles, using .world(
).turtles( ).agents( );, and casting each as (Turtle) to allow use of
the methods to pull out the information I need in the visualization.
If I follow a similar method for Links, I know I can do as Jason
suggested and pull down the AgentSet of links, using
.world().links().agents()., but would I similarly need to cast each
element as something to access the methods, such as (Link) or (Patch)?
I had been intrigued by LinkManager because it seemed the most
convenient where I could get an agent list of Turtles linked to/from a
particular turtle and conceptually allow me to, in the Processing
sketch, have an up-to-date list of turtles that each Java agent should
draw link lines between.
I hope that makes sense. I'm not a programmer by trade and I
appreciate the time you all are taking with me. And on that note, the
response time on this forum is amazing; it truly enhances this
community. Many thanks on behalf of all.
Brant
On Monday, May 19, 2014 6:19:41 PM UTC-4, Seth Tisue wrote:
>>>>> "Jason" == Jason Bertsche <[email protected]
<javascript:>> writes:
Jason> you just want to run NetLogo headlessly and provide your own
Jason> version of the NetLogo view, which, of course, is kept in
sync
Jason> with the state of the model as it progresses. Is that right?
Jason> If so, and if you're dealing with the code from the
'headless'
Jason> branch of NetLogo, then take of a look at
Jason> 'org.nlogo.mirror.Mirroring
Jason>
<https://github.com/NetLogo/NetLogo/blob/headless/src/main/mirror/Mirroring.scala
<https://github.com/NetLogo/NetLogo/blob/headless/src/main/mirror/Mirroring.scala>>'.
Using
Jason> that and its `diffs` method, you can find out what variables
Jason> have changed in the model since your last snapshot, and then
Jason> update your visualization according to that diff.
Generally I second everything Jason has said in his posts. But
Brant, I
want to make sure it's clear to you that the simplest possible
renderer
wouldn't use the mirroring stuff at all. And in fact, NetLogo's own
built-in renderer does not use the mirroring code.
The simplest possible renderer would simply iterate over all of the
agents in the world and draw each one. When it's time to render the
next frame, you just do it all over again.
There are some scenarios in which you might want to persist agent
state
in the renderer between frames, and then use the mirroring code to
update that state. But involving the mirroring code adds a layer of
complexity, so you shouldn't go that route unless you're confident
that
it makes sense to do so in your scenario. Involving mirroring is not
the shortest path to a working renderer.
--
Seth Tisue | http://tisue.net
--
You received this message because you are subscribed to the Google
Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
