Ogres Volume Component

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

Philip: How much progress have you made on paging? I just finished making a custom paging solution in PolyVox, so I might be able to help out there.
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Haven't even started yet. :(
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

Were you considering going the route of PolyVox::LargeVolume and creating a paged volume class that utilizes user defined region request and storage functions? See PolyVox docs for details. I like this method because it makes procedurally generating and saving extremely large voxel worlds fairly straightforward from a user perspective.
I will take a closer look at the Ogre volume component source code over the weekend and get back with you with an initial paging class design.
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Some thoughts about the paging:

1. The Chunktree needs not to load far away chunks. In the runtime, it also needs to load and unload single chunks as they come near or move away from the camera.

2. If you use discrete grids for the volume, you have to split the whole volume up into cubes of like 128^3 (or so, experience will show). This is, what basically LargeVolume does as far as I can see. Compression is already solved, see the serialize method of the Source class. A childclass of the GridSource class won't be that hard.

3. Always reading the raw volume data and creating a chunk from scratch via DMC might be too slow. So the paging would need some intermediate format like a serialization of the Dualgrid or the direct mesh. This could also be pregenerated if needed before you ship the application. The implementation of 1. and 2. will show, if this is needed at all.

When all 3 parts are implemented, the strategy of loading a chunk would be basically this: See, if the Dualgrid-/Mesh-serialization is available. If so, load it and triangulate. If not, load the mesh from the volume source. Unloading would be to serialize the Dualgrid or Mesh and then free all associated memory.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: Ogres Volume Component

Post by TheSHEEEP »

Whatever path you choose to take, this part will need a pretty exhaustive tutorial or example :D
My site! - Have a look :)
Also on Twitter - extra fluffy
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

And the Dual Marching Cubes part of the website is done. :)
http://www.volume-gfx.com/volume-render ... ing-cubes/
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: Ogres Volume Component

Post by TheSHEEEP »

You should have links in the single articles, right now the overview article (and the navigation on top) is the only way to go to the last/next article in the series :)

Btw. great articles, even I am able to understand them (well, most of it)!

How did you create those images (like the Octree one with the red & blue dots at the corners)? Is it a tool? I'd love to use it for images in my own articles :D
My site! - Have a look :)
Also on Twitter - extra fluffy
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Just like "Next" and "Previous" links at the top and bottom, that makes sense. :)

The images are done in Blender (schematic Octree), Gimp (for some adjustements like thickening lines), Inkscape (the 2D dualgrid for example) and screenshots (Red Octrees, Dualgrids, wireframes). The tree-structure of the schematic Octree is done with yed. I can send you the source files if you like.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

PhilipLB wrote:Some thoughts about the paging:

1. The Chunktree needs not to load far away chunks. In the runtime, it also needs to load and unload single chunks as they come near or move away from the camera.

2. If you use discrete grids for the volume, you have to split the whole volume up into cubes of like 128^3 (or so, experience will show). This is, what basically LargeVolume does as far as I can see. Compression is already solved, see the serialize method of the Source class. A childclass of the GridSource class won't be that hard.

3. Always reading the raw volume data and creating a chunk from scratch via DMC might be too slow. So the paging would need some intermediate format like a serialization of the Dualgrid or the direct mesh. This could also be pregenerated if needed before you ship the application. The implementation of 1. and 2. will show, if this is needed at all.

When all 3 parts are implemented, the strategy of loading a chunk would be basically this: See, if the Dualgrid-/Mesh-serialization is available. If so, load it and triangulate. If not, load the mesh from the volume source. Unloading would be to serialize the Dualgrid or Mesh and then free all associated memory.
I will take a crack at this on Friday and Saturday. I have my schedule cleared for the sole purpose. Wish me luck and expect questions. :)
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

Philip: Were you ever able to figure out the Ogre Paging component? Currently I am using my own paging scheme because without documentation or even source comments the Paging component seemed like too much work to decipher. However, I am starting to get the feeling I am reinventing the wheel and do not want to create code bloat and redundancy.

Since the Paging component appears abandoned I will soldier on unless I hear otherwise. I am trying to write my code so transitioning to someone else's paging system should not be too painful.
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Hi,

I haven't had a deeper look into it, but there is at least this topic: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=72637
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

An update on my progress:

Apparently the Paging component has plenty of documentation - I just happened to look at the few files that have little or none when taking a quick glance. :oops: The Paging component is well engineered and generic, being able to page essentially any piece of data that depends on camera position, not just terrain. It is sorely lacking a formal introduction, so I am writing a tutorial / manual entry so that future Paging users will not have to dig through the code and draw a diagram. Hopefully this will be the first of several manual entries for Ogre components to provide overviews of their architecture and feature sets.

