#enginedev — Public Fediverse posts

so this is where the "spline" part of the "spline mesh" finally appears

every edge can be turned into a cubic spline

there's still a bunch of things that don't work yet (e.g. tangent visualization and editing, spline-aware edge picking and face previews)

but at least the intermediate positions are being generated, the spline edges are rendered correctly and they also appear in the exported polygons

#gamedev #enginedev #graphics

making some progress with rig processing

- added conditional tagging
for now there's only face count for vertices/edges and part count for faces, so it's possible to find outlines and inner vertices/edges

- added conversion to polygons/polylines
from there it's possible to make fill/edge meshes etc. from that

could in theory add materials and other metadata to the rig directly but idk, will try to make upgrades as I proceed and see what's needed/helpful

#gamedev #enginedev #graphics

created some extrusion code

the basic mesh transform (outline finding + vertex/edge duplication + face-vertex/face-edge redistribution + bridge faces) turned out much easier than expected

but making the full thing would probably require upgrading the transform gizmo

just need to do missing editing features (element tags, grid, selection modes) and element extraction and it'll be ~enough for editing procedural modeling rigs

#gamedev #enginedev #graphics

finally developed enough features that I could finish skinning the test character at a base level (without finger or face bones)

also ended up not needing undo so far 🤷

the weird thing about developing a reasonably efficient tool is that suddenly the work ends up taking like a few hours total and you wonder if spending several weeks on the tool was worth the effort

hopefully I'll be able to cash in at scale (after skinning a bunch of characters, together with iterations)

#gamedev #enginedev

noticed a really weird issue with dual quaternion skinning

at the end of the day, all skinning is a nasty approximation

(though in this case linear blending looks a lot less weird, even if still unnaturally stretchy)

I wish there was a better option that didn't involve lots of work (cloth simulation + overbuilding the character for it)

#gamedev #enginedev #graphics

the slowest part in all this seems to be the process of figuring out what is it exactly that I want to make:

- dogfooding
- noticing problems
- coming up with several solutions
- coming up with their costs and effectiveness without actually making them
- picking the optimal combination

there's a lot of fancy 3D view selection/editing things that I'd like to make but they seem to cost far more and thus I could only justify them if I have seen somewhere that they worked best

#gamedev #enginedev

did a lot of tiny things but also

1️⃣ removed *shared* bone weight shapes (ones used for all skins)

reason: it would be more difficult to fit most of them to 2+ skins than I initially thought

2️⃣ made weight shape transforms absolute (used to be bone-relative)

reason: allows moving the bone pivot without moving the shapes

reason for both: now all skins are self-sufficient and could be moved into separate files to prevent shared changes from rebuilding all associated files

#gamedev #enginedev

back to working on the mesh skin set editor - a second pass to support more cases

- made the test view functional (as in, finally allow pose changing)
- added the missing weight shape visualizations

yet to figure out how to design the weight shapes for optimal weights (spine seems to be especially complicated... but I have an idea)

self-intersecting meshes could be a challenge but flood fill might solve it (the test model has teeth, can test later)

#gamedev #enginedev

been working on a "spline mesh" for some time (a tiny bit at a time) and finally have something to show

the data structure has been seemingly figured out now and there are a few basic actions available

it's not yet enough to design anything but could be eventually

the goal is to build control rigs for things like this and more: https://mastodon.gamedev.place/@archo/115384498813589175

eventually it should be possible to turn edges into splines and extract faces as polygons

#gamedev #enginedev #graphics

starting a new "building generator" thread (previously https://mastodon.gamedev.place/@archo/116522023095047486) since the last one was getting a bit long

here's a new attempted approach for producing inner faces for stair cutouts

- emit requantized shape
- projected-intersect it against platform shape
- generate edge mesh by pushing vertices upwards up to top plane
- filter out entrance face
- added edge blend layer

good stair sides are still annoying to make in this system tho

#gamedev #enginedev #graphics

added a first set of mutexes for loading textures

there's a global one for the hash table/file texture list, and one mutex for each texture (for loading/unloading)

the whole thing is a bit messy currently (in part because there are several different types of textures) but a stress test seems to work

and it's a bit annoying to spend memory per texture for what's basically failsafe code

but it's the simplest approach I could come up with for now

#gamedev #enginedev

another thing to fix eventually is force-pausing the game while BeginPlay is waiting for the data to be loaded

the idea is to emit a special signal if a partition expects to be activated but isn't yet loaded

and then use this signal to pause most update code and render some overlay indicating to the player that more time is needed before the game can resume

should reduce situations where scripting could fail due to missing parts of the world

#gamedev #enginedev

thought about async loading for a while and landed on this extremely basic approach

since I'll only be loading one thing at a time, the idea is to pick the next thing to do and then apply it, depending on whether it can be streamed or not

anything under Load/Unload will eventually receive the appropriate mutexes

isAsyncBusy should be an event instead of an atomic bool but it should not fail on windows (unlike e.g. android where thread scheduling is far less forgiving)

#gamedev #enginedev

but will I need a separate disk thread? not if most work happens on just one thread (e.g. the map loading thread)

which is true as long as it won't be necessary to load textures in parallel, separately from the rest (if they're not too large and not too many per partition)

