Ogres Volume Component

[PhilipLB]

Hi,

after the Volume GSoC project, I'd like to use the showcase forum for showing the ongoing development of this component.

First, I show what's done and what the next plans are and I'll add answers to this thread with changelogs now and then. I don't expect real big new features until the 6th of November as this is the deadline of my Masterthesis.

Current State
-------------------------------

A dense list of the features:

• Volume Rendering via Dual Marching Cubes
• LOD mechanism via a chunk tree and marching squares skirts for crack patching
• Data-Sources: 3D Textures with density values and the ability to buildup a CSG-Tree with 3D Textures, Spheres, Cubes, Planes, Intersection, Union, Difference and Negation, SimplexNoise addition
• Loading a 3D Texture Scene from config files
• A triplanar texturing example material
• Small bonus: A triplanar texturing SubRenderState for the RTSS

[youtube]eseI2LmXBx0[/youtube]

What's Next?
-------------------------------

There are of course a gazillion ways to improve the project. This wiki-entry states some rough plans: http://www.ogre3d.org/tikiwiki/tiki-ind ... lumeFuture

[Nauk]

I have been following your project since quite a while, really impressive work! Congratulations on finishing it I would love to integrate it into the next version Artifex with the hope to figure out a way to edit it.

[TheSHEEEP]

Awesome work, indeed

Personally, I'd vote for giving paging a higher priority. Mostly because paging terrain is really lacking in Ogre, there is one, but it is limited (only height maps, no overhang/caves).
And a height map only terrain IMO always feels lacking something, especially in bigger worlds.

[PhilipLB]

The idea of putting paging at the last place was actually, that everything in front of it still belongs to the foundation. What use is paging, when there is no decent source for the volume data? Wheras I'd concentrate on the editing rather than more procedural sources. They are nice and easy to implement when you have a function like f(x, y, z) = 0. And Marching Cubes 33 could solve some problems. If MC33 works out, the actual generation of triangles could be superiour to C4 and Polyvoxel.

[Jabberwocky]

Very impressive and very cool.
Congrats and thank you, PhilipLB!

[Nauk]

The idea of putting paging at the last place was actually, that everything in front of it still belongs to the foundation. What use is paging, when there is no decent source for the volume data? Wheras I'd concentrate on the editing rather than more procedural sources. They are nice and easy to implement when you have a function like f(x, y, z) = 0. And Marching Cubes 33 could solve some problems. If MC33 works out, the actual generation of triangles could be superiour to C4 and Polyvoxel.

Totally agree, the terrain without the ability to edit or at least edit the data-source stays nothing else than a proof of concept and is of no practical use to anyone.

[TheSHEEEP]

I'd be really careful when doing some kind of editor.

No matter how you do it, it would most likely not fit any specific implementation in a game or other project.
And then you'd have made a good editor that cannot really be used by anyone, other than showcasing the isolated component.
The Volume Component will almost never be used alone, but in combination with whatever other plugins and libraries. And no editor that is focused on that component only could possibly fit the various use cases.

IMO, it is much more important (and you correctly put it higher ) to have a well documented data source.
How to build up that data source should not neccessarily be a concern of the component itself, as it will vary from project to project anyway.

So, for example, when doing a game with such a nice terrain, you would need an editor that can edit the landscape itself as well as placing objects on it, scriping, etc.
And outside of a full fledged engine like C4, or a specific game, where you can validly make assumptions about the project structure, you simply cannot create such an editor.

Of course, the feature to update the volume data at runtime is mandatory.
While paging is not mandatory. You could also use the Volume Component creating only single scenes, not one big world.
But I know of no free engine or even graphics library that supports large paged terrain with caves. This would really be a feature that stands out even more than single terrain scenes with caves.

[PhilipLB]

I don't meant to write a complete editor. Maybe some day, but not now. I meant that there could be features in the component itself to write one. As far as I can see this would be casting rays directly on a Source (not the triangles) to get a nice intersection point for some kind of brushes. At this coordinate, something has to happen. Whether it internally builds up some CSG or whether it edits directly a scalar 3D field. The first would get slower as the tree builds up with every editing action. The second is destructive. Something in the middle had to be found like a "bake"-command where the CSG tree gets baked into the 3D field and can then be thrown away. After the source has been edited, the Mesh(es) needs to be regenerated. And last, the volume needs to be saved to disc. Whether it's the baked 3D texture or the CSG-tree. Both make sense, the first as some kind of final export, the second as the project file.
All in all, not a small project and not to be expected any time soon. But possible...

[Zonder]

I am not sure the component should have a file type as such more all the commands an editor would need to create the dataset.

But when the paging part is been done (maybe a separate component that uses the main one internally) that will require a file format so it can reconstruct the 3d datasets these I would expect to be cached to disk though with a upper cache size limit.

Keep up the excellent work

[Nauk]

I'd be really careful when doing some kind of editor.

No matter how you do it, it would most likely not fit any specific implementation in a game or other project.
And then you'd have made a good editor that cannot really be used by anyone, other than showcasing the isolated component.
The Volume Component will almost never be used alone, but in combination with whatever other plugins and libraries. And no editor that is focused on that component only could possibly fit the various use cases.

