 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Dunn" <poi### [at] aol com> wrote in message
news:3C56F507.1F0265E4@aol.com...
Well, I don't think there's been an "...intolerant stream of abuse",
Dave, but well said anyway.
I came in when 3.1g was up and running, and as a newbie, found it fairly
easy to use apart from I didn't use all the 'methods' that I could have. In
actual fact, It was a very confusing time for me as Megapov and 3.1 were
being talked about quite a lot in the forums, and as a result, I now have
3.1g, Megapov 0.7 and 3.5 beta10 installed.
Personally, I'm glad that 3.5 is coming out and have enjoyed immensly the
experimentation side of it. It also brings me up to date and in line with
other people here too.
Before I discovered PoV-Ray, I was computer-art illiterate, but 'because'
of PoV-Ray and the people that surround it, I know a fair amount more now,
and for that I will always be thankful to the people that put it together
and will remain loyal as a result.
And that's it.
Just my tuppence worth.
~Steve~
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Why? With the "workarounds" you get a nicer result, often even faster.
It's
> also more versatile, as you can scale non-uniformly the blur amount, and
even
> make the blurring amount to follow a pattern (or function). This is not
> possible with the "hack" in megapov.
My tests, using the code from the VFAQ, indicate that the "workaround" shows
serious aliasing, is quite cumbersome to write, is slightly slower, appears
to be less accurate, and cannot be layered. It seems to be more of a hack
in regards to complexity and end result than the reflection blur in MegaPOV.
The same averaged normal trick works in MegaPOV too, so it's not like having
reflection blur deminishes the versitility of the program at all. This
applies to many other features in MegaPOV. Ironically, the issue of
backward compatibility seemed to have been a higher priority in MegaPOV than
it is in 3.5, as least so far in the beta process. I don't recall ever
having a problem rendering a 3.1 scene file in megapov.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28 Jan 2002 21:12:58 -0500, Warp wrote:
> Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
>:> On the other hand there are things that can be done with 3.5 that can't
>:> be done with megapov.
>: like?
>
> Like pattern functions, fractal patterns with exponents >4, transmit
> behaviour outside the range 0-1, support for reading JPEG and TIFF,
> unicode support, etc.
Forward compatibility with future versions...
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 14:16:23 -0500, Dave Dunn wrote:
> bicubic patch type 2 (Warp, you of all people should have caught this), instead of
mesh 2. And
> yes, the patches in type 2, in addition to parsing faster, seemed to make for
smoother
> objects, with fewer attifacts. Other than that, I still find the excluded features
of value.
Unfortunately, the code for bicubic patch type 2 was buggy and even its
original author didn't think it was suitable for inclusion in 3.5.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 28 Jan 2002 22:15:10 -0500, Dave Dunn wrote:
> MegaPOV 0.7
> Reflection blur - I've seen enough workarounds in these groups to know this
> is needed.
Actually, it's not all that necessary. It wasn't any faster than the
"workaround" (which isn't a workaround at all, but is based on actual
physical principles) in most day-to-day scenes. There's only one thing
it did better, and that's multiple blurred interreflections. It didn't,
however, do blurred transmission, which the "workaround" does.
> Motion blur - okay, flawed, but certainly useful; I use it often.
Written by Nathan Kopp, who is a member of the POV-Team. I'm pretty sure
he didn't feel it was up to snuff for the 3.5 release.
> Blinn microfacets - superior to specular highlights in every way.
Added to MegaPOV after 3.5 development was started. We had to draw the
line somewhere, no?
> Heightfield_height_at (no way trace works better on hfs, sorry).
It certainly doesn't work any worse. hf_height_at didn't return the
normal, it only worked for heightfields, and it bloated the language
unnecessarily. If you want it, write a macro. If you don't like
trace, use a pigment function.
> Text object enhancements (why use a macro when you can just use this?).
Because someday you'll discover that the three effects that were "built
in" in MegaPOV just aren't enough. You'll want flush justification.
You'll want flush justification that only modifies interword spacing.
You'll want to fit your text to a curve. You'll want to use a different
angle for the baseline than for the character advance. Should we add
a new keyword to the language for each of these uses? Of course not.
Why, then, should there be keywords for left/right/center justification?
What about top/bottom/baseline/center vertical alignment? What about
bold and italic characters in the middle of a string? We could write a
whole freakin' typesetting language in the text object, and somebody
still wouldn't be happy. Best to stop that before it starts.
> Ini_option (why in the world was this removed?).
Again, written by Nathan Kopp and voluntarily removed. It caused more
problems than it solved. There are reasons the things that are INI
options aren't script options. Resolution independence, OS independence,
and various other things are among them, but you can think of others if
you try.
> Mesh Type 2 (parsed much faster and came out smoother).
You meant bicubic type 2, as you mentioned. That was removed because
the author left "//FIXME" comments sprinkled throughout. When we
contacted him, he felt that that work shouldn't be added to 3.5 without
major overhauls, and nobody was prepared to do the necessary overhauls.
> Glows (Ahem, Chris, didn't you write this one? ; } ).
After 3.5 was well past the planning stages, again. And Chris is a member
of the TAG, not the POV-Team, so he doesn't decide what goes in and what
doesn't.
> POVMan
Not in MegaPOV per se, not a complete SL implementation, not offered by
the author for inclusion in the official version, and not completed before
the cutoff for new features in 3.5.
> ClothSim (How is 3.5 better than this?)
See comments for POVMan.
> Renderman-like Shaders (See falling star animations at p.b.a)
I have to assume you mean POVMan here, since I'm not familiar with any other
Renderman-like whatsis. The POV-Team has to know about these patches for
them to be included, you know. That means, usually, that the author has to
actually say something to us about them, and give us the rights to include
them. I know I don't have time to read povray.binaries.<anything> anymore,
so perhaps this patch has escaped our notice. In any case, it doesn't
appear to be a vanilla MegaPOV patch.
In any case, if we add programmable shaders they will not resemble
Renderman SL in any way. That's not conceit, or hubris, or unreasoning
defiance. That's simple pragmatism: we can't implement everything SL
needs (in particular, the dU and dV variables turn out to be close to
impossible in POV-Ray) so we shouldn't lead people to believe that any
old SL shader will work. Such functionality is likely to be available
in some form eventually, but none of the existing patches will help with
that.
By the way, star "shaders" are possible in vanilla 3.1. See the 3.5
standard include files. You're looking for a macro called "Star_Pig"
in textures.inc.
> MegaPOV Plus
See comments for POVMan.
> Particle_system (I know the author is around somewhere).
See comments for POVMan.
> OK, there are a few things I like about 3.5 Beta+, like the easier
> dispersion
Let's not forget "more physically accurate" shall we? I spent days
researching color theory to come up with something better there.
Other things you don't know about 3.5: it's more stable, cleaner
code, has more internal consistency in the language, and generally
runs faster than MegaPOV. Code you write for 3.5 will be compatible
in some way with 4.0. Code you write for MegaPOV today won't even
be compatible with the next version of MegaPOV, let alone any
official version of POV.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 04:43:07 +0100, Zeger Knaepen wrote:
> I really don't understand why POV-Ray 3.5 was made. IMHO it's a waste of time. The
> POV-Team should have concentrated on starting with POV-Ray 4.0.
> I mean: POV 4.0 will be a complete rewrite, so everything they do now will have to
be
> redone. What's the point?
People were whining that there wasn't a new official version. We can't
please everybody, it seems.
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 14:26:11 +0100, Zeger Knaepen wrote:
>> Pov3.5 takes the best of Megapov, remove the bugs, and makes it the official
>> version from which all future versions will be build.. I don't see why
>> Pov4.0 should be a complete rewrite.. Anyway, making Pov3.5 first, is the
>> logical way to go.. It's like to climp up the stairs, instead of trying to
>> jump to the top.
> It's not my idea to make POV4.0 a complete rewrite (although I agree that it would
> probably be a good thing). But didn't the POV-Team say that POV4.0 would be a
complete
> rewrite in C++?
Yes. Most of that has to do with having total ownership over the code. It
might surprise you to know that some of the code is not necessarily ours to
do with as we will. Thus, we can't really rewrite large chunks of the
license.
> If I'm wrong about this, then I have no problems whatsoever with POV3.5, but if
that's
> right, I really think starting with POV4.0 would have been a better idea (and no:
I'm not
> telling you what to do, I'm telling you what I would do)
But is that what you would do if it had been years since an official version
was released, the users were getting restless, and 4.0 was probably still
years away?
BTW, parts of the 4.0 rewrite have already started. Option handling is
totally redone in 3.5, for example.
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 13:26:41 +0100, Christoph Hormann wrote:
> Megapov, although being quite stable and containing various features that
> are not in 3.5 has some serious flaws, especially in the
> isosurface/function part like 'trace()' not working on isosurfaces and
That was a bug. I thought it was fixed in the latest MegaPOV.
--
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 19:28:53 -0600, Mike Hough wrote:
> My tests, using the code from the VFAQ, indicate that the "workaround" shows
> serious aliasing,
You're doing something wrong. Try adjusting the scales of the normals and
the displacements to fit your scene better.
> is quite cumbersome to write,
This is why you have macros.
> is slightly slower,
This is the price of the flexibility you get by specifying your own normals
instead of using the fake one that was in the MegaPOV hack.
> appears
> to be less accurate,
The word "appears" here cannot be stressed enough. The "workaround" uses
physically correct principles. The hack does not.
> and cannot be layered.
I don't understand this statement. Why would you want to layer a normal
anyway?
> The same averaged normal trick works in MegaPOV too, so it's not like having
> reflection blur deminishes the versitility of the program at all.
Nope. But it limits future expansion if we incorporate a half-baked, ill-
thought-out feature like MegaPOV's reflection blur. There is a right way
to do this internally to POV, but the way MegaPOV did it isn't it.
> applies to many other features in MegaPOV. Ironically, the issue of
> backward compatibility seemed to have been a higher priority in MegaPOV than
> it is in 3.5, as least so far in the beta process.
Please don't cast aspersions like this without backing them up with some
evidence of some sort. What evidence do you have that the POV-Team is not
fixing compatibility bugs wherever they're found?
> I don't recall ever
> having a problem rendering a 3.1 scene file in megapov.
Didn't use too much layered transparency or radiosity, then, did you?
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes. Most of that has to do with having total ownership over the code. It
> might surprise you to know that some of the code is not necessarily ours to
> do with as we will. Thus, we can't really rewrite large chunks of the
> license.
didn't know that.
> But is that what you would do if it had been years since an official version
> was released, the users were getting restless, and 4.0 was probably still
> years away?
Do users really need an official version every few years? I'm happy with unofficial
patches, as long as they work the way I expect :)
> BTW, parts of the 4.0 rewrite have already started. Option handling is
> totally redone in 3.5, for example.
kewl :)
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> People were whining that there wasn't a new official version. We can't
> please everybody, it seems.
don't get me wrong, it's not that I'm not happy with an official version of POV-Ray,
but I
just hope working on POV3.5 doesn't have a sideeffects, like a later POV4.0 release :)
I mean: I can see the need for official version of POV-Ray, but I'd rather have POV4.0
within 2 years and no official version in the meantime, than POV4.0 withing 4 years
but an
official 3.X version every year.
But as long as I can play with POV-Ray, I'm happy :)
(I hope 2 years wasn't too optimistic?)
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > and cannot be layered.
> I don't understand this statement. Why would you want to layer a normal
> anyway?
How would you make a dirty blurred-reflective metal? In MegaPov you could add a layer
of
a dirt-texture to your blurred-reflective metal, but because layered-textures don't
work
with texture_maps, you couldn't add a layer of dirt to the blurred-reflective metal in
POV3.5.
It's probably possible to 'fake' layers using texture_maps, but you have to agree that
layered textures are much easier to understand and to make.
For the record: I haven't used MegaPov's reflection_blur much, because I didn't really
like the results. The 'workaround' gives much better results, and seems to be faster,
so
except for the layering-problems, I think it's a much better way to make blurry
reflections.
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 30 Jan 2002 04:06:13 +0100, Zeger Knaepen wrote:
>> > and cannot be layered.
>> I don't understand this statement. Why would you want to layer a normal
>> anyway?
> How would you make a dirty blurred-reflective metal? In MegaPov you could add
> a layer of
> a dirt-texture to your blurred-reflective metal, but because layered-textures
> don't work
> with texture_maps, you couldn't add a layer of dirt to the blurred-reflective
> metal in
> POV3.5.
> It's probably possible to 'fake' layers using texture_maps, but you have to
> agree that
> layered textures are much easier to understand and to make.
True. Personally, I don't understand why you can't use a texture_map in a
layered texture. Let me investigate that a little further.
BTW, can you fix your newsreader to use 80 columns per line or less? The
above is what your post looks like here.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> True. Personally, I don't understand why you can't use a texture_map in a
> layered texture. Let me investigate that a little further.
tnx :)
> BTW, can you fix your newsreader to use 80 columns per line or less? The
> above is what your post looks like here.
Done.
I hope it didn't ruin my sig :-/
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Done.
> I hope it didn't ruin my sig :-/
pfew! :)
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 30 Jan 2002 04:21:21 +0100, Zeger Knaepen wrote:
>> True. Personally, I don't understand why you can't use a texture_map in a
>> layered texture. Let me investigate that a little further.
> tnx :)
Well, looking at the code, the main reason is that it would be a major
rewrite if it were possible at all. But don't lose hope.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well, looking at the code, the main reason is that it would be a major
> rewrite if it were possible at all.
AAARGH!!!
<jumping around the room> /me loses all hope for a good life...
<bouncing head against his keyboard> qdfmjaervckjmdfmd
> But don't lose hope.
oh...
sorry 'bout that :)
(I think I need some sleep :)
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Please don't cast aspersions like this without backing them up with some
> evidence of some sort. What evidence do you have that the POV-Team is not
> fixing compatibility bugs wherever they're found?
Most recently there was something in the thread "long time, no see" where
someone brought up a difference in the clock value generated by a scene file
and one of the responses was
"As said, it is a precision issue. It is irrelevant what 3.1 would output
because it is a precision issue and thus it really doesn't matter if
something changed or not. Just get used to it."
I don't know if it was an actual bug or not but it seemed to be written off
without investigation.
In another thread:
"In article <Xns### [at] 204213191226> ,
che### [at] sympaticoca
(Coridon Henshaw) wrote:
> Beta 10 ignores the angle statement unless it is the last
> component in the camera block (this change wasn't documented) and requires
> the up and right vectors to be given when using the orthographic camera.
Neither is correct. Both work at any place in the camera statement.
"
This one is a bug that I noticed when rendering an older file.
Of course, it's still in beta so there's still time for these to be checked
and fixed if needed. It's just that sometimes users are not asked to double
check if it cannot be reproduced, or if there's a good reason for a change
that it is not given.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom>,
Ron Parker <ron### [at] povrayorg> wrote:
> bold and italic characters in the middle of a string? We could write a
> whole freakin' typesetting language in the text object, and somebody
> still wouldn't be happy. Best to stop that before it starts.
Hmm...embedded PDF support? ;-)
> > Glows (Ahem, Chris, didn't you write this one? ; } ).
>
> After 3.5 was well past the planning stages, again. And Chris is a member
> of the TAG, not the POV-Team, so he doesn't decide what goes in and what
> doesn't.
Besides, I've said many times the patch is incomplete...I believe I even
stated this in the documentation.
> > Particle_system (I know the author is around somewhere).
>
> See comments for POVMan.
More like the one for glows...not nearly complete enough.
> Other things you don't know about 3.5: it's more stable, cleaner
> code, has more internal consistency in the language, and generally
> runs faster than MegaPOV. Code you write for 3.5 will be compatible
> in some way with 4.0. Code you write for MegaPOV today won't even
> be compatible with the next version of MegaPOV, let alone any
> official version of POV.
Personally, this is my favorite part...I plan to rewrite both the
particle system and glow patches to take advantage of POV 3.5, doing
things which I couldn't do (without a lot of effort) with MegaPOV.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
25ct wrote:
> In actual fact, It was a very confusing time for me as Megapov and 3.1 were
> being talked about quite a lot in the forums, and as a result, I now have
> 3.1g, Megapov 0.7 and 3.5 beta10 installed.
Is that all? I've got 1.0, 2.2, 3.01, 3.1, 3.5 and a half dozen or more
patched versions installed. :)
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 21:49:45 -0600, Mike Hough wrote:
>> Please don't cast aspersions like this without backing them up with some
>> evidence of some sort. What evidence do you have that the POV-Team is not
>> fixing compatibility bugs wherever they're found?
>
> Most recently there was something in the thread "long time, no see" where
> someone brought up a difference in the clock value generated by a scene file
> and one of the responses was
>
> "As said, it is a precision issue. It is irrelevant what 3.1 would output
> because it is a precision issue and thus it really doesn't matter if
> something changed or not. Just get used to it."
Though that statement was made by a member of the POV-Team, it was not
an official position unless he said it was. I don't believe he did.
> I don't know if it was an actual bug or not but it seemed to be written off
> without investigation.
>
> In another thread:
>
> "In article <Xns### [at] 204213191226> ,
> che### [at] sympaticoca
> (Coridon Henshaw) wrote:
>
>> Beta 10 ignores the angle statement unless it is the last
>> component in the camera block (this change wasn't documented) and requires
>> the up and right vectors to be given when using the orthographic camera.
>
> Neither is correct. Both work at any place in the camera statement.
> "
>
> This one is a bug that I noticed when rendering an older file.
The camera stuff is still being worked on, to the best of my knowledge.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c576a20$1@news.povray.org>,
"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote:
> (I think I need some sleep :)
I think you just need less caffeine and/or sugar...
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen wrote:
> Now this is a reply that's helping me to understand why POV3.5 was made. tnx :)
> I didn't know the MegaPov code was like that. I've never looked at POV-Ray's
source.
Perhaps a little history might help -
http://news.povray.org/povray.announce.frequently-asked-questions/16698/106689/?tmax=100#106689
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
/*
On 29 Jan 2002 22:26:26 -0500, Ron Parker wrote:
> On Wed, 30 Jan 2002 04:21:21 +0100, Zeger Knaepen wrote:
>>> True. Personally, I don't understand why you can't use a texture_map in a
>>> layered texture. Let me investigate that a little further.
>> tnx :)
>
> Well, looking at the code, the main reason is that it would be a major
> rewrite if it were possible at all. But don't lose hope.
Okay, for those of you who didn't lose hope, I have something resembling
good news. It's true that you can't layer over texture maps. But the
next best thing is to not have to use a texture map.
Notes:
- This won't work with blurred refraction. POV uses only the normal
of the top layer to spawn a refracted ray. Sorry, but this isn't
likely to change in the near future.
- The limit on the number of layers you can have in a single texture
is currently 20, so you can't use more than 20 samples minus the
number of other layers you want to use. I'm not sure, but I think
that number doesn't need to be so low.
- Note the changes from the VFAQ example: the pigment is only on the
lowest layer, and the reflection amount must be divided by the number
of samples (this division happens automatically in average texture_maps)
*/
#declare BlurAmount = .2; // How blurred the reflection should be
#declare BlurSamples = 10; // How many reflected rays to shoot
camera {location <0,1,-5> look_at y}
plane { y 0
finish {ambient 1}
pigment {gradient x color_map {[0 red 1][1 blue 1]} scale .5}
}
cylinder {0 5*y 1
texture {
pigment { color rgb 0 } // The pigment of the object here
}
#declare Ind = 0;
#declare S = seed(0);
#while(Ind < BlurSamples)
texture {
pigment {color rgbt 1}
finish { reflection .9/BlurSamples}
normal { bumps
BlurAmount
translate <rand(S),rand(S),rand(S)>*10
scale 1000
}
}
#declare Ind = Ind+1;
#end
}
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mike Hough" <Ama### [at] aolcom> wrote in message
news:3c576c79@news.povray.org...
> Most recently there was something in the thread "long time, no see" where
> someone brought up a difference in the clock value generated by a scene
file
> and one of the responses was
>
> "As said, it is a precision issue. It is irrelevant what 3.1 would output
> because it is a precision issue and thus it really doesn't matter if
> something changed or not. Just get used to it."
>
> I don't know if it was an actual bug or not but it seemed to be written
off
> without investigation.
Bad example. The person with the problem had done something you are told
never to do with floating point values, and was upset when it (as predicted)
eventually failed on him.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> > "As said, it is a precision issue. It is irrelevant what 3.1 would output
> > because it is a precision issue and thus it really doesn't matter if
> > something changed or not. Just get used to it."
>
> Though that statement was made by a member of the POV-Team, it was not
> an official position unless he said it was. I don't believe he did.
That one was a direct quote. I thought it was a bit abrupt but figure
that since Thorsten knows more about the inner-workings of POV-Ray
than I far be it from me to question him on it.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 20:05:31 -0800, Ken wrote:
>
>
> Ron Parker wrote:
>
>> > "As said, it is a precision issue. It is irrelevant what 3.1 would output
>> > because it is a precision issue and thus it really doesn't matter if
>> > something changed or not. Just get used to it."
>>
>> Though that statement was made by a member of the POV-Team, it was not
>> an official position unless he said it was. I don't believe he did.
>
> That one was a direct quote. I thought it was a bit abrupt but figure
> that since Thorsten knows more about the inner-workings of POV-Ray
> than I far be it from me to question him on it.
I'm not questioning the factual accuracy of the statement (i.e. that it is,
indeed, a precision issue.) I'm just saying the tone is not necessarily
indicative of official policy.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> I'm not questioning the factual accuracy of the statement (i.e. that it is,
> indeed, a precision issue.) I'm just saying the tone is not necessarily
> indicative of official policy.
My Bad. (don't you hate it when people say that? I do.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Jan 2002 20:11:47 -0800, Ken wrote:
>
>
> Ron Parker wrote:
>
>> I'm not questioning the factual accuracy of the statement (i.e. that it is,
>> indeed, a precision issue.) I'm just saying the tone is not necessarily
>> indicative of official policy.
>
> My Bad. (don't you hate it when people say that? I do.)
Nope, mine. I didn't make that clear in the original post.
(And yes, I do. Your bad what? Breath?)
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:3C576D9E.D6CEA9B8@pacbell.net...
>
>
> 25ct wrote:
>
> > In actual fact, It was a very confusing time for me as Megapov and 3.1
were
> > being talked about quite a lot in the forums, and as a result, I now
have
> > 3.1g, Megapov 0.7 and 3.5 beta10 installed.
>
> Is that all? I've got 1.0, 2.2, 3.01, 3.1, 3.5 and a half dozen or more
> patched versions installed. :)
Well you've been around for aeons.... ;)
~Steve~
>
> --
> Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c576c79@news.povray.org> , "Mike Hough" <Ama### [at] aolcom>
wrote:
> "As said, it is a precision issue. It is irrelevant what 3.1 would output
> because it is a precision issue and thus it really doesn't matter if
> something changed or not. Just get used to it."
>
> I don't know if it was an actual bug or not but it seemed to be written off
> without investigation.
Oh, come on. First of all you are quoting from the second thread about this,
in the original thread several people had explained the problem in more detail
and the nature of floating-point precision and how to properly deal with it.
As I have no way in proving that there is no problem until the source code is
released, you either take my word for it or you don't. If you really want to
use this fact to claim there is a problem and nobody cares, I find it rather
unreasonable :-(
Do you really think there is some code in there that says:
"add 0.00000000298023224 to clock to annoy users"? ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
<snip lots of stuff>
Great! Now I'm drooling on my keyboard for 3.5
From reading the messages, I have decided to wait for 3.5. If, after a
while, I learn and exploit everything in it, I'll check into the then
3.5 based Mega-Pov.
But since there's still lot's of 3.1 aspects that I haven't figured out
how to use, it may take a while.
--
Tom A.
"No doubt many that post deserve to be flamed. And many that are flamed
didn't deserve it. Can you give them the latter? Then don't be so
quick to deal out the former!" - not Gandalf.
Deja mail is gone. Look for me at raugost at yahoo . com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I always meant to ask; I keep hearing that in POV3.5 iso's, "&" means OR
and "|" means AND. How come?
--
signature{
"Grey Knight" contact{ email "gre### [at] yahoocom" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: Do you really think there is some code in there that says:
: "add 0.00000000298023224 to clock to annoy users"? ;-)
I was wondering if floats could *really* be that inaccurate. When I make
this with povray:
#debug concat(str(99/100,0,25), "\n")
what I get is:
0.9899999999999999911182158
(instead of 0.99). I though, "is this really possible?".
Then I wanted to be sure and I made a small C program which does basically
the same thing:
#include "stdio.h"
int main()
{
printf("%.25f\n", 99.0/100.0);
return 0;
}
This program prints, surprise surprise:
0.9899999999999999911182158
So now I am convinced that there's no bug in povray.
Of course, when making a scene file, one has to minimize the effects of
floating point inaccuracy.
For example, don't do it this way:
#declare Ind = 0;
#declare Clock = 0;
#while(Ind <= 100)
#debug concat("Clock: ", str(Clock,0,25), "\n")
#declare Clock = Clock+1/100;
#declare Ind = Ind+1;
#end
(The last number printed is 1.0000000000000006661338148.)
Instead, do it this way:
#declare Ind = 0;
#while(Ind <= 100)
#declare Clock = Ind/100;
#debug concat("Clock: ", str(Clock,0,25), "\n")
#declare Ind = Ind+1;
#end
(The last number printed is 1.0000000000000000000000000.)
The reason for the second code being better than the first is left as
an exercise to the reader.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Grey Knight <s16### [at] namtarqubacuk> wrote:
: I always meant to ask; I keep hearing that in POV3.5 iso's, "&" means OR
: and "|" means AND. How come?
I haven't followed this thing quite closely, but AFAIK the meaning of '&'
and '|' was changed to logical operators "logical and" and "logical or"
(instead of being set theory operators "intersection" and "union", as they
are in megapov, I think).
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3c580c79@news.povray.org...
<snip>
Just out of curiousity, why does this surprise you?
Also just out of curiosity, if you ask a robot do they say "but it does say
0.99"? Hmm...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
: Just out of curiousity, why does this surprise you?
I knew that doubles are inaccurate, but it surprised me that they are *that*
inaccurate. The inaccuracy is "only" in the 18th decimal.
On the other hand, 18 decimals starts to sound like the maximum number of
digits (when converted to decimal) that the base of a double can hold...
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:3C576D9E.D6CEA9B8@pacbell.net...
>
>
> 25ct wrote:
>
> > In actual fact, It was a very confusing time for me as Megapov and
3.1 were
> > being talked about quite a lot in the forums, and as a result, I
now have
> > 3.1g, Megapov 0.7 and 3.5 beta10 installed.
>
> Is that all? I've got 1.0, 2.2, 3.01, 3.1, 3.5 and a half dozen or
more
> patched versions installed. :)
>
Why do I never see anyone mention 2.1? That's what I've still got
loaded, not 2.2 but all after and megapov 0.7, all DOS. Now I'm in
serious trouble <grin> coz I needed to get Winpov 3.1 for 1st time to
try Schmitt's recompile (Hey! I can use my box while Pov is working.
Thats a novelty!). So thought might as well get WinMega while I'm at
it. If I'm not careful, 3.5b will worm its way in soon.
Alf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Zeger Knaepen who wrote:
>> On the other hand there are things that can be done with 3.5 that can't
>> be done with megapov.
>like?
One neat little feature is spline functions. It's now possible to use a
spline to define a function, and then use that function, say, to specify
an isosurface without any of the mathematics that would otherwise be
involved.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Zeger Knaepen who wrote:
>> : And again: I never used the include files bundled with POV-Ray.
>> Because there wasn't anything interesting in them, until now.
>no, because I like to make everything myself. Even when I add a lensflare, it's
>with a
>customized version of Colefax' include file and using a custom lens effect.
Note, however, that there's been a slight tendency to move some of the
stuff out of the core code and into standard include files. A few things
that are features of the MegaPOV language are implemented in the 3.5
include files.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote:
> > But is that what you would do if it had been years since an official
version
> > was released, the users were getting restless, and 4.0 was probably still
> > years away?
> Do users really need an official version every few years? I'm happy with
unofficial
> patches, as long as they work the way I expect :)
>
AFAIK: Yes! Just consider the use of POV as a benchmark...
Although this is probably not, what POV was invented for, and where it's
real powers are, it's still used as an official benchmark...
You can't think, that people are using "unofficial patches" for doing serious
benchmarks ...
--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
probably it would have been enough, to look at IEEE 754 ?
--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> AFAIK: Yes! Just consider the use of POV as a benchmark...
> Although this is probably not, what POV was invented for, and where it's
> real powers are, it's still used as an official benchmark...
>
> You can't think, that people are using "unofficial patches" for doing serious
> benchmarks ...
What I meant was: of course we need official versions of POV-Ray, but I'm not
gonna complain because there hasn't been an official POV-Ray for over a year (or
even 2 years).
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alf Peake wrote:
> Why do I never see anyone mention 2.1?
I haven't a clue :)
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alan Kong wrote in message ...
>
> I am feeding coins through the ventilation slots in my computer. Are they
>coming through at your end? :)
// --------8<--------8<-----------8<----------8<-----------8<--------8<-----
#version 3.5;
#declare MoneyAmount=30;
#include "colors.inc"
#include "rand.inc"
#declare Coin=
union
{ difference
{ cylinder
{ 0,y*.3,2
pigment { Copper }
normal
{ radial 1 slope_map { [0 <0,1>][.5 <1,0>][1 <0,-1>] }
frequency 120
}
finish { specular .5 metallic reflection .1 }
}
cylinder { -y*.01,y*.05,1.9 }
cylinder { y*.31,y*.25,1.9 }
}
union
{ difference
{ cylinder { <0,.2,.8><0,.35,.8>,1 }
cylinder { <0,.2,.8><0,.36,.8>,.6 }
box { <.001,.2,-.2><1,.36,.8> }
}
difference
{ cylinder { <0,.2,-.8><0,.35,-.8>,1 }
cylinder { <0,.2,-.8><0,.36,-.8>,.6 }
box { <0,.2,.2><-1,.36,-.8> }
}
scale <1,1,.8>
}
box { <-.08,.2,-1.7><.08,.35,1.7> translate -x*.25 }
box { <-.08,.2,-1.7><.08,.35,1.7> translate x*.25 }
pigment { Copper }
normal { bumps .2 scale .1 }
finish { specular 1 roughness .002 metallic reflection .1 }
scale .5
}
camera { location <0,1,-1>*(sqrt(MoneyAmount)*2+5) look_at 0 angle 35 }
light_source { <50,200,-100> 1 }
plane { y,0 pigment { granite scale 5 } }
#declare Loc=array[MoneyAmount]
#declare R=seed(2);
#declare Ind=0;
#while(Ind<MoneyAmount)
#declare Dist=Rand_Gauss(0,1,R)*sqrt(Ind)*1.5;
#declare Ang = rand(R)*pi*2;
#declare Loc[Ind] = <Dist*sin(Ang),0,Dist*cos(Ang)>;
#declare Ind2=0;
#while(Ind2<Ind)
#declare cx=Loc[Ind2].x-Loc[Ind].x;
#declare cz=Loc[Ind2].z-Loc[Ind].z;
#if(cx*cx+cz*cz<4 & Loc[Ind2].y=Loc[Ind].y)
#declare Loc[Ind]=Loc[Ind]+y*.15;
#declare Ind2=0;
#else
#declare Ind2=Ind2+1;
#end
#end
object {
Coin
#if(rand(R) > .5)
scale <1,-1,1>
translate y*.15
#end
rotate y*rand(R)*360
translate Loc[Ind]
}
#declare Ind=Ind+1;
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 31 Jan 2002 01:36:45 -0500 Mark Wagner wrote:
>#version 3.5;
>#declare MoneyAmount=30;
<snip..>
Oh, there they are. Nice placement of coins.
--
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> ?!?!?
>
> I don't understand what you want to do or what you are up to. Or what
> supposedly now takes exponential time.
Sorry Thorsten - it's nothing to do with PoV really. I started to reply
to this a couple of days ago, when I had another look at the way I'd
re-written the algorithm I was using in MegaPoV to work with PoV3.5.
Basically I'd done a real p*ss-poor job of it and that was what was
causing the slow down.
All I really needed to do was separate the three colours, warp each one
and then average the results at the end.
<sigh> Why is it I only notice I've put my foot in my mouth when I'm
chewing on the knee ... </sigh>
Apologies again,
Mike Andrews.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2002-01-30 15:58, Warp <war### [at] tagpovrayorg> wrote:
> Tom Melly <tom### [at] tomandlucouk> wrote:
> : Just out of curiousity, why does this surprise you?
>
> I knew that doubles are inaccurate, but it surprised me that they are *that*
> inaccurate. The inaccuracy is "only" in the 18th decimal.
"That" inaccurate? 18 decimal places is enough to locate anything
between here and Alpha Centauri with an inaccuracy of less than two
inches.
> On the other hand, 18 decimals starts to sound like the maximum number of
> digits (when converted to decimal) that the base of a double can hold...
More like 16, actually. An IEEE-754 double precision floating point
number is 64 bits long: 1 for the sign, 11 for the exponent, which
leaves 52 bits for the exponent. So the precision is log(2^52) = 15.6
decimal places.
hp
--
_ | Peter J. Holzer |
|_|_) | Sysadmin WSR | In case of emergency break laws of physics.
| | | hjp### [at] hjpat |
__/ | http://www.hjp.at/ | -- Stephen Baxter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter J. Holzer" <hjp### [at] hjpat> wrote in message
news:slr### [at] tealhhjpat...
> On 2002-01-30 15:58, Warp <war### [at] tagpovrayorg> wrote:
> > Tom Melly <tom### [at] tomandlucouk> wrote:
> > : Just out of curiousity, why does this surprise you?
> >
> > I knew that doubles are inaccurate, but it surprised me that they are
*that*
> > inaccurate. The inaccuracy is "only" in the 18th decimal.
>
> "That" inaccurate? 18 decimal places is enough to locate anything
> between here and Alpha Centauri with an inaccuracy of less than two
> inches.
>
> > On the other hand, 18 decimals starts to sound like the maximum number
of
> > digits (when converted to decimal) that the base of a double can hold...
>
> More like 16, actually. An IEEE-754 double precision floating point
> number is 64 bits long: 1 for the sign, 11 for the exponent, which
> leaves 52 bits for the exponent. So the precision is log(2^52) = 15.6
> decimal places.
>
> hp
I thought they were 80 bits - at least, on x87 chips they are (which doesn't
mean anything about the standard!). Floats are 32bits (with an additional 8
bit mantissa), and doubles are 64 bits (with an additional 16 bit mantissa),
making them 40 and 80 bits, respectively.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <bdc### [at] yahoocom> wrote:
: I thought they were 80 bits - at least, on x87 chips they are (which doesn't
: mean anything about the standard!). Floats are 32bits (with an additional 8
: bit mantissa), and doubles are 64 bits (with an additional 16 bit mantissa),
: making them 40 and 80 bits, respectively.
The x87 chip (AFAIK) internally handles only 80-bit floats.
When it reads a 32-bit or 64-bit float, it converts it to a 80-bit float
for its internal representation. When it writes a float to a 32-bit or 64-bit
variable (ie. to RAM), it makes the conversion the other way around.
x86 code can have 32-bit floats (the 'float' type in C), 64-bit floats
(the 'double' type in C) and 80-bit floats (the 'long double' type in C,
although some compilers might make those 128-bit long for alignment
optimization purposes, with the extra 48 bits just being unused).
A float takes exactly 32 bits (ie. 4 bytes) and a double takes exactly
64 bits (ie. 8 bytes), no more, no less.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
