Concise and optimal partial refresh

[chanattan]

Is your request related to a problem? Please describe.
I am a bit frustrated with 500 buildings taking up to 2GB of ram in simulation, with refreshing facet set to true for all of them. I have to think more deeply in having efficient display that could be scaled-up. Also, I have different kinds of buildings which are sometimes visually dynamic, sometimes not.

Describe the improvement you'd like
I have certain buildings among lots of others that need to be refreshed and others which do not need to. I want to have easy and concise ways to have different visuals without taking a toll performance-wise.

Describe alternatives you've considered
One way is to separate buildings into two different species: a dynamic and non-dynamic one, which are differentiated in the refresh facet afterward. If a static building were to change after a certain time (it was initially static to gain performance), then a dynamic building would be drawn (it was previously invisible) over the non-dynamic one, but it would cause some glitching issuing in scaling up/changing position tweaks.

Additional context
There may be lots of different cases to consider. We may want static objects that may change after a long time and thus do not need to be refreshed during this time to gain performance. Putting if conditions and flags to trigger changes in display becomes quite messy in the code, let alone graphical troubleshooting if it pertains to the same object. I was also wondering about having different objects that refresh every X cycles/time step but as the buildings are all part of the same display (and for now, species) they all share the same characteristics.

[AlexisDrogoul]

Hi, thanks for the report. However, it is a bit difficult to understand what you are trying to achieve. I can only guess you have a species of buildings in your model, some of them being potentially "changeable", others no ? And your mention of static/refresh refers to the displays, right ? Since it is not a bug or an issue per se, and since you are not asking for a specific improvement, I'm moving this to a discussion and I would advise that you create a small model describing your different attempts.

[chanattan]

Hello, thank you for the answer. I understand the difficulty.
This is exactly it, some of the buildings are potentially "changeable" on the display, others not, which I call them static.

Here you will find short pieces of code which I hope will make it clearer.
Suppose we have a simple Building species populated in a simulation. A building, if considered as dynamic (i.e., may change at some point on the display), currently has to be refreshed at every cycle which makes a loss in computation.
In order to implement the above behavior more efficiently, Arnaud advised me to provide the Building species with two aspects (in 3D):

aspect regularBuilding {
      draw shape color:#gray;
}

aspect dynamicBuilding {
  if (active){
      draw shape color:#red;
  }
}

What can be done with that is to have a duplicate of all the Buildings, such that we have the static buildings (some of them change visually at some point but otherwise they remain static buildings) displayed, and the dynamic ones (duplicated buildings) are being drawn on top of the static ones. We give some offset to the dynamic buildings to unsee the static building (which we want to be dynamic actually).

species Building transparency: 0.05 aspect:regularBuilding refresh: false;
species Building size: point(1#m, 1#m, 1#m) position: point(0, 0, 1#mm) transparency: 0.1 aspect: dynamicBuilding refresh: true;

NB: instead of using an offset in height in position, we may use scale to make it globally bigger, although a workaround it doesn't work as the kynematic drawing order makes the translation after/before scaling and draws at the wrong position the building.

This workaround works but doesn't have a significant performance improve, surely because we have duplicate species which takes a toll on performance and we still have to loop over each aspect function of the species (even though it may draw nothing). Otherwise, I find this workaround too complex and not concise enough, where it gets messy if we want things more complicated. Last but not least, I'd like to consider different refresh periods for different buildings.