Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BradB]

Voted.

Depth by darkening / misting / blurring
Pipes and plumbing
Sand Physics Modelling

[alfie275]

If Toady ever plans to use more than one core, fluids would be one of the things that would fit well, you could even have a core per fluid type.

[RobotDog]

Although this discussion sort of got sidetracked into "Liquid interactions" it's still the best idea for sand I've seen yet.

[robolee]

what about dug sand turning into loads of ramps instead of liquid physics, toady could just add a check each time a tile is dug out to see if any adjacent cells are sand, and distribute sand like this:


it's simple really, no constant check, if the map has sand set a boolean value to 1, if that value is one then every time a tile is dug out check adjacent squares , splurt out a ramp on the tile that was dug out, check tile to the top-left of the dug out cell, if sand turn tile into a ramp and create a ramp adjacent, continue clockwise creating ramps, move up one z level, if there's sand above and a sand ramp below, switch the tiles (full sand tile below, ramp on current z level), continue upwards until no more sand, if a sand ramp is removed, check if there are any full sand blocks adjacent as before, re-create the sand ramp if there was and turn them into ramps, basically the same as before.

[Quixote]

The problem I have with that, robolee, is that it makes sand not conserved. I think it needs to be done in 7ths or 3rds, and 7ths are already used for magma and water, so there's quite a bit of potential for code reuse. I'm not concerned about the proccessing; sand will remain stationary for the most part, except for certain pathological cases.

Who doesn't like the idea of slowly filling torture traps?

[keda]

First off I would like to say that this is an awesome idea. And second for all folks who think this is going to be cpu consuming, I would like to suggest that it wont, at least if done correctly.
All fluids as I have understood it constantly have to check around for squares to fill, potentially over large distances, and it is large masses of water and magma that cause noticable cpu consumption due to having to check so many squares.
Sand wont flow around usually, at least if there are no weather effects like wind implemented. It could be implemented however reasonably as well without much cpu consumption, similar to rain, except that every sand tile it hits sand is displaced 1/7 in the wind's direction, with an element of randomness, and also the likeliness of displacement depending on the slope.

My suggestion of the algorithm would work as follows:

When any tile x is mined, sand is collected from, or is dispaced by cave in do PULL(x):
If a sand tile x is walked on, if a random number is <p, then pick a random adjacent tile y, displace 1/7 sand on it and do PUSH(y), and PULL(x)

PULL(x):   if adjacent tile y, has sand(y) > 2+sand(x) on it set the coordinate x of the dug out tile on an event vector
PUSH(x):   if an adjacent tile y has sand(y)+2 < sand(x), add coordiante y to the event vector

Per frame do:
   For each coordinate x in the queue,
      for each adjacent tile y
         if sand(y) > sand(x)+2, displace sand(y)-(sand(x)+2) onto x from y and do PULL(y)
      if any sand has been displaced do PUSH(x), otherwise remove the event (move the last coordinate into the gap)

the vector could be reallocated 1000 coordinates at a time to speed things up
While no sand is moving it should not consume almost any cpu cycles, and when sand moving is needed, it will be very localized (unless you are digging out a huge inverted pyramid) and thus should consume a minimal amount of cpu cycles.

[Draco18s]

First off I would like to say that this is an awesome idea. And second for all folks who think this is going to be cpu consuming, I would like to suggest that it wont, at least if done correctly.

Almost none of the criticism is that it would be CPU expensive.  The criticism is that we need to overhaul the fluid system as a whole to be able to support an arbitrary number of fluids.  We can add sand pretty easily, but adding the 30th liquid would be very complex and time consuming in order to deal with the interactions between that fluid and the previous 29.

[keda]

Well, I was not thinking of an arbitrary number of fluids, I guess you have a point there if that would have to be moddable, it would be very complicated, but if we keep to sand, magma, and water, I don't see much problem there. Magma melts or turn sand into glass, while water occupies the remaining space in the sand square. If water would be able to seep through sand, that would be more complicated though. Nothing a decent programmer couldn't handle though. I would think the CPU criticism is much more problematic, if it was true. But yeah if you want modding fluids that might be a lot of work.

[Draco18s]

Not necessarily modded fluids, but a way for Toady to implement them more easily.  Sort of like civs: how each civ interacts with another civ is due to its properties.

[Quixote]

What you are saying draco, is that the fluid system needs to be generalized?

I agree. Maybe that should be in the ESV, instead of Sand, or in addition to it. Who controls the sand entry? I, for one, like the idea. It would allow things like oil to be added, which would be awesome.

[keda]

