Renderer rewrite

[torkleyy]

This is the PR merging renderer into develop. It is WIP, but shows the overall progress.

TODO

• Fix examples
• Check docs, crate structure
• Properly handle configs

[stenverbois]

Nit: these could be made a bit cleaner with if let bindings.

[Binero]

There is still a few issues with this PR.

• It exposes a lot of cgmath, for instance inside renderer::Camera.
• It appears to me that the renderer and the asset manager are tightly linked through AssetPtr. It was decided in #190 that both systems are optional, so the asset manager must work without the renderer, and the renderer must work without the asset manager.

[Binero]

There is still a few issues with this PR.

• It exposes a lot of cgmath, for instance inside renderer::Camera.
• It appears to me that the renderer and the asset manager are tightly linked through AssetPtr. It was decided in #190 that both systems are optional, so the asset manager must work without the renderer, and the renderer must work without the asset manager.

[torkleyy]

@Binero I don't know when that decision was made, but having a game without rendering doesn't make much sense to me.

[torkleyy]

@Binero I don't know when that decision was made, but having a game without rendering doesn't make much sense to me.

[Xaeroxe]

Zork! although I must say it seems unlikely a text adventure would have any need for Amethyst. :P

[Xaeroxe]

Zork! although I must say it seems unlikely a text adventure would have any need for Amethyst. :P

[Binero]

@torkleyy Well, the issue is linked in the post. One of the rationales I quite like is that the components need to be reusable and replaceable. If I want to use a custom renderer, that should be possible. If I want to use a custom asset manager, that should be possible as well.

[Binero]

@torkleyy Well, the issue is linked in the post. One of the rationales I quite like is that the components need to be reusable and replaceable. If I want to use a custom renderer, that should be possible. If I want to use a custom asset manager, that should be possible as well.

[Xaeroxe]

The fundamental problem with that idea is that it's in direct conflict with our desire for a hot reloading feature. The two have to be coupled to make that work. The only way I can see around this would be to use cargo features to expose a different API without hot reloading capabilities when there isn't an "assets" feature present. So if modularity is truly that high of a priority for us we can do that but I feel that should be a bigger discussion with more people involved. My views personally are that we eventually have to make some architectural decisions for our end users in order to provide useful and usable software. Too many choices can hamper ease of use.

[Xaeroxe]

The fundamental problem with that idea is that it's in direct conflict with our desire for a hot reloading feature. The two have to be coupled to make that work. The only way I can see around this would be to use cargo features to expose a different API without hot reloading capabilities when there isn't an "assets" feature present. So if modularity is truly that high of a priority for us we can do that but I feel that should be a bigger discussion with more people involved. My views personally are that we eventually have to make some architectural decisions for our end users in order to provide useful and usable software. Too many choices can hamper ease of use.

[torkleyy]

The way I see it, renderer and assets crate are separate, thus reusable. The main crate is just the glue, so if you want to e.g. use another renderer, you can still use the other crates, but you need your own glue.

[torkleyy]

The way I see it, renderer and assets crate are separate, thus reusable. The main crate is just the glue, so if you want to e.g. use another renderer, you can still use the other crates, but you need your own glue.

[Binero]

One must consider that because they are so tightly coupled at the moment, it is impossible to generate meshes at runtime, as is needed in for example voxel engines or other volumetric engines.

This is because MeshComponent is an Asset, which is loaded from Loader. I think the following approach would be much more flexible:

1. When you load a Mesh from the Loader, it gives you an AssetFuture<T> where T: Mesh which implements Component whenever T does.
2. This AssetFuture<Mesh> can be attached to an entity.
3. There is an AssetSystem which tracks whenever these futures have been completed, and replaces the AssetFuture<T> components on these entities with T.

As an added bonus, this system could leave behind a LoadedAsset<T> component, as to keep track of which entities use which assets. Hot reloading can then easily be implemented by simply iterating over these entities and adding new AssetFutures.

This approach has the advantage that when the asset system is not required, as it isn't for instance when you are generating meshes, it doesn't get in the way as it does now, preventing you from implementing your features.

[Binero]

One must consider that because they are so tightly coupled at the moment, it is impossible to generate meshes at runtime, as is needed in for example voxel engines or other volumetric engines.

This is because MeshComponent is an Asset, which is loaded from Loader. I think the following approach would be much more flexible:

1. When you load a Mesh from the Loader, it gives you an AssetFuture<T> where T: Mesh which implements Component whenever T does.
2. This AssetFuture<Mesh> can be attached to an entity.
3. There is an AssetSystem which tracks whenever these futures have been completed, and replaces the AssetFuture<T> components on these entities with T.

As an added bonus, this system could leave behind a LoadedAsset<T> component, as to keep track of which entities use which assets. Hot reloading can then easily be implemented by simply iterating over these entities and adding new AssetFutures.

This approach has the advantage that when the asset system is not required, as it isn't for instance when you are generating meshes, it doesn't get in the way as it does now, preventing you from implementing your features.

[omni-viral]

Wow. Checks are passed 🎉

[omni-viral]

Wow. Checks are passed 🎉