Best method for IOR back

(L) [2013/08/10] [ost by Bealy] [Best method for IOR] Wayback!

Hello,
this may be a simple question, but it's quite puzzling for me: what is the best method (overall) for managing transparent IOR objects? (Meshes) e.g. checking if you are entering or exiting the object.
At the beginning I used only normals, this worked until I found some objects which have wrong normals (not pointing outside). So I switched to a code flag "InsideMaterial" which seems to work but does not satisfy me, for example it does not work if you are inside the object.
Is there a general rule??

(L) [2013/08/11] [ost by graphicsMan] [Best method for IOR] Wayback!

I think without modeling support there's no real good way.  A paper I wrote with a colleague used a CSG-like method for handling nested dielectrics (Simple Nested Dielectrics in Ray Traced Images).  We were able to use existing modeling software (Maya), but we had to augment the output with priorities in our file format.  There was no way to tag the various meshes from Maya.

I think it would be great if the modeling software could support this; if they simply guaranteed outside-ness via triangle winding order or something, and then had both sides of the primitives tagged with media, it would be possible to do arbitrary media transitions without any data structures.  It also means that for boundaries like water/glass, you'd only want a single layer of triangles.  If there are shared boundaries, any existing technique would completely fail.

One caveat: You have to know the media you start in.  One way to bootstrap this is to just trace an infinite ray, keeping track of the interface changes until you don't hit anything.  By looking in reverse order you can know your media.

(L) [2013/08/12] [ost by ingenious] [Best method for IOR] Wayback!

>> graphicsMan wrote:I think it would be great if the modeling software could support this; if they simply guaranteed outside-ness via triangle winding order or something, and then had both sides of the primitives tagged with media, it would be possible to do arbitrary media transitions without any data structures.  It also means that for boundaries like water/glass, you'd only want a single layer of triangles.  If there are shared boundaries, any existing technique would completely fail.
What if you have a glass cube that's half in the water, half in the air? You will then need to split some cube faces along the water border, so you can assign them different media interfaces. This is theoretically possible, but puts some load on the modelling tool, and I guess could be undesirable (e.g. lead to over-tessellation) in some cases. A volume stack (with media priorities) seems like the better option in that regard.

(L) [2013/08/12] [ost by Serendipity] [Best method for IOR] Wayback!

A volume stack sounds like an interesting option but how would you handle the intersection in this case? In real life you often have different tessellations for the glass model and the water model. How should the intersector detect if he has hit the right surface? Or how can you make sure to hit the surfaces in the right order?
This would be possible if you collect all the intersections along a ray or at least all intersections withing a given epsilon range (i hate those things) and sort them after that in a clever way based on the IOR and shade them one after another. But I wonder how to do this efficiently.

(L) [2013/08/12] [ost by graphicsMan] [Best method for IOR] Wayback!

>> ingenious wrote:
What if you have a glass cube that's half in the water, half in the air? You will then need to split some cube faces along the water border, so you can assign them different media interfaces. This is theoretically possible, but puts some load on the modelling tool, and I guess could be undesirable (e.g. lead to over-tessellation) in some cases. A volume stack (with media priorities) seems like the better option in that regard.
Hi Ingenious.  That was more-or-less the problem we set out to solve with our paper (if you look at the main result image for the paper, we actually have a glass of liquid with an ice cube floating such that it falls above and below the liquid surface).  The other solution (with modeling software assistance) would need to ensure that the tessellation properly followed the boundaries where the water/air/ice interfaces meet.  Since I didn't have any way to ensure that, our method was born.  

Our method does not require consistent facing normals, etc...  In fact, in my code, I always faced the normal toward the incoming ray (negative dot product) for consistency in my code.  I determined whether I was going in or out based on the little data structure I maintained.  Note that in my code, I used a heap structure.  My co-author used a linked list.  In my opinion, nowadays unless you are doing super nutty nestings, a statically sized array of length 8 or 16 aught to be plenty.  Searching through an array that long for the highest priority items (and/or current item) should be very fast.  Since there's no allocations, and no complicated searching, I think it's probably the fastest.  Modeling software could also be augmented to easily support our prioritizing scheme.  I'm unsure what's best (which technique would be easier to support) for a modeling tool.

(L) [2013/08/12] [ost by graphicsMan] [Best method for IOR] Wayback!

>> Serendipity wrote:A volume stack sounds like an interesting option but how would you handle the intersection in this case? In real life you often have different tessellations for the glass model and the water model. How should the intersector detect if he has hit the right surface? Or how can you make sure to hit the surfaces in the right order?
This would be possible if you collect all the intersections along a ray or at least all intersections withing a given epsilon range (i hate those things) and sort them after that in a clever way based on the IOR and shade them one after another. But I wonder how to do this efficiently.
This is why we artificially inflated the water in order to guarantee a gap between the water interface and the glass interface.  Because of our prioritization scheme, you'd put water on the "stack", but would not enter water until you leave glass.  I encourage you to read the paper.  Also, I say "stack" in quotes because a stack will not work (a slightly more complex structure is needed).

(L) [2013/08/12] [ost by graphicsMan] [Best method for IOR] Wayback!

I should also mention that there are a handful of small updates to the paper in my dissertation ([LINK http://graphics.cs.ucdavis.edu/~bcbudge/deep/research/budge_dissertation_final.pdf])

(L) [2013/08/13] [ost by Bealy] [Best method for IOR] Wayback!

Thank you, I just read your paper.
So, I guess that if you want to write a new raytracer you would choose method two (e.g. the "InsideMaterial flag"). Meanwhile I downloaded two free raytraces, looking for a "defacto" standard but one uses the flag and the other uses the normal(!)

Edit:
randomly surfing, this one uses the flag:
[LINK http://heart-touching-graphics.blogspot.it/2012/03/bidirectional-path-tracing-using-nvidia.html]

(L) [2013/08/13] [ost by graphicsMan] [Best method for IOR] Wayback!

Ah, you just want to implement a single refractive object.  I'm not sure either one is better than the other.  I think the flag toggle is probably easier.  That way you don't need to know triangle winding orders nor consistent shading normals.

(L) [2013/08/13] [ost by Serendipity] [Best method for IOR] Wayback!

>> graphicsMan wrote:
This is why we artificially inflated the water in order to guarantee a gap between the water interface and the glass interface.  Because of our prioritization scheme, you'd put water on the "stack", but would not enter water until you leave glass.  I encourage you to read the paper.  Also, I say "stack" in quotes because a stack will not work (a slightly more complex structure is needed).
Thanks, I will do that.