What about my question regarding the hot reloading of shader files?
Reloading of shaders at runtime sounds nice, definitely. With static (constant pool) strings this will of course not work. Most changes I had to do in the shaders also involved host/shader interface changes, especially when trying to find an optimal SSBO memory layout for BVH and kd trees. I had to play around with that a lot. So runtime reloading of shaders was simply not something I needed to look into in the past.
I got a āPower Chordā patch working as an option for the PTheremin yesterday.
Basically two sines, a perfect fifth apart [hmm, guitars generally use equal temperament instead? maybe, maybe not if they tune by using harmonics], with simple clipping, with a parameter available for real time interpolatione between the clip and the sine. It sounds decent, not ideal.
I tried a couple other nonlinear equations given by DspRelated and CCRMA, but neither were radical enough.
Not finished, though, as the aliasing is over the top. Am going to work on implementing a low-pass filter. My audio engineering friend points out I made need to over-sample to get enough filtering that doesnāt also compromise the basic tone.
Having seen that on Nvidia drivers glGetProgramBinary also outputs the ARB_vertex_program/ARB_fragment_program/NV_gpu_program4/5 assembly text, I begun learning the NV_gpu_program4 assembly language and reading about low-level shader optimizations (MAD instead of MUL and ADD, using negation on instructions operands instead of negating the result, etc.) to squeeze the most performance out of it.
EDIT: Hit exactly this GLSL compiler bug now: https://devtalk.nvidia.com/default/topic/952840/bug-report-linker-error-when-indexing-dvec-in-an-unbounded-loop/
Plus, whenever I use bounded loops the time the compiler takes to compile the GLSL code is directly proportional to the upper bound of the loopā¦ So if I have for (int i = 0; i < 1024; i++) ā¦ glCompileShader() actually does not end in foreseeable timeā¦ This makes me want assembly even moreā¦
Wrote a simple MagicaVoxel importer (so far only taking diffuse color into account) using this: https://github.com/ephtracy/voxel-model/blob/master/MagicaVoxel-file-format-vox.txt
I think I am going to add imports of user-generated content for various kinds of props (with smaller scale than the world cubes). This way, authoring can be done in that wonderful MagicaVoxel tool and placing can be done in-game. Here are some 4K videos and still images of āin-gameā rendering showing some of these MagicaVoxel models with ray-traced and irradiance-cached ambient occlusion:
aDsbeHF4C7w
ah5BPomcNj4
ReagZ75sG2E
This one looks really promising. Is it done via opengl? Is it for your engine or just for fun?
Just a bunch of OpenGL/GLSL demos/experiments, no engine, just for fun.
You fucking genius - looks really nice.
I learned a lot more about 3D rendering, and finally managed to add a third dimension to the map. I have low-poly lighting and adapted marching squares into 3D to give the map regions a better shape. The height map Iām using isnāt the best and Iām far from done with the map rendering, so the mountains donāt look like mountains yet. But they will!
Made an interpreter for my gameās mini-scripting language. The only thing this is going to be used for is determining where to route resources in tubes. For example, you can write
allow input if quantity of IRON > 2
or things like that. Itās basically the final form of all the different systems of determining where to route stuff in Factorio/modded Minecraft.
I like the upper one a bit better, but thereās not much of a difference tbh.
I would strongly suggest you to start working on something more important than fine tuning textures if you want to finish this within the next decade. Any gameplay yet? Do you have a main menu? A settings menu? How many units do you have implemented yet?
Iām telling you this because i also get caught up with fine-tuning very often and itās not very productive, itās not going to get you closer to your goal if you waste your time adjusting textures, trust me. You will probably make some huge changes later on that force you to swap out your fine tuned textures anyway.
I understand you very well. There is that moment which does not give me rest concerning these textures. I have both the main menu and a good part of the gameplay. But there is still a lot of work to be done.
Started working on adding people into my game. Once the road network is done properly they can walk along the paths instead of randomly.
5Nmd3jrGzDY
Started working on a rudimentary options menu which is basically just a visual representation of the underlying settings.json file of my game. GUI is really my weakspot, so I just started playing a little bit around and began to start implementing methods which allow the player to alter the settings file thourgh the options menu. Backend methods for loading, saving and adapting the settings file are already done. Really not enjoying GUI somehow. Options menu is far from dome but basically does what it needs to right now. Also planning to allow the player to change controls later in a second tab and maybe a restore default button.
Done some big performance improvements (~26% faster) for the k-d tree eye/primary ray tracing.
DQtGjmUx5-c
Red color component: Number of rope/neighbor pointer reads/dereferences
Green color component: Number of descends from parent to child nodes
Got some pathfinding setup. The LibGDX AI pathfinding stuff was kind of confusing to work out how to use, but it works very well and is really flexible.
Ba3GTH3Z41s
Implemented multi-level k-d tree traversal. That means, there are now two acceleration structures - top-level and bottom-level. The top-level tree is used to spatially subdivide the (transformed) axis-aligned bounding boxes of the few model instances. Each leaf in that tree then indexes into a bottom-level k-d tree for the model which holds the voxels.
The following video shows a debug render showing the actual k-d tree nodes color-coded based on the number of descends from parent to child nodes and the number of neighbor/adjacent node followings. Each leaf of the top-level tree holds a per-instance transformation matrix (video shows different per-instance position and rotation). Each bottom-level k-d tree references a color palette which each voxel indexes into with a 0ā¦255 byte value. So, this is compatible with MagicaVoxel color/material palettes. Next comes adding scaled-down models into the large voxel world. The video shows the chr_sword.vox model shipped with MagicaVoxel.
kZ-LvwoMZVs
Layout of the acceleration structure:
Little progress on my LibGDX / Box2D prototype.
- Space Bar to break joint
- Auto creates a new joint when car / trailer colide correctly
The car class which is inherited by all vehicles has a hitchable bool, being true allows the vehicle to pick up trailers / caravans etc.
Testing
Box2D Debug draw on
Experimenting with screen-space contact shadows
CS
https://puu.sh/BXbRM/83c584344a.png
CS + Shadow Maps
https://puu.sh/BXbRU/7805aad9ba.png
https://puu.sh/BXbSd/78922d3c09.png
https://puu.sh/BXbSk/c98582d414.png
https://puu.sh/BXbSD/505348945b.png
https://puu.sh/BXbSK/8c40298566.png
Contact shadows only.
https://puu.sh/BXc10/3ef0099e48.png
Still not finished but works.