hoping to avoid a good chunk of the complexity by steering clear of the cutting edge and not overdoing it with the granularity of partitioning

#gamedev #enginedev

I think it's no secret that most of the issues are likely to appear in the process of making the streaming system work with real content

expecting a need for a loading thread (with all the necessary sync), and some way to attribute renderables to partitions (possibly with opt-out if I'll want to carry some stuff out) so that I can fade things in and out at the very least

but e.g. component addressing has been designed with streaming in mind already tho

#gamedev #enginedev

worked on the runtime side of the partition system

basic support for loading and unloading works now (no multithreading of any kind yet, no hierarchy either)

there are a few basic shapes (sphere, box, cylinder*, capsule*) for measuring the distance between the partition and the reference point (= camera position for now)

(* - missing editor preview)

so far the work has been much simpler than anticipated, though in part due to prior design and extensive refactoring

#gamedev #enginedev

One of the things that fascinated me about #Doom was its aggressive visibility determination, avoiding work for geometry that never reached the screen.
For #helios I opted for a non-hierarchical AABB culling #algorithm (Miettinen), currently testing against every scene member and switching MaterialHandles to highlight culled and visible objects. On to #BSP now! #indiedev #enginedev #indiegames

been working on the editor side of the partition system

moved map items out of layers, into "indexed chunks"

the chunks are basically a list of map items that all have common filter parameters (initially layer, now also partition and whether it's inside the low or high LOD section of the partition)

starting small for now - currently partitions exist, can be edited, and items can be assigned to them but otherwise they don't affect much in practice yet

#gamedev #enginedev

test animation 4

this is the animation I wanted to create initially

the transition points are visibly broken at the moment, but also necessary for this animation to work

I'm also rethinking the whole concept of transition points, as it doesn't make much sense from an editing standpoint for them to always be synchronized across the axes, possibly even if they contribute to the implicit acceleration curve

#gamedev #enginedev #3d #animation

created a new test animation consisting of 3 keyframes that create a circular motion with decreasing speed

it appears that the new rotation curve editor is finally working well enough to stick with it

#gamedev #enginedev #animation

a very early preview of how the rotation editor might look (while nothing is hovered)

worried about vertical autosizing of the curves and keeping everything in the frame while keeping it still for editing (might need some state to freeze things while they're being edited)

the discontinuous curves are somewhat trippy but also purely visual since the curves as currently defined can't support discontinuities (rapid changes need two points next to each other)

#enginedev

so as expected, the curve view interface isn't really working for editing the rotation curves

and as expected, the issue is the adding of differences

moving a single point doesn't mean what one would expect

worse still, moving has this weird duality - the results are different depending on which segment of the curve is considered to be edited

so it's impossible to preserve the invariant during/after that operation

now contemplating making a fully custom insanity of a UI

#enginedev

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

(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

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

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

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

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

in order to avoid spending too much time on plan A unnecessarily, opted to finish plan B first

nearly finished portal screen space grid lookup data generation code (cpu-side, ~150loc, similar to what's needed for tiled shading, still needs near z clipping and testing)

I also still need the shader code, gpu resource mgmt/upload, renderer integration and light space portal integration

would be really nice if I could make it work over the weekend

#gamedev #enginedev #graphics

the best I can currently come up with for portals:

- screen space grid lookup
- for portal in grid cell:
- end loop if current volume doesn't match portal entry volume
- intersect the portal plane
- go to the next portal if pixel is outside portal quad (and optionally texture mask)
- change the current volume to portal exit volume and skip to the first portal for that volume

the portal shape has to be O(1) for this to work

#gamedev #enginedev #gpu

... but also because it looks like volume lookup could be a lot more GPU-friendly

the beauty of hash grids and BSP are that the loops are shallow:

- loop 1: for each cell under the same hash
(1:1 mapping from coord to cell so no nesting needed)

- loop 2: while node is a branch, node = point in front ? node.front : node.back
(also 1:1 coord to leaf)

no inner loops/branches means that the loops should be highly parallel even when the data slightly differs

#gamedev #enginedev #gpu

the reason why I'm avoiding it at the moment is that it would prevent the use of a corpo/ghost-style camera that isn't limited by the world

not only that, it would also prevent the use of top-down/sidescroller cameras, however in those cases arguably 2D or 2.5D volumes can be used, which tend to be much easier to look up quickly anyway

so it is admittedly a very limited use case - one can definitely make and sell great games without it

#gamedev #enginedev

Hitman (2016+ series engine) is a notable exception but they seem to sidestep the need for perfectly accelerated volume lookup by relying on screen space portals (rectangles) to find where one volume ends and another one begins

if I fail to accelerate volume lookup, that's my backup idea

it has the downside that the camera can't escape interior geometry - if it does, outdoor lighting would need to be assumed for all pixels that don't pass through a portal

#gamedev #enginedev #graphics

accelerating the lookup of densely packed volumes is a complicated problem overall

it's probably why:
- BSP-based engines have been largely phased out
- open world games tend to strictly separate outdoor and indoor sections
- of those that don't separate, most end up finding a way to enclose indoor sections into very few OBBs via design, either by making them thin and staying away from walls to allow oversizing the OBBs (MGS 5), or by making the exterior box-shaped (GR:W)

#gamedev #enginedev

the use case is streaming of partitioned world sections

thinking that in theory streaming should be set up so that it can take a while and happen over several frames

so if volumes get introduced to the world cell by cell, it shouldn't be an issue in theory

also, usually the volumes shouldn't overlap globally so sections could come with most cells being precalculated and only the sides would require live recalculation

#gamedev #enginedev

wondering how crazy it would be to have a hash grid of small BSP trees for my volumes

BSP tree building is full of O(n^2) code

hopefully most of the time n would be very small (1 on the edge, 2-3 inside a huge volume)

one corner is n=24 (3 corner faces x 8 solids), may need to precalculate parallel planes, getting most corners down to n=3/8 hybrid (3 planes but they reappear in subtrees)

may also need to subdivide specific grid cells that contain too many corners

#gamedev #enginedev #math

finally added support for convex decomposition

a very basic divide-and-conquer algo atm: find worst concavity, find nearest vertex that fully solves the concavity, subdivide into 2 polygons and process them recursively

(note that I'm not yet checking if the vertex is visible or have fallbacks for partial solving, will need to fix that for more complex cases)

this can be used to convert from the old data and also for making rooms from concave polygons in the future

#gamedev #enginedev #math

thinking that it might also be useful to precalculate the face polygons

the idea is that there could be a hash grid where each cell is a binary tree

inserting into the tree requires that the faces are finite, to determine whether they intersect with the planes in the tree

it might not require that the faces are polygons however (an unordered pile of vertices might be enough to intersect a plane)

polygons might help with other things tho (ray tests/volume paths)

#gamedev #enginedev #math

turns out it's quite painful to move to a different volume representation

the original one was fairly well chosen for the game in that it allowed doing 2D-based measurements easily

unfortunately I do need a new one to build new 3D spaces

so I need new algorithms for
- roughly measuring the walkable (floor) area
- editor volume side raycast (from inside and outside) with snapping to edges

I also need a new shader encoding for the data (first a temporary one, to be improved later)

#enginedev

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

𝗧𝗢𝗗𝗔𝗬 there will be a live stream about the Trial lisp game engine, from 𝟭𝟴:𝟬𝟬-𝟮𝟮:𝟬𝟬 𝗖𝗘𝗧. Stop on by and you can ask questions, get me to show off stuff, discuss games, and hang out!

More information and a countdown to the event is here:
https://events.shirakumo.org/12

#opensource #lisp #gamedev #indiedev #enginedev

Hey hey, just a quick reminder that 𝘁𝗵𝗶𝘀 𝗦𝗮𝘁𝘂𝗿𝗱𝗮𝘆 𝟮𝟭𝘀𝘁 𝗼𝗳 𝗙𝗲𝗯𝗿𝘂𝗮𝗿𝘆 𝟮𝟬𝟮𝟲 there will be a live stream about the Trial #lisp game engine, from 𝟭𝟴:𝟬𝟬-𝟮𝟮:𝟬𝟬 𝗖𝗘𝗧. Stop on by and you can ask questions, get me to show off stuff, discuss games, and hang out!

More information and a countdown to the event is here:
https://events.shirakumo.org/12

#gamedev #indiedev #opensource #enginedev

did a quick refactor of engine headers

had this combined "Engine.h" header containing display mode config, scene render config, scene camera/screen/time info, input info, app info/events + it included a translation header

various changes would recompile a bunch of unrelated files

moved to using a separate header file for each of the mentioned categories - far less likely to have excessive recompilation in the future

#programming #cpp #enginedev

Biblically accurate pictures of me trying to master as fast as possible the internal source code of #godot engine made of ~2,703,000 lines of code.

#gamedev #enginedev #dev #godotengine #shitpost #meme