Hello, I have some questions:
1. Is there some "voxelizer" programm or algorithm to convert models from 3D model to voxel model?
2. What technology give best performance for render voxels ( raycasting,marching cubes,shaders,using gpu or cpu?)
how many voxels can be in scene for modern PC?(for example voxels can have different colors and there some lightning in scene).
can I draw some big model and when clear scene and draw another big model enough fast for doing some kind of animation?
3. what if not to draw voxels, but to get visible envelope of voxels as 3D vertex model and draw it as usual in OpenGl?

1)Check out: http://www.cs.princeton.edu/~min/binvox/
2)The number of voxels in a scene depends greatly on your requirements and use. Practically infinite.
In regards with the animation, I doubt that marching cubes would be fast enough to animate something (and storing that animation as voxel data could become problematic ) But your requirements are too vague to truly give you an accurate answer.
3)That is exactly what marching cubes is doing. (If I understand your question correctly.)

If you're a begginer at this, I strongly suggest playing around with ogre and polyvox, just to get a feel for how things work. Then you can ask yourself these questions again.

I think marching cubes extract something like smoothed surface, but I need "corrugated envelope"
in other words I want to see "pixelized" surface not smoothed.
maybe i can just modify algorithm?

And closer to practice:
1.How to store the voxels?
simplest 3-dim array which contatin 0 if no voxel and 1 if have one.(harder other structures like SVO).
or 3-dim array of structures which contain not only visibility of voxel but it's color and maybe some other properties.
1 model - 1 3-dim array, further we can put this model in any point of our scene.
2.Ok, have aray of models(made of voxels) or 1 big model, then we want to extract surface by apllying something like marching cubes algorithm.
how this surface must be described to draw with OpenGl(or something else)?
array of triangles which consist of 3 points in 3D?
I must extract all surface and than cut of with something like frustum culling or I can do it somehow beforehand?
3.Ok, step 3, we have a surface,but how it must be stored and represented and how to draw it?



and about animation if we have animated 3D model can we convert it on the fly to voxel representation at each frame?
or just have prebuild N voxel models and change them at each frame?

and where I can read how PolyVox and Ogre works(in general not in particular) ?

I'm brand new to PolyVox myself, so you shouldn't take my word as gospel, but maybe I can help steer you towards a couple of answers...

