managed to "lock in", as they say, and write a >400 LOC hole component

it inherits from a mesh component but also has a physics mesh and two polygons (metadata for wall clipping) as subcomponents

still need to make a thing that detects walls from nearby meshes and adjusts side planes to fit them, and some keyboard shortcuts for both that and regenerating nearby objects

also need to consider syncing portals from this component

but it should help with my hole problem

#gamedev #programming

added portal sync to the hole component

it might make sense for it to be done while moving the portal around as well (since portals use absolute coords for speed)

need to think about all the ways hole editing can be streamlined

#gamedev #programming

tweaked the lighting to match light levels on both sides of the portal

makes the texture mapping across the hole look perfectly smooth

also, while testing portal updates, it became clear that the shape of the portal has to match the mesh, otherwise things will look wrong due to room lighting being largely directionless, especially near the hole

unfortunately that might mean that non-rectangle portals might need to be rendered into textures

#enginedev #graphics #programming

added a keyboard shortcut to resync selected actors/components

already much easier to move holes around

now will also need to have a keyboard shortcut for resyncing everything likely intersecting the selection *except* the selection

either that or a shortcut for A automatically followed by B, so that only one keyboard shortcut needs to be invoked for a full update in the correct order

created the combined keyboard shortcut where first the selected thing is updated and afterwards the overlapping things are updated

need to do some integrations soon to see to what extent this might solve the hole problem

#gamedev #programming

added a button to find adjacent aligned faces and copy materials from them

unfortunately the UV mapping cannot be copied over as well so things don't auto-align as perfectly as they did in floor plan (which simply added a quad using the existing floor mapping) but it's a passable first attempt

need to figure out how to share a coord space across systems for UV gen to fix that

still yet to do a proper integration of the hole component in one of the test maps

#gamedev #graphics #programming

the first test done with a "real" (preexisting) map

initial hole setup took some time but actor templates/prefabs will take care of that

found a bunch of issues with AI navigation data and how to generate it

among those - holes need nav.links but I haven't yet provided them

but the nav.links also require 2D portal shape data and I'm moving to 3D

need to think about what's the best approach for moving to 3D before I can do much there, maybe could reuse vis.portals now

#gamedev #programming

while looking into refactoring the navigation system to prepare it for future upgrades, found a "room ID" inside the navigation area component which has existed since 2022-09 (3.5 years ago), basically from way back when I was still messing around with the code and there were no concrete plans to make a specific game yet

turns out it's been shipped despite having no use whatsoever anymore

it was used to place the components in an array for easy lookup

🚮

#gamedev #programming

transferred all nav link (🚮) functions to the portal component

the volume/portal components will probably need to be generalized so that various components could be attached to them, allowing the minimum viable world partitioning definition to be reused as much as possible

in corpo/ghost the overlap was at 100% (visibility volume = sound volume = navigation area = room visit tracker volume = light zone)

I can imagine other cases but divergence is more of an exception

#gamedev #programming

the way those components are currently generalized is that any component that wants to attach to it, has to maintain its own mapping (e.g. volume->nav area) to optimize access

(the other direction is not an issue since the metadata component keeps a reference to the volume/portal)

ideally there's a better (and faster) way but it's unclear what that might be

in the case of nav areas, one may want to have more than one agent type, is that still one component or several?

#gamedev #programming

added the basic hole component to the [make portal] command

it's a bit janky in that I don't have full control over the emitted component, which is a broader thing of how generated objects work

also came up with a possible partial solution to the problem of objects having generated parts

a "rootable" (can be placed in the map directly) object could inherit from a component, thus actors/spawners/prefabs/gen.objects etc. could become special cases of a rootable component

#gamedev #programming

added door holes to my placeholder door prefab that was used in the spatial sound test map

also converted an old "styles" map (plain room styling test)

it's quite a bit of work to convert the rooms by hand and automated conversion probably doesn't pay off for the <20 remaining maps

improving rectangle editing should be universally useful though

thankfully it seems the holes are finally working as intended though - separate objects that I can move around and integrate with 1 keyboard shortcut

added a new projection mode to deal with the issue of putting doors and windows between rooms

projection is basically doing a raycast to figure out where to place an object

there is an invisible volume whose side faces are in the middle between rooms

so I figured that I could just raycast that volume instead of the visible meshes

and the raycasted point is snapped to the edges so that doors (with origin at the bottom) can be quickly and easily placed on the wall-floor edge

#gamedev #ui

added drag handle support to gen.objects, which should also help a bit with porting the data, as well as designing new content

currently only the rectangle supports these but the plan is to add them to some other things (e.g. polygon edges) as well where useful

it is a bit annoying however that editor upgrades are bottlenecked by having many different forms of scene data, which is why I'd like to consolidate them into fewer forms to require less supporting code

