 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I agree that animations take up large amounts of hard disk, but the limiting
factor is the number of frames you generate, not the camera movement.
Right?
Harold
"Warp" <war### [at] tag povrayorg> wrote in message
news:3af5e0b5@news.povray.org...
> ZenPsycho <Zen### [at] yahoocom> wrote:
>
> I don't think a moving camera is a good idea in this kind of very long
> animation unless you have hundreds of megabytes of free disk space :)
>
>- Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
to give your game the human touch, randomly position each piece within
its square and give it a random twist on its vertical axis. in other
words, no human could place all of the pieces in the exact center of
each square and facing exactly forward. nice job btw. :)
Warp wrote:
>
> A chess set is not as classic as the reflective sphere on a checkered
> plane, but it comes close. Thus I decided to make one myself.
> I made it completely from the scratch, all by hand and pure CSG (I have
> played chess quite a lot and I know what the pieces look like, approximately
> at least).
>
> Making a chess set is actually quite fun. I recommend it to everyone
> who hasn't done one yet.
> It's not too difficult (the horse is the piece that requires most work,
> as can see in my image as well).
> The set forms a very nice hierarcy of objects. In my set the base of each
> piece is the same object; then I made colorless versions of each piece on
> the base object, and then white and black versions of each piece. Then I
> just copied the right number of pieces to the board.
> It's also easy to make a little macro that positions a piece on the board
> given its coordinates. This way it's easy to actually "move" the pieces
> on the board, as in actual playing.
>
> Name: chess.jpg
> chess.jpg Type: Postscript Document (application/postscript)
> Encoding: x-uuencode
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I guess you don't play chess with obsessive compulsives very often ;-)
Harolddd
"Ryan Constantine" <rco### [at] yahoocom> wrote in message
news:3AF72E9A.2209030E@yahoo.com...
> to give your game the human touch, randomly position each piece within
> its square and give it a random twist on its vertical axis. in other
> words, no human could place all of the pieces in the exact center of
> each square and facing exactly forward. nice job btw. :)
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Harold Baize" <bai### [at] itsaucsfedu> wrote in message
news:3af732a8@news.povray.org...
> I guess you don't play chess with obsessive compulsives very often ;-)
Ha! I wish I had said that.
I'm just such a person sometimes. A chess set in particular must be exactly
aligned at the start. I can lose to a 10 year old so unfortunately that
doesn't mean I can play well.
> "Ryan Constantine" <rco### [at] yahoocom> wrote in message
> news:3AF72E9A.2209030E@yahoo.com...
> > to give your game the human touch, randomly position each piece within
> > its square and give it a random twist on its vertical axis. in other
> > words, no human could place all of the pieces in the exact center of
> > each square and facing exactly forward. nice job btw. :)
I like both kinds of setup; erratic or immaculate, either way. Yet another
reason to do 3D rendering.
About the focal blurring maybe being overdone, I think of that in the same
way. Or it has something to do with my eyesight and not always wearing my
glasses.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Harold Baize <bai### [at] itsaucsfedu> wrote:
: I agree that animations take up large amounts of hard disk, but the limiting
: factor is the number of frames you generate, not the camera movement.
: Right?
Wrong. Most compressing animation formats take advantage of previous
(and sometimes next) frames in order to compress the current frame.
This means that the less things change from frame to frame, the more
compression can be achieved.
If you move the camera, virtually everything in the image changes, thus
resulting in less compression.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well wrong is some respects, but not as most people who animate with
POV-Ray are concerned. I think most of us render all the frames before
compression, and that is what eats up disk space, not the final animation
file. I know how video compression works. I recently animated (with POV)
a rotating factor structure from a factor analysis of a children's mental
health outcomes measure. I made 360 640x480 frames, so it was about
to 330MB before making an AVI file. Some programs, like Hash
Animation:Master will render directly to an animation so you don't chew
up so much disk space in the process. It is the pre-compression phase that
makes disk space a limiting factor, not the relatively small difference in
final
file size that camera movement contributes, even if it increases the final
animation file by a factor of four.
Harold
> Wrong. Most compressing animation formats take advantage of previous
> (and sometimes next) frames in order to compress the current frame.
> This means that the less things change from frame to frame, the more
> compression can be achieved.
> If you move the camera, virtually everything in the image changes, thus
> resulting in less compression.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
'perfectly aligned' by a human still isn't perfect. iirc, we can see
down to about 4/1000 of an inch which is pretty small, but that doesn't
mean we can make our hands move things by such slight amounts. you
would still need a robot to position the pieces 'exactly'. so even the
obsessive compulsive couldn't position them exactly. there would simply
be less jitter, in which case a positioning macro could have several
jitter settings: near perfect, regular, or sloppy.
"Bob H." wrote:
>
> "Harold Baize" <bai### [at] itsaucsfedu> wrote in message
> news:3af732a8@news.povray.org...
> > I guess you don't play chess with obsessive compulsives very often ;-)
>
> Ha! I wish I had said that.
> I'm just such a person sometimes. A chess set in particular must be exactly
> aligned at the start. I can lose to a 10 year old so unfortunately that
> doesn't mean I can play well.
>
> > "Ryan Constantine" <rco### [at] yahoocom> wrote in message
> > news:3AF72E9A.2209030E@yahoo.com...
> > > to give your game the human touch, randomly position each piece within
> > > its square and give it a random twist on its vertical axis. in other
> > > words, no human could place all of the pieces in the exact center of
> > > each square and facing exactly forward. nice job btw. :)
>
> I like both kinds of setup; erratic or immaculate, either way. Yet another
> reason to do 3D rendering.
> About the focal blurring maybe being overdone, I think of that in the same
> way. Or it has something to do with my eyesight and not always wearing my
> glasses.
>
> Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ryan Constantine" <rcc### [at] ucdavisedu> wrote in message
news:3AF9699E.FCDBEA61@ucdavis.edu...
> 'perfectly aligned' by a human still isn't perfect. iirc, we can see
> down to about 4/1000 of an inch which is pretty small, but that doesn't
> mean we can make our hands move things by such slight amounts. you
> would still need a robot to position the pieces 'exactly'.
Okay, but for 3D modelling I'd be willing to bet the typical render
resolution disallows that accuracy with which you say a human can manage.
Or would I lose that bet? Hmmm. 1/250 of an inch on a 19" screen at
1024x768 for example? I think that's about 70 pixels per inch... maybe, or
something like 1/70 an inch of accuracy possible.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
unless you render higher than your screen resolution for print
purposes. but, you did say 'typical' render resolutions. my typical
final resolution is always print quality however.
"Bob H." wrote:
>
> "Ryan Constantine" <rcc### [at] ucdavisedu> wrote in message
> news:3AF9699E.FCDBEA61@ucdavis.edu...
> > 'perfectly aligned' by a human still isn't perfect. iirc, we can see
> > down to about 4/1000 of an inch which is pretty small, but that doesn't
> > mean we can make our hands move things by such slight amounts. you
> > would still need a robot to position the pieces 'exactly'.
>
> Okay, but for 3D modelling I'd be willing to bet the typical render
> resolution disallows that accuracy with which you say a human can manage.
> Or would I lose that bet? Hmmm. 1/250 of an inch on a 19" screen at
> 1024x768 for example? I think that's about 70 pixels per inch... maybe, or
> something like 1/70 an inch of accuracy possible.
>
> Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob H. <omn### [at] msncom> wrote:
: Okay, but for 3D modelling I'd be willing to bet the typical render
: resolution disallows that accuracy with which you say a human can manage.
That's what antialiasing is for. It calculates sub-pixel information.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
