Cubiquity - A fast and powerful voxel plugin for Unity3D

@productofself - I can understand this is frustrating, but keep in mind that Cubiquity is really just a part-time project which we fit around our regular jobs, etc. There is currently no financial incentive and so we're no longer trying to acquire users as such, but simply trying to have fun creating an interesting/useful system. One of the reasons for going free was so that we wouldn't have to worry about justifying these kind of positions.

That said, there are clear benefits to opening up the source to Cubiquity and even making it free for everyone (which is a possibility). But life is busy at the moment, and the next priority is actually to get Voxeliens shipping on Steam. After that there will be time to think again about the future of Cubiquity. Honestly, I'm not trying to cleverly hide our future plans... I simply don't know exactly what they are yet. You really do have to base your decision on what you can do with Cubiquity at this moment.

Right, so let's start with finding out why the example scenes don't work. Does it help if you double-click the terrain in the hierarchy, in case it is out of view? Does anything happen if you switch to play mode?

If it still doesn't work then do you see any errors being printed? Is a 'cubiquity.log' created next to the .exe? What platform are you on? I can try exporting a stand-alone build for you to see if that works.

It is a Unity wrapper for the Cubiquity voxel engine, but the necessary .dlls are included so it should just work.

 

Hi David so i put it into a different project and it works Unity is so weird sometimes. I have 3 projects open to spread out the assets for my game in the 1 project i can't move the standard controller just won't do anything. In another the displacement slider in a tessillation phong shader can make huge mountains from a plane tried it in the others and they behave normal. In the last my ocean won't work if i import to many gigs into the asset folder. What the size of my asset folder has to do with a functioning ocean is beyond me.

 

Great, I'm glad it's working and that it wasn't a problem with Cubiquity.

 

Quick question: I'd like to make a minecraft-like game where the terrain is procedurally-generated and the world extends infinitely in all horizontal directions. The game would then load a region of the world around the player, and would unload chunks as the player moves far away from them. My question is, what are the ideal dimensions for each chunk of terrain to have? I was reading the documentation, and you seem to discourage people from dividing the world into too many different volumes, but in the case of an infinite procedurally-generated world, obviously you have to divide it up somehow. How big should the chunks be? Would 16x16 be too small? Would 64x64 be a good size? The documentation mentioned that breaking up the scene into too many pieces can interfere with optimizations; how small can I get before that would be a problem?

 

Although it's a popular genre, Cubiquity isn't really designed for such games. The focus is really on fixed-size maps which are loaded from a database. You can generate them procedurally and save them back to a database, but that's quite different from what you need for infinite terrain. You will probably be better off using an engine which is specifically designed for this scenario.

 

Hi again, been playing around a bit more with the cube version. Cool stuff... but a couple of questions...
Demo runs at great frame rate (macbook pro) except when I blow up some cubes with radius of only 3 or so... the whole scene stutters/pauses. I tried turning off the resource load/instantiate of the cube debris. but this only partially speeds things up.. It seems like turning off the cubes would be very fast, but it does not seem to be so ? IS there any thing I should keep in mind for best performance ? help appreciated, thanks.

 

Hey i just downloaded Cubiquity, I really love the way the cube volumes look. I can run it fine on the editor but once I create an executable, it seems that the volume doesn't even attempt to load, i just get a blank scene, any ideas why this might be happening?

I'm running on windows 10.

 

I don't think it works in a web exe, try making a standalone .exe

 

I think the slowest part of the destruction is probably the regeneration of the collision mesh, which has to happen even if only a single cube is removed. You can test this quite easily by opening the 'ColoredCubesExampleScene', selecting the 'Colored Cubes Volume' in the hierarchy, and then removing the 'Colored Cubes Volume Collider (Script)' in the inspector. Cubes will now fall through the floor when destruction occurs, but how is the performance?

Does a 'Cubiquity.log' file get created next to the .exe, and if so what does it say? Did the problem occur using your own scene? If so, what happens if you try exporting one of the example scenes? Try the ColoredCubesExampleScene so we have a common reference point. Did you export as 64-bit?

If you can't get it work then I can try exporting that scene myself and give you the build, or you can give me your build, just to compare results.

I'm also on Windows 10 but I must admit I haven't tested exporting since I upgraded.

 

