Today’s episode is a short one, there’s been major refactoring under-the-hood but is too boring for a video so I’m making this one. In this episode I add support for multiple languages and translations using .json files. Just that so, Enjoy! (there’s no music atm, maybe add in future episodes).
In this episode of “Voxel Gamedev”: I do the spotlight implementation and change how lights are loaded into the shaders. The spotlights are based in the Learn OpenGL, light casters article, although the lightning code is a minor modification of the PBR directional light.
I’ve been working in a new GUI for Voxel, this is still based on NanoVG for drawing but uses a new layout and display system. This is based on the idea of a Window Manager/Display Server, all the GUI is composed of “windows”, each window is composed of components (Buttons, Images, Text, etc), making the creation of menus more easy and fast. Of course custom windows can be made by extending the NanoWindow object.
Internally the Window Manager/Display Server uses a compositing renderer, this puts together all the windows and creates the final image that is displayed. Each window contains a buffer where everything is rendered, this is shared between the client-side area and the window frame. The logic (drag, maximize, close, etc) and decorations are done by the window itself, not the window manager.
The Window Manager takes the image of the buffer, applies custom shaders and then adds it to the final buffer. This is done in a back-to-front rendering. Because of the dynamic nature of NanoVG the entire rendering can be replaced or modified on-runtime.
That’s it, the anniversary of Lux Vacuos and the second year of Voxel development.
Has been 2 years since the start of this project, many things have happened in this short time, lets start by a video of the progress.
We started the year with the release of version 0.0.9, the new 0.0.10 version is in progress and is the most time-consuming update ever; it contains a lot of changes and rewrites to the code, new rendering system, new world system, nearly all the code is new. Also we have a new member, HACKhalo2, he has been doing all the rewrite and creating new stuff.
We launched a new update system for Voxel and support for .deb packages in Debian-based distros. With this the “snapshots” update channel become live.
The UI got a massive rewrite and a new layout system, designed to mimic a Window Manager.
The Deferred Renderer got an upgrade in the same way by using a PBR pipeline and diffuse irradiance, this feature made it’s way into Infinity.
More stuff is coming this year so keep close.
This is the first year of Lux Vacuos.
The idea of Lux Vacuos is to keep all the projects in a single place and to share the most resource between them. The big addition is the new account system, designed to share the same account in different places. Other minor changes where the updated logos for all projects.
We have more plans for this year and want to make them reality. This is all for today so have a nice day!.
So recently I’ve been working on trying to smooth out some issues pertaining to how files are loaded and Chunks work, and I’ve been redoing a lot of backend things dealing with all of that. One of those changes was the inclusion of FutureChunks, which is (in theory) going to replace all the null chunk checks. Currently, they cause the main thread to stall due to them being hastily thrown together and not at all optimized, but I opened an issue on the Github for it and I plan to fix all the issues dealing with it soon.
Next major change was how Chunk loading/saving works. I originally just dumped the data into an output stream and force read it back, and it was bulky and slow and took up a lot of space on disk for not a lot of gain. I trimmed up a lot of the fat (aka removed the unused blocklight storage) and rewrote the loading/saving code to use the NBT file format. This also means that the old worlds will no longer work, but there is a noticeable speed increase loading and saving things, so that’s a plus. There is, however, a caveat with this. I had to extend the NBT format to deal with the Block array Voxel uses (Voxel stores some simple BlockMetadata, like rotation, with the Block ID in a long instead of an int), so all the current Minecraft NBT tools WILL NOT WORK with Voxel NBT files.
However, fear not. There is a new repo on the Lux Vacuos github, PyNBT. This is going to be modified to work with the Voxel NBT files from here on out. It runs on Python, and should be used as the basis for any implementations to use or to modify existing NBT utilities.
Heya, I’m HACKhalo2, the on again/off again secondary coder for Voxel (mostly due to real life issues sapping any energy I have). I’m going to be around doing things and stuff behind the scenes, helping Guerra as much as I can and trying to make Voxel the best it can be. Anyways, to the good bits of this Post.
Over the last couple of days, Guerra and I were banging our heads together trying to figure out why in the everloving hell Voxel was working flawlessly on his computer, but wasn’t working at all on mine. We both have different OS’s and hardware, which is great when developing a game. It also sucks a whole lot of golf balls through garden hoses when a bug like this pops up. And it was literally the dumbest bug there could be, that shouldn’t of broken everything, but it did.
In the F_Tessellator shader file, line 26, is a vec3. That vec3 used to be a vec4, and that vec4 broke the Tessellator for literally every system and every OS, except systems using nVidia GPUs. Why was nVidia spared from this horridly stupid bug, you might ask? There are two ‘theories’:
nVidia is lazy as the Duck Hunt Dog and just likes to laugh at you while you waste hours tracking down stupid bugs that should be throwing parser errors anyways.
There was also an GLSL extension Voxel was using that was nVidia specific (or at least only currently implemented on the GeForce drivers), ARB_shading_language_include, that loved to completely crash the JVM if used outside it’s little safe space. I wrote a co-preprocessor, the ISL (Includes Shading Language), to mimic and extend this behaviour for Voxel so all platforms can benefit from it. There are plans to extend the ISL farther to make Voxel’s GLSL shaders more dynamic, but that’s down the line. I’ll make a blog post about the ISL next week sometime.
First, the accounts server is in an undefined maintenance so logins through the launcher are disabled, we are looking for a new account system or making a custom one.
And on Voxel
Voxel has received a new World System with new subsystems, all written from the ground with Multi-Threading in mind. The first test were good, minor issues where detected and fixed but apart from that nothing new.
A bug that affects all OS X systems was detected which is in progress of begin fixed, this bug causes the Tessellator to not be rendered so the world is invisible, still there but can’t be seen. Fixed 😀
The new Molten API will work using scripts, mods are now be done using scripts. This will made mods easy to port from the Client to the Server, also the server can sync mods with the Client easily.
The rewrite is progressing very well, major parts of the World system are nearly completed and the rendering is starting to be re factored, the Windowing code has been re factored and now supports new features as multiple windows and better input. The rendering system will be detached in modules that implements a generic API, this allows to the engine to switch between OpenGL or Vulkan. This system allows to use multiple rendering APIs without changing code that no relies on the generic API.
Screen Space Lights
The engine now supports Screen Space Lights, this technique of rendering lights uses the data stored in the GBuffers and renders the lights in Screen Space, the advantages of using this are:
Better performance: instead of rendering in the pixels of the model they are renderer in a flat quad using the data available.
Nearly infinite lights: right now supports 256 independent point lights to be rendered in a single call.
The Voxelcode is being rewrittenbyHACKhalo2, from 70% to 80% is new code. Most features are retained but some had to be modifiedto accommodate the new code. Here is a list of what features were changed or replaced
ECS Components has been reworked.
The reason for this is to convert Universal in the core and on top write the client and server, this serves to keep most of the shared code in one place, speeding up the development process. The actual state of the code don’t allow to play, because of that there will be no updates until reaches a playable state.
If you what to check the process or contribute please go to Github.