Advertisement

How to manage Resource lik Mesh, Material, Script on your game engine's core system?

Started by November 06, 2023 12:57 PM
1 comment, last by frob 1 year, 1 month ago

In the case of my own engine, it is implemented in ECS format in the core part.

In addition, the current ECS consists of Entity, Component, System and Resource, Node, and Scene.

In the case of resources, it means data such as Mesh, Material, and Script.
In the case of Node, it is a bundle of pointers of required components. It can be seen as similar to Archetype.
In the case of Scene, it corresponds to the world, and each system and node is registered and used.

The problem that I was worried about is that I can do simple rendering in the current structure, but I don't know how to do instancing rendering.

For example, if there are currently 10 nodes using Cube Mesh inside Scene, if you want to instancing render this case, you must hand over additional information about the Mesh to be rendered.
In other words, each Scene should contain information on nodes using resources such as Mesh or Material registered.
However, I didn't have a good sense of how to manage these connections.

Simply, whenever a node using a resource is registered in the Scene, it was questionable whether to register the IDs of the nodes for the resource within the Scene.

So, others left a message wondering how to define and use the relationship between Mesh and other objects that use it to do instant rendering in the ECS structure.

Thank you for reading the question.

The resource in ECS is generally meta-information, a proxy for the concrete resource. That is, in many systems a resource the developers see as a Mesh, Material, Sound, or similar resource they can attach to an object in their Inspector or other editor isn't a reference to the actual mesh, the actual textures, the actual audio clips. Instead it's a proxy into a structure in the engine which manages what those concrete resources are. It's all hidden through that abstraction.

Then the proxy objects in the scene will rely on a cache of the resources that are actually loaded (or not loaded). The world / scene system that does the actual rendering can use instances when multiple of those cached objects are used. This doesn't give away the information to the scripts in the game. The scripts see a “Mesh”, they see a “Material”, and they can use it regardless of it the actual mesh is actually loaded or at any specific material happens to be loaded into the video memory at any given time. Even objects that are far away, culled from existence to the point they're not even loaded, the meta-information is present so the game scripts can do whatever simulation they need, change whatever states they need, and otherwise manipulate the ECS objects in any way they want immediately regardless of actual resource's loaded state.

This also gives more freedom to swap out for things like level of detail, or using different material states, or doing more complex tasks. When the script changes a value on the meta-information it can trigger up work by the engine to load up new textures or meshes, the game script knows what they're intending to be but generally doesn't need to know internally that the resource is still loading. Similarly, if the engine decides to swap LODs or to use a billboard or whatever else, the game script doesn't need to know any of it, it happens behind their back in the system managing the cached pool of physical resources.

Internally in your scene management when you do the actual rendering, that system takes the proxy object for what is attached in the scene and looks into the details of which concrete resource to actually use.

This topic is closed to new replies.

Advertisement