Dissapointing building times from lbvh gpu based builder back

(L) [2012/01/11] [dbz] [Dissapointing building times from lbvh gpu based builder] Wayback!

The results from the paper "Simpler and Faster HLBVH with work queues" seem very promising so I did a search for the code and found a repository created by one of the authors which refers to the paper [LINK http://code.google.com/p/slash-sandbox/wiki/NIH].
The lbvh from the repository is very fast: 16 ms on a GTX 470 for 1 million triangles but results in (very) poor quality trees.
The binned sah builder is slow, 370 ms for 1 million triangles.
The sah builder takes 230 ms for 1 million triangles.
Everything has been compiled (with some efforts) in release mode. The last two builders perform nowhere near the 10ms for 1 million triangles as reported in the paper. Did anyone get better results?
(I have doubts the builders from the repository are really those from "Simpler and Faster HLBVH with work queues" but are the builders from the older papers instead)

(L) [2012/01/12] [toxie] [Dissapointing building times from lbvh gpu based builder] Wayback!

AFAIK the NIH library is indeed not using the same stuff as the paper, but the full SAH construction features a new SAH implementation done independently by Jacopo. But 230/370ms is not bad for high quality trees, or what did you expect? [SMILEY :)]

(L) [2012/01/12] [dbz] [Dissapointing building times from lbvh gpu based builder] Wayback!

The paper mentions building times around 10 ms for 1 million triangles for high quality trees which is real-time whereas 200 - 400 milliseconds clearly is not. I guess NVIDIA won't release the code just like the hlbvh code which still has an empty repository... The paper is too general to just start implementing the algorithm which is a shame because the results seem promising.

(L) [2012/01/13] [mpeterson] [Dissapointing building times from lbvh gpu based builder] Wayback!

first at all it is an academic paper... what we have seen is that it was never ever able
to produce high quality trees for 1mio polygons in 10ms. it was more in the range
of 100ms. and that is not that bad.

(L) [2012/01/13] [dbz] [Dissapointing building times from lbvh gpu based builder] Wayback!

I guess you are right. If it sounds too good to be true it probably is too good to be true. It would also explain why NVIDIA never released the "Simpler and Faster HLBVH with work queues" code or the earlier hlbvh code.
So far for the reproducibility of academic work ... Kindoff strange NVIDIA published this in the first place.

(L) [2012/01/13] [outofspace] [Dissapointing building times from lbvh gpu based builder] Wayback!

I am one of the authors of that paper as well as the author of nih and I must correct some information
that was posted here: nih doesn't contain code for HLBVH yet.
It does contain a version of the basic LBVH which is not optimized for ultimate speed:
the primary purpose of nih is providing an educational platform, and all its algorithms are designed
with simplificity and flexibility in mind.
The LBVH builder is bound to produce lower quality trees than HLBVH because it doesn't perform any
SAH optimization at all.
The example tests are also slightly slower than the standard construction used in the papers
as they'r using 64bit Morton codes rather than 32bit ones.
The full SAH builder, to the contrary, does *too much* optimization for real-time graphics, and is targeted to
very high quality, offline rendering apps like iray or maxwell.
Technically, HLBVH is a composition of the two, which should be easy enough to do by yourself if you're
fluent with some metaprogramming, ray tracing, and a little bit of CUDA (it is my plan to incorporate that
too, but I am currently busy with other projects as well...).
It builds an LBVH for the lower tree levels, building a set of 10-30k clusters out of 1M tris,
and performs a full SAH construction for those.
Now let's some math: 230ms for 1M tris. Divide by 50 to make it work on, say, 20k clusters: 4.6ms.
That's all you need to go from the low quality LBVH to the higher quality HLBVH reported in the paper
(some levels of LBVH construction are saved, so you can save a few ms there).
Before disqualifying the reproducibility of academic papers I'd suggest actually looking into detail at
the publications themselves.
And btw, I think you could consider 230ms for a full SAH builder a pretty decent result by itself.
My baseline single-threaded CPU version takes ~10s on an i7 @ 2.8Ghz.  [SMILEY ;)]

(L) [2012/01/16] [toxie] [Dissapointing building times from lbvh gpu based builder] Wayback!

which doesn't explain though why the source code hasn't been pusblished yet, as was promised..  [SMILEY ;)]

(L) [2012/01/16] [outofspace] [Dissapointing building times from lbvh gpu based builder] Wayback!

Ethernal lack of time?
The paper implementation was researchy code, and needed to be cleaned up before being ready to be
published (as I think you well know for your own work stuff [SMILEY ;)]
But instead of just giving out a cleaned up implementation of hlbvh alone, I decided it was far better
to build a whole framework with composable pieces that could be used as building blocks
for hlbvh as well as for other tree constructions (e.g. k-d trees, octrees, etc).
Which was also crucial for my own work, as I started to have more or less the same code duplicated in
~10 different projects.
At the same time, I had to release voxelpipe, which in a way is a lot more interesting as it shows
a far more complex pipeline running entirely in sw on the GPU.
And then now that real-time ray tracing is a solved problem (thanks to Kirill), there are plenty of other
interesting things in my todo list. [SMILEY ;)]

(L) [2012/01/16] [spectral] [Dissapointing building times from lbvh gpu based builder] Wayback!

Seems interesting even if I have not read the paper (not yet... but hope during the next months).
But, I have a question... it seems that the best BVH construction algorithm remain the SBVH, I'm talking about offline renderers (please, tell me if I'm right or not) and high quality BVH.
But all theses BVH-building algorithms target simple BVH, right ?
Thx
BTW:
The kirill Frustrum-BVH algorithm seems great but there are some missing details in the paper. Also, I have just see a video, no code to test... so I can't tell more.
I hope I don't say anything stupid... but I will be interested to test all theses techniques and compare them [SMILEY :-P]

(L) [2012/01/16] [straaljager] [Dissapointing building times from lbvh gpu based builder] Wayback!

>> outofspace wrote:At the same time, I had to release voxelpipe, which in a way is a lot more interesting as it shows
a far more complex pipeline running entirely in sw on the GPU.
And then now that real-time ray tracing is a solved problem (thanks to Kirill), there are plenty of other
interesting things in my todo list.
Hi, in the Voxelpipe paper ([LINK http://research.nvidia.com/sites/default/files/publications/voxel-pipe.pdf]), you briefly described a real-time global illumination system that uses real-time GPU voxelization to build a scene proxy for tracing incoherent rays each frame, allowing dynamic geometry and lighting (running at 50 fps). Do you have any updates on that?