I'm considering downloading the trial version of Voxel Farm, but have a few questions about its capabilities before I do.

I know that it includes a procedural terrain module, but can't find much in the line of details on that modules capabilities.

Is it capable of generating terrain chunks in real time (as would be needed for infinite, or nearly infinite terrain)?

Does it generate only surface features, or is it capable of including sub-surface features such as caves, ore deposits, different rock types, etc?

How does Voxel Farm store generated voxel data?
Do I have any control over this (for instance, if I want to store chunk data in a database rather than a binary file or however Voxel Farm handles this by default)?

Is Voxel Farm able to deal with voxels with custom properties, or is this something I would have to handle external to voxel farm?

Does Voxel Farm offer any kind of liquid flow handling?

Does Voxel Farm offer any kind of pathfinding?

Does Voxel Farm work out-of-the-box with the client/server model included in Unreal Engine, or is it going to require a lot of modification to the client/server code to get it up and running?

Has anyone used the trial? At this point, I'm still in the "evaluating different technologies" phase of my project, and certainly won't be ready to buy into any particular technology within the 30 day limit. I have been burned by other "cancel within 30 day" trials before where cancellation is basically made nearly impossible within the time frame required, so I'm always a bit cautious about "give us your credit card even though we're theoretically not charging you" trials.
0 0
The terrain component is able to generate chunks in real time as it would be needed for nearly infinite terrains. This component will create a volumetric layer where surface materials are extruded down. If you dig you will find the same material as in the surface. You could layer several of these to form some sort of multi-layered cake. It really depends on your world design.

Additional layers like caves, ore deposits etc. can be added so your world is made of the combination of all these layers. We include a caves plugin, but there is no ore deposit component. The main reason for this is each game will have a different logic for placing and shaping ore deposits so this is really up to the application. Writing a custom voxel layer is simple and our SDK contains multiple examples of this. With this knowledge you should be able to implement ore placement that follows your particular vision for your game world.

Storage of voxel data is up to the application. We provide some implementations, like a memory mapped database, but you are not required to use any of this. You can provide callbacks to the engine so it will request you to save/load blocks of voxel data. How you actually perform this is up to you.

We do not offer any kind of liquid or flow handling. We include ocean and lake generators, but this is static water.

Voxel Farm does not deal with pathfinding. It is able to produce highly optimized meshes which can be used by traditional pathfinding algorithms. No need to re-invent the wheel here.

We are currently looking at the client/server model in UE4. We do not have a multiplayer example at the moment. It is not clear if this will require modifications at all.

We believe 30 days is enough to evaluate the software. You can cancel this any time you want and you will receive a notification five days before the end of the trial reminding you to cancel. If you require an extension to your trial just email us at support.

0 0
Thanks for the quick response. I have a few more followup questions:

Any idea on what your timeframe is for evaluating Voxel Farm in the client/server model of UE4?

I assume storage and voxel generation are handled in fixed size chunks as I have seen with most other voxel implementations. Is this the case in Voxel Farm?

If so, is the chunk size something that we have control over externally, or is it fixed within the Voxel Farm engine?

From what I can tell from documentation, there is already some limited support for detecting when a clump of voxels becomes detached and should fall. Is there any support built into the engine for more complex structural physics, for instance, not being able to support a blob of 100 voxels from the side with a single voxel?

I looked over the downloadable demos, and I have to admit they look pretty good, but none of them seem to offer a good demo of realtime deformation of terrain (digging, etc). Any plans to create a demo that shows off those capabilities? I'd also be curious to see some more technical info on the demos, like what voxel sizes are being used for them.
0 0
We will be looking at multiplayer UE4 in the following weeks. This is very high priority for us.

All chunks contain the same amount of voxels but cover different scales of space. You can change this if you have the PRO version.

There is no structural analysis to discover fracture points at the moment.

The INDIE package available now contains demos that allow deformation, destruction and physics. We will be updating the other demos shortly, but as a user of the INDIE package you will have access to that right away.
0 0
Thanks for all the good information!

I will probably wait until you guys have had a chance to investigate using Voxel Farm with the UE4 client/server model before I sign up for the trial. That way I am not using up limited trial time trying to solve networking issues and can spend it really evaluating the use of the engine itself. I'll be keeping an eye on the forums here, assuming you will make a post at some point regarding multiplayer support.
0 0
So I have been thinking quite a bit about network support for voxel terrain the last couple days. I suspect that even if the UE4 multiplayer system does work out-of-the-box with Voxel Farm, it is not going to be the most efficient means of handling networking, simply due to the way UE4 handles replication. I would like to offer my thoughts on a more efficient way to handle this. Disclaimer: I haven't downloaded the Voxel Farm trial yet, since I am waiting until you guys have had a chance to investigate network support first. No sense spending my trial trying to get something working that is already on your roadmap. Because of this, I may be making a few wrong assumptions, but I think in general, these ideas may be helpful anyway.

