CODEWITHSUNDEEP
netlogo
csstudent
csstudent

Reputation: 107

Netlogo export-world format

I have been experimenting trying to work out how does the export-world work, in particular how does the DRAWING section work.

I created the following code to experiment using the default environment size of max-pxcor and max-pycor of 16. If you run this code shown at the end of this post, each file produced will be 5 megabytes, so it is easy to use up over a gigabyte of data after a minute of running.

Anyway, my question is this: How does the DRAWING section work? I have seen that the first entry is at -16.4, 16.4. I have summarised some of my observations in the simple table below. The first column is how much the turtle has moved, while the second column shows partial output in the CSV file.

0.001  FF1D9F78
0.016  FF1D9F78FF1D9F78
0.093  FF1D9F78FF1D9F78FF1D9F78

I have also seen that the first entry is created when the turtle moves by 0.001.The second entry seems to happen when the turtle has moved by 0.016 and the third entry is 0.093.

I am trying to work out what the pattern could be, but there doesn't seem to be one. How much turtle movement does one of the entries represent in the CSV file?

Thanks.

---- The code is below.

globals
[
  totalAmount
]

to setup
  ca
  crt 1
  [
    setxy -16.4 16.4
    pd
    set heading 90
    set color turquoise
  ]
  set totalAmount 0
end

to go
  ask turtles
  [
    fd moveAmount
  ]
  set totalAmount moveAmount + totalAmount
  export
end

to export
  let filetemp word "turtletest" totalAmount
  let filename word filetemp ".csv"
  ;print filename
  export-world filename
end

Upvotes: 1

Views: 399

Answers (1)

Seth Tisue
Seth Tisue

Reputation: 30498

The drawing layer is just a bitmap – a grid of pixels. It doesn't know what turtles moved and how far, it only knows what pixels the turtles colored in while moving. Internally, it's a java.awt.image.BufferedImage with TYPE_INT_ARGB encoding.

It's written to an exported world file by this code:

https://github.com/NetLogo/NetLogo/blob/533131ddb63da21ac35639e61d67601a3dae7aa2/src/main/org/nlogo/render/TrailDrawer.java#L217-L228

where colors is the array of ints backing the BufferedImage, and toHexString just writes bytes as hexadecimal digits (code).

If your image is mostly black, you'll mostly see a bunch of 00 bytes in the file.

As for your non-zero bytes, it appears to me that FF1D9F78 is a pixel with alpha = FF (opaque), red = 29, green = 159, blue = 120. At least, I think that's the right interpretation? Is that plausible for what you're seeing on screen? Maybe the A-R-G-B bytes are in the reverse order? To double check it, I'd need to do export-view and then look at the resulting PNG file in a program that could tell me the RGB values of individual pixels -- I don't have such a program handy right now. But hopefully this'll put you on the right track.

Upvotes: 1

Related Questions