I meant more provide the infrastructure and maybe a sample for editing capabilities as api feature than a ready made editor, equivalent to get & setHeight, exposed pointer to terrain data etc, functions in current heightmap based components, so developers have a point to begin with. At least that is what I understood Philip had in mind too. There is no matter how a definate need to create content to display, with that, the nearest thought for me would be to create it with the same component you going to display it later on in your game or app.

But I know of no free engine or even graphics library that supports large paged terrain with caves. This would really be a feature that stands out even more than single terrain scenes with caves.

Of course that would be awesome

I don't meant to write a complete editor. Maybe some day, but not now. I meant that there could be features in the component itself to write one. As far as I can see this would be casting rays directly on a Source (not the triangles) to get a nice intersection point for some kind of brushes. At this coordinate, something has to happen. Whether it internally builds up some CSG or whether it edits directly a scalar 3D field. The first would get slower as the tree builds up with every editing action. The second is destructive. Something in the middle had to be found like a "bake"-command where the CSG tree gets baked into the 3D field and can then be thrown away. After the source has been edited, the Mesh(es) needs to be regenerated. And last, the volume needs to be saved to disc. Whether it's the baked 3D texture or the CSG-tree. Both make sense, the first as some kind of final export, the second as the project file.
All in all, not a small project and not to be expected any time soon. But possible...

What about using existing APIs?

[PhilipLB]

What existing APIs?

[ppClarity]

But I know of no free engine or even graphics library that supports large paged terrain with caves. This would really be a feature that stands out even more than single terrain scenes with caves.

Why would you complicate your terrain generator with a cave feature instead of using a portal system like the PCZ SceneManager?

[TheSHEEEP]

Using portals means that your caves have to exist as ready meshes. And then the portals in in your height map terrain "link" to them. This is how it is done in most cases, I figure.
That's not bad, but also nothing special. And it means more work as someone will have to build the caves by hand.

But what if you want your whole world to be procedurally generated. The terrain as well as the caves.
Think of Minecraft, it just makes for far more interesting terrain. And now imagine how it would be if they only had like 10 caves and would place them randomly. Yuck!

Also, it's not only about caves, but also about overhang, something which simply exists in nature and makes your terrain more interesting.

Obviously, it depends on what you want to achieve if you could simply use portals or really need the full "procedural experience".

[Nauk]

What existing APIs?

Meaning there are quite a handful of open source 3D editing apps, apis and paper implementations out there, so there is a good chance to find at least some inspiration how to do it, best case someone that has solved the problem already. But don't get me wrong I don't want to imply you haven't done your homework.

[PhilipLB]

I'd love to see a free volume editor. The only descend one I know is Acropora [0] with which I also created the 3D texture which is now used in the sample. But my trial expired and they simply don't answer if there is a possibility to get some kind of academic or opensource license. The homepage seems to be rather dead, too. Meaning, the last news entry is like a year old and the forum is inactive.

So if anyone knows a free or opensource volume editor, please give a shout.

[0] http://voxelogic.com/index.php?option=c ... &Itemid=21

[ppClarity]

Using portals means that your caves have to exist as ready meshes. And then the portals in in your height map terrain "link" to them. This is how it is done in most cases, I figure.
That's not bad, but also nothing special. And it means more work as someone will have to build the caves by hand.

Huh? A mesh is a mesh is a mesh regardless if it's created by a 3d-artist or math. There's nothing about PCZSM that's incompatible with a fully procedurally generated world including portal placement. OgreProcedural or even a voxel-based area generator come to mind as tools to use to create cave meshes.

That said, I forgot that the point of this project was a volume generator (developer needs coffee badly). Now it makes sense for it to also do caves, et. al.

[Nauk]

So if anyone knows a free or opensource volume editor, please give a shout.

I am definately going to help with looking for one or a solution.

[PhilipLB]

Just merged my dev-repo with the main one. Changelog:

Maintenance, refactoring, optimizations and consistency.

• A fix in the nearest neighbor normal interpolation.
• Some refactoring and optimizations of all trilinear interpolations.
• MeshBuilderCallback renamed to the more meaningfull "trianglesReady".
• Renamed the parameter "maxPixelError" to "maxScreenSpaceError".
• Big refactoring of the Source:getValueAndGradient() function to return a Vector4 containing gradient and density instead of returning a Real and the gradient in a given reference. Yielding in a nice loading time decrease (~10%) and cleaner code.

[PhilipLB]

Again maintenance, refactoring, optimizations and consistency.

• Smaller refactoring and code cleanup.
• Made the IsoSurface class abstract and the current MC implementation is now the first child. This opens the door to new MC variants like MC33.
• Renamed the occurences of "normal" of the 3d texture source to "gradient".
• Support for the Specular Map in the lighting, switchable from global specular to the maps.

And I updated my signature to point to the current development repository.

[TheSHEEEP]

Maybe it would make more sense to make your signature link to this thread instead of the GSoC page, as this is where all the action is now
And as the first post here already links to the GSoC thread, nothing is lost

[PhilipLB]

Good idea.

[drwbns]

Are you still working on this project?

[PhilipLB]

Of course. But I'm in the final corrections of the thesis now and hardly any actual implementation happens currently.

[drwbns]

Ah..ok. Just making sure it's still alive

[al2950]

Just to let you know the triplanar texture RTSS SRS has a few compile errors when compiling Ogre with double precision. This is not a major issues for me, but should probably be corrected. I could make the changes and submit a patch if you want, but I find that process takes a lot longer than just asking for a simply change