*Uploaded a tiny demo with my test enviroment, think I missed some of the extra files in it because its almost 200 mb:
Heyo,
I really don’t like to post in the marketplace thread as it bumps an unfinished project when there are new topics in there so I am branching out this thread for progress information instead (this is why I haven’t been posting progress information lately).
I have been waiting on 4.11 to test out something I want to try out with packets and sending volume data to client before releasing a test build. In the meantime I have been implementing some of my “wishlist” items.
1st new thing:
I moved the uv mapping out of the material editor and into a custom VertexFactory hlsl shader. This way there isn’t spaghetti nodes in the material editor to make a material for a voxel volume and the end result is actually significantly more performant. I figured out a good way to quickly calculate axis aligned UV mapping for the voxels in tangent space so the texturing and normal mapping is as easy as just plugging them into the material like with any other material.
I decided on a whim to make a StaticMesh to VoxelActor conversion function, it creates a voxel volume out of the vertices of a Static Mesh and assigns the color to the voxels based on their intersection with the tri and its UV layout. It is a two day old attempt so I have some edge cases to handle yet (voxels on the edge of a tri have some color bleeding) but the end result looks pretty good already. It accounts for the mesh scaling and the result depends on the voxel size.
Voxel size doesn’t matter, it is just the scale that they are, total Voxel volume is a potential problem due to memory limitations with uncompressed data, iteration time for checking for exposed voxels and the fact that it generates more vertices then. You get too large and paging in data instead of storing it all in memory is preferred.
As far as per frame performance, I am only sending one vert per corner to the GPU, this saves on total vertices (faster updating when sending altered chunks to the GPU) and loses when it comes to FPS a little as the normals / uvs are calculated in the pixel shader. It would be a far better if the engine wasn’t deferred rendering but its a minor hit at the moment.
The first Triceratops in that one image is one voxel per U unit, I really wouldn’t suggest ever using that scale more for memory reasons across many objects than for rendering performance (although the tri count is huge with cubic representations compared to standard). Really that scale of voxel should be reserved for raymarching renderers built specifically for voxels if anything.
It really all depends on style and what you are trying to get out of it though.
I have to ask, do you plan to make smooth surfaces out of the voxels (so that a smooth terrain can be made, for example), or only going for the cubic look?
Honestly, the code for marching cubes is in the base framework but I hate the result of MC and something like a CSG terrain editor really should be its own thing. I dropped attempting to support it for now and if I ever pick it back up it will be as its own project.
That being said Voxelfarm is still coming as far as I know and they support Dual Contour which is a far better solution in the first place.
Not entirely sure that either of those are useful without the rest of the package. I don’t import as mesh or convert the models to mesh, I import/convert to a voxel volume. I mean I could make a tool that converts them into a blocky mesh if requested. The thought hadn’t crossed my mind that it would be a useful tool? Keep in mind that auto generation of a representative model could suffer a little (as you see the eyes are lost in the lower resolution generated voxel mesh there) so I assume you would be looking for converting a static mesh to a MagicaVoxel importable file and then being able to reimport to the engine as a static mesh after editing or something?
Kind of curious, would you just be making “pixel like” content with it then but without real time editing?
I was inspired by the Replicators from Stargate and want to make robots that break apart and then assemble. I’m using Magica Voxel to make them but right now I’m just importing the static mesh. All I need is the vertices and then I can use my own static mesh instances for the blocks (different shapes even) and assemble them in the actor construction. They break apart when hit and then all the pieces go back to where they belong.
Ah so you just want some way to iterate over the voxel file data so you can spawn your own meshes? That is pretty simple to put together, however I don’t see anyone else needing your specific use case. You can PM me if you really need it and we can work something out, pretty sure I could throw it together fairly quickly out of my code base.
Is large world support a planned feature for this plugin? This feature is critical for my project.
If possible I would like to use height maps for more control over my Terrain - if possible.
To give you an Idea of what I am want out of this plugin in terms of world size see the video below.
For large world I assume you mean streaming in and out of world data and possibly infinite world support, and initially no (i’ve already answered this to you by the way), I plan on incorporating it but it isn’t the focal point of this project at the moment.
The plugin is intended to be a maximum speed voxel tool set (I may have not made this clear enough), I keep getting people asking instead for game specific features and basically a fully featured game system. I do not intend of creating the entirety of minecraft back end with it as I consider it the least interesting use case and as something like that would do better with a custom solution tailored towards interactive textured blocks.
As far as progress, I am waiting for 4.11 to check out the packet intercept functions and get a clean build and will release then for bug testing and will add additional features after seeing how it performs on a few different systems. My trello is going to remain private for a bit, there are some tags that are purely theoretical that I don’t want people getting the wrong idea about at the moment.
My vive is due in early april, going to be using the plugin extensively with it after that point so should have pretty fast additions to it.
This is a mix of yes and No from me. Let me explain - While Infinite world support is great! That is not what I am looking for. I just want to load some tiled height map data (.raw or .r16) from world machine and have it converted to a voxel terrain. Similar to the above video. My goal is not to make a bunch of infinite worlds but to have a single large handcrafted world.
I do not expect you to make a minecraft backend. I am expecting you to make a toolset for making games with unreal engine.
Do not get me wrong - I want a fast voxel toolset as much as the next guy who works with voxels and Unreal Engine. But I can see the benefit of extending the core large world features of unreal engine such as the procedural foliage toolset and possible world composition which does allot of the work of placing foliage for the developer for them. Again this is a core feature that can be extended into your plugin and would be a big hit for people like me making hand crafted worlds.
No problem and totally understandable about the trello board.
Awesome to hear. Cannot wait to see and hear more.
Except it is a volumetric terrain, if you want to be able to edit the terrain at all post creation then you need to store all of the voxel data and keep it accessible. For a really large world this will REQUIRE streaming in the data to/from disk to minimize Ram usage. The built in level streaming itself might work with each tile being it’s own voxel terrain for singleplayer but making that multiplayer might be a tad difficult as level streaming currently loads the new level for ALL clients, not just the one that entered it.
Obviously it is all up to your self set limits for memory usage and vertices on screen but it is something you have to consider. The compressed volume won’t be actively worked on until the plugin is totally stable as I will have to start using a different threading system to manage that one. The streaming from disk would come after that as the obvious choice would be to use the compressed volume with disk streaming.
The foliage tools aren’t compatible through use of a plugin, it would require changing the foliage painting plugin itself. The procedural foliage toolset will not correctly function with dynamic objects as it paints instanced static meshes only. One of those “hidden” trello cards is instanced voxel actors which might be able to be made compatible with the painter, however this has the obvious downside of having them not be editable as instances and either converting them to non instanced if affected by something or not allowing editing at all on them, and at that point you might as well just use the instanced static meshes.
Obviously the way to go would be a custom solution (and why I have started on a custom editor mode for voxel terrains) that is more limited but is dedicated to editing the terrain. The mesh voxelizer is one of the tool options in that editing mode.
Spent the weekend playing around with the game jam in order to test the plugin. Made the base of an infinite flight game that never ends in the style of old arcade shooters. Ended up sorting through a bunch of bugs that I ran into when using the plugin outside of my normal test bed. Guess this will become a second test project to go over perf and update speed. I am overhauling some of the voxel actor code because of things I ran into when working on it.
Also got the voxelizer working much better, I wasn’t happy with the initial results and spent half of the first day revamping it.
Uploaded my test project as a demo on the main post. I am refactoring voxel actors at the moment so I removed them in it. However the current version of the adaptive LOD is applied.
