scallyw4g / bonsai Goto Github PK
View Code? Open in Web Editor NEWA voxel engine in a pot
License: Do What The F*ck You Want To Public License
A voxel engine in a pot
License: Do What The F*ck You Want To Public License
This is problematic for the UI sprites, which get pushed onto a global array in the order they're traversed, then indexed by static offests.
The directory traversals should probably return a tree structure of some sort the user can traverse themselves. The trees should be the same across platforms.
A few people have accidentally cloned without --recursive
. It would be pretty trivial to check if submodules are initialized and emit a specific error reminding them to initialize submodules
At the moment the radio buttons are a little weird.
They currently don't treat the enum value they're created from as primal. The proof of this is that if you open two windows that read/modify the same value, toggling a radio button in one does not update the other. This is undesired, and actually a bug. Since the underlying enum value is actually modified, the view that doesn't update is stale, and displaying the wrong value!!
Additionally, radio groups don't display the default value (typically zero), as selected, which smells pretty wrong.
Windows created with WindowLayoutFlag_StartupSize_InferHeight
and WindowLayoutFlag_StartupSize_InferWidth
can open a larger window than the screen can fit.
It would be nice if the code that did the window setup stdlib/src/ui/ui.cpp:2366
would be smarter about how large it would make a window. The screen dimensions are accessable through the renderer2d *Group
in that function as Group->ScreenDim
.
The fix should be as simple as clamping MaxClip to Basis-ScreenDim. For bonus points, there's a global called DefaultWIndowSideOffset
.. you could work that in such that there's a nice border between the max edge and the edge of the OS window.
Hi! I was recently recommended your project by GitHub and found it quite astonishing!
I wanted to try it for myself, as I noticed the presence of a default.nix
file. However it seems to be quite out of date (last updated about 5 years ago) and only provides a few dependencies. With my curiosity picked, I tried to assemble a very basic derivation that would build the core items of the engine (the game loader, and demo files). Currently, the setup is a bit hacky (for instance i have to cd
within the result dir), but here the derivation i made as a proof of concept:
{ stdenv, fetchFromGitHub, clang, which, libGL, xorg }:
stdenv.mkDerivation (finalAttrs: {
pname = "bonsai-engine";
version = "1.5.1";
src = fetchFromGitHub {
owner = "scallyw4g";
repo = "bonsai";
rev = "refs/tags/v${finalAttrs.version}";
hash = "sha256-hzKmrrYNwBVnkwN/AyoYJMI+2xYZGJ7pl5dYpFfitQA=";
fetchSubmodules = true;
};
nativeBuildInputs = [ clang which xorg.libX11 libGL ];
prePatch = ''
patchShebangs .
substituteInPlace external/bonsai_stdlib/src/initialize.cpp \
--replace-fail "./bin/lib_debug_system_loadable" "$out/lib/lib_debug_system_loadable"
'';
buildPhase = "./make.sh";
installPhase = ''
install -Dm 755 ./bin/game_loader $out/bin/game_loader
install -Dm 755 ./bin/lib_debug_system_loadable.so $out/lib/lib_debug_system_loadable.so
for lib in \
blank_project_loadable \
project_and_level_picker_loadable \
terrain_gen_loadable \
the_wanderer_loadable \
transparency_loadable \
turn_based_loadable \
voxel_synthesis_rule_baker_loadable; \
do
install -Dm 755 ./bin/game_libs/$lib.so $out/lib/$lib.so
done
cp -r shaders $out/shaders
cp -r assets $out/assets
cp -r settings.init $out/settings.init
cp texture_atlas_0.bmp $out/texture_atlas_0.bmp
cp texture_atlas_1.bmp $out/texture_atlas_1.bmp
touch $out/.root_marker
'';
})
Here is a screenshot of the generator, that has been built using from the prototype derivation:
It was wondering if you were interested to improve the nix support (which would take me quite some time to do properly).
I could setup a flake.nix
for this repository to provide things like the devShelll, package to build the demo declaratively and more. This could also be the opportunity to port the engine to nixpkgs repository.
Right now games have to provide an implementation for every thread queue job, most of which are identical across games, and have nothing to do with the game.
We should have a system that provides default implementations of the jobs, and something that lets us override the default .. probably a compile-time #define for each job which users set to 1 if they want to override .. or something like this.
Could probably metaprogram the defines such that we don't have the annoying manual step of going to add that every time we add a new thread job.
Nearly everything in Bonsai is allocated on an Arena, for which there is a pretty fancy (and bulletproof) implementation. That said, I've started to want a heap in a few places. #7
The task at hand is to improve the test harness for the Heap implementation such that we're relatively confidant it's not buggy (or at least doesn't have any glaringly obvious bugs), so we can start using it in a select few cases.
I've gotten a fair bit of interest in porting to OSX, mostly for developers, so I'm starting an issue to track progress. The branch with porting work is port/darwin
.
Shawnecy reported some sparkling black boxes on linux. We investigated for an hour or two but didn't get to the bottom of them. What we found out:
i am on Arch linux(endeavour os)
command used :
Archlinux
sudo pacman -S freeglut libx11
Common
git clone --recursive https://github.com/jjbandit/bonsai bonsai && cd bonsai
./scripts/make.sh
cmd logs :
[iamacat@iamacat-ms7c89 bonsai]$ git clone --recursive https://github.com/jjbandit/bonsai bonsai && cd bonsai
./scripts/make.sh
Clonage dans 'bonsai'...
remote: Enumerating objects: 24300, done.
remote: Counting objects: 100% (7399/7399), done.
remote: Compressing objects: 100% (1920/1920), done.
remote: Total 24300 (delta 5633), reused 7182 (delta 5422), pack-reused 16901
Réception d'objets: 100% (24300/24300), 69.60 Mio | 5.85 Mio/s, fait.
Résolution des deltas: 100% (18038/18038), fait.
Sous-module 'include/bonsai_debug' ([email protected]:scallyw4g/bonsai_debug) enregistré pour le chemin 'include/bonsai_debug'
Sous-module 'include/bonsai_stdlib' ([email protected]:scallyw4g/bonsai_stdlib) enregistré pour le chemin 'include/bonsai_stdlib'
Sous-module 'scripts' ([email protected]:scallyw4g/bonsai_build_scripts) enregistré pour le chemin 'scripts'
Clonage dans '/home/iamacat/bonsai/bonsai/include/bonsai_debug'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.
Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_debug' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/include/bonsai_debug' a échoué
Impossible de cloner 'include/bonsai_debug'. Réessai prévu
Clonage dans '/home/iamacat/bonsai/bonsai/include/bonsai_stdlib'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.
Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_stdlib' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/include/bonsai_stdlib' a échoué
Impossible de cloner 'include/bonsai_stdlib'. Réessai prévu
Clonage dans '/home/iamacat/bonsai/bonsai/scripts'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.
Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_build_scripts' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/scripts' a échoué
Impossible de cloner 'scripts'. Réessai prévu
Clonage dans '/home/iamacat/bonsai/bonsai/include/bonsai_debug'...
[email protected]: Permission denied (publickey).
fatal : Impossible de lire le dépôt distant.
Veuillez vérifier que vous avez les droits d'accès
et que le dépôt existe.
fatal : le clonage de '[email protected]:scallyw4g/bonsai_debug' dans le chemin de sous-module '/home/iamacat/bonsai/bonsai/include/bonsai_debug' a échoué
Impossible de cloner 'include/bonsai_debug' pour la seconde fois, abandon
bash: ./scripts/make.sh: Aucun fichier ou dossier de ce type
[iamacat@iamacat-ms7c89 bonsai]$
It would be very useful to have a streaming datastructure that allocates blocks of elements and, when the current block fills, allocates another block of elements. The blocks either get chained together in a linked list. For example:
<block0 (1024 elements)> -> <block1 (1024 elements)> -> <block2 (1024 elements)> -> null
A better method would be to keep another contiguous buffer that stores the block pointers, and gets re-allocated every time the array resizes. This either requires each "Blocked Array" structure to have it's own arena (not great), or to heap-allocate the contiguous buffers. Unfortunately, the heap implementation in Bonsai is pretty janky. #8
There's already an implementation for this in "include/bonsai_debug/debug.h". Look for debug_context_switch_event_buffer_stream
. It's put to use in "include/bonsai_debug/headers/win32_etw.cpp".
The task at hand is to copy-paste that implementation and make it generic (using a void*
at first), then metaprogram the implementation using poof
.
It would be nice if it were impossible to scroll up/down past the boundaries of the content in windows.
Bonus points for adding a little juice by being able to scroll a little way past the end (or top) and having the scroll lerp back to where the hard-stop would have been, like OSX does.
The code that does the scrolling is in stdlib/src/ui/ui.cpp
, UiFrameEnd
line 2955
This is how much code the Error macro produces:
More concerning is Assert, which is similar. This is contributing a sizable amount of bloat to the builds which we should avoid.
I'm actually not sure why the heck I made them macros in the first place .. should probably just replace them with some variadic functions and a single FormatString call
This should be a pretty straight-forward task for someone wanting to get their feet wet doing some graphics programming. I can explain how to do this, and maybe search out some good resources to follow along with during implementation.
Because the actual operation of buffering an AABB is quite cheap, we'll need to pack a lot of the operations together. Doing this amortizes the cost of the worker thread starting up the job, which is also cheap, but not free.
We probably want to go with a two-step approach:
There's an example of doing this already; grep for work_queue_entry_copy_buffer_set
Alternatively, we could implement instanced drawing, which is probably what we should actually do..
Right now all geometry pushed into the 3d immediate buffers are in camera space (called render space in the code), but that has some problems. Namely, the camera has to be updated before any of that geometry gets pushed. While this was a servicable approach for quite some time, there is a new constraint that the camera must be updated after the UI is drawn (to avoid a frame of camera jank when the UI captures input), which means there is now a frame of UI jank on the immediate geometry that the UI draws (things like the highlighted voxel, selection region, etc). The solution to this is using camera-independent coordinates in the immediate buffer, then transforming into camera space in the shader, like a real program.
It would be nice if this loaded a simple model and drew some "hello world" text to the screen .. just so the user knows it's working. Right now it's almost a totally blank screen, which (to me at least) smells like it's broken.
It would be real nice if shaders supported hot reloading, such that you could edit the shader and the changes appeared.
There is code that creates shaders already. The majority of the work here is to write code that polls the text files for changes and reloads when it detects a .. new timestamp?
Right now the debug lib menu comes up on F1 click. I also want a set of "engine debug" options to show up under it. The first element in the list should be "Watched Values". We should also move the "Picked Chunks" tab into the engine from the debug lib.
The "Watched Values" tab should show up where the '0' is in this screenshot, below PickedChunks.
There's a GameUiRenderer
struct setup on the engine_resources
that can be used in the same way that the one in the debug lib is.
There's a
I've tested with a few different MESA versions and they're unilaterally varying degrees of broken. Some almost work properly, some get a black screen, I've even had reports of system hangs and instability.
I'm not sure if the cause is driver bugs, application bugs, or ..
When a window opens that has no content the window's not sized correctly.
A better look would be something like this
The code that handles the minimum size for a window is in stdlib/src/ui/ui.cpp
, look for PushWindowStart
. At the time of this writing the code is specifically in a block that triggers when the resize handle is pressed on line 1289.
There's a subtle problem sometimes causing holes in portions of the mesh when the noise values are manipulated conditioned on a mask computed from the normal of the surface.
What a mouthful.
The issue is that the noise values are computed on a grid the same size as the normals, and the resulting voxels. This is a problem because the code that computes faces is required to operate on a grid that is 1 larger than the resultant mesh, and the code that computes normals is required to operate on a grid of noise values that is 1 larger than the resulting normals grid. Said another way, each stage in the pipe requires downsampling the grid size by one.
The problem occurs when indexing into these grids on the chunk edges. The grids are larger than the result grid such that we can deterministically generate the voxels on the 'border' of each neighbouring chunk. If the normals & meshing grids are inflated more than one cell they index into the wrong cells when doing the borders. Most of the time this is fine, because the noise values only change a small amount across a single voxel, but occasionally it causes a problem when one chunk thinks a voxel is filled, and another chunk thinks it's not, causing a hole.
The solution to this problem is pretty simple conceptually; use the meshing grid size as primal, and add one for the noise value grid.
This turns out to be kind of annoying in practice because that code is somewhat scattered across the various generators, so we might have to make this a bit more systemic. I'm going to leave it for now, but wanted to write this down so I don't forget exactly what the problem is.
If you open the textures window and drag it such that it clips against the game window (os window) bounds, the textures warp in a weird way like. IIRC this happens because the UVs are wrong.
DONE
This should be relatively painless, although it'll require also moving bonsai_worker_thread_callback
into stdlib (and probably renaming it to something else).
The debug windows can currently clip down to a size that produces some visual artifacts. We should fix the logic that clamps the min value to a more sensible value
It's not obvious what the controls for the game are, so we should add a modal that defaults to displayed, and lets the user know what they can do.
I took a crack at a fancy LoD system a while back (which kinda-worked), but it's pretty straight-forward to implement the same meshing algorithm(s) on a coarser LoD of voxels, which would buy us a lot for a little work.
Right now there's a bug; the grid follows the camera around. I think we need to pass the camera offset relative to the center of the world into the shader and subtract that from whatever we're treating as the origin for the grid.
The git hooks system is hilariously half-baked so we have to add some gymnastics to the build to actually get the repo hooks onto other peoples' machines
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.