#enginedev — Public Fediverse posts

created a first test animation

need to figure out a much better test since this is very axis-aligned and too fast overall

the fancy interpolation ends up being unused for rotation, basic slerps ended up being OK at this speed

also probably could use a time scaling parameter

#gamedev #enginedev #animation

working on the animation editor, only made vec3 curves minimally usable so far

I wish it was easier to line up the velocities of adjacent points when the velocities are small

#gamedev #enginedev

- created the [animated mesh set] component
- fixed the data transfer bugs
- added an [initial pose] feature to the [animated mesh set] component

...one thing led to another...

- created the leaning toilet 🚽

#gamedev #enginedev #art

- created the [animated mesh set] component
- fixed the data transfer bugs
- added an [initial pose] feature to the [animated mesh set] component

...one thing led to another...

- created the leaning toilet 🚽

#gamedev #enginedev #art

Недавно достиг первого результата в SDL GPU: потестировал меши, трансформации, постпроцессинг свечения - простой, но зрелищный эффект, текстуры и прочее элементарное.

Вышел регулятор Уатта из эпохи паровых машин. Механизм ходит не слишком ровно, но я доволен. Хотя бы что-то движок уже показывает.

Есть некоторые проблемы производительности при смешивании старого SDL_Renderer и нового API.

https://www.youtube.com/shorts/wX5A2W_oJI4

#dlang #sdl #enginedev #graphicsprogramming #программирование #ит

Попытка оптимизировать техноблог, обходясь лишь видеоплощадками - с треском провалилась. Трудоёмкость экспериментов создаёт перерывы в видео, нужно место для девлогов. Приземляемся в Mastodon обратно.

Фиксируем результат весны 2026. Лучше развился инфоотсек: почти выстроен прототип GUI-тулкита на #SDL (SDL_Renderer + Cairo) и #Dlang. Но SDL GPU в SDL3 заставляет погружаться в 3D. Весной вспоминал OpenGL, аналогией портируя в SDL GPU и HLSL.

#enginedev #graphicsprogramming #программирование #ит

(re-)added the ability to edit hit volumes

the previous skeleton metadata editor was capable of this so it's largely a matter of copying the code

but now there's a possibility to add more than one shape per bone, which could be useful in cases where one shape isn't quite enough

#gamedev #enginedev

(re-)added the ability to edit hit volumes

the previous skeleton metadata editor was capable of this so it's largely a matter of copying the code

but now there's a possibility to add more than one shape per bone, which could be useful in cases where one shape isn't quite enough

#gamedev #enginedev

the whiteboard case also showed in what ways calculated, non-destructively edited weights are superior to painting - subdividing the model wouldn't result in needing to repaint the subdivided bits

another interesting side effect of in-engine skinning is that I could combine any mesh generator with skinning at some point, making something animated entirely inside the engine

not that the existing capabilities help with character design but it's something to consider

#gamedev #enginedev

the whiteboard case also showed in what ways calculated, non-destructively edited weights are superior to painting - subdividing the model wouldn't result in needing to repaint the subdivided bits

another interesting side effect of in-engine skinning is that I could combine any mesh generator with skinning at some point, making something animated entirely inside the engine

not that the existing capabilities help with character design but it's something to consider

#gamedev #enginedev

got as far as getting a skeleton editor to a point where it's minimally usable, and starting work on a mesh skin set editor

figuring out the data structures and data flows took a long time but I think that might be largely done at this point

while testing the mesh skin set editor, noticed that the model I was initially testing it with (a movable whiteboard) wasn't sufficiently subdivided to make it bend, so I had to change it

#gamedev #enginedev

got as far as getting a skeleton editor to a point where it's minimally usable, and starting work on a mesh skin set editor

figuring out the data structures and data flows took a long time but I think that might be largely done at this point

while testing the mesh skin set editor, noticed that the model I was initially testing it with (a movable whiteboard) wasn't sufficiently subdivided to make it bend, so I had to change it

#gamedev #enginedev

https://mastodon.gamedev.place/@archo/116393663626833304

as I'm designing destructible obj ➡️ fragmentation fx data passing, two important things emerge:

