Question Streaming Prefabs

Is it possible to stream Prefab of GameObject with skin mesh render and turn it to entity at runtime?
I want to create customization system for character.

 

Depending what customisation you have in mind. You would need to be more pricise.

But technically you don't need to create new go prefabs at the runtime.

Just create an entity instance of Prefab entity and do operation of customisation on that entity at runtime. You can even mark that entity as Prefab, if you need later many instances of it.

 

I want to load prefab from addressables for example, a hat, and add it to the character.
the only way I found to create entity from prefab is in the bake, is there other way to do it ?

 

Are you using a DOTS animation system ?
In my case the characters are loaded using addressables and are represented as companions, Which makes it easier until unity provides an official solution.

 

I am using Rukhanka for animation, because I need something that is production ready.
and what do you mean by "represented as companions" ?

 

The "entities" package includes the concept of companion game objects, where an entity can replicate its transform data to a game object (e.g., VFX, characters). While using Rukhanka is beneficial, it does have a limitation that restricts to construct the required data during baking phase. Unfortunately, Unity only supports baking in the editor, which poses a significant constraint for games like yours and mine, where the need to load animated characters at runtime is essential.

 

Is there a reason this doesn't work?

If so, I'd be very curious about your use case. It might be something I could add support for, if you don't care which animation system you use.

 

Certain projects may necessitate a multitude of character skins, and storing them within a subscene may not be an ideal strategy for several reasons:

1. The current state of Content Management is significantly less practical compared to the Addressables package.

2. In certain projects, skins can exhibit high dynamism, with the potential to be represented by an infinite number of variations, such as player-constructed skins. This complexity makes it impossible to pre-construction them ahead of time.

 

so you're suggesting to do the the character and the animation on GameObject and all the data and the movement on the entity side ? if so wouldn't it kind of ruin the purpose of entity ?

 

This is the path our team chose. The project goes beyond basic animations. We use DOTS for things like physics, netcode, game logic (including the ability system and character controller), and rendering. On the other hand, certain modules, like VFX, don't offer much choice. We've also adopted a hybrid approach for handling animations.

 

I won't comment on this as I haven't played with it enough, however...

This runtime construction case very much interests me. I'd like to know a bit more about it, and what kinds of tradeoffs you would find acceptable. For example, if you had to be responsible for maintaining the lifecycle of blob assets built at runtime, or perhaps streaming them as byte arrays in ScriptableObject Addressables, would that be acceptable? If you also had to provide the API either bone binding indices or bone path names, would that be acceptable?

 

I'm not very experienced with animation in DOTS, but we began using DOTS back in its early days, around 2017. One thing we really like about Unity's approach is how they smoothly transitioned from the older MonoBehaviour workflow to DOTS. ( However, we don't really like how they removed the conversion "Baking" phase from the runtime.)

In our Gameplay Ability System package, we continue to use Unity's Hybrid approach. where abilities are created in advance using ScriptableObjects, which are configured through a user-friendly visual interface 'Graph'. Then, at runtime, each ability is dynamically converted using our Package API. This API transforms the abilities graph into a BlobAsset called 'AbilityDefinition' and links it to a user-defined Ghost Entity. The rest of the process is managed automatically by our package.

We find this approach to be very helpful, straightforward, and designer friendly.

When it comes to trade-offs, in our specific situation, our aim is to automate processes whenever it's possible. Here are a couple of examples:

• Automated Replication: We handle the replication of GameplayAttributes and GameplayTags into ComponentData/ComponentDataTags automatically, eliminating the need for users to write extra code.
  
  
• Automatic Disposal: We also take care of automatically disposing the AbilityDefinition BlobAssets when it's no longer referenced.

it's crucial to recognize that there are certain aspects that remain beyond our current scope of automation. eg:

• users are still responsible for defining the Ghost entities that represent their abilities Actions : projectiles, area of effects...
• users must manually Download the needed abilities SOs via their preferred bundling system 'Addressables, Content Management...' and call the API that converts the ScriptableObject to a BlobAsset so we dont load all the defined abilities and their related assets 'Textures, ParticleSystems, Animations...'