Create in-memory representation of project.

[muhuk]

Layers

• [x] Create Layer component. This will also be used to order entities in query.
• [x] Create a system that runs from time to time and ensures Layers' ordering is spaced out enough.
• [x] Create a system that can add a new layer on top of the stack or above a specific layer.

Preview

Previews will be rendered in a progressive way. It is likely that before the rendering of a preview is complete project will change, making the preview currently being calculated obsolete. In this case once a render pass is done it should still be displayed in the viewport but the same way an obsolete preview is displayed (grayed out?).

For this to work we need to keep two timestamps, one for the last time project is edited (edited here) and one for the last time a preview is started (started here). If edited > started, once the currently running render pass is complete (and displayed), preview render should be restarted. Similarly in the viewport if edited < started the preview is considered up-to-date, otherwise it is considered obsolete. (Need to think about edited == started case.)

• [x] Create signal for project update. (This can also be used in undo/redo system later)
• [x] Create resource that keeps track of previews.
• [x] Create an event for new layer changes (creation only for now)
• [x] Create a system that tracks layer creation events and informs preview calculation.
• [x] Create marker component for preview mesh.

Bake

In the discussion, we said bake data should be a Resource, but we will have zero or more bake setups so perhaps entities are better to store these. Multiple bake setups may be used in these scenarios:

• Terrain LoD's, having copies of the same bounds with different resolutions.

• Having low-res bakes of inaccessible areas.

  • This brings an interesting edge case; higher res bake should blend with the low-res neighbour somehow. Something to consider in the future.

---

See relevant discussion.

[muhuk]

Create signal for project update. (This can also be used in undo/redo system later)

Creating one signal for a very generic even like project update (change) is tricky.

Event should be signalling something has happened, not something should happen. Should happen part is the responsibility of listeners.

Instead of one generic event we should have each module trigger their own specific events.