1️⃣ some volume primitives may be needed to fill the volumes with particles instead of placing them along a mesh surface (which doesn't make sense with solid objects)
2️⃣ a separating plane may be needed to help construct a simplified collision environment by separating the two sides where broken glass would fall

regular particle systems would suck at both

#gamedev #enginedev

but the other issue with particle systems is that they're like 100x more code than doing the minimal thing directly

the main difference being UI (IIRC roughly half of UE's Niagara was editor code)

but also when you go from one struct/one array to generic attribute arrays and configurable steps, the overall complexity tends to skyrocket

suddenly a "generate random velocity" half-line of code becomes a module where you configure which attribute even is velocity

#gamedev #enginedev

out of these, decals and rain have nothing to do with typical particles

decals are mesh slices or projections

rain is a combo of fog, animated cards wrapped around the camera, splashes on surfaces (where the sky is visible) and maybe screen-space droplets if you look up

but the rest also have complications:
(see above for fragmentation)
- dual-slice needs anim sync between slices
- smoke ideally needs some area adaptiveness
- sparks need to simulate camera motion blur

#gamedev #enginedev

returning to my own game projects for a bit, I expect to avoid the need for GPU particles for most effects as well

the effect types I'll probably have:
- damage & splatter decals (already done)
- fragmentation (doing now)
- dual-slice animation (prototyped a year ago)
- smoke (both focused and diffuse/fog-like)
- [maybe] rain
- [maybe] sparks

all of them are fundamentally different systems (with some overlap for focused smoke/sparks)

#gamedev #enginedev

https://mamoniem.com/behind-the-pretty-frames-pragmata/ here's one of the most recent examples (the full game isn't even out yet)

IIRC there were just two GPU particle systems, and they were used to drive 10s of particles (maybe up to low 100s, haven't played it myself)

did that genuinely require a GPU particle system at all?

and out of the effects described in the post, all the remaining effects were just layered designed sprites

IIRC in Doom (2016+) blood spatter was individual spritesheets as well

#gamedev #enginedev

another funny thing that I had also noticed most AA-AAA effects are still pre-rendered (or pre-designed) sprites/spritesheets

because effect quality generally doesn't increase with pure particle count

so most effects are so basic that they'd have no issues running on the CPU

there's basically one exception which is sparks - since they are small and require world collision

but upending your entire design for just one exception doesn't make a ton of sense to me

#gamedev #enginedev

that said, there is a role for being able to operate with easy primitives and quickly iteratively tweak things with live preview

I can't say I have *the* answer for how things should be developed

and this definitely wouldn't work for beginners (basic inflexible systems still help there)

but stuff like UE Niagara to me isn't the answer either

apart from the prefab behaviors (rendering, physics) that it offers, it's no less complex than writing the code, arguably even more

#gamedev #enginedev

here's some particle generation code so far

a component of velocity is a sinc(-ish) wave based on particle's distance from last impact

particle size depends on prior recorded impacts - with the assumption being that the previously damaged areas would result in smaller particles

how does one even begin to make a system for any of that? custom per-instance data passing protocols? how do we encode an array?

particle systems are as much of an insanity as any precog design

#gamedev #enginedev

since I'm probably only going to need like 5 different types of effects, this is a mechanically hardcoded effect (details can still be configured though)

was considering making a particle system but it's unlikely to add value for me

idk if you've noticed but particle systems kind of suck at mechanical customizability but also require a lot of work (with the amount of work being roughly proportional to modularity; UE spends something like ~0.5MLOC on particle system alone)

#gamedev #enginedev

On #helios’ way toward an #ECS-driven infrastructure, I’m rewriting resource management, abstracting it into a TypedHandleWorld - a handle-oriented, domain-specific registry that simplifies access to resources otherwise scattered across the system(s).

#gameengine #enginedev #indiedev #indiegames

on top of all that, it's probably also possible to resolve-and-resave the prefab format anyway so even if I do need edit-time resolving, having two different data formats for basically the same thing isn't especially efficient

actor templates had the special ability to do subtemplates with remaps of actor-unique component IDs, which allowed them to combine many things into one actor

now it might be possible to allow doing the same thing with prefab components

#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

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

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

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

helios is currently rendering ~10.000 objects in the #gameloop at stable 60 fps (w/o inst.). Lets crank those rookie numbers up and make sure the render resources are managed more cache friendly, render commands batched and queues optimally sorted.

#gamedev #helios #enginedev #indiegames #indiedev

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 random thought on data inheritance

it's trivial to change the entire meaning of the data

more "the contents of a cup" than "ship of theseus"

still technically inherited but really shouldn't be anymore (or should inherit from another base object)

probably not worth worrying about too much (as long as things look OK), just thinking how to discourage it to avoid unnecessary work

maybe could hide some properties (e.g. most textures) by default or something

#gamedev #enginedev #programming

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

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