Instead of doneCount.incrementAndGet() the r4 had a doneCount++ there. But since the whole method is synchronized, there was no race condition there, and it was sufficient to have the variable volatile, to make sure all cores have the same value.

Learned something again. I must say in all the years of using Java I didn't learn as much about concurrency than in this small project. It's been good to try

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.

The latest version (-r4) works, I get 11 FPS on my Intel Inside Pentium D. When I maximize the window, it becomes really slow.

I'm writing the data to a BufferedImage and draw that through a g.drawImage() call. It's surprisingly fast, because I can use images without alpha channel.

The code looks like this - the real tracing code is in the object.hit() and object.trace() methods. I've tried to keep the framework expandable to have more object types but planes and spheres. TracerDataSet is kept in one instance per thread. linepix is an int [] which will take the pixels of one line. Ray, p, lineV and the like are instances of a 3D vector type. Look is the looking vector of the viewer into the scene.

The code is there now. It's a bit farther evolved than the one used for the demo in this thread, but it didn't cut into performance too badly. The SimpleRay class has a main method which you can run and which will show the demo scene:

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org