The bubble contribution keeps throwing me curve balls.  Between the
opacity of the code and it not doing what the comments say it does (or
what anyone other than Charles Robertson expects it to do), I am unable
to figure out how Mr. Robertson expected this code to behave.

My intention with version 4.0 was to slow the expansion of the bubbles
as they rise.  After I uploaded it Wednesday, I was eager to try it out
on my glasses of Champagne, but I got unexpected results.  Fiddling
around with the bubbles revealed that the expansion rate varies
depending on how high the beverage is above the Cartesian origin.  This
has implications for a long-stemmed wineglass.

So I wrote a test program to try out bubble containers of various
heights and sizes, and that's when things got really weird.  The columns
of bubbles would not stay in their lanes.

The issue is a section of code that "adjusts" the column positions, and
ultimately derives from parameters eFluidX, eFluidZ, and fRadius.
Common sense would suggest that this is an attempt to deal with a
non-vertical container, but that is not what this code section does.  In
fact, I cannot figure out what the heck Mr. Robertson is trying to do here.

Version 4.0.1 suppresses that adjustment, forcing the bubbles to stay
within their container.  Unfortunately, the Champagne flute must remain
upright for the bubble columns to be positioned in any quasi-realistic
manner.

As for the bubble expansion rate, I am not an expert on fluid dynamics,
and clearly neither is Mr. Robertson.  Version 4.0 adds a global
parameter to control the expansion rate of the bubbles.  Between that
parameter and varying the height of the bubble container, one should be
able to find a combination that resembles real life carbonation.

(Why did I skip from version 2.* to version 4?  Because the initial
version of this contribution was 3.6, so I wanted to leave 3.* clear.
I'm guessing that the 3.6 was a misunderstanding of the version field of
the Object Collection upload form.)

In the attached images, Bubble_Rate = 1.00 uses the original expansion
code, and Bubble_Rate = 0.45 is the new default expansion rate.  All
containers in these images are vertical, so a tilted orientation cannot
be the reason for the "adjustments."

Post a reply to this message

Attachments:
Download 'test_bubble_sizes-old1.jpg' (164 KB) Download 'test_bubble_sizes-old2.jpg' (142 KB) Download 'test_bubble_sizes1.jpg' (169 KB) Download 'test_bubble_sizes2.jpg' (153 KB)

Preview of image 'test_bubble_sizes-old1.jpg'

Preview of image 'test_bubble_sizes-old2.jpg'

Preview of image 'test_bubble_sizes1.jpg'

Preview of image 'test_bubble_sizes2.jpg'

Bubble version 4.0.1:

  https://github.com/CousinRicky/POV-bubble/releases/tag/v4.0.1

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> The issue is a section of code that "adjusts" the column positions, and
> ultimately derives from parameters eFluidX, eFluidZ, and fRadius.
> Common sense would suggest that this is an attempt to deal with a
> non-vertical container, but that is not what this code section does.  In
> fact, I cannot figure out what the heck Mr. Robertson is trying to do here.

Since you have a vertical cylinder, then the x and z parameters are there to
keep wandering bubbles inside the cylindrical container.

It looks like he just didn't do a very good job of making the correction.
I'd try collision testing of the spheres with the wall of the cylinder before
the calculations of the next round happen, along with storing the direction of
motion of each bubble from the previous step, and a flag. If a collision will
take place, set the flag, make the bubble move toward the central axis for a
certain number of steps before releasing it from that corrective direction by
turning off the flag.

> Version 4.0.1 suppresses that adjustment, forcing the bubbles to stay
> within their container.  Unfortunately, the Champagne flute must remain
> upright for the bubble columns to be positioned in any quasi-realistic
> manner.

When I get back into "bounding cylinder" mode, I'll try to ponder bounding a
tilted champagne flute.

However, perhaps you should just use trace() to determine the starting position
of the bubble, and then when it collides with the side of the tilted flute, make
it rise along the edge until it's y-value equals the liquid's surface.

