The following are my ramblings that may or may not be of use to anyone:
Map format.
Okay, i
read a bit about .vxl files, and i have to say that they're pretty cleverly made, because the visibility problem is mostly sorted out in the file format itself (rendering all of the voxels would seriously mess with most modern GPUs/CPUs).
However, i think that there's absolutely no way that someone uses them at runtime without interpreting them first - otherwise you'd have to re-write the whole file after each and every single voxel addition / removal. Now, that might not be so bad, because the files tend to be pretty small, but imagine doing that multiple times per second and sending this whole file to connected players every tick. So, your usual arrays must be used for handling things apart from loading/saving the maps.
This brings up a question i have - does UnityScript or C# support arrays or records, like pascal? Since i am not sure that we have figured out how to make >3D arrays (
), storing the "spans" in records seems pretty logical and efficient to me. Of course, not being restricted to how the VOXLAP engine works, this brings me to question the current file format - in my opinion, the amount of data stored in .vxl format files could be decreased by combining all of the color values (r,g,b,a) into one byte value, that would represent indexed colors - if Unity is used, there is no need for storing data for shading, and since very few maps are likely to use more than 256 colors in them, this seems perfectly reasonable to me. This would lead to file sizes 5/8 of the original, even less if any compression is used. The only downside i can see is incompatibility with the original .vxl maps, but this probably can be averted by creating a simple converter utility, that scraps the file of unneeded values and calculates the closest indexed color by inspecting the r,g,b parameters.
Of course, if i've picked the wrong .vxl specification, then none of this matters. Seriously, there's like 4 of those things floating around there.
Map synchronization.
Probably way too early to talk about this, but i was wondering about how one could synchronize maps like this across the network.
What i have come up with is that the host sends the players .vxl files for the initial map, which can then be saved on the hard drive for later use (saving bandwidth, the name of the file might be its hash value or something), and while in-game the server could create a queue of operations done on the map - whenever a voxel is created or destroyed, an event would be added to this, then, after a certain amount of changes, a new .vxl might be generated - one of all the changes, after the creation of which the queue would be reset. When a new player would connect, they would receive the latest .vxl file, as well as the current queue, which would be applied on top of the .vxl.
Alternatively, instead of a full .vxl file, one that only contains the changes compared to the starting map file could be made, say, one that would overwrite values in the .vxl, although this would require a new format and probably is never happening.
- - -
Will try to make a program that first converts the .vxl file into a plaintext one in pascal tomorrow, and perhaps look for a simple way to fill an array from the file in Unity. No promises, just making a list of what i would like to do.
Also, does anyone have any idea where i could find a decent example of runtime culling in Unity? Perhaps there's any recommended techniques for voxels in general?
Lastly, what are your thoughts on the 128 block draw distance in BnS?
