Realtime Ray Tracing in Freebasic

[ferris]

8x8 to 1x1 squares, so I think that's 4.

Stonemonkey: I think I have the source to your realtime attempt!! Might be an earlier one. I'm at church but when I have access to my machine at home I'll see if it's the one!

[Stonemonkey]

That would be cool if you have Thygrion, I've searched through a pile of backup discs and found nothing. Feel free to post it if you find it.

[Jim]

Code might be hanging around here too...somewhere...

@Thygrion - I mean when you get a hit and spawn a reflected ray, how many times can it be reflected?

Jim

[ferris]

At this point none; but I plan to have 2 layers of reflection, i.e. primary ray hits sphere, reflected ray hits wall, reflected ray hits sphere.

[Shockwave]

That looks really good! Runs nice and fast, about 35 fps here in 640 X 480 I'd say I wonder if it will run faster on the laptop (dual core processor).

[Clyde]

I've got to say all this Ray stuff, is very interesting to read. And deserves to be a Star Post. I really like reading and seeing how things develope.

Keep it up dudes,
Clyde.

[ferris]

Stonemonkey: Sorry, haven't got the source, just the exe from when you made it.

Shockwave: It's even faster now, and is getting better!

Everyone especially Voltage : I've been spending my time lately special-casing functions, i.e. merging my interpolation functions into my square functions and having one square function for each size of square. This is alot faster because I can take advantage of knowing the square size which means I can use numeric constants instead of variables, and also it saves function calls. Not to mention there are less variables passed to each function that IS called, so this is working pretty well .

I have a little more work because I'm going to rewrite the interpolation for the 2x2 squares to make them faster, and I'm also going to optimize my shadow checks by storing the last object that casted a shadow's id and checking it FIRST for shadows in the next intersection. I forgot what this was called, but as far as I know it works very well.

After that I'll implement planes, followed by textures, and then I'll either do cylinders or just move straight to CSG.

[Voltage]

Hey,

Cool idea for shadow checking....  Because the shadow ray exits the funciton as soon as it finds ANY intersection...... the most likely object to be casting a shadow, is the last one that was casting a shadow.

I will implement this also.  You are an bottomless well of optimised raytracing knowledge

My sub sampler works heaps better with shadow edges now...  I wasn't checking if the corners were all in or all out of shadow, but now I am.  Now shadow edges are sexier, and I can raise the error metric that checks the difference between colours, which means less rays cast. 

It's looking good.

Reflections are next, then I'm gonna change my sub sampler from a 6x6 non adaptive, to an 8x8 adaptive.  The the shadow optimisation...... and then..... and then....... and then...... 

[Voltage]

Attached is the latest version.... it does one reflection for each intersection point.

The shadows are fixed, and I included the shadow optimisation that Thygrion mentioned.

I also added a FPS counter and an interactive control for image quality...press keys 1-5.

I'm getting about 10 frames a sec on a Dual Core Athlon 64 3800+, with quality 3.

Still needs lots of optimisation, but I'm liking the results so far.

[rdc]

Looks good. Since you are on a Dual-Core you should split your algo into threads; it will run much faster that way as each core will process a thread.

[Stonemonkey]

Yep, very nice. The differences between pressing 1-5 could be quite useful in giving surfaces different properties if it's possible to vary that per object.

[ferris]

Here's my update.

Did lots of stuff, but DID NOT update rtmask.exe.

I'm not happy with the speed, and I have alot of ideas in mind to get it faster that are just general code optimizations rather than raytracer-specific ones.

The scene is an obvious Heaven Seven ripoff, but it's a good test scene

This will probably be my last source release; at a point code gets too precious to let go

[rain_storm]

  Excellent stuff looks so sweet you could eat it

[docgen]

Hi!

Really great work!

[Shockwave]

My gosh, they both look really neat.
Seeing your work and how it's been pushed forward during this thread is a real joy! Both are really really amazing, respect and Karma stuffs to both!

[Jim]

rdc's right - you might get a lot of benefit from subdividing the scene between CPUs.  Even on my P4 HT I was able to double the speed of my Mandelbrot code using 2 threads, and if I'd used a cleverer algorithm to make sure both threads were fully occupied (not one rendering black for ages with the other having finished rendering coloured bits) I could have squeezed out a bit more.

Jim

[Voltage]

@rdc n Jim: Sounds very interesting.  How do I tell one core to do one thing, and the other another?  I didn't know could, it just sounded fast when I bought the thing   

I am fully engaged in leanring how to write a raytracer though, so if it is too steep a learning curve, then I may wait until I've squeezed what I can from the tracer first.

[Jim]

Use the Windows API CreateThread.  You can use that to start a procedure running.  You can pass each proc a different set of parameters and set it off working on a different bit of the scene.  Windows takes care of sharing the work between available CPUs.
So in pseudocode you might do something like

Code: [Select]

sub renderscreen

CreateThread(render_quarter, TOP_LEFT)
CreateThread(render_quarter, TOP_RIGHT)
CreateThread(render_quarter, BOTTOM_LEFT)
CreateThread(render_quarter, BOTTOM_RIGHT)

end sub

sub render_quarter(which_quarter_rect)
...raytrace the quarter
end sub

There are some things to worry about with multithreading which occur when one thread is updating a piece of data that the other thread is reading or updating.  I don't see where that could occur in raytracing though.

<edit>
Freebasic has some of its own thread handling built in, so you may not need Windows API
http://www.freebasic.net/wiki/wikka.php?wakka=CatPgThreading

Jim

[ninogenio]

is it really that streight forward todo multithreading on the windows api i had it that it would be much harder.

how much benefit could be had from multithreading a normal cpu ie my lappy one a pentium m 1.8 i know i depends on what task your multithreading but say i done the abouve and renderd my scene through diffrent threads.

[Jim]

Yes, it can be that simple.  I've just spent the last year with Intel sending me white papers on how to make multithreaded programs (want to sign up?).  They're desperate for people to write their code multithreaded so they can sell more Core2 CPUS   There are things you need to take into account, but you fix those when you need to (runtime library issues, shared data structure issues).  Nearly all my programs use more than one thread now, where convenient.

On a single CPU you might find it slower.  How much depends on the algorithm and the pattern of memory access.

Jim