|
 |
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] hotmail com
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
|
