[GSoC 2012] Volume Rendering with LOD aimed at terrain

[qwertzui11]

I just hate the GPL license for libraries.
That's all.

got it. good point.

I think it's really cool of you to change the license, but I think you ought to consider to change it to ZLIB, BSD, MIT or Apache.
You really deserve the credit.

I've got to admit that i really love to read my name, however "WTFPL" sounds much better and is free of limitations

Markus

[madmarx]

Hi qweruyt!
I certainly was not speaking of the 'transvoxel', I was simply refering to the triplanar texturing shader (which is very little code in comparison to the rest of your code). But I also had forgotten you made some changes, sorry.
'Here where it all started...' : http://www.ogre3d.org/forums/viewtopic.php?f=2&t=61396
Great that you can change the licence, if this can help Philip and Ogre. I wish you that it will be used in many applications.

[PhilipLB]

What do you think? Time for the actual GSoC application?

[Assaf Raman]

Add your project to here before student application deadline.‬

[PhilipLB]

I added a rough UML class diagram and added some informations about the license, a sentence about the risk and what I plan to do after the summer.

[PhilipLB]

Just playing arround with the data-source and implemented a first version of the CSG-part. Currently supports:
- Spheres
- Union
- Difference
- Intersection
They are done like in [1], but the simple minmax way which could be enough for first experiments. Later on (probably after this GSoC), more sophisticated methods could be evaluated/implemented (like the one in the paper or the one in [2]).
Doing some more basic geometrics like cubes and planes tonight. Kinda fun, because this stuff is really implemented within 1-5 lines each. Afterrwards, I'll add this to my proposal.

[1] http://www.sccg.sk/~novotny/doc/cgi.pdf
[2] http://diglib.eg.org/EG/DL/WS/VG/VG01/119-132.pdf

[PhilipLB]

Cubes, planes and negation done, proposal updated.

[PhilipLB]

Updated with the new and already implemented class "TextureVolumeSource".

[aguru]

great to see how much effort you are already putting into this. Would be a shame if this project wasn't chosen!

[Mattan Furst]

Hello PhilipLB,

First let me say that this is one of the more impressive and ambitious projects I've seen of late.

From your posts I'm led to believe that you already started implementation. Is this the case, and if so, do you have a personal branch of ogre on bitbucket that I can download/see?

[PhilipLB]

Yep, I'm already toying arround.

There is no Bitbucket Fork (yet), currently I compiled the current Ogre trunk and linked to it in a testproject (derived from the BaseApplication class). This project is currently under version control on a private server. I'll soon move to something public like Bitbucket.
I can send you the few sources of course when you want to have a look at it.

[Mattan Furst]

I'm only asking out of personal interest. no rush.

[al2950]

This GSOC sounds awesome . I have almost no knowledge of this area but I was wondering if this volume rendering could be merged with the current terrain component. What i mean is that the main terrain will still be created from a height map but extra features like overhanging cliffs and caves can be created using this module. I was under the impression this is how the crysis terrain worked, however i may well have completely misunderstood something!

The reason I ask is that currently, if this project goes ahead, we will end up with two different terrain components and I am not entirely sure of the pros & cons of the two. If the above is not possible I would much appreciate if you could explain why just so can understand

[PhilipLB]

Hi, thanks.
I heard that too, that Crysis mixes this. This may make sense performance-whise. But I think there are some drawbacks which makes the implementation of such a system way more than one person can handle in a summer:
It should be transparent to the content creator. The system would take some volume data and generate the heightmap and the needed meshes out of it. Sounds difficult. If it isn't transparent, then the content creator could actually just create a heightmap and some additional meshes on his own. Generating LODs without cracks between heightmap mesh and additional meshes sounds tricky, dito texture coordinates.

Pros and Cons of heightmap vs. volume terrain are to be documented of course.

(Just updated the proposal with some more concrete plans on how to generate the VolumeOctree which is used to create the dualgrid.)

[duststorm]

I think Crysis uses voxels only in the editor and only on places in the terrain mesh where you explicitly add voxel areas.
Have a look here: http://www.crydev.net/wiki/index.php?ti ... oldid=1966
If I read correctly, I think afterwards the sculpted voxel gets converted to a regular mesh for ingame use.

[Zonder]

I think this should be separate from the terrain component.

But a hybrid plug-in of the 2 terrains would be interesting. The hybrids editing features could cause areas of the terrain to become volume based depending on the type of editing applied. I do think that would be something created after the GSoC or for GSoC next year

