Tomasz Stachowiak

Sorry, no, MoltenVK doesn't do ray-tracing. Please see https://github.com/EmbarkStudios/kajiya/issues/37 for the current kajiya-side issue.

Mainline of `kajiya` requires ray tracing, but you could check out Ashley's branch from the linked issue.

That is a very good question, and got me thinking for a while! It does seem like a useful feature to have, but at the same time, I think it...

Ah, I think I misunderstood what you meant then -- I thought you were suggesting that the framing would happen by adjusting the camera's fov. In that case the crate...

They are in the repo under https://github.com/EmbarkStudios/physx-rs/tree/main/physx-sys/src, and compilable by Cargo's `build.rs` mechanism at https://github.com/EmbarkStudios/physx-rs/blob/main/physx-sys/build.rs

Yup! It was the first thing I tried, and at least back then `bindgen` gave up on most of PhysX. I don't think it had any way of handling ABI...

- [x] [`wasmer`: Add support for stack traces from wasm](https://github.com/wasmerio/wasmer/issues/827)

If you mean `repr(Rust)`, then it's not very compatible with anything; even two identical structs can be incompatible with each other: https://doc.rust-lang.org/nomicon/repr-rust.html

It's probably something for @Jasper-Bekkers :P What was the intended use case? The issue lists possible options, but not motivations. I was going under the assumption that this would be...

Ouch! That's painful xD The DDS is rgb9e5, and maybe that's the problem for those loaders... You could try https://github.com/h3r2tic/tony-mc-mapface/blob/main/OCIO/lut-converter/tony_mc_mapface_f32.dds which is f32 :)