Show HN: A physically-based GPU ray tracer written in Julia (makie.org)
We ported pbrt-v4 to Julia and built it into a Makie backend. Any Makie plot can now be rendered with physically-based path tracing.
Julia compiles user-defined physics directly into GPU kernels, so anyone can extend the ray tracer with new materials and media - a black hole with gravitational lensing is ~200 lines of Julia.
Runs on AMD, NVIDIA, and CPU via KernelAbstractions.jl, with Metal coming soon.
Demo scenes: github.com/SimonDanisch/RayDemo
21 comments
[ 4.9 ms ] story [ 45.0 ms ] threadI'm asking because I had a lot of trouble trying to describe interfaces between materials, only to find out that what I wanted to do was not possible in PBRT without modifying the code. Apparently, in PBRT a material can only have one other material touching it. So, for example rendering a glass filled with water and ice is not possible without hacks. From a user's point of view this is a bit of a let-down, of course.
Context: https://news.ycombinator.com/item?id=45668543
Re: the compilation latency discussion — it's a real tension. JIT gives you expressiveness but kills startup. AOT gives you instant start but limits flexibility. Interesting that most GPU languages went JIT when the GPU itself runs pre-compiled SPIR-V/PTX anyway.
My own take is that Julia didn’t since the two language problem as much as was defeated by it.
Julia didn’t attract the high-level Python data science crowd because of Julia’s latency issue, lack of package ecosystem, and the inconveniences that a high performance compiled language incurs, such as having parametric containers.
The research software engineer crowds didn’t buy in because Julia has no interfaces or automatically checkable behavior, poor static tooling, imprecise semantics which is hard to build abstraction on, and a complex performance model that makes it hard to ensure speed, and is hard to deploy.
So, where they tried to make a language that can span the gap, they succeeded in making a language that works for neither, and which no-one wants.
I like the language. But after having used it for eight years, I find it increasingly hard to argue against the point that it’s better to choose Rust for software engineering and Python for scripting.
Edit: I should say: I used it for eight years because it IS fine for my specific niche: High performance research software engineering. Where I care neither about the convenience of Python, nor need to write truly robust and maintainable code. Where my choice of language was personal and I didn’t need to convince a team of coworkers.
https://github.com/NumericalEarth/NumericalEarth.jl
https://github.com/Marco-Congedo/Xloreta.jl
https://github.com/slink/ZwickerLoudness.jl
>the reference implementation from Physically Based Rendering (Pharr, Jakob, Humphreys)
I'd like to know a little about the process you went through for the port. That book * sounds like an excellent resource to start from but what was it like using it and the code?
* https://pbrt.org/
This is why I wish Julia were the language for ML and sci comp in general, but Python is sucking all of the air out of the room.
It’s like calling a framework Mike
Waving around an outdated blogpost as if it would automatically invalidate everything is just silly at this point.
They were paid to do this cool thing and possibly to post it here as well but if you dislike "capitalist pigs", maybe you shouldn't browse yc.