#gamedev #programming #ui

attempted to replicate one aspect of the 0-thick separator by writing a quick hack that connects tagged vertices of a polygon

currently the only way to visualize it is by using a light since they're assigned individual light spaces at the moment

also figured out that it ✨ just works ✨ (no need to filter out the outside loop) if you use directed edges for inner loop finding and only add both directions of the interior (cutting) edges, keeping the outer edge unidirectional

#gamedev #programming

for cases like this eventually I'd still want to have a mesh (like what the floor plan tool has) so that

1) interior edges can be more complex
2) individual interior faces can be filled/styled independently
3) stable identifiers can be assigned to those mesh faces (to propagate them to generated components)

not sure how to structure the runtime data yet however

there could be a fight between nav/sound areas and envmap volumes on how such a space should be split up

#enginedev

moving light portal data into the main portal component so that there isn't a second component at all

also planning to remove light space components entirely

they only have one parameter - an array of volume component refs - so I figured out that in all use cases the light spaces can be inferred from flood-filling the volumes through portals that explicitly allow such light transfers

this will avoid all the issues associated with linking components together

#gamedev #enginedev #programming

spent a lot of time replacing volume-adjacent components

already turned light space and nav area components into dummy skeletons that await data cleanup so that they can be removed

could need a volume component system if I don't want to go through upgrading the data multiple times (not sure yet)

upgraded the baked asset ref key (a name for looking up external files) but can't shake the feeling that I have a fundamental issue with trying to persistently name generated things

- got rid of light space/nav area components entirely (scene framework and actor templates seem to be handling nonexistent components in data well enough)

- created a "volume component", first impl = navigation component, second impl = room visit tracker

- only one remaining legacy component having its own copy of a world volume (light zone), not sure if I want it to be a volume component however - there's some benefit in overlaying detailed lightmaps where needed

#enginedev

also I've been noticing that volume components have some things in common with regular components, but also some crucial differences

thinking about whether it's possible to unify them into one type system

e.g. room visit tracker needs "begin play" and "runtime serialize" callbacks

do we just run all of them from the volume, turning volume into an omni-component that signals the capability to do everything, only to be able to pass the signal along? or can we reduce signal passing work somehow?

on a related note, thinking of separating some "begin/end play" work

e.g. editor needs interlinking of components but doesn't need any preparation work for game updates

it's kind of like there should be several distinct passes instead of trying to mix things together

sometimes "begin play" work even relies on having all the links (including from other components)

also, "end play" outside of unlinking doesn't seem to be much of a thing (there's some deallocs but dtor can do those)

#enginedev

in addition to all that, there's been a need to perform various stages of init in a specific order

e.g. updating light on/off state before updating emissive materials or NPC vision based on that state

normally game updates handle this, except for the first frame which sets the initial values after which changes may be tracked

I had a "map post init" callback but it only works for map actors

I should look into unifying these before-first-update callbacks

#enginedev

it's not even that complicated conceptually btw - having a callback where per-type lists of upcoming components can be iterated

it's just that when loading a map, there's currently a natural list of all map components (since these lists are stored per-map)

when spawning actors manually, there's no such list

arguably manual spawning isn't that useful though, so designing for it can be a waste of time

I would however like to have per-world component lists to simplify iterating them

#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

was thinking about spawners in the context of actors/rootables

there were 3 options for spawners:

1️⃣ spawners and actors coexist in separate arrays, spawning = creating an unassociated actor (current solution)
2️⃣ spawner as a property of actor, replacing most fields
3️⃣ spawner as parent/owner of the actor

I managed to entirely eliminate 2️⃣ by considering one of their highly beneficial features - custom root transforms

#gamedev #enginedev

a player spawner doesn't have the usual position+rotation+scale transform

it only has position+angle (around the up axis)

this makes it physically impossible to accidentally edit the spawner into a situation where a player would be spawned slanted, sideways or scaled

not even by editing the spawner data manually in the text editor

this eliminates a whole category of errors

in some cases, actors could have their own root transform, which would conflict with the spawner

#gamedev #enginedev

tbf it's not a hard limitation at the moment and you can just update the transform one-way (always spawner to actor) in the editor

however I also considered the possibility that actors could have their own root transforms instead of requiring a root transform component, at which point it becomes a lot more difficult to justify and consistently enforce having a 2nd (override) transform in the spawner, especially if it's a partial replacement (angle ➡️ rotation only)

#gamedev #enginedev

leaning towards putting existing actors inside other actors instead of broadening what's considered a rootable

maybe there's a way to combine all that but

