Hi there,
I am just trying to reconstruct one of the examples where Sim Ember samples velocity from a particle source and I can’t seem to make it.
I tried with both PRTLoader loading particles w/ velocity and also tried sampling PFLow. In both cases when I scrub the timeline I get no vectors no matter what. Also scrub bar responds very quickly as if there was no Ember at all.
Ideas?
The input particles object seems wrong. I wonder what happened with the online builds vs. what we had at Siggraph - the InputParticles node does NOT accept PFlow sources yet. It has to point at an Event, e.g. “PF Source 001->Event 001”.
I picked a PF Source here and it automatically added the Event 001 object instead.
So it is possible that the build you are running does not have this UI code yet.
The trouble is I cannot send you my script because it was modified to work with later versions of Ember.
You would have to set the object via MAXScript, which is quite a workaround.
Something along the lines of
$SimEmber001.MagmaHolder.setNodeProperty 3 "node" (getNodeByName "PF Source 001->Event 001")OK but I tried also with prtloader. Is that a valid source?
What other sources can be accepted now?
Also with stoke can I directly use prtloader or pflow as a field? Or only via ember?
The maxscript assigner works pretty well and I am getting an event assigned, but it does not change the situation.
I also tried some othero perators but it does not help to get the ball across.
– EDIT –
Actually it looks as if it was this aprticular operator (ParticlesSumRadius) that fails. When I use Nearest Particle or ParticlesSumCount it seems to work fine.
Any chances for a build that includes that?
Or for being able to sample velocity data w/ Stoke directly from PRTLoader?
What I need it for is simply increasing the volume of a particularily demanding Pflow sim that takes years to compute (thanks to Ember mostly I guess 
).
So Ember/Stoke was what I wanted to use for that. If there’s no chance to do that I may try the old good hi freq noise approach.
Looking again at your flow, you have the comparison operator wrong, but it is probably not reporting the error correctly.
The NumParticles is an Integer, you are comparing it to a Float. Switch the logical operator to compare to Integer 0 and it will work…
We REALLY need to fix this on our side so 0>0.0 becomes a valid comparison. It is on the ToDo list anyway…
Well, let me check. And shame on me failing on obvious basics.
Lack of error messages in Ember makes the play a bit tough, but I appreciate what you made available anyway. Without it my work would not be possible.
Generally unless there is a serious reason NOT to, I would suggest simply adding an automatic conversion at least between similar types so that would auto convert Int, float16, float32, bool etc… but probably not vectors (or maybe a magnitude normalized to 0-1). I guess in many cases that would work and if you have a special case you can always declare explicitly.
This is a huge topic. We don’t want to insert nodes automatically because people work in different ways and we cannot predict what they are doing next. PFlow Box #3 does that and I don’t like it because the moment you change the type of the input node, it breaks the flow.
We would like to have some basic rules of implicitly handling Integers and Floats so there is less need for explicit conversion.
Okey, it worked. Many thanks.
Just wrapping my head around these tools, so a few more general questions if you don’t mind…
If the particles are moving mostly in the same way, you don’t need too many, just enough to cover the whole volume where it matters. Since the current sampling is weighted by distance, the closest particle will will have the most influence, and the rest will barely affect the sample, so having hundreds particles to sample would just slow it down without producing a better look. If you are running the FFT solver, the result will be smoothed out anyway even with very few particles.
The Channel Sampling is the more important one - if you are sampling in a very small radius, you will capture more detail, but you will also need more particles (see 1.) If your radius is large, you will get influence of more particles falling within the sampling range, and the result will be smoothed out more. Of course, the Velocity sampling will also have an effect, but we interpolate the values quite well so even a lower res. grid will provide a fairly good representation of the field. So both will affect the resolution, but if your input is low res, it will probably affect the results more.
It is better to use Stoke for reflowing. Why do you even need a PFlow when you can pick the PRT Loader directly?
Stoke uses a much better algorithm for splatting the particle data into the grid (coming soon to Ember, too). It is much faster. Unless you need some advanced features from Ember, I would suggest Stoke. That’s why we wrote it in the first place - fast and simple advection of particles!
Looks AWESOME!
Not sure if you got what I mean. Essentially what I need is to:
I Can read PRT Loader data as a distribution source, but for velocity field I need either:
→ PRT Loader > Ember Sampling Velocity by Position & radius >set Ember as Velocity Field
→ PRT Loader > PFlow Birth & Update > set PFlow as Velocity Field
I wish I could add PRT Loader as a Vector field source directly, but I cant (it’s not on the list and not mentioned in documentation).
I totally got what you meant, and the StokeUI.ms I see here (even from the older build you have) should allow for PRT Loaders as Velocity sources.
The filter function should look like
fn filterSources obj = findItem VelocitySources obj == 0 and findItem #(PF_Source, KrakatoaPRTLoader, PushSpaceWarp, Vortex, Motor, Drag, PBomb, Path_Follow, Gravity, Wind, Spacedisplace, SIMEmber, FumeFX, Stoke, Spray, Snow, SuperSpray, Blizzard, PArray, PCloud, Thinking) (classof obj.baseobject) > 0 and obj != selection[1]
and it clearly features KrakatoaPRTLoader as a valid velocity source class.
I tested it (in my current build though) and it worked as advertised.
Please check the StokeUI.ms file and see if the line I posted matches yours…
Mine was different. I edited the code, but still I can’t add a PRTLoader neither via direct pick or list.
Maybe I could get your build? I’m starving for it! Since we’re in alpha I’ll keep asking and bugging you anyways, so it does not make much difference, does it?
We will release a new build as soon as we have tested the changes - they were BIG changes and my script would not work with your plugin at this point…
Looking forward to it. Hopefully today since on Friday I need to send my film to Cannes 