NFBI Symposium 2011 talk on Recent advances in interactive medical volume visualisation

[cpbotha]

BTW, stefanbanev, impressive renderings on your youtube page! (they're just missing shadows ;)

Reading your comment, I thought to myself: "This guy must have something to do with Fovia". I see now that indeed your renderings are made with Fovia. Fovia is a company that of course sells a CPU-based rendering product.

Looking at this academically: In certain cases GPU-based VR solutions will be better and in others CPU-based. Physically-based lighting in interactive VR: definitely GPU. :)

[stefanbanev]

Once the sources of light are mapped/raycasted (additively) there is no overhead for following ray-casting. So, any number of light sources may be added with no impact on interactive VR; it's true that in this case, the setting-step of new light source takes time roughly equal to render one extra frame. Sure, it is still a volumetric ray-casting not a volumetric ray-tracing with reflection/refraction ray-forking at each sampling point (TF gets 2 extra parameters R G B O Rl Rr); is it your case?

[ExposureRender]

@stefanbanev

I'm not sure to which technique you are referring, is it Precomputed Radiance Transfer?

[stefanbanev]

It sounds adequate, I'm not well familiar with academia publications though. The math & basic algorithms behind are really trivial to bother how to name it; an actual complexity comes from a lot of "trickery" to cope with hardware limitations. I'm wandering about your technique; does it really apply reflection/refraction ray-forking at each sampling point? I do not think it is possible but If it is the case then indeed it is quite an undertaking...

[ExposureRender]

@stefanbanev

Well, in our proposed method we do not apply trickery to simulate light transport. We apply principles from Monte Carlo raytracing to volumetric data. We simulate unbiased light transport with brute force methods. At the moment we support single scattering, but we already have an implementation with multiple scattering.

[stefanbanev]

Aside note, HDVR does support volumetric shadowing in the way as I've described it. I did not use it simply because for my taste the offset-light source makes image look too messy (some their images/movie apply volumetric shadow). Besides, the current HDVR implementation of volumetric shadowing is a binary mapping so it works well only with "hard shadow". I'm sure it is not their high priority since for mainstream medical application it is hardly a need.

[SuperGastrocnemius]

@cpbotha Totally agree (and disagree with stefanbanev). The CPU is way too slow for practical use of physically based volume rendering in a clinical setting. Exposure Render on the other hand proves that it can be done when using the GPU and the interactive quality is much better than anything I have ever seen before. It's an amazing visualization tool.

[stefanbanev]

@SuperGastrocnemius It's not matter of opinions, it's matter of side-by-side comparison, ultimately market decides not words...

[cpbotha]

I don't agree. :)

Our whole point with this work is to show that physically-based lighting is now possible even on a single GPU, including *realistic* multi-lightsource shadows and NOT for example shadow volumes. This is significantly more overhead, but you get what you pay for.

Whilst there now is still some startup noise, our technique will be fully realtime also on laptops within two years or so, whilst multicore CPU lags more and more behind with massively parallel problems such as these.

[stefanbanev]

A nice presentation, thanks for sharing what GPU is capable. In the medical field, the high quality interactive VR is a well established procedure, the interactive quality I see from this demo is really TOO low to be competitive for main stream medical applications, milticoreCPU may do an incomparably better job. Volumetric shadowing is not an overhead at all (if any), it is really just a mapping of residual ray energy modulated by gradient-light dot product. Anyway a it's a great development...