My primary qualm with using the Paging component was adding a Ogre dependency to Volume component that could hinder it from becoming its own engine-independent library. Thankfully Paging is itself almost entirely independent from Ogre, so the whole thing (Volume + Paging components) could be separated into a new library with little difficulty.

Since the Paging component is well engineered and has few Ogre dependencies, I have begun converting my hacky custom paging solution to use OgreGrid3DPageStrategy. It breaks the volume into a 3D grid of chunks which can be loaded or saved to disk as needed while the camera moves about. This is similar to the approach taken for the Terrain component, except that the paging grid is in 3D instead of 2D to allow for paging of arbitrarily shaped volumes - such as voxel planets. :)

I am about 3/4 of the way done converting everything to use the Paging component, though it may be a couple weeks before I get to finish. I have a couple deadlines at work this week and I have some family related business to take care of on Saturday, so I am hoping this coming Sunday will see great strides.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: Ogres Volume Component

Post by TheSHEEEP »

Keep up the good work. You may have a potential user here ;)

Hopefully this weekend I will have time to start porting my small research on procedural terrain generation to the Volume Component (it is currently based on PolyVox, which is just too unstable - I get crashes constantly). If that works out well*, I will use it in my future project and for that, Paging is a must have feature :)

*If it doesn't I will meet Philip and poke him until it does ^^
My site! - Have a look :)
Also on Twitter - extra fluffy
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Sounds great. :) Is the paging of Volume Data fast enough? Because of the expensive creation of the DualGrid. Initially, I thought about using the DualGrid itself as paged data.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Managed again to spend some time on developing here:
  • Mouse behaviour while editing in the terrain sample extended to a painting-mode as long as the button is pressed.
  • Made a factor used for the octree splitting configurable for unusual density sources.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
xelon
Halfling
Posts: 91
Joined: Mon Jan 07, 2013 4:24 am
x 13

Re: Ogres Volume Component

Post by xelon »

Amazing work, I downloaded it and played a little bit with it and I must say its amazingly done. I have been working on a custom polyvox implementation on my engine and I think I will switch to this one once I get enough time to fully go through it's source code and structure. I did go through the source and the sample example a little bit and so far i must say its well written and easy to understand so good job. I have a couple of questions tho :)
Since I didn't really fully went through the source code yet, i came across a problem when I was experimenting with the sample example "VolumeTerrain". I changed the source to use the noisesource instead of the .dds file and it worked as expected, however when I tried to use the raycasting it crashed on this line

Code: Select all

bool intersects = mParameters.src->getFirstRayIntersection(ray, intersection, mVolumeRoot->getScale());
and specifically in the OgreVolumeSource here

Code: Select all

 Vector3 start = getIntersectionStart(scaledRay, maxDistance);
. I tried to do some debugging but I could not figure it out. Shouldn't the getFirstRayIntersection work on all the sources?
Ludoria now on Kickstarter! Ludoria is now on KickStarter! https://www.kickstarter.com/projects/17 ... g-rpg-game
Ludoria's official website http://www.Ludoria.com
On Facebook https://www.facebook.com/pages/Ludoria/644733108967479
On Twitter https://twitter.com/LudoriaGame
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Thanks a lot. :)

Could you provide the source you used so I can reproduce the crash?

//Edit:
Whereas... This whole concept of finding a decent startpoint of the ray is a bit whacky anyway. It has it's origins in the problem of the density grids, where the ray has to start within them. But what to do with combining CSG sources like union here? I have to think about something...
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
xelon
Halfling
Posts: 91
Joined: Mon Jan 07, 2013 4:24 am
x 13

Re: Ogres Volume Component

Post by xelon »

PhilipLB wrote:Thanks a lot. :)

Could you provide the source you used so I can reproduce the crash?
this is the part that I changed in the volumeterrain sample

Code: Select all

