Scene Graph is now available as an Experimental feature in UEFN
We release tools as Experimental to give you the chance to try out new functionality that is still under development. This allows you to try out new features and helps us improve them based on your feedback.
[Question] What was the decision behind making mesh_component no longer be the base type for static_mesh_component?
[Feedback] mesh_component has a var Material: ?material property which is not @editable, therefore it cannot be set in the editor.
[Feedback] The same property seems to be wrong. A single mesh can have 0-n materials, not 0-1. The creative_prop allows to set 0-n materials on its root mesh via SetMaterial<native><public>(Material: material, ?Index:int = external {})<transacts> :void method. This seems like a bigger oversight. However, I already reported this issue before Scene Graph was even released.
[FEATURE WISH] Please expose GetEntity methods for fort_vehicle and fort_character. Additionally please make sure that fort_vehicle entity is NOT the spawner but the actual vehicle. That way we can apply custom attachments to the vehicle.
[FEATURE WISH] We need a component for a Control Rig asset. While it might be a little bit away, in the meantime at least I hope we can get an actor bridge where we can temporarily attach the CR actor by hand.
[FEATURE WISH] When we get access to the player and vehicle entities, could we possibly also the following two capabilities:
fetch their mesh or skeletons components and change the scale to be smaller or larger (I would like to make vehicles a little bit smaller to be accurate compared to real world counter parts)
the ability to disable the pawn mesh or skeletons altogether in order to replace them with custom meshes (this would enable so many new creative ideas)
[FEATURE WISH] This is for the unreleased verse camera APIs. Can the camera APIs receive the capability to apply custom camera shakes?! This is especially important for custom vehicle cameras. Additionally I really hope that custom cameras will not only work on the player pawn like the current early access cameras, but also on vehicles. I’m trying to push vehicle focused maps, it’s a lot of work, but many things are being left out on that front.
[Feedback] The same property seems to be wrong. A single mesh can have 0-n materials, not 0-1. The creative_prop allows to set 0-n materials on its root mesh via SetMaterial<native><public>(Material: material, ?Index:int = external {})<transacts> :void method. This seems like a bigger oversight. However, I already reported this issue before Scene Graph was even released.
Mapping multiple materials onto meshes will be supported in the future.
Could that potentially negatively affect the creation of future (H)ISM and spline_mesh components? I can’t wait for these three mesh component types.
Could that potentially negatively affect the creation of future (H)ISM and spline_mesh components? I can’t wait for these three mesh component types.
It won’t negatively affect those. (H)ISM may not be mapped into the scene graph 1:1 with its actor implementation but we will create capabilities that solve the same performance/memory issues that ISMs address. Similar story for things like spline mesh and skeletal mesh; there will be equivalents but we’re still working on the specific designs so they might look slightly different than their actor equivalents.
Are current entities considered as always loaded? I assume there’s zero support for WP streaming right now.
Are meshes from mesh_component processed by the HLOD builder? Haven’t had the chance to test that yet. This would eventually need the ability to set the preferred HLOD policy to decide if the mesh should be merged or instanced instead.
Will the HLOD system be eventually entity-fied as well?
Are there any order guarantees on which way components of attached entities receive tick events? Some earlier tests seemed to indicate “depth first” order.
expose subscribable_event, this would make components (or actually everything) better.
always mention an approx release date for experimental features. I am not going to bother with something, if i don’t know if i can publish anything within the next week, month or year.
add interactable_component and trigger_component, so we can do more with them than just spawning Meshes, Particles and Lights.
aside from the entity related components mentioned above, the components that i would be most interested into would be player/fort_character components. When seeing that they weren’t exposed this patch, i was slightly disappointed.
[FEEDBACK] Components cannot be reordered on an entity.
[FEEDBACK] It’s not possible to create purely data / verse driven entities with sub-entities and components. UEFN enforces the transform_component. It would be great if we could create entities and prefabs without a transform. They don’t need any visual representation, nor any position, these would only contain logic. For such entities, transform is redundant.
the entity class should have an Entry point. It is weird that i can define a subclass of entity, but not specify any components at all. This makes creating subclasses of entities in Verse kinda useless.
GetCreativeObjectsWithTag<native><public>(Tag:tag)<transacts>:[]creative_object_interface is a global function while (InEntity:entity).FindEntitiesWithTag<native><public>(Tag:tag)<transacts>:[]entity is an extension method to entity (in this case it would be the root entity).
The answer is a bit complicated. You are correct that there is no support for WP streaming for entities yet. We’ll be working on streaming support in the future. However, entities and their components do participate in the underlying FN relevancy system. On the server where your Verse code is running the components will always run, but the replicated information that updates things like meshes or transforms might not happen on clients if the user is far away from that entity. So your code changes will stick but the user won’t see it until they get close enough to the entity.
The editor automatically injects transform_component for you since that’s the more common workflow. You should be able to remove them if they aren’t being used for that entity. You can also spawn entities directly through Verse which will not have any components on them outside of the ones you add.
We’re still working on the long term Verse theory underpinning “prefabs as classes”. There is a lot of good research ideas internally but we have to align the data structures before we add formal support for writing a derived entity with default components manually in a sustainable way.
seems to be wrong. A single mesh can have 0-n materials, not 0-1. The 
