Sadly not a single mention of Julia that i ran across though. Several times while in a session the researcher would mention a problem they had and I would scream in my brain “Use Julia! Problem solved!”
As you probably already know, Steven de Keninck and Charles Gunn were there representing the geometric algebra community. They are not Julians but I am constantly in contact with those people and they help promote Julia on the bivector.net website.
The javascript library of his ganja.js could be combined with my Grassmann.jl library to provide a geometric algebra ray tracer in Julia… this might be really convenient in the future since more javascript and Julia integration is being worked on.
I was at that session. It was really good actually. For a 90 min course they did an excellent job of answering the question “why use GA in Computer Graphics?”.
BTW the Computer Graphics in SIGGRAPH is the old school meaning of CG, which encompasses Simulation, Animation, Surface Modeling/Editing, and all the other things you might do on a computer before displaying it in a non-text buffer, as well as actually Rendering.
I was quite involved in computer graphics as a hobbyist some time ago — mostly in the aqsis renderer (sadly defunct) and somewhat in OpenImageIO + a tiny little bit in OSL.
You’re absolutely right that Julia is perfect for that use case: so much of production rendering is about high performance numerics combined with scripting. Neat example: OSL introduced pervasive automatic differentiation for shaders back in 2010 or so. OSL / OpenImageIO have their own type system, mostly for talking about computer graphics primitive types. OSL uses LLVM as JIT for shaders. As neat and extremely well engineered as those systems are, all this could now be done directly in Julia without needing to reinvent things like a type system and JIT. I think a production renderer in Julia would be really interesting.
Exactly. I saw several examples of things being reinvented that could be done with Julia now. The most painful was seeing a (failed) C++ template implementation of reverse-mode auto diff. Was considered a failure because even this simplest use-case took ages to compile.
For example, this presentation on youtube goes into detail how difficult it is to make a fully generic geometric algebra implementation without Julia:
The Grassmann package I made is in my opinion currently the most advanced geometric algebra software in existence, since I fully took advantage of the Julia multiple dispatch and I designed a new pre-compile-safe way of adaptive caching for fully generic sparse geometric algebras, with seamless sub-algebra interoperability. This would have been nearly impossible with other languages, and since I used metaprogramming and code generation the entire code is only about 3000 lines and easily maintainable (only if you understand my design choices). It would take a lot of explaining to another developer, but for me it is fairly easy and lovely to maintain.
No, not necessarily all code is easily maintainable. What I mean by easily maintainable is that it is easy for me to make huge changes to my program with big ramifications by only editing one line of code. This means it is very easy to do more with it, requiring less work and maintenance. I doubt “all” code is like this, but when using Julia it is much easier to do things like that as opposed to say C++.
I was being sarcastic (a lot of code has design choices which are only apparent to the author). Sorry if it did not come across. I did not imply anything negative about your code in particular.