void Sample_VolumeTerrain::setupContent(void)
{
    setupControls();
	Real size = (Real)31.0;
    Vector3 to(size);
        
    // Skydome
    mSceneMgr->setSkyDome(true, "Examples/CloudySky", 5, 8);

    // Light
    Light* directionalLight0 = mSceneMgr->createLight("directionalLight0");
    directionalLight0->setType(Light::LT_DIRECTIONAL);
    directionalLight0->setDirection(Vector3((Real)1, (Real)-1, (Real)1));
    directionalLight0->setDiffuseColour((Real)1, (Real)0.98, (Real)0.73);
    directionalLight0->setSpecularColour((Real)0.1, (Real)0.1, (Real)0.1);

	 // A plane with noise
    CSGPlaneSource plane1((Real)10.0, Vector3::UNIT_Y);
	Source *source;
    Real frequencies[] = {(Real)1.01, (Real)0.48};
    Real amplitudes[] = {(Real)0.25, (Real)0.5};
    CSGNoiseSource noise1(&plane1, frequencies, amplitudes, 2, 100);
	
   
    // Volume
    mVolumeRoot = OGRE_NEW Chunk();
    mVolumeRootNode = mSceneMgr->getRootSceneNode()->createChildSceneNode("VolumeParent");
	source = &noise1;
	//mParameters = mVolumeRoot->load(mVolumeRootNode, mSceneMgr, "volumeTerrain.cfg", &source);
	mParameters.sceneManager = mSceneMgr;
    mParameters.src = source;
	mParameters.baseError = (Real)1.8;
	mParameters.errorMultiplicator = 0.9;
	mParameters.maxScreenSpaceError = 20;
	mParameters.skirtFactor = 1.0;
	mParameters.scale = 10.0f;
	mParameters.createGeometryFromLevel = 3;
	mVolumeRoot->load(mVolumeRootNode, Vector3::ZERO, Vector3(256,256,256), 5, &mParameters);
    
    // Camera
    mCamera->setPosition((Real)(2560 - 384), (Real)2000, (Real)(2560 - 384));
    mCamera->lookAt((Real)0, (Real)100, (Real)0);
    mCamera->setNearClipDistance((Real)0.5);

}
and I use the same shootRay function.
I feel like it has something to do the volume scale, because I saw strange values when debugging.

Edit:
ok it seems i solved that problem, I had to use the first constructor of the load function because it assigned the lod callback functions and the rest of the parameters correctly, I had to do a minor change to it tho so it does not load the texture file directly but instead use my noise source. however It seems that the combineWithSource function only works with the GridSource and the TextureSource, if I want to use it with the noisesource I guess I need to implement that separately or maybe I'm wrong. Anyway I will keep looking into this. :)
Last edited by xelon on Mon May 06, 2013 3:40 am, edited 3 times in total.
Ludoria now on Kickstarter! Ludoria is now on KickStarter! https://www.kickstarter.com/projects/17 ... g-rpg-game
Ludoria's official website http://www.Ludoria.com
On Facebook https://www.facebook.com/pages/Ludoria/644733108967479
On Twitter https://twitter.com/LudoriaGame
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

Another quick progress update on the paging system.

I have finished porting my old code to use the Paging component, including using Ogre's WorkQueue for threading, and am in the process of fixing compiling errors and testing. Once that is done (hopefully before Friday) I will set up a bitbucket repo so anyone interested can take a look.
PhilipLB wrote:Sounds great. :) Is the paging of Volume Data fast enough? Because of the expensive creation of the DualGrid. Initially, I thought about using the DualGrid itself as paged data.
Based on my prior threaded custom solution, yes, paging volume data is fast enough! Initial surface extraction requires about 3 or 4 seconds of loading prior to seeing something on the screen. Past that, I was able to meander across an endless CSGPlaneSource without a hiccup, even at somewhat fast movement speeds. I am running an Intel i5-2500k processor, which is a good middle-of-the-road processor so this seems reasonably fast. Hopefully it will remain fast using the Paging component and WorkQueue.

I am curious how well this will scale for large regions with LOD. Is LOD considered during surface extraction so that you can extract extremely large distant regions? If not, would this be easy to implement?
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

@Philip: How is threading meant to work in the Volume component? From what I see in Volume::Chunk, a load() creates worker threads and waits on them to finish before returning. This causes the main thread to stall while it waits on the worker threads. This is fine if a single load will be performed during initialization, but paging requires that loads not stall the main thread and that several loads be allowed to occur simultaneously. If I understand correctly, doing this would require modification to Volume::Chunk. While using PolyVox::LargeVolume I solved this problem by performing surface extraction in a separate thread, but finishing my ManualObject in the main thread so that the graphics API calls happen there (where they should).

This leads me to my next question. Currently I am paging Volume::Chunk as my basic volume data structure so that I have an array of Chunks. Is this what you had in mind, or should I be paging data from a lower or higher level somehow? It is not clear to me how to go to a lower level without accessing protected member data, which implies creating a child or friend class of Chunk, which I assume you would prefer not to do. Please correct me if I am mistaken.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Ogres Volume Component

Post by Zonder »

I would suggest adding a LoadAsync method as well as load, you would expect load to have completed on return I think. LoadAsync of course firing load on a separate thread then performing a calling back when completed
There are 10 types of people in the world: Those who understand binary, and those who don't...
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogres Volume Component

Post by PhilipLB »

Hi,

you are right with your assumptions about the threaded loading. I'll implement the optional asynch way with a callback in the next days, makes totally sense. :)

All LOD-Levels are created in this process, see http://www.volume-gfx.com/volume-render ... chunktree/ . I'd keep this datastructure and add a loaded/unloaded stage for the chunks. Unload a chunk when it is far away, load it, when it comes nearer.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

