Take a look at this project by Runi: a preliminary language server for WGSL. IMO this is one of the biggest barriers in making graphics programming genuinely approachable: I'd love to see this catch on!
@alice_i_cecile There is also wgsl-analyzer ( https://github.com/wgsl-analyzer/wgsl-analyzer ) though I'm not sure how good it is for bevy. It's already pretty frustrating to use for plain wgsl so I guess it can only be worse with bevy preprocessor.
@logloggames Amazing read, thanks for sharing! I cannot agree more regarding hot-reload and recommend Bret Victor - Inventing on Principle ( https://youtu.be/PUv66718DII ) if you haven't seen it already. Having the possibility to try and find out is not rust forte and yet is required for any creative process to truly shine.
Spark is the culmination of over a year of dedicated research and development, built upon a solid foundation of years of experience in GPU compression technology.
Today I released my first (two) #rust crates! 🎉
mesh_to_sdf generates a signed distance field from a 3D mesh and its client lets you visualize it to fine-tune the parameters (and more).
It's agnostic to your math library, so you start using it right now with #bevy#fyrox or your favorite math library / game engine.
I couldn't have a SDF visualization without a raymarcher now, could I? Including trilinear, tetrahedral and funky interpolations. The only vis missing would be marching cubes I guess, but that's a story for another day.
I have everything I wanted for the 0.1 release, I just need to understand how I publish it on crates.io now.
Hey Tech Art folks, I have seen many variant of mesh-based outline shader but I haven’t seen one that maintain consistent outline width under different fov and camera distance.
I think we usually guess the width factor based on fov and distance as the correct calculation is too costly. Is there a mathematical sound yet fast solution?
Alternatively I would do the calculation in screen space (fov and distance no longer matters), I wonder if there are equivalent ways that I missed?
Wrote a first grid-based sdf generation. 12 seconds for 1M5 triangles on a single thread for a 100x100x100 grid (1M points). Already quite happy with it as it's in the realm of "usable". The model was also a bad fit for the algorithm.
After 20 minutes of scribbling, I re-discovered that the vertices of the equilateral triangle inscribing the unit circle were on the circle of radius 2. I guess I'd learned that in middle school...
I was surprised not to find a mesh-to-sdf lib in rust, so I built my own with a visualizer, which also acts as a voxelizer. I wasn't sure what the state of the art was in this area (apart from a deep-learning approach), so I did my own thing.
A bit bruteforcy, but enough for my needs. I'll write a grid-specific version since that's my main use case and there's room for much faster than my current implementation.
#Genuary4 Pixels. I just couldn't resist the temptation. Optimizing it to render in real-time was a struggle, but I really like the end result. (I hope I'm your first of the year, please tell me I am)
@sebastianlague latest video made me want to try his spatial grid algorithm. I've been wanting to try gpu-based spatial partitioning for quite a while and Sebastian's explanations are really nice to follow and wrap one's head around the concept.
But first, particles!
#Genuary15#Genuary16 So I'm cheating a bit here since I worked on my own physics library as I implemented spatial grid partitioning, which was the beginning goal of this project. I now render 256k particles at 300fps. I wanted to reach 1M but with 80 fps it's not stable enough yet. :/
Now I need to think about mesh collisions and proper rendering I guess.
Finally back to working on the simulation. It's time to dogfood my mesh_to_sdf crate for the fluid sim mesh collisions. Really happy with the first results, it works!
I need to find a better screen recorder though, ScreenToGif struggles and invents drops when it's running at 300fps...
