[GSoC 2012] Volume Rendering with LOD aimed at terrain

[PhilipLB]

After having cleaned up the code according to the styleguide (spaces instead of tabs!? My heart is bleeding! ):
The public viewable fork can be reached here: https://bitbucket.org/philiplb/ogrevolumeterrain/

[PhilipLB]

Inspired by xiaoxiangquan, I also created a wiki-page.
I copied the structure and posted the first weekly progress.
You find it here: http://www.ogre3d.org/tikiwiki/SoC2012+ ... at+terrain
Also updated the initial posting with this link.

[Assaf Raman]

I updated your signature - so when you post in the forum - the community will be able to identify you, please don't change your signature until the end of the project.

[PhilipLB]

More warmup and making a comfortable environment.

• SDKTray TextBox, Main Sample class is registered as LogListener and fills it.
• Checkbox for showing and hiding the octree.
• Hotkey "h" hides/shows all UI elements, nice for screenshots.
• Read the first half of "Effective C++" 3rd edition to brush up my C++ knowledge. Highly recommended book!

[PhilipLB]

As the Summer of Code hasn't officially started yet and also my Thesis waits for some formal stuff, I tackled
mostly stuff which is nice but not super directly relevant to the LOD isosurfacing: Triplanar Texturing! And
some other small stuff.

• Triplanar Texturing with a small test-mesh, implemented as CG shader.
• Finished "Effective C++". Now that went into detail...
• Began a DualCell class which currently just holds 8 corners and can add them to a manual object for debug visualization. Next step is to traverse the octree and generate the duall cell grid.

[duststorm]

Read the first half of "Effective C++" 3rd edition to brush up my C++ knowledge. Highly recommended book!

I couldn't agree more
Highly recommended for everyone starting seriously with C++

[PhilipLB]

Slowly actually getting started.

• Completed the CSG cube
• Implemented the construction of the dual grid with a (switchable) debug visualization
• Put a new roadmap in the Wiki

[Mattan Furst]

Hello PhillipLB

I've been going a bit through your code. just a couple of suggestions

1. documentation - I think you should pay a bit more attention to classes and method documentation. Otherwise, sometime in the next month or two you will need to go back to your old code, either to fix a bug or to document the code for the final submission, and if your anything like me you may experience a "what the hell did I write here" moments. It doesn't need to be full blown documentation for now but I would at least ask you to have a one line comment describing what each method / class does.
2. inheritance of VolumeOctreeNode - To my understanding VolumeOctreeNode is a class that may need to be extended by inheritance (for instance to include texture information, references to source data or other information). I would suggest that you keep all references to it by pointer. For instances in which pointers are not used see: VolumeOctreeNode::getChild and the subsequent implementation in DualGridGenerator. I would also suggest some sort of a factory class or virtual function within VolumeOctreeNode to create new nodes so that this can be overriden to create other types VolumeOctreeNode in the future. something along the line of perhaps:

   Code: Select all

   virtual void VolumeOctreeNode::createInstance(const Vector3& from, const Vector3& to)
   {
       return new VolumeOctreeNode(from, to);
   }
   

[Mattan Furst]

I see you already started on the changes I requested. Thank you.

[PhilipLB]

Hi,

thanks for the hints.
Towards the documentation: "a bit more attention" is a bit of an understatement, there was simply none. Half way through with some basic documentation now, the rest is for tomorrow.

[Mattan Furst]

I've just made another small check in. The check-in was done to fix some container issues in MeshBuilder.h:

1. On using boost - In all likelihood people who will use your project will be able to include boost as well. however, you cannot assume that this is the case. You need to either define your project in the CMake script as built only when boost is available or make the project able to compile in a non-boost available environment. MeshBuilder was using an un-ordered map from boost. I changed the code so if boost is not available std::map would be used instead.
2. On using std containers - instead of using stl vectors directly. you can use the ones defined by Ogre. Ogre has special memory allocators that both help to find memory leaks and are said to be faster than the default implementation. Instead of std::[container]<[template parameters]> use Ogre:::[container]<[template parameters]>::type, so that std::vector<size_t> becomes Ogre::vector<size_t>::type.

