Robbert Groenendijk

Took a quick look at your setup and pulled it a few steps forward I've attached that file again. As for the changes;

- The most important thing is to really regard the surface constraints and the pressure constraint as totally separate things. Scaling the surface of a balloon does not simply multiply the inside volume and thus we need some tricks to calculate the correct rest length for the pressure constraint (you can see this in the setup that is attached). I've used a transform that looks up a detail attribute from it's spare input to simply scale the original balloon so you can visually see what is happening (you could also just calculate it all in a wrangle). We then have the original volume and the target volume, and can simply deduct a scaling factor from those.
- I've pulled the writing to the pressure constraint totally separate from the other constraints. Mostly for clarity.
- A real balloon has a bit more pressure than its surface allows for (hence the stretching of the surface). So we either scale the pressure up a bit (can be done in the wrangle with a slider) or lower the final restlengths a bit (done in the sim in the VellumConstraintsProperty node).
- The pressure constraint 'fighting' with the surface constraint can cause bit of random movements as they try to overcome each other. I've added a bit of drag to quickly dampen this, but there are many other more elegant ways of doing this.

Anyhow, I think you were not that far off. This balloon thing is a bit of a complicated setup, and doing the same with a softbody containing pressure 'strut' constraints would be much easier and more stable to handle. Hope this helps you out a bit tough

Cheers!

In the SOP network, prior to emitting the balloons into the vellum sim you can store the frame number on the geometry. A wrangle with something like f@emitframe = @Frame; will do. When they are emitted into the sim, this attribute stops accumulating and thus stores the frame at which it was actually emitted. You can then use another wrangle, or a VEXpression in the sim and just lerp the restlength based on that number. For example; f@restlength = lerp(f@originalrestlength,f@targetrestlength,fit(clamp(@Frame - f@emitframe,0,10),0,10,0,1)); This way, your restlength will lerp from the original length to another length over 10 frames. Additionally, you can store the targetrestlength on the emitted geo, giving you per-balloon control. You could even do the same with the time it takes to lerp, by replacing '10' with for example 'f@lerptime'. Hope this helps a bit

I had to deconstruct this setup a bit from a much larger setup, so there might be some things that you simply do not need or things that can be simplified for your setup. But it might help you get going. There is basically a curve that you can sculpt however that will guide everything down the line. The sim is extremely simple and fast, in another version of that setup I also transferred the f@curveu from the original curve to lerp attributes down the line (confinement of the shape for example). There are some operations in the last step to control the confinement of the shape and such, as the original setup was used to go from a water-like shape into a perfectly glass-like shape that still had to retain the bubbles moving through it (so we needed the flip particles in there).