Possible to instantiate gameObject returned by InstantiateRealtimePrefab prior to calling it?
When talking to the AI for the docs it mentioned in the flow:
LoadRealtimePrefab()
InstantiateRealtimePrefab()
as long as a valid GameObject is returned by the end of InstantiateRealtimePrefab() i.e. the one that you are actually instantiating
you can actually instantiate it before the call to InstantiateRealtimePrefab()
the reason I'm asking is because we're using Addressables with dynamically sizing pools so we're managing releasing the operation handles for loads in a bit of a round about way to work with the synchronous pattern. I would love to be able to do something like
LoadRealtimePrefab() --> LoadAssetAsync().WaitForCompletion ---> InstantiateAsync().WaitForCompletion ---> InstantiateRealtimePrefab() where we would just immediately return the GameObject we already instantiated and passed on from LoadRealtimePrefab
then
on DestroyRealtimePrefab() we could just do Addressables.ReleaseInstance(prefabInstance)
to release the handle without having to track it in its own dictionary and handle it that way..
I assume that's kosher considering the pattern normcore lays out between the LoadRealtimePrefab and InstantiateRealtimePrefab but I could understand if there's something like a callback that normcore absolutely needs the instantiation to happen after InstantiateRealtimePrefab is called
7 Replies
Hi @foundrey. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the provided Normcore documentation, the prefab instantiation pipeline is designed around two main delegate methods:
-
Yes, it is acceptable to instantiate the GameObject before
LoadRealtimePrefab(RealtimePrefabMetadata prefabMetadata) (for loading the prefab asset)
- InstantiateRealtimePrefab(GameObject prefab) (for instantiating a new instance of the prefab)
The default implementation of InstantiateRealtimePrefab simply calls UnityEngine.Object.Instantiate(prefab), and the documentation for advanced pooling and Addressables integration shows that you can override this to implement custom pooling or instantiation logic. For example, with pooling, you might return an already-instantiated object from your pool instead of creating a new one each time, and on destruction, you can return it to the pool or release it as needed. This is explicitly supported and recommended for advanced pooling scenarios, as seen in the prefab pooling documentation.
The key requirement is that by the time InstantiateRealtimePrefab returns, you must provide a valid, fully-instantiated GameObject that Normcore can use. There is no explicit requirement in the documentation that the instantiation must occur strictly within the body of InstantiateRealtimePrefab—only that the returned object is ready for use. This means your proposed pattern (pre-instantiating via Addressables and returning the instance from InstantiateRealtimePrefab) is compatible with Normcore’s expectations, as long as you ensure the returned object is not in use elsewhere and is in a valid state for Normcore to manage.
For destruction, using Addressables.ReleaseInstance(prefabInstance) in your custom DestroyRealtimePrefab implementation is also supported, as the delegate is designed for exactly this kind of custom cleanup logic.
Summary:Yes, it is acceptable to instantiate the GameObject before
InstantiateRealtimePrefab is called, as long as you return a valid instance from that method. This pattern aligns with how Normcore’s pooling and instantiation delegates are intended to be used, and there is no indication in the documentation of a required callback or ordering constraint beyond returning a valid instance at the right time. Just ensure your pooling or Addressables logic does not introduce race conditions or double-use of instances.
References:
- Prefab Pooling & Advanced Pooling
- Addressables Integration Recipe
- IRealtimePrefabInstantiateDelegate
If you have a very advanced use case, it’s always a good idea to test thoroughly, but your approach is in line with Normcore’s documented extension points.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@719968242445058051> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
I don’t fully understand the question, but it sounds like that would work? isn’t that what we do in our addressables recipe on the docs site?
the only reason we maintain the dictionary is because you don’t always know when a remote client is about to instantiate something and so you don’t want to be trying to synchronously load it in that case
yeah my bad for the word salad I guess what I'm asking is :
if I call Instantiate during LoadRealtimePrefab() will that break Normcore's initialization of that GameObject.
As long as I pass the same GameObject to InstantiateRealtimePrefab and just return immediately. Is that fine?
yeah that’s totally fine
Word. Many thanks Max!
really appreciate it.
In the docs you guys just still wrapped the Instantiate(prefab) inside InstantiateRealtimePrefab, but it makes sense why it wouldn't matter when it was called as long as the correct GameObject is passed.
Thanks again!
sure thing!