Funding and followthrough #165
Replies: 2 comments 3 replies
-
Wow! Thank you @John-Nagle. 🙇 Renderling has made it to the second phase of NLNet's selection process for this year's funding. I'm waiting to hear back about how it's going. I'm not sure what official channels are available to send your letter through, but I'll ask my advisers about that, and point them to this discussion. And just so you know, even if the project is not funded, I'll keep working on it, as it's rewarding for me. But of course development would slow down as I would have to find some contract work to replace that income. |
Beta Was this translation helpful? Give feedback.
-
Khronos, which runs the Vulkan conference, realizes that they have an ease of use problem. Comment on the Vulkan discord at the above link if you agree. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'd be willing to write NLNet, or other funding organizations, in support of Renderling. Here's what I've drafted:
NLNet:
I am writing to encourage increased support of Renderling, the 3D rendering library written in Rust.
I'm a user of 3D rendering libraries in Rust. I've developed a big-world metaverse client, Sharpview, entirely in safe Rust. Here's a video:
https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ
I've looked at the available options for a Rust 3D renderer.
three.rs - a rendering library comparable to three.js, but in Rust instead of Javascript. Abandoned.
orbit - another rendering library, with a good design, Abandoned.
rend3 - a reasonable rendering library, and a one-person project. Abandoned. I maintain a fork of it.
renderling - promising, but not ready for use yet.
Renderling is the only alternative with a future.
This is a hard problem. It's relatively straightforward to write a low-performance 3D renderer. Trying to scale up such a renderer to large virtual worlds hits an obstacle. To reach the point where the GPU is fully utilized, it's necessary to have considerable concurrency in the renderer. If that concurrency isn't built in, the frame rate drops under load when the main CPU thread becomes compute bound. This happens long before a modern GPU is fully utilized.
Partly because of this scaling problem, 3D work in Rust has stalled. The Rust game dev forums and sites are now little used. No one has ever written an AAA game title in Rust. The best success is "Tiny Glade", a game in which one builds little farms and castles in a small forest glade. It works because it's tiny. It has a scene small enough to not stress the rendering engine.
The big commercial game engines, Unreal Engine and Unity, have solved this problem at considerable expense. It hasn't been solved yet in open-source code. Renderling seems to be getting close to solving this problem. It needs ongoing support to finish the job.
Ongoing support is the key here. Three volunteer efforts have stalled at the point where it becomes hard. Pushing this technology through to usefulness requires several years of funding.
Beta Was this translation helpful? Give feedback.
All reactions