Realtime hi res raytracing at last!

the 2nd picture looks rather strange :)
and teh fps are low :)

but nice raytracer :)

Nai: the second picture shows the subdivision of rays. What he does is he shoots rays at, let's say every 16 pixels. Then he finds where he needs to subdivide (where more than 1 object is contained by the subdivided space). This is why it's subdivided around every sphere and shadow.

Nice idea.

Wow. I didn't think it was possible, congrat's! I see you're getting 5 fps in what seems to be a rather simple scene, I wonder how it'd perform with something much more complex (like a scene from Toy Story for example)?

Ofcours it's possible, and it looks real nice for a polygon-rendering of 2 spheres.
For raytracing on the other hand, it looks fake and like it's done in a 64Kb into.

Subdivision is cool for the images you submitted, but now I want to see it in action for objects whose projected size is smaller than your initial subdivision-step :)

Drop the fake lensflares, they take away the beauty of a semi-realistic raytraced image.

Sorry to bash you but you asked for it posting stuff like "If you didn't think it could be done u were wrong" :)

Next step : include less easy primitives like polygon meshes or implicit surfaces - and at high speed ( at least > 3.084f FPS :))

Btw, what's the resolution of the images ?
If it's

Does your algorithm have any type of logic to deal with small objects? If an object is small enough or far enough away so that its only a few pixels wide, it could fall between your sample points and disapper. If it is moving, it will blink in when it hits a sample point and blink out again when it moves between them. How do you deal with this, or are you just ignoring it for now (and if ignoring it, do you have any plans/ideas to deal with it)?

Mhm it seems a good work to me. It's something like fresnel2 by Kolor (64k intro). I see that you're u-v interpolating reflections too. that's neat but are U using dual texturing or just (as it seems to be) render fully reflective objects (so that you don't have to blend the surface u-v and the reflection u-v)? The scene is poor (only two spheres and a plane?) and also you seem to subdivide only at object-object and object-shadow boundaries... you should shoot a few extra rays for phong highlights too imho (well this is not a must) and also for such simple objects it's easy do develop some tecnique that tells you where more rays are needed depending on the "curvature" of the surface... Mhm what's next? ah... if you want to do reflections a bsp tree would be nice too... Well I like RTRT, if you want to talk more about it email me (ken@uniplan.it). Bye

Grandpa Rogers likes this very much. Awesome. I must try this out! Good job!

I agree with L.e.Denninger. The screen shot looked very promising then I downloaded it and thought, gee this is just a bunch of hacks that add up to something which resembles ray tracing. The lighting is not real, the subdivisions are way too big, and its not even 'real time' only 5-8 fps on a 1gbz p3.

I commend you for releasing something different though and breaking ground with a new idea (at least I've never seen it before). Good job, I just wouldn't go around touting it as a real time solution.

I get ~15 fps so it is definitely real-time. Sadly, it looks like shit because of assumptions that were made about the 3D hardware. I have a voodoo 3 and the flare textures aren't alpha blended and no other textures show up.

I'm really surprised by the attitude of the people here..

Yes, it's a hack, the same as used in software realtime raytracing apps (ie. UV interpolation), which is perfectly legal extension to what's happening in "real" raytracing already, where you adaptively cast more rays within one pixel to get proper antialias on the edges.. here you just move in different direction.

Who cares if your subdivision is 16x16 or even 64x64 pixels as long as the result is correct - or as close to correct as you need (as in the case of a simple plane).

As for the speed of the thing, he most probably hasn't done too much optimization on the raytracing side (and there's a lot there that you can do).

I wouldn't worry too much about more complex geometries, they can be done.. what I would be concerned about is using several different textures, materials, etc, and recursive reflections. All of those have been solved in the software-rendered 64k realtime raytrace intros which you seem to despise so much, and which I admire.

Anyway, this has all been done already with better framerates. Check out this link for hw-accelerated realtime raytracing goodness.

Which isn't to say this is still sort of nice, mind you.

hah! 6FPS is hardly realtime ;P It's still kinda r33t tho...

then again what engine would be able to do toystory realtime?

ehor,
i also believe drop the lensflares but the thing that im unsure about is the 8000+ polys , have u constructed the spheres out of 4000 polys each? if so then thats quite impressive, or are they described as
Q(t) = a*t^2 + 2*b*t + c. personally ive sort of gone off raytracing even thogh the results are *FAR* more impressive than what u achieve with normal polygon modeling it doesnt hold a candle to radiosity (except for speed + yes i know they do different things).
looking at your page 1024x768 at 5fps on a p3-450 is not to be sniffed at, though i wonder how itll handle more difficult scenes.
ild be interested to see how youre gonna develop this further
spot ya

