Path Tracing

I have been writing a Java-based Path Tracer recently.

Here is my current result:

Edit: I forgot, it maybe should have been posted in the Java section instead.

… just because there’s a java icon in the image means this should be in the java programming section? I disagree. The java programming section should be questions/topics relating to the java programming language itself. Not a project that just so happens to be written in java (he didn’t even explicitly sate anything that has to do with java).

[quote=“imthenull, post:2, topic:549517”]… just because there’s a java icon in the image means this should be in the java programming section? I disagree. The java programming section should be questions/topics relating to the java programming language itself. Not a project that just so happens to be written in java (he didn’t even explicitly sate anything that has to do with java).[/quote]I mean, he did kinda edit his post before it was moved saying it should be in the java section.

fair enough.

Now I have uploaded a beta version of this project to GitHub. It can be seen at: https://github.com/macroing/Dayflower

[quote=“Davidi2, post:3, topic:549517”][quote author=imthenull link=topic=668417.msg4470429#msg4470429 date=1422656250]
… just because there’s a java icon in the image means this should be in the java programming section? I disagree. The java programming section should be questions/topics relating to the java programming language itself. Not a project that just so happens to be written in java (he didn’t even explicitly sate anything that has to do with java).
[/quote]I mean, he did kinda edit his post before it was moved saying it should be in the java section.[/quote]Why is there even a section solely for Java programming? I don’t understand the logic behind it.

@object: This is actually very impressive. Do you plan on making the ray tracer interactive? That would be neat. Is this project for learning purposes, or for something specific?

This is fascinating, and I’m really impressed that it was written without using any libraries. Was going to check it out to see how you accomplished something like this with openGL/lwjgl but you didn’t use either

EcoPS GM: Thanks! My plans are to support interaction using a movable camera. But for this to work practically, the quality of the graphics most certainly has to be lowered. At least for the time being. The images shown took around 10 hours to render on my fast laptop.

Eyeownyew: Thanks! I have plans to port the Path Tracer to OpenCL. A few months ago I even tested using a library or framework called Aparapi, which transforms Java bytecode to OpenCL code on-the-fly. It turned out to be pretty hard to get the algorithm to work, as there are many limitations in both Aparapi and what can be done in OpenCL. You can’t, for instance, use recursion in OpenCL (or on the GPU for that matter).

This looks very neat! Though, I’m curious - how come there isn’t any anti-aliasing? I’m not too familiar with how this works, other than this style of rendering is known as “baking” and the longer it’s baked, the better the scene looks. But since the rays surely work on a geometry-based/sub-sampling basis, shouldn’t the edges of lights and such be smooth? Also how did you test this if a scene took 10 hours :stuck_out_tongue:

Also, while this is HLSL and not GLSL, there are ways of cheating recursion on the GPU. Not sure how applicable that’d be though.

Lin:

Thanks!

About anti-aliasing; it has anti-aliasing, but I don’t really know why the light is not anti-aliased as you could expect. I must have done something wrong there. But I have plans to fix it at some point.

Path Tracing is a form of Ray Tracing, in that it casts rays from each pixel into the scene. The primary rays are what constitutes Ray Casting (another more simple algorithm). Ray Tracing and Path Tracing both cast more rays, so called secondary rays, from each surface intersection point. In contrast to Path Tracing, Ray Tracing has to cast so called shadow rays, in order to determine whether the intersection point is visible. Path Tracing treats each and every shape in the scene as a light source (or emitter). But one inherent difference between the two, is that Path Tracing casts rays in a random direction in the hemisphere of the surface normal of the surface intersection point (and from the pixel itself). So it’s a Global Illumination (GI) solution to the rendering equation.

The anti-aliasing is done by 2x2 pixel sub-sampling.

You’re right in that Path Tracing gradually makes the image look better. It converges to the correct solution.

I test it by simply starting the program. It updates all the time. So I can see the image pretty much immediately. Although it will have a lot of noise in the beginning. The longer it runs, the less noise will be reduced, as there are less noise to reduce.

Edit: I actually found a fix for the anti-aliasing issue with the lights. If I render to a larger image and then down-sample it to the expected resolution, it works. It’s a form of Supersampling.

[quote=“object, post:8, topic:549517”]EcoPS GM: Thanks! My plans are to support interaction using a movable camera. But for this to work practically, the quality of the graphics most certainly has to be lowered. At least for the time being. The images shown took around 10 hours to render on my fast laptop.[/quote]Holy moly! 10 hours haha, I would have never waited that long for a scene to render. Why didn’t you use libraries to make the loading process faster? I mean, it’s more impressive to do it without libraries, but still. That’s dedication! I cannot wait to see upcoming additions to this.

EcoPS GM: I did the rendering over night. So I didn’t sit and wait for it. :wink: As for additions, I’m not giving up on this project. So I may very well add new stuff in the near future. Like new shapes. Then I’m also looking at getting that SimpleCamera class replaced by my other Camera classes, that I used in an earlier version of Dayflower (the name of the engine). But I havn’t been able to get it to work just yet.

Oh I most certainly hope you didn’t wait for it! I’m not judgmental, however that would be a case I’d feel obligated to judge you on, hah. Nonetheless, I’m sure you’ll get the Camera working in the near future. With hard work and dedication - workload will pay off! Honestly, I’m not active in Mopar at all, however this project is virtually the sole reason that sparks my activity here. I’m actually very interested in this.

Now I have added support for super-sampling with down-scaling and some other minor things.

Bump. I hope new updates are arriving.

EcoPS GM: Yes, new updates will arrive at some point.

Edit: Actually, new updates were added yesterday. It’s now possible to switch between “realtime”- and normal-rendering. The realtime rendering is currently not that fast, hence the quotation marks. But there are many configuration-options in the code that can make it faster. They are not exposed in the UI at this time. And, you can’t move the camera yet either.

Edit: More has been comitted to GitHub. Now it’s possible to walk around using your WASD-keys. Realtime rendering is now done without actual Path Tracing. It just returns the “albedo” color of the surfaces themselves, so it’s faster.

Just checked up on this - very nice progress, object! Any particular reason you’re making this, or just decided so on a whim?

EcoPS GM: Thank you! :slight_smile: I’ve been interested in 3D graphics for a long time. Both realtime- and photorealistic rendering. But I do it as a hobby project. At least for now. Although that GitHub account was created recently, the engine wasn’t started on “yesterday”. It has taken quite a while to get it to this state. Many such projects have been created and abandoned in the past. :stuck_out_tongue: Rasterizers (Scanline Rasterizers) and Ray Tracers (Whitted Ray Tracers and Path Tracers).

Edit: My ambision is to combine both realtime- and photorealistic rendering in one renderer. With options to favor one over the other, such as lower quality graphics and faster rendering vs. higher quality graphics and slower rendering.

[quote=“object, post:18, topic:549517”]EcoPS GM: Thank you! :slight_smile: I’ve been interested in 3D graphics for a long time. Both realtime- and photorealistic rendering. But I do it as a hobby project. At least for now. Although that GitHub account was created recently, the engine wasn’t started on “yesterday”. It has taken quite a while to get it to this state. Many such projects have been created and abandoned in the past. :stuck_out_tongue: Rasterizers (Scanline Rasterizers) and Ray Tracers (Whitted Ray Tracers and Path Tracers).

Edit: My ambision is to combine both realtime- and photorealistic rendering in one renderer. With options to favor one over the other, such as lower quality graphics and faster rendering vs. higher quality graphics and slower rendering.[/quote]
Don’t Forza and other racing games do that? I’m pretty sure the car body and windows, etc… are ray traced and the rest of the scene is polygon modeled.

Limits: Yes, that may very well be the case. Although, polygons can themselves be ray traced. But I’m sure you mean rasterized?