Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Notice the (2021).

Read the change in which Embark's CTO backs off from Rust.[1] They were building their own rendering ecosystem, but seem to have backed off from that.

The mainstream Rust 3D ecosystem just isn't good enough yet. I've brought this up before.

The core crate for 3D is WGPU. This is a layer which tries to cover Vulkan, Metal, OpenGL, DX12, Android, and WebGPU targets. It works, but there are performance compromises to support all those different targets. Supporting web and Android means giving up some parallelism on desktop.

The main alternative to WGPU is Vulkano, and MoltenVK, which is an adapter for Apple's Metal. (Apple just had to Think Different, which is why many games are not ported to MacOS.) It's OK, but it's really just a subset of Vulkan on top. Same parallelism problem, although not for any essential reason.

All those offer a Vulkan-type API, which is rather low level. The caller has to manage GPU memory and scheduling. For that, there's Bevy, which is a whole game engine framework. Good work has been done in Bevy, but it's a framework, so you do it their way or not at all. There's Rend3, which is just a crate to manage memory and scheduling. I use that. It's been abandoned. I may have to take up maintaining that.

Nobody is pushing these towards maximum performance and quality. Nobody has a good modern big-world 3D shooter on these stacks.

All this stuff works fine if you're doing simple scenes. If you're pushing towards, say, the level of a 10 year old AAA title, it's not there. Modern Unreal Engine, not even close.

Not enough money behind it.

[1] https://github.com/EmbarkStudios/rust-ecosystem/commit/61f0e...

From my friends who work on rust-GPU it’s been my impression that Embark is moving away from Rust. But it’s not because of the ecosystem. Although I agree that it is immature. Instead it seemed to be more an economic situation.

It’s hard to pay the frontier tax and ship AAA games.

I would say the main alternative is ash not vulkano, from my experience in experimenting with graphics on rust, I haven't seen much support or like for vulkano as it has many of the same performance issues as wgpu and doesn't simplify too much after the trade off of the lack of resources, it also appears embark was using ash atleast for kajiya.

I have encounter a lot of your posts and that's what pushed me towards just tackling vulkan instead of using wgpu. I also encountered many of the same issues around the ecosystem. I think the main issue is there is just not enough dev time going into it or money. Even valoren, which I already knew of before learning rust from posts in linux/oss communities only has received 8k of funding, while offering the closest to an AA experience.

But I don't think its that reasonable to expect the ecosystem to just have a batteries included performant general rendering solution, idk if any language has that? I know there is bgfx, which might be the closest thing but I assume also has its own issues. So I don't really think its the graphics part holding things back, as ash is a great wrapper around vulkan and maps 1-1 with a little bit of improvements (builders for structs, not needing to set stype for each struct, easy p chaining).

The main issue I encounter is all around the lack of dev-time and the tendency for single developers and for small single purpose crates. Most of my friction is around lack of documentation, constant refactoring making that lack even worse, and this causing disjoint dependency trees. So many times have I encountered one create using version x.x of one crate that depends on x.y version of another then the next being on z.x of another dependency and then another still needing z.y. This normally wouldn't be that big of an issue, except the tendency to constantly introduce refactoring and breaking changes meaning I end up having to fork and fix these inter-dependencies myself and cant just patch them.

But this all just circle back to there just isn't much dev time going into them. It also seems the "safety" concerns and rust just not allowing some things causes devs of many crates chasing their tails with refactors trying to work around these constraints. But it does get quite tiresome having to deal with all of these issues. If I was using c++ I could just use sdl/glfw, imgui, vma and vulkan and they would all be up to date with each other. In rust I need winit, imgui bindings, imgui-winit, imgui-vulkan, raw-window-handle, ash and vma bindings. And most of these are all using different versions of each other and half of them have breaking changes version to version.

Reply on news.ycombinator.com