"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> I don't know if there is a special case in which a loop of  the variable
> "FooCounter" should remain unchanged.
> But what about a simple detector where the value of "FooCounter" from the
> #while(FooCounter cond) condition does not change when you reach the end of
> the loop?.
>
> If this is an "insurmountable" logical hole guess we will have to settle for
> what is, but thanks anyway for your reply.
>
> B. Gimeno

Actually, I just wrote some code that has that.  The loop counter is
conditionally incremented, and the condition isn't known until after it is
evaluated.  I cut out some earlier code that wasn't relevant (mostly file
writing stuff).

#local i = 0;
#local seaweedCount = 10000;

#while( i < seaweedCount )
    #local xcord = xdist * rand(rs1) + bounds1.x;
    #local zcord = zdist * rand(rs1) + bounds1.z;

    #local normVect = <0,0,0>;
    #local intersectVect = trace(o_rocks,<xcord,10,zcord>, <0.5,-1,1>,
normVect);

    #if( intersectVect.y < waterLevel + 0.5 )
        sphere
        {
            intersectVect, 0.05
            texture{ marker1s }
        }
        #local i = i + 1;

    #end
#end

Basically it selects a random point within the bounds of a heightfield, then
uses trace to find the exact point on the heightfield.  It then checks to make
sure the point is close to the water level.  If the point isn't slightly above
the water level or lower, the counter is not incremented.  In this way I get
seaweedCount (10000) objects where I need them, and not 10000 total attempts to
place an object, whether it is successful or not.

It is quite possible to place a secondary condition so that it "bails out" after
some very high number of tries, but only the individual user can decide for a
given instance of where and what that condition should be.

-Reactor

Post a reply to this message