Thanks for your reply David.
I'm not too worried about the performance of the cubes rigid body collision 'after' the explosion... this performance I can manage... reducing number of cubes created, maybe destroying some instantly, etc....
Creation of the cubes can also be sped up with pooling objects...
The problem, as you say, is probably re-generation of the collision mesh... this causes the large pause at the time when the explosion goes off. (my map is fairly large compared to the demo scene)
Is collision mesh generation done inside the C++ library, is there no way to time-slice this ?

How is this for an idea.... ? feel free to shoot holes in it (pun intended)
1) fire off explosion....
2) cut the hole in your collision mesh, but don't re-generate new polygons (if that is the slow part)
3) make list of positions of all the new 'exploded' cubes to be spawned
4) make a list of all explosion-adjacent cubes that are currently still whole / enabled (you probably do this already)
5) create dummy unity cubes at these 'adjacent' locations with regular unity boxes with collision meshes..
6) time-slice the generation of new collision mesh over multiple frames
7) once finished.. swap in the new collision mesh and turn off the temporary unity collision cubes.
8) if another explosion goes off before the time sliced version is finished.... then stop slicing, and finish it fully, (probably with a pause in performance) and start new time slice on the newest explosion...
Or it might be possible to just stack more unity cubes into a list, and keep working on time slicing alternate collision mesh until it is good to go, then swap it out.

 

There are actually two separate stages here. Firstly there is creating the mesh from the volume data, and then there is turning it into a Unity collider. Generating the mesh is done in the C++ and is pretty fast (it is also used for rendering, which easily updates in real time) though for sure it can be improved. Converting the mesh to a collider is done by Unity and this is the slow part, as Unity has to build various internal structures to support collision detection.

I'm a bit hazy, but some form of time-slicing is already done in that if there are multiple collision meshes to be built by Unity then we spread this over several frames (as I recall). However, at least in Unity 4 it was not possible to build a collision mesh in the background, so the frame has to pause by at least the time required for constructing a single collision mesh. I should probably check if this has changed in Unity 5.

Actually, I would quite like to drop the use of collision meshes completely. In point (5) you hint at temporarily using Unity box colliders, but I think they could actually be used as a complete and permanent replacement for the mesh colliders. To do this you would want to combine multiple adjacent boxes into a few larger ones, similar in principle to the way we reduce triangle count by merging adjacent quads. Then keep a pool of 1000 (or whatever) kinematic cubes and simply reposition/scale then to approximate the terrain. Rearranging them in response to terrain changes should then basically be free. It should also be more robust as the volumes can then really be considered physically solid, rather than just being a shell.

 

Thanks for the great reply... sooo reading between the lines.... It sounds like if I put the work in... I could make a custom collision system.... turn off the generate collider..

I see 2 ways to go....
1) something akin to an octree/volume of cubes Static, except when something is exploded, but would need alot of pre parsing /prep. Might still take a while to re-calc volume boxes after explosions

2) read the voxels near anything that might collide with voxels ? and if it does, use a pool of unity box colliders, moving them around to follow moving objects when near walls. No pre calc required... but more dynamic calculations and vox checking. Probably more prone to issues... also probably smaller memory footprint, and quicker to respond to lots of explosions...

If you think this will work, and be fast.. I might give it a shot

For projectiles, I think I can just do some kind of simple ray trace detect, (like a 3D line-draw) reading the cubes, and ignoring collision mesh entirely. Can ignore collision check if projectile is still in same vox as last frame.
But for more complex objects or needing rigidbody, then need option 1 or 2 above...

interesting problem...


...thinking on it some more.... I think option 2 might work very well, and very fast for my needs, if reading the vox array to check for full/empty voxels is quick

 

This is what I will investigate first if/when I get around to looking at this myself. I don't think is is too hard/slow to generate an appropriate set of boxes to approximate part of the volume after an explosion occurs, Actually, we are already generating the mesh (for rendering and currently for collisions) and as a first approach you could turn that mesh into a set of boxes. The mesh is a list of triangles, but every pair of triangles actually defines a quad. These quads have already been combined with their neighbours to minimize the number which are required.

