Realtime Ray Tracing in Freebasic

[rdc]

As Jim mentioned FB has built-in thread support. See threads.bas in the example folder of your FB installation. When you use threads the CPU will automatically allocate a thread to a core, so all you need to do is to add thread support to your program.

Even on a single core CPU you can gain some benefits from using threads. For example, a thread can be calculating while another thread draws something on the screen. The drawing process may take longer than the calculation process, so when the drawing is done, a fresh set of calcs are waiting to be drawn. On a dual core the calcs and drawing would happen at the same time so it would be much faster. On a single core it would time slice, but may still be faster than a serial operation (calc-draw-calc, etc). You would just have to try it and see.

[rain_storm]

Is it a problem with multithreading that if one thread lags behind the rest than the whole program only runs as fast as the slowest thread?

[rdc]

Your program is only going to go as fast as the slowest part of the program, regardless of whether you use threads or not. A thread can bottleneck a program of course, but if you structure it correctly it is really not much different than a program that doesn't use threads. The only real danger of using threads is a deadlock, where two threads are waiting for each other to finish. However, this can be easily avoided by just using proper structure, and using some flag variables to indicate when a thread has completed.

There are a couple of approaches to using threading. One approach is to use the slow parts of the program to do additional work to gain an overall speed boost. As I mentioned above, if drawing takes more time than the calcs, you can do a fresh set of calcs while you draw a scene. This way the drawing routine is always working and doesn't have to wait for new calcs.

The other approach is to divide and conquer. If a routine is too slow, you can break it into parts and work on each part at the same time. If the drawing routine is too slow, you can break it into 2 threads each thread draws half of the screen. If the calcs are too slow, you can divide the calcs in the same manner with each thread doing part of the work.

You can also mix the two as well.: While one half of the screen is being draw, you are calculating the other half that will be passed to the render. While the second half is being drawn you are calculating the first half of the next frame.

How you approach it just depends on what bottlenecks you have that may benefit from threading and how to synchronize the different threads to handle the work. It isn't all that complicated, you just have to approach the problem with a clear idea of what you need to do and when you need to do it.

Threads aren't magic bullets either. Some program just don't benefit from threading. A ray-tracer though should be a good candidate for threading, especially on a dual core system. The more you can do simultaneously, the faster your program will be in the end.

[rdc]

One amendment to my previous post: I believe FB gfx lib isn't thread compliant so you wouldn't benefit from having threads do the actual drawing. (You might to want to double check this with the FB dev team on the FB forum.) However, you could sill use threads for calculations while the main program draws the frame. Anyway, it is just an option to keep in mind as you work on the program.

[Stonemonkey]

cool stuff Thygrion.

[ferris]

This is the latest update. Basically the point was to minimize subdividing around reflection objects, which explains most of the jpg-like artifacts.

I need to optimize the hell out of this CPU-eating beast, but when that's done and the tracer's done I'll comment it all and put it up here.

I like the image quality myself (I use the same cheats H7 uses ), but tell me what you think.

As far as freebasic goes, I've found my old sources! Also reinstalled drivers so I can stream my neighbor's internet once more, so I'll try to post some stuff up tonight

[Shockwave]

Beautiful, textures and everything and it runs fast too.
Stunning stuff man.

[ferris]

If only it ran fast here

I know the problem is all the double-texture interpolation and such...I'm going to rewrite those routines (rtrt/engine/tracer.cpp, look at tracersquare8 etc....ouch!) and it should be alot better afterwords.

How's your tracer coming, Voltage? Haven't talked in awhile.

[p01]

shiny!

[rain_storm]

Runs really fast here in all but the 640x480 resolution which is not quite realtime but still framerate isnt too bad at that res but its really good quality I notice that the walls seem to reflect more than one ball so how many times does the ray bounce around? its gotta be more than twice

[ferris]

Nah it's just twice. Which is why sometimes you can see a reflection of the ball on the ball and it almost looks like it has 8 walls rather than 4

[Clyde]

Hows it going Voltage dude?

[Voltage]

*bump* accepted.

I haven't done much on this recently...  we have a new baby(girl), just got engaged, and I have my Hapkido black belt grading on this Friday.  Been a little busy. 

I'm still fired up to make this thing a reality though, so thanks for the interest.

Voltage

[Clyde]

Cool and welldone dude, best of luck on Friday.

Cheers,
Clyde.

[ferris]

Hope all goes well, I want a preview!!

[Shockwave]

Congratulations on your baby girl btw Voltage I think I posted it in the shoutbox, but well, here it is again just in case

[Voltage]

@Clyde and Shockwave:  Thanks dudes.

@Thygrion: Preview of what?  My engagement?    That's a little personal. 

If you want I'll post a vid of my grading, I've gotta break some tiles for this one. 

[ferris]

Lol...sorry I switched the subject there

I want another tracer preview!

[Shockwave]

This is so fucking great. I had to revive this topic, here is a screen for people who don't know what they are missing!

[va!n]

Wow, looks awesome... is it possible to get a compiled version? thx