Chris Huff wrote:

> I agree...I think it would be an improvement to use {} blocks for while
> loops and other blocks. Or at least have different ending keywords:
> #endif, #endwhile, etc.
> And another thing, it is often difficult to tell if a piece of code is
> creating a variable or modifying it. I have proposed a #set directive
> that is incapable of creating a new variable but would be used to modify
> existing ones, but I seem to be the only person who thinks it is a good
> idea. :-(

We seem to be the only two who think it i a good idea.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

"David Fontaine" <dav### [at] faricynet> wrote in message
news:39A### [at] faricynet...
|
| Nope, all RMF. Perhaps I didn't use the correct setup. I like the overhang
| though, it serves as a natural shelter for the outpost. I agree the snow
is a
| little saturated, it's just hard to get it to look right on a monitor
because
| they're so dim compared to real blinding glare...

Interesting.  I hadn't seen the RMF get over-hangs without further external
influence.
I figured you were trying for the glare of sunlit snow and ice but the sky
didn't seem to fit.  That's difficult anyway, attempting to mimic a visual
appearance such as glare.  In actuality what you have done there would be
the way to do it though, somewhat darker surroundings.

Bob

Post a reply to this message

Bob Hughes wrote:

> Interesting.  I hadn't seen the RMF get over-hangs without further external
> influence.
> I figured you were trying for the glare of sunlit snow and ice but the sky
> didn't seem to fit.  That's difficult anyway, attempting to mimic a visual
> appearance such as glare.  In actuality what you have done there would be
> the way to do it though, somewhat darker surroundings.

Umm, there is no sky yet.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote in message <39AC778E.97FB4B89@faricy.net>...
>Chris Huff wrote:
>I have proposed a #set directive
>> that is incapable of creating a new variable but would be used to modify
>> existing ones, but I seem to be the only person who thinks it is a good
>> idea. :-(
>
>We seem to be the only two who think it i a good idea.


Better make that three.

Mark

Post a reply to this message

Mark Wagner wrote:
> Better make that three.
> 
	Well, four


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

<Jer### [at] enstfr> wrote:

> > > We seem to be the only two who think it i a good idea.
> > Better make that three.
> 	Well, four

Well, I guess I was wrong!
BTW, I think I just figured out how to implement it, just have to 
compile and test it...and another thing I noticed, MegaPOV has 
"shortcuts" for declaring, and one of them is the '%' character.(I knew 
about the shortcuts before, I just never payed attention to the specific 
characters)
I thought the '%' character was already used for a modulus operator...it 
seems like this could cause problems. Or maybe I am thinking of it's use 
in the isosurface patch...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

As far as I understand (I think I recall Nathan mentioning it somewhere) the
shortcuts for #declare and #local will not make it into the official POV-Ray
because of problems with other parts of the code.

Kev

Webpage/Pov Gallery:- http://web.libertysurf.co.uk/kevin.ellis

Post a reply to this message

Looks cool.

        I have an idea for an optimization of your lego dome
algorithm.  Have two 2-d arrays, one for the current level of
bricks in the dome, one for the layer above.  Build the dome from
the top down.  The arrays would be used to determine where the
1x1 bricks are going to be placed ... say "1" for a brick and
"0" for no brick.
        Now: for each "1" in the current array that has a "1"
in the array above it, change the "1" to a "0".  This would cause
unseeable 1x1 bricks to not be rendered.  This should save a
lot of memory at the expense of more parsing.

        Another different idea would be to have many long 1xN
bricks, which would go from the left side of the dome to the
right side of the dome.  Consider this ascci art diagram (top down
view of one "slice" of bricks from the dome), where
I represent every other brick with a different asci color,
"X" or "O"

        OOO
    XXXXXXXXXXX
  OOOOOOOOOOOOOOO
 XXXXXXXXXXXXXXXXX
 OOOOOOOOOOOOOOOOO
 XXXXXXXXXXXXXXXXX
  OOOOOOOOOOOOOOO
    XXXXXXXXXXX
        OOO


        That might be both faster in parseing
and memory efficient during render.  The difference in length
between a long brick and the one above it would determine the
placement of pips.


-- 
BTW, getting off topic now ... I rendered your neato
faceted twisted torus.  It is a parse monster!  It took a
half hour just to *parse* on my machine!  Wow!

Pete

Post a reply to this message

Pete wrote:

>         Another different idea would be to have many long 1xN
> bricks, which would go from the left side of the dome to the
> right side of the dome.

That is *exactly* what it does (alternating each layer)! You get the
prize!
Of course, there's no 1x5, 1x7, 1x34, etc, so I have an array for each
length saying what pieces to use,
#declare Beams = array[76][7]
{{1,0,0,0,0,0,0},{2,0,0,0,0,0,0}...{12,10,3,10,12,0,0}...}

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Chris Huff wrote:

> As has been mentioned, they would make great quartz crystals...are you
> going to post the source?

Sure, in a bit. If it's not in p.b.s-f in two days, nag me!

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message