Wouldnt it be funny to create a realistic terrain with this?
Well you can calculate the normals ahead of time and send them in? Not sure why you want “per pixel normal”, all per pixel functions are Lerped between the vertices on the tri.
Not with the data you get from PolyVox, as you only get one vert per corner and Unreal’s prcedural mesh requires that if you do send in normals that the normal array has to be the same length as the vertex array. The normals aren’t really a problem as you can use the flat shading from here and get things to look decent enough. My main issue is UV’s, again the UV list has to be as long as the vertex list (using Unreal’s procedural mesh) so without quadrupling the vertices its (almost) impossible to get proper UV’s co-ords from a box with only 8 verts. So the only way to apply textures is to get the per pixel normal and do some fancy footwork. I’m going off the info from PolyVox Docs. And I can use tri-planar texturing, but getting the scale to match a block is difficult at best and seems very “hackey” the way i’m getting it done.
Maybe for me getting the best result would require me to create my own mesh component. I’ve been looking at Andrew Scheidecker’s BrickGame source, and the original CustomMeshComponent from the wiki and trying to piece how its done together and what the best way to do it would be. 
Epic has a node already made for triplaner texturing, i’m not using it with cube volumes because there are some speed ups if you assume the geometry but you can use theirs straight up.
That and world aligned texture would do for you
Hey is there any news on this?
I really want to see this
I too would like to bump my interest in this!
Will you be able to provide the source at any point or will you develop it as a kind of plugin?
Keep up the good work! It really looks great & I am looking forward to playing it
I’m also interested in this, I check back frequently to see if you’ve updated at all. For the last 6 months or so I’ve been looking at some of the work by others, people who claimed they might be releasing something to the community only to see them either stop, change their mind or just disappear. With Cubiquity officially now down the drain as well, I’m on the hunt for something to suit my purposes. Really didn’t want to write my own from scratch if the work was being done by so many others. Eventually looking for a marching cubes or dual contouring solution.
Oh i’m sorry, I never thought to check the thread if it wasn’t popped back up to the first page of the marketplace forums, I will subscribe to it so that I get updates.
Yes I have been doing a lot of work on it, I was contacted by someone outside of UE4 who was interested in migrating over using my plugin and have been getting feature wishes from him and using some of his assets to profile performance.
My main initial concern was to re-write hackish sections that I had left in as I was coding this just for my own light use into something more robust that wouldn’t require much effort to make use of.
I’m pretty sure that the only way to have a plugin package AT ALL at this point is to include the source (my Sessions plugin requires this). Regardless it is a plugin and just gets dropped into the project files and doesn’t require recompiling the engine itself.
I have recently decided to scrap marching cubes (I will update the OP), it has always been the inferior and bad looking version of DMC and DC and I don’t think that it is worth putting serious effort into. I may make a terrain editor that exports to landscapes using it but I decided that I do not want to put tons of effort into marching cubes that would be better spent on more elegant algorithms. Voxelfarms use of DC is so clean and nice that i’m not even sure that there is much use in re-implementing his fantastic work in that area since it is dated to come to UE4 soon anyway.
I apologize to anyone that was looking forward to Marching Cubes, however it just isn’t worth the time investment considering the lack of quality from it. I may consider it for the future with a completed cubic version but at that point I would have my compressed octree storage anyway and Dual Contouring would be the obvious choice instead.
I am banging out a list of TODO’s from a private Trello before putting anything up, currently improving the brush system so that the same brush can be used in editor and in game. Almost all of the main conversions I had planned for public use are already finished.
Here is a recent test of collisions while changing LODs though, also testing after decoupling creating the collision mesh from the main thread so that there are no FPS drops. When I get the brush system re-coded I’ll just release this demo? I’m just trying to bash out as much of the important stuff as possible right now.
I’m very interested in your project and I would love to use it. I don’t even know where to begin when it comes to integrating PolyVox with UE4 so it would be really nice to have a in house voxel plugin that everyone could use.
Have the brush system re-implemented using blueprint nodes now as a control interface (original was c++ only and a little hard to use).
Test video of painting with a 60HZ update rate:
I have a big interest in this, especially what you initially showed in your first demo with the large scale terrain.
I really hope this gets released in some fashion.
Hey,
Got a bit of a few questions / suggestions -
Is there going to be Voxel animation support using unreal engines animation tree system?
In regards to Biomes and large worlds -
Would it be possible to get a Biome Editor similar of that to SoA?
A GUI based Biome Editor would allow us to make environments really quickly IMHO.
1: Not entirely sure what you are looking for, if you want skinned voxels that deform to a skeleton then no I would not support procedural weighting (deformation across bones), that is a project in itself. If you want components that could be attached to an actors bones that are voxelized then yes, the current component would do that just fine, would literally just have to initialize one, attach to the bone, and it would transform with the animation. The base object in the plugin is an actor component that holds the procedural mesh, I form different actors / objects around it as needed, although it does not generally store voxel information itself, subclassing it to do so would be simple (And I will add it to my TODO).
That being said for one of my test projects I extracted a voxel character to FBX and skinned and animated it to a skeleton as I wanted smooth animation. That would generally be where I would expect people to go unless they want characters that can have holes blasted through them or something of the like or want the rigid component animation.
2: Biomes / large world generation is either an entirely standalone project or a game specific implementation, a general voxel framework isn’t going to support everything that everyone would want for generation, even more so something as specific as biomes types with simple sliders. To put it in perspective SOA is years into development now with multiple programmers and a defined end goal, and this is a one man plugin being shoehorned into an engine not intended for it and has to be generic / encompassing enough to be used as the starting point for many different things.
My intent is to get a base system working good enough that people without coding experience can use it and then see where to go from there. Large scale infinite world support or biomes or the like probably wouldn’t be on a feature list right off the bat, it is something I would love to work on eventually but I have to be realistic, this isn’t a minecraft remake plugin, if it was then it would be far easier and faster to complete.
Also apologies for any that thought this would make progress faster, It takes a lot of thought about best practices to refactor code in this plugin considering it is multithreaded, I have multiple side issues that I keep on the back burner and go back to periodically to see if I can improve them any more which tends to eat up dev time for a day here and there. Also it takes a lot of effort to make it accessible through blueprint in a sane manner, a lot of the re-coding I am doing is opening up classes to blueprints and blueprint safe implementations and moving features out of actor scope and into global (like the fracturing, have to open it up to things other than the terrain).
Looking good! Look forward to seeing how this progresses, keep up the good work 
Well the holidays got in the way for a bit but I got the fracturing re-implemented as a general scope feature. I have a laundry list of optimizations to do to it and some island detection to perform in the future but I tend to spend too much time optimizing and have decided to leave some of the areas as they are until it is more feature complete. I doubt too many care about 1/4 of a MS a frame as much as I do.
Hi Mordentral, do you think it would be possible to use this plugin for voxelisation of actors? Let me explain my use-case a bit. I was planning to build a simple voxelizer to be able to approximate buoyancy and air drag on an actor constructed out of multiple static meshes. So it’s not really for rendering purpose but more for tracing voxelized data to get values for density, surface area and etc.
Well the input/output/iteration of voxel data is supported yes, the shelling and solid fill of mesh to make it into voxel data wasn’t something I can considered handling with it as most voxel editors handle it themselves, so it seemed like a feature bloat. Were you thinking of generating the fill data on runtime or pre calculating the voxel field for the mesh and then combining the fields into a single volume to check against?
More of pre-calculating on the level of necessary components and then optionally grouping into a bigger voxel, if components change their location in real-time too much.
For example, something like a boat hull would be pre-calculated into voxels and in real-time voxels will only be queried if specific piece is in contact with waterline or completely submerged.
There are other cases like for example a landing gear of airplane which not only adds to cross-section drag but can “shadow” part of airfoil from getting airflow.
It might sound silly, because all this can be solved programmatically in advance if you know what kind of vehicle you have. But I’m looking at it from the perspective of game where users can build their own vehicles and general shape or placement of animated components are not predefined.
While possible with voxels I would assume that you would get better/easier results with convex hulls / using physx convex hulls for it. They are already built in to whatever accuracy that you set them too and wouldn’t require a new pipeline to implement. You can get the mass / density properties of Physx as well in the bodyinstance and convex shapes data. Using voxels would be more memory intensive (already have the physx data) and potentially less accurate depending on the scale of the volume, voxel data would be better suited for fluid simulation or gas flow or force propagation than something like that I would assume. Also surface area calculation with a hull would be pretty easy to take the surface area of each tri and add them together if using a tight fitting hull wouldn’t it?
There are a number of issues with convex hulls which are not so easy to solve. For example calculation of the volume of overlapping hulls. Calculating volume of the pyramid is easy but calculating volume and center of volume of it’s intersection with another pyramid turns into a costly routine where more than necessary triangles are involved in calculation. Tracing visibility of the triangle is another difficult part - many corner cases where triangle is partially visible but big enough to be significant.
It seams that voxels can handle such cases more gracefully but this is just speculation and I agree with higher memory expense. Perhaps I’m not being eloquent enough. I’ll dig up few papers which describe this approach.