Raytracing, maybe,

but Real time or not real time, that is the question.

It struck me one clear day there wasn't enough raytracers available on the net yet and i had to take my chance, but with one hand in the back and a blindfold.

With Heaven7 by Exceed in mind (no less), implementation numero uno ensued.
I learned a lot along the way and in particular that i was heading to a dead end at full speed.

Back to the drawing board.
The second incarnation is much simpler. It aims at doing only one thing, triangles, fast.
So far, so good.

Buzzword compliant techno blabberring:
V1 supported many primitives (planes, spheres etc) and that means more branching. It also lacked any spatial partitionning (scenes were suposed to be kept simple). A simple 3DDA was bolted on later on, with no effect whatsoever but an increased code complexity. It featured every standard tricks and cheats i knew of (this article by Lycium is a gem) yet i couldn't see how i could match the sphereflake scene found in Heaven7.

V2, *cough* will *cough*, shoots coherent rays (packet of 4 rays bundled together, SIMD friendly) through a BVH (Bounding Volume Hierarchy, more precisely aabb in array form) and only supports one primitive: triangles.
I've chosen BVH instead of the ever popular KD-tree for the sake of simplicity. I know Wald & al. would beg to differ.
While my shoddy BVH construction definitely ill behaves on some SPD scenes (rings etc...), i'm currently shooting 1.4M non coherent rays/s (2.2M/s for shadows) on my 2ghz opteron on large models (1M+ triangles) like the happy buddah.
There's some hope.

tbp.

note: measuring performance in terms of ray/s is a bad idea, yet rays are about the only feature shared by raytracers... this is an attempt to to refine that notion (even if right now the measure is rigged by the ray generation, fix on the way).

If you're bold enough to give it a try, drop me a line as i'd like to know how it performs on other platforms (ie Intel).

A quick note about ray / box intersections.

W.I.P section.
2004-11-20:

cleaned up model loading code, added support for 3DS (see Mesh Factory) and raw triangles (for SPD, use the -r 11 driver; note to self: put some canned bins up).
added basic Lambert shading (diffuse etc); it's not done the Right Way™ but i grew really tired of the hacked up z-buffer style.
some more command line switches.
faster rendering for the synchronized OpenGL view (rendering a million box can be quite slow).
some code to benchmark intersections (mono ray->box, 17 cycles; it's official).
more clean up, and more hacks; that's a draw.
a binary should follow ASAP; done.
snapshot binaries shipped; sadly the msvc version is back to suck-ass mode (50%+ slower than the gcc version) because a) it's an asinine compiler b) i don't care enough atm to fix it with ad hoc asm.
screenshots on the way. done. heuristic screwed for some models. gah.

2004-11-21:

implemented more BVH construction schemes namely SAH (Surface Area Heuristic) and a kind of hybrid SAH; SAH was a real pain to bring to acceptable performance, but now i'm quite happy with the result and it removed most of the pathological cases i've been encountering until then. It could definitely use some tweaking, but it's already way better than median cut... i guess i need to get used to it :)
more fixes; got a report that confirmed that the gcc version now works ok on non cygwin environements.
1.694 Mray/s, 2.618 M shadow ray/s on the bunny bench.

2004-11-23:

got some clues about SAH from another read of Havran.
SAH evaluation is a computationnal nightmare and my ugly hacks to make it bearable won't work anymore. I seriously need to think about an out of core solution to handle gigantic models/scenes: you need to hammer on gigs of transient data for a 28Mtri model like Lucy and windoze memory management is a sad joke.
Mueller proposes another pass to detect clusters in a BHV (empty spaces etc, p. 20) in his thesis.
Another reference.

2004-11-24:

attempt #2 at SAH already gives some promising results, around +25% speed up on average but the tree compilation time also are on the rise by some order of magnitude; fix on the way.
preliminary result, with a reduced split range, on the bunny bench: 1.8Mray/s (2.8 for shadows).

2004-11-26:

still a little loss on small models (ie bunny) but an overall win in the heavy weight category; got the xyz statuette to load for the first time and there's still room for improvements.
and i need a ******* brain, today's shots were taken with a profiling built binary. "Room for improvements", he said knowingly.

2004-11-28:

managed to get some stuff done despite the flu i caught lately.
model compilation time back to something acceptable: from 1.5s for the bunny (69k tri) to 330s for the xyz dragon (7m tri).
it's still a bit too much for my taste, so i've hacked in some mmaping out/in of the BVH in final form; i don't know what kind of limitations xp has (geometry is mapped read only while the bvh itself has to go with copy-on-write because of the post-load fixups); got to love the insta loading of the dragon once it's cached by the OS :p
since i'm pretty much set up on the hierarchy side the next task will be... getting rid of that flu.
thai statuette, 10Mtri:

compilation...
bvh::do_build: hang tight and fasten your seatbelt.
bvh::do_build: done in 334.905 seconds and 254 banks.
        nodes 5544029 leaves 2772014 splitters 2772015.
check: leaf found at lvl 10 largest 27  loners 0
bvh::store: purging a bit.
flat::flatten: allocated 169.190 M bvh, 438.492 M geometry

then...
bvh::disk_map: mapped 169.190 M copy-on-write.
bvh::disk_map: mapped 438.492 M read-only.
bvh::bvh_load: load+fixup in 0.423 seconds.

wicked i'd say.

2004-11-30:

got coherent (packets) rays traversal & intersection (box & tri) going on but Trumbore's really doesn't fit: ray/box is 4x faster but the ray/tri lags way behind so...
i'm moving to Wald's ray/ triangle intersection (got it working), but i need to rethink the way i store my vertex data both for shading & intersection; that will definitely require more memory and while i'm at it i'll plug in texture coordinate support.
distinct shading data support done; 1.72M mono-rays/s on the bunny bench, woot.

2004-12-01:

packet/coherent pipeline done in a crude way, tho rays are still unmuxed for shading and there's no fallback to mono-rays when the coherence of the packet is screwed; the packet setup is barbaric, yet i'm getting a 2x speedup (despite a large increase in avg. intersections).
experimental gcc-4.0.0 rocks.
uploaded some pics.

2004-12-02:

added normals to SPD's raw triangle driver (-r 11) and matching code to load them.