I see that one of the big advantages of using Apparance it’s the ability to update your creations at run-time.
What is the correct or suggested method of updating / spawning and replacing entities at runtime.
The example below has a box collision being updated at runtime.
The left one is Unreal Blueprint updating a box collision on top a static mesh.
The right one is Rebuilding the Apparance Entity, which in turn rebuilds all of its collision.
That means that the collision is removed from the world, and another one is placed in its place, and if the player is on top of it.
If there are any systems (such as locomotion foot ik), in place that perform a blueprint collision check with an object to then use it, when the carpet gets pulled from under them so to speak, (I mean the box is deleted and a new one added), the system doesn’t like it very much, and it can completely break.
So, are you saying that it all goes wrong if the character is on the right box and they fall through?
At the moment, there is no re-use or pooling of generated components. This is something that needs adding for this sort of thing to work, it’s not trivially easy as there are some complications around making sure all changes are correctly applied to recycled objects. Hopefully this would fix the issue.
On the subject of runtime generation, whilst it is designed to generate things at runtime, the idea of animating this generation process is only a by-product of this capability and not explicitly supported. Some of the things you can do interactively do have potential to be used in an application but you risk it suffering at the expense of other generative objects you add later. This means that it is more a case of “if it works for you then go for it” and trial-and-error and testing will be key.
I have pondered using this technique for changing state of objects more gradually, e.g. progressive damage on impacts or building something up with a series of buffs. Animating it might be asking too much, but try it and see.
That’s because the locomotion system I’m using (does raycasts down to the ground to figure things like foot-locking and mantling, I haven’t tried with default physics objects. I’ll check that out later.
But lest talk more general terms.
Let’s say you are generating more detailed versions of something depending on the LOD (like you did on the city)
You would handle the logic of replacing those LODs in externally to Apparance? or is that something you could do inside a procedure?
I guess I’m kinda answering my own question here, for the entities to be rebuilt they’d have to have the Rebuild appearance entity called on them on the LOD change. (How did you handle that with NYC?)
I mean, you’d have to handle the streaming of appearance entities in / out in your externally to apparance.
LOD management tends to be application dependent and as such you have to implement that outside of Apparance procedures. You can certainly have alternate versions of objects that the procedures can generate (parameterised by detail), but there’s no management of switching them for you. I’m not sure how easy it would be to integrate LOD generation into Apparance Entities so that it will rebuild and switch between different detail levels automatically but this would certainly be a nice feature to have [feature request].
Having said this, part of the original Apparance premise is dynamic detail and endless scalability, and some of this tech is still in there, but not exposed in the plugin. The reason is that it needs to be a lot more intrusive in how you structure and run your scene, from how objects and elements get added/spawned, to how the materials work, to how rendering/visibility is decided. This is something that I will be revisiting in the future, but it’s not going to be in the plugin anytime soon. Until then you will need to build your own (hybrid) system for detail management. For example, generating dungeon layout procedurally to instance empty room placeholders, then use BPs to manage the generation of rooms as the player approaches each one (and discards with distance).
I also notice that you can’t set Apparance Entity to Movable or Stationary.
Say you want to procedurally generate an Elevator Platform and animate its position through blueprint without rebuilding the Apparance Entity, right now you can’t.
so this is not something you can do with an appearance entity.
Even if you were to spawn a movable blueprint entity that in turn spawns the appearance entity that builds the platform, the platform would still be static.
