 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
