( almost :) ) Realtime Java Raytracing

Shared Code
#1

Hy everyone.

First, please sorry for my poor english but i’m french.

Here is my first raytracer in java. With low parameters, i’m close to realtime. On my computer - core
i5 2500K 4 cores at 4.2ghz - the demo’s scene - 17762 triangles - is about 3 fps with a screen at 600x400.
With higher parameters (anti-alliasing, smooth shadows, higher recursion), it can be very, very slow.

You can configure the raytracer with the « Param.txt » configuration file in “_Param” directory. All the
parameters are explained and easy to understand.

Some coding tips :

KDTREE:
I’m using 2 kdtree for this demo.

  • 1 for static objects that use SAH optimisation.
  • 1 for dynamic objects, that must be rebuilt on each frame, with middle splitting axe. With « symetric »
    objects, it’s not very much slower than SAH.

The KDTree build is multithreaded. At level 2, 4 threads are created. After, for the SAH version only,
if there are enough faces, 3 threads are created, one for each plane to check.

I use another optimization : as the triangles coordinate are sorted on the current axe, we don’t just use
left and right child, but i introduce a middle child, that was copied to the right child.

ANTI-ALIASING:
When turn on, the rendering is made twice :

  • The standart one
  • One the second pass, each pixel is compared to the 4 around. A delta is computed. If this delta
    is higher the a value (AA_DELTA_COLOR in parameter’s file) then AA_LEVEL rays are fired.

SMOOTH SHADOW:
For smooth shadow, i’m using a poisson distribution on light area (each light have is own rectangular
area) to avoid banding.

I’m a developper, not a graphist, so sorry for the demo’s scene that I know to be awful. All the
algorithms used come from the web. I’m just tried to use the best. I’m not a great programmer, as
i can see in this forum, so, please, be gentle with me and thank’s for reading my code and give
me you’re feedback and what can be improved. In particular, the normal mapping part, that i’m pretty
sure to be false. The most important classes are RT_SCENE.java and RT_KDTREE.java

Java 7 is required (i think)

Thank’you.
Fred

The executable jar
The eclipse jar (kepler)

http://s22.postimg.org/68ntb0y1d/JRay.png

#2

Well… yeah. Almost :smiley:

Get 1 FPS when minimized and with the lowest settings.

4 cores, 8 threads, 3.3 GHz.

Each frame takes about 10 seconds, when I turn on antialiasing and especially when I turn on smooth shadows. Looks really, really nice tho, and runs fast for what it shows!

Keep it up!

#3

:o

#4

i7 2600K @ 4.5GHz: 3 FPS \o/

#5

Might not be useful in games but it looks darn beautiful!

#6

I just tried it.
I win with 4 FPS! Looks great ;D

#7

good work! back in the day I attempted to make a real time ray tracer for a java4k competition… I did get it to fit in 4k… but with no room for game play :stuck_out_tongue:

I did have an interesting ( and to my knowledge novel ) idea for ray triangle intersection test which may be quite fast… i never did follow it up, but if you want i can outline the algorithm to see if it gives any speed improvements.

Oh I found a version of that realtime raytracer: (well before i started shrinking it :stuck_out_tongue: )
[applet archive=jrtrtapplet.jar class=org.moogiesoft.JRTRT.TestApplet width=800 height=600]
Up/down arrow = thrust
left / rigth = roll
Mouse drag = move mouse view.

(Not sure why the Embeded applet tag is not working :frowning: )

#8

Thank’s.

I’m using barycentric coordinates algo for ray-triangles intersections from :

http://www.flipcode.com/archives/Raytracing_Topics_Techniques-Part_7_Kd-Trees_and_More_Speed.shtml

#9

Hehe, that site looks familiar :slight_smile: I think i have used it in the past.

The ray/triangle intersection method that I had though up is to replace the barycentric coordinates conversion and subsequent tests with three simple distance tests.

The main thought is to approximate the triangle vertices as arcs on large radius circles: as the radius of a circle gets larger, an arc of of that circle of a fixed length starts to look like a straight line.

So to perform a ray-triangle intersection test:

  1. calculate the intersection with the plane of the triangle
  2. test to see whether the origin-intersection distance is less than the radius. If greater then stop as it does not intersect the triangle.
  3. repeat 2 for remaining vertices.
  4. ray does intersect the triangle.

Of course to speed up this algorithm i was planning to precompute and store the origins for each of the circles with the triangle and to only compare the squared distances (i.e. no square roots necessary)

To calculate the origins for each of the circles:
-take the 2D normal of a triangle vertex and project inward from the mid point of the vertex by a sufficiently large radius.
-for optimisation, the radius would be a constant and used for all triangles.

This algorithm is not limited to just triangles, any convex polygon can be represented by simply increasing the vertices checks.

There is a potential bonus property of this method, it should reduce the visibility of seams between triangles in a mesh as the triangles will be slightly bulging.

However this method may have some strange effects due to floating point precision between large and small numbers.

I never implemented it so if you do I would love to hear if it works and if it provides any speed boost.

#10

Infact I was going to use a modified version of this algorithm for the java 4k real time ray tracer. To help save code size I was was only going replace the ray-plane intersection test with a ray-sphere intersection test. In the same way as a arc of a large circle can approximate a vertex, a large radius sphere can approximate a polygon face.

#11

I just had a thought: it is probable that you can skip calculating step the mid point of a vertex: given sufficiently large radius, and arc will approximate a straight line and thus the difference in distance between a triangle vertex of an edge and the origin as compared to the mid point of the edge to the origin will be minuscule.