For each quad, work out it's size (width and height) and this will give you two dimensions of the box collider you need to add (set the other dimension to 1?). Then place the box collider just under the quad (according to it's normal?). There will be a number of overlapping boxes but I guess that doesn't matter. Remember, you should pool all these box colliders so there should be no cost to creating and deleting them, and moving them into position should be free.

Note that you should probably not read back from the Unity mesh (may be in GPU memory and slow?) but instead from the 'raw' Cubiquity mesh data that the Unity mesh is built from (see here: https://bitbucket.org/volumesoffun/...ity/Scripts/Impl/MeshConversion.cs?at=develop)

The approach I describe is suboptimal though because a large number of boxes will overlap. Perhaps a better algorithm for 'box decomposition' is needed. But it could be a starting point. Also Unity supports composite colliders, so each chunk of the volume should probably have a single composite collider containing many boxes.

If you want more guidance I can take a closer look.

I hadn't really though of this approach, but it actually sounds more complicated and game specific. I don't think it would be implemented inside Cubiquity for Unity3D as there would need to me some method/API to define to define which parts of the volume were 'interesting' for collisions. Also, the box colliders would not be merged in this case (right?) so you'd have a very large number of small colliders. But, the idea is interesting and does deserve more thought.

Approach one only requires the box colliders to be updated when the volume changes, but approach two requires them to (potentially) be updated whenever anything moves in the scene?

 

yes agreed, method one is the way to go for generic use for sure.
Youd just do a recursive oct-tree search of the voxels... if all are filled at a size level, you'd mark the octree full and just make one collision cube at that size... and stop the recursion there. Mark empty quadrants, empty, and partially fulled quadrants(octants ?) as partial, and recursively parse deeper.
When explosion went off in an area, you'd need to re-generate tree for that octant.

but method 2 works well if your objects are small compared to the size of the voxels (mine are) or can approximate with sphere colliders ( I can also ) so I'd only need to check/generate a small number of voxels per colliding object, and have choice of fast sphere distance check.. or BoxColliders and rigidbody.
Main down side is that doing a long range raycast is hard.... needing an iterative (slow?) approach.

Just tried quick test with collider off, (and without generating cube debris or fx sprites) and its much faster, but still hitches frame-rate about half the time, depending on the spot that you try to explode.... some areas are fast and don't hitch framerate, other areas of the map seem slow... maybe if doing an explosion across chunk boundaries ? it might hit 2, 4 or 8 chunks at once ? is this possible ? hence re-calculating mesh could be slow at the boundaries ?

 

Hi, does anybody have the script - the destruction of cubes not from clicks but from colliding with the trigger

 

is it possible to create? that would have been a certain cube. Which would have been with the physics-such as liquid, ie as the explosion, but was not removed. And the cube which could carry an empty object where it would add spawn some object.

 

and still have the problem with the click. if I used three cameras, the click doesn't work when you change the camera rotation and the flying camera attached to the object. only works on the first chamber

 

Just look at the click to destroy script... you can add a call to this from your colliding object.
something like....
void OnCollisionEnter()
{
ClickToDestroy.m.DestroyVoxels( transform.position, damageVoxRad); //blow a hole in the voxelmap !!!
}

 

@vinurd - Cubiquity is quite a low-level system which is not really aware of things like collisions taking place. It only really provides an API for adding and removing voxels via SetVoxel(). If you want the world to respond to collisions then you can do this, but you need to code it yourself. The 'ClickToDestroy()' is only an example of the kind of functionality you can achieve. You are welcome to modify this example but you will need to have good C# skills to do this.

You also indicated to me on Twitter that you are using PlayMaker. I have never user this tool so I cannot say how well it will work with Cubiquity. But you will need a way to connect it to the Cubiquity API, unless PlayMaker already does that for you.

Yes, this is correct. There may be better algorithms for finding the set of cubes but the approach you describe sounds reasonable.

Yes, agreed, that sounds sensible.

Can you not just take the position of the object in your scene and check all voxels within a certain radius? So if your object is at (x,y,z) and you know it has radius 2, then every frame you check the 5x5x5 = 125 voxels between (x-2, y-2, z-2) and (x+2, y+2, z+2) to see if they are solid, and if so put a cube there? Maybe this checking of voxels is too slow a it has too go across the C++/C# boundary. There would be some argument for the C++ library being able to provide this list I guess.

It sounds like a possible explanation. You can try changing 'DefaultBaseNodeSize' in the code but I'm not sure I've ever tested it (should control chunk size I think). But of course smaller chunks means more chunks, so it's a trade-off.

 

"then every frame you check the 5x5x5 = 125 voxels"

Yep this is exactly what I mean, but its less voxels than that, as I can ignore all the ones inside the center on my sphere collider (no point colliding with myself)
Might also be able to ignore the ones on the back of my moving object.. away from direction of travel.... maybe...
And definitely ignore the ones where I already have a collision cube...
So it might turn out pretty fast... Still thinking about it, but I'll let you know if I get it working.

Thanks.. I'll try fiddling with DefaultBaseNodeSize !!!

update... size 16 works pretty well... still little stutter, but not often.

actually... once down to size 16... I can turn the collision script back on also, so I don't need to do the alternate collision system... phew.. !

 

Is it possible to get the C++ source code for the DLL ?
I'm willing to pay for it if you want me to.
Thank you.

 

Great! I'm now wondering if there should be separate node sizes for rendered vs. collisions meshes... probably that's too complicated though. I'll keep it in mind though, in case my own plans to switch to box colliders don' work out for some reason.

Unfortunately not - the C++ code still needs some work before it is ready to be released. I do hope to make it available in some form in the future though.

 

Is it possible to NOT create the voxel database ?
I mean, I use a procedural script to create the voxels then only add the modifications with an array, it's lighter like that.
So I really don't need to save the current database format as I use my own system.
Is there a way to disable this ?
Thank you.

 

No, Cubiquity always makes use of the voxel database and there is no way for you to change this. I do agree it would be interesting to add support for a more generic 'data source' (which could then be procedural) but this is not supported at the moment.

However, you can choose not to provide a path when creating the .VDB, and in this case a temporary file will be created which you do not need to manage (as I recall). See: http://www.cubiquity.net/cubiquity-...e_data.html#a3c62dc0eacd304b2c51e673efae08892

 

Is there a way to disable side meshes that are at the upperCorner / lowerCorner ?
As I understand it, it's a feature that is added to the mesh by the DLL, but I don't want it.
I need to have multiple chunks glued together seamlessly, but the sides are rounded so it shows a cut in between the two chunks.
Basically I don't even want side meshes for the upperCorner / lowerCorner.
Thank you.

 

Unfortunately removing the side meshes will not (properly) fix this. The Marching Cubes algorithm does not operates on single voxels at a time, but instead on sets of eight voxels. This makes it difficult to seamlessly join volumes because the mesh at the edge of one volume becomes dependent on the neighbouring volume. You would have to actually overlap volumes to get them matching properly in all situations, and this means you would have to duplicate voxel data (which in turn makes updates more difficult).

Internally Cubiquity already splits the volume into multiple chunks (e.g. for fast updates), and does so in such a way that these issues are hidden from you. However, the volume size is still limited because the whole volume is always rendered. It would be interesting to change this in the future but for now Cubiquity is not suitable for huge/infinite volumes, and you will probably hit various issues if you try to force this.

 

is there any support for alpha in the color channel of each voxel ? you mentioned before, something about hiding extra information in there if I wanted to make a custom shader that could do other things apart from the default texture...

or what happens if I do use alpha ? I assume there is no support for rendering semi-transparent cubes ? I assume they are all opaque ?

btw what is the performance hit on changing color ? can I change a whole bunch of cubes colors per frame without triggering any kind of mesh re-calc ?

 

There is no real support for transparency, though as you mention some bits are set aside for this in the future. Actually I forget exactly what happens... I think I cube will simply be drawn solid if the alpha is greater than 50% or greater than zero (I forget which).

Actually making use of the alpha channel will be tricky, as the transparent voxels will have to be drawn separatly and probably be depth sorted. I haven't really given this much though yet.

Changing the color of a voxel will have the same performance impact as adding or removing a voxel, in that the mesh for the chunk will be regenerated. The colors of the voxels can affect the structure of the mesh because only quads of the same color are merged into larger quads. Note that I say 'can' rather than 'does' because there will be cases when changing the color does not affect the structure of the mesh, but we don't optimize for these. It might be worth doing in the future, but we'd also have to split the mesh into separate position and color streams, so there's a bit of work here. Overall I think the previously-mentioned box colliders are the more important optimization.

 

Thanks much, understood on all.

 

Is it possible to make the Mesh creation Synchronous (Not Async) ?

 

In Volume.cs there are two constants called 'maxSyncOperationsInPlayMode' and 'maxSyncOperationsInEditMode'. If you set these to a large value then Unity should always fully suncronize to the .dll output, which should give you some of the effect you are after.

However, I don't remember if the .dll itself spreads the mesh generation over a number of frames. I'd have to dive in to the source to check this but I am going to be away for a couple of days.

 

What would it take to get cubiquity running in the linux editor?

 

I think it should be straightforward as it already works in the Linux player. You will at least need to copy the shared library to the correct place when in Linux editor mode. You can start by looking at Installation.cs.

 

I didn't even have to copy the .so. Just added
case RuntimePlatform.LinuxEditor:

 

Great, and then it all seems to run as expected? Do you notice any bugs which aren't present on other platforms?

 

I noticed that whenever I load a colored cubes map, it spams the debug console with about 500 print messages "Shader wants normals, but the mesh doesn't have them" if I turn off the renderer, then turn it back on, it spams the messages again... Its using your default shader/material which uses a normal map, so I assume the mesh itself does not have normals ? How do I get rid of this error / prints please ?

 

@JonnyHilly - Yes, I have seen this. But for me it doesn't happen most of the time, I've only seen it occasionally when things go wrong. Do you even see this if you open the Cubiquity example maps? Have you had it since you first started using Cubiquity? Any insight into when or why it started happening?

You are correct that the cubic mesh does not have normals, or at best it has dummy normals (perhaps, I forget). Because we want the cubes to be flat-shaded normals actually present a problem, because they are (smoothly) interpolated across triangles by the GPU. The usual solution for flat-shading is to duplicate vertices which lie on a boundary - i.e. a single cube would be represented by 24 vertices instead of the usual 8. This is obviously wasteful, so Cubiquity instead uses some tricks to generate the normals in the fragment shader.

 

Yes, saw that the shader, makes up temporary normals, on the fly.

You are correct, the 2 example scenes don't have the errors.
I have a mesh imported from Magica... fairly large, just a perlin noise example from magica.
But I don't know what to do to fix the errors.

lots of these....
"Shader wants normals, but the mesh doesn't have them"

if interested I can dropbox you the magica file?

btw, maybe related question... It renders fine on my mac, but on my friend's mac, it renders whole terrain almost all black... no lighting. I can't figure out why yet. Quality settings make no difference, I have 1 main directional light in the scene, ambient and one spot. your shader is set to model 3.0, could it be his mac can only render shader 2.0 ? How does fallback shader work in this situation ? Or what happens on 2.0 shader model video cards ?

btw.. just let me know if I'm asking too many questions and I'll stop, hehe

 

Ok, so what if you open the colored cubes example scene, and modify the volume to point at the .vdb you imported from Magica (Inspector -> Colored Cubes Volume (Script) -> Volume Data)? In other words, does your imported data look correct if placed in the example scene?

Conversely, what if you take your problem scene and point it at the example volume instead of the Magica import? It seems unlikely that the problem is related to the .vdb file or it's source - more likely it is a problem with the scene, volume settings, or lighting.

Yes, but do the above tests first because it may be that you actually need to send me the scene/project/etc rather than the Magica file. You can PM me the link if you prefer, but we can follow up here as I try to keep discussion public where possible.

Are you talking about with your problematic volume/scene, or with the example scene (it's good to use that as a reference)?

I must admit Mac get a lot less testing (just inside VirtualBox as I don't actually have one). But the situation could be as you describe, and the fallback shader won't work properly due the the lacks of normals. It would probably be possible to write a better fallback shader which drew cubes with a solid color (no lighting). I don't think shader 2.0 support is that high priority though.

Not at all! You seem to more or less understand Cubiquity and put plenty of effort/detail into your posts. It's good if people can see Cubiquity is a supported product (which is one of the reasons why I keep everything public) and it also shows the product is still active. So just fire away with the questions

 

is there any way to add cubes while in run-time?

 

Yes, the capabilities at runtime are the same as at edit time. In both cases you can set the color/opacity of a voxel with the SetVoxel(...) function. If the alpha channel (opacity) is set to 0 then the voxel disappears, and if you set it to 255 then the voxel is shown.

 

Hi again guys, long time fan, second time poster. Last time I posted, I had successfully achieved a networked version of Cubiquity running with ColoredCubes; last night I switched to Smooth Terrain (and loving it!). A couple questions come to mind and was hoping I could throw them up here and see if I get some guidance (listed in order of priority).

1) The vdb size may be an issue for me moving forward, so I'm looking for alternatives to solving this issue. In my networking design, I stream the server-owned vdb to each client upon them accessing the "door" to each area. My hand-drawn smooth terrain vdb is about 240 KB, which is a pretty large stream. What could I do to lower this file size? Increasing the voxel size and decrease volume resolution?

In my particular project, I'm using the voxels for caves, so I thought maybe if I only stored the locations of the "empty" voxels and just have the client fill in the rest with "filled" voxels, that may reduce the size pretty significantly? Open for ideas on this one.

2) I notice when using the smooth terrain, there can become instances when you're editing terrain and small pieces of the terrain are left floating in the area afterwards. Sometimes this can be fixed by removing the rest of the voxel, but sometimes not. Anyway of detecting these outliers and removing them when I destroy the voxel?

3) Are there any third-party voxel editors that create smooth terrain voxel objects that work with Cubiquity? Previously, I was using a model I created with MagicaVoxel and found out pretty quickly that it doesn't covert to smooth terrain. Which is perfectly fine because it was a test model anyway, but does a similar workflow exist for smooth terrain? I created a model in Unity editor, but it's sloppy since it's done by hand. I'm looking for something a bit more symmetrical.

