[FEATURE REQUEST] Property Access System Features

Loving the new Property Access System for Animation Blueprints. Some ideas for extensions, most are probably obvious or stuff you’re working on, but still :slight_smile:

  • Be able to negate bools (and everything)

  • Be able to use it as criteria for things like Blend by Int/Bool/Enum (You can use it for the time, but not the actual criteria)

  • Speaking of Enums, would be awesome if you could do at least enum equals comparisons. Might be some technical issue why not, but that’s a biggie that requires a lot of rework to get around

  • If Possible, ranges, again, this might be too complex for the PAS, but would help a lot.

Btw. Would love something similar for normal blueprint variables, parameters etc so you could make blueprints less messy

Anyhooo, keep up the good work

I just wanted to let you know, Homde- I’ve passed this to the team. If there are any updates on this, we’ll be sure to update the thread. :slight_smile:

Hey, If I can make a slight addendum :slight_smile: I noticed you can’t copy/paste Property Access bindings. Would be great if they’re repetitive

Can you also pass along that while well intentioned, this thing is actually a total disaster as it is? It accesses arbitrary uobjects and calls arbitrary ufunctions from the anim worker thread in parallel with no safety checks whatsoever. Most game code is NOT thread safe. No one expects it to have to be. No one expects to have to worry about multi threading race conditions when working on an animation blueprint in the editor.

We’ve wasted whole days trying to determine why our animations were subtly wrong and completely exploding in some edge cases, and it was just because of that. This is going to create the most cursed bugs people have ever encountered, if it isn’t changed to collect the values on the game thread and cache them.

This thread will act as a course source of the initial feature request, so any further information or amendments to the original request will be visible to the developers :slight_smile: So any additional information you wish to add will be great! :slight_smile:

I think the main idea (I’m no export) is to put data to be accessed multithreaded in FAnimInstanceProxy (as described here Animation Optimization | Unreal Engine Documentation), When something call out to AnimInstance I think there’s a lock taken as to minimize race conditions. Also multithreaded animation has to be explicitly enabled.

You can probably access stuff that will get you into problems with the PAS, as you mention, and a system should make it hard for a user to shoot himself in the foot. Perhaps some additional locking/safety could be put in place, or some locking when you call out. The warning system regarding Property Access System seems to be lagging behind a little, perhaps due to it being a new feature.

It’s on by default, and should be for performance reasons.

That’s the point. The system is a giant footgun as it is. You can use it correctly - but nothing tells you that it’s going to call your functions from worker threads - and a lot of users probably won’t even know what that means, why it’s a problem, or how to deal with it.

If your game supports modding, this issue becomes elevated from a fun bug to a critical security hole.

Another nice feature would be, where possible such as referencing a variable, be about to right-click and chose like “Collapse to Property Access”, and vice versa, “Expand to Node”

If you wanted to be suuuuuper fancy it would be awesome to have a “navigational path control”, kinda like windows explorer, where you could click a down arrow of part of the part to select something without having to start over

Another thing, (sorry!) Would be reeaaaaally useful to have a search box beside anything that takes property access. It could even search recursively through all available options. Precariously navigating several hierarchies of dropdowns soon becomes unwieldy :slight_smile: Especially when you have structs with tons of attributes

I want to thank you for letting us know about these issues. They are currently slated to be fixed for 4.26.2. It was always the intention that we only ever call unsafe code from the game thread and cache the results.

Glad to hear it was just a bug!

Well, after updating to the latest 4.26 changes, our animations are broken again. It looks like now it’s desynced, where some functions are called on the game thread and some properties are being read from the worker thread, after the game logic has progressed further.

This especially affects manually ticking character meshes.

I’d like to get some insights into what your expectations are here. For instance what you are trying to acheive and whether the system is not performing as expected. For reference, if a function is called via property access, if it is not deemed thread safe via metadata (and BP functions are always considered non-thread safe, for example) then it will be batched in a set of calls made from the game thread before anim update/evaluation is performed and the results cached on the node’s properties themselves. Internal data accesses and thread-safe calls will be performed on the worker thread as the anim graph is updated and copies will be made there and then to the anim node’s properties.

The specific problem we are facing is that the animation grabs several parameters from the game state, some directly and some through accessor methods. However, some time will pass between the character mesh manually being ticked (which grabs the values from accessor methods) and the animation evaluation task running (which grabs the remaining values). Between those, the game logic continues executing, causing a de-sync. Depending on what you’re doing, the desync may result in small or very severe errors in the animation.

I’m not sure what the correct solution is. Perhaps a setting to force it to execute all copies on the game thread and call it a day. It’ll still be much faster than using BlueprintUpdateAnimation.

How are you ‘manually ticking’ the animation? It is unusual to tick only the event-graph style logic independently of the graph itself.

Characters do this by default, see TickCharacterPose

Much to my chagrin, that calls through with

bNeedsValidRootMotion = true;

, which means that UpdateAnimation ends up calling ParallelUpdateAnimation to update the graph as well on the game thread ‘in-line’. In what set of circumstances are you seeing the graph NOT be updated?

Hmm. I think, this will require more in depth investigation into *why *our animation is exploding with that latest commit. For now, I’ve bodged modified it to require external for all properties and it works smoothly again.

[USER=“2567”]Tom Sarkanen[/USER] I’ve found the problem. The bug is in UpdateAnimation, property access external batched copy is being executed **before **the anim instance/blueprint updates the state for the current tick, while internal ones are obviously grabbed after. This is the cause of the de-sync.

Fix is simple:

@Zeblote Thanks for tracking that down!
Im interested in your use case here - to me this implies that you are doing some data transformation in your event graph/native update, then accessing this via a function (I guess transforming it further?).