Why not front-to-back ray casting?

[vahpy]

I was wondering why this package prefers back-to-front rendering while we can make rendering more efficient when using front-to-back? VTK (Visualization Toolkit) uses Front-to-Back direct volume rendering, supports early ray termination (stops ray casting when alpha (opacity) reaches around 97 or 99 percent). It happens a lot in real applications and saves processing time. I know some people prefer back-to-front for some reasons, is there any specific reason that you have used it here? What happens if I reverse it?

[Quantuman134]

I prefer front-to-back. I think it is necessary to design an adjustable early ray termination function for large-scale medical datasets, which is helpful to real-time rendering and interaction.

Vahid @.***> 于2022年3月7日周一 14:53写道：

I was wondering why this package prefers back-to-front rendering while we can make rendering more efficient when using front-to-back? VTK (Visualization Toolkit) uses Front-to-Back direct volume rendering, supports early ray termination (stops ray casting when alpha (opacity) reaches around 97 or 99 percent). It happens a lot in real applications and saves processing time. I know some people prefer back-to-front for some reasons, is there any specific reason that you have used it here? What happens if I reverse it?

— Reply to this email directly, view it on GitHub https://github.com/mlavik1/UnityVolumeRendering/issues/85, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQM6T3PFU5GZTJTZQAE52ZTU6WRWPANCNFSM5QCMHXDA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mlavik1]

Hmm.. It might have been done back-to-front for some reason originally, but I honestly can't remember. I should look into this. In surface rendering mode we already use front-to-back ray-casting. I don't like how it's done though (should probably render the front faces and cast from there instead). I should also calculate a proper ray length, instead of making every single ray 1.732(√3) long. This was originally just a small example project I made, and I haven't really revisited that code since :sweat_smile: So thanks for reminding me!

I'm curious about what the performance gain would be in a typical use case though. I can imagine that the extra if-check would add some extra cost (not sure how much?), and that we would only get a performance boost in cases where all the pixels/fragments evaluated by threads of the same warp are terminated early (the whole warp will need to wait if one thread takes longer to finish). But I can imagine that it will help a lot on some models.

So I think I will do the following:

1. Fix the hacky hard-coded √3 ray length. That should give some performance or quality boost for free, and I can get rid of this:
2. Implement front-to-back raycasting with early ray termination (maybe add it as an option?)

Thanks a lot for the feedback! (and things have been quite busy for me recently, but I hope to get time to start on some of this soon).