Feature: Add a plugin system

[ajh123]

Adding some kind of "plugin" system to the engine will allow other people to customise how the internals work. This will allow people to do different plugins without breaking how the engine works.

So someone could make a "tiny voxels" (#8), or physics, or anything else plugin that would be reusable by other projects. This would make it easier for other developers who want to do the same thing.

Some parts of the engine could be done as a plugin for example, lighting, different developers may want to have different kind of lighting, so by making a plugin, lighting could be changed.

[lucasdamianjohnson]

Hello and thank you for the requests.

I think in general this is a good idea but I am not sure what parts of the engine people would want to plug into and change.

The core engine itself is pretty malleable. I am developing several other libraries that are basic add-ons for the engine that expand the basic functionality. Such as infinite world generation and physics. But none of that is part of the core engine.

As for "tiny voxels" that is way harder than you would think. The dev that built Tear Down spent years developing a special system to achieve that which is different than the one I am building. I am willing to work on things that keep the engine in the realm of "Minecraft Like". Otherwise, the data structures and rendering techniques are so radically different that it's ridiculous to have one engine do all of that and to ask me to develop that. Especially if I have already built several games with the current engine.

Otherwise, if you have any ideas for plugins that are in that scope please let me know.

Here are some things the engine already does though:

• Allows expansion of individual voxel data. You can add tags to each voxel. This is how the physics library works. It adds an extra tag to the voxels for collider id.
• Allows expansion of chunk/column/region data. You can add extra attributes to the world data itself.
• Allows for complete custom meshing of voxels. Each chunk mesh is built in a thread. Each voxel can be rendered any way you want. It does not have to be a cube. Each mesh starts as just arrays of mesh data.
• Complete customization of shaders. All the shaders can be added to and changed before it is compiled into the final shader program.
• Sunlight, AO, and RGB light can be turned off. All materials could be replaced with the standard babylon.js materials.

Those features combined with the basic tool sets the engine provides you can build almost any plug-in you want. As long as it follows the paging/multi-level hash map data structure.

Either way, I am moving on to improving world generation, light propagation, and chunk meshing times by using compute shaders. Any work on the engine outside of that needs to be justified. As I am the only one with an actual stake in the engine at the moment and the only one with completed projects with it.

I would hope most people just look at the code for inspiration or fork the engine and start their own with it. It may be several years before I stop pushing breaking changes.

[lucasdamianjohnson]

As of now DVE is renderer independent. I have added at least for BabylonJS PBR rendering with more modern lighting and real time reflections for stuff like water with their SSR post process.
In the future I may add more plugins or abstract more of the engine to be able to do more things I am not sure yet.
For right now though I am only comfortable with voxels that involve actual meshes. Doing a full path/ray traced scene or another method would take me some time to develop on my own.
Also to support different types of voxel renderers it would need to change the underlying data structures use which is possible but may not work well in a multi threaded context using SharedArrayBuffers. There is always the option to use WASM but I have no idea how effective that would be. Either way that is years worth of work to explore and develop the various engine types. If people want to help me develop and implement the other types I am open to that.

[lucasdamianjohnson]

Okay first I added two new packages.

• @divinevoxel/quantum-renderer
  • For more cutting edge rendering techniques using web gpu
• @divinevoxel/magic
  • Provides a parser for vox files.
  • Processes them for gpu rendering as well.

And here is my first attempt at rendering a vox file using ray marching.

I just committed this code for this to the quantum-renderer today. Will probably still take some work to make it look better, be more effect, ad so on.

[ajh123]

Looks good, also could you provide an example repository so I can get started using DivineVoxel?

Edit: I've found https://github.com/Divine-Star-Software/DVEStarterApp thanks!

[lucasdamianjohnson]

The starter app is a little outdated simply because these last few big changes were made literally in a week or so.
I will have it updated by the end of the week.
The main repo here is a mono repo using npm workspaces containing all @divinevoxel packages and @divinestar packages (I should probably make that its own thing but DVE relies on most of those packages).
But as of now there are three React apps in the testing folder. One for "classic DVE" or @divinevoxel/foundation, one for React Three Fiber, and lastly the for Magic voxels where I am also testing the new renderer.