actors have the beneficial properties that:
- all changes are minimal - component deletion, relinking (even hierarchial reordering) and other data edits don't require the reshuffling that hierarchialized unserialization would need
- actor is a logical unit (can render - or skip - just one) and I want to preserve this

#gamedev #enginedev

technically it's still possible to put an actor inside a different rootable but that has another issue with subactors - the hierarchy could change between runtime vs in editor (runtime doesn't need to retain prefabs/gen.objects/etc.)

and I really want the "if cur_actor is test_actor" exclusion test for raycasts to be really fast

with subactors that means having a one-type parent pointer (no inheritance/interfaces), which also means no sandwiching of random types in between

#gamedev #enginedev

I probably wouldn't want spawners inside other actors anyway

it makes no sense for e.g. players/NPCs (though arguably for my upcoming project spawners aren't useful for those anyway)

but prefabs/gen.objects could in theory fit inside other actors

another interesting thing to consider is how actors interact with visibility groups

e.g. a door could be a subactor of a door frame - that's like the main (only?) reason why visibility groups aren't merged with actors atm

#gamedev #enginedev

however, from a design perspective, it's helpful to design the door together with the door frame

and yet gen.objects can only produce a single actor (without subactors since those don't exist currently)

I guess there's also a case to be made for having one vis.group be inside each actor, but then also being able to create additional ones in some way

further still, one could imagine having vis.groups for each streamed partition too - could make outdoor culling cheaper

#gamedev #enginedev

and looking from the opposite direction, actors currently have no runtime use for most (static) objects

they're a way to manage a pile of components that are interlinked

once the components of a single actor are linked together, it only serves to provide a world pointer where it's otherwise unavailable

so either most actor objects could be thrown out at runtime, or they could be given a new use case of a default vis.group (but it will hurt the non-visual actors)

#gamedev #enginedev

as I've unsquished the cached actor def json, another problem has become clearer

a lot of this is effectively just fancy spam

I don't intend to tweak per-object decal visibility basically ever, this should just be handled automatically based on mesh flags

the visibility group is a "group" that consists of just one mesh

the "actor" is also one mesh, never to be drawn individually

the vast majority of cases should just be a single mesh with the basic data attached

#gamedev #enginedev

got rid of the decal receiver component

instead added a weak pointer to scene components so that decals can track owner visibility/transform/layer etc. as needed without worrying that the component might disappear at some point

been wanting to add weak pointer support for years but didn't have a decent enough reason to do so, until now

might need to increase the size of mesh flags now (uint8 -> uint16) since there's no room for a decal flag

#gamedev #enginedev

another observation of the current state of things is that a gen.object can generate many logically separate objects (e.g. rooms) inside just one actor

I don't intend to use it that way much but it raises the question whether it might help in some way to be able to give different procedurally generated logical objects their own actors, e.g. if they're turned into rigid bodies or other interactables that might need individual shadow maps / outlines / culling

#gamedev #enginedev

dealt with the spawner question by removing them from runtime data structures entirely

they are effectively just command objects so they'll only exist in editor's objects as data storage, and in the map unserialization function until they are run and then will be discarded immediately

in the end wasn't sure why I was even keeping them around in the first place, nothing seemed to require it

editor has its own object structures anyway, runtime data doesn't need them

#gamedev #enginedev

actor is now also a component

this took 40+ prep commits of opening things up (in this case - moving to string IDs) and aligning things (SFActor and SFComponent interfaces)

the idea is that the owner chain is now basically a one-type chain (all SFComponent) so unlimited ownership of things inside other things is now possible

the string IDs will allow all inner components to be uniquely identifiable

decided that I can reoptimize the IDs once I know what the data will be

#gamedev #enginedev

there's a couple loose ends still remaining:

- override unserialization assumes there are only up to 2 hardcoded sets of overrides (derived map & prefab) - may need to move to a different override applying method (repeated partial unserialization with actor merging logic probably)

- a bunch of proc gen code still uses the legacy 32-bit local ID generation - need to convert that to string generation at some point

neither issue is probably urgent (yet) though

#gamedev #enginedev

created the first prefab-as-component

the approach in terms of memory is to only keep a pointer to all the parameters (prefab path and overrides) directly

once the prefab has been spawned in play mode, the parameters will be deleted and thus in the end the component should only waste 4-8 bytes

the editor doesn't support editing subactors yet however, so I can't even link the prefab to a local transform component yet

#gamedev #enginedev

wondering if I can eventually phase out (edit-time resolved) actor templates since the vast majority of premade actor instantiations use (runtime-resolved) prefabs instead

they could have uses in theory but in practice they were never finished and didn't handle piece assembly work well

I'm hoping that prefabs could cover the fully hand-designed actor use case and building gen.objects could cover the "assembling env art from pieces and whatever" use case

#gamedev #enginedev