Rendy is released!


#1

Today my year-long preparation to make greatest rendering engine for amethyst got to major point.
:tada: Rendy is now available on crates.io :tada:

What’s rendy anyway?
rendy is collection of crates to “build your own renderer”. It’s not a renderer on its own. You can’t just throw a mesh into some scene and it will render that mesh for you, no.

rendy crate itself is umbrella crate for all rendy-* crates each of which solve particular task.

In its core rendy has small and concise crates to solve hardest tasks that arise before modern graphics API user.
Memory management (rendy-memory), resource management (rendy-resource), command encoding (rendy-command) and synchronization (rendy-chain).

rendy has also two big crates - rendy-factory and rendy-graph.

First one (rendy-factory) gives you simple and reliable way to create resources, upload data, gives access to command queues and manages resource destruction (built upon rendy-memory, rendy-resource and rendy-command).

Second one (rendy-graph) allows user to build complex rendering graphs from simple nodes, manages transient resources and calculates required inter-node synchronization (using rendy-chain).
Rendering node has own tree of traits and implementations to further simplify node construction.
See “quads” example to know how to create graph that will render 2 millions moving quads in no time.

On top of it we are working on data-driven rendering system that will allow user to render objects with custom shaders with ~0 lines of additional code.

Instead of picking one of modern graphics API to support rendy uses gfx-hal (it provides vulkan-ish API and implements various backends including Vulkan, DirectX12 and Metal).

I hope we will replace old clunky amethyst renderer in next few weeks and start creating new features with it.


(Fletcher) #2

Congrats viral! This is a huge accomplishment!


(Dzmitry Malyshau) #3

Congratulations! I’m looking forward to use parts of it in our wgpu-rs implementation ;_


DRAFT: Amethyst 0.11.0 release
#4

Thanks!
What parts you are interested in, btw? :slight_smile:
IIRC You use memory manager, but we decided we want integrate memory management into hal directly someday. Is there anything else?


(Dzmitry Malyshau) #5

Memory and descriptor allocation are the obvious things to start with :wink:

I don’t think we want to use the committed resource semantics of gfx-hal, if it materializes. On D3D12 this would probably be less efficient than manually managing larger allocations.