projectmesa / mesa

Mesa is an open-source Python library for agent-based modeling, ideal for simulating complex systems and exploring emergent behaviors.
https://mesa.readthedocs.io
Apache License 2.0
2.54k stars 891 forks source link

Consider whether we should define a fixture class #1234

Open rht opened 2 years ago

rht commented 2 years ago

Edit: even earlier question by @Holzhauer

Is there any way to prevent certain agents from being redrawn each tick on the CanvasGrid? I have e.g. wall and furniture agents in the model. Not redrawing these each tick would cause the simulation to appear much smoother.

Initial discussion at https://github.com/projectmesa/mesa/pull/1219#discussion_r839489994=. In that thread, you can read how MASON does it, and how it is possibly to performantly define a fixture as a non-actioning agent that is added to the model space, but not the model scheduler.

wang-boyu commented 2 years ago

What was mentioned in https://github.com/projectmesa/mesa/pull/1219#discussion_r841024888 about MASON seems to be about its physics engine. Not sure whether that relates to our interest.

I did a quick search in MASON archives of their mailing list and found this. In particular:

Also, my graph is static and does not change at all during the simulation, so there would be no reason to redraw it at every time step. I found a flag called immutableField in the FieldPortrayal class, is setting this value to true enough to prevent redrawing? Or is there something else I need to do?

No. immutableField just informs the FieldPortrayal that the field will never be changing (as is the case for you), and so the FieldPortrayal can cache its drawing and just re-draw the cache rather than rebuild it, if that's useful.

So my naive guess is, to have an immutable field (i.e., FieldPortrayal with immutableField set to True) containing all fixture objects that do not move, so that these objects are cached for re-drawing, without being rebuilt.

What this translates to Mesa is, probably, to have a separate space (e.g., model.immutable_space) keeping all fixed objects, and this space gets sent for visualisation only once; subsequently it is cached at frontend, without being sent at each step.

What I'm doing in a feature branch of mesa-geo is similar but slightly different (see https://github.com/wang-boyu/mesa-geo/commit/7adc14e8a36737077045e26473918745dfd55367): fixtures are added as layers into GeoSpace, and they are sent to frontend only once when initialising the model. Referring these fixtures as layers is from the context of GIS, and relates to the idea from https://github.com/projectmesa/mesa/pull/1219#discussion_r840870659.

But this implementation is ugly - several changes need to be done to visualization/ModularVisualization.py and visualization/templates/js/runcontrol.js which in fact belong to Mesa. If there can be any generic solution from Mesa, I'll use that instead.

rht commented 2 years ago

Ah, right, I didn't check that that MASON's Wall.java is defined in the context of its physics engine. Though the parent class, SimplePortrayal2D is a generic class for portrayal.

Though, it looks like Field refers to grid / space, instead of a fixture object, and so I don't see how you can conclude that fixed objects are located in this separate immutable Field in MASON.

wang-boyu commented 2 years ago

I never used MASON in the past so I could only guess, and may be wrong : )

In their PDF manual, there are diagrams explaining the overall architecture and visualisation process on Page 9, Page 155, Page 180, and Page 246. That's why I'm guessing that fixed objects are handled separately in immutable field. But again, I could be wrong.

rht commented 2 years ago

I emailed the MASON-INTEREST-L aatt LISTSERV.GMU.EDU mailing list. Not sure if it went through.

Just in case, I will cc @SeanLuke here.

jackiekazil commented 2 years ago

@rht not sure that is the right Sean Luke. Just incase, I sent the Mason Sean Luke an email with a link to this thread.

rht commented 2 years ago

The right Sean Luke has posted his answer on the MASON-INTEREST-L mailing list. I also posted it on Matrix. I should have also posted it here:

That's exactly how it's handled in MASON: but note that at present it only works with the "fast" field portrayals, that is, ones which draw objects as simple colored squares rather than letting the objects draw themselves. If a field is immutable, MASON draws the field into a semitransparent buffered image (a picture), then splats the picture on the screen. Thereafter if the drawn boundaries haven't changed, MASON just resplats the image.

Sean