Aras Pranckevičius, a graphics programmer, writes about C++, SIMD, hashing, Gaussian splatting, texture compression, and performance work.
HN commenters link his posts on Gaussian splat compression, slow SIMD code in debug builds, and OBJ parsing libraries.
It's Unity's (the game engine) new Entity-Component-System, the blog post is an answer to this presentation:
http://aras-p.info/texts/files/2018Academy%20-%20ECS-DoD.pdf
Unity's traditional entity system is suffering from a number of "OOP-isms" which make it hard/impossible to optimize for performance.
The new ECS strictly follows a Data-Oriented-Design approach, where everything is built around laying out the data in memory in a CPU-cache friendly way (and a few other things that neatly 'fall into place', like spreading work across CPU cores, a specialized 'high-performance' C# dialect, and the ability to move work from the CPU to the GPU).
The big question is how the traditional Unity audience will react, since the ECS programming model is quite a bit different from the old way, and it's no longer as simple to build a game from a jenga-tower of adhoc-hacks ;)
I've read the criticism of that post ( http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ , discussed previously at https://news.ycombinator.com/item?id=18777735 ) but not the original, and now that I did, I have that strange feeling of not knowing whether it was satire or not --- and am unfortunately leaning towards the latter.
I made another comment here on this item, that it feels like a lot of the recent developments in programming languages are more along the lines of showing off how much complexity you can add, rather than solving the real problem itself. It's a "do less with more" mindset, the complete opposite of what I believe in.
Aras has also done some very interesting blog posts regarding this technique:
* https://aras-p.info/blog/2023/09/05/Gaussian-Splatting-is-pretty-cool/
* https://aras-p.info/blog/2023/09/13/Making-Gaussian-Splats-smaller/
* https://aras-p.info/blog/2023/09/27/Making-Gaussian-Splats-more-smaller/
Gsplat gets a mention:
Aside: the excellent gsplat.tech by Jakub Červený (@jakub_c5y) seems to also be using some sort of VQ/Clustering for the data. Seriously, check it out, it’s probably be nicest gaussian splatting thing right now w.r.t. usability – very intuitive camera controls, nicely presented file sizes, and works on WebGL2. Craftsmanship!
It’s not entirely trivial (if you care about texture quality) you’re choosing 2 endpoints in 3d space that can be linearly interpolated to values that best fit 16 points in 3d space.
I may have been a little off with saying seconds per texture but it’s definitely non trivial amounts of time. And ects (mobile) and BC7 are certainly still not something you want to compress to at game load-time.
Some comparisons of texture compression speeds for various formats (from 2020 but on a 12core i9): https://www.aras-p.info/blog/2020/12/08/Texture-Compression-in-2020/
This isn't really to do with raytracer perf. It's about how Miguel de Icaza (The creator of Mono) improved Mono's float handling. The difference in raytracer perf on different .net runtimes is just what brought the poor float handling to his attention. Better mono float handling is a good outcome for lots of non raytracer scenarios.
If you read the linked blog about the ray tracer, the C# ports are just blog 3 in a series of 8 that does actually conclude with two posts on SIMD - https://aras-p.info/blog/2018/03/28/Daily-Pathtracer-Part-0-Intro/
It's definitely possible to compress/palletise the SH bands (see https://aras-p.info/blog/2023/09/27/Making-Gaussian-Splats-more-smaller/ for one approach).
We just found that splats encode some view-dependent shininess anyway (for example the guitar body https://playcanvas.com/model-viewer?load=https://code.playcanvas.com/viewer/guitar-cleaned.ply) and so considered the extra data and rendering cost of SH not worth it for now.
It would be quite straightforward to add SH to the PLY file and we'll definitely consider it in future!