Getting data from other events

[masqu3rad3]

I used to use a simple trick with data operators to get/set data from different flows.
"Custom Properties" operator lets you do that in the same flow but not from other flows. Is there a way to achieve this in tyFlow?

I attached a simple snapshot to tell what I mean.

[tyFlow]

Hmm, that's a tricky one...if your flows have exactly the same number of particles and you don't plan to delete any of them (so the offset between their indices will always stay the same), you could accomplish that pretty simply with a script operator.

Within the particle loop you'd just put this line:

Code:

int offset = 5000;
tf.SetCustomVector(sInx, "channelName", tf.GetCustomVector(sInx + offset, "channelName"));

[masqu3rad3]

Brilliant workaround. Never thought of that.

[jrandom]

This brings up a really good point, I would really like to see an easier method of channel manipulation. I feel a little lost without Data Ops. While the Script op looks super capable a visual workflow is much easier and also allows for much easier/faster experimentation, particularly for less coded driven users.

For example I am screwing around with a procedural car. I have objects bound, I have a simple drive method, but what I would really like to do is be able to control the cars speed/path/articulation with a lead particle in a different system (separate Birth Event).

I was trying to use the Set function in Custom Props, then a Get function well, even having the same particle count across two events I can't seem to Set the properties of the second event. For example, I am grabbing Velocity Magnitude in EV1 in Channel 5 and want to send it to Spin Magnitude EV1 Channel 5.

So my guess is that there is only local scope for the Custom Properties operator?

[tyFlow]

Custom properties are local to each particle, yes.

Eventually I actually plan on adding a vehicle actor helper to tyFlow, to achieve exactly what you're trying to do.

As for visual data flows...I personally found the opposite to be true. I always thought PFlow's data op was incredibly clunky...so many nodes required to achieve simple things like modifying a matrix row or swapping vector coordinates, etc....massive trees of nodes impossible to parse at a glance that could be translated into a couple lines of code. The only reason I used data ops is because pflow's script operator was slow and limited. Hence my focus on tyFlow's script operator instead.

[jrandom]

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.

[cgdvs]

I also want to have operators that visually manipulate the data stream. It's not just about customizing the data and channels you need. Can also do multi-condition testing. Can collect some information about objects and particles, and so on.

[3d-agent]

Custom properties are local to each particle, yes.

Eventually I actually plan on adding a vehicle actor helper to tyFlow, to achieve exactly what you're trying to do.

As for visual data flows...I personally found the opposite to be true. I always thought PFlow's data op was incredibly clunky...so many nodes required to achieve simple things like modifying a matrix row or swapping vector coordinates, etc....massive trees of nodes impossible to parse at a glance that could be translated into a couple lines of code. The only reason I used data ops is because pflow's script operator was slow and limited. Hence my focus on tyFlow's script operator instead.

I do agree with you... but i am very much sure when you design TyData op, its going to be amazing.. in every expect.
Thanks for this amazing tool and reviving the 3DS max's particle system.