Quote:Original post by phantomus
Hm you're right, perhaps that's causing the small speckles I have in the demo I pointed to a few posts above this one (did anyone try it? could you post some performance figures and machine specs?). Basically I start with ID 0, and add one to this for every generated ray. It's an unsigned int, so there are quite some rays generated before it wraps. Should be pretty safe.

ill try it after i finish this post.
uint, 4 billion isnt it? i agree, considering you only cast a couple of million rays / frame, there would only be a change once every 1000 frames for a patch not to be hit at all 1000 frames long, then to be hit by a ray with the exact same ID. not going to happen, realisticly. not an optimal solution though, imho.

Quote:
Using your one bit approach requires you to reset the bits. And that's not going to help performance. That list that you mention is going to be huge, on my bunny model about half of the triangles will be in it. For the 1.1M buddha model it's a nightmare. And even for that model, the incrementing ID will cycle only every x frames so why bother. ;)

i dont think its that bad. i keep my patches in an array inside my mesh class. if i just swap the references to the tested patches to the front of the array (a cheap operation youll agree), resetting the bits will be a joke. just count how many patches youve intersected (only something like 3 on average at most) and reset their bits.

Celeron, that's PII class right? Nah that's not gonna cut it. :)

"not an optimal solution though, imho."

Why on earth not? :)

"i dont think its that bad"

It's not bad, but it's not better. My approach takes NO postprocessing and you're never gonna beat that. Anyway those are your clockcycles, you may decide what to do with them. ;)

mobile p4 centrino 1300, it maintained an easy 5 fps, very very awesome!

however, seeing the size of such a bunny and the accompanying kdtree, reinforces my choice to go with higher order surfaces :P. also, do you use vertex normals? i see raytracing of higher order surfaces as a good way to get rid of that hack once and for all.

oh yeah.

i did see some speckles, but i dont think its even possible they were due to your mailboxing method, since none of the affected triangles had the chance not to be hit. it was probably just passing of rays trough edges. another problem i hope to reduce by using barycentric patches. patches rule.

as for the postprocessing you mentioned: three dereferences and three bits to reset (on average). doesnt seem significant to me, but if i can cram that bit in somewhere else, it does save me 4 bytes/primitive. (3 if i dont).

another idea: instead of a bit, i give a primitive a pointer to the primitive that was hit before it. if this pointer is null, the primitive hasnt been hit yet, otherwise it is. to reset these pointers, just unraffle the chain.

this allows me to keep the primitives not by reference, but directly in the mesh structure, which in turn allows for 2 byte pointers. (aswell as less memory fragmentation and better cache behavior)

5fps is nice, that's in line with my own measurements.

But you're right: To get a decent amount of detail I use 69k triangles (well that's not completely true, I justed wanted to render a standard model). Higher order surfaces would probably much more efficient, and perhaps the lower memory usage would be more friendly to the cache also. But I'm not sure about this vertex normal thing: Obviously you don't have to interpolate normals based on barycentric coords anymore but how about texturing?

O btw I have to admit I used one trick. The shadow rays start at a specified offset from the intersection point of the primary ray and the mesh. The advantage is that these rays don't have to traverse the dense kd-tree structure near the bunny mesh; for two light sources this virtually doubles the performance of the demo. The drawback is that some small features don't cause self shadowing. This is noticeable for the ears: Without the trick, the edge of the ear casts a shadow on the inner ear; with the trick it doesn't. But at 100% speed improvement, I thought it was a nice trick nevertheless.

Quote:Original post by phantomus
5fps is nice, that's in line with my own measurements.

But you're right: To get a decent amount of detail I use 69k triangles (well that's not completely true, I justed wanted to render a standard model). Higher order surfaces would probably much more efficient, and perhaps the lower memory usage would be more friendly to the cache also. But I'm not sure about this vertex normal thing: Obviously you don't have to interpolate normals based on barycentric coords anymore but how about texturing?

well, much more efficient not im affraid. youll have much lower memory requirements, so indeed better cache, and less tree traversal. however, intersection aswell as normal calculation is considerably more expensive. texturing shouldnt be a problem. a good intersection algo returns UV coords. personally i dont like vertexnormals, because they are a hack, and one that potentially bites you in the ass with raytracing, because youll have normals that arnt always perpendicular to your surface, potentially messing up reflection and refraction calculations. higher order surfaces give you even smoother results, without the hacks, and at very much reduced memory costs.

personally i plan to go with triangular cubic bezier patches. they have some nice benefits in raytracing, such as a reduced chance of a ray passing between two of them, and i think quads are totally retarded as a primitive to model with.

im still in research phase however, im not sure yet whats the best way to combine all of my goals. wald also did a nice paper about higher order surface tracing. 'ray tracing triangular bezier patches' is also a good read imo.

Quote:Original post by phantomus
O btw I have to admit I used one trick. The shadow rays start at a specified offset from the intersection point of the primary ray and the mesh. The advantage is that these rays don't have to traverse the dense kd-tree structure near the bunny mesh; for two light sources this virtually doubles the performance of the demo. The drawback is that some small features don't cause self shadowing. This is noticeable for the ears: Without the trick, the edge of the ear casts a shadow on the inner ear; with the trick it doesn't. But at 100% speed improvement, I thought it was a nice trick nevertheless.

i must say i did think your shadows looked slighty 'off', although i wasnt able to specify why. in retrospect i would indeed describe it as a lack of selfshadowing. clever trick though.