4) I'm interested in creating a similar "DestroyVoxels.cs" script for smoothed terrain in that it spawns a few rigidbodies on the client when they explode and destroyed some voxels. It's a little more difficult because I need to detect the shape of the voxel and replace it with a prefab that's broken apart. Anyway of detecting the clicked voxel shape? Going off of what I understand about Marching Cubes, there's a finite number of voxel formations, so once I know the shape, I can select the right formation prefab and spawn the effect on the client. Alternatively I could just spawn a particle effect, but I think it would look better with broken terrain falling around the player.

5) Final question, I promise! Actually, it's more of a comment than a question. +1 on collision mesh performance improvements! I saw there was an earlier post on this and I'm noticing some slight hiccup whenever I use the DestroyVoxels function on my smooth terrain. I know this asset is being provided for free so I'm not putting my hopes up that this will be improved anytime soon (and I don't blame you @DavidWilliams ! You've been awesome supporting this product with everything else you have going on!), but just thought I'd chime in.

Sorry for the long list of questions. Really enjoying working with this tool.

 

@bigd I intend to implement something like your #2) question, but I think its not so trivial a problem.
When you explode an area or a single cube... You'd have to do a search, starting from all nearby remaining cubes (say on the outside of the exploded surface area.... For each voxel, you'd have to do some kind of recursive search... counting how many connected cubes there are... and place a limit on what you call a disconnected area (number of cubes/voxels) once it passes the test (connected) stop searching, and move onto the next voxel in the list.
Removing individual cubes would be pretty easy... removing clumps could get slow

 

