I am not sure if I am missing something..
It appears that the spawn operator can only emit child particles with exactly the properties of the parent? (The same type of particle) For example if the parent has a PhysX shape then the spawned child particles have the same collision shape. How do I spawn child particles that have no PhysX Shape from those that do? Especially if I am deciding to emit the child particles using specific logic and circumstance.
For an example what if each particle is car driving around spawning smoke particles behind it. If the car has PhysX Shapes for collision then the spawning will cause the smoke particles to have PhysX shapes that will collide with the cars?
Somewhat related I also notice that the SetTarget operator will alter targets of spawn operator particles produced before they are sent to another event (it does say in the docs they won't be sent out until the end of the event, but still in this case it seems a bit confusing). Seeing as the spawn operator lets you add a custom property to particles they can be tagged and filtered - but it seems odd you can't set the simulation group of the spawned particles in the operator?
Do I somehow have to spawn into a different flow? Or have I overlooked something else?
(05-28-2023, 05:58 PM)wbk Wrote: How do I spawn child particles that have no PhysX Shape from those that do?
Just place a PhysX Switch operator (set to disable), in the the event where spawned particles are.
(05-29-2023, 01:11 PM)d4rk3lf Wrote: (05-28-2023, 05:58 PM)wbk Wrote: How do I spawn child particles that have no PhysX Shape from those that do?
Just place a PhysX Switch operator (set to disable), in the the event where spawned particles are.
After I posted last night I of course found the 'Shape Remove' operator today lol. I will have a look at the switch operator too thanks.
But in general it would be really helpful if there was a mode in the spawn operator that output 'fresh particles' with no properties or shapes. For example removing lots of unneeded custom properties on spawned particles in certain circumstances is overly verbose without something like that.
Well, you can change shape of the particles, anytime you want.
What is preventing you? 
Just add a shape operator in second event, and it will override previous.
PhysX Switch set on disable, will remove any PhysX calculation.
As for spawning "fresh particles", as I said, I never had any issuers with above approach I mentioned, but you can also do another method.
You can create new TyFlow, and add Birth Flow, and Flow update operators, and the new TyFlow will just read from the first particles whatever values you want.. and from there.. you can do whatever you want.. spawn them.. delete them.. send them...
I often use it for complicated destructions.
(05-29-2023, 02:14 PM)d4rk3lf Wrote: Well, you can change shape of the particles, anytime you want.
What is preventing you?
Just add a shape operator in second event, and it will override previous.
PhysX Switch set on disable, will remove any PhysX calculation.
As for spawning "fresh particles", as I said, I never had any issuers with above approach I mentioned, but you can also do another method.
You can create new TyFlow, and add Birth Flow, and Flow update operators, and the new TyFlow will just read from the first particles whatever values you want.. and from there.. you can do whatever you want.. spawn them.. delete them.. send them...
I often use it for complicated destructions.
Ah ok - so I think what I am missing is that it is intended that 'I should be' using different flows for different 'types' of particles. So in my example of particle cars leaving behind trails of smoke. Is that the cars should be one flow, and the smoke another flow referencing the car flow with the birth flow operator.
(05-29-2023, 02:19 PM)wbk Wrote: Ah ok - so I think what I am missing is that it is intended that 'I should be' using different flows for different 'types' of particles. So in my example of particle cars leaving behind trails of smoke. Is that the cars should be one flow, and the smoke another flow referencing the car flow with the birth flow operator.
Not necessarily.
I just mentioned it as another approach that might be handy for some stuff.
You can have all in one flow... cars with physX sims, then just add spawn operator, and in the next event add PhysX Switch set to disable, add another shape operator set to whatever shape you want, make their scale however you want... add wind if you want.. graviry.. etc...
Don't forget to check in spawn operator that they should be spawned on particle mesh, rather then pivot (if you want that).
Also, don't forget that play with inheritance in spawn operator.. it's on 100% by default.. reduce it if you want.
The Birth Flow/Flow update approach might be handy for this, only because you wouldn't have to re-simulate cars PhysX each time you change something in the second event.
05-29-2023, 03:43 PM
(This post was last modified: 05-29-2023, 04:30 PM by wbk.)
(05-29-2023, 02:31 PM)d4rk3lf Wrote: (05-29-2023, 02:19 PM)wbk Wrote: Ah ok - so I think what I am missing is that it is intended that 'I should be' using different flows for different 'types' of particles. So in my example of particle cars leaving behind trails of smoke. Is that the cars should be one flow, and the smoke another flow referencing the car flow with the birth flow operator.
Not necessarily.
I just mentioned it as another approach that might be handy for some stuff.
You can have all in one flow... cars with physX sims, then just add spawn operator, and in the next event add PhysX Switch set to disable, add another shape operator set to whatever shape you want, make their scale however you want... add wind if you want.. graviry.. etc...
Don't forget to check in spawn operator that they should be spawned on particle mesh, rather then pivot (if you want that).
Also, don't forget that play with inheritance in spawn operator.. it's on 100% by default.. reduce it if you want.
The Birth Flow/Flow update approach might be handy for this, only because you wouldn't have to re-simulate cars PhysX each time you change something in the second event.
I am not sure why but the text of your last message comes up super tiny but still helpful when magnified! I am working on a lot of script logic and custom properties with this, so I think the multiple flow option is probably the best in my case then.
Oh but when I use a birth flow it takes either none or all the custom properties. Which is a bit annoying if I only want say the target from the previous flow but not the rest of the custom properties (of which I have quite a few states).
Not sure I understand bro.
Any preview that you can share, and/or Tyflow editor screenshots?
(05-29-2023, 05:48 PM)d4rk3lf Wrote: Not sure I understand bro.
Any preview that you can share, and/or Tyflow editor screenshots?
I mean if you add any custom property data channels to a particle they get carried along to any spawned or derived particles. For example if I have particles that are car models that have custom float data channels named 'damage' and 'headlights-active'. Then I spawn particles from them for smoke or wheel mud particles, then I don't need or want them to have those properties.
If spawned within the same flow the properties will be just there as there seems to be no remove property data channel operator. If in separate flows it seems you have to carry across all or none of those custom properties depending on if they are float/vector/TM types.
On a related note it seems carrying across the target of a particle from one flow to another doesn't work as the particle IDs in one flow don't mean anything in another flow - so you have to carry across the targets position as an actual 3d point.
In both Birth Flow, and Flow update operators, you can deselect all 3 Custom property values (Float, vector, and TM), if you like.
I am not sure how to transfer Particle ID's... maybe Tyson or someone else knows.
(btw, forgot to mention, you don't need to manually create second TyFlow, right click on empty space in the first flow, and go to preset flows - simple reference flow, and it will automatically, quickly, create it for you)
What I don't understand, why do you care if the custom properties are transferred (via spawn)?
Are you worried because it will consume more memory, or something like that?
In my expedience, it shouldn't be that memory consuming, and also I guess you can override custom property with another custom property with the same name (but not 100% sure).
|
