By design (bad?) GetPosition node returns value depending on system space selected (World/Local).
How can I modify or get this position differently so I always get the world or local position independant of current system space ?
Hey @koirat ,
I believe the position attribute is just a Vector3, it’s not spaceable (does not store any data on what space it’s in). If you want to convert it to a particular space, you can use the Change Space operator, here for example from local to world:
Thank you for you input.
Yes I understand how GetAttribute:position is working (I have learned by my own mistakes). And I have to say I was quite surprised that we do not have GetAttribute: positionWorld and GetAtribute: positionLocal or equivalent.
Anyway by example I would like to point out what I think is a general problem with it.
I had a particle system in local space, this system from time to time pushed particles into it’s origin local (0,0,0) and out of it creating pulsating movement.
Than I decided to convert it into world space because I wanted the particles to drag behind the moving object, and all my system started to behave differently/wrong.
Now I know of ChangeSpace node but it is still not safe since you need to know what space your position is anyway.
You cannot create more generic systems or subgraph operators.
What we need is positionLocal, positionWorld I was mentioning before or node that converts position to Local/World with implicit system space consideration.
Without having seen the graph, I’d just venture one guess that something like this could have fixed your graph: you can set the position in the space you want, even if it’s different from your system’s space.
The position is always in the system’s space, and since the system space cannot be modified dynamically, it should be quite safe to create a subgraph with the ChangeSpace operator if you want to extend the functionality.
This might help illustrate it:
At (0,0,0) we have the world origin. We have a VFX game object at (1,0,0). If the system is local, and we set the particle position to (0,1,0), then if we read the particle position, it will return (0,1,0), i.e. local space, relative to the VFX transform. Plugging the position for debugging into a Set Color block gives us a green particle, with an RGB value of (0,1,0).
If we do the same with world space and debug the particle with color, we get a yellow particle (RGB (1,1,0)).
- note that we are setting the position in Set Position in local space (the little L icon), so it will set it to 1 up from the local position (which is 1,0,0) to give us (1,1,0) as the final result.
Again thank for your effort @VladVNeykov
I know that I can set my particle position independent of my system space, I’m using it and appreciated it greatly 
.
Pity I cannot get my particle position independent of my system space. 
Moment I need to do some computations on my particle position I will have to always be wary of my current system space.
I cannot create working elements sets that could just be copied from one particle system to another without worrying that I forgot to do some additional steps.
Personally I consider this feature to be important, it also does not look like a difficult one to implement.
It could be realized also as an attribute returning current system space (or boolean → IsWorldSpace etc…)
How can I make a feature request and what are my chances to see this included in an engine ?
That’s fair, it’s not something I’ve personally encountered, so it’s valuable for the team to get feedback on what everyone’s needs are.
Like many things, it might not be difficult, but it could be complicated Some possible considerations:
- Any attribute is stored per-particle, so just adding another space attribute or extending the float3 to a float4 for position is an additional 4 bytes of data. Not a deal-breaker, but a consideration (suppose it can only be stored if it’s read somewhere in the graph, etc.).
- Rather than having position be a spaceable attribute, it might be more versatile having an operator which can return the system’s space so everyone can implement their own custom logic based on their needs (i.e. rotation based on space) We try in general to avoid bloating the number of operators/blocks and focus instead of building blocks which enabled people to create custom solutions for their needs.
- Adding space as an operator currently is not feasible, as operators are global and not aware of individual systems.
- We might want to support eventually local system variables which, depending on their implementation, might provide an interesting per-system way of storing space, instead of per-particle.
- Space in general is something we’d like to revisit: for example, it might be useful to support custom space (like the built-in particle system does) so any implementation for this has to take that into consideration.
- I think an idea was floated around for an additional VFX-specific offset (kinda like an internal transform so you can rotate your whole effect without rotating the transform itself) so this should also work with any space re-work.
So in short, lots of willingness to make the tool better, but we have considerations we need to take into account.
We’d def. love to get your feedback, you can submit new ideas here.
We review suggestions continuously, then prioritize based on urgency. As you can see on the roadmap, there’s already a bunch of highly-requested features and improvements being worked on. It’s helpful to get the feedback so when new features or rework on existing ones is being done we can account for the range of use cases out there.
Hope this helps, thanks for the feedback!
3 Likes