Makes sense to me conceptually! Putting the idea into code is where I'm a bit lost, particularly around doing a search of all nearby elements within the destroy function and performing a check. I'm just not as familiar with how to check the number of connections a given voxel would have? I would be interested in talking more should your try and take a stab at this yourself!

 

Hello i was drawn to Cubiquity for its "free price label" and functionality but i have a few questions is Cubiquity compatible with unet multiplayer the "new" networking solution for unity?Like say i have a character and i fire some projectiles towards the terrain will it destroy the terrain pertaining to the projectile for example a exploding arrow explodes when it collides with the terrain?If not it would be cool

 

I'm not the authoritative source on Cubiquity, but I believe what you are trying to accomplish is possible; however you would have to make these changes yourself with some code. Conceptually, all Cubiquity really needs is the x,y,z position of where you want to remove or add terrain. I can see it working so that you would attach a script to your arrow object which calls Cubiquity's SetVoxel() function with its position when a collision occurs with the voxel terrain.

Cubiquity will work over UNet, but again, with heavy modifications. I look at Cubiquity as a pretty modular type system and if you understand UNet enough and with enough time, you too can make them work. I did it with Bolt recently and you can read some of my other posts to get the gist of how this can be done. Hope this helps! Good luck.

 

Thankyou, for your reply although your not a developer for this asset but you understand the core concepts of what i'm trying to achieve, i believe i somewhat understand where you were going with this. I'm not a programmer at least not yet so i was kind of hoping someone could give me a basic script layout of where to start i noticed what you were saying or at least this is how i perceived it to be.Basically i would have to write/edit some scripts pertaining to Cubiquity and somehow make them sync/transform over the network?Glad i purchased a C# programming book the other day Would be cool if they could implement a Unet multiplayer version i would pay for that Guess i have a long term goal ahead of me thankyou for your reply and informative response Bigd,I will read up on this book and keep in touch with everyone on the forums as i go along on this open wide journey.So many things to do hehe thanks again..

 

