Better/easier bridging. You bridge centers also get thinner as they stretch. Be something like - Amount of neighbors to connect, distance threshold and thinning. Zhu/Bridson can kind of achieve it but the bridges usually fail quite easily.
Strands image.wistatutor.com/content/fee … Fibrin.jpg
Thanks, this is something that drives me a little nuts, I spent a more that a couple hours trying this, I ended up with a kinda subpar result using a trail and scale, it just seems it should be easier to get a little better stretch out of the mesh.
Like a viscous thing, like honey for example, leaves a nice long thin strings before it completely breaks from its parent.
Not always do I want to have to use a billion particles
If the particle had a 3 component scale and an orientation (they do!), then you would be able to make elongated splats to the voxel grid aligned to some sort of field, or defined by velocity, or oriented to the PCA of the neigborhood, or whatever.
The Anisotropic mode uses an ellipsoidal particle kernel. But in this case stretching the search to reach the one far particle will also reach the other far particles, and you won’t get a strand to the one but a flat disk to both.
The Anisotropic mode stretches the kernel for you. What I want is explicit ellipsoids from the particles themselves. The channels are all there, so if you did a Box#3 BloodMoon setup and oriented and stretched the particles as you made them, Frost would use those channels to make a the splat ellipsoids instead of doing it’s own stretching. Anyway, that’s the idea.
EDIT: You could do the opposite too. Emit particles from the surface of a mesh, orient the particles to the normal/binormal, and scale the particle according to the distance to the nearest particle. So your splats would look more like surface filling sequins.
I thought it risky to post such a statement but I had to risk it, knowing full well I might receive deluge of criticism and possibly offend the hand that feeds me, it was not done out of spite but for the better good
I see, I see, yep that is what I would like
I did try it with the Anisotropic and to get any kind of believable stretch the main body would totally loose its structure.
As I mention and you noted, another approach, I am able to fake it with intermediate control particles and scale them down succession, although it is hard to reach a smooth no bulge look. I can bring up the blend radius to almost get rid of it but it is still exist. From afar it is good, up close not so much.
I like the idea of ellipsoidal particles, and they are on our wish list. However I’m not sure if they’d work here – because of the ellipsoid’s symmetry, it would stretch both toward and away from its neighbor, so I think you’d still need to seed particles along the strand?
Like Chad had mention, it would be along the speed or normal vector of the closest or threshold value of a neighboring point. If I understand correctly. Would the deform always have to be mirrored?
The problem is that to make a strand that is .01 units thick, you need to have your particles roughly .01 units apart with a radius of .01 units. This makes for a lot of particles, but at least they are easy to set up.
If you do ellipsoidal particles, you can make them .01 units in radius along the axes perpendicular to the strand, but have a radius of .5 along the strand, meaning you can space them ~.5 units apart. In this case saving you ~98% of your particles.
The only reason I suggested ellipsoids, and not something more complex (superquadratic ellipsoids? oloids? spherical harmonics?) is that it’s trivial to represent it in the particle system now. No extra channels, no aliased channels. Trivial to show in the viewport PRIOR to meshing.
Could you support particle shape mesh splatting? Or Geometry splatting at all? Like if you voxelized the mesh instead of the points of the mesh? That would solve a LOT of other issues, but would be slower than the case of “like sphere, only scaled/rotated”.
What I was suggesting, however, was that you control all of that in the particles themselves. Not in Frost. Why? Because your particles are history dependent and Frost is not, so your particles would be able to set up the difference between strands that are broken and those that are not, and you would be in a better position to avoid cases where the “closest” neighbor changed from one frame to the next enough to flip the axis.
For sure. I have a feature request for a meshing mode similar to “Geometry”, but which meshes a union of the geometry level sets. Are you thinking of something along those lines?
This is something that I was having a difficult time grasping if it were based in frost, because yes that would be an issue, it seems it would have to have some kind of a “timed” relax or ease curve and who knows however many other params.
Right now we cannot use orientation/scale in Frost at all. What I’m saying is that if we COULD, then you could make particle systems that used this feature to make the kind of level sets you were describing with very little effort at all. Rather than have Frost be a black box of voodoo processing, just let it accept more explicit data that can be trivially made in your particle system.
Metaballs have, since Blinn introduced them until now, been plagued by the fact that the surfacing is not time dependent, which is exactly NOT how you typically use them for modeling particle fluids. There’s no “attraction” between particles in the real world, and while you can pull the particles apart quickly and get a nice effect, pulling them slowly apart, or worse, pushing them slowly together gives you a really lame effect. BUT the meshing is history independent, so it’s pretty fast. We don’t want to have to do a Frost run-up, especially if we are meshing from data (like particles) which already has a run-up.
I’m not sure why it would need to be similar to Geometry. I’m thinking the level set would be more like Union of Spheres, the only change is that you would allow the level set to be splatted by geometry level sets. So if you look at how PRT Volume works, you’d do a union of all of those level sets and mesh the result using the current Frost meshing types.
Ah, I see the problem. Frost assumes ALL the inputs are pointsets. So you need at least 2 classes of sampling inputs, points and level sets (and whatever else we come up with). The resulting mesh would be a union of all the inputs. So you might have ((UnionOSpheres(PRT Loader 01))+(ZhuBridson(PRT Loader 02 + PRT Source 01))+(Anisotropic(PF Source 01)+(LovelyLevelsetSampler(Geometry Level Set 01)) or whatever. Once you add a non-point input, you’d lose the direct replacement methods, so you couldn’t do Vertex Cloud or Geometry, unless we decided on a good means of handling that, ala PRT Volume.
Chad
EDIT: Oh, ok. I see where you were going… You’d still use particles, but use the particle shape mesh do define the splat kernel. So even if we were just doing one mesh, we could make a particle system with one particle and assign it that shape mesh. Interesting…
Yes, that’s what I was thinking. I would like to mix inputs like you described, but I’m not sure how we could fit it into Frost.
Here’s what I’d like to implement: add a new meshing mode that’s like the current “Geometry” mode, but which performs CSG operations on the geometry level sets. This would let you union particle shapes together, and subtract using negative radii (or negative density or whatever).
In addition to the new meshing mode, I’d like an input that is unioned with the particle implicit surface, and another input that is subtracted from the implicit surface. For example, let’s say you are meshing water poured into a glass, which was simulated using a hybrid particle + level set simulator. You mesh the particles using Zhu/Bridson, union them with the bulk liquid level set, and subtract the glass from the result to prevent the liquid surface from penetrating the glass.
That sounds good, but it would seem to me to be very inefficient compared to ellipsoid splatting. Much more flexible, but at a cost if you only want something better than spheres. These strands would be ideal case for ellipsoids.