 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
BTW if you have any suggestions on composition go ahead.
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"David Fontaine" <dav### [at] faricy net> wrote in message
news:39AB4AD3.65F7CCB0@faricy.net...
| BTW if you have any suggestions on composition go ahead.
Not a suggestion, a question. Such as how are you going to get that station
to sit on such a slope? Going to be partially built in?
The white seems a little on the over saturated side, maybe toning it down
some would be better. Looks like you used noise3d on that ridged
multifractal for the overhangs there. I tried some that way but it takes a
while to get them to where no parts are suspended in mid air.
Bob
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
I like the first one, looks a bit like one of those ancient paintings of arctic
expeditions.
The crystals seem a bit too transparent to me, but maybe they just suffer from
the lack of a background to reflect. They don't look like ice crystals so they
probably won't fit in the landscape.
In the third one i do not realize the difficulty (the stats seem quite extreme
though) but maybe i just don't see enough details in the pict.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
David Fontaine <dav### [at] faricy net> wrote in message
news:39AB40DA.7FB92E68@faricy.net...
>
> Second image is some test rendering of the crystal macro I made, though
> I don't know if they'll fit in the RMF landscape. Still good for other
> stuff though.
Crystals look very nice. Can you change the texture/interior?
They'd be nice for amythest crystals, the ones sometimes found in the
center of rocks.
Gail
--
********************************************************************
* gsh### [at] monotix co za * System.dat not found. *
* http://www.rucus.ru.ac.za/~gail/ * Reformat hard drive Y)es O)k *
********************************************************************
* If at first you don't succeed, call it version 1.0 *
********************************************************************
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Now this is what I'd expenct an ice planet to look like.
The render time isn't bad, but I don't like disk thrashing.
--
Cheers
Steve email mailto:ste### [at] zeropps uklinux net
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
11:50am up 7 days, 16:08, 2 users, load average: 1.02, 1.03, 1.00
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Bob Hughes wrote:
> Not a suggestion, a question. Such as how are you going to get that station
> to sit on such a slope? Going to be partially built in?
Yes! That green post should also be out a little farther than it is, but that's
just a mental note, no need to make a whole nother render.
> The white seems a little on the over saturated side, maybe toning it down
> some would be better. Looks like you used noise3d on that ridged
> multifractal for the overhangs there. I tried some that way but it takes a
> while to get them to where no parts are suspended in mid air.
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...
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Steve wrote:
> Now this is what I'd expenct an ice planet to look like.
Thankies!
> The render time isn't bad, but I don't like disk thrashing.
Well, the render time for the outpost is more than the crystal, landscape
and vehicle put together (though it was at a higher resolution). I can
possibly make it a little smaller in mem, but not much. :-(
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Gail Shaw wrote:
> Crystals look very nice.
Thanks!
> Can you change the texture/interior?
But of course.
> They'd be nice for amythest crystals, the ones sometimes found in the
> center of rocks.
Methinks so too.
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christoph Hormann wrote:
> I like the first one, looks a bit like one of those ancient paintings of arctic
> expeditions.
Thanks!
> The crystals seem a bit too transparent to me, but maybe they just suffer from
> the lack of a background to reflect. They don't look like ice crystals so they
> probably won't fit in the landscape.
Oops, forgot reflection! The crystals I was just toying around with, they need a
little work.
> In the third one i do not realize the difficulty (the stats seem quite extreme
> though) but maybe i just don't see enough details in the pict.
It's fairly simple in theory: for each layer of bricks, make a grid, and specify
each element as outside, part of a cylinder, or part of a hemisphere. Next, go and
take out any "nubs" (cylinder elements that only have one adjacent cylinder
element). Then go laying bricks around the outside of the cylinder portions. Then
fill in the domes (the domes are solid :-( ).
Personally, though, I find POV-Ray's language hard to read. I am used to C; you
always know where a line ends with a semicolon, no manually incrementing loops,
'{}' indicates blocks rather than objects.
POV, on the other hand, is very dense visually; characters like '#', long keywords,
etc. Loops and other control aids are virtually indistinguishable without actually
reading the code, because in order to change a variable you need #local or
#declare, which has the same first character and is the same color as #while and
#end.
Of course, that's no excuse for '<' versus '<=' or indexing from one... ;-)
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
In article <39AC1FDE.21DBD949@faricy.net>, David Fontaine
<dav### [at] faricy net> wrote:
> Oops, forgot reflection! The crystals I was just toying around with,
> they need a little work.
As has been mentioned, they would make great quartz crystals...are you
going to post the source?
For ice, maybe thinner, more needle-like crystals would help.
> Then fill in the domes (the domes are solid :-( ).
Completely solid? Ouch...maybe you should leave out parts in the center.
It would parse a bit longer, but would use less memory.
> Personally, though, I find POV-Ray's language hard to read. I am used
> to C; you always know where a line ends with a semicolon, no manually
> incrementing loops, '{}' indicates blocks rather than objects. POV,
> on the other hand, is very dense visually; characters like '#', long
> keywords, etc. Loops and other control aids are virtually
> indistinguishable without actually reading the code, because in order
> to change a variable you need #local or #declare, which has the same
> first character and is the same color as #while and #end.
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. :-(
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
David Fontaine wrote:
> ...
> Third image is the research station. There is a door, although not
> visible, and antennas and stuff will go on top later. I wrote piles of
> code to automatically generate the domes, and since they are entirely
> made out of 1xn plates, it takes a loooong time to parse and a *lot* of
> memory. (83 layers of plates...)
I like the largest and the smallest of the domes.
Have you tried to let the height of the poles (plates ?)
be slightly random ?
Tor Olav
--
mailto:tor### [at] hotmail com
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"David Fontaine" <dav### [at] faricy net> wrote in message
news:39A### [at] faricy net...
|
| 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] faricy net> 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
Jérôme
--
******************************* Jérôme M. BERGER
* Doctor Jekyll had something * mailto:ber### [at] iname com
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
In article <39ACC640.F8F9E738@enst.fr>, Jérôme Berger
<Jer### [at] enst fr> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, 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] faricy net> 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] faricy net> ICQ 55354965
Please visit my website: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |