[simulation] volume & displacement
Steve Breslin
objects have a bulk or volume which corresponds with the container's
capacity.
This is normally very simplistic. For example,
a bag with a capacity of 6 can hold any one of the following:
6 stones (of bulk 1 each).
2 rocks (of bulk 3 each).
1 big rock (of bulk 6).
1 rock (of bulk 3) and 3 stones (of bulk 1 each).
This model requires that every object have a whole number for its
bulk.
This model assumes that the "space between objects" in the container
is never appreciable (or never >= 1 I guess).
Let's call this assumption "perfect packing". Perfect packing implies
that whatever fits, fits perfect, and there's no way of ever cramming
even a small thing in between a few big things.
Perhaps this only really becomes an issue with particularly small,
collective objects (like marbles down to sand) or powders and liquids.
Say I have filled a jug up with tennis balls, and I want to pour some
water into the jug. But the jug is quite technically full, from the
simulation-model's perspective, so there's no room for water between
the balls. Say that the bag is filled with 6 stones. Try putting a
spoonful of sand in the bag, or a few marbles, but they just won't fit
between the stones.
What interest, if any, should a general weights and measures module
have in the problem of perfect packing? Answers from 'module users'
are as welcome as those from 'module writers'.
One preliminary idea about handling this: have two volumes for each
non-tiny object, 1) 'solid displacement' or 'typical displacement' and
2) 'liquid displacement' or 'absolute displacement'. The former would
operate for objects being packed with other non-tiny objects, and the
latter would permit 'tiny' objects to find space in the container
between the other objects. So then a container could be fully packed,
but not so perfectly packed that there would be an unbelievable lack
of space between the objects.
That's just one idea. Any thoughts or preferences?
Jim Aikin
> One preliminary idea about handling this: have two volumes for each
> non-tiny object, 1) 'solid displacement' or 'typical displacement' and
> 2) 'liquid displacement' or 'absolute displacement'. The former would
> operate for objects being packed with other non-tiny objects, and the
> latter would permit 'tiny' objects to find space in the container
> between the other objects. So then a container could be fully packed,
> but not so perfectly packed that there would be an unbelievable lack
> of space between the objects.
--contains an assumption of its own, namely that there are only two types of
packing. Consider this:
> put bicycle in volkswagen
You cram the bicycle into the dented Volkswagen.
> put kayak in volkswagen
Sorry, the dented Volkswagen is full.
> put tennis ball in volkswagen
Sorry, the dented Volkswagen is full.
The second response makes perfect sense, but the third one makes very little
sense, even though it would be pretty much required by a model that only
provided for solid displacement and liquid displacement.
A more realistic (though more cumbersome) approach would be to give a solid
object such as a bicycle an "exterior irregularity" parameter. The container
would then be responsible for figuring out, via some algorithm, whether the
combination of contained objects and their exterior irregularities left any
room for additional objects.
If you were to begin by filling a barrel with water and then attempt to put
a bowling-ball into it, you'd need a different parameter, however, because
the exterior irregularity of water is zero. Water's flexibility is very
high, so you might be able to do something with that. Some objects, such as
tennis balls, have some compressibility with respect to packing. Others,
such as water, have very little compressibility, even though they have lots
of flexibility.
Then you get to the question of whether the object you drop into the
water-filled barrel can float. The amount of water displaced from the barrel
when you drop an object into it will depend not only on the object's
absolute volume but also on whether the object floats or sinks to the
bottom -- and if it floats, on how much lighter it is than water.
Have fun, if possible....
--JA
A.P. Hill
would use even integers for large items and odd for small, so that a
small can always be accommodated in a sack with a max bulk of 40. I
would total up all the bulk for my items in the game and deduct a max
bulk per container so that a few 1's can fit at all times. Making
large items bigger numbers would prevent it from fitting, and could
leave up to 5 bulk or so.
A.P. Hill
Steve Breslin
That's a better version of the preliminary idea I posed. I was also
thinking of making a 'square volume' and a 'real volume' for each
object. The real volume would be how much actual space the object
displaced, and the 'square volume' would be some advisory bulk, named
after an idea of how much area the object would take up if it were
packed squarely in a box. In any case, it sounds like two volume
properties is one inroad into this problem.
> If you were to begin by filling a barrel with water and then attempt to put
> a bowling-ball into it, you'd need a different parameter, however, because
> the exterior irregularity of water is zero. Water's flexibility is very
> high, so you might be able to do something with that. Some objects, such as
> tennis balls, have some compressibility with respect to packing. Others,
> such as water, have very little compressibility, even though they have lots
> of flexibility.
Well in the t3liquid library, which this question is coming out of,
there's already a good method for calculating overflow. We have
implemented buoyancy already, and will probably follow newtonian
physics for calculating area displaced by floating objects, based on
the relative density of the liquid and floating-object. This is more
or less what you're suggesting, as I understand:
> Then you get to the question of whether the object you drop into the
> water-filled barrel can float. The amount of water displaced from the barrel
> when you drop an object into it will depend not only on the object's
> absolute volume but also on whether the object floats or sinks to the
> bottom -- and if it floats, on how much lighter it is than water.
My first reaction to your wolkswagen/bicycle/kayak/ball example was
that this problem could easily be overcome with good game design.
(Make sure that all the objects in the game have good relative
volumes, so the ball will always fit where appropriate.) However, this
requires that the game designer considers all possible combinations of
objects for each container, and balances everything beautifully for
all possible combinations -- not a minor task. This seems akin to what
AP Hill suggests in this thread.
I may be trying to stretch the applicability of this question beyond
the eccentric needs of liquid simulation, but maybe with some thought
a broadly useful solution will present itself.
Michael
For Inform, the Recept.h library extention handles this pretty nicely.
It provides a size property as well as volume and weight properties.
Each container has associated limit properties for these attributes.
So, you can define something that can fit in a small space, but whose
total volume might be too big to be contained in that small space. I
use this extention along with Emily Short's WaterElement.h (with
slight modifications), and you get something very similar to what
you're trying to accomplish.
Michael