Integrate EnTT ECS components

[pgruenbacher]

This isn't a feature request so much as me just writing out an issue to track my thoughts on the matter. I'm going to be evaluating bs framework for whether EnTT can be used as an alternative scene framework. Luckily bsf is already composition-friendly from what I can tell.

@BearishSun I should just make a Source/Plugin/bsfEnTT plugin right when I fork and play around right?

[BearishSun]

Source/Plugin/bsfEnTT sounds good. Although you don't have to make it an actual separate shared/dynamic library as other plugins. Files can reside in that folder, but can link with the main bsf library, perhaps controlled by an optional CMake flag.

[pgruenbacher]

agreed.

[pgruenbacher]

A big bonus of using EnTT reflection would be that the component and classes would no longer need to inherit from IReflectable for the current RTTI reflection system. However @skypjack I haven't seen an example of serialization / deserialization using EnTT reflection if that's even a thing. I was just gonna use cereal but I'd be curious how well EnTT reflection fits with serialization.

[skypjack]

It's primarily meant for that actually.

The possibility of attaching free functions to meta types as if they were fake member functions is intended if you want to create built-in, per type serialization functions without having to extend your types. Otherwise you can literally walk through the meta types with a generic serialization system and serialize a field at a time.
In fact, it supports different models for serialization. It's a matter of taste to decide what's the preferred one before to proceed.

Note: meta requires C++17.

[pgruenbacher]

Some more notes going through the code.

1. At >200,000 lines of code this is really well documented and maintained code. I'm using it as an example framework from now on.

2. The biggest pain point from a contributor standpoint is the amount of code necessary to handle the simulation/core thread synchronization between the Object and ct::Objects. It's hard for me to decide whether the ECS module should just disregard MT completely for now. My guess is yes for prototype purposes. Though @skypjack 's new responsive observer features may be useful when it comes to syncing dirty components.

3. Two options: it could come with a separate bsfRenderECS plugin as well, since the main benefits would be the visibility culling, depth ordering if ECS were tightly integrated.

4. Other option: Many of the ECS benefits come from the simulation side and state updates, so instead the entities could instead just be coupled to the scene objects for rendering, so that all game logic can still happen on the ECS without worrying about rendering.

It's hard to say... maybe a high entity count scene should be generated for testing purposes as the very first objective to see when bsfRenderBeast starts to strain. @BearishSun have you formed any opinions about how ECS would benefit / not-benefit the framework. I definitely don't think it could serve as a replacement backend for generic users, but only as alternative for certain developers.

[BearishSun]

I think it would be nice to have all the engine internals run on a unified ECS system, which can then also be utilized by users that need high performance without having to dig into individual systems. Ideally it would serve as a high-performance way to extend systems like the renderer, animation, particle system, etc., but also for generic simulation purposes.

Unity has special rules for their ECS regarding threading and how it handles data copying. Perhaps something like that can be employed here. I'm guessing it would work similarly to core object syncing.

But all in all it would be a huge overhaul and we should start "small". I agree the initial focus should be just the renderer, and perhaps even just the core-thread part of the renderer (no MT syncing).

bsfRenderECS sounds good, although many parts of the current renderer are built-into RenderBeast and you would likely want to re-use many of those (e.g. various RenderMaterials such as tonemapping, tiled deferred, etc. and even helper classes for shadow mapping and similar). So as you build it, I wouldn't be opposed if you pull parts of RenderBeast into the core of bsf, so you can use it for your own plugin (as this was something I was planning to do myself).

[pgruenbacher]

yes there's a lot of useful logic in renderBeast. Well in that case I'll probably just get a rought prototype going without worrying about any sort of re-using of existing MT / reflection / serialization logic. This will keep the components much simpler.

[pgruenbacher]

I'm basically using my initial fork branch to push everything I want into bsf #341.

The plan is to actually update bsfRenderBeast's sceneInfo, visibilityINfo, cullInfo as the starting point, since those vectors translate very well to EnTT api. The getRendererId() of renderables means that theoretically the current scene structure of scene objects will still be compatible with the ECS backend which is great, while still having an ECS registry exposable for a person to take advantage of without having to make thousands of scene objects.

Some other notes: the applicationCore will need to have a runLoopSteps() that will run a certain # of steps before exiting, allowing for more integrated unit-testing.

[BearishSun]

Sounds good. We'll probably want to add Application::runOnce or something similar, then users can run a loop step on demand. I've also had requests for this for other use cases. Although there might be challenges how the implementation handles this (I took a quick glance once I don't think the solution was trivial, but I forgot the details).

[pgruenbacher]

yea I've got runMainSteps(UINT32 steps) and then moved the actual loop logic into CoreApplication::Update().

[pgruenbacher]

shadows, lights, decals, renderables, and particles all seem to be working with the ECS refactor. Of course this is a incremental refactor so it's not necessarily an improvement in performance yet, but it's getting there...

Basically the easiest thing to refactor was the Renderer module scene info, which had independent vector containers for each light, renderable, decal, particle instance. The EnTT registry api was relatively easy to replace those containers. This simplifies a lot of code that was originally involved with recycling space in those container when the renderer was registrying/deregisterying instances. It also gets rid of the need of the rendererView and rendererLight instances from having to track their own vector containers for visibility and light data. The other cool thing is that the existing Scene api still plays well with the RenderECS module.

#341 see my pull branch for reference.