Sure thing and good luck! Knowing how to code is crucial especially if you are integrating assets on the asset store. I believe there's an asset out there called PlayMaker, which is a very popular node-based graphical interface that outputs code for you. It's coding for non-coders. You might want to check that out. While I don't think it'll work perfectly for what you're trying to do, I believe you could play around with it and create smaller scope projects. The goal is to learn from the code that's generated to facilitate your learning.

 

@Cascadex, bigs is correct, its possible in Cubiquity, but not straightforward.... (and you don't need to modify Cubiquity)... read up on RPC's Remote Procedure Calls... they exist in most network solutions.. basically it is a function that when you trigger it... is executed on all networked machines with the same data...
So for example when you want to edit one block on the map, you make an RPC with what you are doing to the block at a specific location e.g. SetBlockColorRPC(x,y,z, newColor);
Try this tutorial... https://doc.photonengine.com/en/pun/current/tutorials/tutorial-marco-polo
But if you aren't a coder, this might be a bit tricky.... Find a coder to join your team perhaps, or just take your time and learn some c# for a while first and experiment getting comfortable coding.

 

Sorry for the slow reply guys, it's been a busy week for me. But it's great to see people have been helping each other out in my absence.

I don't think there is much you can do to improve the compression rate. Internally there are things I could do but no easy wins - they would all take some work.

However, you say your terrains are 'hand-drawn', so you have heightmaps? How are you converting these to terrains? Could you send the heightmaps over the network and convert them client side?

Yes, though you'll have to implement this yourself. I don't have a clear algorithm because I've never implemented it, but you should probably look into breadth-first search. Or possibly 'finding connected components' (it's a classic image processing problem).

