04-17-2019, 08:23 PM
Is it possible to make them setable to local/global or directable to particular events/operators? I think that would expand its scope by quite a bit.
Solid idea the vehicle actor
The car was simply a practical example of utilizing cross system channel data.
Well here is a pitch:
The schtick, tF/tP/PF/MCG/OSL/Krakatoa Magma+Stoke+Genome/Houdini/ect. are all visual data flows.
Coming from using pArray with a linked object/spacewarps/helper hierarchy to node based systems, you can't even compare to two. You break hierarchy in one you need to rebuild the hierarchy from the break point, the other sees the change and compensates automatically, with no further input from the user.
The number of iteration cycles, learning though process and the speed of experimentation you can do in a visually based system is orders of magnitudes faster, or to some extents solve what otherwise may not even be possible. Using this method we discover things we would have never imagined via code or linking.
I have also seen scripts operators that in no way could I parse what was happening at a glance. While I agree code is always more efficient, all the tools we use are based on it, the thing is the keys to the kingdom can be much harder to acquire for more right-brain dominate users.
You write code, while I write "some" code too, my knowledge of math operations on matrices/quats/pairs/even vectors is not all that strong. I can make a particle travel in a circular path with a few data ops, sadly I couldn't do the same in a script op with a bit of relearning.
I can safely say that I think quite a few of us have learned a lot of the little we know using Magma/Data Ops/MCG/OSL/ect. simply because it is possible to cycle through an abundance of options to immediately see an end result, if anything the system is smart enough to tell us we can't do an action before we try to proceed. Can't tell you how many times I have sent max into an infinite loop via script.
This has certainly taught me how to do more efficiently or fumble or hack my way through a lot of problems. Some things I would have had to pass on because I may not have been able to iterate through a script in an efficient enough manner.
Oh, best of all of the aforementioned tools also let you create libraries of user operators/nodes/objects!
If a visual data channel tool is not something you want to create, it is fine, it is your tool, I just think it is a mistake to write it off for the whole. It closes off a lot of creative brain power and limits those to pre-created ops/nodes/objects. At the very least consider developing a library of common scripts/actions that can help users understand your implementation better One of PFlow scriptings huge usability aspects is its close ties to MXS and Borislav Petrov and the huge quantity of practical solutions he developed for common problems.
Anyway thanks for reading.
Solid idea the vehicle actor
The car was simply a practical example of utilizing cross system channel data.Well here is a pitch:
The schtick, tF/tP/PF/MCG/OSL/Krakatoa Magma+Stoke+Genome/Houdini/ect. are all visual data flows.
Coming from using pArray with a linked object/spacewarps/helper hierarchy to node based systems, you can't even compare to two. You break hierarchy in one you need to rebuild the hierarchy from the break point, the other sees the change and compensates automatically, with no further input from the user.
The number of iteration cycles, learning though process and the speed of experimentation you can do in a visually based system is orders of magnitudes faster, or to some extents solve what otherwise may not even be possible. Using this method we discover things we would have never imagined via code or linking.
I have also seen scripts operators that in no way could I parse what was happening at a glance. While I agree code is always more efficient, all the tools we use are based on it, the thing is the keys to the kingdom can be much harder to acquire for more right-brain dominate users.
You write code, while I write "some" code too, my knowledge of math operations on matrices/quats/pairs/even vectors is not all that strong. I can make a particle travel in a circular path with a few data ops, sadly I couldn't do the same in a script op with a bit of relearning.
I can safely say that I think quite a few of us have learned a lot of the little we know using Magma/Data Ops/MCG/OSL/ect. simply because it is possible to cycle through an abundance of options to immediately see an end result, if anything the system is smart enough to tell us we can't do an action before we try to proceed. Can't tell you how many times I have sent max into an infinite loop via script.
This has certainly taught me how to do more efficiently or fumble or hack my way through a lot of problems. Some things I would have had to pass on because I may not have been able to iterate through a script in an efficient enough manner. Oh, best of all of the aforementioned tools also let you create libraries of user operators/nodes/objects!
If a visual data channel tool is not something you want to create, it is fine, it is your tool, I just think it is a mistake to write it off for the whole. It closes off a lot of creative brain power and limits those to pre-created ops/nodes/objects. At the very least consider developing a library of common scripts/actions that can help users understand your implementation better
One of PFlow scriptings huge usability aspects is its close ties to MXS and Borislav Petrov and the huge quantity of practical solutions he developed for common problems.Anyway thanks for reading.