All LOD-Levels are created in this process, see http://www.volume-gfx.com/volume-render ... chunktree/ . I'd keep this datastructure and add a loaded/unloaded stage for the chunks. Unload a chunk when it is far away, load it, when it comes nearer.
I could take this to mean several different approaches:
  • Divide space up into a grid, each cube in the grid being a different Chunktree (i.e., Volume::Chunk object). This way there are many Volume::Chunk root objects, each for a different region of space. This is what I currently do.
  • Use a single Chunktree and swap it out for a new Chunktree covering a different region whenever the player moves too far from the center of the current Chunktree. This way there is only one Chunktree ever visible, but new Chunktrees are being generated in the background to replace it as the player moves around.
  • Do all paging within a single stationary Chunktree, where the whole volume is rendered at LOD level 1 and higher level LOD is loaded and unloaded as the player moves around. To my understanding this would disallow infinite volumes unless the root of the octree can be extended and/or multiple octrees joined.
Two problems arise from these approaches.

# The seams between meshes of neighboring octrees is very noticeable due to how Marching Cubes handles edges. This could be solved by only using a single Chunktree, as mentioned above, though I am not sure how to handle it using multiple Chunktrees as I currently do.

# The other problem is probably more difficult to tackle and involves rendering extremely large volumes from a distance. For instance, if I am on Earth and looking up at a voxel Moon, I should be able to see the whole moon at a really low level of detail. However, since I am far away from the Moon the paging system will not load any of its Chunktrees, so I would not see it in the sky.
One way I thought to get around this is to include the entire Moon in a single Chunktree and never page out LOD level 1, very similar to the last approach I mentioned above. This would require paging higher LOD as I get closer to the moon. In other words, paging and dynamic LOD creation would have to occur within the Chunktree itself, necessitating paging system-related methods be implemented within Volume::Chunk.
The other option is to make the loaded region size depend on the distance from the Moon. When you are close to the Moon, only a small region is loaded, but when you are far from the Moon the whole lunar body is loaded. This would require that LOD be on demand within a Chunktree, rather than generating all LOD levels upfront when a Chunktree is loaded.

No matter how I look at it, Volume::Chunk would need to be modified to allow greater control over when LOD levels are extracted.

Personally, both of these problems are important for my practical use of the Volume component, though the first is the most important.

Edit: I have updated this post to make it more clear and precise.
Last edited by holocronweaver on Sat May 11, 2013 3:01 pm, edited 3 times in total.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

After some thought, I think a variation on the third option is what Philip intends. I will detail my thinking when I get some time in a few hours.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogres Volume Component

Post by holocronweaver »

My idea is a blend of the second and third options and I believe is what Philip has been suggesting all along.

Use a single Volume::Chunk root object to represent a cubic region with the player always at the center. When the player moves too far from the center of the current region, the region is moved to keep the player near the center. Chunks at the top of the Chunktree which are no longer in the current region are paged out and new chunks are paged in to take their place.

This eliminates the first problem I mentioned (since there is only a single Chunktree) and could potentially solve the second. To solve the second problem, the size of the loaded region increases as the player moves away from the Moon while simultaneously the maximum LOD decreases. When the player is far away from the Moon, the whole body would be loaded at a very low LOD. This requires two changes: 1) dynamic control of maximum LOD by implementing a setMaxLOD() method and 2) allowing extremely coarse grained LOD levels to handle huge volume regions. From looking at the code I do not think (1) should be very difficult, but (2) may be a little more challenging. I do not see any reason both could not be implemented though.

I am going to think about it some more tonight, then tomorrow I will begin working on the above approach. If anyone objects or has a better idea, I am all ears. :)

Edit
This is the algorithm I am considering.
  • A single cubic Chunktree (Volume::Chunk) is centered on the player.
  • The player begins to move away from the center of the cube.
  • (optional step) If necessary, the cube is resized and the sampling coarseness is adjusted (via baseError and errorMultiplicator). For example, increasing the cube size and coarseness as the player moves away from the origin of the volume.
  • The cube is moved to recenter on the player by paging the appropriate children of the Chunktree root.
    1. Chunks which are no longer needed are stored in a buffer queue of finite length. When the buffer reaches maximum capacity, the front is popped and paged out (i.e., volume data is permanently stored using the Volume::Source) to make room.
    2. Chunks which are needed are paged in (i.e., volume data is either obtained from the buffer or Volume::Source).
  • The surface mesh of the newly positioned cubic Chunktree is extracted. (When possible, reuse previously extracted triangles unless the chunk volume data has been modified.)
Edit2
Just to be clear, this approach DOES require either modification to the Volume::Chunk or a derived child class. If I don't hear back from anyone, I will start off by creating a derived class (Volume::PagedChunk) and can merge the changes into Volume::Chunk if desired.
Post Reply