aras_p

That is not actually true.

Unity used to be on ancient version of Mono before year 2017. Then until 2019 the option to use “up to date” version was optional. Since 2019 it has been on more or less current Mono version (Mono itself stopped getting any serious updates around 2020).

If you mean built-in Unity physics, then unlikely. All built-in physics stuff (either 3D physics which is PhysX, or 2D physics which is Box2D) are done entirely in C++ code and are unaffected by Mono float<->double shenanigans.

(author here) I think yes and no -- while it is true that the "MOP" quick test I tried does not allow to access/decompress individual EXR channels, it does allow to access "chunks" of the image. Unlike say EXR ZIP that splits up image into 16 scanline chunks where each is independent, this splits up into 16K pixel chunks where each is completely independent from each other. So you can access a chunk without decompressing the whole image.

That said, if someone were to investigate ideas like this furher, then yes, making "layers" within EXR be able to get decompressed independently would be a thing to look at. Making individual "channels" perhaps not so much; it is very likely that if someone needs say "indirect specular" layer, then they need all the channels inside of it (R, G, B).

Yes, within VSE (and elsewhere in Blender) almost (*) everything uses premultiplied alpha, directly or indirectly. 8bit/channel images are stored non-premultiplied, but any math done on them does premultiplication, the math, then reverses back into un-premultiplied form (reason being, that w/ premultiplication 8bit/channel is not enough precision). Float/channel images are always premultiplied.

(*) I have found one or two VSE effects that do not do the correct premultiplication within their calculations. Someone(tm) should fix them at some point. But also a good question, whether there should be an option to keep previous "broken" behavior.

wrt color spaces, VSE by default does not do blending in linear color space. Default is sRGB, and variuous blending operations are done directly on sRGB values, i.e. "what four decades of photoshop has taught us to accept as expected results". VSE can be set to operate in some other color space, optionally.

wrt filtering of images, the pixel values are "just" filtered without color space awareness. So for 8bit/channel images (usually sRGB), they get "slightly incorrectly" filtered. If you want proper linear space filtering, can force images to be to floating point (any floating point images wihtin Blender are in "scene linear").

