Note: Split from here: http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=306

I'm not proficient enough at programming to comment on the core changes you're proposing, but its good to see you're continuing to perform improvements where you see them.

I'd just like to add that I'd really like to see some more end-user convenience functions. Stuff like more complex surface extractors. The latest example being one briefly discussed in another thread - Being able to perform extractions in such a way that one can get a smooth terrain surface, but hard cubic walls. Or smooth walls and floors, but lock the corner verts so it keeps its shape (Eg cliff corners are hard, but cliff wall and adjoining floor are smooth).
Whether that is done as one extraction or you give the user the ability to choose to extract only voxels with a up-facing normal (floor), etc.

david/matt can you cut this off to another thread, I don't want to start a new one and leave the beginning post trailing in here



About that.
Tom (foreverwar) was thinking about exactly this problem once the Smooth Surface extractor was working. I do not remember if he ever got anywhere with this.

anyway, it might be possible if a 2nd threshold is added, above which the Surface is done Cubic.
or simply do this for density==max, since there are no different states of "cubicity"

Since all Voxels around such a cubic Voxel would see that voxel, the SurfaceExtractor could make sure that the Mesh will still lign up.

It could be that I'm not fully understanding you here, but wouldn't that leave out corner cases where a single voxel might be both smooth and hard? For example, a voxel sitting on the edge of a cliff will be smooth on its top face whilst being hard everywhere else.
EDIT: I just had a thought that this might not be an issue - A voxel sitting on the corner of a cliff would then become a 'bevelled' voxel - The transition voxel between the smooth and hard faces.

To extend that, you'd also have to think about the difference between a cliff and a mound. A cliff would be say a wall >= 2 voxels high, whereas a voxel sitting alone above an otherwise flat area would be a mound. How would you represent this? Can you represent this at all? Maybe this sort of logic must come as part of customization conditionals written as part of the extraction.

actually you won't differentiate at all. everything in marching cubes works on a voxel and it's direct surroundings.
in SurfaceExtractor.inl:429-507 you see the part that creates the vertices.
Basically it should be enough to check whether one of the voxels has "cubic-density" and if it does do a custom vertex positioning.
as long as you create a vertex wherever marching cubes would create a vertex, it should nicely match up with the index creation part.
It might just work and not be a riddiculous amount of work

EDIT:
if i see it correctly, the line

and it's y/z counterparts are what would do the magic...
if the density of the v100 is max density, all you do is set fInterp to

else compute like usual.

it would not be perfect, but close enough as a start.

Hrm. You know. We should really setup a git-clone and kick it off or something. Get a basic ogre demo going and code up some extractors.

In priciple something like this is possible. The interpolation is performed seperately along each of the three main axes, so it should be quite easy to disable it on two of the axes while leaving it active on the third. This wouldn't give you cubic+smooth terrain (like castle story) but it would give you a combination of angular+smooth.

Rather than completely disabling the interpolation on one axis, you could instead use the surface normal to 'weight' the amount of interpolation that is performed. In this way surface pointing upwards could be smoothed more.

But I think to get real cubes+smooth (like castle story) you probably will want a custom extractor rather than basing it off the Marching Cubes one.

hmm... i'll simplify my idea to 2d to show what i mean.

this is how marching cubes does it:


this is what I think we want to achieve.


this way smooth terrain would continue towards the wall and hit it, then go straight up.

the same voxels are queried for density as in marching cubes, just the vertex placement depends on whether this or the next voxel is "blocky"



do so, and add me (ker on gitorious). we can simply copy the BasicExample as it uses SurfaceExtractor

Ker - I've cloned PolyVox into PolyVox-Extractor-Dev and added yourself. I'm at work so I haven't done anything more. I'll look at getting a basic Ogre demo going, unless you have code handy.

So do you imagine operating on a pure density volume here, or will you also use some other attribute?

The idea is interesting, but I find it hard to imagine if it will really work. But do some experiments and see what you can come up with

Also, be aware of a subtle difference between the way the smooth vs cubic extractors work. The smooth extractor works on 'cells', where a cell is a group of eight voxels. Generated triangles are (at lest conceptually) associated with a cell rather than a particular voxel. But the cubic surface extractor is different in that it really operates on voxels, and the triangle are conceptually assosiated with these. Maybe there is no issue here... but just keep it in mind.