It just occurred to me the current fluid system needs an overhaul anyway, and could be much less CPU intensive. All the 6's that dance around in the 7's for instance. Fluid would only have to move if theres 2 levels of difference, and it could be designed to treat fluids as bodies with borders to optimize fluid displacement.

[robolee]

The problem I have with that, robolee, is that it makes sand not conserved. I think it needs to be done in 7ths or 3rds, and 7ths are already used for magma and water, so there's quite a bit of potential for code reuse. I'm not concerned about the proccessing; sand will remain stationary for the most part, except for certain pathological cases.

Who doesn't like the idea of slowly filling torture traps?

how is sand not conserved? instead of showing it as x/7 it's a ramp, it's like the OP except you'd be able to climb up banks of sand that are less than 7/7, after all you'd have to remove a portion of the sand to make a ramp, basically imagine in that image that the 3 ramps that used to be full sand blocks are now 6/7 sand and the new ramp is 3/7, in the stairs image the sand fills the topmost stairs block and partially fills the one below because I assumed that above that would be 9 sand tiles, so each of them would be 6/7 sand and the remaining sand would be 9/7, one full regular sand tile (7/7) blocks the topmost staircase and one ramp (2/7) partially blocks the one underneath it, and that is roughly how sand works it would block itself of so no more sand could flow (because unlike an hourglass stairs have flat surfaces for the sand to pile up on and block the flow), the other method of it behaving as a liquid would have it flow all the way down the stairs. The only problem with the method is that you need to have some kind of *sand blocked stairs* and *partially sand blocked stairs*. Of course there would need to be a check to see if it's filling downwards or laterally, it should only fill a full sand block downwards and only distribute 4/7 ramps laterally (otherwise it would look weird).

half written pseudo code (lee cancels write pseudo code, too hot, can't think):

Spoiler (click to show/hide)

(run when a tile is removed)
bool movedown;
if (tile removed==staircase){z+=1;movedown=1;}//assumes the only way to dig underneath a sand tile is by digging an up & a down staircase
store current floor;
count_surrounding_sand_tiles();// start from center then top left and scan clockwise, turning the sand blocks into ramps(set ramp "flow" value to 6/7), storing the tile locations in a 3*3 array
//distribute sand
if (movedown==1){
    if tilecount<7{
      z+=1; int oldtilecount=tilecount;
      if {count_surrounding_tiles()+oldtilecount>oldtilecount)//take one more from
       
      }
      z-=1;
    }
    z-=1;
    if tilecount>7{
      tile_attach_flag=staircase_sand_blocked;tile_flow_amount=7;
      tilecount-=7;
    }
    else{
      tile_attach_flag=staircase_sand_partial_blocked;
      tile_flow_amount=tilecount;
      tilecount=0;
    }
}
while (surrounding_tile_count!=0){
    loop_movedown();//move down until first floor is encountered,do nothing if tile already has a floor
    fill surrounding tiles();//place ramp, decrease tile count by full amount or 4 if tilecount >4, move to next adjacent tile in the 3*3 grid that has a floor
}

[Quixote]

So, if I read you correctly, you are recommending that sand have the 7/7 fluid deal as the underlying mechanic, but display it as ramps?  I guess I could get behind that. Kind of like Magma and Water being init toggleable to show up as ~ instead of 7. Of course it should be an init option, and displaying as ramps could make it easier to understand for some ppl.

[marcusbjol]

Not easy.

Liquids are currently implemented as an additional item in the spot and there is only 1 liquid per tile.  One could look into all the ways around it, but there is this simple fact:

Sand is not a liquid.

In a game mechanics sense, sand does not level out like other liquids.  Given time, water settle so the surface is flat.  Sand I think will remain with a 42 degree slope indefinitely.

So given how complex this problem (memory requirment for liquid management goes up 2-3x, computationally intensive) is compaired to the benifits to the end user (nifty, that is all), this probably should wait until proper fluid (air is a fluid) mechanics to be implemented.

[Quixote]

You want to simulate air now?

Sand is not a liquid, but clean, dry sand does have behaviors similar to liquids. The idea is to use a slightly modified version of the algorithm currently used for magma to model this behavior.

Where do you get 42 degrees? As an engineer, I'd imagine that the angle of repose is dependent on grain size, grain-grain adhesion, contamination and grain geometry, just to name a few things. Geology isn't my area of specialty, but I would find it hard to believe that all sand behaves in the same way.  Of course, for our purposes, it's good enough to model it all as the same.

Why do you and others keep saying that sand modeled as a fluid will be computationally expensive? Why do you say that this is a complex problem? The most difficult part will be cleaning up the fluid code, making it extensible. The rest is simple.