My guess is that the code was written by someone in 1995 back when no one understood color spaces, or something (it's hard to track down who and when wrote it exactly due to all file moves and refactors etc.)

No it's not. But, the previous code was already effectively doing "c * c" for the last 15 years. So for now, just keep doing that, a bit faster.

A more proper way would be to do proper color-space aware luma calculation. Which under default settings is sRGB indeed, but not necessarily so (VSE can be set to operate in some other color space). Someday!

(blog post author here)

Most of actual research I've seen (i.e. papers) are not Unity/Unreal, they rather are CUDA/Python.

The "Unity Gaussian Splatting" is not a research per se, just integration of that existing technique into Unity. As for why Unity, well yeah that's because I have experience with it, and am comfortable using it.

There's many other people experimenting with in in web ecosystem (WebGL, WebGPU, three.js, aframe etc.), that you can say is properly open source.

Blender as is right now is lacking certain functionalities to efficiently do gaussian splatting. However, for upcoming Blender 4.1 several pieces are landing - I have extended PLY file importer to be able to import custom attributes (as needed by gaussian splats), someone else contributed APIs to be able to write compute shaders from a Python addon. Once various pieces like that are in place, someone could indeed make a decently performant gaussian splat add-on or something.

I looked at that in the previous post (https://aras-p.info/blog/2023/09/13/Making-Gaussian-Splats-s...) and while there's some nearby correllations in positions & colors (for colors I actually (ab)use that by doing BC7 compression on that data), the rotations & scales are "pretty much random". Which makes sense; if they were not random the GS optimizer would probably have represented them as smaller amount of larger splats.

I can't comment on the linked github issues, but looking at the turbopfor icapp.c sources, it looks like the blosc2 bytedelta is not used correctly there: the expected order is "shuffle, then bytedelta", but icapp.c does "bytedelta, then shuffle". That might explain the poor result you get :)

Yeah I was considering whether to include TurboPFor at some point or not. It looks really good, but for my particular use case is not applicable due to GPL license.

I have a new post (https://aras-p.info/blog/2023/02/03/Float-Compression-5-Scie...) comparing zfp, fpzip, spdp, ndzip, streamvbyte libraries for compressing this same data set. All in lossless, single threaded mode so far (just like all the other experiments before).

zfp performance is... "underwhelming" to say the least :( (fpzip is pretty good though, if only a bit slow at decompression). Maybe zfp is much better on 3D or 4D data, and/or in lossy mode. Which might be a topic for a future post.

"Kind of". My understanding is that block floating point actually makes a bunch of numbers have the same exponent (probably the largest among the group). That's not exactly the same as reordering bytes where exponents can be different (but maybe similar).

So "block" is not a lossless transformation/compression.

(post author) All of this has been done elsewhere! I'm just trying to try various approaches that are out there, on "my own data".

(blog post author) I'm not doing operations on floats. The data is floats, yes, but the XOR is obviously not on floats; and Delta is not either. Both are just interpreting data as 4-byte unsigned integers or 1-byte unsigned integers depending on the filter.

What was your thesis topic, if you don't mind sharing?

"Rendering Soft Shadows in Real Time" (https://aras-p.info/texts/files/ArasPranckevicius_Magistras_...), which was an overview of rendering techniques from that era (2005), and also two new approaches that were both kinda silly in retrospect :)

I am the author. I'm not from the US, so no idea about your thesis question. I did my thesis many years ago, so this investigation is completely not related to that topic :)

Yeah, I should have clarified: most games using Unity or UE4 are using PhysX, since that's what these two engines are using out of the box.

Everything that is made with Unity or UE4 uses PhysX.

That said, not that many games use the GPU-accelerated parts of it; for a lot of gameplay physics CPU code path of PhysX works just fine and does not have special hardware requirements.

No, it wasn't recorded. And I was talking in Lithuanian, which wouldn't have been very useful :)

There was a video, but since I talked in Lithuanian, I doubt if it would be useful to many people :)

That's just coding style, which by itself is not a new dialect. Yes a bunch of APIs in Unity use different naming conventions from the rest of .NET world, but the language is the same.

The new HPC#/Burst indeed are subsets of C#, but that's a very recent development, and completely unrelated to "Unity had to make their own C# dialect to avoid Novell/Xamarin licensing issues".

As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down

I have worked at Unity since 2006. Yes Unity was Mac only at that point, but it still used Mono there.

Unity only adopted C# after moving out of the Mac into the PC

Not quite true; Unity has always used Mono. The very first Unity 1.0 version in 2005 was already using C#/Mono.

Which meant it grew to a kind of C# dialect

Unity never had it's own "C# dialect".

I'm referring to his Metal timings being more than 10x slower than D3D

In my case it's the difference in hardware. DX11 results are on GTX 1080 Ti, whereas Mac are on Iris Pro on 2013 MacBookPro. > 10x performance difference between these GPUs is entirely expected.

Correct, right now it's only Windows/Mac/Linux. That leaves the whole mobile & console platforms without it, so it's not like our IL2CPP stuff is "not needed anymore".

* OpenGL is a dealbreaker since modern things in it (compute etc.) don't work on iOS/Mac; and elsewhere has a lot of driver stability problems. Does not work on any consoles.

* Metal is a dealbreaker since it does not work anywhere that's _not_ Apple.

* Vulkan is a dealbreaker since it only works on Android (mobile) or requires fairly new drivers/GPU (PC). Does not work on consoles.

* Direct3D 11 is a dealbreaker since it does not exist outside Microsoft platforms, and does not have some modern stuff (async compute etc.).

* Direct3D 12 is a dealbreaker since it does not exist outside Microsoft platforms; and on PC requires Win10.

See a common pattern? All of them can be considered "dealbreakers" for one or another reason. The (perhaps sad) reality today is, that you can't cover "all platforms" with a single graphics API.

Not that it's a big issue though... making a renderer/engine that works on more than one graphics API is not that big of a deal, compared to challenges everywhere else in game development.

It'd be interesting to see how the 128-bit Murmur versions compare.

Added them (and some more hash functions) in a follow-up post: http://aras-p.info/blog/2016/08/09/More-Hash-Function-Tests/

asm.js is essentially a "32 bit" compilation target, it does not (to my knowledge) support 64 bit arithmetic efficiently right now.

Yeah, should revisit this and test more hash functions. Just ran out of time I wanted to spend on this (hey, I got some actual work to do too :))

PX4/XB1 use a fairly low-end AMD CPU (Jaguar core, ~1.6GHz). Apparently it also does not quite appreciate heavy use of 64 bit multiplies (as used in xxHash64 for example).

Modern phones (e.g. iPhone 6) in terms of CPU are actually very impressive indeed!

Yeah I forgot to mention that even if most of the time you don't care about "security concerns" with regular hashtables, there are cases where a weakness in your hashtable can be used to bring some of your services down. That has happened!

However, many of the times that is not a concern, but as always, case by case basis.