#enginedev — Public Fediverse posts

the more I think about materials, the more it feels like they shouldn't be either a one-per-file thing (like unity/unreal) or an embedded object thing (like godot)

instead there should be a big database-like pile/table (or several - one per package) where it's cheap to do all sorts of operations on them without having to do a complex file system scan

tho I haven't figured out the whole thing yet

#gamedev #enginedev

implemented autogenerated materials but ran into an issue

the materials also store the aspect ratio used for generating UVs

when they were generated at asset processing time, this aspect ratio was transferred during the generation step

now the generated materials are being set up prior to the textures being loaded

sometimes material data is even loaded without the textures (though usually the textures are still loaded by something else)

#gamedev #enginedev

thinking about trying to use single-texture autogenerated materials in the engine

not that materials are some huge bottleneck to design but they still seem to get in the way quite a lot

and when several different variations are needed depending on the circumstances (at least opaque + alpha cutout + decal), pregenerating all of them no longer seems like a reasonable option

#gamedev #enginedev

created a terrain test

the result mostly seems fine, except for the weird overlap in the middle

turned out that the convex polygon check wasn't detecting 180 degree turns

#gamedev #enginedev

moved to triangle check (#verts <= 3) for determining the validity of the initially generated areas as the old angle check was failing

this required fixing issues with link generation so that it's much closer to 100% correct
- issue 1: forgot to check vertical overlap in parallel-intersect cases
- issue 2: midpoint checks too strict (this one might return later, should rethink it)

also fixed my flood fill code to find all connected areas, as it was generating duplicates

#gamedev #enginedev

added a 135 degree corner link merge
(first image = new/after)
it results in links being created that are rotated in 22.5 degree increments
it also apparently results in a more simple navmesh

#gamedev #enginedev

finally the spiral platform navmesh builds correctly

had a bug with some link intersections not being detected

also had a bug with the traversable link check not checking correctly whether the reached endpoint is on the same level (elevation) as the desired endpoint

#gamedev #enginedev

finally the spiral platform navmesh builds correctly

had a bug with some link intersections not being detected

also had a bug with the traversable link check not checking correctly whether the reached endpoint is on the same level (elevation) as the desired endpoint

#gamedev #enginedev

was using only a slope angle check for adjacency data, which was favoring diagonals
now also added a step height check
not entirely sure what's the best approach here but this works for now; can revisit later

#gamedev #enginedev

was using only a slope angle check for adjacency data, which was favoring diagonals
now also added a step height check
not entirely sure what's the best approach here but this works for now; can revisit later

#gamedev #enginedev

created a spiral platform test
it rasterizes and detects features seemingly correctly but the edge connecting step is currently broken here for some reason

#gamedev #enginedev

created a spiral platform test
it rasterizes and detects features seemingly correctly but the edge connecting step is currently broken here for some reason

#gamedev #enginedev

started testing overlapping platforms
untraversable links were being created

added a traversal to check if the link is walkable (https://www.cse.yorku.ca/~amana/research/grid.pdf but with known adjacent tile selection instead of stepX/stepY)

#gamedev #enginedev

started testing overlapping platforms
untraversable links were being created

added a traversal to check if the link is walkable (https://www.cse.yorku.ca/~amana/research/grid.pdf but with known adjacent tile selection instead of stepX/stepY)

#gamedev #enginedev

reenabled area finding code (link walking on either side) and joined areas across redundant links

#gamedev #enginedev

reenabled area finding code (link walking on either side) and joined areas across redundant links

#gamedev #enginedev

removed the garbage links
fixed a missing edge link

#gamedev #enginedev

removed the garbage links
fixed a missing edge link

#gamedev #enginedev

added a type to each link
adding more connections between points
the result is similar to triangulation

#gamedev #enginedev

added a type to each link
adding more connections between points
the result is similar to triangulation

#gamedev #enginedev

filtering of inner links
merging of straight link chains (ported some old code)

#gamedev #enginedev

filtering of inner links
merging of straight link chains (ported some old code)

#gamedev #enginedev

connecting found features

#gamedev #enginedev

connecting found features

#gamedev #enginedev

looking for elevation corners
(H/V only for now, could do diagonal later)

#gamedev #enginedev

looking for elevation corners
(H/V only for now, could do diagonal later)

#gamedev #enginedev

finding adjacent tiles and edge tiles

#gamedev #enginedev

finding adjacent tiles and edge tiles

#gamedev #enginedev

rebuilding nav mesh building code, this time with full 3D support

this is step 1 (raycast + space checks -> multilevel heightmap)

#gamedev #enginedev

rebuilding nav mesh building code, this time with full 3D support

this is step 1 (raycast + space checks -> multilevel heightmap)

#gamedev #enginedev

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

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

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