I think you are correct about Marching Cubes being used to extract smooth surfaces. I imagine that the algorithm could be modified without doing a total re-write. But first, I would check out PolyVox::CubicSurfaceExtractor (or it's cousin, CubicSufraceExtractorWithNormals). I haven't read through the code yet, but the name sure sounds promising.

As to your question on how to store voxels: I just got done reading through an article written by one of the developers here: http://books.google.com/books?id=WNfD2u ... &q&f=false

This article is a great starting point for learning the underlying concepts and terminology of PolyVox. Of particular relevance to your question are the concepts of blocks and regions-- the former optimized around memory/caching/storage considerations, and the latter optimized with regards to surface extraction. But rather than try to summarize the article here with my own poor translation, I'd just recommend that you read the real deal.

Your other questions are way beyond my understanding right now, sorry! I'm still trying to grok everything from the introductory article and follow up on the references.

Good luck!

-DM

PolyVox includes both a Marching Cubes (smooth) surface extractor and also a 'cubic' surface extractor. The CubicSurfacExtractor behaves as you describe.



PolyVox provides both a simple 3D array (RawVolume) and also more advanced approaches including compression and paging (LargeVolume). In theory you can have several volumes in a scene but I've only ever worked with one large volume.



The mesh data is output as an indexed triangle list. That is, there is a list of vertices and a list of indices. Each set of three indices denotes the vertices of one triangle.



You can choose to generate a mesh for only part of the volume. So you can generate several meshes which touch but don't overlap, and then you can use occlusion culling techniques to decide which meshes to draw for a given viewpoint.



You can draw it with any API/engine which supports indexed triangle lists. This includes both OpenGL and Direct3D, as well as higher level engines such as Ogre. You could also convert the mesh to a different format if you needed to.



I don't have much experience here but I think you'll have difficulty doing the voxelization on the fly. It's not impossible though - NVidia have an article where they do it for fluid simulation (but on quite a small volume).



Have a read of this article, which was based on PolyVox. For Ogre you need to check out their webpage.

A question occurred to me as I read this. In the case of multiple touching meshes generated from the same volume do you guarantee that the touching vertices will always be the same?

As I'm sure you're aware if they are not this can cause rendering engines to have tiny but visible gaps in the scenery.

I'm pretty sure that the vertices should always line up as long as you're sticking to the same extraction algorithm for the whole volume and are vigilant about updating the correct regions as they are altered. Regions should be chosen so that they are adjacent, but need not be overlapping for Marching Cubes. As long as they are adjacent, they are sort of implicitly overlapping at the voxel-level, though Marching Cubes isn't really concerned with this and operates on cells, or groups of 8 adjacent voxels. See section 3.4 of David's article.

For the Cubic surface extractor... I'm not entirely sure how that works yet, but it looks like it operates on voxels rather than cells. So, in this case, it might not have the same kind of 'implicit overlapping" that Marching Cubes does, but if you're extracting a blocky/cube mesh with harsh edges anyway, then it seems like seams between regions won't be noticeable or distinguishable... or maybe a better way of putting it is that, the resulting visual should be independent of how chose your regions.

Where things get dicey is if you're trying to implement a Level of Detail system. There's an interesting discussion of this topic here. There are a lot of different ways to handle LOD, but I'm not really sure about the pros and cons of them yet. I suppose it would depend on your application.

Thanks, very interesting article and pretty easy to understand.

Before I start using voxel library, I want to ask one more question,
if i want to render changeble mesh(or scene).
for axample if I have cubic mesh("voxel style"), I cast a ray from center of screen
and get polygon that was first hit, then I perform substruction of 1 "voxel" or for example substrcuction of some "cubic" shape.(the smallest feature that I need add or substruct 1 "voxel" from the point where ray hit)
the question actually is why I can't only change mesh and then redraw mesh(scene)?
why I can't use just vertex mesh instead of voxels+ marching cubes?

I read some articles about CSG(for perform some shape operation like substruction) but it seems more complicated than I need. I just want to use "cubic" voxel like meshes, and operations like ADD, OR, XOR on them is "discrete"(no rounding errors on floating digits and so on).

This is a good question. Classic CSG is indeed complex, though it has been possible in real time for quite a while (as shown by Red Faction - awesome game engine). But you're basically proposing using CSG and constraining it to cube based meshes to make it simpler and more robust. I am not aware of anyone who has tried this but it's an interesting idea.

There are other advantages to the voxel represention though, in particular collision detection and picking are much easier.

why can't you? if I understand correctly your question, using Ogre you can edit any mesh, vertex per vertex if you want. sounds tricky, but not impossible.

If I understand, what you should do (in ogre) is :
0) setting the rules for AND, OR, XOR, WHATEVER (Maybe dev people of Blender3D can be helpful for that)
1) getting voxel datas
2) generating a first mesh (manualobject)
3) generating a second mesh (manualobject)
4) then using AND, OR,... on the meshs (edit manualobject)
4.1) building the solution in a third mesh
4.2) deleting the old meshes


but


and in CSG you will probably be forced to remesh everytime the whole mesh if you want to avoid useless faces.
something come to my mind, if I'm not wrong, numbers of vertex AND polygons aren't the most important but numbers of faces are at your screen, so if you consider having two cubes (one polygon or two, the last sound more easy to implement) glued one to each other you can maybe just turning off the glued faces.

anyway, using voxel + marching cubes seems the most interesting for what you want. (If I understood correctly)