Just to start a bit of a chat really....
I came across an old raytracing program, it in C, it pumped out a binary file with the colour information, I have jigged it to use SetPixel and draw to a window. I spent a good few days along time ago optimizing it, until for a 320x240 resolution I could get about 5 frames a second - this is still using SetPixel, and a standard window, and in C....
Given that this was running on a P3-550 and I now have a 1Ghz machine (almost entry level) what do you guys think that a real-time raytraced game is possible?
umbongo

If I look to some actual 3D games it seems to be already realtime
and real-life quality.
Most games have a huge amount of effects, like bump mapping,
light sources, fog, smoothing, etc.
I often wonder what else will there be possible in the future?
beaster.
by the way - I think SetPixel is likely the slowest GDI function :)

You're right, SetPixel is one of the worst GDI functions, as it has to have the GDI cache flushed before and after it is executed! However I wasn't including it in the tracing time as it's not realistic to use it.
You mention smoothing, it is interesting to note that using raytracing a sphere is made of of 4 values - x,y,z and radius. All the rendered parts are calculated. Using normal 3D techniques a sphere has to be made up of flat pieces, so it takes alot of power to render spheres, where as in raytracing it doesn't take that much, and no matter how close you get to the sphere, it doesn't look 'blocky' so smoothing isn't an issue.
umbongo
This message was edited by umbongo, on 6/12/2001 6:27:01 AM

Not to rain on your parade Umbongo, if fact I think its a good idea but it will require alot of horse power.
You see using raytracing techniques every pixel on the sphere will require complicated 3d maths. Using the face mesh method of OpenGL and Direct3D you need only proform complicated maths for 3 points and then fill in the triangle they make with quick 2d integer maths.
But still with some clever optimisations I'd say it could work. Just brush up on that coordinate geometery. Seriously though I intend to write a series of 2d and 3d coordinate geometry and trigonomitry routines into asm procedures this summer. Lines intersecting other lines, spheres, etc. I'll setup a site and post them here, maybe they'll be of some use to you.

the maths for the sphere is :-
vector subtraction
2 dot products
a sqrt (yuk)
a couple of compares
a vector add and subtract
a normalise.
Admittedly this is more than you'd get for the OpenGl versions, and we have to remeber that reflection in Raytracing will have to do the sphere again. But it's not that much.
Getting rid of the sqrt is the biggie here, and, if we get clever, we can cast a ray into the centre of the sphere and calulate the pixels that will definately be in the sphere (based on the radius and distance) then the first 1/2 of that routine isn't needed as we alreay know the ray has hit.
see - I can almost see the sunshine from the parade ground....
umbongo

What you want here is a routine for calculating the intersection between a infinite line (or would you prefer a line segment) and a sphere.
You couldn't know how tempted I am to sit down and spend the rest of the night writing such a routine, but for a week at least I have to resist the temptation as I'm in the middle of exams.
But I know I will write it once I'm finished, even if only for myself, as this is the the type of routine I enjoy writing. Sad maybe, but hopefully I'll get a good job out of it.
Anyway in the Agner Fog hlp file there are two routines for calculating sqrt faster, at a drop in accuracy. If your program can still work with this sacrifice then it may be helpful.
This message was edited by Zadkiel, on 6/12/2001 1:45:17 PM

Chunks of it

**had**been re-written in assembler, but I lost that version when my PC got stolen (I know, I know, make backups!) But it was a little scrappy anyway, so I'm thinking about starting it again now... the biggest single speed up was to calculate the vectors for the sweeping ray from the screen by using static increments instead of doing all the dot products and things each time.. that made it fly... Still, I think it would be feasable to get a space game (where there aren't too many polygons basically) and it would look excellent if you could fly past another ship and see your own ships reflection in his canopy (a curved reflection too!) umbongo This message was edited by umbongo, on 6/12/2001 2:41:36 PMHi
Strange how i was thinking to the same thing a few day before....
Our team use POVRay(c) to do our game GFX
and it is Open Source i belive...
I was tempted to rewrite it in ASM or to write
a raytracer from scratch in ASM...
i belive this will somehow make it "real time"
Why? well because raytrace has a lots of advantages like:
1.Real Shadows.
================
Most 3D scanline (triangle driven) cant do real shadows, they do tricks to make u belive its a corect 3D shadow bit its noy. Check your games to see how many of them just have a bitmap placed instead of the shadow. Doing a shadow in 3D requires a second rendering for EVERY light in the scene ...this in not possible today *think at 8 lights in OpenGL ;)
2.Real Reflections.
=====================
There is again no real reflection in today 3D games...just simulated one. First they use a big specular value to simulate shiny surfaces then they make an environment maping image and blend it over...this in NO REAL reflection just a phatetic replacement
3.Refractions
================
Watter and Glass have and IOR...3D scanline CAN NOT do this also
4. Easy simple and powerfull algorithm (i belive)
5. ETC
=======
there are a lots of other effects or real life things that
today 3D render algorithm (scanline triangle based) can
not do in a decent way (fire media, radiosity etc, eficiaent backface culling)
Raytrace algorithms are simple and CAN do A LOT of those effects
However they require a lots of brute calculations...
but sometimes less (they do a kinda automatic backface culling)
this eliminates the nees for BSP trees and gets them in
advantage in some kinda aglomerated scenes but with large spaces also
I belive is possible to combine the power of ASM
and the speed of today micros and time has come
to do some Realtime Raytraceing...
examples in the demo scene write the word on the walls:
Ray Trace is the future of 3D ... lets get it work ;)
So... ;) if anybody can send me a simple/easy raytracer in ASM
or even basic C or the join forces and start this project together
(because i have little time free left with my current overwhelming projects and being lazy) its wellcome.
Some algorithms explained for a dummy (ie me ;) ) will also help.
Bogdan

Bogdan,
I've got some straight C code, it's pretty eas to read and the actual raytracing code is quite small.
Currently it uses rectangles for faces, which I had changed to triangles with a really fast algo I found on the net, it was about 4 times faster, but obviously it had to do twice as many check, even then it was still twice as fast.
I'll see if I can find it again.
I have the untouched original code somewhere too...
umbongo

OK send me anything u have, even evil C ;)
i will start to convert it to asm ...
however i belive primitives like spheres,etc should be parametric equations like X^2+Y^2+Z^2-R=0 (sphere) and intersections to this are faster then a lots of triangles or quaterions that tesselate a sphere ;)
a separate MESH object should be used for such triangles and quaterions.
we will make it a free open source project for this forum? ;)
then add a moddeler, then make it better then XX Max then we get rich ;) ... OR try to make a 3D game with it (if its fast enough) ... i was going to make my next game a 3D one anyway ;)
This message was edited by BogdanOntanu, on 6/13/2001 6:48:47 PM

Bog,
I'll send it from work tomorrow (today now actually), the reading of the files is pretty messy, but thats not the bit I considered important.
On the open project front, I though Hiro was migrating the board so we could have files areas etc etc etc???
umbongo