 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greetings Math Wizards !
Below are two versions of pov script both currently producing exactly
the same object, a semi-hemisphere or half dome if you wish. The first
is out of a scene I have been working on and it suited my needs for the
one scene. After establishing a a procedure I thought it would be nice
if I could parameterize the script so it is self adjusting. By this I
mean I would like to be able to provide the 3 dimensions of a box and
the desired radius for the dome and the script takes care of the rest
as far as number of objects, rotation angles, etc. It would also be nice
to have a choice between half dome, half sphere, and full sphere versions
but I am not going to push my luck at this point.
Anyway I started working on the improved version and got so tangled up
I stopped and said enough. I'm at the stage where if someone will help
finish it I would appreciate it greatly. I just can't seem to get everything
working together in unison for the desired output. I have commented the
major operating points of the script and it shouldn't be too difficult
to follow. The feeble attempts I made at getting it to work have been
eliminated so as not to confuse the issue. Only the identifiers have been
left in place as a guide. I can see a definite candidate for a macro here
but would rather the help you provide stays within the current format.
I need to learn how to convert stuff like this to macros myself and this
will be my first case study.
Thanks !
P.S. If you indent the script I won't cry too much ;^ {
camera{location<0,20,-65>look_at 20*y}
light_source{< 0,500,-900>rgb 1}
light_source{< 0, 5,-100>rgb 1}
// original working code
#declare HalfDome_1 =
union {
#declare aa = 0;
#while (aa < 90)
#declare bb = 0;
#while (bb < 45)
box{-.5,.5
scale <.05, 1.50, 1.50> // Box scale
translate <-40, 0.00, 0> // Translate from origin
rotate <0.0, 0.00,-2*bb> // rotate for first verticle section of dome
scale <1.0, 1.00,1.6+pi/90*-bb> // Scale each box smaller as it goes up
rotate <0.0, 2*aa, 0.00> // rotate scaled section horizontily to form
dome
translate <0.0, 0.75, 0.00> } // Translate bottom edge to y*0
#declare bb = bb+1;
#end
#declare aa = aa+1;
#end }
// New code that works but needs help - lots of
#declare HalfDome_2 =
union {
#declare Xscale = 0.05; // Box scale
#declare Yscale = 1.50; // Box scale
#declare Zscale = 1.50; // Box scale
#declare Rad = 40.0; // Dome radius
#declare Trnslt = <-Rad, 0, 0>; // Translate from origin
#declare HSegNum = 180/2; // Number of horizontal segments
#declare VSegNum = HSegNum/2; // Number of verticle segments
#declare aa = 0;
#while (aa < HSegNum)
#declare bb = 0;
#while (bb < VSegNum)
#declare Rotate1 = <0,0,-2*bb>; // rotate value for one verticle section of dome
#declare RotScale = <1,1,Yscale+.1+pi/HSegNum*-bb>; // Rotation scaler
#declare Rotate2 = <0,2*aa, 0>; // rotate values horizontal sections of dome
box{-.5,.5
scale <Xscale,Yscale,Zscale> // Scale of Box
translate Trnslt // Translate from origin
rotate Rotate1 // rotate to create first verticle slice of dome
scale RotScale // Scale each box smaller as it goes up
rotate Rotate2 // Rotate scaled verticle section to create dome
translate <0,Yscale*.5,0>} // Translate bottom edge to y*0
#declare bb = bb+1;
#end
#declare aa = aa+1;
#end }
#declare Tex = texture{pigment{rgb 1} finish{ambient .4 diffuse .2}}
object{HalfDome_1 rotate 180*y texture{Tex}}
//object{HalfDome_2 rotate 0*y texture{Tex}}
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay Ken... you have a couple of magic numbers in here (a magic number
is a number that is just there for some reason and no logical
explaination is known except by the author) The most important one is
1.6*pi/90-bb where did you get this figure? I am trying to figure it
out, and my guess is that you just kept tweaking it until there weren't
any gaps...Also, where did you come up with the origial scale for the
box?
Steve
Ken wrote:
>
> Greetings Math Wizards !
>
> Below are two versions of pov script both currently producing exactly
> the same object, a semi-hemisphere or half dome if you wish. The first
> is out of a scene I have been working on and it suited my needs for the
> one scene. After establishing a a procedure I thought it would be nice
> if I could parameterize the script so it is self adjusting. By this I
> mean I would like to be able to provide the 3 dimensions of a box and
> the desired radius for the dome and the script takes care of the rest
> as far as number of objects, rotation angles, etc. It would also be nice
> to have a choice between half dome, half sphere, and full sphere versions
> but I am not going to push my luck at this point.
> Anyway I started working on the improved version and got so tangled up
> I stopped and said enough. I'm at the stage where if someone will help
> finish it I would appreciate it greatly. I just can't seem to get everything
> working together in unison for the desired output. I have commented the
> major operating points of the script and it shouldn't be too difficult
> to follow. The feeble attempts I made at getting it to work have been
> eliminated so as not to confuse the issue. Only the identifiers have been
> left in place as a guide. I can see a definite candidate for a macro here
> but would rather the help you provide stays within the current format.
> I need to learn how to convert stuff like this to macros myself and this
> will be my first case study.
>
> Thanks !
>
> P.S. If you indent the script I won't cry too much ;^ {
>
> camera{location<0,20,-65>look_at 20*y}
>
> light_source{< 0,500,-900>rgb 1}
> light_source{< 0, 5,-100>rgb 1}
>
> // original working code
>
> #declare HalfDome_1 =
> union {
> #declare aa = 0;
> #while (aa < 90)
> #declare bb = 0;
> #while (bb < 45)
>
> box{-.5,.5
> scale <.05, 1.50, 1.50> // Box scale
> translate <-40, 0.00, 0> // Translate from origin
> rotate <0.0, 0.00,-2*bb> // rotate for first verticle section of dome
> scale <1.0, 1.00,1.6+pi/90*-bb> // Scale each box smaller as it goes up
> rotate <0.0, 2*aa, 0.00> // rotate scaled section horizontily to form
dome
> translate <0.0, 0.75, 0.00> } // Translate bottom edge to y*0
>
> #declare bb = bb+1;
> #end
> #declare aa = aa+1;
> #end }
>
> // New code that works but needs help - lots of
>
> #declare HalfDome_2 =
> union {
> #declare Xscale = 0.05; // Box scale
> #declare Yscale = 1.50; // Box scale
> #declare Zscale = 1.50; // Box scale
> #declare Rad = 40.0; // Dome radius
> #declare Trnslt = <-Rad, 0, 0>; // Translate from origin
> #declare HSegNum = 180/2; // Number of horizontal segments
> #declare VSegNum = HSegNum/2; // Number of verticle segments
> #declare aa = 0;
> #while (aa < HSegNum)
> #declare bb = 0;
> #while (bb < VSegNum)
> #declare Rotate1 = <0,0,-2*bb>; // rotate value for one verticle section of
dome
> #declare RotScale = <1,1,Yscale+.1+pi/HSegNum*-bb>; // Rotation scaler
> #declare Rotate2 = <0,2*aa, 0>; // rotate values horizontal sections of dome
>
> box{-.5,.5
> scale <Xscale,Yscale,Zscale> // Scale of Box
> translate Trnslt // Translate from origin
> rotate Rotate1 // rotate to create first verticle slice of dome
> scale RotScale // Scale each box smaller as it goes up
> rotate Rotate2 // Rotate scaled verticle section to create dome
> translate <0,Yscale*.5,0>} // Translate bottom edge to y*0
>
> #declare bb = bb+1;
> #end
> #declare aa = aa+1;
> #end }
>
> #declare Tex = texture{pigment{rgb 1} finish{ambient .4 diffuse .2}}
>
> object{HalfDome_1 rotate 180*y texture{Tex}}
>
> //object{HalfDome_2 rotate 0*y texture{Tex}}
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Lavedas wrote:
>
> Okay Ken... you have a couple of magic numbers in here (a magic number
> is a number that is just there for some reason and no logical
> explaination is known except by the author) The most important one is
> 1.6*pi/90-bb where did you get this figure? I am trying to figure it
> out, and my guess is that you just kept tweaking it until there weren't
> any gaps...Also, where did you come up with the origial scale for the
> box?
>
> Steve
>
Don't you just love magic numbers :)
The 1.6*pi/90-bb was arrived at by a certain amount of tweaking but you
would be surprised at how quickly I found it. The 1.6 is the box's Yscale
demension +.1 (Why ? because .1 worked better than just 1.5 that's why).
I can't remember why "pi" worked so well here but it does. The 90 part of
the equation comes from the number of degrees the box must travel to form
the section that will later be rotated 180 degrees to form the half dome.
The -bb is the regressive scaling factor. Simple no ? This function is
necessary to scale each box in sucsession smaller than it predessesor.
Without it you have a terrible mess at the top of the dome. It seemed like
a logical approach at the time and there is no doubting that it works.
The original scaling for the box was arrived ar to match the opening of
an archway with those demensions and the half dome had to conform to scene
elements that were already fixed and unchangable. As I mentioned I would like
(you) to set up the math in the script so that the box defines the rest of the
parameters. Changing the scale of the box for development purposes won't hurt
a thing.
Thanks for the continued support.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ahh...okay, so the size of the box determines all else..I will work on
this.. oh, and did you ever think that perhaps the reason you are
getting lost is because you don't indent and therefore have to spend all
of your time thinking about where you are in the program?
Steve
Ken wrote:
>
> Stephen Lavedas wrote:
> >
> > Okay Ken... you have a couple of magic numbers in here (a magic number
> > is a number that is just there for some reason and no logical
> > explaination is known except by the author) The most important one is
> > 1.6*pi/90-bb where did you get this figure? I am trying to figure it
> > out, and my guess is that you just kept tweaking it until there weren't
> > any gaps...Also, where did you come up with the origial scale for the
> > box?
> >
> > Steve
> >
>
> Don't you just love magic numbers :)
>
> The 1.6*pi/90-bb was arrived at by a certain amount of tweaking but you
> would be surprised at how quickly I found it. The 1.6 is the box's Yscale
> demension +.1 (Why ? because .1 worked better than just 1.5 that's why).
> I can't remember why "pi" worked so well here but it does. The 90 part of
> the equation comes from the number of degrees the box must travel to form
> the section that will later be rotated 180 degrees to form the half dome.
> The -bb is the regressive scaling factor. Simple no ? This function is
> necessary to scale each box in sucsession smaller than it predessesor.
> Without it you have a terrible mess at the top of the dome. It seemed like
> a logical approach at the time and there is no doubting that it works.
>
> The original scaling for the box was arrived ar to match the opening of
> an archway with those demensions and the half dome had to conform to scene
> elements that were already fixed and unchangable. As I mentioned I would like
> (you) to set up the math in the script so that the box defines the rest of the
> parameters. Changing the scale of the box for development purposes won't hurt
> a thing.
>
> Thanks for the continued support.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Lavedas wrote:
>
> Ahh...okay, so the size of the box determines all else..I will work on
> this.. oh, and did you ever think that perhaps the reason you are
> getting lost is because you don't indent and therefore have to spend all
> of your time thinking about where you are in the program?
>
> Steve
I once gave serious consideration to indenting my scene files and
it lasted for at least 5 minutes. I then dismissed it as a complete
waste of time and resources. Below you will see how my scene files
are usualy written. The source I posted to night was layed out straight
for the bennefit of those who just can't stand it any other way. A full
screen of pov script reduced to 3 lines. Neat isn't it ?
#declare HalfDome_1=union{#declare aa=0;#while(aa<90)#declare bb=0;#while(bb<45)
box{-.5,.5 scale<.05,1.5,1.5>translate z*-40 rotate z*-2*bb scale<1,1,1.6+pi/90*-bb>
rotate y*2*aa translate y*.75}#declare bb=bb+1;#end#declare aa=aa+1;#end}
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
To quote Kryten from Red Dwarf "OH MY GOD!! It's HIDEOUS!!!" No wonder
you can't do your work... of course you realize that there are no
appreciable HD savings in this version since the minimum sector size is
4k and so any file less than 4K in size takes up 4K anyhow... In larger
scenes, there will be some, but really, the ease of reading is SOO much
improved with indentation that I don't doubt you have problems getting
lost in your code...Take a look at my indented version. (comments
removed to kill wrap errors)
#declare HalfDome_1 =
union {
#declare aa = 0;
#while (aa < 90)
#declare bb = 0;
#while (bb < 45)
box{
-.5,.5
scale <.05, 1.50, 1.50>
translate <-40, 0.00, 0>
rotate <0.0, 0.00,-2*bb>
scale <1.0, 1.00,1.45+pi/90*(-bb)>
rotate <0.0, 2*aa, 0.00>
translate <0.0, 0.75, 0.00>
}
#declare bb = bb+1;
#end
#declare aa = aa+1;
#end
}
Sure it takes more lines, but I can easily see where loops begin and
end, and which block my commands belong to (you'll rarely see a missing
} in my code) adding new lines is easy and removing things without
causing problems is easy as well because I can see what I am affecting.
Steve
Ever on the crusade for indentation.
Ken wrote:
>
> Stephen Lavedas wrote:
> >
> > Ahh...okay, so the size of the box determines all else..I will work on
> > this.. oh, and did you ever think that perhaps the reason you are
> > getting lost is because you don't indent and therefore have to spend all
> > of your time thinking about where you are in the program?
> >
> > Steve
>
> I once gave serious consideration to indenting my scene files and
> it lasted for at least 5 minutes. I then dismissed it as a complete
> waste of time and resources. Below you will see how my scene files
> are usualy written. The source I posted to night was layed out straight
> for the bennefit of those who just can't stand it any other way. A full
> screen of pov script reduced to 3 lines. Neat isn't it ?
>
> #declare HalfDome_1=union{#declare aa=0;#while(aa<90)#declare bb=0;#while(bb<45)
> box{-.5,.5 scale<.05,1.5,1.5>translate z*-40 rotate z*-2*bb
scale<1,1,1.6+pi/90*-bb>
> rotate y*2*aa translate y*.75}#declare bb=bb+1;#end#declare aa=aa+1;#end}
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm the kind of person that doesn't bother with any fancy formatting for
the sake of saving typing, but that is awful!
Hell, the quote of it that netscape made is easier to read! ;)
-Mike
Ken wrote:
> I once gave serious consideration to indenting my scene files and
> it lasted for at least 5 minutes. I then dismissed it as a complete
> waste of time and resources. Below you will see how my scene files
> are usualy written. The source I posted to night was layed out straight
> for the bennefit of those who just can't stand it any other way. A full
> screen of pov script reduced to 3 lines. Neat isn't it ?
>
> #declare HalfDome_1=union{#declare aa=0;#while(aa<90)#declare bb=0;#while(bb<45)
> box{-.5,.5 scale<.05,1.5,1.5>translate z*-40 rotate z*-2*bb
scale<1,1,1.6+pi/90*-bb>
> rotate y*2*aa translate y*.75}#declare bb=bb+1;#end#declare aa=aa+1;#end}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <36C### [at] pacbell net>...
> #declare HalfDome_1=union{#declare aa=0;#while(aa<90)#declare
bb=0;#while(bb<45)
> box{-.5,.5 scale<.05,1.5,1.5>translate z*-40 rotate z*-2*bb
scale<1,1,1.6+pi/90*-bb>
> rotate y*2*aa translate y*.75}#declare bb=bb+1;#end#declare aa=aa+1;#end}
That reminds me of the BASIC I used to write when I was a kid.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Lavedas wrote in message <36C### [at] virginiaedu>...
> of course you realize that there are no
>appreciable HD savings in this version since the minimum sector size is
>4k and so any file less than 4K in size takes up 4K anyhow...
Maybe on =your= disk.
In NTFS, the MFT record which stores the demographics of the file can store
the contents too, if it is short. So there is =no= space allocated for the
file besides the MFT record which holds the name(s), size, permissions,
dates, etc. On some UNIX file systems, data of a few hundred bytes can be
stuffed in the iNode, which is the same principle.
So on NTFS, all files take exactly 1K for the MFT (master file table)
record, plus consume a couple bytes in an index (how the directories are
kept). If the content is a few hundred bytes, it will go in the MFT too and
the file only takes 1K.
After that, it allocates clusters, where the cluster size is fully
configurable at format time. I use fairly small clusters to prevent just
this kind of waste. Microsoft's documentation claims, in all its wisdom,
that a smaller cluster size will increase fragmentation. But on a fast SCSI
drive it's never been a problem, and I can always defragment if needed.
Anyway, a data drive could easily have clusters of 1K or 2K, not the
wasteful 4K. One could even use half a K per cluster.
--John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is the first I've realized what all the huff was about, this
"indentation", or lack thereof.
Egad, I am also appalled. I can't stand not to move incrementally right
as I move through a definition, although I do tend to start back
leftward if it makes it look better. Aesthetics can be under-rated. I go
for grace.
Oops, now I'm making myself sick...
Your right about the example, compact. But if anything, for POVs sake
use separate lines at least!
//END of rant 'n' rave.
Ken wrote:
>
> I once gave serious consideration to indenting my scene files and
> it lasted for at least 5 minutes. I then dismissed it as a complete
> waste of time and resources. Below you will see how my scene files
> are usualy written. The source I posted to night was layed out straight
> for the bennefit of those who just can't stand it any other way. A full
> screen of pov script reduced to 3 lines. Neat isn't it ?
>
> #declare HalfDome_1=union{#declare aa=0;#while(aa<90)#declare bb=0;#while(bb<45)
> box{-.5,.5 scale<.05,1.5,1.5>translate z*-40 rotate z*-2*bb
scale<1,1,1.6+pi/90*-bb>
> rotate y*2*aa translate y*.75}#declare bb=bb+1;#end#declare aa=aa+1;#end}
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.htm
mailto:inv### [at] aolcom?PoV
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You are of course right, but knowing that Mr. Tyler is using a Wintel
machine, I was just talking to him specifically, though I should have
said that in the email...Sorry for being Wintel myopic.
Steve
"John M. Dlugosz" wrote:
>
> Stephen Lavedas wrote in message <36C### [at] virginiaedu>...
> > of course you realize that there are no
> >appreciable HD savings in this version since the minimum sector size is
> >4k and so any file less than 4K in size takes up 4K anyhow...
>
> Maybe on =your= disk.
>
> In NTFS, the MFT record which stores the demographics of the file can store
> the contents too, if it is short. So there is =no= space allocated for the
> file besides the MFT record which holds the name(s), size, permissions,
> dates, etc. On some UNIX file systems, data of a few hundred bytes can be
> stuffed in the iNode, which is the same principle.
>
> So on NTFS, all files take exactly 1K for the MFT (master file table)
> record, plus consume a couple bytes in an index (how the directories are
> kept). If the content is a few hundred bytes, it will go in the MFT too and
> the file only takes 1K.
>
> After that, it allocates clusters, where the cluster size is fully
> configurable at format time. I use fairly small clusters to prevent just
> this kind of waste. Microsoft's documentation claims, in all its wisdom,
> that a smaller cluster size will increase fragmentation. But on a fast SCSI
> drive it's never been a problem, and I can always defragment if needed.
> Anyway, a data drive could easily have clusters of 1K or 2K, not the
> wasteful 4K. One could even use half a K per cluster.
>
> --John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Lavedas <swl### [at] virginiaedu> wrote:
: Take a look at my indented version.
It could be better. Your indentation style has some lack of logic.
The general rule is: every block is indented.
: #declare HalfDome_1 =
: union {
Here the entire union is a block so it should be indented with respect
to the #declare, ie:
#declare HalfDome_1 =
union {
...
}
: #declare aa = 0;
The block inside the union is also a block, so it should be indented:
#declare HalfDome_1 =
union {
#declare aa = 0;
...
}
: #while (aa < 90)
This #while is not an independent block with respect to the #declare, so
it can't be indented. It's part of the same block.
#declare HalfDome_1 =
union {
#declare aa = 0;
#while (aa < 90)
...
#end
...
}
: #declare bb = 0;
: #while (bb < 45)
Here you made it right. So sometimes you indent in one way and sometimes
in the other. There's no logic there.
: box{
: ...
: }
A block closing parenthesis should be indented at the same depth as the
block itself, ie:
box {
...
}
Another style of placing the opening parenthesis is:
box
{ ...
...
}
(I like this one more)
So my version would be:
#declare HalfDome_1=
union
{ #declare aa=0;
#while(aa<90)
#declare bb=0;
#while(bb<45)
box
{ -.5,.5
scale<.05,1.5,1.5> translate z*-40 rotate z*-2*bb
scale<1,1,1.6+pi/90*-bb> rotate y*2*aa translate y*.75
}
#declare bb=bb+1;
#end
#declare aa=aa+1;
#end
}
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I would probably be able to help you with the maths but I didn't completely
understand the problem. Can you explain more detailedly what do you want to
calculate?
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> I would probably be able to help you with the maths but I didn't completely
> understand the problem. Can you explain more detailedly what do you want to
> calculate?
>
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/
As cleary as I might. The code I presented forms a quarter sphere shape
from flattend almost 2D boxes. After a little work I managed to come up with
a method that solves the problem you get when you rotate two different curves
into each other. A problem that is illustrated by the construction of a beach
ball. The sections are narrower on the ends an fat in the center. If they
were of equal width they would bunch up at the poles of the globe.
Any way the code takes one box, rotates it from n*-x, y*0 to x*0, n*y
stopping at 90 degrees. As each box is placed by the first while loop action
there is a scaling function being performed the reduces the size of each
subsequent box until the loop times out. So now I have a curved wedge
shaped construct much like the shape of a beach ball section. This small
sliver is now rotated 180 degrees to form the quarter sphere. Finished done.
For all of this to happen I had to calculate all of the values for each action
that took place to form this object. I would like to restructure the scene file so
that all I or another user has to do is input the size of box he/she wishes to use
and the radius of the sphere shape that needs to be created. The rest of equations
will be handled by the script from this point on.
Therefore the question is:
Can the file be converted to take 3 - scale values for the single box object
and one coordinate value, which by the way is also the radius value, then finish
the calcualtions and construction of the object by itself ?
I believe it is rather straight foreward and should pose no real challenge.
I just lack the personal memory of the processes learned 25 years ago and don't
have the printed resources here to look up the equations I need to plug in to
the right places.
So that's where it stands.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Lavedas wrote:
>
> Okay Ken... you have a couple of magic numbers in here (a magic number
> is a number that is just there for some reason and no logical
> explaination is known except by the author) The most important one is
> 1.6*pi/90-bb where did you get this figure? I am trying to figure it
> out, and my guess is that you just kept tweaking it until there weren't
> any gaps...Also, where did you come up with the origial scale for the
> box?
>
> Steve
I have finally figured out why it was necessary to add the extra .1 to
the object size. As the boxes are rotated and scaled the are rapidly
reduced in size for the y dimension. In fact the are reduced to zero
on the last loop of the counter. When the loop hits the last count
the object has reached a dimension where it is divisible by itself
and Pov notes a divide by zero error.
The Pov team, in their own infinite wisdom, have built a trap into
the program to protect us from this kind of situation. Unfortunately
when Pov steps in to correct the error it automatically assigns a
scale of one to the offending object. I could not for the life of
me figure out why my dome was so distorted on the top most row.
I finally, probably by accident, found that adding the .1 value
kept the object within scalable limits before the count died and Pov
would be forced to rescue me from myself.
I wonder If I could save myself a lot of trouble by starting the first
rotation from the top of the dome downward opposite it's current
behavior. This way it would never reach zero because the object size
will be increasing instead of decreasing through the loop.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Actually, sitting through what may have been THE most boring lecture I
have ever attended... And I have attended quite a few, I came to a
solution to your problem. I have yet to implement it except on paper
since I have been extremely busy (though I can now claim the 7th fastest
ergometer score on my crew team since I covered 2000meters in 6:31.2
today after covering the same distance in 2.4 seconds more yesterday and
got perhaps that much sleep between them) So if you will forgive me, I
am going to nap, then go to a meeting, then lift, then do homework for
three classes and then tomorrow after my long day is over, I will
implement the code... The sad part is that it isn't so hard to
implement, but I just haven't sat down and typed it in (btw the radius
will and must be defined by the size of the box used...)
Steve
(of course in the time it took me to write this...)
Ken wrote:
>
> Stephen Lavedas wrote:
> >
> > Okay Ken... you have a couple of magic numbers in here (a magic number
> > is a number that is just there for some reason and no logical
> > explaination is known except by the author) The most important one is
> > 1.6*pi/90-bb where did you get this figure? I am trying to figure it
> > out, and my guess is that you just kept tweaking it until there weren't
> > any gaps...Also, where did you come up with the origial scale for the
> > box?
> >
> > Steve
>
> I have finally figured out why it was necessary to add the extra .1 to
> the object size. As the boxes are rotated and scaled the are rapidly
> reduced in size for the y dimension. In fact the are reduced to zero
> on the last loop of the counter. When the loop hits the last count
> the object has reached a dimension where it is divisible by itself
> and Pov notes a divide by zero error.
> The Pov team, in their own infinite wisdom, have built a trap into
> the program to protect us from this kind of situation. Unfortunately
> when Pov steps in to correct the error it automatically assigns a
> scale of one to the offending object. I could not for the life of
> me figure out why my dome was so distorted on the top most row.
> I finally, probably by accident, found that adding the .1 value
> kept the object within scalable limits before the count died and Pov
> would be forced to rescue me from myself.
>
> I wonder If I could save myself a lot of trouble by starting the first
> rotation from the top of the dome downward opposite it's current
> behavior. This way it would never reach zero because the object size
> will be increasing instead of decreasing through the loop.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Lavedas wrote:
So if you will forgive me, I
> am going to nap, then go to a meeting, then lift, then do homework for
> three classes and then tomorrow after my long day is over, I will
> implement the code... The sad part is that it isn't so hard to
> implement, but I just haven't sat down and typed it in (btw the radius
> will and must be defined by the size of the box used...)
>
> Steve
> (of course in the time it took me to write this...)
Good night Steve,
I have at least another couple months to live so take all the time you
need. All kidding aside your efforts are appreciated and never have
I asked for extra effort or put time demands on someone who is doing
me a favor in the first place.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
