[GSoC 2012] Volume Rendering with LOD aimed at terrain

[Mattan Furst]

@PhilipLB

Just to make sure we are all on the same page.
both Assaf, CABAListic and I want the your GSoC project to be merged to v1-9. Just as you did on https://bitbucket.org/philiplb/ogrevolumeterrain2/.
now it only needs to be pushed to the main ogre source control on https://bitbucket.org/sinbad/ogre (also on the v1-9 branch) .
I already gave you writing permissions to https://bitbucket.org/sinbad/ogre about a month ago (as discussed in earlier posts).

would you like to do the honors?

edit:
p.s
I thought this would be the fun part

[PhilipLB]

With pleasure, right now.

[PhilipLB]

Done!

[duststorm]

nice

[CABAListic]

Excellent! Now that it's in v1-9, it's easy to get it into v2-0 and default, too. It'll just get picked up once we do the next forward merge.

[Mattan Furst]

congratulations.
http://www.youtube.com/watch?v=3GwjfUFyY6M&t=34

[Assaf Raman]

I have issues in the d3d11 render system after your project commit:

02:03:11: OGRE EXCEPTION(7:InternalErrorException): Unable to compile Cg program 2817628953_FS: The compile returned an error.
SGXLib_TriplanarTexturing.cg(7) : error C1008: undefined variable "normalAndFogVal"
SGXLib_TriplanarTexturing.cg(8) : error C1008: undefined variable "texScale"
SGXLib_TriplanarTexturing.cg(9) : error C1008: undefined variable "texScale"
SGXLib_TriplanarTexturing.cg(10) : error C1008: undefined variable "texScale"
in CgProgram::compileMicrocode at C:\hg_Code\ogre\d3d11_GSoc\forMerge\src\PlugIns\CgProgramManager\src/OgreCgProgramManagerDll.cpp (line 67)

Will you be able to find some time to fix this?

Also - what is going on with the EOL on your commit? Do you use the '"hgext.win32text" extension?
It led me to back-out the undo the back-up of one of my commits... Make sure you commit with the right EOL.

[masterfalcon]

I also saw that happening with GL as well.

[Assaf Raman]

Well, parameters are just missing from SGXLib_TriplanarTexturing.cg, I don't understand how it worked before the commit, this smells like a bad commit...

[PhilipLB]

Will be fixed asap.

[Mattan Furst]

Parameters are fixed temporarily including a small problem with parameter creation problem in the tri-planar shader

[PhilipLB]

Thx, I'll have a look at it anyway what the problem was / fix the temp. solution.

I've seen, that there are a bunch of warning-fixes done, like changing

Code: Select all

virtual const Real getValue(const Vector3 &position) const = 0;

to

Code: Select all

virtual Real getValue(const Vector3 &position) const = 0;

What warning was that? Isn't it ok to return const stuff?

[Assaf Raman]

I don't know

[CABAListic]

No, apparently it's not ok for POD types, because as return values they are already treated as const or something like that. Which I think is a pain in the ass, because it is ok and legitimate to do for non-POD types, and I hate these kinds of inconsistencies.

[FlorianGeorge]

http://stackoverflow.com/questions/1134 ... eturn-type

I personally don't think it hurts to add the const to keep it consistently, and I don't get any warnings for it in Visual C++, but i guess the gcc community would get annoyed by the warnings.

[PhilipLB]

Interesting, thx.

(Cpp is such a beast...)

[TheSHEEEP]

It's called diva

[bstone]

Adding const to things returned by value as opposed to references and pointers makes little sense since you give the value away and don't really care if it's modified or not. It doesn't matter if it's a built-in type or a user defined one. Furthermore, once you get into rvalue refs that habit will be harmful for types supporting move copy/construction semantics and will bite you in the back once in a while

[CABAListic]

You do care because it prevents certain mistakes, e.g.

Code: Select all

if (someFunc() = 42)
{
  // ...
}

Now, for POD types like ints this is already illegal code because they are already treated as const rvalue. That's why GCC gives you a warning if you declare someFunc as const int - the const qualifier is redundant. But if it returns a class type, the const is not redundant and can prevent similar mistakes. So unless you know you want different behaviour, adding const to non-POD return values is good practice, imho.

[Mattan Furst]

Hello Philip,

I just talked to Assaf. One of your check-ins "3760 (e09c55ac19a0) Volume Rendering: added volume media" contains a large media file called samples\media\volumeTerrain\volumeTerrainBig.zip. This file is to big for Ogre's repository taste.

I am currently researching ways to strip the file from Ogre.

Do not attempt to delete it or change it. That will not remove it from the repository. it will just add to it.

[Assaf Raman]

Removing changesets or shrinking a Mercurial repository

[Assaf Raman]

Mercurial - Editing History

[Assaf Raman]

HisteditExtension

[Mattan Furst]

Assaf

I wasn't aware of the HisteditExtension extension. But how ever it is used I doubt its that easy. from what I've read mercurial is not built for these sort of things. if you remove something from the repository it changes the entire history and the repository becomes hard to merge. and even if you do that you need to make sure it doesn't come back in from other forks.

[PhilipLB]

This is the 3D texture with the volume data of the terrain. What to do without it? It's 256x256x256. I could create one with 128x128x128 maybe, but then the terrain has far less details. But this .dds would be 8MB then.
But I'd suggest to just stay with the big file now if it isn't easy to be removed. Sorry to have not used 128^3 from the beginning on.