[xiaoxiangquan]

I think this should be separate from the terrain component.

I agree with you
This exciting feature will surely introduce some advanced APIs that most users/applications will not touch. It's better not to confuse them.
And from a design perspective, it seems not to be going to reuse something from the Terrain, including LOD, paging, and MaterialGenerator. In other words, they are completely different things.

So just add a VolumeTerrain aside the Terrain. Another benefit is that the two workflows won't conflict. For example, both of us are accepted ( I wish ).

[qwertzui11]

u may wanna think about using dual contouring
http://www1.cse.wustl.edu/~taoju/resear ... ontour.pdf

Have fun
Markus

[PhilipLB]

Hi,

I had a look at dual contouring when chosing the iso surface algorithm. The advantage is the preservation of sharp edges and (maybe) speed in mesh generation. But it's anything but sparse with triangles, see the lower right "house" in the first posting of this thread. So the first isosurface algorithm will still be dual marching cubes. Other algorithms might be implemented in the future like:
- Old school marching cubes for speed
- Dual Contouring for the sharp edges and speed
- "Isosurfaces Over Simplicial Partitions of Multiresolution Grids" [1] which is slower than DMC but solves some (rare) edge case problems

[1] http://josiahmanson.com/research/iso_simplicial/

[Assaf Raman]

Congratulation on the summer project!

[PhilipLB]

Yay, that's great!

And congratz to the other projects of robert_sasu, Xiao Xianquan and Karol Badowski!

[Mattan Furst]

Hello PhilipLB and congratulation on having your proposal accepted to google summer of code 2012.

As you may already know I will be your mentor for your project.
I see you have quite a bit of experience with programming (the uml was a very nice touch) so I hope not to bother you to much as a mentor. I would still ask that you adhere to the following guidelines for developing for the GSoC:

1. Please open a fork of ogre on bitbucket and use it as your source control for this project. Make sure you give permission to Ogre team members to view/edit it. Please do it sometimes within the next 2 weeks.
2. From about the second month onwards please try to make sure that when you check-in the code to bitbucket it is at the very least compile-able even if not working.
3. Please review Ogre's coding standard page. I see you have written a SceneManager extension to Ogre so you should already be aware of the coding standard. But if not here is the link: http://temas.obelisk.net/ogre/CR/docs/howto.html.
4. While developing please report on your progress every week or two, even if it is to say you've made no progress. This will keep me abreast of how you are doing relative to your proposed timeline.
5. Please post any problem that you encounter / become stuck on in this forum. I can't say that have much experience in your proposed field. But I have quite a bit of experience with ogre and I'll try to help when I can. Plus posting problems on Ogre's open forum will mean other people from the community can pitch in. I already added this forum to my subscribed list so I should receive an e-mail automatically if you post anything here.
6. This project seems to be the type of project that can be a major part of Ogre in the future. so for future development I will ask that when you submit the final code it will have a good documentation. especially on the description of the classes and how they go together. An updated UML image would be nice but not required.
7. Please download TortiseHG (http://tortoisehg.bitbucket.org/) in order to work with. Once you install TortiseHG please configure it according to Ogre's specifications. Configuration page can be found here: http://www.ogre3d.org/tikiwiki/Getting+ ... TortoiseHG

It's kind of late for me here so there might have been a few things that have slipped my mind, but all in all that's basically it.
I will review the documentation you posted in the next few days. I think I already got most of it accept for the dual marching cubes algorithm (and yes, I am aware it is a bit like saying I get the Ogre engine accept for the part where it renders stuff).
If you have any questions please post them and I'll try to answer as well as I can.

Edit:
about opening a fork on bitbucket. Ogre uses a mercurial source control. I would recommend that you download tortiseHG (if you have a compatible os) to deal with the source control.
Edit 2:
updated list (added 7)

[MirceaKitsune]

Awesome work! Can't wait for this to be ready, cheers

[PhilipLB]

Updated the design with the new Octree-Split implementation which doesn't use QEFs. So for the first implementation, no QEFs are required anymore which has some advantages:
- The Mesh-Generation is faster as there are no 5x5-matrices to invert anymore
- No flipped triangles which is a small glitch in the reproduction of sharp features of DMC
The drawback is that the reproduction of sharp features is actually then not so good anymore. But this is nothing which can't be extended later when the base is up and running.

This is a result of a (too high resolution) octree representing a single sphere:

[spacegaier]

Relevant for all students: http://www.ogre3d.org/forums/viewtopic. ... 55#p456794