Also see this post (with video): http://www.volumesoffun.com/phpBB3/viewtopic.php?p=4769#p4769

There's Acropora though I've never really worked with it, and you might want to just try searching for 'voxel sculpting' or 'digital sculpting'. In general you will have to find a way to get the data out of these tools though.

I agree that the built in Cubiquity editor is rather primitive, but you will probably find you can use it for painting on the materials.

Getting the true shape is complicated, and you won't get it quite right without reimplementing Marching Cubes in C#. The catch is that each vertex is not dependant on a single voxel, but instead on the relative values of eight adjacent voxels (forming a 'cell').

You could make some assumptions like assuming every voxel is fully solid/empty which might simplify things a bit but I don't think it would looks right. Or spawn spheres with different sizes depending on the voxel density, and fix them together with a root object so they all fall as one (also noted here)?

There's going to be some improvisation required for this one

Unfortunately the smooth terrain is a lot slower than the cubic terrain in this regard, because it generates a lot more triangles and so the collision mesh takes longer to build. We already have experimental support for LOD when rendering, and ideally we would extend that to use the lower-LOD meshes for collision as well. But don't hold your breath, it's probably a way off.

I just wanted to note that only searching the outside (the surface voxels) is an important constraint, as it reduces it from and O(n^3) problem to an O(n^2) problem.

I think others have already pointed you in the right direction here. As noted, Cubiquity is quite a low level system and has no knowledge of concepts such as networking, collisions, projectiles, etc. However, you can use Cubiquity as a building block to build the kind of system you are after. You will need to create/handle/syncronise network events yourself, and then modify the Cubiquity volume in response to these events. It is an advanced topic, and I haven't tackled it myself yet!