Replicating all data for voxels in range of the camera is probably not going to very efficient, and is, I suspect, exactly what UE4 is going to attempt to do. A couple reasons this could be problematic: 1 - it is a LOT of data and could tie up a substantial amount of bandwidth as the player moves around, 2 - For a game that has underground features like ore, if you send all this data to the client, SOMEONE will build a utility to snoop the data and cheat.

To combat this, I propose the following. Maintain separate unreplicated actors on the client and server for handling terrain and handle replication yourself (here I am making an assumption about how Voxel Farm works in the first place, but even if this is not right, I think the concept is still valid). When a region is paged in on the client, a request is sent to the server. The server sends an array with the summary of all the chunks in that region. The summary should contain only a small amount of data. A 4 byte integer with the current version of each chunk, and a couple bits saying whether the chunk is empty, hidden, or exposed. An empty chunk is any chunk that has no rendered voxels in it, just air. A hidden chunk is a chunk that has all 6 faces completed blocked by neighboring voxels, and thus will not be rendered. An exposed chunk is any chunk that has 1 or more renderable voxels.

Once the client has this chunk map, it can then request data for any exposed chunks (obviously any empty or hidden chunks can be ignored, since they are not going to effect rendering). Again, the response should only contain details about exposed voxels (any voxel that has a single exposed vertex is exposed, since this will effect mesh generation). Any voxels that are complete hidden should simply be sent to the client as generic hidden voxel, this should allow fairly good compression of the data stream to minimize bandwidth usage, and also not expose any more data than necessary to potentially dishonest players. Note that since the client already has a version number for each chunk, if the chunk has not changed since the last time the client downloaded it, it does not need to request it again until the version number changes.

So I have addressed the initial paging in of terrain, but not real time changes. When a chunk is paged in on the client, in addition to supplying the chunk header information, the server should automatically subscribe the client to updates on this chunk. Updates would be as small as possible, since in most cases a change is only like to effect a few voxels. Change messages should basically contain an identifier for what chunk has changed, the new version number of the chunk (incremented on the server each time there is a change), and the voxels that were changed this update. This should make terrain changes use up VERY little bandwidth.

Hopefully these thoughts are somewhat helpful.
0 0
I wrote my own multiplayer voxel engine for UE4 but am hoping to switch to VoxelFarm once they get the Multiplayer Support, hang-on-load and destructible trees/flora in multiplayer.  I ran into some issues with multiplayer implementation that you should be aware of.  The quicker you get that working, the easier my life is going to be XD

Here are the issues i saw.
1) Terrain collision relevant to all clients must be built on the server.  That means all the server will need to track where everyone is and generate local chunks with collision for them.  You won't need the lods on a dedicated server though.

2) Only replicate changed voxels (as mentioned above).  Or avoid using the replication system all together preferably through the UDP messaging system plugin.  I built mine plugin was available and had to write a streaming algorithm to avoid filling up the replication pipe with even changed voxels.

3) Implement Client->server voxel change code.  Pretty simple but felt, for completeness to add this.

4) Use Dynamic NavMesh with Navmesh invokers so mobs can navigate terrain.  This is more info for uses that Voxelfarm but VF should make sure that dynamic navmeshes and invokers work with  their stuff or else we can't have mobs [frown]

5) Items and vehicles will need to be turned off when players (terrain) move aware from them so they don't fall off the map.  Not saying VF needs to fix this but support code to determine if vehicles & mobs are in safe terrain should be there.

Some general advice,  look at the navigation invoker mechanism.  This is a good model for server based voxel collision invocation.  And it's already coded in UE4.
0 0
Thanks for the tips, this helps ups greatly. If you can think of anything else please post it here.
0 0
Glad to help.  I want to see VF be a success here XD.

 I guess the only other thing is that a lot of the calculations for the terrain mesh can be done in separate threads but I imagine you already are doing that.  Also, an optimization suggestion,  I prioritized chunk generation based on an x,y spiral  it looked more believable and lowered the risk of the player falling through the map.  On the server,  it's a bit more tricky, I prioritized based on distance to the closest player.
0 0
How has the multiplayer support progressed ? 
0 0