 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
Here is a little pyramid I've made with the help of a macro from the
internet. It took about one day to parse and render.
I use an iteration 8 pyramid sponge 25 times to build another pyramid, which
I use 25 times to make another, and I do this once again resulting in 15,625
of those iteration 8 pyramids using my 3 loops.
The way I do it creates about 8 superfluous pyramids per loop (which were
uncounted in the 25 figure), so about 512 useless RAM sucking pyramids for
the whole thing (8 in loop1 8times in loop2 8times in loop3).
I'd like to get rid of them. Any help is appreciated.
Here is the untersheisse demo image and the source (therefore making this
inappropriate for P.B.S-F).
ian
Post a reply to this message
Attachments:
Download 'RecursivePyramid.pov.txt' (5 KB)
Download 'RecursivePyramid_it8_3rdloop.png' (216 KB)
Preview of image 'RecursivePyramid_it8_3rdloop.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Sep 2000 11:29:51 -0700, ian wrote:
>Hello,
>
>Here is a little pyramid I've made with the help of a macro from the
>internet. It took about one day to parse and render.
The download was also recursive, Oh now that I've checked it's just that
you've posted massive files. There was something wrong with the image
aswell, I can't view it.
--
Cheers
Steve email mailto:ste### [at] zeropps uklinuxnet
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
4:38pm up 8:17, 3 users, load average: 2.22, 2.11, 2.03
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I downloaded it, and it opened fine for me.
Its was a 215kb greyscale png and a 4kb pov file. Not exactly massive...
I don't know what happened, but if its my fault I apologize.
It all checked out here..
Thanks,
ian
>The download was also recursive, Oh now that I've checked it's just >that
you've posted massive files. There was something wrong with >the image as
well, I can't view it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Worked fine here. Png causes problems for some readers, though.
Grim
"ian" <ian### [at] aolcom> wrote in message news:39d37eac@news.povray.org...
> I downloaded it, and it opened fine for me.
> Its was a 215kb greyscale png and a 4kb pov file. Not exactly massive...
>
> I don't know what happened, but if its my fault I apologize.
>
> It all checked out here..
>
> Thanks,
> ian
>
> >The download was also recursive, Oh now that I've checked it's just >that
> you've posted massive files. There was something wrong with >the image as
> well, I can't view it.
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV-Ray includes a sample macro that deals with a similar issue.
Under Scenes\Macros\Pyramid and Pyramid2 are the files you're looking for. Part of the
trick is to include
a direction in the macro, so that it doesn't back track on itself.
Josh
ian wrote:
> Hello,
>
> Here is a little pyramid I've made with the help of a macro from the
> internet. It took about one day to parse and render.
>
> I use an iteration 8 pyramid sponge 25 times to build another pyramid, which
> I use 25 times to make another, and I do this once again resulting in 15,625
> of those iteration 8 pyramids using my 3 loops.
>
> The way I do it creates about 8 superfluous pyramids per loop (which were
> uncounted in the 25 figure), so about 512 useless RAM sucking pyramids for
> the whole thing (8 in loop1 8times in loop2 8times in loop3).
>
> I'd like to get rid of them. Any help is appreciated.
>
> Here is the untersheisse demo image and the source (therefore making this
> inappropriate for P.B.S-F).
>
> ian
>
> Name: RecursivePyramid.pov
> RecursivePyramid.pov Type: POV-Ray scene file
(application/x-unknown-content-type-POV-Ray.Scene)
> Encoding: x-uuencode
>
> Name: RecursivePyramid_it8_3rdloop.png
> RecursivePyramid_it8_3rdloop.png Type: PNG Image (image/x-png)
> Encoding: x-uuencode
--
Josh English -- Lexiphanic Lethomaniac
eng### [at] spiritonecom
The POV-Ray Cyclopedia http://www.spiritone.com/~english/cyclopedia/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ian wrote:
> Hello,
>
> Here is a little pyramid I've made with the help of a macro from the
> internet. It took about one day to parse and render.
>
> I use an iteration 8 pyramid sponge 25 times to build another pyramid, which
> I use 25 times to make another, and I do this once again resulting in 15,625
> of those iteration 8 pyramids using my 3 loops.
>
> The way I do it creates about 8 superfluous pyramids per loop (which were
> uncounted in the 25 figure), so about 512 useless RAM sucking pyramids for
> the whole thing (8 in loop1 8times in loop2 8times in loop3).
>
> I'd like to get rid of them. Any help is appreciated.
> ...
The idea of putting the two reflecting spheres inside
this fractal like pyramid is nice
I would love to have a closer look at the reflections
in them.
Then about your superfluous pyramids problem:
I think your macro is not the problem. (For me it
does not seem to generate unnecessary triangles.)
So therefore I think the problem must lie within the
rest of your code.
You could try to simplify the rest of your code.
(E.g. like I did with your macro in the code below).
Maybe it then will be easier for you to spot the "bug".
I think one error is that your loops are putting multiple
copies of the last assembled pyramid at some of the
locations they are translated to (And therefore I
suspect that the number of unnecessary pyramid
copies are far more than 512 !)
And last:
What does "untersheisse" mean. Is it german ?
Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Btw.:
It seems for me that most of the rest of your code
is "doing by hand" what your macro could do for you.
Wouldn't a call like this do roughly the same job as
most of your other lines does ?
#declare Corn =
mesh {
pyramid(SZ*4*y, SZ*4, 0, 8 + 2 + 2 + 2)
pigment { color 0.6*White }
finish { phong 0.2 }
translate 3*(SZ/2 + 5 + 1.25)*<1, 0, 1>
}
Here's my suggestion for the macro:
#macro pyramid(p0, size, rec, maxrec)
#local SS = size*<1, 1, 1>;
#local p1 = p0 - SS/<-2, 1, -2>;
#local p2 = p0 - SS/< 2, 1, -2>;
#local p3 = p0 - SS/< 2, 1, 2>;
#local p4 = p0 - SS/<-2, 1, 2>;
#if (rec >= maxrec)
triangle { p0, p1, p2 }
triangle { p0, p2, p3 }
triangle { p0, p3, p4 }
triangle { p0, p4, p1 }
triangle { p1, p2, p3 }
triangle { p3, p4, p1 }
#else
pyramid( p0 , size/2, rec + 1, maxrec)
pyramid((p0 + p1)/2, size/2, rec + 1, maxrec)
pyramid((p0 + p2)/2, size/2, rec + 1, maxrec)
pyramid((p0 + p3)/2, size/2, rec + 1, maxrec)
pyramid((p0 + p4)/2, size/2, rec + 1, maxrec)
#end // if
#end // macro pyramid
And here's my suggestion of how to start simplifying your
code (But only if you're interested :)
I'll use this line as an example:
translate <(-Y*(SZ/2))+(SZ*3),Y*SZ,(-Y*(SZ/2))+(SZ*3)>
First make it more friendly to the eye. Put in some spaces
after commas and around - and + to indicate that they are
"weaker" than * and /
translate <(-Y*(SZ/2)) + (SZ*3), Y*SZ, (-Y*(SZ/2)) + (SZ*3)>
Then remove all unnecessary parenthesis
(I.e. all in this case)
translate <-Y*SZ/2 + SZ*3, Y*SZ, -Y*SZ/2 + SZ*3>
Then find the common multiplier for each part in each
component of the vector and put this outside some
parenthesis:
translate <SZ*(-Y/2 + 3), SZ*Y, SZ*(-Y/2 +3)>
Now you see that each component of the vector also has SZ
as a common multiplier, so then you can put this outside
the vector and remove the parenthesis again:
translate SZ*<-Y/2 + 3, Y, -Y/2 +3>
Then maybe you see that the vector now can be
written as a sum of two vectors.
I.e.: <-Y/2 + 3, Y, -Y/2 +3> = <-Y/2, Y, -Y/2> + <3, 0, 3>
If so then you can write the statement like this:
translate SZ*(<-Y/2, Y, -Y/2> + <3, 0, 3>)
Again you can see that there is a common multiplier for
each component in the first vector and also for the last
vector. So put these multipliers outside the vectors.
Then we get:
translate SZ*(Y/2*<-1, 2, -1> + 3*<1, 0, 1>)
Then I would say that you're finished.
Or maybe you prefer this ?
translate SZ*(Y*<-0.5, 1.0, -0.5> + <3, 0, 3>)
Then compare the readability of that to the readability
of the statement as it was:
translate <(-Y*(SZ/2))+(SZ*3),Y*SZ,(-Y*(SZ/2))+(SZ*3)>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow, very comprehensive response! Thank-you!
Segmented response needed..
Tor Olav Kristensen wrote in message <39D3E3D5.52209309@hotmail.com>...
>The idea of putting the two reflecting spheres inside
>this fractal like pyramid is nice
>
>I would love to have a closer look at the reflections
>in them.
Much rendertime. :)
>Then about your superfluous pyramids problem:
>
>I think your macro is not the problem. (For me it
>does not seem to generate unnecessary triangles.)
>
>So therefore I think the problem must lie within the
>rest of your code.
The macro is from the internet as noted, and so isn't mine.
The fact that all problems lie in code generated by me is not at all
suprising, sadly enough. :)
>You could try to simplify the rest of your code.
I thought it was simplified?
>I think one error is that your loops are putting multiple
>copies of the last assembled pyramid at some of the
>locations they are translated to (And therefore I
>suspect that the number of unnecessary pyramid
>copies are far more than 512 !)
That is exactly where the problem is.
The problem that generated this problem, is the fact I could not find any
single translation to accomplish this, and could not adjust the others
properly. This probably has something to do with the fact that math isn't my
strongest ability (getting highly irritated at small, insignificant things,
on the other hand..).
>And last:
>What does "untersheisse" mean. Is it german ?
>
If you classify bad English translated into worse German as such, then, yes.
:)
If the impossible word was used incorrectly enough, it would be something
along the lines of 'sub-sh!t', or more literally 'under poop'. Depending on
usage, 'low pig' is also possible. :p
>It seems for me that most of the rest of your code
>is "doing by hand" what your macro could do for you.
I don't understand the macro enough to modify it.
>Wouldn't a call like this do roughly the same job as
>most of your other lines does ?
If it works, I'll accept that as affirmation.
>
>#declare Corn =
>mesh {
> pyramid(SZ*4*y, SZ*4, 0, 8 + 2 + 2 + 2)
> pigment { color 0.6*White }
> finish { phong 0.2 }
> translate 3*(SZ/2 + 5 + 1.25)*<1, 0, 1>
>}
Thats scary. How did you do this?
As far as the optimizations of the translations I used, they made perfect
sense to me, but in their simpler form are confusing.
I generated them visually, by manually placing objects and finding the
appropriate translations. I know what the stuff I typed does, and don't know
how the simplifications were reached.
If I told you I was bad at math, it would warrant a major slapping about the
face, as understatements of that nature should never be made.
I appreciate your modifications very much!
:)
ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If I told you I was bad at math, it would warrant a major slapping about
the
> face, as understatements of that nature should never be made.
Join the clan!
Mick
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry for not replying earlier.
ian wrote:
> ...8< ... Snip
> >You could try to simplify the rest of your code.
>
> I thought it was simplified?
:)
> ...
> >It seems for me that most of the rest of your code
> >is "doing by hand" what your macro could do for you.
>
> I don't understand the macro enough to modify it.
You don't have to understand how it works in order
to simplify it. (I did not see clearly what it was doing
before I had simplified it.)
If you apply some techniques (like those I did in my
last post) for reducing the complexity of the mathe-
matical expressions, and if you also modify the code
so that it does not calculate the same things over and
over, one usually ends up with code that is much
simpler to understand.
Selecting good (but not too long) names for variables
and macros also helps a lot. :( I'm not good at this )=
> >Wouldn't a call like this do roughly the same job as
> >most of your other lines does ?
>
> If it works, I'll accept that as affirmation.
>
> >
> >#declare Corn =
> >mesh {
> > pyramid(SZ*4*y, SZ*4, 0, 8 + 2 + 2 + 2)
> > pigment { color 0.6*White }
> > finish { phong 0.2 }
> > translate 3*(SZ/2 + 5 + 1.25)*<1, 0, 1>
> >}
>
> Thats scary. How did you do this?
Warning: Lengthy and boring explanation follows:
After having simplified the macro I had a closer look at
your image. It looked like the whole recursive pyramid
could be done with the macro.
But I did not understand what that other code after the
macro actually did, so I got curious and decided that I
had to find out.
I commented out most of your code after the macro,
except the "Co" section, which I started simplifying in
the same way. And after doing this for a while, I saw
that some of the math expressions looked very similar
to some intermediate expressions I had got while
simplifying the macro.
Then I had a look at your loops. While commenting out
all but one of the object {} expressions within the loop,
I played around with the start and stop values for the
counter variable.
And when I un-commented the other object {}
expressions, one by one, I saw how a pyramid was
built step by step. While doing this I also noted that
several of the smaller pyramids was put in the same
place. (I then concluded that these where the super-
fluous pyramids you mentioned.)
Your other two sections; "Cor" and "Corn" turned out
to be just variations over the same "theme".
I then decided to see if I could work out how to make
the same pyramid as yours by only one macro call.
Your "last" pyramid had a different height than the ones
that the macro had, so I had to work out the real height
of the final pyramid.
Since each of your code sections put 4 layers of
pyramids on top of each others, the the height of the
resulting pyramid for each section was multiplied by 4.
The height of the pyramid made by the macro was 2.5.
Therefore the distances between the "layers" in your
"Co" section also had to be 2.5.
Then these 4 layers adds up to 4*2.5 = 10
Therefore the distances between the "layers" in your
"Cor" section had to be 10.
Then these 4 layers adds up to 4*10 = 40
Therefore the distances between the "layers" in your
"Corn" section had to be 40. (SZ = 40)
Then these 4 layers adds up to 4*40 = 160
Therefore the height of the final pyramid had to be 160.
(4*SZ = 160)
When it came to finding the final horizontal position of
your pyramid, I was to tired to do more accurate math-
work.
I found some "unnecessary" numbers in the x and z co-
ordinates for some vectors in the different sections.
So I guessed that these added up to give the final
position of the pyramid. Since each of these numbers
was multiplied by the counting variable (which at maxi-
mum reaches 3) I thought I would multiply the sum of
these numbers by 3 in the translation statement.
Then I rendered the scene with this macro call only.
The position did not look bad so then stopped.
(But maybe my guessing was somewhat wrong here.)
Actually each section of your code ("Co", "Cor" and
"Corn") adds to what equals 2 recursion levels to the
final pyramid. (One recursion level would make 2
"layers" of pyramids out of a given pyramid. Then two
levels makes 2*2 = 4 "layers" of pyramids.)
The final macro call would then need 2 + 2 + 2 = 8
extra levels. These were added to the 8 your macro
call already had.
I did not have enough time, memory or patience to
test this out, so I only did some testing with levels of
3 to 6.
So you see that it's not scaring if you do some work
with the code =)
> As far as the optimizations of the translations I used,
> they made perfect sense to me, but in their simpler
> form are confusing.
You may try to visualize how the vectors (with their
multipliers removed) will translate the objects. I.e. in
what direction they will be moved. Added (or subtracted)
vectors means that you can visualize the translations in
several steps, where each step corresponds to a vector.
Then have a look at the multipliers outside the vectors to
see how many times more the object will be moved in the
direction of the vectors.
If the translations takes place inside a loop, and if the
counting variables (taking values 0, 1, 2 ...) are multiplied
by the translation vectors, then one can often of think of
this as putting several objects after each other with a
spacing equal to the length of the translation vector.
The number of objects equals the number of times the
loop is "run" (of course).
Look at the start and end values of the counting variable
to find the start and end positions of the "string" of
objects.
(If the counter starts at 0 then the first object will not be
moved at all in the direction of the vector that this
counter is multiplied by. This can often be a very useful
information.)
If you have read until this point, then hopefully my
scribbling has been informative.
Best regards
Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