WOW! NICE program! I get about 25fps, but it drops once I get to about ~10000 polygons.

I'm sure you could easily compound this with some other method of rendering and make it run even faster!

I've also discovered a bug in your culling -- cull your billboards. If they end up behind the camera then you can still see them.

Idea - put in a mode to do specular highlighting by raytracing, and not by rendering another billboard; I think that'd look better.

GREAT WORK!
-Louis

Oh yeah, one other thing -

I noticed you're sort of "faking" the texture mapping on the reflective spheres. Wouldn't you have problems doing that with more complicated scenery?

If you're just doing reflection, why not "fake" that too, and use a cubic environment map? It'd be less accurate, but you wouldn't have those subdivision-edge issues, because you could use polygonal models.

Please include some refraction, caustics, or gravitational lenses! I'd like to see that in action.

Hey looks good man. On my P4/GF3 system I get anywhere from 8-40 FPS depending on my distance from the spheres. Panning out a bit and watching the giant shadows spin around is very cool. :D

Keep up the good work.

--Liq

Well I think it's quite good. Very nice work.

Another NZ coder!

God this is really really amazing !

have you tried to implement model loading ? What are you going to do with this engine?

louis

hm.. i have rtrt on 200x200 withOUT any optimisations at 15-20 fps on my p3 500 mhz, means with calculating with about 2x40000 rays ( one time reflected for specular and reflection.. )

what i dont have is texturing..

but anyways, i think if i would blow my one up with each 4 pixels i would get 800x800 more smooth.. ( i can do this simply by maximizing my window, its on a dx-surface means blurred up:) )

i dont say your's is crap, but try to optimize your code, it helps very much.. my one is only algorithm-optimized with a little asm-code. and my one is "real rtrt", not a fake with freakin speculars:)

once i get my new pc i start to code on a real one:)

Are you sure you know what raytracing is and what those 8000 polys mean?

Look at the second picture, it shows you where those polys are!

Gotta agree with everyone else. It seems fast, but it's only 2 sphere's. The sub division seems really good though, but still not enough to consider this thing realtime. I experimented with bresenham lines over a 2d grid like 2 months ago, and the improvements I saw were amazing. In the end, I got around 6fps at 100x100 resolution with reflections (no shadows yet though, got lazy) rendering with over 500+ orthogonal texturemapped polygons in opengl on a celeron 400, tnt2. I know what you are saying, 100x100 ain't nothing. Thats true, but I wasn't using any subdivision at the time. Think of it, I could hit almost the same performance at 800x800 by using an 8x8 sampling. Of course, I would have to throw in more rays to reduce blockiness, but who cares for now. There were planned improvements though, such as a 3d bresenham routine and more primitives, but I fell off the project to pursue another. I wasn't developing it primarily for raytracing though. Raytracing is the perfect visibility scheme(my opinion). I believe that once someone implements the 3d bresenham routine (there have been implementations, just none for gaming purposes), it would be the best way to go. Hey Kurt, you should have a new contest to see who can make the fastest/best looking raytracer.

Never thought I would see a proud mac user :)

Nice that you supply nice code as a keypoint in the raytracer, at least for me well structured and well coded code is something that is often forgiven behind the nice images and demos we provide.

Nice thingy there, I don't know a heck about raytracing engines but it looks cool :-)

Cheers
Albert

well i have written my own realtime raytracer, so i do know a little bit about it ;)
a sphere is an easy object to model in polygons + lends itself well to increasing/decreasing of the polycount, thus enabling u to see how well the raytracer works under higher poly counts.
yes with a raytracers its easier/better/faster to use the actual sphere formula but substitue your 8000poly sphere for a 8000poly person

Hmmm, I don't get the FPS numbers people are quoting. I'm getting 20-30fps if I load the demo without any changes. Obviously, if I up the subdivisions a couple of notches I get about 5 fps.

Also, the flares have black squares surrounding them - looks like the masking routine doesn't work on my card or something. I'm using a GeForce2 GTS.

Cool stuff though :)

= James.

Am I missing something about the fast approximate ray-sphere intersection test that uses a dot product and a scalar compare you claim to have invented? My confusion comes from the fact that the standard method for an exact line-sphere intersection test is a dot product and a scalar comparison, and this gives you exact results for a ray-sphere intersection if you know that the sphere is in front of your ray.

omg! didn't you make that qb crab game? :)