redesigned the map derived material system because an issue was found

all the materials were loaded with the map

when a map is being streamed, nothing as big should be preloaded in entirety, not to mention cases where the materials end up not being used at all

instead saved them to separate files (one might say OFPM) while still supporting them being edited in the map editor (key code remains basically unchanged, at least for now)

#gamedev #enginedev

addressed the issue while working on v2 map streaming (partitions: https://mastodon.gamedev.place/@archo/116291337841878255)

seems like a lot of the things generalize well when what was previously a "map" is now a "component container", and there's a few more of those

manual spawning ended up being handled by the "pending set"

the "per-world component list" is basically the "run set" - other sets of components are either copied (maps/partitions) or moved (pending) into this one

#enginedev

had to mostly revert 2 commits that moved actors/spawners into the world directly

as it turned out, component container was a better location for it

now world contains 2 containers (the "run set" for what's active and the "pending set" for what's manually added and about to be active next frame)

seems like in the end the component container will be basically the same as the map object, just controlled differently and with copying features

#gamedev #enginedev

finished removing the old submap system from the map editor a while ago

turned out that it was heavily integrated

now dissolving maps from the runtime code

already managed to dissolve most of it

just need to convert things to a point where a map can contain a categorized set of objects that can be moved into the main world (and ideally also back out without destroying them)

thinking of moving actors and spawners into the component container now

#gamedev #enginedev

now wondering if I want one file per partition or one for all, or some hybrid

per-partition actor UID lists could become long

but I don't want to try replicating the partition hierarchy in the file system either

could have one master file + per-partition files

all the master file needs to be useful is the hierarchy (e.g. tab-indented list of partition IDs)

the rest could be in per-partition files (ID, name, bounding volume(s), real/imposter actor UIDs)

#gamedev #enginedev

this probably already exists somewhere at least partially but here's the idea of partitioning I have so far:

- not a 2D grid (like UE)
- hierarchical (partitions can have subpartitions)
- orthogonal to map editor layers
- each actor stores which partition it belongs to, but also there's a cache to find actors from partitions (for faster limited map loads)
- actors can be marked real or imposter (LOD)
- partitioning doesn't affect actor path (<map root>/_ofpa/<world UID>/*)

#gamedev #enginedev

now thinking about extending the OFPA system for a more open-world type thing

I had submaps initially (like UE) but ended up never using them

I also don't like the idea of scenes (Unity, Godot) since it adds too much friction for same-logical-map transfer actions and makes linking too manual overall

I also want the paths to be stable since all my resource refs are path-based

currently leaning towards removing submaps and adding a partitioning extension instead

#gamedev #enginedev

added portal walk and created a small stress test (10 portals)

I can scale it up later if needed, so far I'm not expecting more than 10 per tile (and even then the camera would need to be very zoomed-in to go through all 10 for most tiles)

will probably also need some editor features to make lighting easier to preview (e.g. using pivot as light origin, different camera modes) but in any case, this might be good enough for now

#gamedev #enginedev #graphics