Ogres Volume Component

[xelon]

Sorry if I'm bumping this thread, but did anyone manage to get paging working?
I'm tempted to get started on it, and I want to make sure that no one has done it so far.

[holocronweaver]

Yes, I implemented octree-based paging at the voxel and mesh levels in December last year. Right now I am working my rear off to graduate on time and finish my game, but hopefully in the next month or so I can push it (along with a bunch of other work) to my GL3+ repo.

BTW, if you are curious about performance, I found that for geometries with high frequency details DMC outperforms MC since DMC creates more reasonable meshes at lower grid spacing. This is due to DMC using feature isolation, something MC does not do. Thus you generally don't have to use as many LOD levels with DMC. DMC also produces fewer triangles, so usually mesh decimation is not necessary, which can really push MC octrees over DMC octrees in total pipeline computation time.

EDIT: Hm, after a bit of thought I decided I will put my game on hold for a few days so I can get back in sync with OGRE upstream. I will post here when I have pushed my changes.

[xelon]

Yes, I implemented octree-based paging at the voxel and mesh levels in December last year. Right now I am working my rear off to graduate on time and finish my game, but hopefully in the next month or so I can push it (along with a bunch of other work) to my GL3+ repo.

BTW, if you are curious about performance, I found that for geometries with high frequency details DMC outperforms MC since DMC creates more reasonable meshes at lower grid spacing. This is due to DMC using feature isolation, something MC does not do. Thus you generally don't have to use as many LOD levels with DMC. DMC also produces fewer triangles, so usually mesh decimation is not necessary, which can really push MC octrees over DMC octrees in total pipeline computation time.

EDIT: Hm, after a bit of thought I decided I will put my game on hold for a few days so I can get back in sync with OGRE upstream. I will post here when I have pushed my changes.

That is amazing to hear, I always wanted to switch from MC to DMC for better performance and more view distance. Thanks for your efforts.

[PhilipLB]

Wow, great to see. Even if I've been too passive about this project in the last months, it still means a lot to me and I actually want to continue it of course:

• Does it work with Ogre 1.10? If not, I want to make it work.
• Same with Ogre 2.0 and 2.1
• There is a hack/magic number inside scaling the voxeldata by about 1.5. I never could explain that number but I later found out that it was due to the export of Acropora. Might be a bug in the software or a misconfiguration when creating the terrain. This factor has to move to a configuration file.

[xelon]

Wow, great to see. Even if I've been too passive about this project in the last months, it still means a lot to me and I actually want to continue it of course:

• Does it work with Ogre 1.10? If not, I want to make it work.
• Same with Ogre 2.0 and 2.1
• There is a hack/magic number inside scaling the voxeldata by about 1.5. I never could explain that number but I later found out that it was due to the export of Acropora. Might be a bug in the software or a misconfiguration when creating the terrain. This factor has to move to a configuration file.

Glad to see you are getting back to it philipLB, did you manage to get shootRay working with sources other than texturesource? Using CSGNoiseSource would crash on this line

Code: Select all

 bool intersects = mVolumeRoot->getChunkParameters()->src->getFirstRayIntersection(ray, intersection, scale);

[PhilipLB]

Ou, of course it shouldn't crash, will investigate.

[holocronweaver]

Quite a bit delayed, but I plan to merge in my octree pager during October. See this post for context and timetable.

[Plutoman101]

I had a couple questions! I wasn't exactly sure where to ask them, so I'll put them here. If I say, use your code, but fully ported to C# in another engine, can I use it in a commercial project without having to add the MIT license to the rest of my codebase? Obviously, I can keep it on the ported versions of your code, but I wanted to be sure. I didn't exactly want to put my entire project under the MIT license just to use it. I didn't think so, but I wanted to double check.

The second thing is that I implemented paging into my own software; and to be frank, the simplest way for me to implement paging was to generate the octrees into a cached dictionary map for various points - and if I wanted to generate the rest, octree => dual grid => mesh, I would have to have the neighboring octrees, 7 of them in particular (above, back, side, and the diagonals for each). Each one would run a secondary generation between those 8 octrees, just as it does internally. It would create the seams from the original.

Taking your graphic, if I wanted the mesh for #3 => http://www.volume-gfx.com/wp-content/up ... bering.png I would generate the octrees for the neighboring ones first, and then cache them. Each would generate the seams for those edges, and as you propagate, all seams are handled. This can be done at any LOD level, in addition, regardless of how they are paged. When you want to generate the next one, it would already be created, and it would create it's own missing octrees if needed, too.

Discard the cache as you go, and it works fine. This does add dependencies between them, but is extremely effective in reducing the size of the global chunktree without complicating the code-base and allowing for infinite worlds without needing a global chunktree of 'infinite size'.

Anyways. Besides that, I love the project! It's been amazingly effective. I've implemented a unique way to generate using function nodes of signed distance functions, and a plotting that generates and adds function nodes to the level, which is then split into the octree and turned into meshes, before we place geometry. The code is well written and ported so easily compared to other projects I've tried to work with (I tried to port a k-dimensional interval tree from c++ - gave up).

[Daixiwen]

If I say, use your code, but fully ported to C# in another engine, can I use it in a commercial project without having to add the MIT license to the rest of my codebase? Obviously, I can keep it on the ported versions of your code, but I wanted to be sure. I didn't exactly want to put my entire project under the MIT license just to use it. I didn't think so, but I wanted to double check.

The MIT license is not viral so using this code doesn't force you to put your whole project under the MIT license. You'll just need to distribute the MIT license with your software (as part of the documentation for example)

[Plutoman101]

Great! Since I already ported the majority of the code involving the mesh generation. It works extremely well, and provides far more functionality and detail than Marching Cubes ever provided me.