[PhilipLB]

Ah, true, good hints. Thanks.

(Now in this case, "Boost" deserves it's name literally as it will really boost the generation of the meshes if available )

// Edit: Nice "trick" using memcmp, didn't know about this function.

[CABAListic]

Actually, I think Ogre even has some typedefs for an unordered map pointing back to a native compiler implementation, if available. Might want to check that.
Definitely do try to keep your code clean of Boost. Right now, Boost is our primary threading option, but that might change in the future, and in that case Ogre should be fully usable without Boost.

[PhilipLB]

About multithreading: Later, I plan to add some multithreading to the generation of the meshes. What are my options here with Ogre? Currently, it sounds like that multithreading (mutexes etc.) comes with Boost. Now with trying to avoid Boost, should there be a singlethreaded variant beside the multithreaded one, activated via #ifdefs?

[CABAListic]

Ideally you should use the Ogre facilities for multithreading (WorkQueue and Request/Response system), as that is automatically implemented via the chosen thread provider.

[PhilipLB]

Working...

• Added some first documentation.
• Implemented a MeshBuilder to build up a mesh from triangles using vertices and indices without duplicating vertices.
• Started with Marching Cubes.

[PhilipLB]

Yesterday, I had no screenshot with new stuff to show as everything was just internal.
Now I have a first version of Marching Cubes running (needed later to contour the dualgrid). The screenshot shows a CSG Sphere made with an oldschool MC wandering over a regular grid.

[Mattan Furst]

Amazing job. Its wonderful to see a renderable results this early in the project.

I think you're GSoc schedule might be slightly off .

[PhilipLB]

Cheers.

Next step is to make this working on the dualgrid cells. And maybe some other smaller things here and there. I plan to have this done until this sunday and then there are indeed two weeks saved in the roadmap.

[Zonder]

Cheers.

Next step is to make this working on the dualgrid cells. And maybe some other smaller things here and there. I plan to have this done until this sunday and then there are indeed two weeks saved in the roadmap.

just leaves more time for docs and testing

[PhilipLB]

In my proposal, I talk about how to close the gaps between the chunks. This is one of the bigger problems in this project, to triangulate the borders at the chunks. This is mostly done now. I'm using some kind of Marching Squares (MS) [1] for this on the dual cells which uses the same interpolation as the surrounding marching cubes (Anyone knowing a good source for MS? I'd love to avoid Wikipedia as Source in my Thesis...). Todays screenshot shows a sphere at the border of the rendered volume which is nicely closed via MS.

First closed gaps.

• Added a checkbox to hide and show the actual mesh.
• Using the cells of the DualGrid for Marching Cubes now.
• Updated the roadmap as the Marching Cubes stuff was earlier done than expected.
• Implemented Marching Squares to triangulate the open parts of the (future) chunks.

[1] http://en.wikipedia.org/wiki/Marching_squares

[Mattan Furst]

Updated the roadmap as the Marching Cubes stuff was earlier done than expected.

I missed setting this requirement when you started on the project so it wont be compulsory. But if it turns out you have time at the end of the project I would like you to please set time aside to move the core of the sample to a plug-in.

[jacmoe]

I have a suspicion that the original marching cubes algorithm is patented, so that should be avoided.
Could someone confirm this?

[Mattan Furst]

@jacmoe

From the wikipedia page philipLB link to:

The Marching Cubes algorithm is claimed by anti-software patent advocates as a prime example in the graphics field of the woes of patenting software. An implementation was patented (United States Patent 4,710,876[4]) despite being a relatively obvious solution to the surface-generation problem, they claim. Another similar algorithm was developed, called Marching Tetrahedrons, in order to circumvent the patent as well as solve a minor ambiguity problem of marching cubes with some cube configurations. This patent expired in 2005, and it is now legal for the graphics community to use it without royalties since more than 17 years have passed from its issue date (December 1, 1987[4]).

I think this means its in the clear.

[PhilipLB]

Plugin: Yep, this is something I'd like to do when everything is in a somewhat "demoable" state.

Patent: See above.