so... entites will always just be a single voxel then? maybe 2 if it's aplayer ? so no making like a large animated dragon/samauri ICE? (intrusion countermeasure electronics from Shadowrun/Cyberpunk matrix)... hmm hard to show what I mean it's just a image in mind, and a rough search returns 0 results that are even similar... something like http://superdupergc.com/?p=221 ... but I guess other models don't have to be voxel based... kinda the inverse of robocraft, where landscape is just a mesh, and the entities are all voxel...
Yes you can animate large block structures in Blackvoxel
. A single MVI active voxel can animate a lot of voxels.
But, yes, that's not similar to games having entities whether these are vector or voxel entities.
The problem with entities is that they can't interact with the world the same way the voxel does.
So, that's a particular design choice in Blackvoxel to replace entities by true voxels.
That's what we mean by "pure voxel paradigm".
Of course, that choice mean Blackvoxel can't do what a lot of voxel gamesdoes with entities.
But it also mean we can do some things other games can't.
That's what we can call a choice
.
I take this opportunity to say that Black Ice get out a long time after Blackvoxel.
I'm not attempting to make it be something else... I'm just noting where others have already made some interesting mods.... and some of them would really be fairly easy to accomplish.
Was actually heading more towards making a micro scale world to represent the neural networks... which would be within a robot cube for instance. ... and although it doesn't really need a orientation, it would be useful to add an offset-origin to it; and might as well just add orientation while at it.
Why not creating an abstraction with an "ai" robot that will scan a portion of world where you create your design and copy it internally for execution?
You keep speaking of this 'road map' but I didn't see it.... may be I didn't look hard enough, but in the early beginning was looking for such information...
So, lets explain what's is our vision and roadmap.
Blackvoxel started in 2010. Engine and all parts around take a big amountof time. After two years, we froze engine capabilities, developed content and stabilized the whole stuff.
Since Blackvoxel has enough content to be played, we completely got out of alpha and beta state and entered in full stable state. Blackvoxel is now stable since a while.
This state won't mean development stopped, but rather that stability became a strong priority over new engine features. When users have some issues, we try to do our best to quickly fix them. The more stable it is, the less time it take to make support over developing time.
Now, our roadmap is focused on game content, educational materials and other kind of stuff around the game. Game contents like new voxels, automatics, robots, zones, etc, are now the main priority of the project. Doing things differently would be very difficult.
At this time, making engine evolution is not a priority: it's working very well. It's stable, it's fast. And there is now a lot to do with stuff it does. (We know there is some cleaning to do in it. We'll try to do our best in the time.)
So we'll try to minimize changes on it to keep stability, but also for best usage of our limited resources: it would be nonsense to have a wonderful engine with no game and no content.
That won't mean that we'll do no evolutions on the engine. But rather that evolution will be well planned in long term evolutions with careful changes to avoid stability problems.
Of course we can decide to change this if one day we found it's interest of the project.
But for now, there is a lot of things to do with what we have already.
I also played with 'Seed of Andromeda' which has a good approach for modelling full dynamic planets, also with a sub-meter voxel.... They have no smoothing, and I inquired, and they said 'it's an artistic choice we make to set ourselves apart' ... looks more to me like it's a choice that makes them like everyone else... it's more rare to have smoothing than to have minecraft cube model.... but they do have cute explosions when voxels are removed... with persistant particles such that they can be picked up later... or you can break a dirt block and get gems out or something based on sub-portions of the material being able to be different result types. They also didn't think neural networks would be within their scope either... even within the scope of supporting as a external Mod; even though the creator's like 'allow modders to do anything they want'... *shrug* Or better to have dynamic choice on whether a voxel is smoothed (can use a single bit in the 16 for
VoxelType for instance, and still leave 32000 types of cubes ) ... and iterating up the relations, smoothing per voxel-sector, smoothing per world... (landscape and constructions based on top of it being separate worlds, within the same universe).
In fact, voxels are very old concept. We found early kinds of voxel game at the early 80. Even smoothed voxel are old : marching cube patent was published in 1985. If you want to see a Minecraft looking game that have more than 15 years old, TurboLode, it's
here.
Voxel game where 3D evolutions of 2D tiled games. But the vector game fashion lead to forgot them for a long time. That wasn't the only reason: voxels are memory hungry.
But with modern hardware and it's huge memory along with vector game boring, that was only a question of time for voxel game to come back.
We can understand why some creators prefer to use non smoothed voxels.
Smoothed voxels can get more visual friendly on engine that are focused on this.
In other hand, non smoothed voxels are far better for manipulation because they are clearly distinctive.
So what will be choosed in a game could depend on what it's creator want to do.
There is a lot of original things to do, even with unsmoothed voxels. The concept is far less used than vector game concepts or 2D game "revivals" a lot of creator are using.
Could resolve collisions by using a robust physics library like Bullet,ODE, Newton, etc...
I'm afraid with voxels things are never as simple as gluing pieces of code.
I mean, that could be simple to say and to imagine. But things are never never getting as simple in the reality as in theory.
Even in cases where making proofs of concepts take only days, resolving side effects could take weeks, making things well polished could take months. And making content working well with this could take years.
Sometimes, things are simple, but I'm afraid it is not the case of this.
There was another article I was reading on voxel engines in general, about optimizations and cullings... and like for the surface of things, doing combining of continuous areas... so basically the central zone would result in drawing one plane with repeated textures instead of X flat planes of the tops each cube.... which then begins to lose effectiveness on the light blue height-map area with individual arbitrary spires.
This is an interesting case illustrating the feature exclusion problem we were talking on above posts.
In one word, this method means adding an extra step to connect polygons to make larger ones.
The optimisation will be reducing polygon count and GPU load in exchange of more CPU load before compiling lists.
In Blackvoxel, the GPU polygon count is rarely a problem even on little machines. Execution of display lists are blazing fast.
The problem is the CPU load while refreshing a display list. And this method will increase the problem. And particularly with Blackvoxel because it's increased needs of frequent refresh.
So, this method is well suited for games that won't refresh too often the sectors.
Now, let's modifying some parameters. Let's decrease voxel size by 4 with the same visual limit (so increased number of sectors). The number of polygon will explode and become a true problem.
That's mean an engine aiming to use little voxels need to use this kind of method.
But that's also mean it will be technically difficult to combine little voxels with MVI even if we don't count the exploding load on MVI itself.
So, that's explain why game choices condition others ones.
Because they are far more resource hungry than vector game engines, voxel engines will remain fragmented for a long time. So a lot of good different games rather than a "perfect one".
But some things can just be simply boxed with a collision box instead of being voxel-perfect collisions between arbitrarily mixed sized voxel entitites.
That could be acceptable for an entity character. But not for a spacecraft.
The Blackvoxel Team
