Ogre Forums

It would be awesome to have VFC, CHC++, and HZB as separate implementations that could be used depending on the scene specifics

That would is another gsoc subject, http://www.ogre3d.org/tikiwiki/Help+Req ... ybrid_tree allowing the traversal to be tree implementation agnostic, and allow for chc and other hzb to be implemented easily and independently.
Note that the basics are within the chc source code, with multiple culling algo implemented using the traversal pattern, with VFC, recursive VFC, stop&wait, chc, debug, etc.
Best would be to extend it so that can have parallel Dod "Data Oriented Design" orientations as much as possible in it.

That's good news then.

I have updated my initial post to reflect a rough draft of my proposal. I still have runtime errors with tuan's code, so I'm not able to get a concrete schedule set up until I have a better idea of where his code left off.

I have a better idea of where his code left off

I can help you there: prototypal level is where it was, not production ready.
On hybrid tree => was needing ogre core change.
On CHC => removing experimental occlusion/occluder/occludee and better debugging (notably more/better debugging view)
Read all my CHC related post here. Should be full of comments on that, as many people tried to implement CHC++ and to read my code.

ok, that is what I thought, I just didn't want to say anything before I had the code actually running in case I put my foot in my mouth

I will try and get a timeline typed up sometime today or this weekend.

I have added a rough timeline. I'm still in the process of getting familiar with tuan's code and the ogre engine in general, so some dates may shift as I do so. I feel fairly confident, however, that this is an achievable timeline. Any comments and input on the proposal are greatly appreciated, though.

Any comments and input on the proposal are greatly appreciated, though.

Still very rough planning you have there, main focusing point should be :

- unless you plan to finish the hybrid spatial tree, either specify what spatial tree type you'll be using (loose octree is really not suited for visibility algo, as object can be in two different leaf at the same time, check http://www.ogre3d.org/forums/viewtopic.php?f=3&t=50950 for recent discussion on latest ABT alternatives). The really best and fastest way would go for a brute force DOD culling grid as in http://publications.dice.se/attachments ... efield.pdf then use CHC on that grid. Best perf, simpler code, done easily and fast.

- solving the way visibility per camera and per light/shadow is stored in each node and frame unicity is determined (some fast consistent hashing on render target+camera+framenum might do the trick )

- generalisation of culling mechanism so that shadow caster culling in shadow passes can be done. (check paper "chc shadow caster" paper linked above)

- chc optimisations (3 paper listed above on that chc++, chc++opt, shadowcaster chc opt) should be listed in the proposition.

Thank you for your input, those sound like good areas of focus. I've been busy so far this week and will be tomorrow, also, but thursday I should have more time to do more reading on these topics and get a better game plan. I've read through the presentation you linked, and I noticed it talks a lot about multi-threading. Do you think DOD alone will compensate enough performance-wise without multi-threading?

Another question, this may be implicit in your third area of focus, but when storing the visibility information in a node, should a level of abstraction be taken so that cameras, lights, and shadow casters can be treated the same way?

Do you think DOD alone will compensate enough performance-wise without multi-threading?

yes, shorty is memory access cost much more than brute force cpu computations nowadays, see dod the slides for more details.

Another question, this may be implicit in your third area of focus, but when storing the visibility information in a node, should a level of abstraction be taken so that cameras, lights, and shadow casters can be treated the same way?

Was more meaning to add a way to store many information, something named like "RenderTargetCullingPass", with multiples named instances attached to a render target.
You'll have to store an UUID for each of those in there, and when storing visibility info in a node, use that id as the map associative key. The CHC++ info like the draw renderqueue of last frame "visible", and last frame number too could fit there.
And then you'll be able to query it from inside current render to get last frame culling info, per current render pass.

Add your project to here before student application deadline.‬

Apparently I misunderstood when the deadline was and missed it

Assaf Raman wrote:Add your project to here before student application deadline.‬

I tried to be clear...

Next year, then!

Yes.
BTW: Feel free to write the code outside the Google summer of code and submit it to the project.

Assaf Raman wrote:Yes.
BTW: Feel free to write the code outside the Google summer of code and submit it to the project.

+1