Gryz wrote:
Thanks for the reply! Here is a screenshot:
https://pasteboard.co/GBUYM9t.pngYes, the map is generated and stored in an array. The array is used to build the cube volume.
I still need to implement the changes, but reducing the number of voxels rendered during scrolling from 10x100 to 10x16 has improved performance significantly.
Some other questions and points:
- Is there a performance advantage in rendering part of the volume compared to the whole in my case? For every column of voxels added to the grid, a column of voxels is removed using:
data.SetVoxel(x, 1, z, new QuantizedColor (0, 0, 0, 0));
So your array is 1000x1000 (it's a 2D array, not 3D?) and your Cubiquity Volume is 100x100 voxels. As the player moves around you write new voxels into the volume and also delete some voxels which go out of view? Wouldn't this mean you also need to scroll the rest of the voxels by one position? Or is the Volume actually the same size as the array, and you just keep it only partially filled?
This sounds like it might be overly complex... have you tried getting rid of the array and simply having a volume which get completely filled on startup with all the data? Then there is no need to do anything as the camera move around. Internally Cubiquity splits up the volume into chunks so Unity will still only render the parts which are actually on screen.
For a 1000x1000x16 volume I think you can do this (at least it is worth testing), but if it needs to be any bigger then you might have a problem. One of the example volumes (a bridge or a city, I forget which) is 512x512x64 voxels (so the same number of voxels in total) so perhaps test this too?
Gryz wrote:
Or are you suggesting I break up the volume further into sub-volumes?
No, I would advise against this. Cubiquity already breaks the volume down internally.
Gryz wrote:
- I would like to provide a map view in my game. It would work just like a map in an RTS game-- clicking on the map would take the main camera to that point in the world. Do you have suggestions on how to implement this so that there is no wait time for the new location to render?
Again this would become easier (trivial?) if the whole volume was loaded all the time.
Gryz wrote:
- I added a Cubes Collider to my volume. The collision detection is pretty unreliable-- colliding into a wall straight on the x or z axis stops the player. But the player can slip through a wall by traveling on both axes, or occasionally by colliding straight on one axis. Is there a way to fix this?
A few options:
- You could re-enable Cubiquity's built-in collision mesh generation. It significantly slows down mesh generation but if you are doing most of that on startup it might not matter too much... could still be slow though.
- You could maintain a pool of cube colliders (maybe 100 or so?) which you move around to always occupy voxels near to the character.
- You could impement collision detection manually, by calling getVoxel() on voxels which the player is about the enter.
Some experimentation might be needed here :-)