Jax's true calling: Ray-Marching renderers on WebGL
1–10 of 15 posts
Re: Jax's true calling: Ray-Marching renderers on WebGL
#2Pytorch is such a maddening mess of half implemented research features in a state of Heisen-deprecation, Jax becomes more appealing to me by the day.
Re: Jax's true calling: Ray-Marching renderers on WebGL
#3Moving my thumb across the image causes the ball and cube graphic to disappear to black and then scrolls the page. Firefox on iOS
Re: Jax's true calling: Ray-Marching renderers on WebGL
#4> the thing JAX was truly meant for: a graphics renderer
I mean, just like ray-tracing, SDF (ray-marching) is neat, but basically everything useful is expensive or hard to do (collisions, meshes, texturing etc.). I mean mathy stuff is easier (rotations, unions/intersections, function composition, etc.) but 3D is usually used in either modeling software or video games, which care more about the former than they do the latter.
Re: Jax's true calling: Ray-Marching renderers on WebGL
#5Yeah GPU compilers will be used for way more things than AI because parallel = good
Re: Jax's true calling: Ray-Marching renderers on WebGL
#6Moving my thumb across the image causes the ball and cube graphic to disappear to black and then scrolls the page. Firefox on iOS
Me too, Chrome on Android.
I like the concept of applying Jax to SDF sphere tracing :)
Re: Jax's true calling: Ray-Marching renderers on WebGL
#7> the thing JAX was truly meant for: a graphics renderer I mean, just like ray-tracing, SDF (ray-marching) is neat, but basically everything useful is expensive or hard to do (collisions, meshes, texturing etc.). I mean mathy stuff is easier (rotations, unions/intersections, function composition, etc.) but 3D is usually used in either modeling software or video games, which care more about the former than they do the…
Games and simulations are typically stateful, I'm not sure the functional purity of JAX is a good fit.
Also, what's the story for JAX + WebGL when it comes to targeting hardware-accelerated ray tracing?
Re: Jax's true calling: Ray-Marching renderers on WebGL
#8Yeah GPU compilers will be used for way more things than AI because parallel = good
We’ve come full circle and started using Graphics Processing Units to process graphics again
Re: Jax's true calling: Ray-Marching renderers on WebGL
#9Jax is super fun to use outside of ml!
Recently I had fun reimplementing an old (but still usable!) code for accelerator optics. It involved transfer matrices for a 6D phase space to second order. Most of the FORTRAN77 source code was just pages and pages of hand-differentiated 6x6x6 matrices (with quite non-trivial elements) and the plumbing to painstakingly propagate those jacobians around for fitting... all replaced with a single, magic, call to jax.grad(). Felt like cheating!
I'm also super interested in its application to modelling, e.g. projects like https://github.com/deepmodeling/jax-fem -- particularly for chaining different sorts of simulations and analysis together and getting gradients through the lot. Also quite magic!
Re: Jax's true calling: Ray-Marching renderers on WebGL
#10> the thing JAX was truly meant for: a graphics renderer I mean, just like ray-tracing, SDF (ray-marching) is neat, but basically everything useful is expensive or hard to do (collisions, meshes, texturing etc.). I mean mathy stuff is easier (rotations, unions/intersections, function composition, etc.) but 3D is usually used in either modeling software or video games, which care more about the former than they do the…
Games and simulations are typically stateful, I'm not sure the functional purity of JAX is a good fit. Also, what's the story for JAX + WebGL when it comes to targeting hardware-accelerated ray tracing?
Maybe you mean mutation? State is inherently a part of functional purity. It's just handled explicitly instead of implicitly.