Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

Surface Extraction Development <- All Coders Apply here
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=310		 Page 1 of 1
Author:  DJDD [ Mon Jan 09, 2012 5:30 am ]
Post subject:  Surface Extraction Development <- All Coders Apply here
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.
Author:  ker [ Mon Jan 09, 2012 8:26 am ]
Post subject:  Re: Changes to basic voxel types
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

DJDD wrote:
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.


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.
Author:  DJDD [ Mon Jan 09, 2012 8:41 am ]
Post subject:  Re: Changes to basic voxel types
ker wrote:
DJDD wrote:
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.


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.
Author:  ker [ Mon Jan 09, 2012 10:01 am ]
Post subject:  Re: Changes to basic voxel types
DJDD wrote:
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
Code:
float fInterp = static_cast<float>(VoxelType::getThreshold() - v000.getDensity()) / static_cast<float>(v100.getDensity() - v000.getDensity());

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
Code:
fInterp = static_cast<float>(VoxelType::getThreshold() - v000.getDensity()) / static_cast<float>(VoxelType::getMinDensity()- v000.getDensity());

else compute like usual.

it would not be perfect, but close enough as a start.
Author:  DJDD [ Mon Jan 09, 2012 12:12 pm ]
Post subject:  Re: Changes to basic voxel types
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.
Author:  David Williams [ Tue Jan 10, 2012 2:09 pm ]
Post subject:  Re: Castle Story style surface extraction
ker wrote:
EDIT:
if i see it correctly, the line
Code:
float fInterp = static_cast<float>(VoxelType::getThreshold() - v000.getDensity()) / static_cast<float>(v100.getDensity() - v000.getDensity());

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
Code:
fInterp = static_cast<float>(VoxelType::getThreshold() - v000.getDensity()) / static_cast<float>(VoxelType::getMinDensity()- v000.getDensity());

else compute like usual.


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.
Author:  ker [ Tue Jan 10, 2012 3:58 pm ]
Post subject:  Re: Castle Story style surface extraction
hmm... i'll simplify my idea to 2d to show what i mean.

this is how marching cubes does it:
Attachment:
File comment: regular marching cubes
test1.png
test1.png [ 3.29 KiB | Viewed 6158 times ]


this is what I think we want to achieve.
Attachment:
File comment: shifting the vertices
test2.png
test2.png [ 3.01 KiB | Viewed 6158 times ]


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"

DJDD wrote:
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.


do so, and add me (ker on gitorious). we can simply copy the BasicExample as it uses SurfaceExtractor
Author:  DJDD [ Wed Jan 11, 2012 3:37 am ]
Post subject:  Re: Castle Story style surface extraction
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.
Author:  David Williams [ Wed Jan 11, 2012 4:00 pm ]
Post subject:  Re: Castle Story style surface extraction
ker wrote:
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"


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.
Page 1 of 1 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/