>
> As for the bubble expansion rate, I am not an expert on fluid dynamics,
> and clearly neither is Mr. Robertson.  Version 4.0 adds a global
> parameter to control the expansion rate of the bubbles.  Between that
> parameter and varying the height of the bubble container, one should be
> able to find a combination that resembles real life carbonation.

The size of a bubble is related to the pressure exerted on it.
Fluid pressure is dependent solely on the height of the column of liquid.
So you should start with a bubble of some initial size, and then adjust the
VOLUME of the bubble in a linear fashion as it rises.
P1V1 = P2V2

- BW

Post a reply to this message

I used one of those fancy new tools to generate some starter code.

I think creating a liquid object and then using insidedness tests would be the
way to go.  Maybe define a central axis to correct everything towards - that
would even work with a tilted container.

#macro Bubble(id, startX, startZ, startY, radius, fluidMinX, fluidMaxX,
fluidMinZ, fluidMaxZ, fluidSurfaceY)
  // Rise speed based on radius
  #local riseSpeed = radius * 2;

  // Vertical position based on clock
  #local currentY = startY + (clock * riseSpeed);
  #if (currentY > fluidSurfaceY)
    #local currentY = fluidSurfaceY;
  #end

  // Expansion as bubble rises
  #local scaleFactor = 1 + (currentY - startY) / (fluidSurfaceY - startY) * 0.2;
  #local currentRadius = radius * scaleFactor;

  // Turbulence: horizontal wobble using sine waves
  #local wobbleX = sin(clock * 10 + id) * 0.2;
  #local wobbleZ = cos(clock * 10 + id) * 0.2;

  // Apply turbulence to position
  #local posX = startX + wobbleX;
  #local posZ = startZ + wobbleZ;

  // Clamp to container bounds
  #if (posX < fluidMinX + currentRadius)
    #local posX = fluidMinX + currentRadius;
  #end
  #if (posX > fluidMaxX - currentRadius)
    #local posX = fluidMaxX - currentRadius;
  #end
  #if (posZ < fluidMinZ + currentRadius)
    #local posZ = fluidMinZ + currentRadius;
  #end
  #if (posZ > fluidMaxZ - currentRadius)
    #local posZ = fluidMaxZ - currentRadius;
  #end

  // Create the bubble
  sphere {
    <posX, currentY, posZ>, currentRadius
    texture {
      pigment { color rgbt <1, 1, 1, 0.9> }
      finish { specular 0.6 reflection 0.1 }
    }
    interior { ior 1.0 }
  }
#end



#declare fluidMinX = -2;
#declare fluidMaxX = 2;
#declare fluidMinZ = -2;
#declare fluidMaxZ = 2;
#declare fluidSurfaceY = 10;
#declare bubbleCount = 10;

#declare i = 0;
#while (i < bubbleCount)
  #declare startX = RRand(fluidMinX + 0.3, fluidMaxX - 0.3, i);
  #declare startZ = RRand(fluidMinZ + 0.3, fluidMaxZ - 0.3, i + 100);
  #declare startY = RRand(0.5, 2.0, i + 200);
  #declare radius = RRand(0.1, 0.3, i + 300);

  Bubble(i, startX, startZ, startY, radius, fluidMinX, fluidMaxX, fluidMinZ,
fluidMaxZ, fluidSurfaceY)

  #declare i = i + 1;
#end


If interested, I have access to a better verion, and GPT-5 at work, which seems
to be able to spit out a ton of higher-level code.

There's still a lot of mistakes regarding lowercase reserved identifiers,
macro-vs-function, passing undeclared identifiers into "functions", etc.,
however it gives you a lot of preliminary ideas to work with, and can help
implement tricky equations in code a lot faster.

-BW

Post a reply to this message

Attachments:
Download 'bubblephysics.png' (106 KB)

Preview of image 'bubblephysics.png'