Anti Photon Engine - A SFML driven (realtime) Raytracer

[Lord Delvin]

I wrote together with a friend a lib that allows the creation of CPU based realtime raytracing applications. Realtime is atm. not 2 MegaPixel fullscreen with 16 sampels perpixel, but hopefully it will be some day.
We just finished our work on 0.2 version, which is the first version that offers others to use our lib, as it includes not only demos, but also the headers and libs needed for development, documentation and some tutorials.

SFML is used to implement the ScreenBuffer, that is a device that talks with the OS and puts Pixels onto the screen.
In 0.1 we used also Threads but decided to move to boost.

As for 0.2 the libs are not fast and we got a lot of features that are currently unused we decided to work on a 0.3 version which will look the same, that means programmers wont need to change their code.
This 0.3 version will bring you needed speed and implementations and hopefully far more tutorials.

Have fun with this: http://www.determinationmusic.de/package.7z

EDIT: Any feedback is very welcome!

[Kreeg]

Incredible !
I noticed this file is hosted on the server of a metal (?) band. Nice tune on the page !

[Lord Delvin]

Its the band of my coautor Jonathan.

Anyone who wants to become tester is welcome. I would give you individual support if you wish:)

[Lord Delvin]

For those who dont want to download my package, here are some screenshots I put together:



The big one is a solar system demo. The background stars texture has a too low resolution, thats not our fault, as we allow any size for textures as long as it fits into RAM.

Small imagase top to down:
First is a point based camera that moves around in a box with two spheres and a flat blue mirror. You see things from short above the "glas" sphere.

Second is a short demo of the pixel shading system. It creates some sort of edge detection and greenish depth based fog. Both takes about 10 lines of C++.

The last image is done with only 80 lines of code at all. It uses two textures for normal mapping and three for diffuse/emissive color. The scene contains 0! Triangles: There is one ellipsoid and six quads.(Quads are exactly as fast as triangles so there is no need for them)


It would be nice to have more feedback;)

[Lord Delvin]

For those who dont want to download my package, here are some screenshots I put together:



The big one is a solar system demo. The background stars texture has a too low resolution, thats not our fault, as we allow any size for textures as long as it fits into RAM.

Small imagase top to down:
First is a point based camera that moves around in a box with two spheres and a flat blue mirror. You see things from short above the "glas" sphere.

Second is a short demo of the pixel shading system. It creates some sort of edge detection and greenish depth based fog. Both takes about 10 lines of C++.

The last image is done with only 80 lines of code at all. It uses two textures for normal mapping and three for diffuse/emissive color. The scene contains 0! Triangles: There is one ellipsoid and six quads.(Quads are exactly as fast as triangles so there is no need for them)


It would be nice to have more feedback;)

[Tank]

I really like your raytracer, it produces high-quality graphics. Too bad my CPU is too slow to get some nice FPS (currently I get < 1 FPS).
Keep up the good work!

[Lord Delvin]

I really like your raytracer, it produces high-quality graphics. Too bad my CPU is too slow to get some nice FPS (currently I get < 1 FPS).
Keep up the good work!

Thats unexpected, but good to read. As we are working with big buffer objects(96bit Colors, Ray gc, etc.) its good to have more then 1GB RAM and 200Mhz clock(that would be 800 for DDR2).

On my dev machine, an amd X2 4600+ with 6GB of high performance DDR2 RAM, I get for most demos between 2 and 7 fps and for Solar System in the shipped way about 40 to 44. The big difference how ever seems to be produced by the sceduler of ubuntu, as linux64 builds seemed to be about 50 to 100% faster then the windows ones even in wine demos seem to run a bit faster.

If you reduce resolution to about 200x200 you should get "realtime" by now...well but there is a lot of work and conversions from C++ to SSE asm in some places deep inside you wont see, so you can get 30FPS on some sort of quadcore(whats btw below our target platform, as we thought it would take us much longer to add so much functionality) in some normal low resolution such as 800x600, what would be okay for real applications.(If you start devolepment at this resolution and you finish a year later, the advancement in our and at hardware side will be enaugh to allow resolutions around 2M Pixels.