Realtime raytracing experiments in pure Java

Java 2D
#1

The insanity! But I dared and wanted to see what can be achieved with a simple raytracing engine and a Java2D rendering backend (Java2D isnt’t the bottleneck here, as it turned out).

Edit start

Latest demo without shadows:
http://www.java-gaming.org/user-generated-content/members/132627/simpleray-r5.jar

Latest demo with shadows:
http://www.java-gaming.org/user-generated-content/members/132627/simpleray-r6.jar

Edit end

The results are surprising - realtime raytracing of simple scenes might be possible with Java on current computers. The preview doesn’t look like much, but textures won’t cause a big slowdown, and the two spheres have mirror surfaces, so the core features of raytracing, reflection and refraction seem to be doable. Lightsources and shadows will cause a slowdown though. For this scene, I’d estimate 30% slowdown for each additional light source. I’ll find that out soon. In the demo the balls circle around the center of the checkerboard plane, so there shouldn’t be any caching messing with my timings since each frame is different from the former.

Using one thread on a 2.5 GHz core i5 I get about 30FPS with my current code and three scene elements (two reflective) and 800x600 pixels.

800×600 73.4 KB

I hope I can optimize the tracer itself some more, and when using all (virtual) cores of the CPU there might be a speedup of 3 or more in reach, which is looking promising.

I hope to get a little graphics demo out of this, wanted to do something like that since a while :slight_smile:

#2

wow, go haead and let us to know how i going!!! :wink:

#3

Going well so far :smiley:

Textures took a while, but I now have textures and two worker threads in place to parallelize the rendering process. Didn’t result in such a big speedup, and the thread synchronisation was quite tricky, but it works.

800×600 97.9 KB

I’ve put a demo up - I’m curious to hear if and how well this works on other systems. It does a few ugly hacks in the graphics code, and I feel uncertain if this will work well on other systems …

http://www.java-gaming.org/user-generated-content/members/132627/simpleray.jar

It’s an executable jar file, a double click should run it if you have Java 7 installed.

Also I’m curious how high/low the FPS will go on other PCs. I’m getting something like 30 FPS in average, but the movement isn’t all smooth because some frames take notably longer to render than others. I have not yet found out why. Initially I thought it would skip frames or double-show buffered frames, but the double buffering seems to be alright. It’s indeed the calculation time itself that can go up by 30% for some frames.

Anyways, looks promising and I want to add some light and color effects now to work into the direction of a graphics demo.

Edit: Resizing the window can annoy the rendering code to the point when it stops rendering. If you want to reproduce the bug, you have a 99% chance that resizing will work ;D

#4

62 FPS on an i7 860 @ 3.52GHz.

Why did you need any synchronization? It should be possible to do the ray tracing for each pixel in parallel without any synchronization at all. Shouldn’t each pixel only depend on its own ray?

#5

Would love to try it on Mac 10.6.8, but alas, Java 7 requirement. :frowning:

#6

Oh! That’s solvable! It’s actually possible to download it! FOR FREE! :wink:

#7

Java 7 is not available for 10.6.8. Keep in mind roughly ~40-50% of Macs are still on 10.6.8, and are unable to run Java 7 apps.

Further, Java 7 will not work on OSX Chrome.

Nor will it work with LWJGL, until the devs fix it. So even if I did purchase Mountain Lion, I would need to switch back and forth between JREs in order to run Java 7 apps, Chrome applets and any LWJGL apps.

So basically Java 7 will cost me $30, a long download on my slow wifi, a lot of trouble, and of course all the little problems that tend to come with upgrading your operating system. Not worth it to run a Java 2D application which has no real reason to target JRE7 in the first place.

The whole thing is a pain in the ass. And all of this for string switch? ::slight_smile:

#8

so very do I see the framerate?

#9

Synchronization was maybe a bit misleading. The problem is that the display thread needs to wait till all rendering threads have finished, and then switch the buffer and display the frame while the rendering threads work on the next frame.

Each pixel is independent. Just the threads must keep some order so that the parts come together in the right frame.

I’m not sure if I did it right, but I tried to compile it with “Java 6 binary level”, and I hope this will execute with Java 6, too:

http://www.java-gaming.org/user-generated-content/members/132627/simpleray-r2.jar

It’s also got a bugfix for the mentioned thread synchronization. It might be a tad faster than before. Tomorrow I’ll try to work some more on it. Do the current AMD and Intel CPUs have two real FPUs, or even more?

@Danny02: The FPS are in the window title, updated every second.

#10

35 FPS here. Impressive!

The movement stutters a little. And on some runs the balls simply stop moving, and FPS is no longer updated. No error in the console.

#11

Intel has one per physical core, older AMDs had that too. Newer AMDs (Bulldozer) have one per module (which includes 2 integer clusters), but that one can be used by both clusters and switches pretty fast. On my Core i7 (4 cores, 8 threads), i get 57fps with a cpu load of 25% (i.e. 2 of the 8 possible threads are at 100%).

#12

Thanks! And thanks again for testing on a Mac. It’s good to know that it works there, too.

The stuttering will stay until I try to smooth out the display of frames. At the moment each frame is displayed once it it is ready, and the rendering code for some reason has a notable jitter in the rendering times.

With some luck I could solve the deadlock though. it seems all three threads could run into a “wait()” call, and waited for a notify to continue, which never came because all threads were waiting … I need a clear head and some sleep to look into this again.

A more bouncy version, hopefully with less deadlock:

http://www.java-gaming.org/user-generated-content/members/132627/simpleray-r3.jar

Thanks for all the feedback :slight_smile:

#13

That looks reasonable. The third thread most likely vanishes in the backgground noise because it only does the display and buffer switching. Thanks also for the details on the CPUs!

Next will be to see how much slowdown shadows will cause. And glass bodies.

#14

Sorry I just get a black window. OpenJDK 1.7 update 6

#15

I guess my graphics tricks don’t like that. Can you run it from a console window, and see if there is a ClassCastException or ArrayIndexOutOfBounds exception thrown? I had to reach deep into the raster classes to get Java2D working as a framebuffer for me.

#16

for my works

fantastic!!!

congratulation good job

#17

Steady 80FPS on my i7 2600K with GTX 580. I really need to learn how ray tracing works :S

#18

Ha, I would not have thought of anything like that. It makes sense though.

Can triple buffering help synchronization? (I haven’t read this myself… :D)

#19

If you haven’t happened to think about this…don’t forget cache coherency for your worker threads.

#20

Um, the Raytracer crashes after 2-5 Minutes.
It just stops rendering and shows the last frame.
Is this intentional?

  • Longor1996