povray.beta-test.binaries message digest

[Mr] Re: Function / pattern issues. New inbuilt f_dec... [1893 days 18 hours and 59 minutes ago]

Fri, 5 Feb 2021 17:05:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/4/21 8:14 AM, Mr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> >
> > It looks good. But I'm not sure what I'm looking at. Could this be used as a
> > kind of tangent space normal_map? If so, using images or functions only?
> >
>
> Thanks. :-) I'm with you on not being sure what the images are! Both are
>   isosurfaces - so shapes. They showed up while I was testing.
>
> Neither encode or decode with these functions care where the data comes
> from or goes too. For the encode there is one value in and three out.
> The decode takes in three values and creates one.
>
> The primary aim is to be able to store and recover high bit depth values
> - something at very nearly double accuracy. The working value range for
> these two functions is -1.0 to 1.0. Expect 0.0-1.0 is what will be most
> used.
>
> Today - with v3.8 - we can easily(1) get to depths of 32 bits (.df3
> only), but not more. The best we can do with the usual image formats
> (and internal color representations) is floats (23 bits).
>
> (1) - With functions in v3.7/3.8 you can almost always do whatever you
> want, but it's often not easy.
>
> So! First and foremost, these two functions are a way to easily work
> with values having bit depths of up to 51 (3 channels, 17 bits each)(2).
> Fifty one is the most this method can support due having to use double
> for input and output.
>
> (2) - In v3.8 Christoph made improvements so that several image formats
> support a bit depth per channel setting (up to 16). This in part the
> reason to support bit depths of 1 to 17 per channel with these two
> functions.
>
> ---
> Once I got to playing with / testing the implementations, the
> possibilities opened up in a way I did not expect. These functions, by
> side effect, can do more than store high bit depth numbers - and with
> good performance. I was trying to suggest this with my initial post.
>
> I don't know myself what all can be done. I struggled with what
> documentation I wrote for them. The 'extra' stuff is not nearly as easy
> to understand and use. Heck, I'm sure I don't see all the subtleties as yet!
>
> Much of my aim with the povr branch - and especially with this
> pattern/function re-work push - is to knock down restrictions/obstacles
> and open up possibilities. To a degree, I don't know what the work means
> in terms of actual day to day usefulness. ;-)
>
> Bill P.

This sounds very exciting anyway !

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_dec... [1894 days 17 hours and 9 minutes ago]

Thu, 4 Feb 2021 18:55:28 GMT

On 2/4/21 8:14 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> It looks good. But I'm not sure what I'm looking at. Could this be used as a
> kind of tangent space normal_map? If so, using images or functions only?
> 

Thanks. :-) I'm with you on not being sure what the images are! Both are 
  isosurfaces - so shapes. They showed up while I was testing.

Neither encode or decode with these functions care where the data comes 
from or goes too. For the encode there is one value in and three out. 
The decode takes in three values and creates one.

The primary aim is to be able to store and recover high bit depth values 
- something at very nearly double accuracy. The working value range for 
these two functions is -1.0 to 1.0. Expect 0.0-1.0 is what will be most 
used.

Today - with v3.8 - we can easily(1) get to depths of 32 bits (.df3 
only), but not more. The best we can do with the usual image formats 
(and internal color representations) is floats (23 bits).

(1) - With functions in v3.7/3.8 you can almost always do whatever you 
want, but it's often not easy.

So! First and foremost, these two functions are a way to easily work 
with values having bit depths of up to 51 (3 channels, 17 bits each)(2). 
Fifty one is the most this method can support due having to use double 
for input and output.

(2) - In v3.8 Christoph made improvements so that several image formats 
support a bit depth per channel setting (up to 16). This in part the 
reason to support bit depths of 1 to 17 per channel with these two 
functions.

---
Once I got to playing with / testing the implementations, the 
possibilities opened up in a way I did not expect. These functions, by 
side effect, can do more than store high bit depth numbers - and with 
good performance. I was trying to suggest this with my initial post.

I don't know myself what all can be done. I struggled with what 
documentation I wrote for them. The 'extra' stuff is not nearly as easy 
to understand and use. Heck, I'm sure I don't see all the subtleties as yet!

Much of my aim with the povr branch - and especially with this 
pattern/function re-work push - is to knock down restrictions/obstacles 
and open up possibilities. To a degree, I don't know what the work means
in terms of actual day to day usefulness. ;-)

Bill P.

[Mr] Re: Function / pattern issues. New inbuilt f_dec... [1894 days 22 hours and 49 minutes ago]

Thu, 4 Feb 2021 13:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> <---------------------- References. Sixteen previous posts
>
> Function / pattern issues. Povr surface normal{} like dents.
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5f3fb137%241%40news.povray.org%3E/
>
> and
>
> Function / pattern issues. Povr inbuilt status 20 Dec 2020.
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5fdfc14f%40news.povray.org%3E/
>
>
> Elsewhere mentioned I mentioned replacing the .hf, never official,
> function block only and undocumented feature in v33.8. For the povr
> branch this comes as two new inbuilt functions called f_enc_nbit3c and
> f_dec_nbit3c. The 3 c standing for three channels (usually R,G,B) but
> the channels can be defined anyway one wants.
>
> I'd also mentioned supporting 2-17 bits of depth per channel, but on
> testing realized 1-17 was better because at 1, you can use f_dec_nbit3c
> alone as in inbuilt 3 value average pattern function. One which doesn't
> need to use the function { pattern/pigment } internal interface.
>
> 1-17 bits supports up to 51 bit single value depth (doubles come in at
> 52). The max in practice will probably be 16 bits per channel as this
> will fit in three 16 bit channel image formats of which there are a few.
> Using 17 bits requires moving to hdr or exr with float storage. It means
> on moving from 16 to 17 bits the storage per value increases from 48
> bits to 96 bits.
>
> Why the low bit depths? The depth effectively skews the G and B channels
> by powers of 2 and then powers of 2*2. This is useful as one can weight
> the contributions and then tune. Further, if the contributions are
> functions for example the full bit depth after the power of 2 shifts is
> still there when working with/or as is the values have been normalized.
> This last a concept the .hf implementation didn't support directly -
> users could make it work.
>
> I believe everything here is still doable in v3.8, but it is harder to
> code up.
>
> Not experimented too much as yet, but a couple test images attached.
> Both using a bit depth of 3, functions for each of the three channel
> inputs and marking the inputs normalized. I believe many interesting are
> possible.
>
> Credit to whomever wrote .hf. On some level, the approach in povr's two
> new inbuilt functions is the same. but one less hardwired to a
> particular task.
>
> Bill P.

It looks good. But I'm not sure what I'm looking at. Could this be used as a
kind of tangent space normal_map? If so, using images or functions only?

[William F Pokorny] Function / pattern issues. New inbuilt f_dec_nbi... [1895 days 13 hours and 20 minutes ago]

Wed, 3 Feb 2021 22:44:30 GMT

<---------------------- References. Sixteen previous posts

Function / pattern issues. Povr surface normal{} like dents.
http://news.povray.org/povray.beta-test.binaries/thread/%3C5f3fb137%241%40news.povray.org%3E/

and

Function / pattern issues. Povr inbuilt status 20 Dec 2020.
http://news.povray.org/povray.beta-test.binaries/thread/%3C5fdfc14f%40news.povray.org%3E/

Elsewhere mentioned I mentioned replacing the .hf, never official,
function block only and undocumented feature in v33.8. For the povr
branch this comes as two new inbuilt functions called f_enc_nbit3c and
f_dec_nbit3c. The 3 c standing for three channels (usually R,G,B) but
the channels can be defined anyway one wants.

I'd also mentioned supporting 2-17 bits of depth per channel, but on
testing realized 1-17 was better because at 1, you can use f_dec_nbit3c
alone as in inbuilt 3 value average pattern function. One which doesn't
need to use the function { pattern/pigment } internal interface.

1-17 bits supports up to 51 bit single value depth (doubles come in at
52). The max in practice will probably be 16 bits per channel as this
will fit in three 16 bit channel image formats of which there are a few.
Using 17 bits requires moving to hdr or exr with float storage. It means
on moving from 16 to 17 bits the storage per value increases from 48
bits to 96 bits.

Why the low bit depths? The depth effectively skews the G and B channels
by powers of 2 and then powers of 2*2. This is useful as one can weight
the contributions and then tune. Further, if the contributions are
functions for example the full bit depth after the power of 2 shifts is
still there when working with/or as is the values have been normalized.
This last a concept the .hf implementation didn't support directly -
users could make it work.

I believe everything here is still doable in v3.8, but it is harder to
code up.

Not experimented too much as yet, but a couple test images attached.
Both using a bit depth of 3, functions for each of the three channel
inputs and marking the inputs normalized. I believe many interesting are
possible.

Credit to whomever wrote .hf. On some level, the approach in povr's two
new inbuilt functions is the same. but one less hardwired to a
particular task.

Bill P.

[William F Pokorny] Function / pattern issues. Povr inbuilt status 2... [1940 days 14 hours and 39 minutes ago]

Sun, 20 Dec 2020 21:25:35 GMT

<---------------------- References. Fifteen previous posts

Function / pattern issues. Povr supertoroid parametric.
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee61540%241%40news.povray.org%3E/

and

Function / pattern issues. Povr surface normal{} like dents.
http://news.povray.org/povray.beta-test.binaries/thread/%3C5f3fb137%241%40news.povray.org%3E/


I had plans to get together another povr tar ball for year end, but I 
started too many work threads to tie them off in time. Instead a list of 
the current inbuilt functions (less the specials like pattern / 
f_pattern) since I've not posted many updates on this front of late.

The image attached uses a new f_radial_tubes function pulled out of the 
old f_polytubes so it's not hard wired to fourth order uni-variate 
polynomials. The tubes in this case follow an f_sphere. A little like a 
Holiday ornament, perhaps.

f_agate
f_boom
f_box
f_boxb
f_bump
f_cbrt
f_cone
f_cubic_wave
f_cylinder
f_dec2x_f32
f_dec3x_f21
f_dturbulence
f_eblob
f_ellipsoid
f_elliptical_cylinder
f_elliptical_sphrswp
f_enc2x_f32
f_enc3x_f21
f_gradient
f_granite23 - Experimental. Solidify..?
f_helix1
f_helix2
f_hessian_dist
f_hetero_mf
f_hypot
f_hypot_raw
f_labsweep
f_lame
f_length
f_length_sqr
f_marble - Perhaps drop. Really gradient with turb.
f_max1to8pairs
f_min1to8pairs
f_morph2to9fncts
f_mult1to8pairs
f_noise3d
f_noise_cubed
f_normal
f_normalized
f_npmod
f_onion
f_paraboloid
f_ph
f_pillow - Perhaps keep after rework...
f_piriform - Perhaps keep after rework...
f_planar
f_polyhedron
f_quartic_cylinder
f_quilt_cubic
f_r
f_radial
f_radial_tubes
f_remap
f_repeat
f_ridge
f_ridged_mf
f_rotate2d
f_rounded_box
f_scallop_wave
f_scallop_wavef
f_sign
f_sign0
f_signpow
f_signsqrt
f_sine_wave
f_sine_wavef
f_snoise3d
f_sphere
f_spiral - Reworking
f_steiners_roman - To be replaced w f_bezier_seg.
f_superellipsoid
f_supertorus
f_th
f_torus
f_toupie
f_triangle_wave
f_turbulence
f_upoly
f_wood - Plan a rework for rings.
f_wrap

Happy Holidays!

Bill P.

[William F Pokorny] Re: Playing in povr with shaped noise. [1962 days 18 hours and 38 minutes ago]

Sat, 28 Nov 2020 17:26:46 GMT

On 11/12/20 1:49 PM, William F Pokorny wrote:
> With povr, in addition to quilted, I've taken dents back to a normal 
> perturbation only pattern.
> 
...
> playing around with alternative noise shaping methods.
> 

With povr, I decided to make use of one of the quilted normal 
perturbation fixes not adopted as a new "tiled" normal perturbation only 
pattern.

Further, while I played with the idea of a new offset parameter to let 
the users make use of more of the internal quilt_cubic curve, I ended up 
implementing new "lo" and "hi" keywords so users can "re-range" inputs 
into the quilt_cubic curve function. Folks can make use of whatever 
parts of the curve they want.

For quilted pattern the usual value input range is 0.5 to 0.866 and for 
the new tiled pattern it's 0 to 0.5; Unless lo/hi used with other values 
in which case re-ranging happens.

Attached a quilted normal used on the left and on the right the new 
tiled normal only pattern; both with re-ranging into quilt_cubic.

Both images make use of noise shaping options of f_noise_cubed() for the 
base isosurface.

I'm thinking about one additional normal only pattern - based on the 
tiled approach - called grooved or furrowed, but we'll see.

Bill P.

[William F Pokorny] Re: Playing in povr with shaped noise. [1977 days 16 hours and 25 minutes ago]

Fri, 13 Nov 2020 19:39:28 GMT

On 11/12/20 2:48 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> to f_noise_cubed(). In looking at the inbuilt function again, I got to
>> playing around with alternative noise shaping methods.
>>
>> One of these is used for the raised bits on an isosurface plain in the
>> attached image. The updated quilted normal perturbation pattern is
>> applied on top on the shape.
>>
>> Bill P.
> 
> I looked at the noise generation code a while, and it's currently beyond my
> ability to puzzle out - pretty complex with all that hash table stuff.
> (Has anyone implemented Simplex Noise yet?)
> 

Not in any POV-Ray version that I'm aware. I looked at it briefly a long 
while back. My take then was that it would be less, "better" for us than 
those coming from the pure the pure Perlin type noise.

> I'm glad to see that you're renaming things to more accurately reflect what they
> are.
> Perhaps one approach to semi-retain some of the old naming would be to just make
> an include file "legacy.inc" that has a list of things like
> #declare dents = normal {noise_cubed} or whatever your syntax for that would be.
> 

Something possible I guess, but cannot use "dents" as it's still there 
as a normal only pattern.

> The isosurface looks great - I immediately thought it would make a great blood
> vessel wall, or a work-eaten wood or bark, or sand dunes....
> Probably lots of other immediate applications just by altering the colors and
> textures.
> 

Thanks. (And just picked up plain rather than plane in my original post...)

I enabled the shaped noise options of f_noise_cubed() in the noise_cubed 
pattern today and have been testing / playing. Attached an another image 
using the pattern form with average.

Bill P.

[Bald Eagle] Re: Playing in povr with shaped noise. [1978 days 16 hours and 14 minutes ago]

Thu, 12 Nov 2020 19:50:06 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> With povr, in addition to quilted, I've taken dents back to a normal
> perturbation only pattern.
>
> What was the dents scalar value for maps pattern in POV-Ray was noise
> cubed. I've kept the pattern, but renamed it noise_cubed.
>
> I've also renamed the previously created povr f_dents() inbuilt function
> to f_noise_cubed(). In looking at the inbuilt function again, I got to
> playing around with alternative noise shaping methods.
>
> One of these is used for the raised bits on an isosurface plain in the
> attached image. The updated quilted normal perturbation pattern is
> applied on top on the shape.
>
> Bill P.

I looked at the noise generation code a while, and it's currently beyond my
ability to puzzle out - pretty complex with all that hash table stuff.
(Has anyone implemented Simplex Noise yet?)

I'm glad to see that you're renaming things to more accurately reflect what they
are.
Perhaps one approach to semi-retain some of the old naming would be to just make
an include file "legacy.inc" that has a list of things like
#declare dents = normal {noise_cubed} or whatever your syntax for that would be.

The isosurface looks great - I immediately thought it would make a great blood
vessel wall, or a work-eaten wood or bark, or sand dunes....
Probably lots of other immediate applications just by altering the colors and
textures.

[William F Pokorny] Playing in povr with shaped noise. [1978 days 17 hours and 14 minutes ago]

Thu, 12 Nov 2020 18:49:53 GMT

With povr, in addition to quilted, I've taken dents back to a normal 
perturbation only pattern.

What was the dents scalar value for maps pattern in POV-Ray was noise 
cubed. I've kept the pattern, but renamed it noise_cubed.

I've also renamed the previously created povr f_dents() inbuilt function 
to f_noise_cubed(). In looking at the inbuilt function again, I got to 
playing around with alternative noise shaping methods.

One of these is used for the raised bits on an isosurface plain in the 
attached image. The updated quilted normal perturbation pattern is 
applied on top on the shape.

Bill P.

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1984 days 19 hours and 10 minutes ago]

Fri, 6 Nov 2020 16:53:48 GMT

On 10/31/20 8:23 AM, William F Pokorny wrote:
...
> 
> Thinking some of increasing the max allowed depth for AA method 1 to 
> perhaps 20. Also of trying again my isosurface cloud renders with jitter 
> values >>1.0....
> 

I've updated povr's AA and jitter code to support method 1 +r depths of 
whatever size. Left the other two methods alone.

Also made some updates to avoid extra work where the threshold is 
essentially zero or the aagamma (+ag) is 1.0. This lets one bypass the 
gamma curve corrections and use just threshold for control. One can get
substantial render savings. One can also get longer renders. Amounts to
more control and an ability to get time savings when the curve 
corrections and threshold tests are just useless computations toward an 
end result.

One other thing I've learned is the big jitter makes the method 1 
testing left and up only bias more obvious. For symmetry in AA results 
methods 2 and 3 are the way to go.

Lastly, attaching another example showing an odd effect one can get with 
very big jitter settings and largish threshold settings. Basically the 
big jitter only kicks in near where AA does. Not sure if the result 
would ever be that useful, but FWIW.

Bill P.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [1984 days 19 hours and 26 minutes ago]

Fri, 6 Nov 2020 16:37:52 GMT

On 11/5/20 6:18 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> Just to follow up:
...
> 

Cool. Some of those city-scape differences are artsy on their own.

Bill P.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [1985 days 12 hours and 24 minutes ago]

Thu, 5 Nov 2020 23:40:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> The 'automatic' use of AM3 jitter from render to render seems to work as
> advertised. And with Stochastic_Seed 'on' (with some integer seed value),
> there is NO pixel difference between renders, OR between rendered animation
> frames--jitter is successfully turned off...
>
Sorry, what I meant to say is that the jitter in animation is the SAME from
frame to frame (not 'off'). So no pixel differences from frame to frame.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [1985 days 12 hours and 44 minutes ago]

Thu, 5 Nov 2020 23:20:03 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Just to follow up:
> I have five different v3.8 'development versions' from Github (which run within
> v3.7.0), and I have tried them all: The new antialias mode is not recognized in
> any of them; they all revert to method 2. It seems that this new method was
> never actually implemented in these Windows development builds of 3.8x (or else
> maybe in one of the versions that I haven't yet tried??)...

Well, I was WRONG about that, and I apologize for the misinformation.

The new antialias Method 3 DOES work successfully in the *latest* v3.8
development build for Windows,   10064738+av694 ("experimental")

I thought I had tried that one-- it's in my collection-- but apparently not. (Or
maybe I mis-read the message pane at the time.) So I have finally been able to
do some tests with it, using all .png renders except for this final image.

My AA rendering values in my INI file were  somewhat basic:
Antialias=on
Sampling_method=3 (or 2)
Antialias_Threshold=0.05
Stochastic_Seed=7 (or not used at all)
(the other values/keywords are at their defaults)

The differenced images here are exaggerated of course, to show the pixel changes
of the jitter effect. (I also applied some sharpening in Photoshop, to show any
Moire patterns better.)

The 'automatic' use of AM3 jitter from render to render seems to work as
advertised. And with Stochastic_Seed 'on' (with some integer seed value), there
is NO pixel difference between renders, OR between rendered animation frames--
jitter is successfully turned off. That's good news for animations.

BTW, there is NO difference between two renders using AA method 2, even though
the message pane says that Jitter 1.0 is being used-- which agrees with
William's tests about previous versions of POV-ray, that NO default jitter is
applied. However, *specifying* an actual jitter value does work correctly, and
the message pane returns the correct value.  But from my own tests with this,
the method-2 render actually looks better with NO jitter (the apparent default
value.) With  Jitter_Amount=0.5, any possible Moire patterns in the render are
actually exaggerated(!), at least in conjunction with the rather 'basic' AA
values I used.

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1986 days 20 hours and 41 minutes ago]

Wed, 4 Nov 2020 15:23:46 GMT

On 11/3/20 10:43 AM, William F Pokorny wrote:
> On 11/3/20 7:29 AM, Le_Forgeron wrote:
>> Le 31/10/2020 Ã  13:23, William F Pokorny a Ã©critÂ :
>>
>> How does it interact with bokey ?
>>
...
> 
> I'll try and get back and do some bokeh renders this afternoon. Thanks 
> again for the question!
> 

Ended some time yesterday and more this morning...

---
My look at bokeh with idea of looking at AA big jitter in combination.

Basically, after quite a bit of time, I'm not quite sure what bokeh is 
doing beyond shaping somewhat the sampling pattern. Further, in all my 
testing big jitter overwhelms the bokeh effect.

If anyone has a really good example scene of bokeh usage where the 
effect is working really well, I'd be interested.  Quite a bit with that 
feature looks funky to me, but maybe I just don't understand it well 
enough? Do I not the right sort of in focus versus way out of focus set up?

Stuff that look weird:

no bokeh        -> 4289148 rays
1/3 in x white  -> 3143459 rays
All white image -> 3002417 rays
All black image -> 3282071 rays
... Why is no bokeh so much larger than any bokeh result. Do I need a 
big min samples or something? My assumption is it should still converge 
to the confidence value using up to the max samples, but within the 
shape and all white should always have more samples than black (no shape)?

The larger the user's number of samples the smaller the bokeh jitter in 
the created jitter array. This a bit like the AA jitter value shrinking 
as the recursion deepens no matter the threshold/confidence and adaptation.

Any time I try to use anything but an image_map in the pigment I get a 
core dump.

There is some unfinished code in the bokeh conditional which should 
probably be finished.

Attached is bokehShift.jpg. The sample size is set to 1 so the bokeh 
jitter values are as large as possible. On the left bokeh with a 
completely black image. On the right the completely white image. There 
is a significant shift down and to the left where the image is white (or 
visa versa). And both white and black are shifted relative to simple 
focal blur. No image for this latter lessor shift - though it is buried 
in the image bokehShift.jpg image differences.

Also attached is a second image in blurSmplOne.jpg trying to answer your 
question, Jerome, FWIW.  In the upper left focual blur at 1 sample. In 
the upper right is just "+a0.0 +am1 +r4 +j222". In the lower left corner 
both together but no bokeh. In the lower right focal blur one sample, 
jitter 222, and a bokeh pattern (image) with a vertical white stripe in 
the middle third.  There is change, but it's overwhelmed by the random 
big jitter.

Expect I could figure out more, but I'm not doing it now... And, if 
ever, I'd like to start with a good "working" example of bokeh use. Oh, 
and maybe a good description of the expected inner code behavior should 
be if that exists in someone's library?

Bill P.

[jr] Re: Playpen idea for povr -1 to 1 seed patterns. [1987 days 1 hour and 39 minutes ago]

Wed, 4 Nov 2020 10:25:01 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:
> > > I have five different v3.8 'development versions' from Github [for
> > > Windows]...The new antialias mode is not recognized in
> > > any of them
> >
> > I have never run POV-Ray on Windows but (now) wonder whether any of those five
> > versions, if installed rather than "piggybacked" onto a previous, would not work
> > "as advertised".
>
> Good question. AFAIK, no complete .exe/installable of v3.8 has yet been made for
> Windows. (I don't have the tech know-how to compile one from the source code,
> sorry to say.)

re compile from source, all versions I have installed are labelled "POV-Ray v3.x
for UNIX/Linux" (in the README/INSTALL files), so cannot comment on the Windows
thing.  however, if you were to install MS Visual Studio (there's a free edition
for non-commercial use), I'm certain people here could/would offer support for
the actual compilation/procedure.

regards, jr.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [1987 days 19 hours and 9 minutes ago]

Tue, 3 Nov 2020 16:55:01 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > I have five different v3.8 'development versions' from Github [for
> > Windows]...The new antialias mode is not recognized in
> > any of them
>
> I have never run POV-Ray on Windows but (now) wonder whether any of those five
> versions, if installed rather than "piggybacked" onto a previous, would not work
> "as advertised".
>

Good question. AFAIK, no complete .exe/installable of v3.8 has yet been made for
Windows. (I don't have the tech know-how to compile one from the source code,
sorry to say.)

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1987 days 20 hours and 21 minutes ago]

Tue, 3 Nov 2020 15:43:45 GMT

On 11/3/20 7:29 AM, Le_Forgeron wrote:
> Le 31/10/2020 Ã  13:23, William F Pokorny a Ã©critÂ :
> 
> How does it interact with bokey ?
> 
> Unclamping jitter is adding fuzziness, or it is bluriness ?
> 

I think jitter >>1  is more fuzzy than blurry, but hard to pick up a 
meaningful difference at times. Toward extremes, with everything way out 
of focus not sure there is much effective difference between wild 
sampling with focal blur and wild sampling with big jitter.

Thanks for the wonderful question! I've never used AA with focal blur... 
The latter usually being plenty of "AA." Didn't even think to "play" 
with the combination of the two features.

First to be clear my jitter changes affect only the jitter as used by AA 
methods 1 and 2. The focal blur internal jitter2d use is not changed.

Because I don't know how to use the bokeh feature, let me start with 
three initial compares in the attached image. For AA, when it is run, I 
am using +a0.0 +am1 +r4.

In the top row left is focal blur with no AA taking 7 seconds. In the 
middle top row is the same focal blur but turning on AA as above with 
jitter off. So the top row is comparing v3.8 master focal blur (7 
seconds elapsed) to focal blur with AA (2 minutes elapsed) and the 
difference at a 5x multiplier on the right.

In the middle row everything the same, except I turned on big jitter 
with +j44. Elapsed times basically the same. Differences are more 
dramatic as one might expect. I think one could say the middle column of 
the middle row now looks much more blurry/fuzzy than any of the others.

In the bottom row we have again focal blur on the left and in the bottom 
middle just AA with big jitter on at +j44 (13 seconds elapsed). Here I 
think we see that the jitter alone is more fuzzy than blurry.

I learned that AA with focal blur is much more expensive than either 
feature alone. Supposing the AA tends to mess up the convergence to 
whatever the confidence value is?

Even changing the AA threshold to a more reasonable 0.1 with jitter off 
increases the number of number of rays shot in a focal blur render:

4.2891e+06 -> 2.1576e+07 ---> 403.05%

I'll try and get back and do some bokeh renders this afternoon. Thanks 
again for the question!

Bill P.

[Le Forgeron] Re: Examples of povr random and un-clamped AA ji... [1987 days 23 hours and 35 minutes ago]

Tue, 3 Nov 2020 12:29:37 GMT

Le 31/10/2020 Ã  13:23, William F Pokorny a Ã©critÂ :
> Yesterday in povray.general I rambled long about the current state of
> jitter and related changes made to povr's AA method 1 and 2 jitter.
> Attached an image with some examples with the jitter truly random upper
> left (no much different than today's v3.8) and three images making use
> of larger +j values.
> 
> Thinking some of increasing the max allowed depth for AA method 1 to
> perhaps 20. Also of trying again my isosurface cloud renders with jitter
> values >>1.0....
> 
> Bill P.

How does it interact with bokey ?

Unclamping jitter is adding fuzziness, or it is bluriness ?

[jr] Re: Playpen idea for povr -1 to 1 seed patterns. [1988 days 19 hours and 14 minutes ago]

Mon, 2 Nov 2020 16:50:02 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > > I'm running the latest v3.8 development build in Windows ...
> Just to follow up:
> I have five different v3.8 'development versions' from Github (which run within
> v3.7.0), and I have tried them all: The new antialias mode is not recognized in
> any of them; ...

I have never run POV-Ray on Windows but (now) wonder whether any of those five
versions, if installed rather than "piggybacked" onto a previous, would not work
"as advertised".

regards, jr.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [1988 days 22 hours and 34 minutes ago]

Mon, 2 Nov 2020 13:30:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > I'm running the latest v3.8 development build in Windows [and trying to use
> > the new AA3 antialias method] but it does not accept
> > the   Antialias_Confidence=  keyword.
> > ...
> > I tried instead to use +AC0.98 on the command line, but it does not work there
> > either.
> ...
> I forgot to mention that Stochastic_Seed (or +SS) is not accepted either.
>
> It seems that v3.8 in Windows is not recognizing those terms.

Just to follow up:
I have five different v3.8 'development versions' from Github (which run within
v3.7.0), and I have tried them all: The new antialias mode is not recognized in
any of them; they all revert to method 2. It seems that this new method was
never actually implemented in these Windows development builds of 3.8x (or else
maybe in one of the versions that I haven't yet tried??) Sad news. From reading
other posts here, method 3 apparently does work in Linux compiles of the source
code. So I guess that the relevant new code *is* sitting somewhere in the 3.8
source code itself?

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1989 days 18 hours and 23 minutes ago]

Sun, 1 Nov 2020 17:41:25 GMT

On 11/1/20 9:36 AM, Cousin Ricky wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> Aside 1: Method 1 is R^2 samples max so +r20 it's only 400 samples -
>> which is much less than method 2's max of 66049.
> 
> But method 2 is adaptive, whereas method 1 is not.
> 
Mostly true. :-)

I think of method 1 as one step adaptive to max R samples in any given 
pixel when running typical AA.

I'm running with a threshold of 0.0. Samples go all the way up/down to 
the max, due R, no matter. I'm trying to force a large number of 
samples, but just large enough for an effect rather than wildly too 
large for that effect.

Bill P.

[Cousin Ricky] Re: Examples of povr random and un-clamped AA ji... [1989 days 21 hours and 24 minutes ago]

Sun, 1 Nov 2020 14:40:08 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Aside 1: Method 1 is R^2 samples max so +r20 it's only 400 samples -
> which is much less than method 2's max of 66049.

But method 2 is adaptive, whereas method 1 is not.

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1989 days 21 hours and 51 minutes ago]

Sun, 1 Nov 2020 14:12:48 GMT

On 10/31/20 12:36 PM, William F Pokorny wrote:
> 1     1     4
> 2     4     9
> 3     9     25
> 4     16     81
> 5     25     289
> 6     36     1089
> 7     49     4225
> 8     64     16641
> 9     81     66049

I should've added a new v3.8 method 3 column to the max samples per 
R(+r) setting table:

R       M1      M2         M3
-----------------------------------
1 	1 	4          4
2 	4 	9          16
3 	9 	25         64
4 	16 	81         256
5 	25 	289        1024
6 	36 	1089       4096
7 	49 	4225       16384
8 	64 	16641      65536
9 	81 	66049      262144

Bill P.

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1989 days 22 hours and 27 minutes ago]

Sun, 1 Nov 2020 13:37:19 GMT

On 10/31/20 4:20 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Thinking some of increasing the max allowed depth for AA method 1 to
>> perhaps 20. Also of trying again my isosurface cloud renders with jitter
>> values >>1.0....
> 
> Why "limit" it?
> Maybe issue a warning message that "jitter values above ## may drastically
> increase render times..."  Your extreme settings sort of look like a Gaussian
> blur effect, which some folks might find very useful for specialized purposes
> (heightfields, etc.)
> 

Storage is what I was thinking on coming up with 20.

I suppose for method 1 and 3 not much reason. Method 2 there is actual 
call recursion.

Bill P.

PS. I've wondered whether and actual gaussian/normal jitter distribution 
as an option might not be interesting. C++11 offers a set of 
distributions and there have long been some internal to POV-Ray. Method 
3 uses one of those. Someday, maybe...

[Bald Eagle] Re: Examples of povr random and un-clamped AA ji... [1990 days 15 hours and 39 minutes ago]

Sat, 31 Oct 2020 20:25:06 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Thinking some of increasing the max allowed depth for AA method 1 to
> perhaps 20. Also of trying again my isosurface cloud renders with jitter
> values >>1.0....

Why "limit" it?
Maybe issue a warning message that "jitter values above ## may drastically
increase render times..."  Your extreme settings sort of look like a Gaussian
blur effect, which some folks might find very useful for specialized purposes
(heightfields, etc.)

[William F Pokorny] Re: Examples of povr random and un-clamped AA ji... [1990 days 19 hours and 28 minutes ago]

Sat, 31 Oct 2020 16:36:11 GMT

On 10/31/20 10:40 AM, Cousin Ricky wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> Thinking some of increasing the max allowed depth for AA method 1 to
>> perhaps 20.
> 
> .... Because our renders aren't taking long enough.
> 
> 
:-) There is truth in that statement!

I've been playing most of today with "big jitter" AA. Attaching another 
image / effect I liked. This one using +a0.0 +am2 +r6 +j467

The blurring is different than low sample or 2d weighted techniques. 
Because the sampling rays continue to find the source scene, things 
don't turn to mud until the jitter distances are really, really large. 
No big surprise I guess, but it's interesting to see it in practice.

Prefix aside: There is a table in the documentation regarding the 
maximum number of samples for any given +r recursion depth. As far as I 
know it has more or less forever read:

         M1      M2

1 	1 	9
2 	4 	25
3 	9 	81
4 	16 	289
5 	25 	1089
6 	36 	4225
7 	49 	16641
8 	64 	66049
9 	81 	263169

During the recent AA work I noticed it's wrong for method 2 AA. I 
believe it should read:

1 	1 	4
2 	4 	9
3 	9 	25
4 	16 	81
5 	25 	289
6 	36 	1089
7 	49 	4225
8 	64 	16641
9 	81 	66049

Aside 1: Method 1 is R^2 samples max so +r20 it's only 400 samples - 
which is much less than method 2's max of 66049. Even the +r6 for the 
attached image used 1089. My frustration when playing with stuff like 
the isosurface clouds has been not being able to get a larger number of 
samples in a way which 'only' squares on the recursion depth.

Bill P.

[Cousin Ricky] Re: Examples of povr random and un-clamped AA ji... [1990 days 21 hours and 19 minutes ago]

Sat, 31 Oct 2020 14:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Thinking some of increasing the max allowed depth for AA method 1 to
> perhaps 20.

.... Because our renders aren't taking long enough.

[William F Pokorny] Examples of povr random and un-clamped AA jitter. [1990 days 23 hours and 41 minutes ago]

Sat, 31 Oct 2020 12:23:12 GMT

Yesterday in povray.general I rambled long about the current state of 
jitter and related changes made to povr's AA method 1 and 2 jitter. 
Attached an image with some examples with the jitter truly random upper 
left (no much different than today's v3.8) and three images making use 
of larger +j values.

Thinking some of increasing the max allowed depth for AA method 1 to 
perhaps 20. Also of trying again my isosurface cloud renders with jitter 
values >>1.0....

Bill P.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [1999 days 22 hours and 50 minutes ago]

Thu, 22 Oct 2020 13:14:13 GMT

On 10/20/20 8:22 AM, Kenneth wrote:
> I didn't think to look there --and you are correct, it is falling back to AA
> method 2, and WITH jitter(!). Thanks for the tip. It seems odd that I don't
> *see*  any animation jitter...although I'm not complaining!

Excepting it "might" mean single frame renders don't have access to the 
best AA quality. This a reason for render to render AA 'random' jitter.

Aside: I've long been carrying a feeling, a notion, an idea the am1/am2 
AA in v3.7/v3.8 is a little less good. Hard to really determine because 
of all the assumed gamma change plus now +ag2.5 mixed into the AA 
itself. Maybe jitter handling changed v3.6->v3.7 ?

Bill P.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [2001 days 23 hours and 39 minutes ago]

Tue, 20 Oct 2020 12:25:09 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> My only guess is you have a version which doesn't completely support
> method 3 AA. Did you review the render messages back to the screen?
> ...
> Asking because in regular POV-Ray specifying a mode greater than really
> supported defaults to the largest really supported. Are you seeing
> "Method 3" in the text output?
>
Running the v3.8-alpha.9811560+av591.msvc14 development build in Windows, with a
1280X960 render:

Antialiasing....on (method 2, Threshold 0.050, Depth 3, Jitter 1.00,  Gamma
2.50)
Samples:  10378994         Smpls/Pxl:  7.94

I didn't think to look there --and you are correct, it is falling back to AA
method 2, and WITH jitter(!). Thanks for the tip. It seems odd that I don't
*see* any animation jitter...although I'm not complaining!  ;-)

[off-topic]:
Strange thing: This development build that I'm currently running within v3.7.0
-- the replacement 'pvengine64' file-- came from a folder labeled
    povray-3.8.0-x.10064738-av694-Win64
(which is the name it un-Zipped to when I downloaded it.) But the version
numbers don't match.

I think I'll check out some of the other v3.8-alpha builds that I have, to see
if *any* of them will run the new  am3 AA  successfully.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [2002 days 1 hour and 39 minutes ago]

Tue, 20 Oct 2020 10:25:08 GMT

On 10/19/20 6:29 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>>
>> I forgot to mention that Stochastic_Seed (or +SS) is not accepted either, in
>> either location.
>>
>> It seems that v3.8 in Windows is not recognizing those terms. :-(
> 
> I did an animation test anyway, by simply leaving out the two terms.
> 
> my .ini file:
> [1280x960, AA special]
> Width=1280
> Height=960
> Antialias=On
> Sampling_Method=3
> Antialias_Threshold=0.05
> 
> Nothing moves in my scene, or the camera; just static animation frames. I took
> two consecutive frames into Photoshop, 'differenced' them, and exaggerated any
> possible defects. And I don't see ANY difference between the two images-- no
> out-of-place pixles at all. :-) Perhaps Stochastic_Seed is already 'on' by
> default in the Windows version(?). In any case, the renders are beautifully
> antialiased, and consistent.
> 
> Perhaps a *moving* camera might show something-- but any am3 difference from
> frame to frame would be hard to verify by itself, since everything else is
> slightly changing as well.
> 

My only guess is you have a version which doesn't completely support 
method 3 AA. Did you review the render messages back to the screen? In
the unix based versions we see something like:


   Antialiasing.........On  (Method 2, Threshold 0.100, Depth 3,
                             Jitter 1.00, Gamma 2.50)

Asking because in regular POV-Ray specifying a mode greater than really 
supported defaults to the largest really supported. Are you seeing 
"Method 3" in the text output?

---
... Maybe my thinking about am3 being better for animations due no 
jitter is bogus. Maybe even some of our thinking and documentation about 
jitter frame to frame. Seems like I used to get render to render 
differences with jitter on - it's why I forever have turned it off when 
I do image to image compares.

Trying now I - like you - cannot get a difference... There is something 
I don't understand about jitter and AA! Is it today (v3.7+) really 
random render to render? Are we getting some pre-seeded psuedo random 
jitter?

Busy the next couple of days, but need to look more at this.

Bill P.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [2002 days 13 hours and 34 minutes ago]

Mon, 19 Oct 2020 22:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> I forgot to mention that Stochastic_Seed (or +SS) is not accepted either, in
> either location.
>
> It seems that v3.8 in Windows is not recognizing those terms. :-(

I did an animation test anyway, by simply leaving out the two terms.

my .ini file:
[1280x960, AA special]
Width=1280
Height=960
Antialias=On
Sampling_Method=3
Antialias_Threshold=0.05

Nothing moves in my scene, or the camera; just static animation frames. I took
two consecutive frames into Photoshop, 'differenced' them, and exaggerated any
possible defects. And I don't see ANY difference between the two images-- no
out-of-place pixles at all. :-) Perhaps Stochastic_Seed is already 'on' by
default in the Windows version(?). In any case, the renders are beautifully
antialiased, and consistent.

Perhaps a *moving* camera might show something-- but any am3 difference from
frame to frame would be hard to verify by itself, since everything else is
slightly changing as well.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [2002 days 14 hours and 9 minutes ago]

Mon, 19 Oct 2020 21:55:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I just tried to test it, but it's throwing an error.
>
> I'm running the latest v3.8 development build in Windows, but it does not accept
> the   Antialias_Confidence=  keyword in my quickres.ini file(!)
> ...
> I tried instead to use +AC0.98 on the command line, but it does not work there
> either. I don't know what I'm doing wrong. Help!

I forgot to mention that Stochastic_Seed (or +SS) is not accepted either, in
either location.

It seems that v3.8 in Windows is not recognizing those terms. :-(  If I leave
them out completely, I AM able to render-- but without the Stochastic_Seed
mechanism, I can't do a 'thorough' animation test for possible jitter.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [2002 days 14 hours and 34 minutes ago]

Mon, 19 Oct 2020 21:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/19/20 9:15 AM, Kenneth wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >
> > If I understand this correctly, it makes me wonder if there *would* be a
> > visually noticiable jittering when using the am3 method. I guess I need to try
> > it, to see.
> >
>
> Good question! I don't believe jitter is used in am3, but I did not test
> that belief. Let us know what you find.
>

I just tried to test it, but it's throwing an error.

I'm running the latest v3.8 development build in Windows, but it does not accept
the   Antialias_Confidence=  keyword in my quickres.ini file(!)

[1280x960, AA special]
Width=1280
Height=960
Antialias=On
Sampling_Method=3
Antialias_Confidence=0.98  <------- not accepted
Antialias_Threshold=0.05

I tried instead to use +AC0.98 on the command line, but it does not work there
either. I don't know what I'm doing wrong. Help!

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [2002 days 22 hours and 9 minutes ago]

Mon, 19 Oct 2020 13:55:02 GMT

On 10/19/20 9:15 AM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> If I understand this correctly, it makes me wonder if there *would* be a
> visually noticiable jittering when using the am3 method. I guess I need to try
> it, to see.
> 
Good

Good question! I don't believe jitter is used in am3, but I did not test 
that belief. Let us know what you find.

Bill P.

[Kenneth] Re: Playpen idea for povr -1 to 1 seed patterns. [2002 days 22 hours and 44 minutes ago]

Mon, 19 Oct 2020 13:20:07 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> It's valuable here. Fed the input on the left (no AA) - there is  much
> more 'line-ish' detail below what is seen. The am3 mode came out quite a
> bit faster than am2 for equivalent threshold and depth. The fixed am3
> and confidence set at 0.98. Resulting images not identical, but very close.
>
> With the example posted, it's the best choice.

So just to be clear: The image on the left is with NO AA, and the image on the
right is with the stochastic am3 method? That looks really good.
>
>
> And should add another very good reason to keep - and use - aa method 3
> is the stochastic seed capability. This lets us get a repeatable aa
> method 1, 2 type result without the randomness of the jitter in methods
> one and two.
>

So it seems to be the best thing to use for AA in animations... although there
are two notes in the documentation:
"Conversely you can produce exactly the same output each time. See also:
Stochastic Seed."

That sounds good. But...
"Note: The jitter sequence is also affected by the actual image content, and
will thus always differ between the frames of an animation."

If I understand this correctly, it makes me wonder if there *would* be a
visually noticiable jittering when using the am3 method. I guess I need to try
it, to see.

Thanks for these tests.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [2007 days 16 hours and 59 minutes ago]

Wed, 14 Oct 2020 19:05:41 GMT

On 10/13/20 4:13 AM, William F Pokorny wrote:
> On 10/12/20 10:15 AM, William F Pokorny wrote:
...
> 
> With the example posted, it's the best choice.
> 

And should add another very good reason to keep - and use - aa method 3 
is the stochastic seed capability. This lets us get a repeatable aa 
method 1, 2 type result without the randomness of the jitter in methods 
one and two.

Bill P.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [2009 days 3 hours and 50 minutes ago]

Tue, 13 Oct 2020 08:13:51 GMT

On 10/12/20 10:15 AM, William F Pokorny wrote:
> I've been carrying this a the am3 mode really worth much over heavy am1/am2.

Argh... Should have read something like:

"I've been carrying this doubt whether the am3 mode really worth much 
over heavy am1/am2."

With the example posted, it's the best choice.

Bill P.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [2009 days 21 hours and 49 minutes ago]

Mon, 12 Oct 2020 14:15:11 GMT

On 10/11/20 2:14 PM, William F Pokorny wrote:
> While thinking of deleting the quilted value pattern, started to toy 
> with the idea of replacing it with a seed pattern having values in the 
> function_interval range of -1 to 1.
> 
...

One more. I had thought I could create another image where I scale the 
seed derived pattern very small creating a really good stress tests for 
the am3 anti-alias mode.

Since that set of cases am1,am2,am3 cases making sure there was no 
overall color shift, I've been carrying this a the am3 mode really worth 
much over heavy am1/am2.

It's valuable here. Fed the input on the left (no AA) - there is  much 
more 'line-ish' detail below what is seen. The am3 mode came out quite a 
bit faster than am2 for equivalent threshold and depth. The fixed am3 
and confidence set at 0.98. Resulting images not identical, but very close.

3 minutes 56 seconds (236.791 seconds)   am3
Pixels: 490000 Samples: 425852553 Smpls/Pxl: 869.09

5 minutes 30 seconds (330.180 seconds)   am2
Pixels: 521284 Samples: 531634923 Smpls/Pxl: 1019.86

869.09 -> 1019.9 ---> 17.35%
236.8s -> 330.2s ---> 39.44%

Bill P.

[William F Pokorny] Re: Playpen idea for povr -1 to 1 seed patterns. [2010 days and 39 minutes ago]

Mon, 12 Oct 2020 11:25:38 GMT

On 10/11/20 2:14 PM, William F Pokorny wrote:
> While thinking of deleting the quilted value pattern, started to toy 
> with the idea of replacing it with a seed pattern having values in the 
> function_interval range of -1 to 1.
> 
...
> 
> J - H again with phase +0.1 and adding some turbulence.
> 
> K - J adding the povr wave inverse wave keyword.
> 
> L - J made more turbulent. Adding a light to the scene.
> 

One more isosurface image using something similar to L to displace a 
surface.

It reminds me a little of a tunnel I once traversed. A tunnel created by 
blasting through solid rock.

Bill P.

[William F Pokorny] Playpen idea for povr -1 to 1 seed patterns. [2010 days 17 hours and 49 minutes ago]

Sun, 11 Oct 2020 18:14:51 GMT

While thinking of deleting the quilted value pattern, started to toy 
with the idea of replacing it with a seed pattern having values in the 
function_interval range of -1 to 1.

The wave shape modifiers have been extended to support +- function 
values, but to make use of them without some seed, you need to create 
functions as input.

What if we had one or more seed or base patterns aimed at being fuel for 
more complex patterns?

Idea thus far looks promising.Two images attached. One showing the 
concept from seed pattern through to more complex patterns derived from 
it. The other a larger fall color image using the technique.

A - The seed pattern on a y plane. Negative values as red and positive 
values as green. The black between the near 0 values.(using 
function_interval)

B - What is in A, but used directly in an isosurface.

C - Combining two of A in an average pigment. (function_interval)

D - Pattern of C as an isosurface.

E - C pattern (adding sine_wave along with function_interval)

F - Using E in an isosurface.

G - Adding six more rotations of A to the C average pigment.

H - G using the modified povr cubic_wave (selection) functionality.

I - H adding phase -0.1 to shift the colors toward negative red.

J - H again with phase +0.1 and adding some turbulence.

K - J adding the povr wave inverse wave keyword.

L - J made more turbulent. Adding a light to the scene.

Bill P.

[William F Pokorny] Function / pattern issues. Povr surface normal{}... [2062 days and 30 minutes ago]

Fri, 21 Aug 2020 11:34:15 GMT

<---------------------- References. Fourteen previous posts

Function / pattern issues. New inbuilt f_elliptical_sphrswp().
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee529b9%241%40news.povray.org%3E/

and

Function / pattern issues. Povr supertoroid parametric.
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee61540%241%40news.povray.org%3E/

Some time ago Bald Eagle asked about implementing normal like dents for 
isosurfaces. After implementing a supporting function f_normal(), I've 
coded up in SDL a function (inside functions.inc) called F_ndents(). It 
uses too the previously implemented inbuilt f_dents() and 
f_turbulence(). The latter with the fixed, non-drifting distribution - 
internal Turbulence() function.

To set the table, the dents pattern is one of a few which is implemented 
differently for normal{} use than it is for *map use. The former 
determines and applies a perturbation to the existing surface normal; 
the latter returns a single value which can be used with a *map, among 
other things.

F_ndents() determines the surface normal of the base isosurface shape 
function with f_normal() and perturbs that normal by f_turbulence where 
determined by the f_dents() pattern. The perturbed normal is then used 
to warp/move the effective x,y and z coordinates.

This function/shape deformation approach has advantages. The 
perturbation is only inward or outward relative to the base shape 
surface normal. Further, the deformation by perturbed normal coordinates 
doesn't ever 'fracture' the function/shape(1).

Functions where only values are used - say f_noise3d() added to the 
shape's returned function values - to roughen a surface very often do. 
Especially true where values are added to the base shape function - bits 
and pieces often end up floating above the surface.

(1) - Yep. Lying a little. If the isosurface gradient setting (or image 
resolution) isn't great enough, you can still 'see' fracturing. Further, 
the displacements, if violent enough, can turn inside out surface wise.


Attached we have 4 images using the new F_ndents(). The upper left the 
dents + turbulence is applied outward relative to the surface normal. In 
the other three images showing inward 'dents'. All at various scaling of 
f_dents() and f_turbulence(). There is too a normal like pattern value / 
bump_size value being changed to set 'dent in/out direction' and depth. 
The existing normal {dents} implementation cannot scale 'dents' and 
'turbulence' differently and so is most like the lower right corner 
result with an ability to scale larger or smaller in total.

IIRC. Upper left image took a couple minute on my i3. The rest 30 
seconds or less. One light and radiosity.

I still have in mind F_crumple() and/or F_collision() functions too - 
someday.

Aside: Playing with just a scaled f_normal() as an alternative to shape 
'value shells' might be interesting too as a well to get more normalize 
thicknesses.  I've not had time to try this thought as yet.

---
Generally. Other new functions are f_length() and f_normalized(). Also 
back tracked and added *map value support to more recently added 
functions where supporting *maps could be of use. I'd originally planned 
such *map value support for f_eblob() alone.

Bill P.

[jr] Re: Function / pattern issues. Povr supertoroid ... [2122 days 17 hours and 24 minutes ago]

Sun, 21 Jun 2020 18:40:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/21/20 5:14 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ....
> >> Dump the inbuilt benchmark. ...
> >
> > popped into my head this morning.  :-)  occurs to me that not only is having
> > this benchmark "nice", even if only for own information, it is also, in a sense,
> > a convenient and built-in 'make check' equivalent.  so I think that unless
> > there's an explicit 'make check' which exercises the build, the '--benchmark'
> > (too) ought to be kept.
>
> There is today an explicit 'make check' which uses the advanced
> directory biscuit scene(1). I'm thinking about changing 'make check' to
> something much simpler like a sphere on a checkered plane. I don't think
> there is any reason for a more complete scene for the 'make check'
> functionality.

see below.

> The current inbuilt benchmark ... Not sure where written at the moment. ...

/tmp/

> ...
> Aside: The current benchmark scene could be made more representative -
> or perhaps their should be several benchmarks. Last I profiled the
> benchmark was, time wise, 65% or more noise(NG 1) and media.

agree, as long as this, and or the 'make check', utilise a good cross-section of
the functionality, they should that and no more.


regards, jr.

[William F Pokorny] Re: Function / pattern issues. Povr supertoroid ... [2122 days 20 hours and 50 minutes ago]

Sun, 21 Jun 2020 15:13:57 GMT

On 6/21/20 5:14 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ....
>> Dump the inbuilt benchmark. ...
> 
> popped into my head this morning.  :-)  occurs to me that not only is having
> this benchmark "nice", even if only for own information, it is also, in a sense,
> a convenient and built-in 'make check' equivalent.  so I think that unless
> there's an explicit 'make check' which exercises the build, the '--benchmark'
> (too) ought to be kept.
> 

There is today an explicit 'make check' which uses the advanced 
directory biscuit scene(1). I'm thinking about changing 'make check' to 
something much simpler like a sphere on a checkered plane. I don't think 
there is any reason for a more complete scene for the 'make check' 
functionality.

(1) - Running in a mangled way for my povr compiles at present.

The current inbuilt benchmark amounts to wrappers around the scene 
directory benchmark scene and ini files. Plus, it looks to me, 4 font 
files which exist in the include directory get wrapped too. These are 
the inbuilt fonts text{} can use. I think the whole idea is to let the 
benchmark types at whatever news publication run the benchmark without 
an actual install. The wrapped/c++ encapsulated stuff gets written out 
to files for the --benchmark. Not sure where written at the moment. I've 
looked at little at the encapsulation side, but not how it actually runs.

In any case, as done it amounts to a significant duplication of files. 
Nothing really against it, other than it being something more which must 
be maintained and that it takes around 700K (6.5% of povr today) of 
source code space.

Aside: The current benchmark scene could be made more representative - 
or perhaps their should be several benchmarks. Last I profiled the 
benchmark was, time wise, 65% or more noise(NG 1) and media.

Bill P.

[jr] Re: Function / pattern issues. Povr supertoroid ... [2123 days 2 hours and 49 minutes ago]

Sun, 21 Jun 2020 09:15:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ....
> Dump the inbuilt benchmark. ...

popped into my head this morning.  :-)  occurs to me that not only is having
this benchmark "nice", even if only for own information, it is also, in a sense,
a convenient and built-in 'make check' equivalent.  so I think that unless
there's an explicit 'make check' which exercises the build, the '--benchmark'
(too) ought to be kept.

regards, jr.

[jr] Re: Function / pattern issues. Povr supertoroid ... [2127 days 1 hour and 59 minutes ago]

Wed, 17 Jun 2020 10:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
> > impossible.
>
> I don't know what that does, and that may be true with the current way
> everything functions.

say you have a number of .. knobs which change things in a scene, like having
radiosity enabled or disabled, eg
  #if (1 = Rad)
    // the radiosity stuff.
  #end

then, either on the command-line or in an .ini, you could
  declare=Rad=1
to enable radiosity for (just) that render, w/out needing to edit the scene.

can't have strings, ie 'declare=X="foo"' won't work, still, v useful.

> ...
> If there was a way that POV-Ray could read from inside of an uncompressed
> archive file, then we could tie interconnected files together so as to not
> inadvertently separate them, yet still be able to read/edit them.
> Apparently tar does this.

+1.  bundling up all project scene/inc/image/etc files in a single container,
and POV-Ray "mounting" them as virtual file systems, would be extremely neat.
(one for version 5.x.  :-))


regards, jr.

[Bald Eagle] Re: Function / pattern issues. Povr supertoroid ... [2127 days 14 hours and 34 minutes ago]

Tue, 16 Jun 2020 21:30:06 GMT

"jr" <cre### [at] gmailcom> wrote:

> that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
> impossible.

I don't know what that does, and that may be true with the current way
everything functions.

If WP is going to change things, then I see no reason why something like
CLI_settings {all your CLI / ini stuff}
couldn't serve the same purpose.
And THAT could have the same ifndef functionality where things already declared
outside of the file - in CLI or ini - would preclude redefinition in the
CLI_settings {} block.

> personally, I frequently benefit from that flexibility.

Not using that method of running POV-Ray, I'd need to see a specific use example
where a separate file would be necessary.  Like I said - maybe not necessarily
get rid of it, but complement it with an in-SDL method to accomplish the same
thing.

If there was a way that POV-Ray could read from inside of an uncompressed
archive file, then we could tie interconnected files together so as to not
inadvertently separate them, yet still be able to read/edit them.
Apparently tar does this.

https://stackoverflow.com/questions/9516365/create-a-zip-archive-without-compression
https://stackoverflow.com/questions/430973/create-zip-style-file-without-compression

[jr] Re: Function / pattern issues. Povr supertoroid ... [2127 days 17 hours and 9 minutes ago]

Tue, 16 Jun 2020 18:55:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I would much rather have a way to have everything contained in one scene file
> rather than in multiple files.

that, for example, would make (CLI or .ini) uses like 'declare=N=2' and such
impossible.  personally, I frequently benefit from that flexibility.

regards, jr.

[Bald Eagle] Re: Function / pattern issues. Povr supertoroid ... [2127 days 18 hours and 19 minutes ago]

Tue, 16 Jun 2020 17:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> I guess that you not being a user of .ini files does not help.  :-)  perhaps, as
> Bald Eagle suggested else-thread, a poll of actual and potential users, asking
> their opinion on (desired) features/functionality?

I don't use them either, except for animations, and only then because - that's
the way it works.

I would much rather have a way to have everything contained in one scene file
rather than in multiple files.  A temporary working ini file could be
constructed to run the animation and store whatever persistent stuff is needed
across all frames.

I'm also a fan of multiple ways of performing the same task.
So, leaving .ini alone, I'd say the same functionality should be available from
within the .pov file.
But I mean, that's my personal preference, and things that I expect to see in
commercial software.  And something that MS messes up on a regular basis.

I'd like to see the "command line options" capable of being invoked from within
the .pov file as well.

And, it's tough, with the way that POV-Ray is, and the way the files and
primitives are structured, and the way a scene has to be parsed and then
rendered - it limits what is possible and what is practical.

[jr] Re: Function / pattern issues. Povr supertoroid ... [2127 days 21 hours and 39 minutes ago]

Tue, 16 Jun 2020 14:25:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/15/20 7:34 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> On 6/14/20 8:48 AM, Mr wrote:
> >>> William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ...
> >> I want to get rid of the ini system and move to just flags.
> >
> > that would be a shame, I think.  personally, I find .ini files increasingly
> > useful, as they allow me to quick render the wip with just "povray name", or
> > (when it matters) "povray name[final]"; also, having multiple sections allows me
> > to render the same image with different "environments", ie library_paths, so
> > different versions of the same .inc files can be used.
>
> I'll think about this some more.

you could always just mark it as 'deprecated'.  :-)

> I don't myself use the ini system much beyond what's automatic - and the
> POVINI environment variable. My belief is in a *nux environment the
> usual shells / scripting languages and environment variables will do.
> It's how I mostly do things, but... ?

I do not use the environment variable.  initially I thought that .ini files are
useful only for animations, but have since come to appreciate them for other
uses.

you're right, I guess, that with BASH, awk, Tcl, etc, everything seems to be ..
well catered for.  still, the .ini, being "specialist" for the application, has
its place, imo.

> My thinking is losing the ini mechanism will simplify the code and
> documentation. Plus unix types are used to $PATH etc. Maybe I'm fooling
> myself though. Almost always once I get into something for real, it's
> more complicated than I imagined. :-)

I guess that you not being a user of .ini files does not help.  :-)  perhaps, as
Bald Eagle suggested else-thread, a poll of actual and potential users, asking
their opinion on (desired) features/functionality?

(there's an .ini file processing utility in tcllib1.18.  ;-))

regards, jr.

[William F Pokorny] Re: Function / pattern issues. Povr supertoroid ... [2128 days and 4 minutes ago]

Tue, 16 Jun 2020 12:00:10 GMT

On 6/15/20 7:34 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 6/14/20 8:48 AM, Mr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>>> Is there a way to play with this povr branch? I could'nt find it on github or
>>> online....
>> ...
>> I want to get rid of the ini system and move to just flags.
> 
> that would be a shame, I think.  personally, I find .ini files increasingly
> useful, as they allow me to quick render the wip with just "povray name", or
> (when it matters) "povray name[final]"; also, having multiple sections allows me
> to render the same image with different "environments", ie library_paths, so
> different versions of the same .inc files can be used.
> 

I'll think about this some more.

I don't myself use the ini system much beyond what's automatic - and the 
POVINI environment variable. My belief is in a *nux environment the 
usual shells / scripting languages and environment variables will do. 
It's how I mostly do things, but... ?

My thinking is losing the ini mechanism will simplify the code and 
documentation. Plus unix types are used to $PATH etc. Maybe I'm fooling 
myself though. Almost always once I get into something for real, it's 
more complicated than I imagined. :-)

Bill P.

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_ell... [2128 days and 25 minutes ago]

Tue, 16 Jun 2020 11:39:02 GMT

On 6/15/20 11:44 AM, Alain Martel wrote:
> Le 2020-06-15 Ã  07:07, William F Pokorny a Ã©critÂ :
...
> I see, huge gradient similar to what we can expect when using the 
> gradient or radial patterns in an isosurface.
> 

Yes, suppose similar if using POV-Ray gradient, radial and seeing the 
clamp. Povr if the normal 0-1 fmod-ish clamping is on, and your 
isosurface is catching the fmod clamping so to speak(1).

Where off in povr the gradient pattern's 'gradient', for example, is 
good/linear.

Bill P.

(1) And not using a wave modifier like triangle... It depends. General, 
simple statements/rules are hard to come by with isosurfaces. With our 
current solver low gradients being key for good performance is one. 
Gradient warnings have always been iffy, though often enough helpful.

Change a set of rays approach to an isosurface and the gradients are 
often different. Tighter bounding helps for both the usual ray misses / 
hits the bounding box reasons - and that smaller dimension(s) along the 
ray help with the 'effective' gradients.

[Mr] Re: Function / pattern issues. Povr supertoroid ... [2128 days 15 hours and 49 minutes ago]

Mon, 15 Jun 2020 20:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Not yet. I'm still changing up how things are structured while working
> on new/changed functionality. Povr will be just the core code and work
> only on unix like systems - which probably makes it of no use to you?

I could use a console version if it builds on Windows Linux and Mac
I might even try it if it builds on Linux only, but I would consider that time a
waste in the long run, if crossplatform is not a goal.

> Already much of the windows stuff is gone.

If something remains to work with.  Minimalist is no problem.

> A possibility I guess would be posting a tar ball here on the newsgroups
> in the short term which folks could build themselves.
I imagine it could be only beneficial to it.

[Alain Martel] Re: Function / pattern issues. New inbuilt f_ell... [2128 days 20 hours and 20 minutes ago]

Mon, 15 Jun 2020 15:44:46 GMT

Le 2020-06-15 Ã  07:07, William F Pokorny a Ã©critÂ :
> On 6/14/20 12:29 PM, Alain Martel wrote:
> ...
>>
>> Assuming a threshold of zero, using min(f_elliptical_sphrswp() , 1)
>> should clamp out the areas of high gradient.
>> If the threshold is, or need to be, around 1, use something like 1.5 
>> to 2 as the clamping value.
>>
> ...
> 
> That sort of clamping does sometimes work.
> 
> Here, what's happening is I'm using two functions with good/low 
> gradients. The container function is cheap to compute - a scaled torus. 
> The sweep is expensive to compute. If either is run alone there are no 
> gradient warnings - and there's a switch to turn off the torus 
> pre-filter so folks can, for example, use the sweep function with 
> pigment maps or whatever.
> 
> The problem comes on the switch from the larger containing function to 
> the elliptical sweep function. It's there that we 'generate' the larger 
> gradient values. To the overall functionality & result those 
> discontinuities don't matter.
> 
> The gradients are not matched/aligned during the switch and how much 
> misaligned isn't constant. Blending the functions would fix the gradient 
> warnings, but then I lose the performance benefit. So, at least at the 
> moment, I think I'm stuck needing to change how the gradient warnings 
> are reported or how generated.
> 
> Aside: As you and Bald Eagle suggested, it's now on my near term list to 
> try and implement 3d vector<->double encode and decode functions. I'm 
> thinking each encoded vector value at 21 bits and 1 bit, combined 
> exponent switching from a +-1.0 range to a +-10 range at 5 or 6 digits 
> of accuracy.
> 
> In working on the elliptical sphere sweep function, I got to thinking a 
> +-10 range at 5-6 digits is plenty of both range and accuracy in many 
> situations. With spline control points, for example. We'll see.
> 
> Bill P.
> 
I see, huge gradient similar to what we can expect when using the 
gradient or radial patterns in an isosurface.

[jr] Re: Function / pattern issues. Povr supertoroid ... [2129 days and 24 minutes ago]

Mon, 15 Jun 2020 11:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/14/20 8:48 AM, Mr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> > Is there a way to play with this povr branch? I could'nt find it on github or
> > online....
> ...
> I want to get rid of the ini system and move to just flags.

that would be a shame, I think.  personally, I find .ini files increasingly
useful, as they allow me to quick render the wip with just "povray name", or
(when it matters) "povray name[final]"; also, having multiple sections allows me
to render the same image with different "environments", ie library_paths, so
different versions of the same .inc files can be used.

> ...
> A possibility I guess would be posting a tar ball here on the newsgroups
> in the short term which folks could build themselves.

please do.  :-)

regards, jr.

[Bald Eagle] Re: Function / pattern issues. Povr supertoroid ... [2129 days and 34 minutes ago]

Mon, 15 Jun 2020 11:30:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Includes like
> functions.inc, math.inc etc will stay. Things like colors.inc etc and
> anything else in there not current with v38 will not be part of the core
> povr repository.

Let me just say that I'm a fan of the military mindset of "if it's detachable,
you'll lose it."
We all have some inc file that has been lost on someone's HD or only ever
existed on a now-defunct hosting site (Geocities, etc)
Things like functions and vectors and math seem so integral to the operation (at
least for me) that I'd think part of the restructuring would be to move the
externally loaded and implemented inc file code into the source where it is
always accessible and orders of magnitude faster.

> I believe even in POV-Ray we should move to a code repository model
> which is much less monolithic. A github repository for scene files, one
> for documentation, one for includes and one for the code.

For all of the ancillary material, I would vote for something:
1. easily maintained, and maintainable by several people
2. easily accessible.
      (POV-Ray already has a steep learning curve, and requiring people to then
learn git might be too much)
3. Easily indexed and cross referenced.
      (I would love a way to better search the archives for inc and scene files
based on certain topics, keywords, etc.)

Web-based searching and indexing immediately comes to mind simply because it's
so widespread and so many people can code that stuff in little time.   Not
saying that's THE way to do it - but making it compatible/friendly to that
approach would be a good thing to do from the start.

Maybe take a poll of the problems people have experienced in the past with all
manner of POV-Ray things, and use that as a guide for "Well, we certainly don't
want to do THAT again..."

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_ell... [2129 days and 57 minutes ago]

Mon, 15 Jun 2020 11:07:28 GMT

On 6/14/20 12:29 PM, Alain Martel wrote:
...
> 
> Assuming a threshold of zero, using min(f_elliptical_sphrswp() , 1)
> should clamp out the areas of high gradient.
> If the threshold is, or need to be, around 1, use something like 1.5 to 
> 2 as the clamping value.
> 
...

That sort of clamping does sometimes work.

Here, what's happening is I'm using two functions with good/low 
gradients. The container function is cheap to compute - a scaled torus. 
The sweep is expensive to compute. If either is run alone there are no 
gradient warnings - and there's a switch to turn off the torus 
pre-filter so folks can, for example, use the sweep function with 
pigment maps or whatever.

The problem comes on the switch from the larger containing function to 
the elliptical sweep function. It's there that we 'generate' the larger 
gradient values. To the overall functionality & result those 
discontinuities don't matter.

The gradients are not matched/aligned during the switch and how much 
misaligned isn't constant. Blending the functions would fix the gradient 
warnings, but then I lose the performance benefit. So, at least at the 
moment, I think I'm stuck needing to change how the gradient warnings 
are reported or how generated.

Aside: As you and Bald Eagle suggested, it's now on my near term list to 
try and implement 3d vector<->double encode and decode functions. I'm 
thinking each encoded vector value at 21 bits and 1 bit, combined 
exponent switching from a +-1.0 range to a +-10 range at 5 or 6 digits 
of accuracy.

In working on the elliptical sphere sweep function, I got to thinking a 
+-10 range at 5-6 digits is plenty of both range and accuracy in many 
situations. With spline control points, for example. We'll see.

Bill P.

[William F Pokorny] Re: Function / pattern issues. Povr supertoroid ... [2129 days 1 hour and 24 minutes ago]

Mon, 15 Jun 2020 10:40:37 GMT

On 6/14/20 8:48 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> Herein documenting better povr code for it which runs about four times
>> faster.
>>
>> The new povr code looks like:
...
> 
> Is there a way to play with this povr branch? I could'nt find it on github or
> online....
> 

Not yet. I'm still changing up how things are structured while working 
on new/changed functionality. Povr will be just the core code and work 
only on unix like systems - which probably makes it of no use to you?

Already much of the windows stuff is gone. The html documentation, scene 
fies are no longer part of povr. All the windows libraries that make the 
existing repository so large are gone.

The include directory I plan to severely prune, but I'll keep the 
include files which are closely code related. Includes like 
functions.inc, math.inc etc will stay. Things like colors.inc etc and 
anything else in there not current with v38 will not be part of the core 
povr repository.

I believe even in POV-Ray we should move to a code repository model 
which is much less monolithic. A github repository for scene files, one 
for documentation, one for includes and one for the code.

I want to get rid of the ini system and move to just flags. Dump the 
inbuilt benchmark. And much more.

Long winded way of saying I'm not yet ready to initialize a new 
repository in my own space which I could post on github.

A possibility I guess would be posting a tar ball here on the newsgroups 
in the short term which folks could build themselves.

Bill P.

[Alain Martel] Re: Function / pattern issues. New inbuilt f_ell... [2129 days 19 hours and 35 minutes ago]

Sun, 14 Jun 2020 16:29:30 GMT

Le 2020-06-13 Ã  15:32, William F Pokorny a Ã©critÂ :
> <---------------------- References. Twelve previous posts
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4b9e3%40news.povray.org%3E/

> 
> 
> and
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/

> 
> 
> 
> To povr adding new f_elliptical_sphrswp(). As Cousin_Ricky has 
> mentioned, it is not a match for an elliptical torus (supertoroid 1,1 
> asymmetric a,b), but probably something useful. See attached images.
> 
> Of note the implementation is testing out a torus pre-filter - my f_dual 
> idea to improve isosurface performance. Idea works for performance, but 
> it introduces a gradient change away from the surface so there are 
> always max gradient warnings. The actual gradient to use is always 
> around 1.0 for the sweep itself. So, need to figure out smarter max 
> gradient determination (near roots); Create a warning on/off option for 
> isosurfaces(1) - or do both.
> 

> Bill P.

Assuming a threshold of zero, using min(f_elliptical_sphrswp() , 1)
should clamp out the areas of high gradient.
If the threshold is, or need to be, around 1, use something like 1.5 to 
2 as the clamping value.

May be worth a try.

[Mr] Re: Function / pattern issues. Povr supertoroid ... [2129 days 23 hours and 14 minutes ago]

Sun, 14 Jun 2020 12:50:03 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> <---------------------- References. Thirteen previous posts
>
> Function / pattern issues. New inbuilt f_bump().
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/
>
> and
>
> Function / pattern issues. New inbuilt f_elliptical_sphrswp().
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee529b9%241%40news.povray.org%3E/
>
> I posted code to povray.text.scene-files for a parametric supertoroid
> which will run in POV-Ray proper:
>
>
http://news.povray.org/povray.text.scene-files/thread/%3C5ec01b20%241%40news.povray.org%3E/
>
> Herein documenting better povr code for it which runs about four times
> faster.
>
> The new povr code looks like:
>
> ...
> #declare Vrx  = 0.1;
> #declare Vry  = 0.1;
> #declare Vrz  = 0.1;
> #declare VrAx = 0.9/Vrx;  // Major radius in x dived by Vrx.
> #declare VrBy = 0.2/Vry;  // Major radius in y dived by Vry.
> #declare VrE1 = 1.0;  // Flat / Sharp
> #declare VrE2 = 1.0;  // Square or Diamond path
> #declare VrMajorR = max(Vrx+VrAx,Vry+VrBy,Vrz);
>
> #declare FnX = function (u,v)
> {
>      Vrx * (VrAx + f_signpow(cos(u),VrE1,VrE1)) *
>                    f_signpow(cos(v),VrE2,VrE2)
> }
> #declare FnY = function (u,v)
> {
>      Vry * (VrBy + f_signpow(cos(u),VrE1,VrE1)) *
>                    f_signpow(sin(v),VrE2,VrE2)
> }
> #declare FnZ = function (u,v) { Vrz * f_signpow(sin(u),VrE1,VrE1) }
>
> #declare Para99 = parametric {
>      function { FnX(u,v) }
>      function { FnY(u,v) }
>      function { FnZ(u,v) }
>      <-pi,-pi>, <pi,pi>
>      contained_by { box { <-VrMajorR*2.2,-VrMajorR*2.2,-VrMajorR*2.2>,
>              <VrMajorR*2.2,VrMajorR*2.2,VrMajorR*2.2> } } // Sloppy
>      accuracy 0.0005
>      max_gradient 0.001
>      precompute 18, x,y,z
>      pigment { color Green }
> }
> ...
>
> here the bounding still general. The elapsed times for each of the
> attached images was in the 2-3 second range with AA on my two core i3.
>
> It's a flexible shape.
>
> Bill P.

Is there a way to play with this povr branch? I could'nt find it on github or
online....

[William F Pokorny] Function / pattern issues. Povr supertoroid para... [2129 days 23 hours and 47 minutes ago]

Sun, 14 Jun 2020 12:17:04 GMT

<---------------------- References. Thirteen previous posts

Function / pattern issues. New inbuilt f_bump().
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/

and

Function / pattern issues. New inbuilt f_elliptical_sphrswp().
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee529b9%241%40news.povray.org%3E/

I posted code to povray.text.scene-files for a parametric supertoroid 
which will run in POV-Ray proper:

http://news.povray.org/povray.text.scene-files/thread/%3C5ec01b20%241%40news.povray.org%3E/

Herein documenting better povr code for it which runs about four times 
faster.

The new povr code looks like:

...
#declare Vrx  = 0.1;
#declare Vry  = 0.1;
#declare Vrz  = 0.1;
#declare VrAx = 0.9/Vrx;  // Major radius in x dived by Vrx.
#declare VrBy = 0.2/Vry;  // Major radius in y dived by Vry.
#declare VrE1 = 1.0;  // Flat / Sharp
#declare VrE2 = 1.0;  // Square or Diamond path
#declare VrMajorR = max(Vrx+VrAx,Vry+VrBy,Vrz);

#declare FnX = function (u,v)
{
     Vrx * (VrAx + f_signpow(cos(u),VrE1,VrE1)) *
                   f_signpow(cos(v),VrE2,VrE2)
}
#declare FnY = function (u,v)
{
     Vry * (VrBy + f_signpow(cos(u),VrE1,VrE1)) *
                   f_signpow(sin(v),VrE2,VrE2)
}
#declare FnZ = function (u,v) { Vrz * f_signpow(sin(u),VrE1,VrE1) }

#declare Para99 = parametric {
     function { FnX(u,v) }
     function { FnY(u,v) }
     function { FnZ(u,v) }
     <-pi,-pi>, <pi,pi>
     contained_by { box { <-VrMajorR*2.2,-VrMajorR*2.2,-VrMajorR*2.2>,
             <VrMajorR*2.2,VrMajorR*2.2,VrMajorR*2.2> } } // Sloppy
     accuracy 0.0005
     max_gradient 0.001
     precompute 18, x,y,z
     pigment { color Green }
}
...

here the bounding still general. The elapsed times for each of the 
attached images was in the 2-3 second range with AA on my two core i3.

It's a flexible shape.

Bill P.

[William F Pokorny] Function / pattern issues. New inbuilt f_ellipti... [2130 days 16 hours and 32 minutes ago]

Sat, 13 Jun 2020 19:32:09 GMT

<---------------------- References. Twelve previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4b9e3%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/


To povr adding new f_elliptical_sphrswp(). As Cousin_Ricky has 
mentioned, it is not a match for an elliptical torus (supertoroid 1,1 
asymmetric a,b), but probably something useful. See attached images.

Of note the implementation is testing out a torus pre-filter - my f_dual 
idea to improve isosurface performance. Idea works for performance, but 
it introduces a gradient change away from the surface so there are 
always max gradient warnings. The actual gradient to use is always 
around 1.0 for the sweep itself. So, need to figure out smarter max 
gradient determination (near roots); Create a warning on/off option for 
isosurfaces(1) - or do both.

(2) - IIRC. Megapov had a warning on/off thingy.

#declare angleStart = 153;
#declare angleArc   = -137;

#declare Iso98 = isosurface {
     function {
         f_elliptical_sphrswp(x,y,z,ax,bz,r,angleStart,angleArc,0)
     }
...

#declare Pig00 = pigment {
     function {
         f_elliptical_sphrswp(x,y,z,ax,bz,r,angleStart,angleArc,1)
      }


f_elliptical_sphrswp()
----------------------
Parameters: x, y, z

Six extra parameter required:

1. The traditional a multiplier of the x axis.

2. The traditional b multiplier of the z axis.

3. The minor radius, r.

4. The starting angle. 0 to 360.

5. The arc angle from the start angle. -360 to 360.

6. 0 = sweep with optimization. 1 = return 0 to 1 map value matched to 
angular rotation of arc.  2 = skip up front in torus filter. (e.g. Using 
sweep values for map control)

Notes. Like the f_torus() function the f_elliptical_sphrswp() sits 
around the y axis at the origin.  In other words, it is sitting in the 
x,z plane.  Angles and directional angles are left handed about y.

With respect to isosurfaces; Gradients are decent, but due the internal 
method of calculation, performance is somewhat volatile. Larger r values 
tend to run more slowly. Rays more orthogonal to the y axis are slower - 
sometimes slower than a parametric representation.

The function is close to that of an elliptical torus - supertoroid with 
e1,e2 at 1.0 (spherical) and asymmetric x,z axis values.  Also this 
method has start and end points - arcs - there is less continuity / 
smoothness at the cap spheres than elsewhere in each arc.

Bill P.

[William F Pokorny] Function / pattern issues. New inbuilt f_bump(). [2130 days 22 hours and 2 minutes ago]

Sat, 13 Jun 2020 14:01:47 GMT

<---------------------- References. Eleven previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ec3f269%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4b9e3%40news.povray.org%3E/

In povr adding a new helper function in f_bump(). Not meant to be run 
stand alone but rather to bump (displace) a surface - or field - using a 
base function. In the attached image 4 examples displacing the surface 
of a plane where the base function is a cylinder. The bottom row a 
displacement on a sphere on left and a displacement of a 'field' 
provided by the torus to create the inner shape.

...
#declare Fn01r = function (x,y,z) { sqrt(x*x+z*z) }
#declare Fn01 = function (x,y,z) {
     y - f_bump(Fn01r(x*5,y,z*1),8,0)*0.5
}
#declare Iso99 = isosurface {
     function { Fn01(x,y,z) }
...


f_bump()
--------
Parameters:

1. Input value as provided by a base function.

2. Power of 2.0 exponent integer multiplier. For the typical rounded 
dome use 1.0. Higher values tend to square off or sharpen the result. Up 
to 20 usually OK.

3. If 0, the value is returned straight up which means the maximum value 
is ~= 0.3679.  If 1, return value is normalized to 0 to 1 range. If 2, 
the return value is normalized to a -1 to 0 range or a 0 to 1 range 
depending upon input polarity.

Notes. The bump function 'bumps' values > -1 and < 1. Other input values 
are ignored.


Bill P.

[William F Pokorny] Function / pattern issues. New inbuilt f_turbule... [2131 days and 29 minutes ago]

Sat, 13 Jun 2020 11:34:59 GMT

<---------------------- References. Ten previous posts

Function / pattern issues. Updated f_ellipsoid(). New f_lame,...
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ebe9706%241%40news.povray.org%3E/

and

Function / pattern issues. New inbuilt f_morph2to9fncts().
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ec3f269%241%40news.povray.org%3E/

To povr adding an inbuilt f_turbulence() to make available the internal, 
fixed, non-drifting distribution Brownian motion functionality. Attached 
images show the three noise generator distributions and a couple 
isosurface examples.

...
#declare Iso99 = isosurface {
   function { y-f_turbulence(
                  f_gradient(x,y,z,-1,0,+1)*3,
                  y,
                  f_gradient(x,y,z,+1,0,-1)/3,0,2,0.01,0,1,4,0.5,1.7)
               +f_turbulence(
                  f_gradient(x,y,z,-1,0,-1)/3,
                  y,
                  f_gradient(x,y,z,+1,0,+1)*3,0,2,0.01,0,1,4,0.5,1.7)
               -f_turbulence(x/3,y,z*3,0,2,0.01,0,1,4,0.5,1.7)
               +f_turbulence(x*3,y,z/3,0,2,0.01,0,1,4,0.5,1.7)
   }
...


f_turbulence()
--------------

Parameters: x, y, z

8 extra parameter required:

1. 0,1 or 2 for x, y or z result.

2. The noise generator to use. Valid values 1-3.

3. Scale returned internal turbulence() value for magnitude / (frequency 
for fmod inputs).  Using 1.0 results in no scaling. This operation is 
the last performed before returning.

4. Normalization.

    0 - None. Distribution will be centered at 0.0 with deviation 
depending upon turbulence settings of octaves, omega and lambda.

    1 - Adjust to 0 to 1, 0.5 centered distribution. Not clamped. If the 
passed deviation value not 'large enough' values can go outside the 0 to 
1 range. See (3).

    2 - Adjust to -1 to +1, 0.0 centered distribution. Not clamped. See 
(2,4).

    3 - Basically (1) with hard clamping such that values below 0 are at 
0 and values larger than 1 are at 1.

    4 - Basically (2) with hard clamping such that values below -1 are 
at -1 and values larger than +1 are at +1.

    5,7 - triangle, cycloidal to  0 to +1 range, respectively.

    6,8 - triangle, cycloidal to -1 to +1 range, respectively.

5. Deviation. With default turbulence controls this will be 1 - and 
often less practically.  This value should be the deviation as returned 
from turbulence(), ahead of any distribution adjustments. The value 
passed only used if (4) has a 1-4 value.

6. Number of octaves for the turbulence call. Pattern version defaults to 6.

7. Omega value for the turbulence call. Pattern version defaults to 0.5.

8. Lambda value for the turbulence call. Pattern version defaults to 2.0.

Notes. (1) above provides for a method to get three substantially 
different values about any given point in space. In other words, a way - 
for example - to get a vector turbulence with three calls, one each for 
x,y,z.


Bill P.

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_aga... [2138 days 22 hours and 54 minutes ago]

Fri, 5 Jun 2020 13:10:02 GMT

On 6/5/20 6:43 AM, William F Pokorny wrote:
> ...
> Similar. For agate most of the impact looks to me to be from:
> 
> static inline const ClassicTurbulence *GetTurb(const WarpList warps)
> {
>      POV_PATTERN_ASSERT(!warps.empty());
>      POV_PATTERN_ASSERT(dynamic_cast<const 
> ClassicTurbulence*>(*warps.begin()));
>      return static_cast<const ClassicTurbulence*>(*warps.begin());
> }
> 
...

Couple coffees and now wondering if some of what I see is just that I 
have that pattern assert on...

In any case, my plan is to slowly remove the special turbulence 
handling. If I remember, I'll look at agate vs f_agate performance again 
when I get back to pattern cleanup work again. Focused elsewhere at the 
moment.

Bill P.

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_aga... [2139 days 1 hour and 21 minutes ago]

Fri, 5 Jun 2020 10:43:03 GMT

On 6/4/20 5:06 PM, Thorsten Froehlich wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>>
>> A significant part of the performance degrade in the normal agate
>> pattern looks to be due the use of a dynamic_cast(1) while it checks
>> which turbulence warp exists / is the internal agate one. So, other
>> special turbulence patterns likely have this slow down too - though I've
>> not tested them.
> 
> You mean this train wreck of a C++ function that is abusing dynamic cast for a
> type check?
> 
> bool AgatePattern::Precompute()
> {
>      return (!warps.empty() && dynamic_cast<ClassicTurbulence*>(*warps.begin()));
> }
> 
...
Similar. For agate most of the impact looks to me to be from:

static inline const ClassicTurbulence *GetTurb(const WarpList warps)
{
     POV_PATTERN_ASSERT(!warps.empty());
     POV_PATTERN_ASSERT(dynamic_cast<const 
ClassicTurbulence*>(*warps.begin()));
     return static_cast<const ClassicTurbulence*>(*warps.begin());
}

as it gets called - or probably 'run' as it's inlined - each time the 
agate pattern is evaluated at a point.

After a couple times finding dynamic_cast to be big performance hits, 
Christoph took a pass removing them from the ray tracing paths, leaving 
the majority of uses in the parsing code. But, some still exist in other 
than the parser. In the csg code there is still a cluster of them as I 
recall.

Bill P.

[Thorsten Froehlich] Re: Function / pattern issues. New inbuilt f_aga... [2139 days 14 hours and 54 minutes ago]

Thu, 4 Jun 2020 21:10:05 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/7/20 9:45 PM, William F Pokorny wrote:
> ...
> > In a surprise, I expected f_agate() to be a little slower than the
> > inbuilt used as a pattern in a pigment, for example. It's running about
> > 16% faster for reasons not currently understood. This the first pattern
> > where - other than f_dents which is cheap - the inbuilt function
> > implementation can match the pattern one exactly. (My f_granite23
> > inbuilt doesn't match granite.) A mystery for another day.
> ...
>
> A significant part of the performance degrade in the normal agate
> pattern looks to be due the use of a dynamic_cast(1) while it checks
> which turbulence warp exists / is the internal agate one. So, other
> special turbulence patterns likely have this slow down too - though I've
> not tested them.

You mean this train wreck of a C++ function that is abusing dynamic cast for a
type check?

bool AgatePattern::Precompute()
{
    return (!warps.empty() && dynamic_cast<ClassicTurbulence*>(*warps.begin()));
}

Oh hell, if the remaining code was turned into such a pile of junk :-( :-( :-(

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_aga... [2140 days 17 hours and 34 minutes ago]

Wed, 3 Jun 2020 18:30:09 GMT

On 5/7/20 9:45 PM, William F Pokorny wrote:
...
> In a surprise, I expected f_agate() to be a little slower than the 
> inbuilt used as a pattern in a pigment, for example. It's running about 
> 16% faster for reasons not currently understood. This the first pattern 
> where - other than f_dents which is cheap - the inbuilt function 
> implementation can match the pattern one exactly. (My f_granite23 
> inbuilt doesn't match granite.) A mystery for another day.
...

A significant part of the performance degrade in the normal agate 
pattern looks to be due the use of a dynamic_cast(1) while it checks 
which turbulence warp exists / is the internal agate one. So, other 
special turbulence patterns likely have this slow down too - though I've 
not tested them.

In povr I'm now on the path of creating a set of it_ prefix turbulence 
keywords and have this going for fog. Plan to move all the special 
turbulence to these over time and move the special turbulence storage 
out of the warp list into whatever. The it_ stands for (i)nternal 
(t)urbulence. What I'm working with currently is:

it_depth      - Scaling by value along ray or other single vector.

it_frequency  - Multiplying the turbulence returned value(s). In action 
                  it's a synonym for it_magnitude, butthe result is used 
for a pattern map, or similar. Meaning the value(s) will see some form 
of fmod() resulting in a frequency of repetitions through the map - or 
whatever.

it_lambda     - Violence of each step(2.0).

it_magnitude  - Synonym for it_frequency in action, but better
description when thinking about vector turbulence and we are changing 
              the magnitude of the returned DTurbulence vectors.

it_octaves    - Integer. Number of iterations 1 to 10?.

it_omega      - Dampening factor (0.5)

it_scale      - Multiplies input coordinates before turbulence 
generated.  Internally x|y|z/<float(s)>. The fog turbulence 3d vector is 
really acting as a 3d inverse scale.it_translate  - Moves from input 
location before turbulence generated.  Internally x|y|z - floats(s)

Today we have ambiguity with just turbulence <vector>. In straight 
turbulence it means it_magnitude. In fog - POV-Ray proper - it means 
it_scale(2). In other places it means wave modification frequency 
multiplication because of what the magnitude multiplication sees post 
value(s) multiplication. Trying to make each sort explicit over time.

Bill P.

(1) - We've hit similar issues before with dynamic_cast. It's really, 
really slow.

(2) - Frequency scaling is missing from our pattern 'magnitude' 
turbulence today which is why you see people do things like:

scale 5/1  // scaling the whole mess up.
warp { turbulence... }
scale 1/5 // scaling the whole mess back down.

[William F Pokorny] Re: v3.8 Isosurface artefacts test case. Windows... [2140 days 17 hours and 54 minutes ago]

Wed, 3 Jun 2020 18:10:03 GMT

On 10/12/19 1:57 PM, William F Pokorny wrote:
...
> I have a first pass f_npmod() and pattern.cpp updates. Tested creating 
> isosurface 'sheets' from all 27 tiling patterns. 15 of those originally 
> hit the mod()/fmod() jump to zero issue. My initial code cleaned up all 
> but 6 of those. 4 of those 6 had other numerical issues in the tiling 
> code like not clamping to 1.0 where the old 1.00001 fmod allowed the 
> tiny overrun.
> 
> I'm left with two tiling patterns still an issue in tilings 19 and 20.
> 
> I'm attaching an image for 20 showing the initial pattern.cpp 'mod' 
> fixes and new f_mpmod function. These partly fixed issues in 19 and 20 
> as seen left to right - but there is still something wrong. It looks 
> like an incorrect count in x or similar at the isosurface z sides is 
> part of it, but I've not found the problem(s).
...

Following up. The last issues with 19 and 20 were me not getting the 
scaling for repetition right. I'd cut those two patterns in half on one 
axis.

All tiling patterns now clean for me in isosurface use.

Bill P.

[William F Pokorny] Function / pattern issues. New inbuilt f_morph2t... [2155 days 21 hours and 13 minutes ago]

Tue, 19 May 2020 14:51:21 GMT

<---------------------- References. Nine previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5eb4b9c6%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ebe9706%241%40news.povray.org%3E/


Adding the function f_morph2to9fncts() to be able to set up complex 
morph-able shapes. In the attached image, set up 9 torus shapes and then 
started twiddling. Shapes just sort of happen unless you plan ahead for 
some specific morph-able thing.

#declare VrR = 0.05;
#declare Fn00 = function (x,y,z) {
     f_morph2to9fncts(9,-VrR,+VrR/9,
         f_torus(y+0.0,x+0.2,z+0.0,0.5,VrR),
         f_torus(y+0.0,x/5-0.0,z,0.5,VrR),
         f_torus(y-0.0,x-0.2,z-0.0,0.5,VrR),
             f_torus(x+0.2,y+0.0,z+0.0,0.5,VrR),
             f_torus(x+0.0,y/5-0.0,z,0.5,VrR),
             f_torus(x-0.2,y-0.0,z-0.0,0.5,VrR),
                 f_torus(x+0.0,z+0.2,y+0.0,0.5,VrR),
                 f_torus(x+0.0,z/5+0.0,y,0.5,VrR),
                 f_torus(x-0.0,z-0.2,y-0.0,0.5,VrR),
    1/9,2/9,1/9,
    0/9,1/9,0/9,
    1/9,2/9,1/9
    )
}
#declare Persimmon = srgb <0.92549,0.3451,0>;
#declare Iso99 = isosurface {
     function { Fn00(x,y,z) }
...

A whole bunch of knobs / parameters.

---- f_morph2to9fncts
Parameters:

1. Count of value inputs from 2 to 9.

2. Clamp on how negative any given function contribution can be.

3. Clamp on how positive any given function contribution can be.  This 
one more important than (2) because letting any given function's 
positive, outside the shape, values get too large really limits what can 
be accomplished with respect to morphing. In fact, internal to 
f_morph2to9fncts(), the value specified is modified to be 
value/non-zero-weights. In other words, it's normalized at start.

4-12. Input values (function calls) as parameters.

13-21. Weights as portion of the sum of all weights.

Notes. Sums and averages input values according to the weights.  Can 
morph in place or along a gradient. The math to control the morphing - 
set the weights - done outside this function. The weights themselves can 
be set up as 1/function-count or similar. Internally, they get totaled 
and the particular functions contribution is its weight against the total.

A good starting place with the negative and positive clamp values is -1 
and 1 unless you know the max negative values with the torus minor 
radius for example in which case start with +- that value.  If too many 
shapes, or too much of some shapes are disappearing lower the positive 
clamp some more. You can of course set the clamps to large values to 
avoid clamping altogether - most used when morphing from one shape to 
another.

----

In other news; added some other lessor helper functions and pattern 
implementations.

f_cbrt(), f_hypot(), f_onion(), f_sign(), f_sign0(), f_signpow()
and f_signsqrt().

Lastly, The isosurface in the image is intentionally implemented with a
large accuracy, and with the new jitter on, for effect. You can get some
interesting shapes this way (sometimes by accident...).

Bill P.

[William F Pokorny] Function / pattern issues. Updated f_ellipsoid()... [2159 days 22 hours and 44 minutes ago]

Fri, 15 May 2020 13:20:06 GMT

<---------------------- References. Eight previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ead9027%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5eb4b9c6%241%40news.povray.org%3E/

Updating the inbuilt f_ellipsoid() function. Adding new f_lame() and 
f_polyhedron() functions.

The f_ellipsoid function was one of those with it's threshold / roots up 
a 1.0. It also specified the scaling as inverse values. It's now a 0.0 
centered ellipsoid function with expected a,b,c scaling. Also brought 
out the exponential value to get some superellipsoid functionality on 
the cheap. Two of the latter sort of super forms shown in the top two 
rows of the attached image.

The new f_lame (1) and f_polyhedron functions are ways to create n faced 
objects by passing in axis aligned gradients (and/or using x,y,z). The 
latter is a subset of the former's result, but faster if you only want 
flat faces. Results from f_polyhedron in the lower left and f_lame in 
the lower right of the attached image with the same 5 input gradients.

(1) Yes the e should be accented in f_lame, but wimped out on having 
that character in the code. Interesting to me is LamÃ©'s work seems to be 
underneath a lot of the super__oid stuff.

In other than the f_polyhedron implementation, I'm also playing with the 
ability for the user to specify additional internal sqrt()s to reduce 
the gradients. So long as the equations set up as "<calculated> - 1.0 = 
0.0" this works well in my testing. It becomes another performance trade 
off used over just increasing the gradient. As important, it's a method 
to bring the gradients down toward 1.0 where the inbuilt function values 
play well with other functions and patterns.

------- f_ellipsoid
Parameters: x, y, z
Five extra parameters required:

1. If 0, calculations are done with double floats. Otherwise with single 
floats. The latter often a lot faster with not much loss in accuracy.

2. x scale

3. y scale

4. z scale

5. The pow() exponent to use. For a proper ellipsoid use 2.0. For an 
octahedron use 1.0. For an inward curvature from axises use values < 
1.0. For Rounded box to round use values >2.0. The exponent here not 
locked at 2.0 offers a subset of results like that of the superellipsoid 
at less compute expense.

6. The number of times to take the sqrt() internally to reduce the 
gradient.  1 a good starting point. Usually more than 2 not worth it. 0 
for very round results works fine.

Notes. Previously f_ellipsoid() only worked for isosurfaces of threshold 
1.0 and the axis scaling was inverted. In other words, it was not a 
general function thought relatively fast. Changed in povr May 14, 2020 
to align with standard root/threshold behavior.  Further, extended to 
pass exponent as this enables some f_superellipsoid results at a much 
lower compute cost.

---------- f_polyhedron
Parameters: x, y, z as x, y z or passed f_gradient()s on arbitrary 
axises. 13 parameters required:

1. Count of input gradients. 3 to use only x,y,z.

2-13. Up to 12 input axis gradients. See f_gradient function, but any 
value input method allowed.

Notes. When using x,y,z or f_gradient() the gradients are projected onto 
normalized input vectors. This is useful because it often allows for 
some normalization of the scaling.

#declare normScale = 3/(2*<additional_gradients>)
f_polyhedron(x*normScale,y,z*normScale,5,
              f_gradient(-1,0,1)*normScale,0,0,0,
              0,0,0,0,
              0,0,0,0)

------------ f_lame
Parameters:
1. Number of input gradients.

2. If 0 does calculations as doubles, otherwise as floats for 
performance less accuracy.  Here whether floats help depends a lot of 
the exponents. Mixed 0.6 to 1.6 on 5 gradients 31.019 -> 28.882 ---> 
-6.89% going to single floats.

3. The number of times to take the sqrt() internally to reduce the 
gradient.  Using 1 a good starting point. Usually more than 2 not worth 
it. 0 for very round results works fine.

4-11. One to eight input gradient values.

12-19. One to eight matching pow() exponent values.

Notes. If all exponents ==1, look at more efficient f_polyhedron 
alternative. Generally if exponents are <1.0 introduces an inward / 
concave curvature. If 1, flat faces, If >1 outward / convex curvature. 
See f_polyhedron comments on normalized scaling with x,y,z projects onto 
normalized vectors.

----------------- Code snipets
#declare Iso99 = isosurface {
     function { f_ellipsoid(x,y,z,1,0.3,0.9,0.6,4.4,1) }
....

#declare nrmScl = 3/7;
#declare Iso99 = isosurface {
     function { f_polyhedron(x*nrmScl,y*2,z*nrmScl,5,
             f_gradient(x,y*2,z,-1,0,-1)*nrmScl,
             f_gradient(x,y*2,z,-1,0,+1)*nrmScl,0,0,
             0,0,0,0,
             0,0,0,0)
     }

#declare nrmScl = 3/7;
#declare Iso99 = isosurface {
     function { f_lame(5,1,2,
             x*nrmScl,y*2,z*nrmScl,
             f_gradient(x,y*2,z,-1,0,-1)*nrmScl,
             f_gradient(x,y*2,z,-1,0,+1)*nrmScl,0,0,0,
             0.7,1.0,1.3,1.6,0.6,0,0,0)
     }

Lastly, not sure I've anywhere mentioned adding the povr f_gradient() 
inbuilt used here. It replaces the three, fixed axis, pattern wrapped 
ones in functions.inc with one which has 3 additional parameters to 
specify the axis onto which to project (now like the pattern version). 
Opens up another transform-ish like capability for all functions; though 
admit it's a new knob where I've not played much yet.

Bill P.

[William F Pokorny] Re: Function / pattern issues. New inbuilt f_aga... [2167 days 1 hour and 47 minutes ago]

Fri, 8 May 2020 10:16:58 GMT

On 5/7/20 10:23 PM, Alain Martel wrote:
...
> 
> Those looks like a slightly turbulent quilted pattern. Especially the 
> top example.

I agree. :-) You can take the f_agate turbulence to 0.0 and get clean 
lines (or grids) making it look similar to other patterns(1). Suppose on 
some level the underlying driving variables - dimensions - are always 
there.

An f_quilted() inbuilt on my list. It's got better control of the shape 
of both extremes in value. With it I'm thinking of adding options which 
run in x, y and z only. Maybe adding turbulence as an internal option 
makes sense too...

Bill P.

(1) And the agate oriented dimension 'greys out.'

[Alain Martel] Re: Function / pattern issues. New inbuilt f_aga... [2167 days 9 hours and 41 minutes ago]

Fri, 8 May 2020 02:23:21 GMT

Le 2020-05-07 Ã  21:45, William F Pokorny a Ã©critÂ :
> <---------------------- References. Seven previous posts
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ea57285%241%40news.povray.org%3E/

> 
> 
> and
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ead9027%40news.povray.org%3E/

> 
> 
> Replacing the f_agate simple pattern{} wrap in functions.inc with a new 
> inbuilt f_agate which brings out the x,y,z directions and power exponent 
> as parameters in addition to parameters for the turbulence call's 
> octaves, omega and lambda.
> 
> Parameters: x, y, z
> 7 extra parameter required:
> ---
> 1. 0,1 or 2 for x, y or z agate alignment. Pattern's agate always uses z 
> (2).
> 
> 2. Turbulence multiplier. Called agate_turb in the pattern version. (1.0).
> 
> 3. Power exponent for pow(). Hard coded to 0.77 in the pattern version. 
> (0.77)
> 
> 4. Number of octaves for the turbulence call. Pattern version defaults 
> to (6).
> 
> 5. Omega value for the turbulence call. Pattern version defaults to 0.5.
> 
> 6. Lambda value for the turbulence call. Pattern version defaults to 2.0.
> 
> 7. The noise generator to use. Valid values 1-3. Pattern agate uses 
> pattern or global setting.
> 
> Notes. To match the default pattern agate: 
> f_agate(x,y,z,2,1.0,0.77,6,0.5,2.0,2)Â  <-- Matches pattern agate when 
> everything defaulted.Â  With the pattern agate octaves, omega and lambda 
> can be set with those bare keywords immediately after agate changing 
> agate's inbuilt turbulence.
> 
> For the bottom of the attached image creating an isosurface using both 
> the non-preferred directions looks like:
> 
> #declare Iso99 = isosurface {
>  Â Â Â  function {
y+f_agate(x*2,y*2,z*2,0,0.08,0.20,6,0.5,2.0,2)*0.135
> 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
+f_agate(x*2,y*2,z*2,2,0.08,0.20,6,0.5,2.0,2)*0.135
>  Â Â Â  }
> ...
> 
> On the top of the image subtracted both f_agate()s at multiplier of 0.035.
> 
> In a surprise, I expected f_agate() to be a little slower than the 
> inbuilt used as a pattern in a pigment, for example. It's running about 
> 16% faster for reasons not currently understood. This the first pattern 
> where - other than f_dents which is cheap - the inbuilt function 
> implementation can match the pattern one exactly. (My f_granite23 
> inbuilt doesn't match granite.) A mystery for another day.
> 
> Bill P.

Those looks like a slightly turbulent quilted pattern. Especially the 
top example.

[William F Pokorny] Function / pattern issues. New inbuilt f_agate(). [2167 days 10 hours and 19 minutes ago]

Fri, 8 May 2020 01:45:42 GMT

<---------------------- References. Seven previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ea57285%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ead9027%40news.povray.org%3E/

Replacing the f_agate simple pattern{} wrap in functions.inc with a new
inbuilt f_agate which brings out the x,y,z directions and power exponent
as parameters in addition to parameters for the turbulence call's
octaves, omega and lambda.

Parameters: x, y, z
7 extra parameter required:
---
1. 0,1 or 2 for x, y or z agate alignment. Pattern's agate always uses z
(2).

2. Turbulence multiplier. Called agate_turb in the pattern version. (1.0).

3. Power exponent for pow(). Hard coded to 0.77 in the pattern version.
(0.77)

4. Number of octaves for the turbulence call. Pattern version defaults
to (6).

5. Omega value for the turbulence call. Pattern version defaults to 0.5.

6. Lambda value for the turbulence call. Pattern version defaults to 2.0.

7. The noise generator to use. Valid values 1-3. Pattern agate uses
pattern or global setting.

Notes. To match the default pattern agate:
f_agate(x,y,z,2,1.0,0.77,6,0.5,2.0,2) <-- Matches pattern agate when
everything defaulted. With the pattern agate octaves, omega and lambda
can be set with those bare keywords immediately after agate changing
agate's inbuilt turbulence.

For the bottom of the attached image creating an isosurface using both
the non-preferred directions looks like:

#declare Iso99 = isosurface {
function { y+f_agate(x*2,y*2,z*2,0,0.08,0.20,6,0.5,2.0,2)*0.135
+f_agate(x*2,y*2,z*2,2,0.08,0.20,6,0.5,2.0,2)*0.135
}
...

On the top of the image subtracted both f_agate()s at multiplier of 0.035.

In a surprise, I expected f_agate() to be a little slower than the
inbuilt used as a pattern in a pigment, for example. It's running about
16% faster for reasons not currently understood. This the first pattern
where - other than f_dents which is cheap - the inbuilt function
implementation can match the pattern one exactly. (My f_granite23
inbuilt doesn't match granite.) A mystery for another day.

Bill P.

[Bald Eagle] Re: Function / pattern issues. New f_repeat(). [2171 days and 59 minutes ago]

Mon, 4 May 2020 11:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps such a mechanism could be extended to vector handling too as a
> way to pass (return?) vectors directly. Large sets of origin and
> direction vectors for use in cameras or whatever???

I was thinking about this, and we already have the internal pigment patterns
defined by functions.   You input a color_map, and presumably output a color
vector (rgbft?), but then have to choose a dot notation scalar component to pass
the result into another normal function. .r .g. b. f. t. .gray .hf

So maybe most of the mechanism is already lurking in there somewhere.

(It would also be SO much nicer to not need the (x,y,z) for plain-vanilla
functions - have it be optional/assumed.   It would save a lot of screen space
and redundant typing.)

Again, I haven't looked at the code, but if .gray and .hf are computed
internally, presumably without much extra code, then if a function can
"internally" output an rgb vector that can be operated upon to get a scalar
grayscale value, why then can we not say that .temp = .x, .x = .y, .y =. z. and
..z = .temp in order to swizzle on the fly in the compiled code?

Really just curious.  I conceived how to do it in SDL, but at that point I'm
probably using for something that may already be slow...  ;)

[William F Pokorny] Re: Function / pattern issues. New f_repeat(). [2171 days 4 hours and 29 minutes ago]

Mon, 4 May 2020 07:35:45 GMT

On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 Ã  11:22, William F Pokorny a Ã©critÂ :
...
> 
> Why not use :
...

Something else your question has me again thinking about; I'd really 
like to get to where we can pass a set/collection of user defined 
function pointers to inbuilt functions.

Would allow delayed evaluations, but as important, very rapid 
re-evaluations of functions to do whatever larger task. Density 
functions (AKA proximtiy), for example, on functions used in isosurfaces 
or functions acting as stand-ins for equivalent shapes.

On some level these are just double values acting as pointers, but 
letting users (me...) twiddle with such pointer values at all directly 
is asking for boom, crash, bang!

Been thinking about some new, SDL exposed, mechanism which lets users 
register functions / objects by name for later in inbuilt function use. 
A very rough idea at this point.

Perhaps such a mechanism could be extended to vector handling too as a 
way to pass (return?) vectors directly. Large sets of origin and 
direction vectors for use in cameras or whatever???

Thinking about 'bank' as a SDL name for it, but...?

Underneath expect a global C++ map of some sort. un-def/re-def mechanism 
would need to be updated to check whether the existing name is in the 
bank - and fail during parsing if so. We'd want what goes in the bank to 
be a defined once thing even if we perhaps allow value updates.

Yeah, how to handle function parameters not just x,y,z... Don't know, 
and guess I'm thinking aloud and should stop.

Bill P.

[William F Pokorny] Re: Function / pattern issues. New f_repeat(). [2171 days 17 hours and 48 minutes ago]

Sun, 3 May 2020 18:16:45 GMT

On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 Ã  11:22, William F Pokorny a Ã©critÂ :
...
> 
> Why not use :
> 2 Count in X, Y, Z as a vector <X, Y, Z>
> 3 Delta as vector <X, Y, Z>
> 4, 5, 6 Individual directions. Allow for non-orthogonal patterns.
> 7 Cell pattern offset vector <X, Y, Z>
> 
> The later one may also be split in 3 to allow for more variation.

In use folks would define things with a vector, but you cannot pass 
vectors to functions - even with the v.x like syntax. Which is kinda a 
pain.

This latter behavior is I expect related to noticing recently the parser 
does not fix parameter constants on calls even when everything is known 
to the parser when a function call is defined(1).

It might be the parser is allowing for re-definitions before actually 
rendering given the parser generally allows this. But a guess. I don't 
really know why the interface is set up as it is(2).

Bill P.

(1) In other words it saves render time to do

#declare actualParam2 = ABC+XYZ*2.345;

function { FN00(x,y,z,actualParam2) }

if ABC and XYZ are known, rather than to calculated it on call in the 
parameter position. Doing it this later, more concise, way gets 
calculated on every call (at least where I've noticed and looked).

(2) - Might take a look at the parser interface handling at some point, 
but for now just trying to get a bunch of fixes and functionality in 
place with patterns/functions and the interplay between them. Once 
enough is there I can better test the form for how I think the whole of 
it should work by trying to do more complex isosurfaces. (All, perhaps, 
how things were intended to work given the code architecture in place)

[Alain Martel] Re: Function / pattern issues. New f_repeat(). [2171 days 19 hours and 50 minutes ago]

Sun, 3 May 2020 16:14:43 GMT

Le 2020-05-02 Ã  11:22, William F Pokorny a Ã©critÂ :
> <---------------------- References. Six previous posts
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5e9cce19%40news.povray.org%3E/

> 
> 
> and
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ea57285%241%40news.povray.org%3E/

> 
> 
> ---
> In povr have implemented a new f_repeat() function which is like the 
> existing repeat warp in some respects, but mostly implements some 
> SDL/TCL functionality I've had in my toolbox for a while as an inbuilt 
> function with the significant improvement of embedding the cells like 
> pattern mapping so it need not be calculated and maintained apart.
> 
> My toolbox has a bunch of other half done stuff too, but thinking to 
> pile it all in one function likely to get sluggish, so leaving that for 
> probably another version - f_repeatMoreAndSlower() - or something. :-)
> 
> Parameters: x, y, z
> Thirteen extra parameter required:
> 1.Â  If 0, return new x.
>  Â Â Â  If 1, return new y.
>  Â Â Â  If 2, return new z.
>  Â Â Â  If 3, return matched cells pattern
valueÂ  0 to 1 interval.
>  Â Â Â  If 4, return matched cells pattern value -1 to
1 interval.
> 2.Â  Count in x.
> 3.Â  Count in y.
> 4.Â  Count in z.
> 5.Â  Delta in x.
> 6.Â  Delta in y.
> 7.Â  Delta in z.
> 
> Direction. If 0, count applied +-. If <0, count applied - only. If >0, 
> count
> applied + only.
> 
> 8.Â  Direction in x.
> 9.Â  Direction in y.
> 10. Direction in z.
> 11. Cells pattern offset in x.
> 12. Cells pattern offset in y.
> 13. Cells pattern offset in z.
> 

Why not use :
2 Count in X, Y, Z as a vector <X, Y, Z>
3 Delta as vector <X, Y, Z>
4, 5, 6 Individual directions. Allow for non-orthogonal patterns.
7 Cell pattern offset vector <X, Y, Z>

The later one may also be split in 3 to allow for more variation.

[William F Pokorny] Function / pattern issues. New f_repeat(). [2172 days 20 hours and 42 minutes ago]

Sat, 2 May 2020 15:22:15 GMT

<---------------------- References. Six previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5e9cce19%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ea57285%241%40news.povray.org%3E/

---
In povr have implemented a new f_repeat() function which is like the 
existing repeat warp in some respects, but mostly implements some 
SDL/TCL functionality I've had in my toolbox for a while as an inbuilt 
function with the significant improvement of embedding the cells like 
pattern mapping so it need not be calculated and maintained apart.

My toolbox has a bunch of other half done stuff too, but thinking to 
pile it all in one function likely to get sluggish, so leaving that for 
probably another version - f_repeatMoreAndSlower() - or something. :-)

Parameters: x, y, z
Thirteen extra parameter required:
1.  If 0, return new x.
     If 1, return new y.
     If 2, return new z.
     If 3, return matched cells pattern value  0 to 1 interval.
     If 4, return matched cells pattern value -1 to 1 interval.
2.  Count in x.
3.  Count in y.
4.  Count in z.
5.  Delta in x.
6.  Delta in y.
7.  Delta in z.

Direction. If 0, count applied +-. If <0, count applied - only. If >0, count
applied + only.

8.  Direction in x.
9.  Direction in y.
10. Direction in z.
11. Cells pattern offset in x.
12. Cells pattern offset in y.
13. Cells pattern offset in z.

Notes. The base function should be centered at zero and small enough to 
fit in the repeated 'cells.'  The counts too are in both directions 
about the particular axis. So a y count of two means two on each side of 
y. The deltas represent the size of each cell in x,y or z. The 
directions are used to prune counts in particular directions. Lastly, 
the cells offset exists, so if you have multiple instances of the 
isosurface you can make them all look different with respect to textures.

#declare R = 0.070;
#declare cntV   = <+4.0,+1.0,+4.0>;
#declare deltaV = <+0.3,+0.3,+0.3>;
#declare dirV   = <+1.0,+1.0,+0.0>;
#declare coffV  = <+9.0,+9.0,+9.0>;
...

#declare Fn00 = function (x,y,z,r,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz) {
     f_sphere(
         f_repeat(x,y,z,0,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz),
         f_repeat(x,y,z,1,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz),
         f_repeat(x,y,z,2,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz),
         r
     )
}

#declare Iso98 = isosurface {
     function {
         Fn00(x,y,z,R,
             cntx,cnty,cntz,
             dltx,dlty,dltz,
             dirx,diry,dirz,
             coffx,coffy,coffz
         )
     }
...

#declare Pgm00 = pigment {
     function {
         f_repeat(x,y,z,3,
             cntx,cnty,cntz,
             dltx,dlty,dltz,
             dirx,diry,dirz,
             coffx,coffy,coffz
         )
     }
     raw_wave
     color_map { ColorMap00 }
}

Image attached two isosurfaces though could have been one. Using the 
same pigment for both.

Bill P.

[jr] Re: Function / pattern issues. New f_labsweep. [2177 days 20 hours and 59 minutes ago]

Mon, 27 Apr 2020 15:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/26/20 7:37 AM, William F Pokorny wrote:
> ...
> Once in a while, ray tracing, I end up with an image or shape which I
> find disturbing on some sensory level. For me, this is one of them.

although, trim off the cones and you'll have a perfectly good washing machine
drum.

:-)


regards, jr

[Bald Eagle] Re: Function / pattern issues. New f_labsweep. [2178 days and 59 minutes ago]

Mon, 27 Apr 2020 11:05:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> An image applying the leopard pattern ...

> ...I do think it interesting.

Nice  :)

The pattern looks alittle stretched in the y direction, giving it that anti-slip
stair tread look.

https://sc01.alicdn.com/kf/HTB1eq0dFVXXXXciXFXXq6xXFXXX9/205993684/HTB1eq0dFVXXXXciXFXXq6xXFXXX9.jpg

[William F Pokorny] Re: Function / pattern issues. New f_labsweep. [2178 days 2 hours and 32 minutes ago]

Mon, 27 Apr 2020 09:31:54 GMT

On 4/26/20 7:37 AM, William F Pokorny wrote:
...
> 
> Attaching a few images using the new function (f_cone is new too) along 
> with other pattern/function updates previously posted to this newsgroup.
> 
...

An image applying the leopard pattern somewhat like Mike Williams's 
technique for creating shapes with lots of holes via isosurfaces instead 
of traditional csg differences (which are frequently very slow). Here 
the shape is porous throughout.

Once in a while, ray tracing, I end up with an image or shape which I 
find disturbing on some sensory level. For me, this is one of them. Why 
I didn't post it originally, but I do think it interesting.

Bill P.

[William F Pokorny] Function / pattern issues. New f_labsweep. [2179 days and 27 minutes ago]

Sun, 26 Apr 2020 11:37:41 GMT

<---------------------- References. Five previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5e90564c%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5e9cce19%40news.povray.org%3E/

---
Many years ago Tor Olav Kristensen posted a method to create sphere 
capped cone isosurfaces from point a to point b. I've extracted the 
point to point linear sweep embedded in his approach to create a 
function called f_labsweep(), linear a b sweep with the idea of sweeping 
much more than spheres.

It is called once for x,y and z. For example:

#declare ptA = <0,-0.4,0>;
#declare ptB = <0,+0.4,0>;
#declare R = 0.45;

#declare Ax = ptA.x;
#declare Ay = ptA.y;
#declare Az = ptA.z;
#declare Bx = ptB.x;
#declare By = ptB.y;
#declare Bz = ptB.z;

#declare Fn00 = function (x,y,z,r,ax,ay,az,bx,by,bz) {
     f_cone(
         f_labsweep(x,y,z,0,ax,ay,az,bx,by,bz),
         f_labsweep(x,y,z,1,ax,ay,az,bx,by,bz)/1.5,
         f_labsweep(x,y,z,2,ax,ay,az,bx,by,bz),
         r)
}

-------------
// Parameters: x, y, z
// Seven extra parameter required:
// 1. If 0, return new x.
//    If 1, return new y.
//    If 2, return new z.
// 2. 3D point A x value.
// 3. 3D point A y value.
// 4. 3D point A x value.
// 5. 3D point B x value.
// 6. 3D point B y value.
// 7. 3D point B x value.
// Note. This does a linear sweep of a function about the origin
// from point A to point B returning only the modified x, y
// or z value. This enables us to code either directly on the function
// about origin call, which can see modifiers. Or, we can code up each
// as its own X,Y or X function to which we can apply pattern modifiers.
// In testing the former simpler to code, less flexible and slower. The
// latter, approach more difficult to code, more flexible and about 20%
// faster when using the same modifiers for the same result.

Attaching a few images using the new function (f_cone is new too) along 
with other pattern/function updates previously posted to this newsgroup.

Oh, the upper right images uses 'inverse' which is a new pattern wave 
modifier which works both for the traditional 0-1 pattern interval and 
the new -1 to 1 function_interval.

Bill P.

[William F Pokorny] Function / pattern issues. Adding f_granite23,... [2185 days 13 hours and 46 minutes ago]

Sun, 19 Apr 2020 22:18:01 GMT

<---------------------- References. See four additional previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5e8a0353%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5e90564c%40news.povray.org%3E/


Adding four more inbuilt functions in f_granite23, f_mult1to8pairs, 
f_max1to8pairs and f_min1to8pairs.

The f_max1to8pairs and f_min1to8pairs are what they are, both with the 
ability to take the min or max of all the pair results before returning.

The central aim of f_mult1to8pairs is better intersection and difference 
capability for isosurfaces.

The inbuilt f_mult1to8pairs does regular multiplication as a mode too. 
It also takes the min or max of all pair results before exit. It has a 
second regular multiplication mode which takes the square root of the 
results prior to the min/max on return.

The default mode is a specialized multiplication where only negative 
times a negative value returns a negative result while all other 
combinations return positive values. A square root of all the multiplied 
values is done ahead of the min/max before return.

The square root helps with the gradients - which are often bad after 
multiplication. The main goal is to better normalize the resultant 
values to the shape's incoming values. If we work out a nice pattern 
displacement on shape A, we'd like it to track well in effect to the 
multiplied shape A * shape B (intersection) result, for example.


---
In the image Story1to8.png :

row A - min is essentially a merge of the original spheres.
row B - max is an collection of intersections
row C - simple multiplication is a, not very useful to isosurfaces, xor.

Multiplying two 'shapes' today isn't often useful as the shape value 
result is basically an xor - with bad gradients. If a bounding shape is 
used to cut away the surface so the xor -1,-1 regions are visible as in 
row02, you can create interesting structures.

row D - New neg * neg multiply and we get a worse than max looking result.

It's worse because the values at the surface are very small and the 
isosurface solver result is somewhat unstable.

row E - Burns off the tiny values with a tiny positive adder.

Currently, this addition is done outside of f_mult1to8pairs. It's not a 
universal, smooth sharp seams, solution. If the incoming shapes in the 
pair have sharp parts, the burn off does nothing but push the surface 
inward a little. If the 'intersection' of shapes expose, or create, a 
surface deep within the negative values of one or both, the small value 
burn off no longer works or works less well.

row F - A neg * -(neg) shape multiply gives us a difference mechanism.

A difference mechanism with the same tiny value surface burn off 
capability.  An example using this technique was posted to p.b.i 
recently where the two input functions were text hard_object pattern based.

In the row F image an output of the new f_granite23 function acts as the 
-(neg) shape / differencing shape on the left. On the right we do a 
difference(sphere,smaller_sphere).


--- f_granite23

This inbuilt function is a bit of an experiment. It's the combined noise 
2 and 3 variation except it provides 6 post granite modifiers and a 
trailing multiplier. Run with all modifiers and the multiplier at 0, the 
result is very like granite in the 0-1 range and without the apparent 
artefacts of pure noise 1, 2 or 3 - though probably there are some not 
recognized because the result is different.  Further some effort 
internally to better fill the 0-1 range - a stretch of values gets done.

The six on/off modifiers are in order: inverse, dents-treatment, 
inverse, cube root value stretch filter, inverse. Why all the inverses? 
Well the granite pattern in particular 'looks' quite different inverted.

The last argument is an internal multiplier. Perhaps obvious, but with 
functions / isosurfaces value multiplication ahead of displacement is 
different than a 1x value displacement and multiplicative scale. 
Questioning whether, perhaps, all f_<pattern> inbuilt functions should 
provide for internal multiplication / scaling rather than doing it via 
the vm.

---
In the image StoryGranite23.png :

row 0 - Eight pair multiply result with f_granite23 displacement.
row 1 - Dents pow(val,3) treatment to the granite pattern.

Looks useful to me. Should this be another general wave modifier instead...

row 2 - Applying the multiplier ahead of displacement.

Interesting to me, as shown in row 2, with isosurfaces - depending on 
the base function values you can get shapes forming perpendicular to 
simple value adder displacement. It can be hard to hit the window where 
this happens without getting too many floating pieces, but it's a cool 
result when you get it.

Bill P.

[William F Pokorny] Function / pattern issues. Adding f_remap. [2195 days and 45 minutes ago]

Fri, 10 Apr 2020 11:19:40 GMT

Previous related postings:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dd8006c%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5e8a0353%241%40news.povray.org%3E/


We've had techniques like:

max(Fn01(x,y,z)-VarThickness/2.0,-Fn01(x,y,z)-VarThickness/2.0)

for creating isosurface shells; shells of negative value. If you want 
more than one shell based on the same function, it can be done, but in 
the simplest linear function forms, it ends up that the shell at 0.0 is 
twice the 'thickness' of all the others. The set up is also messy.

To help added a new inbuilt f_remap function to povr.

#declare f_remap = function { internal(3) }
// Parameters:
// 1. Incoming value to remap to weighted triangular peaked
// wave -1 to 1 to -1.
// 2. Number of triangle peaks in values remap. Min of 2.
// 3. Threshold for shell values. 0.0 returns weighted
// triangular values. When > 0.0 negative, normalized negative value
// shells created around the 2-8 values specified with
// parameters [4-11].
// 4-11 values to consider 0 points between peaks. Max of 8.

--- Upper left image
Used to displace the y plane via:

#declare Fn00 = function { f_gradient(x,y,z,1,0,0.5) }
#declare Fn01 = function {
     f_remap(Fn00(x,y,z),3,0.0,
         -1.0,0.0,0.5,2.0,
         100,100,100,100)
}
#declare Fn03 = function { y + Fn01(x,y,z)*0.25 }

it generates the upper left image. It remaps values so as to have 0 
crossings at the 2-8 values specified. Given the f_gradient input (and 
yes, that is a new inbuilt function too replacing the three X,Y,Z only 
functions.inc forms), we end up with ramps into and out of the 0 
crossing which themselves peak in a triangular fashion at -1 and 1 values.

--- Upper right mage
Using a normal-ish approach to get shells (here walls) at the zero 
values we use:

#declare Fn02 = function {
max(Fn01(x,y,z)-VarThickness/2.0,
-Fn01(x,y,z)-VarThickness/2.0) }

and get the upper right result where though the shells now all two sided 
they still change widths due the differences in ramps into and out of 
the zero regions.

--- Lower left image
Here we pass the VarThickness threshold to the f_remap function. It 
creates the shells while normalizing to the steepest ramp from 1 or -1 
into any 0 value. The use code for this looks like:

#declare Fn00 = function { f_gradient(x,y,z,1,0,0) }
#declare VarThickness = 0.15;
#declare Fn01 = function {
     f_remap(Fn00(x,y,z),3,VarThickness,
         -1.0,0.0,0.5,1.2,
         100,100,100,100)
}

with Fn01 used directly in the isosurface function. Result in the lower 
left.  Yes, for less linear input functions the shell/width thicknesses 
are still going to vary even with normalization - but substantially less so.

--- Lower right image...
Playing with the value difference between noise generator 2 and 3 as 
wondered about in the recent posting to p.b.i. The code for that looks like:

#declare Fn00 = function {
    f_snoise3d(x-2/2,y/2,z/2,2)-
    f_snoise3d(x-2/2,y/2,z/2,3)
}
#declare VarThickness = 0.02;
#declare Fn01 = function {
     f_remap(Fn00(x,y,z),5,VarThickness,
         -0.6,-0.3,0.0,0.3,0.6,
         100,100,100)
}

and the result is shown in the lower right. Yes, f_snoise3d is now 
inbuilt and requires the noise generator to be set.

Bill P.

[Bald Eagle] Re: Function / pattern issues. Updating cubic_wa... [2199 days 18 hours and 4 minutes ago]

Sun, 5 Apr 2020 18:00:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-04-05 Ã  12:12, William F Pokorny a Ã©critÂ :

> This looks like an improvement.
> As I very rarely encounter that wave type, i don't think that it will
> break anything.

Having had to ascend the learning curve to the point where I read source code
and re-write everything from pattern functions to how the color is mapped, to
the point where I uncover malfunctioning code that's been lurking for 20+
years....

It's a PITA to have to do all that because some function that I want is not
accessible internally, or the output that I wrest from SDL is not sufficiently
suitable for further use (no vector-result functions).

That isosurface using the old cubic function is a nasty, gnarly looking thing
that would be useful and desirable for rendering organic growths.
Consider the render and response to:
http://news.povray.org/povray.binaries.images/message/%3Cweb.5d2f9172746ba36d4eec112d0%40news.povray.org%3E/#%3Cweb.5d2
f9172746ba36d4eec112d0%40news.povray.org%3E

So, I'd say keep the original cubic wave, but implement it in some other way,
such as in an updated function include file, a way to specify what is used,
perhaps with a new "wave_set" argument, such as how we now can select which
default noise generator is used, or tack it on as some other numbered internal
function.

But don't delete it.

We have a user-defined pattern, a user-defined camera,
http://wiki.povray.org/content/Reference:User_Defined_Pattern
http://wiki.povray.org/content/Reference:Camera#User_defined_projection
(etc if there are more such things)

It would be ideal to have a user-defined option for all things - noise
functions, turbulence, ... and wave types.

So maybe that's a long-term option to ponder while you're in the midst of all
this.

Great work as always, Bill.   You are seemingly indefatigable.
All the best.

In the words of Truthstream Media, "We're Living in 12 Monkeys."

[Alain Martel] Re: Function / pattern issues. Updating cubic_wa... [2199 days 19 hours and 7 minutes ago]

Sun, 5 Apr 2020 16:57:44 GMT

Le 2020-04-05 Ã  12:12, William F Pokorny a Ã©critÂ :
> Previous postings:
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/

> 
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

> 
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/

> 
> 
> and
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dd8006c%241%40news.povray.org%3E/

> 
> 
> As discussed previously, I've added a new wave modifier mode called 
> function_interval which works in the -1 to 1 range instead of the usual 
> pattern range of 0 to 1. As part of this working to update all the 
> existing *_wave modifiers to work in both ranges.
> 
> Found with the cubic_wave (does anyone really use it today?) when, eons 
> ago, the inversion of negative values was introduced to get continuity 
> (non-flipping at) while moving from negative to positive values through 
> 0.0 the cubic pattern was apparently not updated and the continuity was 
> mostly broken for it as can be seen in the upper left of the attached 
> image applying it to a gradient x pattern.
> 
> I worked to fix this, but then could see no advantage for cubic_wave 
> over what we already have with sine_wave. I was going to delete it, but 
> have decided for povr, to change the existing cubic wave modifier for 
> both ranges into a bump (selection) function of sorts. The result of 
> this can be seen in the upper right of the attached image again applying 
> it against a gradient x pattern.
> 
> Today if we try a pattern with cubic_wave like:
> 
> granite cubic_wave frequency 3.3 phase -0.5
> 
> and use it as an offset to the y plane in an isosurface, we get the 
> lower right results in the attached image. It's something, but it has 
> awful continuity and is really useful only for noisy results of one kind 
> or another.
> 
> In the lower right is the bump function result with runs in nearly 1/3 
> the time because it maintains the incoming continuity while providing 
> for results much more likely to be useful.
> 
> Bill P.
> 
> 
This looks like an improvement.
As I very rarely encounter that wave type, i don't think that it will 
break anything.

[William F Pokorny] Function / pattern issues. Updating cubic_wave. [2199 days 19 hours and 52 minutes ago]

Sun, 5 Apr 2020 16:12:03 GMT

Previous postings:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dd8006c%241%40news.povray.org%3E/

As discussed previously, I've added a new wave modifier mode called 
function_interval which works in the -1 to 1 range instead of the usual 
pattern range of 0 to 1. As part of this working to update all the 
existing *_wave modifiers to work in both ranges.

Found with the cubic_wave (does anyone really use it today?) when, eons 
ago, the inversion of negative values was introduced to get continuity 
(non-flipping at) while moving from negative to positive values through 
0.0 the cubic pattern was apparently not updated and the continuity was 
mostly broken for it as can be seen in the upper left of the attached 
image applying it to a gradient x pattern.

I worked to fix this, but then could see no advantage for cubic_wave 
over what we already have with sine_wave. I was going to delete it, but 
have decided for povr, to change the existing cubic wave modifier for 
both ranges into a bump (selection) function of sorts. The result of 
this can be seen in the upper right of the attached image again applying 
it against a gradient x pattern.

Today if we try a pattern with cubic_wave like:

granite cubic_wave frequency 3.3 phase -0.5

and use it as an offset to the y plane in an isosurface, we get the 
lower right results in the attached image. It's something, but it has 
awful continuity and is really useful only for noisy results of one kind 
or another.

In the lower right is the bump function result with runs in nearly 1/3 
the time because it maintains the incoming continuity while providing 
for results much more likely to be useful.

Bill P.

[William F Pokorny] Function / Pattern issues. New function f_eblob(). [2334 days 20 hours and 28 minutes ago]

Fri, 22 Nov 2019 15:36:12 GMT

A new inbuilt 'f_eblob' function continuing work documented in the 
previous threads:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/


The idea of using exp() to blob has been around a long time in different 
forms. Maybe 15 years ago, give or take, Tor Olav posted the idea of 
using a 1/exp(S*T) form where the tightness (T) was specified for each 
function providing a value(S). I've used the method and in many 
situations it works - though the gradients tend to get quite high and I 
find myself always twiddling with the starting threshold values.

Of late working to better formulate a complete method in an inbuilt 
f_eblob function.  It's currently set up to be used something like:

#declare FnBlob00 = function (x,y,z,Mode,Tightness) {
   f_eblob(0.001,4,Mode,
   FnSph00(x,y,z),FnSph01(x,y,z),
   FnSph02(x,y,z),FnSph03(x,y,z),0,0,0,0,
   Tightness,Tightness,Tightness,Tightness,0,0,0,0)
}

where the arguments are:

1) +- offset between two 1/exp() evaluations which helps greatly with 
the gradients and provides a way to calculate and initial value to which 
the internal negative blobbing contributions are added. Finding 0.001 
perfectly fine so far.

2) The number of active incoming functions / shapes from 1-8.

3) The modes. 0 calculates a blobbed value from all the function input 
values and strengths. 1 calculates an all pairwise, most negative, 
interpolation to come up with pattern *_map values. The maps have a 
particular form - similar to the tiling patterns - and for the 4 
functions / shapes version it looks something like:

#declare ColorMap01 = color_map {
     [0.000000 ColorPositive]
     [0.142857 ColorFn00]
     [0.285714 ColorFn01]
     [0.285714 ColorFn00]
     [0.428571 ColorFn02]
     [0.428571 ColorFn00]
     [0.571429 ColorFn03]
     [0.571429 ColorFn01]
     [0.714286 ColorFn02]
     [0.714286 ColorFn01]
     [0.857143 ColorFn03]
     [0.857143 ColorFn02]
     [1.000000 ColorFn03]
}

A value of exactly 1.1 provides some debugging feedback by turning off 
interpolation where the function/shape is itself negative enough to 
overcome the internal threshold. Values >1.1 and <=6.0 currently do a 
poly_wave pow() type of interpolation.

4-11) Are the function value inputs.
12-19) Are the match tightness values >0.0 to 100.0.

The function f_eblob expects the incoming function/shape thresholds to 
be at 0.0 - which is usually true.

With reference to the attached image:

--- Row 1
A) Four spheres. Tightness set to 0 to see the original shapes.
B) at 7.5.
C) at 15.
D) at 30.

--- Row 2
E) Tightness at 10 and the isosurface enclosing box cutting a slice to 
show mode 1.0 (linear) color interpolation for the 4 spheres. There are 
discontinuities due the underlying pairwise pattern value interpolation.

F) Like E but using debug mode 1.1 to see where the original spheres are.

G) Mode set to 2.0 for poly_wave like interpolation extending the pair 
end point colors.

H) Mode set to 6.0. The >1.1 to 6.0 pow() interpolation minimizes the 
pairwise effects.

--- Row 3
I-J) Showing VarS / Tightness at 25.0 and 2,3,4,5 powers left to right. 
For many situations looks like the map value generation will work out 
OK. Anywhere the blobbing ends up more or less pairwise applied should 
be fine.

--- Row 4
M) Yes, negative tightness values can be used.

N) The tightness values need not be the same. The top and bottom spheres 
using 1/2 the left and right tightness.

O) The top and bottom using 2x the left and right tightness.

P) All values equal. Showing where spheres overlap the ordering for the 
map color is sorted by pairs. The red-green, most negative pair is 
evaluated first - though other pairings have the same negative values at 
some positions.

--- Row 5 (bottom row)
Showing various blobbing using f_rounded_box() instead of 'f_sphere()'.

Bill P.

[Bald Eagle] Re: Function/ pattern issues. New pattern_modifi... [2354 days 21 hours and 14 minutes ago]

Sat, 2 Nov 2019 14:50:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> If talking about a branch someone could compile themselves, good. I plan
> to assemble publish such a branch(1).

I think that would be a nice tool to have, for a number of reasons.

1. It simply doesn't make a lot of sense to work on things that no one will be
using.  So publishing it for use allows people to, obviously, use it - but also
their use of the branch advertises it in some way and encourages further use.
(IMHO, POV-Ray proper (PRP) could use more of this [a] )

2. It provides a means of accomplishing something that may be impossible using
the current release, vastly simpler, or just far more accessible to folks with
limited time or just not enough time to concoct a scheme to code a clever
work-around

3. Using such a branch allows people (like me ;) ) to break it and find the
bugs, thus driving its iteratively increasing stability, and providing usage
statistics supporting it suitability for inclusion in PRP.

> (1) - Thinking that branch will include additional new functions /
> function / pattern updates. I have a list of potential new functions and
> am playing with several not yet posted about now. I'll probably pick up
> Jerome's rotate warp too in some form.

IIRC, at least 3 people have expressed explicit interest in the vortex
pattern/function.  [jr, TdG, Yadgar, ...] I don't know what you'd need in order
to roll that in as well.

> I'm likely to hack at the current implementation of the new potential
> pattern too... I find myself not sure how to really make use of the
> potential pattern capability with most shapes. It works well only with
> blobs today(1a). I've thought a fair bit about how to extend the
> potential pattern to other shapes, but I've got no idea how to normalize
> the values in the ray-surface equation values space.

I found it extremely useful to look at what loads of people have done with the
ray-marching technique.  Some very interesting and simple-looking functions to
perform a wide variety of clever operations.  It made me thing about a few
things in completely different ways.

[a]
Grant Sanderson of 3 Blue 1 Brown uses python and "manim" - a math animation
package for use with Adobe AfterEffects to make his excellent videos.

Folks say it's rather hard to use with not much documentation - I'm wondering if
they might begin using POV-Ray if they knew about it and could see what it can
do. (I don't have a YT account)
Perhaps Khan Academy, and certain other channels dealing with math and physics
would be drawn to experimenting with POV-Ray's built-in capabilities for
vectors, isosurfaces, parametrics, polynomials, matrices, arrays, and animation.

https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab

[William F Pokorny] Re: Function/ pattern issues. New pattern_modifi... [2355 days 3 hours and 30 minutes ago]

Sat, 2 Nov 2019 08:34:21 GMT

On 11/1/19 1:53 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> What's missing is a way to access the x,y,z vector result of all the
>> modifiers a pigment / pattern might employ.
> 
>> Then pattern_modifier {} grabs just the result of those
>> operations for a given point returning the function/pattern space
>> adjusted x,y,z values. The usage is something like:
> 
> Yes, this will be very nice indeed. 
> 
> Just curious:
> Being eyeballs-deep in the function code, what do you think the odds are that
> there will be functions that can return <x, y, z> vectors for user use, say in
> the next year or so?
> 

If talking about a branch someone could compile themselves, good. I plan 
to assemble publish such a branch(1).

If talking about in POV-Ray proper, I have no idea. The only person 
actually updating POV-Ray in the past years has been quiet since April 
or so. My pull requests, no matter how trivial, had not been getting 
merged in any form since a minor build related one in November 2017. 
Nothing substantially picked up and merged of mine since early 2017. I 
think that reality unlikely to change no matter core development 
starting up again.

Bill P.

(1) - Thinking that branch will include additional new functions / 
function / pattern updates. I have a list of potential new functions and 
am playing with several not yet posted about now. I'll probably pick up 
Jerome's rotate warp too in some form. Might merge in / refine my 
additional black hole warps as part of this branch too as they are 
really part of the same idea push. I'd like to work out an efficient 
back_hole encapsulated turbulence capability so it can more easily be 
applied locally in a feathered-in-strength way.

I'm likely to hack at the current implementation of the new potential 
pattern too... I find myself not sure how to really make use of the 
potential pattern capability with most shapes. It works well only with 
blobs today(1a). I've thought a fair bit about how to extend the 
potential pattern to other shapes, but I've got no idea how to normalize 
the values in the ray-surface equation values space. These equations 
vary wildly in absolute magnitude and polarity - neither of which matter 
to a first order to the majority of the root solvers. This means the 
potential pattern extended to all inbuilt shapes amounts to implementing 
it as some inside/outside switching - and we already have that 
capability with the object (inside test based) pattern.

(1a) - Our blob has always had continuity issues at the boundaries of an 
individual blob element's influence. Others have suggested updates over 
the years to address this - and down somewhere on my list I want to look 
at it given my solver branch addressed many base accuracy issues with 
the blob shape. The point here, even with blobs where the value domain 
is somewhat normalized, their usefulness as complicated multi-blob 
potential patterns is constrained due the long-standing continuity 
issues with the blob shape itself. I see the blob-potential pattern as 
useful for noisy results with complicated structures - like how blobs 
get used for snow and the like today - but not for real detail. The 
surface continuity necessary just isn't there for the latter use except 
with stand alone blob elements. In other words - except with non-blobbed 
blobs... ;-)

[Bald Eagle] Re: Function/ pattern issues. New pattern_modifi... [2355 days 18 hours and 9 minutes ago]

Fri, 1 Nov 2019 17:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> What's missing is a way to access the x,y,z vector result of all the
> modifiers a pigment / pattern might employ.

> Then pattern_modifier {} grabs just the result of those
> operations for a given point returning the function/pattern space
> adjusted x,y,z values. The usage is something like:

Yes, this will be very nice indeed.

Just curious:
Being eyeballs-deep in the function code, what do you think the odds are that
there will be functions that can return <x, y, z> vectors for user use, say in
the next year or so?

[William F Pokorny] Function/ pattern issues. New pattern_modifiers ... [2355 days 18 hours and 43 minutes ago]

Fri, 1 Nov 2019 17:21:09 GMT

A new 'pattern_modifiers' keyword continuing work started in the threads:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

We have since v3.5 a vturbulence parse time function. We have too the 
existing pattern { } wrapper - though as a function wrapper, especially, 
its usefulness is limited. The former handles only turbulence the latter 
only returns the resulting pattern value at points in space.

What's missing is a way to access the x,y,z vector result of all the 
modifiers a pigment / pattern might employ. So adding: function { 
pattern_modifiers {} }. As something function enabled, it's usable at 
parse and render time.

The general idea is to set up a real - or dummy - pattern/pigment 
defining a collection of modifiers. A collection of warps, turbulence 
and transforms. Then pattern_modifier {} grabs just the result of those 
operations for a given point returning the function/pattern space 
adjusted x,y,z values. The usage is something like:

#declare FnHelix1_5p = function {
     pattern_modifiers { Pigment00 }
}
#declare FnHelix1_5 = function (x,y,z) {
     FnHelix1_5c(FnHelix1_5p(x,y,z).x,
         FnHelix1_5p(x,y,z).y,
         FnHelix1_5p(x,y,z).z)
}

for functions. Use in user space requires 'opposite' internal to POV-Ray 
values be flipped before use.

See attached example scene and image. The image's left side shows 
spheres placed in a vertical column and collected in a union; as well as 
a helix1 based isosurface. On the right both the placement of the 
spheres and the isosurface are perturbed by the pattern modifiers (here 
gentle turbulence and a rotate x*33) both defined with the pigment used 
for both final objects.

Bill P.

[William F Pokorny] Re: Fixing longstanding function/pattern issues ... [2366 days 3 hours and 7 minutes ago]

Tue, 22 Oct 2019 08:57:32 GMT

On 10/20/19 1:18 PM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> Well, I think I found an issue with the way that the angle is calculated for the
>> radial pattern.
> 
> I had it in the back of my mind to mention the effect of phase, but forgot.
> The equations also seem to botch the phase adjustment as well.
> I noticed this when I realized I could probably use phase to rotate the color
> map instead of applying the unmodified pigment to the object and then rotating
> around the origin.
> 
> I _think_ I got to the point where I fixed this as well, but it's all worth a
> thorough double and triple checking.
> 
> FYI.
> 
I think I have a fix in hand. Further that the problem with phase was 
rooted in the base radial problem affecting non-integer frequencies. 
Internally phase is an adder applied after the frequency multiplication.

See attached. Upper left is your f=360/270 as the new code renders the 
breaks in continuity (ramp_wave).

Upper right f=360/270 phase 1/4. Lower left f=4. Lower right f=4 phase 1/4.

Done a fair bit of testing and looking OK to me. It will be a while 
before I get a branch out as busy with real life until the middle of 
next week. First thought about a branch for just this change, but it's 
getting to where I'm carrying too many off master. I'm going to roll 
this change into a branch for a set of changes around functions and 
patterns I want including this update. I plan opening a more general 
github issue covering everything in the set of changes too.

Bill P.

[Bald Eagle] Re: Fixing longstanding function/pattern issues ... [2367 days 18 hours and 44 minutes ago]

Sun, 20 Oct 2019 17:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Well, I think I found an issue with the way that the angle is calculated for the
> radial pattern.

I had it in the back of my mind to mention the effect of phase, but forgot.
The equations also seem to botch the phase adjustment as well.
I noticed this when I realized I could probably use phase to rotate the color
map instead of applying the unmodified pigment to the object and then rotating
around the origin.

I _think_ I got to the point where I fixed this as well, but it's all worth a
thorough double and triple checking.

FYI.

[Bald Eagle] Re: Fixing longstanding function/pattern issues ... [2367 days 19 hours and 49 minutes ago]

Sun, 20 Oct 2019 16:15:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> I think you did. Looks too me like only integer frequency multipliers
> have ever worked with the radial pattern. Probably how most use the
> pattern, but wow.

Thanks.  It looked real to me, and it was confusing to try to see what was going
on and get the desired behaviour in my scene, so I had to emulate the pattern
with a function so I could manipulate it's behaviour and track down WHAT was
going on...

> Attached is an image where the top two rows use a +z orthogonal camera
> and the bottom row a perspective camera. Always looking at a thin z
> plane sheet displaced by the radial's returned values.

Very very nice.  That's a great visualization of what's going on.

> The pattern in the
> 270-360 angle range start in the value range 1.00 to 1.25 and those
> values must "come down" by one to create a continuous pattern 0-1.
>
> The means even at the default frequency of 1.0 the wave modification
> code is using fmod() to bring the 1.00 to 1.25 values down. Top row,
> right column.

Yes, that's what I stumbled across and noticed as well.
I still don't fully understand _exactly_ what's going on - not enough to
articulate and explain it - but I could reach out and feel it in the dark and
imagine a fix.

> Where I used 360/270 as you did, we
> expose the discontinuity on the right of the second row.

Indeed, I think it was just pure luck out of laziness picking a 90 deg arc and
then filling in with 270 so I didn't have to write another 2 or 3 lines of code.
  :D

> In the bottom row on the left a perspective camera view with frequency
> 1.0. On the right 360/270. What's interesting to me is where the
> original pattern is continuous, the 1.333 works. We corkscrew by -90*y
> degrees - but this exposes the discontinuity. The size of the
> discontinuity also not consistent relative to frequency - at 1.9 it's
> much smaller. Expect that sometimes tends to hide the problem as well.

Yes.  I figured that it must be somehow due to the fractional portion of the
frequency that triggers the step when [f]mod() is applied.  That's why
everything looked fine when integer frequencies were used.  I had to play around
with that 0.25 magic number as well to understand what it was for and what it's
overall effect was.  Maybe define a HalfPi or QuarterTau constant in the source
to use there, along with a comment.

I could use a nudge in implementing a reversal of the color map, so that it goes
in the opposite direction...

> We should fix this and reduce those huge 0.001 tolerances around x,z
> zero too. We've got a discontinuity around the y axis too for most of
> the rotation around y. I'll put it on my list to create a code branch
> fixing these issues - stealing from your suggested code.

Well what I did there was get rid of the whole tolerance altogether.
#declare Radial = function (XX, ZZ, F, P) {select (XX*ZZ,  FreqPhase
(XX,ZZ,F,P), 0, FreqPhase (XX,ZZ,F,P))}

Assuming that if one of the atan2 arguments was zero, the product would be too.
For the purposes of source, that will probably have to be modified a bit and
bracketed by sanity checks and other safety nets...

> Aside: Apologies to all for my writing yesterday. Far too much of my
> usual internal 'thought-storm' got to the page. Happened to bring up the
> original post and - "frustrating to recognition" - among others. Dang
> brain...

No apologies - the reasoning and speculating, and train of thought is every bit
as useful to learning about all of this as concrete snippets of code and
illustrative renders are.
I always learn a lot.  Thanks for confirming and addressing this.  :)

Bill W.

[William F Pokorny] Re: Fixing longstanding function/pattern issues ... [2367 days 22 hours and 7 minutes ago]

Sun, 20 Oct 2019 13:57:14 GMT

On 10/19/19 11:01 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
> Well, I think I found an issue with the way that the angle is calculated for the
> radial pattern.
> 
...

I think you did. Looks too me like only integer frequency multipliers 
have ever worked with the radial pattern. Probably how most use the 
pattern, but wow.

Attached is an image where the top two rows use a +z orthogonal camera 
and the bottom row a perspective camera. Always looking at a thin z 
plane sheet displaced by the radial's returned values.

In the top row, left column looking at the RadialPattern::EvaluateRaw() 
output values directly using my new raw_wave keyword. The pattern in the 
270-360 angle range start in the value range 1.00 to 1.25 and those 
values must "come down" by one to create a continuous pattern 0-1.

The means even at the default frequency of 1.0 the wave modification 
code is using fmod() to bring the 1.00 to 1.25 values down. Top row, 
right column.

The current method works for f>1 integers as can be seen with frequency 
2 in the second row, left column. Where I used 360/270 as you did, we 
expose the discontinuity on the right of the second row.

In the bottom row on the left a perspective camera view with frequency 
1.0. On the right 360/270. What's interesting to me is where the 
original pattern is continuous, the 1.333 works. We corkscrew by -90*y 
degrees - but this exposes the discontinuity. The size of the 
discontinuity also not consistent relative to frequency - at 1.9 it's 
much smaller. Expect that sometimes tends to hide the problem as well. 

We should fix this and reduce those huge 0.001 tolerances around x,z 
zero too. We've got a discontinuity around the y axis too for most of 
the rotation around y. I'll put it on my list to create a code branch 
fixing these issues - stealing from your suggested code.

Aside: Apologies to all for my writing yesterday. Far too much of my 
usual internal 'thought-storm' got to the page. Happened to bring up the 
original post and - "frustrating to recognition" - among others. Dang 
brain...

Bill P.

[Bald Eagle] Re: Fixing longstanding function/pattern issues ... [2368 days 8 hours and 59 minutes ago]

Sun, 20 Oct 2019 03:05:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> I started documenting longstanding bugs and issues with VM function and
> pattern interplay. I believe as many as possible should be fixed in the
> POV-Ray v3.8 release. Documenting these bugs/issues as I do my best to
> find and fix them in my personal version of POV-Ray.

Well, I think I found an issue with the way that the angle is calculated for the
radial pattern.

 if ((fabs(EPoint[X])<0.001) && (fabs(EPoint[Z])<0.001))
 {
  value = 0.25;
 }
 else
 {
  value = 0.25 + (atan2(EPoint[X],EPoint[Z]) + M_PI) / TWO_M_PI;
 }

 return(value);

If you plot out the values as you go around the unit circle, there's this weird
90-degree "burp" at the 270 degree mark (Theta = 3pi/4 = 4.712) or x=0, z=-1,
which I think is due to the ... + M_PI) / TWO_M_PI part of the equation.

And you can see it as a distinct discontinuity if you render a torus with a
color map like
#declare CM_GreenRedGradient =
color_map {
 [0.0  rgb <0.0, 1.0, 0.0>]
 [0.125  rgb <0.0, 0.0, 0.0>]
 [0.4  rgb <0.0, 0.0, 0.0>]
 [1.0  rgb <1.0, 0.0, 0.0>]
}
and a frequency of 360/270
so that the color and the black show the jump.

This seems to fix it (in my SDL model scene):
#declare Angle = function (XX,ZZ) {atan2 (XX, ZZ)-(pi/2)}
#declare Adjusted = function (XX,ZZ) {select (Angle(XX,ZZ),  Angle(XX,ZZ)+tau,
Angle(XX, ZZ))}
#declare FreqPhase = function (XX, ZZ, F, P) {mod ((P*tau+Adjusted (XX, ZZ))*F,
tau)/tau}

It's late and I'm tired, so I'm making more mistakes and so I'm not going to
play around too much more with this tonight.  But I do believe this is a real
"bug" in the formula, simply due to the numeric #debug output of the formula and
the sharp discontinuity in the color mapped result.

I believe the expected result should be: the color map starts at 0 (<1, 0>),
works it's way around in the y direction, until it hits frequency F, and then
start at the beginning of the color map: entry [0.0 .....].
From what I can determine with my limited experiments, it does not do this.

In the attached render, I have the two small tori, with f=360/90=4, and
f=360/270=1.333....
The two on the left are the native radial pattern with no phase adjustment.
The two on the right are my pattern{function{}} versions with the "fixed"
formulas.

The large center circle is two Segment_of_Torus () objects, textured and rotated
into proper position like I wanted.

I think the fact that the two small tori with f=4 look identical, and so this
has been lurking unseen, since I noticed that it can be very hard to pick out if
you don't know it exists, and are using a color map specifically designed to
expose it.

Let me know what you think.

[Bald Eagle] Re: Fixing longstanding function/pattern issues ... [2368 days 17 hours and 9 minutes ago]

Sat, 19 Oct 2019 18:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Today one has to understand in detail how ALL the pattern wave modifiers
> work and how to hack your functions to get past the issues to use the
> warp/turbulence capability. Oh, and to use any pattern modified function
> in with other functions. It's a huge pain. Anyway, the problem code for
> many functions(3) is:
>
>      /* allow negative frequency */
>      if(value < 0.0)
>          value -= floor(value);
>
>
> Bill P.

Ha!   I just pulled up the code in pattern.cpp this morning and was looking at
that exact section.

I thought perhaps there was some strange way that radial was implemented, but I
should have recalled from my other source patterns to SDL work that it's just
dirt simple.
And I did see the code for special handling of all the wave types, and given
that NPC just posted about the asteroid normal map, I thought maybe that might
solve my "scaling" woes.

Nothing yet - but it's something to play with.

I suppose I ought to somehow graph all of those out so that I have a reference
diagram for understanding and debugging.

[William F Pokorny] Fixing longstanding function/pattern issues in v... [2368 days 19 hours and 12 minutes ago]

Sat, 19 Oct 2019 16:52:37 GMT

In an earlier post to this newsgroup:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da5ba46%40news.povray.org%3E/

I started documenting longstanding bugs and issues with VM function and 
pattern interplay. I believe as many as possible should be fixed in the 
POV-Ray v3.8 release. Documenting these bugs/issues as I do my best to 
find and fix them in my personal version of POV-Ray.

---
The internal kWaveType_Raw waveType clipka introduced with the new 
potential(1) pattern should go the whole way and be available via a new 
'raw_wave' keyword.

It's frustrating to recognition the core developers implemented 
significant infrastructure which should make creating and manipulating 
functions and isosurfaces via the pattern mechanisms easy - except often 
it falls short.

Everything exists today to code and run:


//--- FnZZ used directly in an isosurface - attached image left column
#declare VarPlaneSheetThickness = 0.01;
#declare FnZ = function (x,y,z) { z-(VarPlaneSheetThickness/2.0) }
#declare FnZ_inv = function (x,y,z) {
     -(z)-(VarPlaneSheetThickness/2.0)
}
#declare FnZZ = function (x,y,z) { max(FnZ(x,y,z),FnZ_inv(x,y,z)) }

#declare VarPlaneSheetOffset = 0.8;
#declare FnZZOffset = function {
     pattern { function { FnZZ(x,y,z) }
   //raw_wave // Without middle column, with get intended result right.
     translate <0,0,VarPlaneSheetOffset>
     turbulence 0.1
     }
}
#declare IsoPlaneZOffset = isosurface {
     function { FnZZOffset(x,y,z) }
     contained_by {
         box { <-1,-1,-0.20+VarPlaneSheetOffset>,
         <1,1,0.20+VarPlaneSheetOffset> }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.3
     max_trace 1
     pigment { color Indigo4 }
}

but the above code doesn't work though the developers enabled the 
overall mechanisms.

The raw_wave keyword bypasses the usual pattern 'wave' modification code 
- including the code below which makes manipulating functions with the 
remaining pattern modifiers difficult(2) and very confusing.

Today one has to understand in detail how ALL the pattern wave modifiers 
work and how to hack your functions to get past the issues to use the 
warp/turbulence capability. Oh, and to use any pattern modified function 
in with other functions. It's a huge pain. Anyway, the problem code for 
many functions(3) is:

     /* allow negative frequency */
     if(value < 0.0)
         value -= floor(value);


Bill P.

(1) - Aside. I have concerns with the potential pattern for blobs and 
isosurfaces as currently implemented for v3.8. Other than perhaps being 
complete in providing an isosurface potential pattern, it doesn't make 
much sense. Most anyone will just use the function into the isosurface 
directly. Further, the keywords added code added slows all isosurfaces.
Lastly, with both blobs and isosurfaces the internal 'raw_wave' is hard 
set on - preventing the use of the wave modifiers when they could be 
used.

(2) - In the scene file provided for the thread referenced at top, it's 
why this extra, but today, necessary code :

#declare Fn00f_Tiling11_3 = function {
     pattern { function { max(0,-Fn00e_Tiling11_3(x,y,z)) } }
}

Yes, the clamping hurts the gradient and to get something a little 
better I code:

#declare Fn00_Tiling11_3 = function (x,y,z) {
     0.001-Fn00f_Tiling11_3(x,y,z)
}

instead of:

#declare Fn00_Tiling11_3 = function (x,y,z) {
     -Fn00f_Tiling11_3(x,y,z)
}

for the final isosurface function.

(3) - I have in mind an additional wave modifier keyword - 
function_wave(?) - which bypasses only the problem code. Not yet worked 
on it in detail. Aiming to allow most (or all) the existing wave 
modifiers with it. Excepting of course the new raw_wave one which just 
bails on that code.

[William F Pokorny] Re: v3.8 Isosurface artefacts test case. Windows... [2372 days 23 hours and 41 minutes ago]

Tue, 15 Oct 2019 12:23:34 GMT

On 10/13/19 5:14 PM, jr wrote:
> 
> in a way I'm surprised that POV-Ray does not contain its own low-level maths
> library, I'd have thought that an advantage.  

If I'm following your meaning. There is some. Some even in the shipped 
SDL includes.

> so, I wonder (not knowing the code
> base + off the top of my head) whether collecting various low-level routines
> into a "convenience" library included with POV-Ray would not help with platform
> independence/"implementation differences". 

Again improvement possible in this vein though I don't expect it to help 
much with platform issues - if we have many.

Truth is POV-Ray is really good at compiling and running the same way on 
any platform with a standards compliant C++ compiler. The core 
developers have worked hard at to make this so.

I was speaking of a few concerns - those mostly given recent past 
vector.h behavior in not getting the C++ standard include for abs. It 
just happened the code involved here touches on those 'concerns.' Had 
OSX and Windows users tested, it was as much to confirm no differences 
as anything. I think we 'might' have a soft spot - but maybe not, it's a 
worry.

> libraries like the GSL (see
> attached) are highly optimised and easily wrapped/"plundered".
> 

Yeah, such suggestions always sound good - to me too on first glance. 
The devils are in the details...

In looking at the solvers I've looked on and off at gsl, eigen, Intel's 
embree(sp?) package and others. I borrowed ideas for updates to our 
common quadratic solver from a CERN math package. The julia language 
itself is interesting in that it might eventually be a path to an llvm 
jit implementation POV-Ray could use - but I think it too unstable to 
consider seriously at this point. Julia is in the shiny, new, gazillion 
commits a day phase. Aside: I see julia as an implementation of try this 
math on the fly ideas CERN has been doing themselves for a long time by 
hacking C or C++. So many languages, packages, and papers out there... 
One just drowns in the noise.

I'm looking again at eigen's nD vector support of late as an alternative 
to vector.h which - it appears - is tangled in a negative performance 
impact 3.7 to 3.8. But more interested due my immediate solver work 
needs for flexibility with respect to the 'n' part of nD. I'd like our 
vector.h to be just what I need and it isn't. :-)

Anyway. What can I say somewhat quickly. With my solver work one aim has 
been moving my code in a direction which makes plugging in a common 
library more doable. Still, lots of details would hang us up. Just 
trying to plug in standard solvers where it could be done technically 
(you'd get roots) is iffy because ours are often ray tracer tweaked 
solvers. A lot of the code you find, in sage for example, has the 
solvers set up for more than direct on floating point hardware reals too 
- meaning the code is often built upon largish software packages 
themselves - which makes extracting just what we want harder.

Making parts and pieces of gsl et al available as functions in the 
POV-Ray VM could be interesting. There, not be being tangled in the 
larger POV-Ray code base might make it easier to do.

Bill P.

[William F Pokorny] Re: v3.8 Isosurface artefacts test case. Windows... [2373 days and 10 minutes ago]

Tue, 15 Oct 2019 11:54:22 GMT

On 10/13/19 3:15 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> I'm not at all sure what deep C++ functions and libraries you're dealing with -
> that gets down to a deeper level than I have ever gone.
> 
> I think I understand what you're struggling with - it's akin to the coincident
> surface problem - so let me ask - would adding something like crand / jitter /
> some other random noise to the function make it better or worse?
> Say, something with a range from 0.99999 to 1.00001?   Or 1+/- E-7?
> 
> Not that it solves the underlying problem, but since it went undiscovered / was
> well enough hidden for _this_ long, maybe the thing to do is just build a
> deeper, plusher rug to sweep it under, with the humblest of apologies and a most
> heartfelt promise to come back and fix it "later"   ;)
> 

:-)

Often I bump the isosurface boundary a little, hide or avoid parts not 
right - ten plus years of it. Often, I walk away from ideas in 
frustration because POV-Ray doesn't work as intended.

I hit the issues here more than most because I play with isosurfaces. It 
should be the tiling patterns and others provide a rapid path to complex 
shapes with low gradients. Shapes where we can use all the usual pattern 
modifiers and extensions. The larger mechanisms are there, but they 
don't completely work. It's frustrating.

Your recent posts in part motivated me push again on tiling patterns 
with isosurfaces. I can these days often determine the core problems in 
the source code. I uttered the words, "let's figure this out." (He talks 
to himself too...)

Started expecting a problem or two. Found a half a dozen bugs / 
shortcomings. I've in hand code addressing most. A worry the changes 
ripple into parts of POV-Ray in ways I don't presently see. The 
abs/min/max concerns are secondary and general.

Many of my wild ideas require warps - bending assemblies rather than 
blobbing assemblies. I often cannot avoid the mod/fmod harmonics without 
introducing visible seams due the avoidance. I'm stuck between a rock 
and a hard place, off the beaten path - in the weeds.

Speaking of rugs - and now completely drifting - I believe a secrete 
attraction of physically-based / stochastic rendering methods is the 
approach covers for train loads of numerical sin. Rugs and trains - 
where's Ton... ;-)

> 
> It's always the edge cases that take 90% of the time...   :|

Yep!

> 
> Perhaps there's something along the lines of this that might spark some ideas?
>
http://news.povray.org/povray.general/thread/%3Cweb.5c85aaecd4241a93765e06870%40news.povray.org%3E/
> 
Yes, I remember. A similar discussion. :-)

Bill P.

[jr] Re: v3.8 Isosurface artefacts test case. Windows... [2374 days 14 hours and 49 minutes ago]

Sun, 13 Oct 2019 21:15:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/13/19 11:19 AM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> On 10/7/19 1:07 PM, jr wrote:
> >>> William F Pokorny <ano### [at] anonymousorg> wrote:
> >>>> Perhaps, finally, a good test case for isosurface artefacts I've worked
> >>>> around for years! Confirmation Windows / OSX showing similar artefacts
> >>>> would be useful. Linux users not on Ubuntu 18.04 too.
> >>>> ...
> >>>
> >>> same artefacts (identical looking) on a Slackware box, using
> >>> 3.8.0-alpha.10013324.unofficial.
> >>>
> >> Thanks jr.
> >
> > pleasure.
> >
> > (am dismayed -- riled, actually -- that no Windows/Mac users found the few
> > minutes it took, apparently)
> >
>
> :-) Ah, everyone is busy and focused upon what they're focused upon. I'm
> bad at even minor task switching/juggling. Plus! Could be they see the
> man off wandering in the weeds - as a man off wandering in the weeds.

quite the image..  </grin>


> ...
> The code involved makes use of abs/fabs, min, max and the like.
> Behaviors of which - especially when you don't get the expected C++
> standard library version(1) - can be different.
>
> (1) - As happened with vector.h abs() use when linux users initially
> tried the v3.8 user defined camera. The immediate fix was to use fabs(),
> but on my to-do, someday, list to look at vector.h more closely. I
> suspect it still the case we are getting the c99 math functions in
> vector.h and not the standard library versions due cyclic includes, but
> maybe not, and maybe I should stop looking for weeds to whack.
>
> Related to (1): Had the thought to perhaps enforce std::abs, std::min,
> std::max use over bare abs/fabs ?/..., min, max names enabled with
> 'using...' statements in coretypes.h & types.h. These in particular are
> known to have MS VS to other compiler implementation differences.

in a way I'm surprised that POV-Ray does not contain its own low-level maths
library, I'd have thought that an advantage.  so, I wonder (not knowing the code
base + off the top of my head) whether collecting various low-level routines
into a "convenience" library included with POV-Ray would not help with platform
independence/"implementation differences".  libraries like the GSL (see
attached) are highly optimised and easily wrapped/"plundered".


regards ,jr.

[Bald Eagle] Re: v3.8 Isosurface artefacts test case. Windows... [2374 days 16 hours and 44 minutes ago]

Sun, 13 Oct 2019 19:20:04 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

I'm not at all sure what deep C++ functions and libraries you're dealing with -
that gets down to a deeper level than I have ever gone.

I think I understand what you're struggling with - it's akin to the coincident
surface problem - so let me ask - would adding something like crand / jitter /
some other random noise to the function make it better or worse?
Say, something with a range from 0.99999 to 1.00001?   Or 1+/- E-7?

Not that it solves the underlying problem, but since it went undiscovered / was
well enough hidden for _this_ long, maybe the thing to do is just build a
deeper, plusher rug to sweep it under, with the humblest of apologies and a most
heartfelt promise to come back and fix it "later"   ;)


It's always the edge cases that take 90% of the time...   :|

Perhaps there's something along the lines of this that might spark some ideas?
http://news.povray.org/povray.general/thread/%3Cweb.5c85aaecd4241a93765e06870%40news.povray.org%3E/

[William F Pokorny] Re: v3.8 Isosurface artefacts test case. Windows... [2374 days 17 hours and 27 minutes ago]

Sun, 13 Oct 2019 18:37:00 GMT

On 10/13/19 11:19 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 10/7/19 1:07 PM, jr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>>> Perhaps, finally, a good test case for isosurface artefacts I've worked
>>>> around for years! Confirmation Windows / OSX showing similar artefacts
>>>> would be useful. Linux users not on Ubuntu 18.04 too.
>>>> ...
>>>
>>> same artefacts (identical looking) on a Slackware box, using
>>> 3.8.0-alpha.10013324.unofficial.
>>>
>> Thanks jr.
> 
> pleasure.
> 
> (am dismayed -- riled, actually -- that no Windows/Mac users found the few
> minutes it took, apparently)
> 
>> ...
> 
> regards, jr.
> 

:-) Ah, everyone is busy and focused upon what they're focused upon. I'm 
bad at even minor task switching/juggling. Plus! Could be they see the 
man off wandering in the weeds - as a man off wandering in the weeds.

While I think I understand what's happening, results from POV-Ray 
compiled with other compilers still of some interest should anyone be 
motivated to test.

---
The code involved makes use of abs/fabs, min, max and the like. 
Behaviors of which - especially when you don't get the expected C++ 
standard library version(1) - can be different.

(1) - As happened with vector.h abs() use when linux users initially 
tried the v3.8 user defined camera. The immediate fix was to use fabs(), 
but on my to-do, someday, list to look at vector.h more closely. I 
suspect it still the case we are getting the c99 math functions in 
vector.h and not the standard library versions due cyclic includes, but 
maybe not, and maybe I should stop looking for weeds to whack.

Related to (1): Had the thought to perhaps enforce std::abs, std::min, 
std::max use over bare abs/fabs ?/..., min, max names enabled with 
'using...' statements in coretypes.h & types.h. These in particular are 
known to have MS VS to other compiler implementation differences.

Bill P.

[jr] Re: v3.8 Isosurface artefacts test case. Windows... [2374 days 20 hours and 44 minutes ago]

Sun, 13 Oct 2019 15:20:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/7/19 1:07 PM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> Perhaps, finally, a good test case for isosurface artefacts I've worked
> >> around for years! Confirmation Windows / OSX showing similar artefacts
> >> would be useful. Linux users not on Ubuntu 18.04 too.
> >> ...
> >
> > same artefacts (identical looking) on a Slackware box, using
> > 3.8.0-alpha.10013324.unofficial.
> >
> Thanks jr.

pleasure.

(am dismayed -- riled, actually -- that no Windows/Mac users found the few
minutes it took, apparently)

> ...


regards, jr.

[William F Pokorny] Re: v3.8 Isosurface artefacts test case. Windows... [2375 days 18 hours and 7 minutes ago]

Sat, 12 Oct 2019 17:57:36 GMT

On 10/7/19 1:07 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Perhaps, finally, a good test case for isosurface artefacts I've worked
>> around for years! Confirmation Windows / OSX showing similar artefacts
>> would be useful. Linux users not on Ubuntu 18.04 too.
>> ...
> 
> same artefacts (identical looking) on a Slackware box, using
> 3.8.0-alpha.10013324.unofficial.
> 
> regards, jr.
> 
Thanks jr.

Well... What's going on is subtle and it's an exposure in all continuous 
patterns used with pigments, isosurfaces, whatever.

The root is the SDL use of mod() or, internal to POV-Ray itself, the use 
of fmod() when executing this bit of code - used by all but the two 
potential patterns currently(2):

     if(waveFrequency != 0.0)
         value = fmod(value * waveFrequency + wavePhase, 1.00001); \
// TODO FIXME - magic number! ....

or this bit when functions are used in pattern{} / virtual pattern blocks:

     DBL value = GenericScalarFunctionInstance(pFn, \ 
pThread).Evaluate(EPoint);
     return ((value > 1.0) ? fmod(value, 1.0) : value);

When the mod()/fmod() numerator value is a harmonic of the denominator, 
the resultant value suddenly jumps to 0.0 - though that's not always the 
right thing to do.

In the example scene image I was normalizing the discontinuities of 
tiling 11 so it acts like a linear displacement function for the 
isosurface sheet. The denominator is therefore 1/3 and harmonics of that 
go to 0. Further, due my container sides being at -1,+1 I'm sitting on a 
harmonic and I get spurious shapes.

However, it's a general pattern problem. Should users specify a pattern 
frequency value >1 or use a similar multiplier for a function's values, 
the multiples of 1, 1.00001 or both, depending, are exposed to harmonics 
where the resultant value jumps to zero.

Most often it will be seen with isosurface box containers given they can 
somewhat easily have sides exactly on the mod() harmonics. When the 
artefact otherwise shows up, it will usually be a line of noise perhaps 
the wrong color from a pigment map or similar somewhere is the image. 
I've seen and seen reports of such artefacts over the years. Expect this 
issue sometimes the cause.

Aside: Yes, the pattern { function { } } treatment is different than 
what pattern { } or pigment { agate/etc .... } does, which is not good. 
The former does a better job of of deciding when to apply fmod and does 
it correctly with a denominator of 1.0 - but it ignores the negative 
value space. The latter has that odd 1.00001 denominator(2); the odd 
skipping of calculations when the frequency is 0.0 - and negative values 
are inverted by magnitude. The last something OK with defined patterns 
(gradient x etc), but potentially confusing and sometimes at odds with 
functions(1). Weird stuff can happen with a function's negative values 
due pattern use.

I've used the trick of specifying a frequency 0 when going after a 
little more performance, but I've come up with no reason to not let a 
user take the resultant values to 0 using frequency 0. In fact, that 
with phase provides a nice way of walking a *_map.

Unsure what all to do here, but certainly going to fix what I can in my 
POV-Ray version.

---
Generally we want - on the mod(numerator/denominator) harmonics to 
return the actual value divided by div(numerator/denominator) - instead 
of 0.0. On a 5 day driving trip from LA to NYC across America, it makes 
no sense to fly back to sleep in LA every night. :-)

We need updates for the two bits of code above in pattern.cpp and we 
need a new inbuilt VM function which implements the smarter mod()/fmod() 
to zero - only when we really want zero - functionality. Currently 
calling it f_npmod() - normalized pattern mod(). Also passing an extra 
multiplier to allow normalization back to a 0-1 range.

I have a first pass f_npmod() and pattern.cpp updates. Tested creating 
isosurface 'sheets' from all 27 tiling patterns. 15 of those originally 
hit the mod()/fmod() jump to zero issue. My initial code cleaned up all 
but 6 of those. 4 of those 6 had other numerical issues in the tiling 
code like not clamping to 1.0 where the old 1.00001 fmod allowed the 
tiny overrun.

I'm left with two tiling patterns still an issue in tilings 19 and 20.

I'm attaching an image for 20 showing the initial pattern.cpp 'mod' 
fixes and new f_mpmod function. These partly fixed issues in 19 and 20 
as seen left to right - but there is still something wrong. It looks 
like an incorrect count in x or similar at the isosurface z sides is 
part of it, but I've not found the problem(s).

----
Aside: All through the tiling code there are bits and comments like:

   answer = max(answer, 2.000001); // TODO FIXME - magic number! Should 
use nextafter()

In the tilings changed, I checked nextafter() and never did it work as 
an alternative. Thus far, the magic numbers look to be addressing real 
numerical issues. I've changed these lines to read:

   answer = max(answer, 2.0+1e-7); // +1e-7 add & magnitude due 
numerical fuzziness.

or similar.

It's been the case the original extra amounts has ranged between 1e-6 
and 1e-8, but in all cases 1e-7 worked fine. Interestingly, the value 
adjustments are of a similar order of magnitude to the min intersection 
depth I settled on with the solver accuracy work (4.4e-8).

---

Expect I'll play for quite a while with my changes before opening a 
github issue and publishing a code branch. All patterns are touched by 
my changes. In the meantime, you have my ramblings - for what they're worth.

Bill P.

(1) - Perhaps allow too fabs() with pattern { functions {} } over 
if(value<0) value -= floor(value);. I don't know. Whatever might come 
would be an option so as to not break scenes built on the current 
inverting of the negative (0-1) magnitudes. I've done nothing with this 
secondary concern around using other than >=0 valued functions as patterns.

(2) - The odd 1.00001 fmod denominator has largely hidden the base issue 
- forever. Why someone did it I'd bet. Not very often will usage land 
exactly on a harmonic of 1.00001.

[jr] Re: v3.8 Isosurface artefacts test case. Windows... [2380 days 18 hours and 54 minutes ago]

Mon, 7 Oct 2019 17:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Perhaps, finally, a good test case for isosurface artefacts I've worked
> around for years! Confirmation Windows / OSX showing similar artefacts
> would be useful. Linux users not on Ubuntu 18.04 too.
> ...

same artefacts (identical looking) on a Slackware box, using
3.8.0-alpha.10013324.unofficial.


regards, jr.

[William F Pokorny] v3.8 Isosurface artefacts test case. Windows/OSX... [2380 days 20 hours and 24 minutes ago]

Mon, 7 Oct 2019 15:40:05 GMT

Perhaps, finally, a good test case for isosurface artefacts I've worked 
around for years! Confirmation Windows / OSX showing similar artefacts 
would be useful. Linux users not on Ubuntu 18.04 too.

Looks like something goes wrong when an isosurface's function has an 
inflection (local min/max) where rays cross the containing box/sphere 
surface. Also looks like the inflection can be well away from any shape 
created inside the container; It need not be near the threshold value.

Move the container sides away from the inflection and things work fine - 
also my long standing hack work-around. In the attached test case, three 
of the four containing box sides are at an inflection for the, adjusted, 
tiling pattern function. The last side isn't - by a tiny amount - and no 
artefacts on that side.

See attached image and scene file for v3.8.

Bill P.

[Subclick] Re: A Unix script and a few sample scenes [2402 days 16 hours and 45 minutes ago]

Sun, 15 Sep 2019 19:19:27 GMT

Thank you very much.

[William F Pokorny] Re: A Unix script and a few sample scenes [2404 days and 33 minutes ago]

Sat, 14 Sep 2019 11:31:11 GMT

On 9/13/19 11:07 AM, William F Pokorny wrote:
...
> 
> I'll create a branch with your fixes and open an issue so they won't be 
> forgotten.
> 

See:

https://github.com/POV-Ray/povray/issues/382

Bill P.

[William F Pokorny] Re: A Unix script and a few sample scenes [2404 days 20 hours and 57 minutes ago]

Fri, 13 Sep 2019 15:07:43 GMT

On 9/12/19 5:22 PM, Subclick wrote:
> Iâ€™ve recently installed POV-Ray 3.7 for Unix, and one of the first
> things I did afterwards was to run the scripts
â€œallanim.shâ€,
> â€œallscene.shâ€ and
â€œportfolio.shâ€ to generate HTML documents showcasing
> the ray tracerâ€™s capabilities.  I ran into the
â€œreflection.iniâ€ issue
> reported by ThH nearly four years ago, as well as a few that donâ€™t
seem
> to have been mentioned or fixed anywhere.  The attached archive contains
> the following files edited by me from the ones in the 3.7.0 release.
> Maybe I should have used the 3.8.0 ones instead, but Iâ€™ve read
> _somewhere_ that branch has been more or less abandoned.
> 
...
> 

Updates of the kind outlined are made only in the master, v3.8 
branch(1). Compile related issues cropping up over time have been fixed 
in the v3.7 stable branch since release - buts that's it. Linux package 
providers are at v3.7 only as far as I know.

I agree with the changes you've made with regards to updating the v3.8 
branch. The allscene.sh update will need to be merged with what's in the 
master branch as it has otherwise changed.

I'll create a branch with your fixes and open an issue so they won't be 
forgotten.

The reflection.ini update was made in the master branch very shortly 
after ThH's posting.

Bill P.

(1) - My understanding is it was the (got to beta something) v3.71 
release which was dropped for a v3.8 one. The action coming after a few 
users pointed out the changes more accurately represented another 
substantial update and not a patch release to v3.7.

[Subclick] A Unix script and a few sample scenes [2405 days 14 hours and 42 minutes ago]

Thu, 12 Sep 2019 21:22:32 GMT

Iâ€™ve recently installed POV-Ray 3.7 for Unix, and one of the first
things I did afterwards was to run the scripts
â€œallanim.shâ€,
â€œallscene.shâ€ and
â€œportfolio.shâ€ to generate HTML documents showcasing
the ray tracerâ€™s capabilities.  I ran into the
â€œreflection.iniâ€ issue
reported by ThH nearly four years ago, as well as a few that donâ€™t
seem
to have been mentioned or fixed anywhere.  The attached archive contains
the following files edited by me from the ones in the 3.7.0 release.
Maybe I should have used the 3.8.0 ones instead, but Iâ€™ve read
_somewhere_ that branch has been more or less abandoned.

â€¢ povray/unix/scripts/allscene.sh

The calling conventions detailed in the comments specify eight possible
arguments, but the script only took six into account, ignoring the rest.
I noticed the problem when the script failed to make an HTML file.

â€¢ povray/distribution/scenes/animations/float2/float2.pov

Missing â€œequalsâ€ sign in the text object showing the
â€˜incâ€™ function.

â€¢ povray/distribution/scenes/animations/float4/float4.pov

In the text object, â€œatan2(B,C)â€ should be
â€œatan2(B,A)â€, which is the
value actually calculated.

â€¢ povray/distribution/scenes/portfolio/allobjects.pov

The macro â€˜Sphere_Of_Spheresâ€™ created two
coÃ¯ncident copies of each of
the spheres lying on either of the two first meridians, and did not
check that there was enough room around the poles.  For instance, in
this scene itself, there were two spheres very visibly colliding at the
pole facing the viewer.

Iâ€™ve included two images made with the original macro and the fixed
one,
in the â€œallobjects_imagesâ€ folder.  In the latter,
you need to pay very
close attention to notice the pole at all, revealed only by the slightly
wider space around one sphere, which already happened anyway when a
parallelâ€™s length is close to allowing an extra sphere, but not quite
there.

â€¢ povray/distribution/scenes/portfolio/readme.txt

Repeated word _and_ in the third line (second non-empty one).

[William F Pokorny] Re: Documenting some inside test (object pattern... [2583 days 12 hours and 39 minutes ago]

Mon, 18 Mar 2019 23:24:47 GMT

On 3/17/19 8:11 AM, William F Pokorny wrote:
> On 2/12/19 12:52 PM, William F Pokorny wrote:
...
> 
> So... The one remaining object inside test issue - which I still think 
> real - is the spindle torus union case. The object inside test is acting 
> like the merge variant. Image attached.
> 

On taking a deeper look at this last torus union test, I think it OK too 
- or at least consistent with current generic union media behavior with 
one defined interior.

If three spheres are nested Matryoshka doll style as a union, the media 
based on ray intervals is different and never consistent with the inside 
object test today.

In the attached image the sphere union cases are shown in the left 
column. The inside sphere test results in the middle column. Differences 
in the right column as usual.

In the top row of the image the union is set up with the form:

#declare Union00 = union {
   object { Sphere00 }
   object { Sphere01 }
   object { Sphere02 }
   hollow
   material {
...
   }
}

Which I take to be like the torus union case and the behavior is 
consistent. In the bottom row the union is set up with the form:

#declare Sphere00 = sphere { <0,0,0>, 0.45 hollow
   material { Material00 }
}
#declare Sphere01 = sphere { <0,0,0>, 0.20 hollow
   material { Material00 }
}
#declare Sphere02 = sphere { <0,0,0>, 0.07 hollow
   material { Material00 }
}

#declare Union00 = union {
   object { Sphere00 }
   object { Sphere01 }
   object { Sphere02 }
}

Interesting result, eh?

I've always avoided unions with media where shapes overlap. Still, I 
thought only surfaces would be ignored - should they have a non-clear 
texture - and that we'd always get multiple, end to end, surface to 
surface media intervals instead of one. Instead, what happens media wise 
looks more complicated. I see here too behavior that could be very 
useful - if solidly defined and understood.

Why the different union media behavior - I'm not sure. My first guess is 
that when the interior is defined on each sphere the parser can flatten 
the spheres scene wise and it cannot where the interior has been applied 
to the union alone. If right, the intervals are what they are media wise 
and I can see how the result comes about.

Anyone better understand what is going on with unions and media here?

Wonder what happens if we use either of these union forms in further 
csg. Also now wondering what really happens with semi-transparent 
textures, IORs and union surfaces.

Aside: If using merge instead of union, results are always consistent 
with the object inside test.

Bill P.

[William F Pokorny] Re: Documenting some inside test (object pattern... [2584 days 23 hours and 53 minutes ago]

Sun, 17 Mar 2019 12:11:40 GMT

On 2/12/19 12:52 PM, William F Pokorny wrote:
> On 2/12/19 9:27 AM, William F Pokorny wrote:
>> not today returning the correct inside test results. Further, I've long 
> ...
>>
>> Anyway, more stuff for the todo list.
>>
>> Bill P.
> 
> As all too often happens these days with my ever failing old brain - I 
> remembered a few minutes ago a cylindrical isosurface done years ago. 
> One which could not have worked without the cylindrical inside test 
> working properly.
> 
> So check again the code for test cases 1-3 in my post and I screwed 
> those three up... They're OK.
> 
> Proof I need to go do something else for a while.
> 
> Bill P.

Looked at the media intensity issues today and they too were my fault. 
Typo carried into some of the test cases as a best guess.

So... The one remaining object inside test issue - which I still think 
real - is the spindle torus union case. The object inside test is acting 
like the merge variant. Image attached.

Bill P.

[William F Pokorny] Re: Documenting some inside test (object pattern... [2617 days 18 hours and 12 minutes ago]

Tue, 12 Feb 2019 17:52:45 GMT

On 2/12/19 9:27 AM, William F Pokorny wrote:
> not today returning the correct inside test results. Further, I've long 
...
> 
> Anyway, more stuff for the todo list.
> 
> Bill P.

As all too often happens these days with my ever failing old brain - I 
remembered a few minutes ago a cylindrical isosurface done years ago. 
One which could not have worked without the cylindrical inside test 
working properly.

So check again the code for test cases 1-3 in my post and I screwed 
those three up... They're OK.

Proof I need to go do something else for a while.

Bill P.

[William F Pokorny] Documenting some inside test (object pattern) is... [2617 days 21 hours and 37 minutes ago]

Tue, 12 Feb 2019 14:27:45 GMT

While the test set is still not complete even with respect to covering 
all shape types, I've better flushed out test cases for verifying the 
inside test mechanism. In the process found some of our basic shapes are 
not today returning the correct inside test results. Further, I've long 
had on my list that some of the media intensities look suspect to me for 
the non-inside test based versions and I'll show one example - blobs.

In the attached image master branch used at commit 054e75c except the 
bottom row which uses the my new solver branch given how bad the blob 
result for speckles was with the master branch in the next to bottom row.

The top row shows an expected result for shapes in general. In this case 
for a bezier_spline prism. When things are working the media result in 
the left column uses the shape straight up as a container with constant 
media density. The middle column shows a media result using a matching 
inside-test -> object-pattern -> function based media. Should be the two 
approaches basically match though they won't be identical.

Rows one through four showing shapes where the inside test is failing.

The bottom two rows show a class of cases on my list for a while where 
it looks to me like the normal shape-intersection media intensities are 
too high. Not dug at all - bounding issue for the inside test version 
maybe - don't know.

- Row 0 A good test.

- Row 1 the cylinder.

- Row 2 the cone (cone and cylinder really the same code internally).

- Row 3 superellipsoid set as a sphere (a).

- Row 4 the new torus-union variety is acting like the torus-merge for 
the inside test.

- Row 5 blob test with master. Speckling bad. Shape OK but intensities
puzzling.

- Row 6 blob done test with new solver branch re-based off master.

(a) - Remember the peeling paint superellipsoid scene of Thomas's where 
I tried to use the soft_object to create actual peeling paint on the 
fly. Remember too how it was offset away from the surface of the 
superellipsoid. I until yesterday though I had just gotten something 
wrong in my offset math - looks instead like the dang inside test is 
wrong (set for the largest box possible maybe)!

Anyway, more stuff for the todo list.

Bill P.

[William F Pokorny] Images for recent v3.8.0-x.freetype.1 post to po... [2620 days 17 hours and 20 minutes ago]

Sat, 9 Feb 2019 18:44:29 GMT

Images for recent v3.8.0-x.freetype.1 post to povray.beta-test

[StephenS] Win XP 32, test computer spec [3327 days 20 hours and 31 minutes ago]

Sat, 4 Mar 2017 15:33:42 GMT

Screen capture of two computers I use for beta testing.

Stephen S

[William F Pokorny] Re: Dokken [3353 days 20 hours and 33 minutes ago]

Mon, 6 Feb 2017 15:30:53 GMT

On 02/05/2017 03:29 AM, ThH wrote:
> Another old source...
>
> Find it at povray.text.scene-files:
> Different Results Between Versions, Dave Blandston, 07.08.2009
>
> The resulting image doesn't look right to me. What do you think?
>
> Any confirmations?
>

In his post Dave wrote: "This is my source for the Dokken logo. It 
renders fine with version 3.6.1a but does not render correctly with 
version 3.6.2."

On Ubuntu 16.04 linux I get the 'not-right' result with all my versions 
back through 3.5 which includes a version of 3.6.1.

It looks like the root of the problem is the following two values being 
set the same in Dokken.pov:

#local CornerRadius = .02;
#local EdgeRadius = CornerRadius;

which results in zero cylinder-radius, torus-major-radius(1) values in:

#macro BeveledCylinder (Top, Bottom, Radius, EdgeRadius)

    union {
       cylinder {<Top.x, Top.y, Top.z + EdgeRadius>, Bottom, Radius}
       cylinder {Top, Bottom, Radius - EdgeRadius}
       torus {
          Radius - EdgeRadius, EdgeRadius
          rotate 90 * x
          translate <Top.x, Top.y, Top.z + EdgeRadius>
          sturm
       } //torus
    } //union

#end //#macro BeveledCylinder

Using something like:

#local CornerRadius = .02;
#local EdgeRadius = CornerRadius/2;

works OK for me.

Bill P.

(1) - New 3.7.1 spindle torus features allow the minor radius to 
self-intersect for various results, but it's not the right 'fix' here.

[Kenneth] Re: Dokken [3354 days 12 hours and 19 minutes ago]

Sun, 5 Feb 2017 23:45:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Unfortunately, I don't know what Dave's original scene is supposed to look like,
> as a comparison (or what POV-Ray version he originally wrote it with)

Oops, Dave did mention the versions he used-- 3.6.1a vs 3.6.2.  Right now, I
don't have either older version installed, to further test the scene.

[Alain] Re: Dokken [3354 days 12 hours and 23 minutes ago]

Sun, 5 Feb 2017 23:41:25 GMT

Le 17-02-05 Ã  03:29, ThH a Ã©crit :
> Another old source...
>
> Find it at povray.text.scene-files:
> Different Results Between Versions, Dave Blandston, 07.08.2009
>
> The resulting image doesn't look right to me. What do you think?
>
> Any confirmations?
>
> povray -- version
>
> POV-Ray 3.7.2-alpha.unofficial
>
> This is an unofficial version compiled by:
>  ThH <no.spam@address>
>  The POV-Ray Team is not responsible for supporting this version.
>
> Copyright 1991-2017 Persistence of Vision Raytracer Pty. Ltd.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Built-in features:
>   I/O restrictions:          enabled
>   X Window display:          enabled (using SDL)
>   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
>   Unsupported image formats: -
>
> Compilation settings:
>   Build architecture:  x86_64-unknown-linux-gnu
>   Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
>   Compiler vendor:     gnu
>   Compiler version:    g++ 4.9.2
>   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
> -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math
> -march=native -pthread
>
> --
> Thorsten aka ThH

Utherly broken !
All the parts jutting out from Â«DokkenÂ» should NOT be there at
all. The 
original render did not have those.

Alain

[Kenneth] Re: Dokken [3354 days 12 hours and 49 minutes ago]

Sun, 5 Feb 2017 23:15:00 GMT

ThH <no.spam@address> wrote:
> Another old source...
>
> Find it at povray.text.scene-files:
> Different Results Between Versions, Dave Blandston, 07.08.2009
>
> The resulting image doesn't look right to me. What do you think?
>

On Windows 7 (64-bit), I get the same visual results as you (after changing
Dave's assumed_gamma 2.0 to 1.0). I ran two versions of POV-Ray: one of the
latest development builds (8927145) , and the latest 3.7.1-beta 2 version.
Unfortunately, I don't know what Dave's original scene is supposed to look like,
as a comparison (or what POV-Ray version he originally wrote it with) :-(  The
render does look kind of odd, though, with those "spiky" things jutting out.

As a side note: When I first ran Dave's scene, BOTH POV-Ray versions I used
actually CRASHED. The culprit was his use of
   charset utf8
in his global_settings block. Without that, the scene runs OK. I think this
particular problem has recently been mentioned in the newsgroups, re:
the 3.7.1 beta 2 release. But I was surprised that the same crash happened with
the earlier development build.

[ThH] Dokken [3355 days 3 hours and 35 minutes ago]

Sun, 5 Feb 2017 08:29:13 GMT

Another old source...

Find it at povray.text.scene-files:
Different Results Between Versions, Dave Blandston, 07.08.2009

The resulting image doesn't look right to me. What do you think?

Any confirmations?

povray -- version

POV-Ray 3.7.2-alpha.unofficial

This is an unofficial version compiled by:
  ThH <no.spam@address>
  The POV-Ray Team is not responsible for supporting this version.

Copyright 1991-2017 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built-in features:
   I/O restrictions:          enabled
   X Window display:          enabled (using SDL)
   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
   Unsupported image formats: -

Compilation settings:
   Build architecture:  x86_64-unknown-linux-gnu
   Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
   Compiler vendor:     gnu
   Compiler version:    g++ 4.9.2
   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math 
-march=native -pthread

--
Thorsten aka ThH

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 20 hours and 18 minutes ago]

Sun, 28 Feb 2016 15:46:33 GMT

Am 28.02.2016 um 16:21 schrieb ThH:

> Think ixquick will find it for me ;)
>
> "few bucks"... Depends on how much is few. Will find out :)

Ok. This is the _big_ solution ;)

Will be remember it, if I need a _big_ solution.

Thanks again clipka :)

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 20 hours and 22 minutes ago]

Sun, 28 Feb 2016 15:42:31 GMT

Am 28.02.2016 um 16:09 schrieb ThH:

> Will try convert in a few minutes ;)

convert is the way for me. Thanks you for the example above Bald Eagle :))

Free and for the terminal ;)

As said before: Always learning something new :)

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 20 hours and 43 minutes ago]

Sun, 28 Feb 2016 15:21:04 GMT

Am 28.02.2016 um 16:09 schrieb clipka:

> If you are willing to invest a few bucks, I can highly recommend Scooter
> Software's BeyondCompare 4.

Thank you clipka.

Think ixquick will find it for me ;)

"few bucks"... Depends on how much is few. Will find out :)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 20 hours and 55 minutes ago]

Sun, 28 Feb 2016 15:09:06 GMT

Am 28.02.2016 um 15:43 schrieb ThH:

> Does anyone know of a software (Linux) to compare 2 images?

If you are willing to invest a few bucks, I can highly recommend Scooter
Software's BeyondCompare 4.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 20 hours and 56 minutes ago]

Sun, 28 Feb 2016 15:08:40 GMT

Am 28.02.2016 um 15:53 schrieb Bald Eagle:

>> Does anyone know of a software (Linux) to compare 2 images?
>
> OpenCV library
> Paint.NET
> Photoshop
> ImageMagick
> convert img1 img2 -fx "(((255*u)&(255*(1-v)))|((255*(1-u))&(255*v)))/255"
> img_out
>
>
> Hope that gets you some sort of useful start...

I'm sure it will. Thank you Bald Eagle :)

Will try convert in a few minutes ;)

[Bald Eagle] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 21 hours and 9 minutes ago]

Sun, 28 Feb 2016 14:55:01 GMT

ThH <no.spam@address> wrote:


> Slightly off-topic...
>
> Does anyone know of a software (Linux) to compare 2 images?

OpenCV library
Paint.NET
Photoshop
ImageMagick
convert img1 img2 -fx "(((255*u)&(255*(1-v)))|((255*(1-u))&(255*v)))/255"
img_out


Hope that gets you some sort of useful start...

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 21 hours and 22 minutes ago]

Sun, 28 Feb 2016 14:42:45 GMT

Am 28.02.2016 um 15:29 schrieb clipka:

> My current favourite theory, however, is that the change in brightness
> is related to a change in the media computation. There, too, a
> long-standing flaw led to another systematic error, which has also been
> fixed in 3.7.1.

Currently trying some more scenes.

I had the impression the effect might be linked to media.

> Note that this can explain the differences in abyss.pov, too.

I see.

Slightly off-topic...

Does anyone know of a software (Linux) to compare 2 images?

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 21 hours and 35 minutes ago]

Sun, 28 Feb 2016 14:29:12 GMT

Am 28.02.2016 um 12:24 schrieb William F Pokorny:
> On 02/28/2016 05:04 AM, clipka wrote:
>>
>> You might want to test the newest version though :D
>>
> 
> Cool! You got the bug - thanks.
> 
> I am seeing some shift in optics.pov result 3.7.0 stable to POV-Ray
> 3.7.1-alpha.8499454. I like the new, less intense, result over the old,
> but is this 3.7.0 to 3.7.1 change expected ?

There are various factors that could contribute.

For one thing, the old encoding/decoding scheme for the photon colour
data was flawed, leading to a systematic error in the photon brightness,
which has been fixed in 3.7.1. However, that doesn't seem to fit the
bill, as this error should have manifested as a slight bias towards
black, so that in 3.7.1 we should see an _increase_ rather than a
decrease in brightness.

Another thing is that the error in the photons code I've just fixed has
been around for quite a while, and _did_ already exist in 3.7.0; it just
didn't surface until the change in the encoding/decoding scheme
translated it into artifacts Unix systems. It _may_ be that the old
encoding/decoding scheme did already translate the error into artifacts,
and that they just were a lot less bright.

My current favourite theory, however, is that the change in brightness
is related to a change in the media computation. There, too, a
long-standing flaw led to another systematic error, which has also been
fixed in 3.7.1.

Note that this can explain the differences in abyss.pov, too.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 22 hours and 51 minutes ago]

Sun, 28 Feb 2016 13:13:02 GMT

Am 28.02.2016 um 13:40 schrieb ThH:

> Expected change... Interesting Question :)

abyss.pov 3.7.0 vs 3.7.1... Same result: 2 "different" Images.

Expected change ?

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3697 days 23 hours and 24 minutes ago]

Sun, 28 Feb 2016 12:39:51 GMT

Am 28.02.2016 um 12:24 schrieb William F Pokorny:

> I am seeing some shift in optics.pov result 3.7.0 stable to POV-Ray
> 3.7.1-alpha.8499454. I like the new, less intense, result over the old,
> but is this 3.7.0 to 3.7.1 change expected ?
>
> Bill P.

You're right 8)

Just did a 1200x900 render using the versions mentioned above...

Haven't noticed the "new look" while toying hunting for the error.

Expected change... Interesting Question :)

[William F Pokorny] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days and 39 minutes ago]

Sun, 28 Feb 2016 11:24:51 GMT

On 02/28/2016 05:04 AM, clipka wrote:
>
> You might want to test the newest version though :D
>

Cool! You got the bug - thanks.

I am seeing some shift in optics.pov result 3.7.0 stable to POV-Ray 
3.7.1-alpha.8499454. I like the new, less intense, result over the old, 
but is this 3.7.0 to 3.7.1 change expected ?

Bill P.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 1 hour and 23 minutes ago]

Sun, 28 Feb 2016 10:41:31 GMT

Am 28.02.2016 um 11:12 schrieb ThH:
> Am 28.02.2016 um 11:04 schrieb clipka:
>
>> No need for any more toying.
>>
>> You might want to test the newest version though :D

Case closed. You made it :)))

Thank you and all those involved in the process...

High 5, 10, 15, 20, ... !

[Le Forgeron] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 1 hour and 25 minutes ago]

Sun, 28 Feb 2016 10:39:02 GMT

Le 28/02/2016 11:12, ThH a Ã©crit :
> Am 28.02.2016 um 11:04 schrieb clipka:
> 
>> No need for any more toying.
>>
>> You might want to test the newest version though :D

> Now let's build the new version :))


POV-Ray 3.7.1-alpha.8499454.unofficial
Gitid: 5b5e312523b226e5be1409f270325b66b5c92bf9

no more problem in optics.pov and gnu compiler

Now I have to report it to my branch too.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 1 hour and 53 minutes ago]

Sun, 28 Feb 2016 10:11:34 GMT

Am 28.02.2016 um 11:04 schrieb clipka:

> No need for any more toying.
>
> You might want to test the newest version though :D

Great. Will.

Couldn't resist...

Changing the falloff:

Relevant code from the second light source

     //spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0> // 00 
(Original optics.pov)
     //spotlight radius 0.3 falloff 0.35*20 point_at < 0, 0.5, 0> // 01
     //spotlight radius 0.3 falloff 0.35*10 point_at < 0, 0.5, 0> // 02
     //spotlight radius 0.3 falloff 0.35*5 point_at < 0, 0.5, 0> // 03
     //spotlight radius 0.3 falloff 0.35*.25 point_at < 0, 0.5, 0> // 04
     //spotlight radius 0.3 falloff 0.35/.25 point_at < 0, 0.5, 0> // 05
     //spotlight radius 0.3 falloff 0.35/5 point_at < 0, 0.5, 0> // 06
     //spotlight radius 0.3 falloff 0.35/10 point_at < 0, 0.5, 0> // 07
     spotlight radius 0.3 falloff 0.35/20 point_at < 0, 0.5, 0> // 08

Now let's build the new version :))

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 2 hours ago]

Sun, 28 Feb 2016 10:04:30 GMT

Am 28.02.2016 um 10:45 schrieb ThH:
> Am 28.02.2016 um 09:37 schrieb ThH:
> 
>> To approaches concerning the media-box:
> 
> Two... Heaven!

No need for any more toying.

You might want to test the newest version though :D

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 2 hours and 19 minutes ago]

Sun, 28 Feb 2016 09:45:02 GMT

Am 28.02.2016 um 09:37 schrieb ThH:

> To approaches concerning the media-box:

Two... Heaven!

Moving the mirrors +<1,0,0>...

// 00 - Original optics.pov
object {Mirror(<-3, 0, 0>, 3*45, 2, 1, BlueMirrorTex)}
object {Mirror(<-3, 0, 3>,-45, 2, 1, MirrorTex1)}

// 01 - Variation 1
object {Mirror(<-3, 0, 0>+<1,0,0>, 3*45, 2, 1, BlueMirrorTex)}
object {Mirror(<-3, 0, 3>+<1,0,0>,-45, 2, 1, MirrorTex1)}

// 00 - Original optics.pov
//object {Mirror(<-1, 0, 0>, 180+22.5, 2, 1, RedMirrorTex)}
//object {Mirror(<-3, 0,-2>, 22.5, 2, 1, MirrorTex1)}

// 02 - Variation 2
object {Mirror(<-1, 0, 0>+<1,0,0>, 180+22.5, 2, 1, RedMirrorTex)}
object {Mirror(<-3, 0,-2>+<1,0,0>, 22.5, 2, 1, MirrorTex1)}

// 03 - Variation 3
// 01 + 02

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 3 hours and 27 minutes ago]

Sun, 28 Feb 2016 08:37:02 GMT

Am 28.02.2016 um 09:14 schrieb ThH:

> I'm toddling off... Got some toying around to do ;)

Talking of high values...

What will happen using lower values?

To approaches concerning the media-box:

box {<-7,-0.1,-3>, < 6, 1, 4> hollow
     texture {pigment {color rgbf 1}}
     interior {
         media {
             //scattering {1, color White extinction 0} // 01 (Original 
optics.pov)
             //scattering {1, color White-<0,0,1> extinction 0} // 02
             scattering {1, color White extinction 0+12} // 3 (Docs: 
..artistic freedom...) // 03
             //emission color White*0.2
             method 3
             intervals 1 samples 4
         }
     }
     photons {target}
}

Of any use ?

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 3 hours and 51 minutes ago]

Sun, 28 Feb 2016 08:13:16 GMT

Am 28.02.2016 um 08:55 schrieb clipka
:
> Am 28.02.2016 um 08:07 schrieb ThH:
>
>> Will there be a new master in the near future? Please don't get me
>> wrong... Only asking because I would like to "play around" with the
>> latest master.
>
> Depends on your definition of "near future" ;)
>
> I guess I'll be able to figure out and fix the root cause today or
> tomorrow. Until then, I see no point in releasing some interim workaround.

Thanks for this info :)

I'm toddling off... Got some toying around to do ;)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 4 hours and 8 minutes ago]

Sun, 28 Feb 2016 07:55:54 GMT

Am 28.02.2016 um 08:07 schrieb ThH:

> Will there be a new master in the near future? Please don't get me
> wrong... Only asking because I would like to "play around" with the
> latest master.

Depends on your definition of "near future" ;)

I guess I'll be able to figure out and fix the root cause today or
tomorrow. Until then, I see no point in releasing some interim workaround.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 4 hours and 58 minutes ago]

Sun, 28 Feb 2016 07:06:19 GMT

Am 28.02.2016 um 07:59 schrieb clipka:
> Ha!
>
> Does this look familiar to anyone?

In deed. It does ;)

> It turns out that the root problem _is_ also present in the Windows
> version -- but it's masked by a peculiarity of the run-time library's
> handling of special floating-point values.
>
> What happens is that _somewhere_ in the photon computations one of the
> mathematical operations results in "not a sensible value", which carries
> over into the computed colour values. How such values behave in the
> conversion to the RGBE format depends on the run-time library
> implementation: On Windows it results in zero values, thus "healing" the
> problem. On Linux however, it results in rather high values instead.

Frustration turned into and idea. Fine :)

Will there be a new master in the near future? Please don't get me 
wrong... Only asking because I would like to "play around" with the 
latest master.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 5 hours and 4 minutes ago]

Sun, 28 Feb 2016 07:00:44 GMT

Am 28.02.2016 um 06:02 schrieb clipka:

> While this does show a clear correlation between the falloff parameter
> and the area where the error occurs, the geometry of that area is still
> a puzzle to me: For instance, why is the area farther out on the red leg
> than on the blue leg? And why is the area much farther out than the falloff?
>
> Can you do me a favor and toy around with the colours, the geometry of
> how the optical elements are arranged, and how this relates to the falloff?

Me likes toying around with this great piece of software. I will :)
>
> (BTW, when you post results, please include the details right away. Me
> having to ask for them unnecessarily bogs down the whole process.)

Ok. Understood.

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 5 hours and 5 minutes ago]

Sun, 28 Feb 2016 06:59:16 GMT

Ha!

Does this look familiar to anyone?

It turns out that the root problem _is_ also present in the Windows
version -- but it's masked by a peculiarity of the run-time library's
handling of special floating-point values.

What happens is that _somewhere_ in the photon computations one of the
mathematical operations results in "not a sensible value", which carries
over into the computed colour values. How such values behave in the
conversion to the RGBE format depends on the run-time library
implementation: On Windows it results in zero values, thus "healing" the
problem. On Linux however, it results in rather high values instead.

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 7 hours and 1 minute ago]

Sun, 28 Feb 2016 05:02:48 GMT

Am 27.02.2016 um 19:22 schrieb ThH:
> Am 27.02.2016 um 19:10 schrieb clipka:
> 
>> VERY promising. Whatever you did there, it has some definitive effect on
>> the symptoms.
>>
>> Details please.
> 
> Falloff:
> 
>     //spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0> // 1
>     //spotlight radius 0.3 falloff 0.35*10 point_at < 0, 0.5, 0> // 2
>     spotlight radius 0.3 falloff 0.35/10 point_at < 0, 0.5, 0> // 3
> 
> (Holds breath)

While this does show a clear correlation between the falloff parameter
and the area where the error occurs, the geometry of that area is still
a puzzle to me: For instance, why is the area farther out on the red leg
than on the blue leg? And why is the area much farther out than the falloff?

Can you do me a favor and toy around with the colours, the geometry of
how the optical elements are arranged, and how this relates to the falloff?

(BTW, when you post results, please include the details right away. Me
having to ask for them unnecessarily bogs down the whole process.)

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 17 hours and 43 minutes ago]

Sat, 27 Feb 2016 18:21:26 GMT

Am 27.02.2016 um 19:10 schrieb clipka:

> VERY promising. Whatever you did there, it has some definitive effect on
> the symptoms.
>
> Details please.

Falloff:

     //spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0> // 1
     //spotlight radius 0.3 falloff 0.35*10 point_at < 0, 0.5, 0> // 2
     spotlight radius 0.3 falloff 0.35/10 point_at < 0, 0.5, 0> // 3

(Holds breath)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 17 hours and 54 minutes ago]

Sat, 27 Feb 2016 18:10:33 GMT

Am 27.02.2016 um 19:07 schrieb ThH:
> Am 27.02.2016 um 18:27 schrieb clipka:
> 
>> I think it might well be worth toying around with the spotlight some
>> more.
> 
> Did so. Images attached.
> 
> Anything looking promising?

VERY promising. Whatever you did there, it has some definitive effect on
the symptoms.

Details please.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 17 hours and 57 minutes ago]

Sat, 27 Feb 2016 18:06:54 GMT

Am 27.02.2016 um 18:27 schrieb clipka:

> I think it might well be worth toying around with the spotlight some more.

Did so. Images attached.

Anything looking promising?

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 18 hours and 36 minutes ago]

Sat, 27 Feb 2016 17:27:49 GMT

Am 27.02.2016 um 18:08 schrieb ThH:
> Am 27.02.2016 um 17:17 schrieb William F Pokorny:
> 
>> Christoph,
>>
>> I think it has something to do with the light type.
>>
>> // <--- Fails 3.7.1-alpha.8454683 Ubuntu 14.04  (OK with 3.7.0-stable)
>> // light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
>> //     spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0>
>> //     photons {refraction on reflection on}
>> // }
>> // <--- OK Ubuntu 14.04 3.7.0 & 3.7.1
>>     light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
>>         photons {refraction on reflection on}
>>     }
>>
>> Perhaps someone else can verify ?
> 
> Tried it...
> 
> Yes. The resulting image differs, bit still not right.
> 
> I've attached my rendering.

Looks ok to me (except that the "original" light should cover the entire
height of the image's left side, but I'm pretty sure that's an entirely
different problem). Where the light streams past the block at the upper
edge of the image it's totally normal that we get bright white light.

I think it might well be worth toying around with the spotlight some more.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 18 hours and 53 minutes ago]

Sat, 27 Feb 2016 17:10:52 GMT

Am 27.02.2016 um 16:37 schrieb clipka:
> Am 27.02.2016 um 13:54 schrieb ThH:
>
>> 3 different pics by changing 1 line of the original optics.pov...
>
> What really intrigues me, and what I would like to ask you to try and
> investigate, is why only /some/ of the light rays are affected; why
> don't /all/ the blue and /all/ the red rays end up blazingly white?
>
> There must be /some/ reason for this, and I reckon that it might lead to
> a useful clue.

A new series...

How about these images?

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 18 hours and 56 minutes ago]

Sat, 27 Feb 2016 17:08:05 GMT

Am 27.02.2016 um 17:17 schrieb William F Pokorny:

> Christoph,
>
> I think it has something to do with the light type.
>
> // <--- Fails 3.7.1-alpha.8454683 Ubuntu 14.04  (OK with 3.7.0-stable)
> // light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
> //     spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0>
> //     photons {refraction on reflection on}
> // }
> // <--- OK Ubuntu 14.04 3.7.0 & 3.7.1
>     light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
>         photons {refraction on reflection on}
>     }
>
> Perhaps someone else can verify ?

Tried it...

Yes. The resulting image differs, bit still not right.

I've attached my rendering.

[William F Pokorny] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 19 hours and 47 minutes ago]

Sat, 27 Feb 2016 16:17:36 GMT

On 02/27/2016 10:37 AM, clipka wrote:
> Am 27.02.2016 um 13:54 schrieb ThH:
>
>> 3 different pics by changing 1 line of the original optics.pov...
>
> What really intrigues me, and what I would like to ask you to try and
> investigate, is why only /some/ of the light rays are affected; why
> don't /all/ the blue and /all/ the red rays end up blazingly white?
>
> There must be /some/ reason for this, and I reckon that it might lead to
> a useful clue.
>
Christoph,

I think it has something to do with the light type.

// <--- Fails 3.7.1-alpha.8454683 Ubuntu 14.04  (OK with 3.7.0-stable)
// light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
//     spotlight radius 0.3 falloff 0.35 point_at < 0, 0.5, 0>
//     photons {refraction on reflection on}
// }
// <--- OK Ubuntu 14.04 3.7.0 & 3.7.1
    light_source {<-150, 0.5, 0>, color rgb < 1.2, 1, 1.5>
        photons {refraction on reflection on}
    }

Perhaps someone else can verify ?

I extended the blocking wall for the point light, but not strictly needed.

Bill P.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 20 hours and 24 minutes ago]

Sat, 27 Feb 2016 15:40:39 GMT

Am 27.02.2016 um 16:21 schrieb clipka:

> I dunno... care to tell me /what/ you changed? ;)

This is what gave the 3 different results:

#declare MirrorTex1 =
texture {
     pigment {color White}
     //finish {ambient 0 diffuse 0 reflection  1/1}
     //finish {ambient 0 diffuse 0 reflection 1/10}
     finish {ambient 0 diffuse 0 reflection 1/20}
}

Original reflection - Image ...01...
10% - Image ...10...
5 % - Image ...20...

Keeping my fingers crossed!

>> Yes... The pics are brighter. I used assumed_gamma .5.
>
> Why on earth would you do that?
> (Then again, I did ask you to experiment, so...)

Maybe my CRT-Monitor is too dark. That why I did it ;)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 20 hours and 27 minutes ago]

Sat, 27 Feb 2016 15:37:08 GMT

Am 27.02.2016 um 13:54 schrieb ThH:

> 3 different pics by changing 1 line of the original optics.pov...

What really intrigues me, and what I would like to ask you to try and
investigate, is why only /some/ of the light rays are affected; why
don't /all/ the blue and /all/ the red rays end up blazingly white?

There must be /some/ reason for this, and I reckon that it might lead to
a useful clue.

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 20 hours and 43 minutes ago]

Sat, 27 Feb 2016 15:21:18 GMT

Am 27.02.2016 um 13:54 schrieb ThH:
> Am 27.02.2016 um 12:05 schrieb ThH:
> 
>> Am 27.02.2016 um 12:00 schrieb clipka:
...
>>> It's really frustrating that there is not the slightest glitch to be
>>> seen with the Windows version.
>>
>> Lucky windows-user so to say ;)

No, actually not. I know that there /is/ a bug lurking below the
surface, and unless I know exactly what causes it, I cannot rule out
that it may also strike at Windows users under /some/ circumstances.

> 3 different pics by changing 1 line of the original optics.pov...
> 
> Does this raise any interest or additional frustrations?

I dunno... care to tell me /what/ you changed? ;)

> Yes... The pics are brighter. I used assumed_gamma .5.

Why on earth would you do that?
(Then again, I did ask you to experiment, so...)

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3698 days 23 hours and 10 minutes ago]

Sat, 27 Feb 2016 12:54:04 GMT

Am 27.02.2016 um 12:05 schrieb ThH:

> Am 27.02.2016 um 12:00 schrieb clipka:
>
>> Unfortunately not. I need you to toy around more to give me that one
>> breakthrough idea.
>
> Understood.
>
>> It's really frustrating that there is not the slightest glitch to be
>> seen with the Windows version.
>
> Lucky windows-user so to say ;)

3 different pics by changing 1 line of the original optics.pov...

Does this raise any interest or additional frustrations?

Yes... The pics are brighter. I used assumed_gamma .5.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days and 59 minutes ago]

Sat, 27 Feb 2016 11:04:55 GMT

Am 27.02.2016 um 12:00 schrieb clipka:

> Unfortunately not. I need you to toy around more to give me that one
> breakthrough idea.

Understood.

> It's really frustrating that there is not the slightest glitch to be
> seen with the Windows version.

Lucky windows-user so to say ;)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 1 hour and 4 minutes ago]

Sat, 27 Feb 2016 11:00:31 GMT

Am 27.02.2016 um 11:16 schrieb ThH:

> Was the optics_mod.pov or optics_mod_2.pov provided above of any help?
> 
> Sure.. The original scene is destroyed.
> 
> My hope is/was the simplified version might give you an idea, you find a
> solution, which - by lucky chance - solves all photon/media related
> problems.

Unfortunately not. I need you to toy around more to give me that one
breakthrough idea.

It's really frustrating that there is not the slightest glitch to be
seen with the Windows version.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 1 hour and 49 minutes ago]

Sat, 27 Feb 2016 10:15:13 GMT

Am 27.02.2016 um 10:57 schrieb clipka:

> Doesn't seem to make much of a difference, does it?

I second that ;)

> Looks like I need more help from you folks to figure out where exactly
> the problem is rooted.

Was the optics_mod.pov or optics_mod_2.pov provided above of any help?

Sure.. The original scene is destroyed.

My hope is/was the simplified version might give you an idea, you find a 
solution, which - by lucky chance - solves all photon/media related 
problems.

--
Thorsten aka ThH
No... I've never did any coding using C, C++, ...

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 2 hours and 7 minutes ago]

Sat, 27 Feb 2016 09:57:02 GMT

Am 27.02.2016 um 10:19 schrieb ThH:
> Am 27.02.2016 um 09:31 schrieb ThH:
> 
>> Downloading (while having my 3rd mug of tea)
>>
>> Will report back :)
> 
> Hmmm...
> 
> Output attached.

Doesn't seem to make much of a difference, does it?

Looks like I need more help from you folks to figure out where exactly
the problem is rooted.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 2 hours and 46 minutes ago]

Sat, 27 Feb 2016 09:18:22 GMT

Am 27.02.2016 um 09:31 schrieb ThH:

> Downloading (while having my 3rd mug of tea)
>
> Will report back :)

Hmmm...

Output attached.

[ThH] Re: reflection.ini [3699 days 2 hours and 49 minutes ago]

Sat, 27 Feb 2016 09:15:45 GMT

Am 27.02.2016 um 10:00 schrieb clipka:

> Thanks for pointing out this issue; consider it fixed.

Thank you for fixing it clipka :)

[clipka] Re: reflection.ini [3699 days 3 hours and 4 minutes ago]

Sat, 27 Feb 2016 09:00:42 GMT

Am 27.02.2016 um 09:35 schrieb ThH:
> scenes/animations/reflection related...
> 
> I think reflection.ini needs a change:

Thanks for pointing out this issue; consider it fixed.

[ThH] reflection.ini [3699 days 3 hours and 29 minutes ago]

Sat, 27 Feb 2016 08:34:56 GMT

scenes/animations/reflection related...

I think reflection.ini needs a change:

Input_File_Name=reflect.pov

needs to be

Input_File_Name=reflection.pov

-- 
Thorsten aka ThH

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 3 hours and 34 minutes ago]

Sat, 27 Feb 2016 08:30:17 GMT

Am 27.02.2016 um 09:15 schrieb clipka:

> Nope; while the page the URL takes you to /does/ link to three pre-built
> Windows binaries, it also leads to two source file packages, which
> contain the entire source code for /all/ versions, including the Unix stuff.

I stand corrected.

Downloading (while having my 3rd mug of tea)

Will report back :)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 3 hours and 49 minutes ago]

Sat, 27 Feb 2016 08:15:14 GMT

Am 27.02.2016 um 08:17 schrieb ThH:
> Am 27.02.2016 um 07:59 schrieb clipka:
> 
>> Can someone please test this version:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110
>>
>>
>> I have no idea whether it will fix anything, but there is a glimmer of
>> hope that it just might.
> 
> I wish you luck :)
> 
> The URL listed above leads to a Windows-Only-Thing, right?

Nope; while the page the URL takes you to /does/ link to three pre-built
Windows binaries, it also leads to two source file packages, which
contain the entire source code for /all/ versions, including the Unix stuff.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 4 hours and 41 minutes ago]

Sat, 27 Feb 2016 07:23:13 GMT

Am 27.02.2016 um 08:23 schrieb ThH:
> No to self:
> No postings before first mug of tea!

Darn me...

Meant:

Note to self

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 4 hours and 42 minutes ago]

Sat, 27 Feb 2016 07:22:11 GMT

Am 27.02.2016 um 08:17 schrieb ThH:
> Am 27.02.2016 um 07:59 schrieb clipka:
>
>> Can someone please test this version:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110
>>
>>
>> I have no idea whether it will fix anything, but there is a glimmer of
>> hope that it just might.
>
> I wish you luck :)
>
> The URL listed above leads to a Windows-Only-Thing, right?
>
> Or did I miss any thing for NIXs ?
>
> Thorsten aka ThH

Shame on me...

NIXs meant Linux.

No to self:
No postings before first mug of tea!

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 4 hours and 47 minutes ago]

Sat, 27 Feb 2016 07:16:51 GMT

Am 27.02.2016 um 07:59 schrieb clipka:

> Can someone please test this version:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110
>
> I have no idea whether it will fix anything, but there is a glimmer of
> hope that it just might.

I wish you luck :)

The URL listed above leads to a Windows-Only-Thing, right?

Or did I miss any thing for NIXs ?

Thorsten aka ThH

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3699 days 5 hours and 5 minutes ago]

Sat, 27 Feb 2016 06:59:07 GMT

Am 24.02.2016 um 14:24 schrieb ThH:
> optics.pov from scenes/advanced...
> 
> The appended files had been rendered using povray V3.7.0 and Version
> 3.7.1-alpha.8492620.unofficial.

Can someone please test this version:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8497793%2Bav110

I have no idea whether it will fix anything, but there is a glimmer of
hope that it just might.

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3700 days 3 hours and 27 minutes ago]

Fri, 26 Feb 2016 08:37:08 GMT

Am 26.02.2016 um 05:44 schrieb clipka:

> The following look noteworthy to investigate:
> 
> changeset:   94:8e40f1a50cfd
> parent:      92:e995e1ab7beb
> parent:      93:a07181fe86db
> user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> date:        Thu Jun 19 10:24:56 2014 +0200
> summary:     Merge branch 'master' into refactor
> 
> and then:
> 
> changeset:   96:f2d948f2a077
> bookmark:    hotfix/photons_eca922a2
> tag:         default/hotfix/photons_eca922a2
> user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
> date:        Wed Jun 25 16:42:36 2014 +0200
> summary:     fix photons bug introduced with commit
> 'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'
> 
> In between these, we have a change in how photon colour/brightness data
> is stored.

I think I'm up to something here.

The changes between these two commits are all about the encoded storage
of photons in an RGBE format, which is an adaptation of the floating
point idea to the domain of colours, using three independent mantissas
for the colour channels but a single shared exponent. This idea is also
at the core of the Radiance HDR image file format.

Photon storage and the Radiance HDR image file format use virtually the
same variation of the format, using 8-bit unsigned integers for both the
mantissas and the exponent, with the one exception that for photons an
exponent bias of 250 was chosen, while Radiance HDR uses a bias of 128.

Originally, the data type for photons storage was a simple C-style
4-element unsigned char array, with associated C-style global functions
for encoding and decoding. The Radiance HDR file format handling used
its own independent functions doing virtually the same thing.

Now in the aforementioned changes, this was refactored into a common
C++-style template class type for both photons and Radiance HDR code.

Having looked again at that changed code, I noticed some peculiarities
about the code that I didn't quite understand (yes, I know I wrote the
code myself ;)), and which I currently consider inferior, but I also
wasn't quite sure what that "photons bug introduced with commit
'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'" was that had to be fixed
back then, and whether those peculiarities were there for a reason, so I
decided to revert those changes to revive that bug again.

I immediately recognized the resulting "optics.pov" render as the thing
that prompted me to implement the fix, so I'm sure again what it was all
about: In the process of refactoring I had made a slight "improvement"
that turned out to add a little bit of white light to otherwise pure
colours.

Now this doesn't look anything like what ThH has reported, nor what
you're seeing in your tests; but there is someting intriguing about it
that hadn't caught my attention back then:

It doesn't affect /all/ the rays.

As a matter of fact, it affects /exactly/ the very same subset of rays
as the issue now under investigation.


I think this is very strong evidence that the current issue is also
rooted in the RGBE handling code.

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3700 days 7 hours and 20 minutes ago]

Fri, 26 Feb 2016 04:44:35 GMT

Am 25.02.2016 um 19:08 schrieb Le_Forgeron:
> Le 25/02/2016 03:49, clipka a Ã©crit :
>> Am 24.02.2016 um 18:10 schrieb Le_Forgeron:
>>
>>>> Just one year of patches to check...
>> Binary search FTW.
> 
> If only all commits were able to be compiled...
> 
> The problem is any commit
> from 2014-06-14 14:26:48 +0200
> to 2014-07-02 04:05:34 +0200
> 
> Far before any of your candidates.

(Are you sure your list is complete? I do see more commits in between
those you cite, even on the same branch.)

The following look noteworthy to investigate:

changeset:   94:8e40f1a50cfd
parent:      92:e995e1ab7beb
parent:      93:a07181fe86db
user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
date:        Thu Jun 19 10:24:56 2014 +0200
summary:     Merge branch 'master' into refactor

and then:

changeset:   96:f2d948f2a077
bookmark:    hotfix/photons_eca922a2
tag:         default/hotfix/photons_eca922a2
user:        Christoph Lipka <c-l### [at] usersnoreplygithubcom>
date:        Wed Jun 25 16:42:36 2014 +0200
summary:     fix photons bug introduced with commit
'eca922a2819fabbadd82c31e4bfadaa0c425b5b5'

In between these, we have a change in how photon colour/brightness data
is stored.

Do you think you can try to get these to compile by applying the Jun/Jul
2014 series of "GitHub issue #29" fixes to them?

[Le Forgeron] Re: optics.pov 3.7.0 vs 3.7.1 [3700 days 17 hours and 56 minutes ago]

Thu, 25 Feb 2016 18:08:06 GMT

Le 25/02/2016 03:49, clipka a Ã©crit :
> Am 24.02.2016 um 18:10 schrieb Le_Forgeron:
> 
>> > Just one year of patches to check...
> Binary search FTW.

If only all commits were able to be compiled...

The problem is any commit
from 2014-06-14 14:26:48 +0200
to 2014-07-02 04:05:34 +0200

Far before any of your candidates.

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 9 hours and 15 minutes ago]

Thu, 25 Feb 2016 02:49:37 GMT

Am 24.02.2016 um 18:10 schrieb Le_Forgeron:

> Just one year of patches to check...

Binary search FTW.

For starters, please focus on the commits that changed
`source/core/lighting/photons.cpp`, `source/core/material/media.cpp`,
and/or `source/core/render/trace.cpp`:

3c719d20822eae09e586fa5fb6685f7228872040 (3 Jan 2016)
a4c66a28ffdffe1296e44d1ad587ba93886ec925 (2 Jan 2016)
87de094585c4c8904b1c77124a4218567097dad4 (1 Jan 2016)
6d20f85957cca8e6acc22ad87485665524f363a9 (1 Jan 2016)
49835074f55e1027d97e7260b16bac43a6bc7059 (15 Nov 2015)
93b9ae98eaa28fdc1ada1ce9ccc59150fc037141 (12 Sep 2015)
3e93e2e2a1a4ccec034d7666d41f78ffb1ebf00f (11 Sep 2015)
04ed70261ff8cc1e2a02ec226a4fe0f1ef6177bf (5 Aug 2015)
117f215c5efb9e0d69703a520eff04713de72778 (5 Aug 2015) [p]
1b5aab60b0f15de4e8170bbec3820c5236c353d8 (27 Jun 2015)
6ed60adea3195995492635aa27c7c2db018717cc (5 Mar 2015) [m,t]

[p] I currently have no list of relevant commits to `photons.cpp` prior
to this one, as the file resided in a different location.

[m,t] I currently have no list of relevant commits to `media.cpp` and
`trace.cpp` prior to this one, as the files resided in a different location.

You may first want to check the following commit though; it is known to
build ok on Unix, and dates back just a few days earlier:

0c7f9773c6bbdd3bddcce2475d6e374ab2292ae6 (3 Mar 2015)

Note that some of the other commits may fail to compile on Unix. I trust
you to be able to deal with this one way or the other.

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 17 hours and 48 minutes ago]

Wed, 24 Feb 2016 18:16:04 GMT

Am 24.02.2016 um 18:32 schrieb ThH:

> Now for some more investigation... ;)

optics_mod_2.pov + pics

So far: Comment out 1 photon related command of your choice and the pics 
are optically identical.

Will continue...

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 18 hours and 33 minutes ago]

Wed, 24 Feb 2016 17:31:46 GMT

Am 24.02.2016 um 17:04 schrieb ThH:
> Am 24.02.2016 um 16:51 schrieb clipka:
>
>   -- Be inquisitive and creative!)
>
> I'm in :)

Find attached optics_mod.pov.
Hope it's a good starter on the the way for a minimal scene to produce 
the error.

In addition I've attached 2 pics rendered on my machine. Again 3.7.0 vs 
3.7.1.

Now for some more investigation... ;)

[Le Forgeron] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 18 hours and 53 minutes ago]

Wed, 24 Feb 2016 17:11:05 GMT

Le 24/02/2016 16:51, clipka a Ã©crit :
> Am 24.02.2016 um 16:02 schrieb ThH:
>> Am 24.02.2016 um 15:55 schrieb Jaime Vives Piqueres:
>>
>>>    Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04
.3
>>> LTS.
>>>
>>> -- 
>>> jaime
>>
>> Thanks for checking and confirming Jaime :)
>>
>> So it's not just me ;)
> 
> Okay, here's the deal: I can't reproduce it, so my only chance to
> identify the root cause is to have a close look at the code, but for
> that to make any sense I need a clear picture of exactly where to look.

> To this end, I need you (that's "you" as in "y'all") to:
> 
> - figure out the simplest possible scene that exhibits the problem;
> 
> - identify exactly which commit (in the master branch) broke the scene;
 and
> 
> - do plenty of systematic toying around with the scene to figure out th
e
> exact circumstances under which the error shows. (For instance, why
> isn't the green beam affected? Is it because it is not reflected? Then
> why aren't the red and blue beams affected right after the first
> reflection? Does max_trace_level have anything to do with it? Why does
> only the bottom of the red sub-beams seem affected? Why the top and
> center of the blue sub-beams? etc. -- Be inquisitive and creative!)
> 

The problem might not be only in the code, I tested several heads and
compilers

/=================+=====+==
=====+=======+============
====\
| head \ compiler | gnu | clang | intel | gnu with debug |
+-----------------+-----+-------+-------+----------------+
| 3.7.0 stable    |  ok |  ok   |  ok   |  ok            |
+-----------------+-----+-------+-------+----------------+
| 3.7.1 master    | BUG |  ok   |  ok   |  BUG           |
+-----------------+-----+-------+-------+----------------+
| my master (hg)  | BUG |  ok   |  ok   |  BUG           |
+-----------------+-----+-------+-------+----------------+
| hgpovray        | ok  |  ok   |  ok   |  ok            |
\-----------------+-----+-------+-------+----------------/

notice, the intensity of green on stable branch seems higher (might be
known... gamma ?)

the difference between hgpovray and my master is:
* hgpovray is late on the refactoring of the code
* I have all my additions in hgpovray

the difference between my master and official master:
* I'm about a year late on synchronisation with refactoring

last pull from master to my master was April-June 2015, so the "bug" was
already there then.

The start/fork of hgpovray is 8 june 2014, so code before that date was
still fine.

The OP's picture was in white bug, mine is yellow.
(Ubuntu 64 bits 15.10)

Just one year of patches to check... it might be tied to the size of a
structure, and a particularity of Gnu compiler (gcc/g++ 5.2.1 20151010)
sensible to that... or a change of initialisation...

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 20 hours ago]

Wed, 24 Feb 2016 16:03:52 GMT

Am 24.02.2016 um 16:51 schrieb clipka:

  -- Be inquisitive and creative!)

I'm in :)

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 20 hours and 13 minutes ago]

Wed, 24 Feb 2016 15:51:23 GMT

Am 24.02.2016 um 16:02 schrieb ThH:
> Am 24.02.2016 um 15:55 schrieb Jaime Vives Piqueres:
> 
>>    Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04.3
>> LTS.
>>
>> -- 
>> jaime
> 
> Thanks for checking and confirming Jaime :)
> 
> So it's not just me ;)

Okay, here's the deal: I can't reproduce it, so my only chance to
identify the root cause is to have a close look at the code, but for
that to make any sense I need a clear picture of exactly where to look.
To this end, I need you (that's "you" as in "y'all") to:

- figure out the simplest possible scene that exhibits the problem;

- identify exactly which commit (in the master branch) broke the scene; and

- do plenty of systematic toying around with the scene to figure out the
exact circumstances under which the error shows. (For instance, why
isn't the green beam affected? Is it because it is not reflected? Then
why aren't the red and blue beams affected right after the first
reflection? Does max_trace_level have anything to do with it? Why does
only the bottom of the red sub-beams seem affected? Why the top and
center of the blue sub-beams? etc. -- Be inquisitive and creative!)

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 21 hours and 2 minutes ago]

Wed, 24 Feb 2016 15:01:58 GMT

Am 24.02.2016 um 15:55 schrieb Jaime Vives Piqueres:

>    Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04.3
> LTS.
>
> --
> jaime

Thanks for checking and confirming Jaime :)

So it's not just me ;)

[Jaime Vives Piqueres] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 21 hours and 9 minutes ago]

Wed, 24 Feb 2016 14:55:30 GMT

El 24/02/16 a las 14:24, ThH escribiÃ³:
> optics.pov from scenes/advanced...
>
> The appended files had been rendered using povray V3.7.0 and Version
> 3.7.1-alpha.8492620.unofficial.
>
> Could someone please check this?
>

   Happens here too on 3.7.1-alpha.8454683, AMD FM-6300, Ubuntu 14.04.3 LTS.

--
jaime

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 21 hours and 37 minutes ago]

Wed, 24 Feb 2016 14:27:24 GMT

Am 24.02.2016 um 14:53 schrieb clipka:

> Can't reproduce the issue with the Windows version.
> Are you sure you have a clean build?

The source is from github and hasn't been modified.

Povray has been build using:

cd ~/Downloads/povray-master/unix/
./prebuild.sh
cd ..
./configure --prefix=/home/thh/POV_Master COMPILED_BY="ThH 
<no.spam@address>" LIBS="-lboost_system -lboost_thread"
make check install

No extra configure options.

 From my point of view I'd say it's clean.

I could provide the output of the build process...

[clipka] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 22 hours and 11 minutes ago]

Wed, 24 Feb 2016 13:53:42 GMT

Am 24.02.2016 um 14:46 schrieb ThH:
> Am 24.02.2016 um 14:24 schrieb ThH:
> 
>> Could someone please check this?
>>
>> Thorsten aka ThH
> 
> Ooops... System is AMD64 with Debian. Excuse.

Can't reproduce the issue with the Windows version.
Are you sure you have a clean build?

[ThH] Re: optics.pov 3.7.0 vs 3.7.1 [3701 days 22 hours and 19 minutes ago]

Wed, 24 Feb 2016 13:45:08 GMT

Am 24.02.2016 um 14:24 schrieb ThH:

> Could someone please check this?
>
> Thorsten aka ThH

Ooops... System is AMD64 with Debian. Excuse.

[ThH] optics.pov 3.7.0 vs 3.7.1 [3701 days 22 hours and 40 minutes ago]

Wed, 24 Feb 2016 13:23:49 GMT

optics.pov from scenes/advanced...

The appended files had been rendered using povray V3.7.0 and Version 
3.7.1-alpha.8492620.unofficial.

Could someone please check this?

Thorsten aka ThH

[David] Optics.pov 3.6.2 vs 3.7 RC5 [5136 days 23 hours and 10 minutes ago]

Wed, 21 Mar 2012 12:53:51 GMT

Hi,

I am seeing different results from rendering the scenes\advanced\optics.pov 
sample file. It looks like the photons are not being reflected maybe?

Using the 64 bit version of 3.6.2 and 3.7 RC5 on Windows 7 64bit.

[psoaes] Jokes [5474 days 12 hours and 31 minutes ago]

Mon, 18 Apr 2011 23:33:10 GMT

Warning! No processor found! Press any key to continue

I would love to change the world, but they won't give me the source code

[Trevor G Quayle] Re: Jokes [5500 days 18 hours and 44 minutes ago]

Wed, 23 Mar 2011 17:20:01 GMT

"nemesis" <nam### [at] gmailcom> wrote:
> wrote:
> > WinErr 547: LPT1 not found... Use backup... PENCIL & PAPER
> >
> > 1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
>
> is that you, Invisible?
>
> invisible joke too. :)

WinErr 548: PENCIL & PAPER not found... Use backup... POV-Ray

-tgq

[nemesis] Re: Jokes [5500 days 19 hours and 44 minutes ago]

Wed, 23 Mar 2011 16:20:00 GMT

wrote:
> WinErr 547: LPT1 not found... Use backup... PENCIL & PAPER
>
> 1f u c4n r34d th1s u r34lly n33d t0 g37 l41d

is that you, Invisible?

invisible joke too. :)

[] Jokes [5501 days and 14 minutes ago]

Wed, 23 Mar 2011 11:50:35 GMT

WinErr 547: LPT1 not found... Use backup... PENCIL & PAPER

1f u c4n r34d th1s u r34lly n33d t0 g37 l41d

[Stephen] Re: Beta 39 not releasing memory on ending render [5621 days 4 hours and 59 minutes ago]

Tue, 23 Nov 2010 07:05:01 GMT

On 22/11/2010 10:09 PM, StephenS wrote:
> Stephen<mcavoys_at@aoldotcom>  wrote:
>> Thanks for testing Stephen. I was going to ask you and Miri to check it
>> out on your machines. Would you prefer the BSP file (135 KB)? It might
>> be easier to reduce the scene.
>>
>> --
>> Regards
>>       Stephen
>
> I'm always interested in how people construct there scenes, and I may even have
> time to reduce the scene :-)
>

I'm interested in other peoples methods too.
I've uploaded it to Scene files in the forum.

-- 
Regards
     Stephen

[StephenS] Re: Beta 39 not releasing memory on ending render [5621 days 13 hours and 49 minutes ago]

Mon, 22 Nov 2010 22:15:00 GMT

Stephen <mcavoys_at@aoldotcom> wrote:
> Thanks for testing Stephen. I was going to ask you and Miri to check it
> out on your machines. Would you prefer the BSP file (135 KB)? It might
> be easier to reduce the scene.
>
> --
> Regards
>      Stephen

I'm always interested in how people construct there scenes, and I may even have
time to reduce the scene :-)

Stephen S

[Stephen] Re: Beta 39 not releasing memory on ending render [5621 days 17 hours and 20 minutes ago]

Mon, 22 Nov 2010 18:44:00 GMT

On 22/11/2010 6:33 PM, Stephen wrote:
> Cannot open input file", this scene only. Trying after error, renders ok.

I get that too, sometimes.

-- 
Regards
     Stephen

[Stephen] Re: Beta 39 not releasing memory on ending render [5621 days 17 hours and 30 minutes ago]

Mon, 22 Nov 2010 18:33:53 GMT

On 22/11/2010 4:20 AM, StephenS wrote:
> "StephenS"<nomail@nomail>  wrote:
> ....
>> Let run for 25 minutes after render finished, exit without problem.
> ....
>> Not waiting for all cores to drop below 5 percent useage gives error if I try>  to
render again...
> No amount of waiting(3+hours) lets me render again without error, "Parce error:
> Cannot open input file", this scene only. Trying after error, renders ok.
>
> Next step is to reduce scene to minimum.
>

Thanks for testing Stephen. I was going to ask you and Miri to check it 
out on your machines. Would you prefer the BSP file (135 KB)? It might 
be easier to reduce the scene.

-- 
Regards
     Stephen

[StephenS] Re: Beta 39 not releasing memory on ending render [5622 days 7 hours and 39 minutes ago]

Mon, 22 Nov 2010 04:25:00 GMT

"StephenS" <nomail@nomail> wrote:
....
> Let run for 25 minutes after render finished, exit without problem.
....
> Not waiting for all cores to drop below 5 percent useage gives error if I try > to
render again...
No amount of waiting(3+hours) lets me render again without error, "Parce error:
Cannot open input file", this scene only. Trying after error, renders ok.

Next step is to reduce scene to minimum.

Stephen S

[StephenS] Re: Beta 39 not releasing memory on ending render [5622 days 17 hours and 24 minutes ago]

Sun, 21 Nov 2010 18:40:00 GMT

Stephen <mcavoys_at@aoldotcom> wrote:
> Please find attached a zip file with the problem file.
> I’ve installed PovRay on a new laptop with Win 7  64 bit, 8 Gb ram.
> Using  32 bit version of Beta 39 PovRay still holds on to the memory and
> raises an exception when exiting the program. The 64 bit version works
> as expected.
>
> --
> Regards
>      Stephen

Same setup: Win7 64bit, POV-Ray 3.7.39b 32bit

Let run for 25 minutes after render finished, exit without problem.

Useing a program to check my CPU temperature, CoreTemp, it also shows memory
useage and core useage (AMD cpu); computer is still busy after POV-Ray3.7 32bit
reports render finished. Memory use continues to drop while core useage is above
5 percent.

After the 25 minutes, could be less I did not stay at computer, The core useage
drops to less than 5 percent and memory useage moves up/down a small amount.

Not waiting for all cores to drop below 5 percent useage gives error if I try to
render again. Mini dump sent (#42) with automatic error report.
I did not try all combinations of wait/re-render/re-start.

Stephen S

[Stephen] Beta 39 not releasing memory on ending render [5623 days 20 hours and 5 minutes ago]

Sat, 20 Nov 2010 15:59:37 GMT

Please find attached a zip file with the problem file.
I’ve installed PovRay on a new laptop with Win 7  64 bit, 8 Gb ram.
Using  32 bit version of Beta 39 PovRay still holds on to the memory and 
raises an exception when exiting the program. The 64 bit version works 
as expected.

-- 
Regards
     Stephen

[Stephen] --- [5707 days 17 hours and 44 minutes ago]

Sat, 28 Aug 2010 18:19:57 GMT

I’m getting a crash with this scene.
It is not a big scene but all of the elements are required for it to 
fail. It also seems to be dependent on the camera angle and AA being used.

-- 

Best Regards,
	Stephen

[Stephen] --- [5707 days 17 hours and 48 minutes ago]

Sat, 28 Aug 2010 18:16:44 GMT

I’m getting a crash with this scene.
It is not a big scene but all of the elements are required for it to 
fail. It also seems to be dependent on the camera angle.

-- 

Best Regards,
	Stephen

[Stephen] Parse Error: Cannot open input file [5742 days 21 hours and 53 minutes ago]

Sat, 24 Jul 2010 14:10:47 GMT

Zipped scene file that gives Parse Error: Cannot open input file
When on line 1881  (or search for /+_+_+_ )
#while( Count < 10 ) is changed to #while( Count < 100 )



-- 

Best Regards,
	Stephen

[Christoph Hormann] Re: checking allscene from 3.7 beta 32 [6054 days 21 hours and 40 minutes ago]

Tue, 15 Sep 2009 14:24:24 GMT

clipka schrieb:
> 
> 
>> * crackle2.png : a missing fifth blue in the middle raw ? (remind me of a bug with
>>superellipsoid... probably nothing, but strange )
> 
> 
> Again, seen with POV 3.6 as well, and from the scene code it is intentional.
> Strange though, indeed; maybe it wouldn't work as an isosurface.

This had been removed from the scene during POV-Ray 3.5 development 
since at that time crackle metric 1 worked in a way unsuited for 
isosurfaces (infinite gradient)

-- Christoph

[Alain] Re: changed Insert Menu\80 - Special effects\60 ... [6150 days 22 hours and 44 minutes ago]

Thu, 11 Jun 2009 13:19:55 GMT

Bob H. a écrit :
> Removed the double "colour" typo from that file and replaced with color.
> 
> Bob H.
> --
> http://webpages.charter.net/omniverse/omniverse.htm
> 
> 
> 
"colour" is not a typo, it's the international spelling. BOTH spellings 
are supported.

[Alain] Re: checking allscene from 3.7 beta 32 [6200 days 19 hours and 44 minutes ago]

Wed, 22 Apr 2009 16:20:35 GMT

Le_Forgeron nous illumina en ce 2009-04-21 07:48 -->
> Rendered the all scenes shellscript.
> 
> (linux sources, ubuntu/amd64)
> 
> All my gammas are at 1.0, so do not bother with darkness.
> 
> Nevertheless, I have the following points which might be checked:
> 
>  * chess2.png : a bit too greenish in the reflection ? (cross of kings, and knights,
white
> tower)
Render the same with 3.6
> 
>  * crackle2.png : a missing fifth blue in the middle raw ? (remind me of a bug with
> superellipsoid... probably nothing, but strange )
Ther's a missing piece in the source. You can recreate it if you want.
> 
>  * desk4.png : the initial blank frame is still visible, is the recursion limit good
> enough ? (each iteration get one more desk in frame, not doubling)
Just repeat once more.
> 
>  * samp_demo06.png : the top square between magenta & white is not plain, there is a
grey
> & darker pattern. Is it as intended ?
That looks like an artefact.
> 
> Thanks for your comments.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 


-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you resign the fact that printing 
uses CMYK instead of RGB to one of those tests God gave to Job; otherwise life 
would be too painful to go on.
     -- Taps a.k.a. Tapio Vocadlo

[clipka] Re: checking allscene from 3.7 beta 32 [6201 days 13 hours and 54 minutes ago]

Tue, 21 Apr 2009 22:10:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
>  * chess2.png : a bit too greenish in the reflection ? (cross of kings, and knights,
white
> tower)

This *looks* weird, but it may actually be physically correct; in any case it's
seen with POV 3.6 as well.

>  * crackle2.png : a missing fifth blue in the middle raw ? (remind me of a bug with
> superellipsoid... probably nothing, but strange )

Again, seen with POV 3.6 as well, and from the scene code it is intentional.
Strange though, indeed; maybe it wouldn't work as an isosurface.

>  * desk4.png : the initial blank frame is still visible, is the recursion limit good
> enough ? (each iteration get one more desk in frame, not doubling)

I think it is technically impossible to totally eliminate the blank frame
(except for reducing its size to be no longer discernable).

>  * samp_demo06.png : the top square between magenta & white is not plain, there is a
grey
> & darker pattern. Is it as intended ?

Can't find that scene among the POV 3.6 samples, so no comparison here; in any
case, it seems to me that the square in question is empty (transparent??), and
that we see the shadow of the block to its right

[Le Forgeron] checking allscene from 3.7 beta 32 [6202 days and 14 minutes ago]

Tue, 21 Apr 2009 11:49:49 GMT

Rendered the all scenes shellscript.

(linux sources, ubuntu/amd64)

All my gammas are at 1.0, so do not bother with darkness.

Nevertheless, I have the following points which might be checked:

 * chess2.png : a bit too greenish in the reflection ? (cross of kings, and knights,
white
tower)

 * crackle2.png : a missing fifth blue in the middle raw ? (remind me of a bug with
superellipsoid... probably nothing, but strange )

 * desk4.png : the initial blank frame is still visible, is the recursion limit good
enough ? (each iteration get one more desk in frame, not doubling)

 * samp_demo06.png : the top square between magenta & white is not plain, there is a
grey
& darker pattern. Is it as intended ?

Thanks for your comments.

[MessyBlob] Re: Mesh not smooth with 64bit 3.7beta32 [6205 days 13 hours and 4 minutes ago]

Fri, 17 Apr 2009 23:00:01 GMT

Verm <a@b> wrote:
> Originally reported in p.Beta-test with reference to a mesh2 (downloaded
> car model)
>
>  > I've found that my 64bit (winXP) beta32 is failing to render a mesh2
>  > smoothly - I get flat triangles not smoothed triangles.
>  > I've tried the same scene with 3.6.1 (32 and 64 bit) and with a 32bit
>  > beta32 and I get a nice smooth mesh with all 3 versions.

It looks a bit like vertex ordering has been changed, or normals computed
assuming a different order. I had similar results when I was starting to play
with triangles in OpenGL, where I had to supply normals and vertex data. I hope
that provides a relevant clue for coders :o)

[clipka] Re: Mesh not smooth with 64bit 3.7beta32 [6207 days 14 hours and 54 minutes ago]

Wed, 15 Apr 2009 21:10:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Might be an issue related to XP/64 (compiler ?). At least, no problem with gcc 4.3.2
on
> ubuntu/amd64.

No problem with an Intel icpc build on a Debian AMD64 Linux either.

IIRC there had been some report on a similar issue: Messed-up meshes looking
similarly mangled. Though in that case it was a Linux issue, caused by a distro
POV package and resolved by installing a "proper" release.

[clipka] Re: Mesh not smooth with 64bit 3.7beta32 [6207 days 16 hours and 9 minutes ago]

Wed, 15 Apr 2009 19:55:00 GMT

Verm <a@b> wrote:
>  > I've found that my 64bit (winXP) beta32 is failing to render a mesh2
>  > smoothly - I get flat triangles not smoothed triangles.
>  > I've tried the same scene with 3.6.1 (32 and 64 bit) and with a 32bit
>  > beta32 and I get a nice smooth mesh with all 3 versions.

Uh... I wouldn't actually call those triangles *flat*...

    ... I'd call them outright *f*cked up* :P

[Le Forgeron] Re: Mesh not smooth with 64bit 3.7beta32 [6207 days 18 hours and 13 minutes ago]

Wed, 15 Apr 2009 17:51:00 GMT

Le 15.04.2009 08:57, Verm nous fit lire :
> Originally reported in p.Beta-test with reference to a mesh2 (downloaded
> car model)
> 
>> I've found that my 64bit (winXP) beta32 is failing to render a mesh2
>> smoothly - I get flat triangles not smoothed triangles.
>> I've tried the same scene with 3.6.1 (32 and 64 bit) and with a 32bit
>> beta32 and I get a nice smooth mesh with all 3 versions.
> 
> here's the output for the demo chessmesh scene rendered on 32 bit 3.61
> (set assumed gamma to 1) and 64bit 3.7 beta 64

My output on my 64bit (Linux, source compiled) beta 32 with minors patches (for
isosurface, path 3.7/3.6 of shell script and crash avoidance for trace on fractal;
delta
attached for patch) seems fine. (attached jpeg)

Might be an issue related to XP/64 (compiler ?). At least, no problem with gcc 4.3.2
on
ubuntu/amd64.

Only my 0.02â‚¬... if it can helps

$ file /usr/local/bin/povray
/usr/local/bin/povray: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for
GNU/Linux
2.6.8, dynamically linked (uses shared libs), stripped

[Verm] Mesh not smooth with 64bit 3.7beta32 [6208 days 5 hours and 7 minutes ago]

Wed, 15 Apr 2009 06:56:59 GMT

Originally reported in p.Beta-test with reference to a mesh2 (downloaded 
car model)

 > I've found that my 64bit (winXP) beta32 is failing to render a mesh2
 > smoothly - I get flat triangles not smoothed triangles.
 > I've tried the same scene with 3.6.1 (32 and 64 bit) and with a 32bit
 > beta32 and I get a nice smooth mesh with all 3 versions.

here's the output for the demo chessmesh scene rendered on 32 bit 3.61 
(set assumed gamma to 1) and 64bit 3.7 beta 64

[Ive] Re: Got it!: [6293 days 19 hours and 51 minutes ago]

Mon, 19 Jan 2009 16:13:29 GMT

clipka wrote:
> Thanks for your help! Your scene and experiments provided essential input for
> fixing this issue.
> 

You're welcome. Glad to be of any help, finally it's in my own interest ;)

-Ive

[Ive] Re: Got it!: [6293 days 19 hours and 54 minutes ago]

Mon, 19 Jan 2009 16:10:46 GMT

clipka wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> And as mentioned in my other post, something strange does happen with
>> texture maps even when no radiosity is involved.
> 
> Can you provide a sample scene for that, too?
> 
> I bet if there is *one* mixup of ipoint vs. isect.IPoint (IPoint and
> Intersection->IPoint in the 3.6 code), then chances are there's more of this
> kind to be found...
> 
> 

Attached is a simple SDL file.

 From my understanding T1 and T2 have to look identical, and they do in 
3.6.1.

-Ive

[clipka] Re: Got it!: [6293 days 19 hours and 54 minutes ago]

Mon, 19 Jan 2009 16:10:00 GMT

nemesis <nam### [at] gmailcom> wrote:
> clipka escreveu:
> > Ive <"ive### [at] lilysoftorg"> wrote:
> >> #declare T_Floor = texture {
> >>    checker
> >>    texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
> >>    rotate x*90
> >>    rotate y*45
> >>    scale 117.2/2
> >>    translate <-20.0, 0, 0>
> >> }
> >
> > Ta-ding!
>
> Good.  But his previous texture definition used a finish block with
> diffuse 1 and that is too high, I guess.  The default is 0.6 if I'm not
> wrong...

Not an issue here, as the color is only rgb 0.55.

And the culprit for the weird look has been clearly identified and successfully
eliminated.

[nemesis] Re: Got it!: [6293 days 20 hours and 8 minutes ago]

Mon, 19 Jan 2009 15:55:52 GMT

clipka escreveu:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> #declare T_Floor = texture {
>>    checker
>>    texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
>>    rotate x*90
>>    rotate y*45
>>    scale 117.2/2
>>    translate <-20.0, 0, 0>
>> }
> 
> Ta-ding!

Good.  But his previous texture definition used a finish block with 
diffuse 1 and that is too high, I guess.  The default is 0.6 if I'm not 
wrong...

[clipka] Re: Got it!: [6293 days 20 hours and 14 minutes ago]

Mon, 19 Jan 2009 15:50:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> And as mentioned in my other post, something strange does happen with
> texture maps even when no radiosity is involved.

Can you provide a sample scene for that, too?

I bet if there is *one* mixup of ipoint vs. isect.IPoint (IPoint and
Intersection->IPoint in the 3.6 code), then chances are there's more of this
kind to be found...

[clipka] Re: Got it!: [6293 days 20 hours and 34 minutes ago]

Mon, 19 Jan 2009 15:30:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> #declare T_Floor = texture {
>    checker
>    texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
>    rotate x*90
>    rotate y*45
>    scale 117.2/2
>    translate <-20.0, 0, 0>
> }

Ta-ding!

You know what? That stupid Trace::ComputeLightedTexture() code passes the wrong
co-ordinates to the radiosity code!

Instead of "world co-ordinates" it actually passes the co-ordinates with the
texture translations applied. Incredibly stupid error. And a one-liner to fix.
In file "trace.cpp", locate the line reading:

radiosity.ComputeAmbient(ray, *ipoint, rawnormal, layNormal, ambCol, weight *
max_Radiosity_Contribution, ticket);

replace with:

radiosity.ComputeAmbient(ray, Vector3d(isect.IPoint), rawnormal, layNormal,
ambCol, weight * max_Radiosity_Contribution, ticket);

This actually gets both the "balcony.pov" and "object_pattern.pov" scenes
perfectly back to 3.6 look.

Thanks for your help! Your scene and experiments provided essential input for
fixing this issue.

[Ive] Re: Got it!: [6293 days 21 hours and 40 minutes ago]

Mon, 19 Jan 2009 14:24:09 GMT

clipka wrote:

> Internally, the indirect illumination intensity is referred to as "ambient";
> maybe this led to some mixup of variables, causing this indirect illumination
> intensity to be mistakenly used as ambient term for additional texture layers -
> or something along these lines. Or it is just summed up for layered textures,
> instead of being weighted properly.
> 

Just to make it clear. The layered textures did not cause this problem, 
(maybe they cause artifacts if the max_trace_level is not high enough, 
but this is another story). It is just the patterned texture statement.

texture {
   checker // or anything else
   texture {T1}, texture {T2}
  ...
}

And as mentioned in my other post, something strange does happen with 
texture maps even when no radiosity is involved.

-Ive

[clipka] Re: Got it!: [6293 days 22 hours and 19 minutes ago]

Mon, 19 Jan 2009 13:45:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> So it seems to me that the problem is maybe not even related to
> radiosity but it is to patterned textures. Maybe it has something to do
> with he post by me to p.beta-test from 4/25/2008 "texture_map vs.
> pigment_map" - that never got a response ;(

Now THAT is interesting; in fact, some - albeit less prominent - differences
between 3.6 and beta.30-rad1 I never got resolved do involve patterned
textures:

- The checkered floor in the balcony scene, which got brighter, uses basically
the same construction as your scene.

- The object_pattern scene, which shows some strange artifacts, uses an
object_map on textures.

I guess these are insofar radiosity related as they only show in radiosity
shots. There seems to be an issue with how the indirect illumination intensity
returned by the radiosity code is "post-processed".

Internally, the indirect illumination intensity is referred to as "ambient";
maybe this led to some mixup of variables, causing this indirect illumination
intensity to be mistakenly used as ambient term for additional texture layers -
or something along these lines. Or it is just summed up for layered textures,
instead of being weighted properly.

[Ive] Got it!: [6293 days 22 hours and 54 minutes ago]

Mon, 19 Jan 2009 13:10:15 GMT

clipka wrote:

> At the moment I'm suspecting the floor to pick up light from below for some
> reason. What is the floor made of, geometrically speaking?
> 

  Just a box ;)

#declare W = 500.0;
#declare L = 664.6;
#declare H = 323.6;

//==============================================================
// room
//==============================================================

union {
// floor
   box { <0,0, 1> <W,-1,-L-1>  texture {T_Floor} }

  ... and a lot of more stuff

But here is the interesting thing:

#declare T_Floor = texture {
   material_map { png "Floor#2"
     texture {T_FloorMortar}
     texture {T_FloorWhite}
     texture {T_FloorBlack}
     texture {T_FloorBlack translate  79}
     texture {T_FloorBlack translate 255}
   }
   rotate x*90
   rotate y*45
   scale 117.2/2
   translate <-20.0, 0, 0>
}

where each of the separate textures is a quite complicated layered 
texture. Suspicion was that either the heavy layered textures or the 
material_map statement did mess up things.
So a quick simplification:

#declare T_FloorWhite_simple = texture
{
   pigment {rgb 0.55}
   finish {ambient 0  diffuse 1}
}

#declare T_FloorBlack_simple = texture
{
   pigment {rgb 0.05}
   finish {ambient 0  diffuse 1}
}

#declare T_Floor = texture {
   checker
   texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
   rotate x*90
   rotate y*45
   scale 117.2/2
   translate <-20.0, 0, 0>
}

and the result is still weird! See picture 1.

But then:

#declare T_Floor = texture {
   texture {T_FloorWhite_simple}
   rotate x*90
   rotate y*45
   scale 117.2/2
   translate <-20.0, 0, 0>
}

works perfectly as expected (low quality aside). Picture 2.

This effect can be easily reproduced in any other scene.

So it seems to me that the problem is maybe not even related to 
radiosity but it is to patterned textures. Maybe it has something to do 
with he post by me to p.beta-test from 4/25/2008 "texture_map vs. 
pigment_map" - that never got a response ;(

-Ive

[Dan Connelly] Re: FYI: radiosity changes integrated [6293 days 23 hours and 24 minutes ago]

Mon, 19 Jan 2009 12:40:28 GMT

clipka wrote:

> It is very strange however why a 9-fold number of pixels to calculate should
> result in a 12-fold effort.

With antialiasing, you'd expect the time to be sub-linear in the number of pixels,
assuming higher resolution images are smoother (not true with fractals).

[Ive] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days and 29 minutes ago]

Mon, 19 Jan 2009 11:35:01 GMT

clipka wrote:

> Would you mind e-mailing the scene to "christoph (at) lipka-koeln (dot) de"? As
> of now, it's the only scene I've seen so far that shows this effect.
> 
> Maybe you can strip it down to just the room and the tiles.
>

Will do so, but may take a little time.


> Another thought that just crossed my mind is "gamma": what if 3.7 interprets the
> sky sphere differently with respect to gamma? (Then again, that would probably
> look much different.)
> 
> At the moment I'm suspecting the floor to pick up light from below for some
> reason. What is the floor made of, geometrically speaking?
> 

I will also do some experiments to see if I can narrow down the problem.

-Ive

[clipka] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days and 59 minutes ago]

Mon, 19 Jan 2009 11:05:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> >> I have no explanation why the reflection in the mirror looks different
> >> in the MCPov version. And in fact it makes me quite unhappy, it looks
> >> somewhat desaturated.
> >
> > Hum... maybe max trace level issues of sorts...?
>
> Hmm, maybe. But shouldn't be max_trace_level of 8 be enough? It's just
> camera -> mirror -> rug. And the rug is not reflective.

Well, I don't know how MCPov handles trace level when it comes to diffuse
bounces. 'Twas just an idea anyway.

> All woods have a small amount of blurred reflection to get highlights.

The woods are not the "bad guys" - the tiles are, I think.

> I have attached a version with higher quality settings (and about 5h
> render time):

Didn't compare the shots in detail, but one thing is for sure: The weird effect
is still in there.

> And also a version where the radiosity block is just commented out (and
> no other changes are made). As expected, everything is pitch black
> except the sky and reflective parts of the scene where the sky gets
> reflected.
>
> I really hate it to say so, but I think there is something weird going
> on with the radiosity calculation.

Obviously.

Would you mind e-mailing the scene to "christoph (at) lipka-koeln (dot) de"? As
of now, it's the only scene I've seen so far that shows this effect.

Maybe you can strip it down to just the room and the tiles.

Another thought that just crossed my mind is "gamma": what if 3.7 interprets the
sky sphere differently with respect to gamma? (Then again, that would probably
look much different.)

At the moment I'm suspecting the floor to pick up light from below for some
reason. What is the floor made of, geometrically speaking?

[Ive] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 2 hours and 42 minutes ago]

Mon, 19 Jan 2009 09:22:31 GMT

clipka wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> I have no explanation why the reflection in the mirror looks different
>> in the MCPov version. And in fact it makes me quite unhappy, it looks
>> somewhat desaturated.
> 
> Hum... maybe max trace level issues of sorts...?
>

Hmm, maybe. But shouldn't be max_trace_level of 8 be enough? It's just 
camera -> mirror -> rug. And the rug is not reflective.

>>> - The 3.6.1 shot looks rather dark; I attribute this to the windows and flaws in
>>> POV 3.6 radiosity: When gathering deep-recursion samples, POV 3.6 effectively
>>> just traced a single level, so I guess it will not make it through the windows.
>>> All 3rd-bounce samples will probably be pitch black, and possibly even the
>>> 2nd-bounce ones.
>>>
>> In fact there is NO window "glass", there is just empty space ;)
> 
> Hum again... okay, so there is no spoon...
> 
> If the scene is just radiosity-lit, and materials are defined deliberately to be
> identical, then the only thing I can think of that could cause a significant
> bias to any particular color (like, for example, black) is POV-Ray giving up on
> some rays due to max trace level, ADC bailout or similar (i.e. recursion depth
> in case of radiosity) - in which cases POV will invariably use pitch black as
> substitute.
> 
> So the way a version of POV "counts" recursion depth might make a difference
> regarding how much black is mixed in.
> 
> Does a significant portion of surfaces in your shot have reflective components?
>

All woods have a small amount of blurred reflection to get highlights. 
In the original 2002 version also the floor tiles where slightly 
reflective but I have disabled the floor reflection for this test 
render. The original version also used more complicated layered textures 
   for the walls, and this new renders do use simplified texture there.
The layered textures caused some strange artifacts in the 2002 render 
and where the main reason I gave up at this time.

> 
>>> - The 3.7 shot indeed looks weird - but this weirdness look distinctively
>>> familiar: "Ambient" immediately comes to mind.
>> Nope. All materials do use ambient 0 in the finish statement and no
>> default include files are used where something else might be specified.
> 
> That's perfectly weird. In all tests shots, I have never seen such effects. Note
> that the white tiles do not only "bleed" onto the walls - they themselves look
> overly bright.
> 
> Something gets a >1 term into it somewhere.
> 
> Again: Does a significant portion of surfaces in your shot have reflective
> components?
> 
> Assuming for now that the tiles are partially reflective - is the sum of their
> "reflection" and "diffuse" values possibly >1?

Nope. I would never do this ;) (And I have always double checked in the 
SDL source files to really make sure my answers and description is 
correct.) The color AND diffuse values are alwayxs <= 1. And, as 
mentioned, for the new renders NO reflection for the floor.

> Note that this breaks the law of conservation of energy. This is not an issue in
> classically-lit POV scenes, because of the strict separation between "images"
> and "light sources"; however, in radiosity scenes it can become dramatic.
> 

I know, I really do.

> I can imagine that MCPov *might* handle such situations automatically as a side
> effect of its design. However, I'm quite sure standard POV does not.
> 
> 
> Just to make sure: We are talking about 3.7.0.beta.30-rad1, right?
> 

Yes, 3.7.0.beta.30-rad1 from Chris' zip file, exactly.

I have attached a version with higher quality settings (and about 5h 
render time):

radiosity {
     pretrace_start 8/image_width
     pretrace_end   2/image_width
     count 800
     error_bound 0.4
     nearest_count 1
     low_error_factor 0.5
     recursion_limit 3
     brightness 1
}

And also a version where the radiosity block is just commented out (and 
no other changes are made). As expected, everything is pitch black 
except the sky and reflective parts of the scene where the sky gets 
reflected.

I really hate it to say so, but I think there is something weird going 
on with the radiosity calculation.

-Ive

[stbenge] Re: FYI: radiosity changes integrated [6294 days 7 hours and 7 minutes ago]

Mon, 19 Jan 2009 04:57:06 GMT

clipka wrote:
> stbenge <^@hotmail.com> wrote:
>> But clipka seems to be
>> concerned about the speed as well, so I probably have nothing to worry
>> about :)
> 
> Rrrrright!
> 
> Radiosity is just about slow enough as it is (um, well, I mean, was in 3.6). I'd
> have accepted a slowdown of something like factor 2 as a price for artifact-free
> renders, because it would probably mean that old quality would be obtailable at
> old speed by choosing different settings. But we're talking about factors of 10
> or more.

That's steep, to be sure.

> I won't accept anything that looks like you can't get the same quality as 3.6 at
> roughly the same speed.

Well, if things go wrong I can always stock old versions of POV and head 
for the bunker :)

Sam

[stbenge] Re: FYI: radiosity changes integrated [6294 days 7 hours and 15 minutes ago]

Mon, 19 Jan 2009 04:49:15 GMT

Thorsten Froehlich wrote:
> stbenge wrote:
>> Warp wrote:
>>> TomAust <aus### [at] aust-manufakturde> wrote:
>>>> this image shows a detail of a building rendered in Beta29/30 and 
>>>> Beta30rad1.
>>>
>>>   Why is everyone comparing the radiosity of Beta 30 with the newest
>>> radiosity version?
>>
>> On a personal level, I'm pretty happy with beta<=30 radiosity. 
> 
> But you realize that it was broken in the sense that it just plain did 
> not work anything like it should or did in 3.6? I certainly know because 
> I amputated the code originally for 3.7. So really there is no 
> pre-beta30rad1 radiosity!!!

Yes, I understand that 3.7.b radiosity isn't as good as 3.6, but I'm 
willing to live with it until it is improved. At this point I haven't 
felt the need to go back to 3.6, since only the new beta versions 
support multi-threading. Really, I can get some nice radiosity renders 
out of 3.7. Smooth shading, small details. The quality of enclosed areas 
is still a bit dodgy, but it's not too bad.

I just hope that in the end 3.7's radiosity will still render at a good 
clip :)

Sam

[clipka] Re: FYI: radiosity changes integrated [6294 days 8 hours and 39 minutes ago]

Mon, 19 Jan 2009 03:25:00 GMT

"TomAust" <aus### [at] aust-manufakturde> wrote:
> > the rendertime was 23min with Beta29/30
> > and 220min with Beta30rad1.
> >
>
> Just finished the comparing renderings with same settings but in lower
> resolution at W1500xH1000.
> And now the rendertimes are
> 6min 35sec with beta29/30
> and just
> 16min 49sec with beta30rad1 !
>
> Perhaps a helpful note ?

It is at least *some* hint on what might be going on.

It is very strange however why a 9-fold number of pixels to calculate should
result in a 12-fold effort. Reason says that in the 9-fold number of pixels
shot and with the pretrace resolution defined relative to the total resolution,
we should expect to have about 9-fold the number of rays to trace, 9-fold the
number of radiosity lookups to do, and at most 9-fold the number of radiosity
samples to collect (in fact we should expect less increase, as some areas
should have sufficient coverage at the 1500x1000 resolution already). So that
should be at most 9-fold the rendering time. Well, plus a little bit of
additional overhead as various data structures grow. They're designed to have
sublinear access times though.

Did you keep any stats output?

In any case, this smells like severe performance issues with some data structure
that grows to larger size in the 4500x3000 shot.

Looking up radiosity cache data? No dramatic changes there. Fixed the level at
which a sample is "hooked in", potentially resulting in about 4-fold the number
of samples per node, but that just brought samples per node back to the order of
magnitude seen in 3.6.1.

Creating new sample data blocks? Hm... made a bit of a change there regarding
the locking; I'd actually expect that to speed things up instead, but I better
check.

Creating new nodes in the sample tree? Made significant changes there to change
the locking strategy as well; maybe I messed up something there.

[clipka] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 9 hours and 34 minutes ago]

Mon, 19 Jan 2009 02:30:01 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> I have no explanation why the reflection in the mirror looks different
> in the MCPov version. And in fact it makes me quite unhappy, it looks
> somewhat desaturated.

Hum... maybe max trace level issues of sorts...?

> > - The 3.6.1 shot looks rather dark; I attribute this to the windows and flaws in
> > POV 3.6 radiosity: When gathering deep-recursion samples, POV 3.6 effectively
> > just traced a single level, so I guess it will not make it through the windows.
> > All 3rd-bounce samples will probably be pitch black, and possibly even the
> > 2nd-bounce ones.
> >
>
> In fact there is NO window "glass", there is just empty space ;)

Hum again... okay, so there is no spoon...

If the scene is just radiosity-lit, and materials are defined deliberately to be
identical, then the only thing I can think of that could cause a significant
bias to any particular color (like, for example, black) is POV-Ray giving up on
some rays due to max trace level, ADC bailout or similar (i.e. recursion depth
in case of radiosity) - in which cases POV will invariably use pitch black as
substitute.

So the way a version of POV "counts" recursion depth might make a difference
regarding how much black is mixed in.

Does a significant portion of surfaces in your shot have reflective components?

> > - The 3.7 shot indeed looks weird - but this weirdness look distinctively
> > familiar: "Ambient" immediately comes to mind.
>
> Nope. All materials do use ambient 0 in the finish statement and no
> default include files are used where something else might be specified.

That's perfectly weird. In all tests shots, I have never seen such effects. Note
that the white tiles do not only "bleed" onto the walls - they themselves look
overly bright.

Something gets a >1 term into it somewhere.

Again: Does a significant portion of surfaces in your shot have reflective
components?

Assuming for now that the tiles are partially reflective - is the sum of their
"reflection" and "diffuse" values possibly >1?

Note that this breaks the law of conservation of energy. This is not an issue in
classically-lit POV scenes, because of the strict separation between "images"
and "light sources"; however, in radiosity scenes it can become dramatic.

I can imagine that MCPov *might* handle such situations automatically as a side
effect of its design. However, I'm quite sure standard POV does not.

Just to make sure: We are talking about 3.7.0.beta.30-rad1, right?

[clipka] Re: FYI: radiosity changes integrated [6294 days 10 hours and 9 minutes ago]

Mon, 19 Jan 2009 01:55:01 GMT

Thorsten Froehlich <tho### [at] trfde> wrote:
> But you realize that it was broken in the sense that it just plain did not
> work anything like it should or did in 3.6? I certainly know because I
> amputated the code originally for 3.7. So really there is no pre-beta30rad1
> radiosity!!!

Hm... if you amputated it, someone must have brought it to life again -
partially - before or at beta 29: It did a few things wrong, but it *did*
something, radiosity-wise.

[Ive] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 13 hours and 42 minutes ago]

Sun, 18 Jan 2009 22:22:09 GMT

nemesis wrote:
> That's too beautiful a scene to be just a test. ;)  Inspired by the painting in
> the lower right, I guess?

"The Music Lesson" by Vermeer


> MCPov is the best really, specially with the sharp shadows.  3.6 seems to
> conform with this lighting as well, except for the lack of sharp shadows.  3.7
> does look too bright and a bit too flat on the table cloth and jar.
> 
> Did you use ambient 0 for all objects?  

Sure.


> BTW, I suppose 3.7 is the fastest, right?

yes.

> How about tweaking it's settings a bit to see how it comes out with
> more quality?
> 

Doing this right now ;)

-Ive

[TomAust] Re: FYI: radiosity changes integrated [6294 days 13 hours and 44 minutes ago]

Sun, 18 Jan 2009 22:20:01 GMT

"TomAust" <aus### [at] aust-manufakturde> wrote:
> The whole rendering shows the complete building and has a resolution of
> W4500xH3000.
>...
> the rendertime was 23min with Beta29/30
> and 220min with Beta30rad1.
>

Just finished the comparing renderings with same settings but in lower
resolution at W1500xH1000.
And now the rendertimes are
6min 35sec with beta29/30
and just
16min 49sec with beta30rad1 !

Perhaps a helpful note ?

TomAust

[Ive] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 13 hours and 47 minutes ago]

Sun, 18 Jan 2009 22:17:25 GMT

clipka wrote:
> Impressive scene!
> 

thanks.

> Comments to the pictures:
> 
> - Render times?
> 

~2h for 3.6
~1h for 3.7
~20h for MCPov

I'm currently rendering a 3.7 version with higher quality settings and 
will show it when it's finished.

> - The MCPov shot looks most convincing, no argument here. However, it is not
> perfectly clear whether this is due to an actual superiority in quality, or
> imperfections in the POV 3.6/3.7 material setup. Especially a look at the
> mirror raises suspicion: While it is rather dull in the MCPov shot, it seems to
> be plain 100% reflective in the POV 3.6.1 and 3.7 shots. So there must be *some*
> difference in material settings.
>

I have no explanation why the reflection in the mirror looks different 
in the MCPov version. And in fact it makes me quite unhappy, it looks 
somewhat desaturated. But believe me, the material used for the mirror 
is in all shots exactly the same. The only difference in the materials 
are the woods for the chairs, the viol and the mirror frame where the 
MCPov version makes use of the MCPov blurred reflection feature where 
the 3.6/3.7 versions use averaged normals to get some highlights.

> - The 3.6.1 shot looks rather dark; I attribute this to the windows and flaws in
> POV 3.6 radiosity: When gathering deep-recursion samples, POV 3.6 effectively
> just traced a single level, so I guess it will not make it through the windows.
> All 3rd-bounce samples will probably be pitch black, and possibly even the
> 2nd-bounce ones.
>

In fact there is NO window "glass", there is just empty space ;)

> - The 3.7 shot indeed looks weird - but this weirdness look distinctively
> familiar: "Ambient" immediately comes to mind. It looks very much like you
> forgot to set all materials to "ambient 0" (or, alternatively, turn down the
> "ambient_light" to something like 0.001 and multiply your sky ambient by 1000;
> usually this sufficiently dims the ambient terms and saves you a lot of work.)
>

Nope. All materials do use ambient 0 in the finish statement and no 
default include files are used where something else might be specified.

> That link only leads me to the p.b.i. overview.
> 

Sorry. This should work:

http://news.povray.org/povray.binaries.images/thread/<3da07987%40news.povray.org>/?ttop=296700&toff=5700

-Ive

[Thorsten Froehlich] Re: FYI: radiosity changes integrated [6294 days 14 hours and 25 minutes ago]

Sun, 18 Jan 2009 21:38:49 GMT

stbenge wrote:
> Warp wrote:
>> TomAust <aus### [at] aust-manufakturde> wrote:
>>> this image shows a detail of a building rendered in Beta29/30 and 
>>> Beta30rad1.
>>
>>   Why is everyone comparing the radiosity of Beta 30 with the newest
>> radiosity version?
> 
> On a personal level, I'm pretty happy with beta<=30 radiosity. 

But you realize that it was broken in the sense that it just plain did not 
work anything like it should or did in 3.6? I certainly know because I 
amputated the code originally for 3.7. So really there is no pre-beta30rad1 
radiosity!!!

	Thorsten

[clipka] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 14 hours and 59 minutes ago]

Sun, 18 Jan 2009 21:05:00 GMT

Ive <"ive### [at] lilysoftorg"> wrote:
> Just used one of my "never finished projects" to do a "quick" compare
> between 3.6.1 and 3.7 beta30.rad1 radiosity with moderate low setting -
> at least for this kind of scene. Lit by radiosity only, coming from a
> skysphere with a high ambient value.

Impressive scene!


> Well, look for yourself but from what I can tell the 3.7 radiosity
> lighting looks quite strange. The floor is way too bright and other
> objects like the rug on the table, the viol and the notes on the
> virginal look totally flat. Note also this has nothing to do with the
> change in gamma handling because I have always used assumed gamma of 1.0.

Comments to the pictures:

- Render times?

- The MCPov shot looks most convincing, no argument here. However, it is not
perfectly clear whether this is due to an actual superiority in quality, or
imperfections in the POV 3.6/3.7 material setup. Especially a look at the
mirror raises suspicion: While it is rather dull in the MCPov shot, it seems to
be plain 100% reflective in the POV 3.6.1 and 3.7 shots. So there must be *some*
difference in material settings.

- The 3.6.1 shot looks rather dark; I attribute this to the windows and flaws in
POV 3.6 radiosity: When gathering deep-recursion samples, POV 3.6 effectively
just traced a single level, so I guess it will not make it through the windows.
All 3rd-bounce samples will probably be pitch black, and possibly even the
2nd-bounce ones.

- The 3.7 shot indeed looks weird - but this weirdness look distinctively
familiar: "Ambient" immediately comes to mind. It looks very much like you
forgot to set all materials to "ambient 0" (or, alternatively, turn down the
"ambient_light" to something like 0.001 and multiply your sky ambient by 1000;
usually this sufficiently dims the ambient terms and saves you a lot of work.)


> Here is a link to an image I have done back in 2002 with high quality
> radiosity settings and (I guess) POV 3.5 at this time.
>
> http://news.povray.org/povray.binaries.images/message/<3C3da07987%40news.povray.org>

That link only leads me to the p.b.i. overview.

[nemesis] Re: Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 15 hours and 24 minutes ago]

Sun, 18 Jan 2009 20:40:01 GMT

That's too beautiful a scene to be just a test. ;)  Inspired by the painting in
the lower right, I guess?

MCPov is the best really, specially with the sharp shadows.  3.6 seems to
conform with this lighting as well, except for the lack of sharp shadows.  3.7
does look too bright and a bit too flat on the table cloth and jar.

Did you use ambient 0 for all objects?  BTW, I suppose 3.7 is the fastest,
right?  How about tweaking it's settings a bit to see how it comes out with
more quality?

[Ive] Radiosity POV 3.6 vs. 3.7 vs. MCPov [6294 days 16 hours and 19 minutes ago]

Sun, 18 Jan 2009 19:45:20 GMT

Just used one of my "never finished projects" to do a "quick" compare 
between 3.6.1 and 3.7 beta30.rad1 radiosity with moderate low setting - 
at least for this kind of scene. Lit by radiosity only, coming from a 
skysphere with a high ambient value.


version 3.6:

global_settings {
   assumed_gamma 1.0
   max_trace_level 8

   pretrace_start 0.08
   pretrace_end   0.01
   count 400
   error_bound 0.75
   nearest_count 5
   low_error_factor 0.5
   recursion_limit 3
}


version 3.7

global_settings {
   max_trace_level 8

   pretrace_start 16/image_width
   pretrace_end    2/image_width
   count 400
   error_bound 0.75
   nearest_count 1
   low_error_factor 0.5
   recursion_limit 3
}


I have also attached a version rendered by MCPov 0.5 with 1000 passes.

Well, look for yourself but from what I can tell the 3.7 radiosity 
lighting looks quite strange. The floor is way too bright and other 
objects like the rug on the table, the viol and the notes on the 
virginal look totally flat. Note also this has nothing to do with the 
change in gamma handling because I have always used assumed gamma of 1.0.

Here is a link to an image I have done back in 2002 with high quality 
radiosity settings and (I guess) POV 3.5 at this time.

http://news.povray.org/povray.binaries.images/message/<3C3da07987%40news.povray.org>

There is a difference in the lighting because in the 2002 scene the 3rd 
window is open but the 3 new test renders have this window draped.

[clipka] Re: FYI: radiosity changes integrated [6295 days 13 hours and 14 minutes ago]

Sat, 17 Jan 2009 22:50:01 GMT

stbenge <^@hotmail.com> wrote:
> But clipka seems to be
> concerned about the speed as well, so I probably have nothing to worry
> about :)

Rrrrright!

Radiosity is just about slow enough as it is (um, well, I mean, was in 3.6). I'd
have accepted a slowdown of something like factor 2 as a price for artifact-free
renders, because it would probably mean that old quality would be obtailable at
old speed by choosing different settings. But we're talking about factors of 10
or more.

I won't accept anything that looks like you can't get the same quality as 3.6 at
roughly the same speed.

[stbenge] Re: FYI: radiosity changes integrated [6295 days 14 hours and 25 minutes ago]

Sat, 17 Jan 2009 21:39:10 GMT

Warp wrote:
> TomAust <aus### [at] aust-manufakturde> wrote:
>> this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
> 
>   Why is everyone comparing the radiosity of Beta 30 with the newest
> radiosity version?

On a personal level, I'm pretty happy with beta<=30 radiosity. I can see 
where it can be improved somewhat, of course. I would be very unhappy if 
the render times got higher and higher with each new release. I would be 
worried that it might stay slow :S

>   Unless I'm completely mistaken, the radiosity code in 3.7 beta
> versions <= 30 was, by all intents and purposes, non-functional and
> certainly not intended to be used for anything. The code was just
> provisionally there to give *something* (rather than eg. just crashing
> the program) but not as the intended functionality.

I don't think it's as dysfunctional as you say it is. There is an issue 
with render-block-sized squares showing up sometimes, but changing 
pretrace_end to a lower value makes those artifacts vanish. Black 
patches show up also, but lowering adc_bailout fixes that problem (as 
long as it's not caused by reflecting or refracting objects).

>   What people should compare against is the radiosity in 3.6.

The quality, the speed, or both? If I can still squeeze artifact-free 
radiosity out of pov.b.3.7, I'll be happy. As long as it doesn't take 
too long, of course.

I think if the POV-team is going to pursue a higher-quality radiosity 
implementation at the great expense of speed, there should be an option 
to use the old "broken" 3.7 radiosity if desired. But clipka seems to be 
concerned about the speed as well, so I probably have nothing to worry 
about :)

Sam

[Warp] Re: FYI: radiosity changes integrated [6295 days 16 hours and 8 minutes ago]

Sat, 17 Jan 2009 19:56:13 GMT

Mike Hough <nos### [at] nospamcom> wrote:
> I agree with Warp, since we are not only concerned with speed but the 
> quality of the output. Being the last release build, 3.6 is the standard 
> against which any changes should be measured.

  If the speed (when rendering with one single thread) stays the same as
in 3.6 but the end result has less artifacts and higher quality, the
situation is a complete win.

-- 
                                                          - Warp

[Mike Hough] Re: FYI: radiosity changes integrated [6295 days 16 hours and 30 minutes ago]

Sat, 17 Jan 2009 19:34:35 GMT

I agree with Warp, since we are not only concerned with speed but the 
quality of the output. Being the last release build, 3.6 is the standard 
against which any changes should be measured.


"clipka" <nomail@nomail> wrote in message 
news:web.49722d4ebea0b42dd3a05d570@news.povray.org...
> Warp <war### [at] tagpovrayorg> wrote:
>>   Why is everyone comparing the radiosity of Beta 30 with the newest
>> radiosity version?
>>
>>   Unless I'm completely mistaken, the radiosity code in 3.7 beta
>> versions <= 30 was, by all intents and purposes, non-functional and
>> certainly not intended to be used for anything. The code was just
>> provisionally there to give *something* (rather than eg. just crashing
>> the program) but not as the intended functionality.
>>
>>   What people should compare against is the radiosity in 3.6.
>
> Unfortunately, from what I've seen in my test renders is that there is no 
> great
> difference in speed between 3.6 and 3.7.0.beta.29 (at least when comparing 
> pure
> CPU time). This is because the radiosity code wasn't so dysfunctional 
> after all
> - it was just broken, but that didn't influence speed much.
>
> So the drastic increase in reder time does worry me.
>
>

[clipka] Re: FYI: radiosity changes integrated [6295 days 16 hours and 49 minutes ago]

Sat, 17 Jan 2009 19:15:02 GMT

Warp <war### [at] tagpovrayorg> wrote:
>   Why is everyone comparing the radiosity of Beta 30 with the newest
> radiosity version?
>
>   Unless I'm completely mistaken, the radiosity code in 3.7 beta
> versions <= 30 was, by all intents and purposes, non-functional and
> certainly not intended to be used for anything. The code was just
> provisionally there to give *something* (rather than eg. just crashing
> the program) but not as the intended functionality.
>
>   What people should compare against is the radiosity in 3.6.

Unfortunately, from what I've seen in my test renders is that there is no great
difference in speed between 3.6 and 3.7.0.beta.29 (at least when comparing pure
CPU time). This is because the radiosity code wasn't so dysfunctional after all
- it was just broken, but that didn't influence speed much.

So the drastic increase in reder time does worry me.

[TomAust] Re: FYI: radiosity changes integrated [6295 days 16 hours and 49 minutes ago]

Sat, 17 Jan 2009 19:15:01 GMT

Warp <war### [at] tagpovrayorg> wrote:
> TomAust <aus### [at] aust-manufakturde> wrote:
> > this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
>
>   Why is everyone comparing the radiosity of Beta 30 with the newest
> radiosity version?
>

Because Chris Cason asked for feedback about "integrated radiosity changes"
between b29/30 and b30rad1...?

TomAust

[Warp] Re: FYI: radiosity changes integrated [6295 days 18 hours and 21 minutes ago]

Sat, 17 Jan 2009 17:43:45 GMT

TomAust <aus### [at] aust-manufakturde> wrote:
> this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.

  Why is everyone comparing the radiosity of Beta 30 with the newest
radiosity version?

  Unless I'm completely mistaken, the radiosity code in 3.7 beta
versions <= 30 was, by all intents and purposes, non-functional and
certainly not intended to be used for anything. The code was just
provisionally there to give *something* (rather than eg. just crashing
the program) but not as the intended functionality.

  What people should compare against is the radiosity in 3.6.

-- 
                                                          - Warp

[TomAust] Re: FYI: radiosity changes integrated [6295 days 20 hours and 19 minutes ago]

Sat, 17 Jan 2009 15:45:01 GMT

"clipka" <nomail@nomail> wrote:
> "TomAust" <aus### [at] aust-manufakturde> wrote:
> > Hi,
> >
> > this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
> > The whole rendering shows the complete building and has a resolution of
> > W4500xH3000.
> > Settings are equal except nearest_count and low_error_factor at the suggestion
> > of clipka:
> >
> >  //nearest_count 1
> >  //low_error_factor 0.5
> >  recursion_limit 1
> >
> > On Vista64
> > QuadCore @2.66GHz
> > the rendertime was 23min with Beta29/30
> > and 220min with Beta30rad1.
>
> Are you aware that commenting-out the nearest_count setting gives you a default
> value of 5?
>

Of course, I commented out these two points only for the rendering with
Beta29/30, which was the last run.

> Anyway, this starts to seriously bug me. From my test renders I had the
> impresson that serious slowdown occured only at higher recursion_limit values,
> not with single-bounce shots. Now all reports coming in seem to indicate
> otherwise.
>

Oh, I really don't want to injure you, you are my hope! ;)

> Blood-stained excrements of a male bovine.
>

Hm, where is my dictionary?!

> I can imagine only one thing that could cause this difference in a single-bounce
> shot: Effective trace depth.
>
> What are your global trace_limit and adc_bailout values?
>

No special settings here, in fact not set at all, so they are default.

> (Would you be willing to disclose the scene file so I could do some toying
> around with it? If public posting is not an option, you might send it to
> christoph <at> lipka-koeln <dot> de.)
>

Yes, of course, but with many, many incs, declarations, macros, etc. and a bunch
of selfcreated fileendings - perhaps a reason for the slowdown?
So I should use your mailadress.

> (BTW, the building looks strikingly familiar - I fancy that I've seen the
> original somewhere in the south of Cologne... Zollstock maybe?)

The renderings are visualizations for a planned building in Bonn (so another
point to keep it in confidence) and mostly architects are pretty influenced by
mainstream... ;)
But what a coincidence, neighbour!
Greetings from Bickendorf, not as bad as its reputation!

[clipka] Re: FYI: radiosity changes integrated [6295 days 21 hours and 49 minutes ago]

Sat, 17 Jan 2009 14:15:00 GMT

"TomAust" <aus### [at] aust-manufakturde> wrote:
> Hi,
>
> this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
> The whole rendering shows the complete building and has a resolution of
> W4500xH3000.
> Settings are equal except nearest_count and low_error_factor at the suggestion
> of clipka:
>
>  //nearest_count 1
>  //low_error_factor 0.5
>  recursion_limit 1
>
> On Vista64
> QuadCore @2.66GHz
> the rendertime was 23min with Beta29/30
> and 220min with Beta30rad1.

Are you aware that commenting-out the nearest_count setting gives you a default
value of 5?

Anyway, this starts to seriously bug me. From my test renders I had the
impresson that serious slowdown occured only at higher recursion_limit values,
not with single-bounce shots. Now all reports coming in seem to indicate
otherwise.

Blood-stained excrements of a male bovine.

I can imagine only one thing that could cause this difference in a single-bounce
shot: Effective trace depth.

What are your global trace_limit and adc_bailout values?

(Would you be willing to disclose the scene file so I could do some toying
around with it? If public posting is not an option, you might send it to
christoph <at> lipka-koeln <dot> de.)

> Full of hope
> TomAust

Yeah - I, too, hope to be able to find the cause of those slowdowns... obviously
they're more serious in practice than I expected, so the status quo is
unacceptable.

(BTW, the building looks strikingly familiar - I fancy that I've seen the
original somewhere in the south of Cologne... Zollstock maybe?)

[TomAust] FYI: radiosity changes integrated [6295 days 23 hours and 9 minutes ago]

Sat, 17 Jan 2009 12:55:01 GMT

Hi,

this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
The whole rendering shows the complete building and has a resolution of
W4500xH3000.
Settings are equal except nearest_count and low_error_factor at the suggestion
of clipka:

radiosity
{
 pretrace_start 16/image_width
 pretrace_end 2/image_width
 count 500
 error_bound .1
 //nearest_count 1
 //low_error_factor 0.5
 recursion_limit 1
 normal on
 always_sample off
}

On Vista64
QuadCore @2.66GHz
the rendertime was 23min with Beta29/30
and 220min with Beta30rad1.

Another rendering from another side took 41min with Beta29/30
and 695min with Beta30rad1 (and was the reason why I hadn't enough patience to
use the XP32 machine with Core2Duo @2.4 ;). I've cancelled the process, after
making sure that the speedcomparison was as usual.)

As I mentioned in povray.beta-test the output looks better in b30rad1, if you
look for example into the opened window or under the roof.


Full of hope
TomAust

[Mike Hough] Re: Radiosity testing [6296 days 16 hours and 51 minutes ago]

Fri, 16 Jan 2009 19:12:51 GMT

I tried lowering nearest_count to 1 and recursion_limit to 2, and increasing
low_error_factor to 0.5. This results in a very blotchy image. I can reduce
that some by lowering the final pretrace to 0.005 and increasing the count
but it takes very long to render and is still a bit patchy.

Stumped, I tried the cornell.pov scene. It renders in 30 seconds in the beta
and 1m 31s in v3.6, so for that scene at least there is a major decrease in
render time and the result looks pretty much identical. So I copied and
pasted the radiosity settings from cornell.pov into my scene and reran the
scene file. In the beta is takes 2m 59s and in v3.6 it takes 3m 9s. There
are some very slight differences but for the most part the images look
almost identical, even the brightness of the image. However there is no
detail evident, just some patchy shadows and color bleeding.

I might see if I can find some off Gilles Tran's old radiosity test files.

"clipka" <nomail@nomail> wrote in message 
news:web.496fcbd296903692dea10790@news.povray.org...
> "Mike Hough" <nos### [at] nospamcom> wrote:
>> If anyone has any suggestions for how I might alter the settings to 
>> improve
>> the render I would be happy to rerun this test.
>
> - Reduce the nearest_count to 1. There is no point in using any other 
> value
> anyway that could not be achieved by modifying the low_error_factor just 
> as
> well. Although little known, this was true for 3.6 likewise.
>
> - Increase low_error_factor; having this set to a low value may have 
> helped in
> 3.6 to reduce artifact "strength", but should no longer be required in
> 3.7.0.beta.30-rad1. A value of 0.5 should be perfectly fine now in most 
> cases.
>
> Note that with a nearest_count of 10 and a low_error_factor of 0.2, your
> pretrace will attempt to achieve a 250-fold (!) higher sample density than
> needed for the final trace. (It will never ever achieve this coverage 
> though,
> because it will not do enough passes.) Setting nearest_count to 1 and
> low_error_factor to 0.5 will cause the pretrace to still aim for 4-fold 
> sample
> density.
>
> - Try reducing the recursion_limit, unless you really need three bounces 
> (which
> is very rarely the case). The bugs and flaws in 3.6 basically caused 
> deeper
> radiosity "bounces" to be limited to a single trace level, i.e. every 
> mirror
> and window would look pitch-black to them. The beta.30-rad1 is not so 
> drastic,
> with the effect that deep-recursion pretraces take longer than before even 
> with
> the same number of samples gathered.
>
>

[clipka] Re: Radiosity testing [6297 days 12 hours and 9 minutes ago]

Thu, 15 Jan 2009 23:55:01 GMT

"Mike Hough" <nos### [at] nospamcom> wrote:
> If anyone has any suggestions for how I might alter the settings to improve
> the render I would be happy to rerun this test.

- Reduce the nearest_count to 1. There is no point in using any other value
anyway that could not be achieved by modifying the low_error_factor just as
well. Although little known, this was true for 3.6 likewise.

- Increase low_error_factor; having this set to a low value may have helped in
3.6 to reduce artifact "strength", but should no longer be required in
3.7.0.beta.30-rad1. A value of 0.5 should be perfectly fine now in most cases.

Note that with a nearest_count of 10 and a low_error_factor of 0.2, your
pretrace will attempt to achieve a 250-fold (!) higher sample density than
needed for the final trace. (It will never ever achieve this coverage though,
because it will not do enough passes.) Setting nearest_count to 1 and
low_error_factor to 0.5 will cause the pretrace to still aim for 4-fold sample
density.

- Try reducing the recursion_limit, unless you really need three bounces (which
is very rarely the case). The bugs and flaws in 3.6 basically caused deeper
radiosity "bounces" to be limited to a single trace level, i.e. every mirror
and window would look pitch-black to them. The beta.30-rad1 is not so drastic,
with the effect that deep-recursion pretraces take longer than before even with
the same number of samples gathered.

[Mike Hough] Re: Radiosity testing [6297 days 14 hours and 52 minutes ago]

Thu, 15 Jan 2009 21:12:15 GMT

I ran these scenes with one of the new binaries provided by Chris Cason. 
These all were rendered with pvengine32-sse2.exe.

The first image uses the same global settings previously posted. Render time 
was 7h 53m before I stopped the render. The low error bound of 0.02 slowed 
it to about 7pps.

The second images uses new settings including a higher error_bound and 
additional pretrace options to reduce patchiness. These are the only 
settings that were changed:

pretrace_start 0.08
pretrace_end   0.02
error_bound 0.15

render time 54 minutes

For the last image I used these new settings to rerun the scene file using 
version 3.6. Render time was 3m 58s.

If anyone has any suggestions for how I might alter the settings to improve 
the render I would be happy to rerun this test.

Mike

[clipka] Re: Radiosity testing [6303 days 3 hours and 14 minutes ago]

Sat, 10 Jan 2009 08:50:00 GMT

"Mike Hough" <nos### [at] nospamcom> wrote:
> Did a little testing of the radiosity in beta 30.

I suggest not wasting too much time examining performance of radiosity in beta
30, as it is just a beta 29 with a longer "life expectancy" (hm... the term
"beta decay" just comes to my mind ;))

The coming beta will have enough changes in radiosity code to make any
observations in this are perfectly obsolete - both regarding how good your
settings have to be to get rid of artifacts, as well as how long it then takes
to render.

(I can't promise that the "overhauled" radiosity code will be faster than the
beta.29 code in everyday practice - that's what it needs beta testing for - but
I'm sure it will behave significantly different from the beta.29.)

[Mike Hough] Re: Radiosity testing [6303 days 17 hours and 11 minutes ago]

Fri, 9 Jan 2009 18:53:28 GMT

Apparently I misread the post. I will run this again when the binary is 
released.

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4967676b@news.povray.org...
> Mike Hough <nos### [at] nospamcom> wrote:
>> Did a little testing of the radiosity in beta 30. On simple scenes it is
>> considerably faster but when I start to adjust the settings it slows
>> considerably.
>
>  But the radiosity in beta 30 is practically non-working. The beta with
> the fixes has not been published yet.
>
> -- 
>                                                          - Warp

[Warp] Re: Radiosity testing [6303 days 21 hours ago]

Fri, 9 Jan 2009 15:04:11 GMT

Mike Hough <nos### [at] nospamcom> wrote:
> Did a little testing of the radiosity in beta 30. On simple scenes it is 
> considerably faster but when I start to adjust the settings it slows 
> considerably.

  But the radiosity in beta 30 is practically non-working. The beta with
the fixes has not been published yet.

-- 
                                                          - Warp

[Mike Hough] Radiosity testing [6303 days 21 hours and 24 minutes ago]

Fri, 9 Jan 2009 14:40:05 GMT

Did a little testing of the radiosity in beta 30. On simple scenes it is 
considerably faster but when I start to adjust the settings it slows 
considerably. Here is one example. It can be a little hard to compare 
because 3.7 influences the brightness of images so much, but if you adjust 
the gamma these images look quite similiar in terms of the quality of the 
solution. I might give 3.6 a slight edge in that department. Scenes were 
rendered at 640x480, No AA on an Athlon X2 3.21ghz with 2GB RAM. 
Unfortunately the test scene is a little over 2mb, otherwise I would upload 
it as well.

render times
3.7 - 13m 2s
3.6 - 9m 18s

global_settings {
     radiosity {
      count 100
      nearest_count 10
       error_bound 0.02
      low_error_factor 0.2
      minimum_reuse 0.015
      adc_bailout 0.01/2
      recursion_limit 3
      gray_threshold 0.0
      brightness 2
      normal on
      }
    #end
    max_trace_level 256
    ambient_light 0
}

[triple r] Re: Smoke simulation [6313 days 21 hours and 54 minutes ago]

Tue, 30 Dec 2008 14:10:01 GMT

"Mike Hough" <nos### [at] nospamcom> wrote:
> Third time is the charm...first time file was too big; second time forgot to
> give it a title. Hopefully this one will go through.
>
> This took about 6 hours to render 80 frames at 512x384. It uses the wavelet
> turbulence program produced at Cornell. The smoke exceeds the bounding area
> which is why it gets the flat top near the end.

Hey, that looks pretty good!  Good compression, too.  Gee, what to blow up next?

 - Ricky

[Mike Hough] arghhh [6313 days 22 hours and 44 minutes ago]

Tue, 30 Dec 2008 13:20:43 GMT

Admins,

Was messing around trying to get this uploaded and sent it to the wrong 
group. Much appreciated if you could move it to p.b.a. and delete the 
previous post.

My apologies.

Mike

[Mike Hough] Smoke simulation [6313 days 22 hours and 45 minutes ago]

Tue, 30 Dec 2008 13:18:56 GMT

Third time is the charm...first time file was too big; second time forgot to 
give it a title. Hopefully this one will go through.

This took about 6 hours to render 80 frames at 512x384. It uses the wavelet
turbulence program produced at Cornell. The smoke exceeds the bounding area
which is why it gets the flat top near the end.

Mike

[Mike Hough] --- [6313 days 22 hours and 45 minutes ago]

Tue, 30 Dec 2008 13:18:53 GMT

Sending this again using a smaller file, since I am guessing 30 mb exceeds 
the size limit for this group.

This took about 6 hours to render 80 frames at 512x384. It uses the wavelet 
turbulence program produced at Cornell. The smoke exceeds the bounding area 
which is why it gets the flat top near the end.

Mike

[Quietman] Re: Certain POV file causes crash in beta 29 [6348 days 15 hours and 57 minutes ago]

Tue, 25 Nov 2008 20:07:38 GMT

Doesn't crash the 32 bit version of POV Ray 3.7 beta 29...

"scott" <sco### [at] scottcom> wrote in message news:492c1121@news.povray.org...
>> This file crashes POV beta 29 on Vista 64 bit on open/load.
>>
>> Can anyone else reproduce this?
> 
> It appears to be any file that is exactly 4096 bytes causes POV to crash 
> when trying to open the file.
> 
>

[scott] Re: Certain POV file causes crash in beta 29 [6348 days 21 hours and 12 minutes ago]

Tue, 25 Nov 2008 14:52:17 GMT

> This file crashes POV beta 29 on Vista 64 bit on open/load.
>
> Can anyone else reproduce this?

It appears to be any file that is exactly 4096 bytes causes POV to crash 
when trying to open the file.

[scott] Certain POV file causes crash in beta 29 [6348 days 21 hours and 16 minutes ago]

Tue, 25 Nov 2008 14:48:34 GMT

This file crashes POV beta 29 on Vista 64 bit on open/load.

Can anyone else reproduce this?

[nemesis] Re: Animation with Radiosity: Terrible "Flickeri... [6696 days 17 hours and 4 minutes ago]

Thu, 13 Dec 2007 19:00:00 GMT

"Sven Littkowski" <jam### [at] yahoocom> wrote:
> Hi. What means: RTFM?

"Read The Fucking Manual".  it's part of data centers lore... :)

[Alain] Re: Animation with Radiosity: Terrible "Flickeri... [6696 days 20 hours and 1 minute ago]

Thu, 13 Dec 2007 16:03:25 GMT

Sven Littkowski nous apporta ses lumieres en ce 2007/12/13 10:18:
> Hi. What means: RTFM?
> 
Read The Fucking Manual.

-- 
Alain
-------------------------------------------------
Zen Buddhism: Shit is, and is not.

[Sven Littkowski] Re: Animation with Radiosity: Terrible "Flickeri... [6696 days 20 hours and 45 minutes ago]

Thu, 13 Dec 2007 15:19:09 GMT

Hi. What means: RTFM?

I can read there (your link), that radiosity is still alpha quality. But 
that is said even since version 3.5. I hope that the POV team will find a 
way to make radiosity better. Maybe by not taking a pixel sample (as a part 
of the radiosity function) as base for adding radiosity to that environment 
next to that pixel, but a sample of a blurred area. Just an idea.

Sven Littkowski

"Thorsten Froehlich" <tho### [at] trfde> wrote in message 
news:475ffe60$1@news.povray.org...
> Sven Littkowski wrote:
>> Hi!
>>
>> I made a brief animation with the current beta version ( a starship 
>> flying
>> by), but through the current radiosity technology, the ship with its many
>> ambient windows (bulleyes) on gray steel texture appears like flickering
>> wildly.
>
> RTFM: <http://www.povray.org/beta/>
>
> Thorsten

[Thorsten Froehlich] Re: Animation with Radiosity: Terrible "Flickeri... [6697 days 20 hours and 35 minutes ago]

Wed, 12 Dec 2007 15:29:36 GMT

Sven Littkowski wrote:
> Hi!
> 
> I made a brief animation with the current beta version ( a starship flying 
> by), but through the current radiosity technology, the ship with its many 
> ambient windows (bulleyes) on gray steel texture appears like flickering 
> wildly.

RTFM: <http://www.povray.org/beta/>

	Thorsten

[Sven Littkowski] Animation with Radiosity: Terrible "Flickering" [6697 days 21 hours and 12 minutes ago]

Wed, 12 Dec 2007 14:52:30 GMT

Hi!

I made a brief animation with the current beta version ( a starship flying 
by), but through the current radiosity technology, the ship with its many 
ambient windows (bulleyes) on gray steel texture appears like flickering 
wildly.

Please see a qualitivly downsized version at YouTube (an older version, but 
the same flickering):
http://www.youtube.com/watch?v=oPs3e6n9hwc

Can the flickering problem please be soved with the new version of POVRAY?

Sven Littkowski

[Thorsten Froehlich] Re: #undef crashes whole engine [7112 days 12 hours and 13 minutes ago]

Mon, 23 Oct 2006 23:51:37 GMT

CIma wrote:
> The povray crashed down after I tried to render this right after adding the
> block with #undef directives. I've added this because of problems with
> #local variables.

Is this meant as a bug report, or a follow-up to some bug report in
p.beta-test?  This group is for posting files related to bug reports, not
for making bug reports.

	Thorsten

[CIma] #undef crashes whole engine [7115 days and 9 minutes ago]

Sat, 21 Oct 2006 11:55:01 GMT

The povray crashed down after I tried to render this right after adding the
block with #undef directives. I've added this because of problems with
#local variables.

[StephenS] Cornell, BSP issue [7245 days 1 hour and 8 minutes ago]

Tue, 13 Jun 2006 10:56:36 GMT

Cornell.pov renders differently with different settings for BSP.

I set up an ini file with the following
Input_File_Name = cornell
Bounding=on
Bounding_Method = 2
;BSP_MaxDepth=5
BSP_MaxDepth=4

In cornell.pov I commented out the global settings (assumed_gamma and 
radiosity).

3.7.0.beta.13.icl8.win32
Win XP media center edition 2002 sp2
AMD Athlon 64 X2 4200+ 2Gb

Stephen

[Lance Birch] Crash! Boum! Bang! (different problem, but from... [7260 days 4 hours and 43 minutes ago]

Mon, 29 May 2006 07:21:16 GMT

Extract the image + .pov file and start the .pov file rendering.  As soon as it
starts parsing, hit Stop.  Once it confirms "Render cancelled by user", close
the POV-Ray front end (File -> Exit, or just click the X in the top corner).

The window will close but pvengine continues to end parsing, and when it finally
finishes it generates a VC++ runtime error "This application has requested the
Runtime to terminate it in an unusual way."

As I said, this is unrelated to the problem that Sven is having, but I noticed
it while trying to replicate his issue.

Lance.

[Sven Littkowski] Crash! Boum! Bang! [7260 days 17 hours and 15 minutes ago]

Sun, 28 May 2006 18:48:52 GMT

Hi. This is the scene which causes POV-Ray to crash when the parsing 
procedure is being stopped. I believe the large images may cause the crash, 
somehow. Not sure, though.

Sven




#include "colors.inc"
#include "textures.inc"
#include "shapes.inc"
#include "metals.inc"
#include "glass.inc"
#include "woods.inc"

#declare Earth = texture { pigment { image_map { jpeg "E:\Scripts\Eigene 
Bilder\Povray Textures\Sphere_Earth_01.jpg" map_type 1 } rotate < 0.0, 0.0, 
0.0 > } finish { ambient 0.0 } }   // 2.31 MB - Can't post it - I add it as 
a SMALL version so you can see the kind of the JPEG file: 5400-->540px, 
2700-->270px
#declare EarthLights = texture { pigment { image_map { png 
"E:\Scripts\Eigene Bilder\Povray Textures\Sphere_Earth_Lights_01.png" 
map_type 1 } rotate < 0.0, 0.0, 0.0 > } finish { ambient 1.0 } }   // 2.22 
MB - Can't post it - I add it as a SMALL version so you can see the kind of 
the PNG file: 7500-->750px, 3750-->375px
#declare EarthClouds = texture { pigment { image_map { png 
"E:\Scripts\Eigene Bilder\Povray Textures\Sphere_Earth_Clouds_03.png" 
map_type 1 } rotate < 0.0, 0.0, 0.0 > } finish { ambient 0.0 } }   // 16.0 
MB - Can't post it - I add it as a SMALL version so you can see the kind of 
the PNG file: 4096-->409px, 2048-->205px

global_settings
{
 assumed_gamma 2.0
 radiosity {  }  //
}

camera
{
 location < 000.0, 0.0, -300.0 >
 look_at < 000.0, 0.0, 0.0 >
}
/**/
light_source
{
 < 1000.0, 0.0, 250.0 >
 color White *3
}

#declare Earth_Surface=sphere
{
 0.0, 1.0
 texture { Earth }
 texture { EarthLights }
 normal
 {
  bump_map
  {
   jpeg "Sphere_Earth_Bumps_01.jpg"   // 89.0 KB
   map_type 1
  }
 }
}

#declare Earth_Clouds=sphere
{
 0.0, 1.0005
 texture { EarthClouds }
 normal
 {
  bump_map
  {
   jpeg "Sphere_Earth_Clouds_Bumps_03.jpg"   // 5.11 MB - Can't post it - I 
add it as a SMALL version so you can see the kind of the JPEG file: 
4096-->409px, 2048-->205px
   map_type 1
  }
 }
}

#declare Earth_Atmosphere=sphere
{
 < 0.0, 0.0, 0.0 > 1.0
 pigment
 {
  color rgbt < 1.0, 1.0, 1.0, 1.0 >
 }
 hollow
 interior
 {
  media
  {
   intervals 10
   emission 0.75
   density
   {
    spherical
    color_map
    {
     [ 0.000 rgb < 0.0, 0.0, 0.0 > ]
     [ 1.000 rgb < 0.1, 0.1, 0.5 > ]
    }
   }
   samples 1, 10
   confidence 0.9999
   variance 1/1000
   ratio 0.9
  }
 }
 finish { ambient 0.0 }
 scale 1.0075
}

#declare Earth_Atmosphere1=sphere
{
 < 0.0, 0.0, 0.0 > 1.0
 pigment
 {
  spherical
  pigment_map
  {
   [ 0.0000 Clear ]  // Surface
   [ 0.0001 Blue ]
   [ 0.0001 Blue ]
   [ 1.0000 Clear ]  // Center
  }
 }
 finish { ambient 0.0 }
 scale 1.0075
}

#declare Earth=union
{
 object { Earth_Surface }   //
 object { Earth_Clouds }   //
 object { Earth_Atmosphere }
 scale 100.0
}

object { Earth }

[Christoph Hormann] Re: HDR image reversed when read [7370 days 18 hours and 29 minutes ago]

Tue, 7 Feb 2006 17:35:03 GMT

Trevor G Quayle wrote:
> 
> As a follow up, I tried writing and reading HDR images successively in the
> beta.  (i.e., write the HDR, then read the HDR output by POV as an image
> map and rewrite, etc.).  This had the effect of flipping the image back and
> forth.  It would appear to me that the output is being written correctly,
> but that it is being read backwards.

Yes, indeed it seems the current reading code mirrors the image.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

[Trevor G Quayle] Re: HDR image reversed when read [7370 days 21 hours and 24 minutes ago]

Tue, 7 Feb 2006 14:40:01 GMT

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > The radiance HDR format supports different orientations of the image but
> > the reader in POV-Ray treats all the same way currently (just like most
> > other HDR readers around).  So you should make sure the program you use to
> > write the HDR files uses normal (top to bottom, left to right)
> > orientation.
> >
> > Christoph
>
> Opens forwards in HDRShop which I would think is a common HDR program.  It
> also opens forwards in megapov.
>
> -tgq

As a follow up, I tried writing and reading HDR images successively in the
beta.  (i.e., write the HDR, then read the HDR output by POV as an image
map and rewrite, etc.).  This had the effect of flipping the image back and
forth.  It would appear to me that the output is being written correctly,
but that it is being read backwards.  The attached image shows three
successive outputs from this method (converted to jpg by HDRShop)

As a side note, I also noticed that I get "Unrecognized output file format
H" after the render even though the render and image creation was
successful.

SCENE FILE:
//start
camera{orthographic
  up y*2*image_height/image_width
  right x*2
  location <0,0,-2>
  look_at  <0,0,0>
}

#declare Map="beta1.hdr"; //HDR - name of HDR output by POV
box{<0,0,0><1,1,1>
  pigment {image_map {hdr Map once interpolate 2 map_type 0}}
  finish {ambient 1 diffuse 0}
  translate <-0.5,-0.5,0.1>
  scale <2,2*image_height/image_width,1>
}
//end

-tgq

[Trevor G Quayle] Re: HDR image reversed when read [7370 days 23 hours and 54 minutes ago]

Tue, 7 Feb 2006 12:10:46 GMT

> The radiance HDR format supports different orientations of the image but 
> the reader in POV-Ray treats all the same way currently (just like most 
> other HDR readers around).  So you should make sure the program you use to 
> write the HDR files uses normal (top to bottom, left to right) 
> orientation.
>
> Christoph

Opens forwards in HDRShop which I would think is a common HDR program.  It 
also opens forwards in megapov.

-tgq

[Christoph Hormann] Re: HDR image reversed when read [7371 days 3 hours and 9 minutes ago]

Tue, 7 Feb 2006 08:55:03 GMT

Trevor G Quayle wrote:
> Windows XP Pro - 2.4GHz - 1.0GB RAM - beta11
> 
> As can be seen in the attached images, HDR format images seem to be reversed 
> when read.   The scene displays simply a box with an image map and is 
> identical for both except on uses a BMP format image and the other uses a 
> HDR format image, both made from the same original JPG file. This is valid 
> for "map_type 0", I haven't tested for others.

The radiance HDR format supports different orientations of the image but 
the reader in POV-Ray treats all the same way currently (just like most 
other HDR readers around).  So you should make sure the program you use 
to write the HDR files uses normal (top to bottom, left to right) 
orientation.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

[Trevor G Quayle] HDR image reversed when read [7371 days 8 hours and 14 minutes ago]

Tue, 7 Feb 2006 03:50:38 GMT

Windows XP Pro - 2.4GHz - 1.0GB RAM - beta11

As can be seen in the attached images, HDR format images seem to be reversed 
when read.   The scene displays simply a box with an image map and is 
identical for both except on uses a BMP format image and the other uses a 
HDR format image, both made from the same original JPG file. This is valid 
for "map_type 0", I haven't tested for others.

SCENE FILE:

//start

#declare Map="megane.hdr"; //HDR
//#declare Map="megane.bmp"; //BMP
camera{orthographic
  up y*2.05*image_height/image_width
  right x*2.05
  location <0,-0.15,-2>
  look_at  <0,-0.15,0>
}
box{<0,0,0><1,1,1> pigment {image_map {hdr Map once interpolate 2 map_type 
0}} finish {ambient 1 diffuse 0} scale <2,1,1> translate <-1,-.5,0.1> } 
//HDR
//box{<0,0,0><1,1,1> pigment {image_map {hdr Map once interpolate 2 map_type 
0}} finish {ambient 1 diffuse 0} scale <2,1,1> translate <-1,-.5,0.1> } 
//BMP

//end

-tgq

[Trevor G Quayle] PNG not writing correctly [7371 days 8 hours and 34 minutes ago]

Tue, 7 Feb 2006 03:30:35 GMT

Windows XP Pro - 2.4GHz - 1.0GB RAM - beta11

I decide to try the beta with a process I've been working with and came 
across a couple possible bugs.  When outputing to PNG there may be a 
problem.  I can read the image file in programs like "MS Paint" and "Windows 
Picture and Fax Viewer", however "Microsoft Photo Editor" gives an "Error 
Reading File" error.  I have attached 2 PNG format outputs of a blank scene 
for reference, one from 3.7b11 that doesn't open in MSPE, and one from 3.6 
that does open  (the 3.6 one is almost twice the file size as well).

No particular scene required to replicate.

-tgq

[Bob Hughes] light doesn't pass transparent parts of image_map [7418 days 20 hours ago]

Wed, 21 Dec 2005 16:04:19 GMT

See beta-test message of same subject line.

Light cannot pass transparent parts of image map.

[JYR] Re: [beta9] Radiosity results [7476 days 21 hours and 24 minutes ago]

Mon, 24 Oct 2005 14:40:00 GMT

"Stefan Persson" <azy### [at] hotmailcom> wrote:
> Are you sure that's not 1 Gib RAM? ;)
>
> Stefan
> "JYR" <jyr### [at] hotmailcom> skrev i meddelandet
> news:web.432d785819e9b6e56cc14b5c0@news.povray.org...
> > here are the first results i got with radiosity with beta 9,
> > (win XP home edition, AMD Athlon XP 2800+, 1 MB RAM)

no, i meant it   ;)
Must've been a day with 1 bite of allocatable brain cells.

JYR

[Stefan Persson] Re: [beta9] Radiosity results [7477 days 6 hours and 11 minutes ago]

Mon, 24 Oct 2005 05:53:25 GMT

Are you sure that's not 1 Gib RAM? ;)

Stefan
"JYR" <jyr### [at] hotmailcom> skrev i meddelandet 
news:web.432d785819e9b6e56cc14b5c0@news.povray.org...
> here are the first results i got with radiosity with beta 9,
> (win XP home edition, AMD Athlon XP 2800+, 1 MB RAM)

[JYR] [beta9] Radiosity results [7512 days 21 hours and 34 minutes ago]

Sun, 18 Sep 2005 14:30:00 GMT

here are the first results i got with radiosity with beta 9,
(win XP home edition, AMD Athlon XP 2800+, 1 MB RAM)

with the following code.


//BEGIN CODE
#declare span=<0,-20,0> ;

global_settings {
        max_trace_level 5
        radiosity{
                pretrace_start .08
                pretrace_end   .01
                count 360

                nearest_count 8
                error_bound .02
                recursion_limit 1

                low_error_factor 0.35
                gray_threshold 0
                minimum_reuse .01
                brightness 1
                adc_bailout 0.01
                }
        }

camera {
   location     <0,0,-4.5>
   look_at      <0,0,0>
   rotate       span
}

light_source {<6, 0, -4.5> rgb 2}

plane {y, -1 pigment {rgb <1, .8, .10>} finish {ambient 0 diffuse .9}}
sphere {0, 1 pigment {red 1} finish {ambient 0 diffuse .9}}
//box{-1,1 pigment {red 1} finish {ambient 0 diffuse .9} rotate 20*y}

//END CODE

on the left, with 3.6.1a, on the right with beta 9.

JYR

[Bob Hughes] media will be (or is) changed? [7610 days 1 hour and 13 minutes ago]

Mon, 13 Jun 2005 10:50:50 GMT

See same subject at povray.beta-test

[Bob Hughes] any opinions about lamppost.pov? [7633 days 13 hours and 23 minutes ago]

Fri, 20 May 2005 22:41:15 GMT

This file, in scenes\advanced subfolder, lamppost.pov sure seems to need
something to make the rendering more clearly viewable to show what it is.
Anyone agree, or disagree? Thought I should ask if the suggestion to change
it now might be okay at this point in time? See a comparison of the original
at left with my changes to it on the right. BTW, render time jumped way up
since I used a 5X5 area light and exchanged the solid glass cone to plates
of glass (4 prisms).

[Nathan Shomber] Memory Leak in SSE2 b3 [7649 days 21 hours and 45 minutes ago]

Wed, 4 May 2005 14:19:27 GMT

See post in povray.beta-test.

This is a new one for me:

[Mike Raiford] 3.7b3: Area Light Artifacts [7651 days 23 hours and 57 minutes ago]

Mon, 2 May 2005 12:07:08 GMT

Left: 3.6, Right 3.7b3
-- 
~Mike

Things! Billions of them!

[ingo] Re: chekered splotchiness [7665 days 21 hours and 9 minutes ago]

Mon, 18 Apr 2005 14:55:32 GMT

in news:Xns963B749DC767Fseed7@news.povray.org ingo wrote:

> I'll investigate this, and other scenes, a bit more 
> later today.
> 

Seems to depend on +AM1 or +AM2, as already Gilles mentioned in the beta-
test group.

Ingo

[ingo] chekered splotchiness [7667 days 2 hours and 36 minutes ago]

Sun, 17 Apr 2005 09:27:51 GMT

The strange checker like pattern should not be there, all textures are 
plain colours. Object is a mesh2. The pattern does not seem to be random. 
After adding /TREAHDS 1 it's also there. It's the first scene I rendered 
with the new beta. I'll investigate this, and other scenes, a bit more 
later today.

POV-Ray 3.7 beta-1
win2000 athlon 1800+


Ingo

[fomhorian] Re: radiosity nag. [7980 days 23 hours and 44 minutes ago]

Mon, 7 Jun 2004 12:20:01 GMT

A small addendum here:

I did the same scene with sphere{}, and other basic POVRay
objects, and fresnel exponent 1.5 and got the same strange result.
So it is not my mesh...

Oh:
>You don't seriously want to call that minimal, do you?

When I started with POVRay back in 1999 on my Pentium 75mhz
and DOS; I had meshes, in smooth_triangle, up to 35 megs!
Imagine the loading-time for those ;)

                              ..And I'm off for breakfast..

[fomhorian] Re: radiosity nag. [7981 days and 19 minutes ago]

Mon, 7 Jun 2004 11:45:00 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> Thorsten Froehlich wrote:
> > In article <c9vdmc$64c$1@chho.imagico.de> , Christoph Hormann
> > <chr### [at] gmxde>  wrote:
> >
> >
> >>I really can't see a reason why one would try to use something like
> >
> >
> > I guess it is some program generating this output.  As you apparently have
> > both 3.5 and 3.6 running, could you try to comment out one of the parameters
> > until you find the one interpreted differently?
>
> It seems to be the reflection 'exponent sqrt(2)'.  Note i also get
> occasional render freezes (i.e. the render halts and the program can
> only be stopped by multiple CTRL-Cs) in 3.6 when using the fresnel
> reflection.    Since i never had any problems with fresnel reflection
> before i assume this is something specific to this scene (i.e. the
> mesh).  Lowering max_trace_level strongly or not using radiosity avoids
> this (so maybe the ray recursion handling of radiosity in combination
> with reflection does not work properly although i have rendered a lot of
> scenes with radiosity + reflection without problems).
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 01 May. 2004 _____.//^>_*_<^/.______

Good morning folks!

Yes I too boiled it down to the 'exponent sqrt(2)'. the scene looks
fine as long as I use an exponent <= 1.0 in POVRay 3.6 .
Freezez? No, haven't come across those...

[Gilles Tran] Re: radiosity nag. [7981 days 11 hours and 55 minutes ago]

Mon, 7 Jun 2004 00:08:59 GMT

"Christoph Hormann" <chr### [at] gmxde> a écrit dans le message de
news:c9vgh2$6vg$1@chho.imagico.de...
> It seems to be the reflection 'exponent sqrt(2)'.  Note i also get
> occasional render freezes (i.e. the render halts and the program can
> only be stopped by multiple CTRL-Cs) in 3.6 when using the fresnel
> reflection.

For the record, I also observed an extremely nasty combination of mesh,
radiosity, reflection and prism (!), generating large black artifacts where
3.5 performed OK. Unfortunately I wasn't able to replicate it using a
smaller scene (the scene I used is around 50-100 Mb), so I couldn't report
it. But something is definitely lurking out there...

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

[Thorsten Froehlich] Re: radiosity nag. [7981 days 16 hours and 52 minutes ago]

Sun, 6 Jun 2004 19:11:49 GMT

In article <c9vgh2$6vg$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> It seems to be the reflection 'exponent sqrt(2)'.

OK, so in conclusion that setting should be changed in fomhorian's scene and
it will work.

> Note i also get
> occasional render freezes (i.e. the render halts and the program can
> only be stopped by multiple CTRL-Cs) in 3.6 when using the fresnel
> reflection.

Sounds like stack overflows.  I will need to take a look at the fresnel
implementation to find out what that happens.

>  Since i never had any problems with fresnel reflection
> before i assume this is something specific to this scene (i.e. the
> mesh).  Lowering max_trace_level strongly or not using radiosity avoids
> this (so maybe the ray recursion handling of radiosity in combination
> with reflection does not work properly although i have rendered a lot of
> scenes with radiosity + reflection without problems).

OK, if you find some time, take a look.  Otherwsie, we won't bother for 3.6.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[Thorsten Froehlich] Re: radiosity nag. [7981 days 17 hours and 39 minutes ago]

Sun, 6 Jun 2004 18:25:34 GMT

In article <web.40c346e89346345c307441310@news.povray.org> , "fomhorian" 
<fom### [at] hotmailcom> wrote:

> "Thorsten Froehlich" <tho### [at] trfde> wrote:
>> In article <c9vdmc$64c$1@chho.imagico.de> , Christoph Hormann
>> <chr### [at] gmxde>  wrote:
>>
>> > I really can't see a reason why one would try to use something like
>>
>> I guess it is some program generating this output.  As you apparently have
>> both 3.5 and 3.6 running, could you try to comment out one of the parameters
>> until you find the one interpreted differently?
>>
>>     Thorsten
>>
>> ____________________________________________________
>> Thorsten Froehlich, Duisburg, Germany
>> e-mail: tho### [at] trfde
>>
>> Visit POV-Ray on the web: http://mac.povray.org
>
> I'll try later this week, I'm currently working nightshift, and
> today we start at 2000, so I won't get out of bed until 1300 or so..
> Terribly sorry!

My reply was to Christoph.  Nothing for you to worry about :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[fomhorian] Re: radiosity nag. [7981 days 19 hours and 29 minutes ago]

Sun, 6 Jun 2004 16:35:01 GMT

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> In article <c9vdmc$64c$1@chho.imagico.de> , Christoph Hormann
> <chr### [at] gmxde>  wrote:
>
> > I really can't see a reason why one would try to use something like
>
> I guess it is some program generating this output.  As you apparently have
> both 3.5 and 3.6 running, could you try to comment out one of the parameters
> until you find the one interpreted differently?
>
>     Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org

I'll try later this week, I'm currently working nightshift, and
today we start at 2000, so I won't get out of bed until 1300 or so..
Terribly sorry!
                               Greetings from the Swedish summer
                               (not a polarbear in sight ;)

[Christoph Hormann] Re: radiosity nag. [7981 days 19 hours and 34 minutes ago]

Sun, 6 Jun 2004 16:30:01 GMT

Thorsten Froehlich wrote:
> In article <c9vdmc$64c$1@chho.imagico.de> , Christoph Hormann 
> <chr### [at] gmxde>  wrote:
> 
> 
>>I really can't see a reason why one would try to use something like
> 
> 
> I guess it is some program generating this output.  As you apparently have
> both 3.5 and 3.6 running, could you try to comment out one of the parameters
> until you find the one interpreted differently?

It seems to be the reflection 'exponent sqrt(2)'.  Note i also get 
occasional render freezes (i.e. the render halts and the program can 
only be stopped by multiple CTRL-Cs) in 3.6 when using the fresnel 
reflection.    Since i never had any problems with fresnel reflection 
before i assume this is something specific to this scene (i.e. the 
mesh).  Lowering max_trace_level strongly or not using radiosity avoids 
this (so maybe the ray recursion handling of radiosity in combination 
with reflection does not work properly although i have rendered a lot of 
scenes with radiosity + reflection without problems).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

[Thorsten Froehlich] Re: radiosity nag. [7981 days 20 hours and 12 minutes ago]

Sun, 6 Jun 2004 15:52:32 GMT

In article <c9vdmc$64c$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> I really can't see a reason why one would try to use something like

I guess it is some program generating this output.  As you apparently have
both 3.5 and 3.6 running, could you try to comment out one of the parameters
until you find the one interpreted differently?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[Thorsten Froehlich] Re: radiosity nag. [7981 days 20 hours and 16 minutes ago]

Sun, 6 Jun 2004 15:48:42 GMT

In article <c9vdmc$64c$1@chho.imagico.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> The most likely explanation of the difference you observe is that one of
> your extremely ugly finish parameters is interpreted differently in 3.6
> as a side effect of another change.  When i remove all those finishes
> the results i get in 3.5 and 3.6 are idetical.

Well, the point is not if they are ugly but if they are valid.  We should
try to figure out which change causes this and maybe issue an error if any
of the specified parameters is outside valid bounds (assuming that is the
problem)...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[Christoph Hormann] Re: radiosity nag. [7981 days 20 hours and 24 minutes ago]

Sun, 6 Jun 2004 15:40:02 GMT

fomhorian wrote:
> Okidoki, but I don't know if it is that small...

You don't seriously want to call that minimal, do you?

The most likely explanation of the difference you observe is that one of 
your extremely ugly finish parameters is interpreted differently in 3.6 
as a side effect of another change.  When i remove all those finishes 
the results i get in 3.5 and 3.6 are idetical.

I really can't see a reason why one would try to use something like

       finish{
         ambient  0.05
         diffuse 0.4
         brilliance 2.5
         metallic 1.5
         specular 2 roughness 0.05
         phong 0.5 phong_size 30
         reflection{
          <0,1,0.5>*0.005,0.05
          metallic 0.25
          fresnel on
           falloff 0.5
           exponent sqrt(2)
         }
         }

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

[fomhorian] Re: radiosity nag. [7981 days 20 hours and 49 minutes ago]

Sun, 6 Jun 2004 15:15:01 GMT

Okidoki, but I don't know if it is that small...

[Christoph Hormann] Re: radiosity nag. [7981 days 21 hours and 29 minutes ago]

Sun, 6 Jun 2004 14:35:02 GMT

fomhorian wrote:
> 
>>The scene you posted renders the same in 3.5 and 3.6 here.  No 'ship' is
>>visible at all.  You will need to post a scene and images showing the
>>difference with *exactly* this scene for being of any use to trace down
>>a possible problem.
> 
> I did and I have! I put both a POVRay 3.5 and a POVRay 3.6 version
> of the e x a c t same scene on this board. I also put the scene without
> the mesh here, check both beta-test and beta-test.binaries.
> 

There is nothing in your postings that enables us to reproduce your 
problem.  Without this you can't expect anyone to be able to explain the 
difference you observe.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

[Thorsten Froehlich] Re: radiosity nag. [7981 days 21 hours and 38 minutes ago]

Sun, 6 Jun 2004 14:26:37 GMT

In article <web.40c31ee49346345c307441310@news.povray.org> , "fomhorian" 
<fom### [at] hotmailcom> wrote:

> I did and I have! I put both a POVRay 3.5 and a POVRay 3.6 version
> of the e x a c t same scene on this board. I also put the scene without
> the mesh here, check both beta-test and beta-test.binaries.

You don't understand.  Beta or not, we need a *complete* but minimal scene
to reproduce the problem.  The information needed to reproduce a problem is
outlined in:

From: Alan Kong <ako### [at] povrayWWWSPAMCOMorg>
Newsgroups: povray.announce.frequently-asked-questions
Subject: bug reporting
Date: Wed, 10 Jul 2002 20:32:49 -0700
Message-ID: <fpupiu02i1198jbb38i3o06hv6is1a3uar@4ax.com>
Xref: news.povray.org povray.announce.frequently-asked-questions:50

<http://news.povray.org/fpupiu02i1198jbb38i3o06hv6is1a3uar%404ax.com>

Without a complete and minimal scene, we will not be able to reproduce your
problem and thus will not be able to help you!

    Thorsten

PS: Please note that the final release of POV-Ray 3.6 will be in less than
48 hours, so should this really be a problem in POV-Ray and not in your
scene, we will need your complete but minimal scene *soon*.  Thus, arguing
with us about the information you provided makes it more likely you will
have to wait many month for the problem to be corrected, should it indeed be
in POV-Ray and not in your scene.

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[fomhorian] Re: radiosity nag. [7981 days 22 hours and 19 minutes ago]

Sun, 6 Jun 2004 13:45:01 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> The scene you posted renders the same in 3.5 and 3.6 here.  No 'ship' is
> visible at all.  You will need to post a scene and images showing the
> difference with *exactly* this scene for being of any use to trace down
> a possible problem.
>
> Christoph

I did and I have! I put both a POVRay 3.5 and a POVRay 3.6 version
of the e x a c t same scene on this board. I also put the scene without
the mesh here, check both beta-test and beta-test.binaries.

[Christoph Hormann] Re: radiosity nag. [7982 days and 44 minutes ago]

Sun, 6 Jun 2004 11:20:02 GMT

fomhorian wrote:
> 
> Well; in comparison to the image traced by POVRay 3.5, also posted
> to this board, I have this big black blotch in the center of my
> image :( I tried to up the quality today to see if it was that
> which caused the effect, but as you can see it actually got
> worse, in my opinion that is, with the blackness almost totally
> covering the ship! And no, I didn't get any kind of error-messages.

The scene you posted renders the same in 3.5 and 3.6 here.  No 'ship' is 
visible at all.  You will need to post a scene and images showing the 
difference with *exactly* this scene for being of any use to trace down 
a possible problem.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

[fomhorian] Re: radiosity nag. [7982 days and 54 minutes ago]

Sun, 6 Jun 2004 11:10:01 GMT

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Looking at the render of the scene you provided, I cannot see anything
> wrong.  What wrong output should one expect to see in the scene you posted?
>
>     Thorsten

Well; in comparison to the image traced by POVRay 3.5, also posted
to this board, I have this big black blotch in the center of my
image :( I tried to up the quality today to see if it was that
which caused the effect, but as you can see it actually got
worse, in my opinion that is, with the blackness almost totally
covering the ship! And no, I didn't get any kind of error-messages.

[Thorsten Froehlich] Re: radiosity nag. [7982 days 4 hours and 59 minutes ago]

Sun, 6 Jun 2004 07:04:54 GMT

In article <web.40c1fbd29346345c307441310@news.povray.org> , "fomhorian" 
<fom### [at] hotmailcom> wrote:

> Christoph Hormann <chr### [at] gmxde> wrote:
>> fomhorian wrote:
>> > Example images of my little
>> > radiosity problems.
>>
>> I don't see anything indicating this difference being related to
>> radiosity and i also don't see a reason why the 3.5 version should be
>> 'correct' while the other is wrong.  If you want to know what causes
>> this difference you will have to post the code (only a minimal scene,
>> not the whole mesh!)
>>
>> Christoph
>>
>> --
>> POV-Ray tutorials, include files, Sim-POV,
>> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
>> Last updated 01 May. 2004 _____.//^>_*_<^/.______
>
> Okay, here it is!
> The scene isn't really that big w the mesh either but...

Looking at the render of the scene you provided, I cannot see anything
wrong.  What wrong output should one expect to see in the scene you posted?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[Thorsten Froehlich] Re: radiosity nag. [7982 days 5 hours and 6 minutes ago]

Sun, 6 Jun 2004 06:57:51 GMT

In article <web.40c1fbd29346345c307441310@news.povray.org> , "fomhorian" 
<fom### [at] hotmailcom> wrote:

> Okay, here it is!
> The scene isn't really that big w the mesh either but...

Do you get any render-time messages from POV-Ray suggesting something could
be wrong?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[fomhorian] Re: radiosity nag. [7982 days 19 hours and 4 minutes ago]

Sat, 5 Jun 2004 17:00:01 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> fomhorian wrote:
> > Example images of my little
> > radiosity problems.
>
> I don't see anything indicating this difference being related to
> radiosity and i also don't see a reason why the 3.5 version should be
> 'correct' while the other is wrong.  If you want to know what causes
> this difference you will have to post the code (only a minimal scene,
> not the whole mesh!)
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 01 May. 2004 _____.//^>_*_<^/.______

Okay, here it is!
The scene isn't really that big w the mesh either but...

[Christoph Hormann] Re: radiosity nag. [7982 days 19 hours and 39 minutes ago]

Sat, 5 Jun 2004 16:25:01 GMT

fomhorian wrote:
> Example images of my little
> radiosity problems.

I don't see anything indicating this difference being related to 
radiosity and i also don't see a reason why the 3.5 version should be 
'correct' while the other is wrong.  If you want to know what causes 
this difference you will have to post the code (only a minimal scene, 
not the whole mesh!)

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

[fomhorian] Re: radiosity nag. [7982 days 19 hours and 59 minutes ago]

Sat, 5 Jun 2004 16:05:01 GMT

Hmm; only one image per message..

[fomhorian] Re: radiosity nag. [7982 days 19 hours and 59 minutes ago]

Sat, 5 Jun 2004 16:05:01 GMT

Example images of my little
radiosity problems.

[David Bucciarelli] Re: Incorrect image height in output file (with ... [8009 days ago]

Mon, 10 May 2004 12:03:57 GMT

Christoph Hormann wrote:
> David Bucciarelli wrote:
> 
>> The result of the following command "povray +W100 +H100 +SR0 +ER50 +FP 
>> +Otest.ppm test.ini" is an incorrect image.
>>
>> The header of the PPM file is:
>>
>> P6
>> 100 100
>> 255
>> [...]
>>
>> but it includes only 50 rows. The height of the image file should be 
>> 50 instead of 100.
> 
> 
> This is as intended, otherwise you could not append to the image file in 
> a continued trace.  Also it has been this way in all previous versions 
> of POV-Ray and not just 3.6.

Mmmm, I understand your point however it is strange behavior because 
opening the "test.ppm" file with xv, gimp or Java ImageIO API fails or 
reports errors. Anyway I understand that this behavior is required by 
the "+C" option.

Thanks anyway,
David Bucciarelli

[Christoph Hormann] Re: Incorrect image height in output file (with ... [8009 days 2 hours and 9 minutes ago]

Mon, 10 May 2004 09:55:02 GMT

David Bucciarelli wrote:
> The result of the following command "povray +W100 +H100 +SR0 +ER50 +FP 
> +Otest.ppm test.ini" is an incorrect image.
> 
> The header of the PPM file is:
> 
> P6
> 100 100
> 255
> [...]
> 
> but it includes only 50 rows. The height of the image file should be 50 
> instead of 100.

This is as intended, otherwise you could not append to the image file in 
a continued trace.  Also it has been this way in all previous versions 
of POV-Ray and not just 3.6.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

[David Bucciarelli] Incorrect image height in output file (with +SR/... [8009 days 2 hours and 24 minutes ago]

Mon, 10 May 2004 09:40:00 GMT

The result of the following command "povray +W100 +H100 +SR0 +ER50 +FP 
+Otest.ppm test.ini" is an incorrect image.

The header of the PPM file is:

P6
100 100
255
[...]

but it includes only 50 rows. The height of the image file should be 50 
instead of 100.

Thanks,
David Bucciarelli

[Rafal 'Raf256' Maj] 3.6.beta4.win32 bug interpolate 2 and density_fi... [8019 days 10 hours and 46 minutes ago]

Fri, 30 Apr 2004 01:18:42 GMT

read more in povray.beta-test


// bug found by Rafal Maj raf256.com
// strange effect when using illegal interpolate 2 for density file
// confirmed PRESENT in: PovRay 3.6.beta4.win32
// confirmed   NOT   in: PovRay 3.5.win32
// render with any options, i.e.: +w640 +h480 +a0.02 +am2 +ar2 +fn

box { 0, 1
  pigment { color rgbt 1 }
	interior {
		media {  emission 3
	    density { density_file df3 "spiral.df3" 
        interpolate 2 // <------- illegal, should be 0 or 1 !
			}
	  }
	}
	hollow translate z*1-.5
}


-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

[Hughes, B ] Re: pov 3.6 beta 3 bug - bright media - 2 attach... [8039 days 9 hours and 6 minutes ago]

Sat, 10 Apr 2004 02:58:34 GMT

"Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote in message
news:Xns94C6C683AA0FBraf256com@203.29.75.35...
>
> See in p.beta-test and p.b.s-f
>
> ifj_logo_a.v040.pov36beta3_win32.png - contains random bright-yellow
pixels
> (different position each time You render same scene).


Oh. This is unlikely to be for the reason I thought (in reply at p.b-t)
concerning jitter, wish I had seen this first. It doesn't seem to be simply
media AA, almost like object interactions (reflection surfaces? anything).

-- 
Bob H.
http://www.3digitaleyes.com

[Rafal 'Raf256' Maj] pov 3.6 beta 3 bug - bright media - 2 attachments [8039 days 18 hours and 33 minutes ago]

Fri, 9 Apr 2004 17:31:19 GMT

See in p.beta-test and p.b.s-f

ifj_logo_a.v040.pov36beta3_win32.png - contains random bright-yellow pixels 
(different position each time You render same scene).

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

[Stefan Maierhofer] +L command line option ignored ? [8083 days 14 hours and 17 minutes ago]

Wed, 25 Feb 2004 21:46:48 GMT

see posting "+L command line option ignored?" in povray.beta-test ...

Stefan

[berni] Re: Light or Normal Problem [8085 days and 16 minutes ago]

Tue, 24 Feb 2004 11:47:59 GMT

> > Doesn't this make sense to you?
>
> No, you say you can install and run the linux version but don't have
> access to a linux machine to compile it...
>
> Apart from that POV-Ray 3.5 has been around for a long time now - do you
> expect that the POV-Team makes a bugfix release now that 3.6 is already
> in beta?  The 3.6 beta is quite stable (the normal problem is just a
> lack of backwards compatibility - not a real bug).  Although i can't
> speak for the Team the official statement most likely would be: use the
> beta or work around the problem by compiling your own version.

Sorry for answering your rhetorical question. I should have known that you
are not trying to help me.

Peace, Sorry for getting Off-Topic & Kudos to the makers of POV-Ray
Bernhard

[Christoph Hormann] Re: Light or Normal Problem [8085 days and 54 minutes ago]

Tue, 24 Feb 2004 11:10:05 GMT

berni wrote:
>>Let me see if i understand this right - you ask the POV-Team to compile
>>you a 3.5 version because you are not able to compile one yourself?
> 
> 
> Exactly. But this is a bug in 3.5 which is fixed in 3.6 (tty problem), so
> everyone downloading the 3.5 binaries from pov-ray who wants to use it in a
> script (CGI, webmin, Java, etc.) will experience this problem. So this would
> be more efficient - if 3.6 final is not ready anytime soon. Unfortunately
> compiling is not trivial for me (of course I can go and install linux
> somewhere or spend $$$ for my own server and go through the troubles of
> compiling sources - but my time and money resources are rather limited).
> 
> Doesn't this make sense to you?

No, you say you can install and run the linux version but don't have 
access to a linux machine to compile it...

Apart from that POV-Ray 3.5 has been around for a long time now - do you 
expect that the POV-Team makes a bugfix release now that 3.6 is already 
in beta?  The 3.6 beta is quite stable (the normal problem is just a 
lack of backwards compatibility - not a real bug).  Although i can't 
speak for the Team the official statement most likely would be: use the 
beta or work around the problem by compiling your own version.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

[berni] Re: Light or Normal Problem [8085 days 1 hour and 20 minutes ago]

Tue, 24 Feb 2004 10:44:42 GMT

> > It would be the best for me if the POV team would provide a Linux 3.5
binary
> > that works from a shell script or Java (i.e. a console version without
X).
> > By now I had no luck getting such a version :( And I think I am not the
only
> > one who would need one.
>
> Let me see if i understand this right - you ask the POV-Team to compile
> you a 3.5 version because you are not able to compile one yourself?

Exactly. But this is a bug in 3.5 which is fixed in 3.6 (tty problem), so
everyone downloading the 3.5 binaries from pov-ray who wants to use it in a
script (CGI, webmin, Java, etc.) will experience this problem. So this would
be more efficient - if 3.6 final is not ready anytime soon. Unfortunately
compiling is not trivial for me (of course I can go and install linux
somewhere or spend $$$ for my own server and go through the troubles of
compiling sources - but my time and money resources are rather limited).

Doesn't this make sense to you?

Regards
Bernhard

[Christoph Hormann] Re: Light or Normal Problem [8085 days 1 hour and 42 minutes ago]

Tue, 24 Feb 2004 10:22:04 GMT

berni wrote:
> Hi!
> 
> I think this is a known bug by now (I think the normal bug should be known
> by now).

What bug are you talking about?  There is a confirmed problem with some 
patterns looking different - the difference in your scene might be due 
to this - if you think there is an additional problem you should post a 
minimal scene that does *not* use any critical pattern.

> It would be the best for me if the POV team would provide a Linux 3.5 binary
> that works from a shell script or Java (i.e. a console version without X).
> By now I had no luck getting such a version :( And I think I am not the only
> one who would need one.

Let me see if i understand this right - you ask the POV-Team to compile 
you a 3.5 version because you are not able to compile one yourself?

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

[berni] Light or Normal Problem [8085 days 2 hours and 42 minutes ago]

Tue, 24 Feb 2004 09:22:04 GMT

Hi!

I think this is a known bug by now (I think the normal bug should be known
by now).
Actually I was just looking for a version of pov-ray I can run under a linux
shell script or from Java under Linux, but I got this tty problem (even with
the -D option). I CANNOT COMPILE MYSELF so I was looking for a replacement.
3.6 works from a Linux shell script, but the renders look quite different.

It would be the best for me if the POV team would provide a Linux 3.5 binary
that works from a shell script or Java (i.e. a console version without X).
By now I had no luck getting such a version :( And I think I am not the only
one who would need one.

Regards & HTH
Bernhard

[Daniel Fenner] seg fault in "pov::Determine_Apparent_Colour" [8086 days 19 hours and 3 minutes ago]

Sun, 22 Feb 2004 17:01:13 GMT

(there is an post in povray.beta-test with the same title and more details)

The archiv can simply be un-tar-ed with

tar -xzf test.tar.gz

and then

cd test
povray test.ini

will (hopefully) reproduce the problem.

[Michael Raiford] Changes to some patterns? [8103 days 10 hours and 2 minutes ago]

Fri, 6 Feb 2004 02:02:17 GMT

See post in p.bt

It appears waves is significantly different between the two versions of the
raytracer.

[Top: Rendered with v3.5, Bottom: Rendered with v3.6b1]

[Slime] Height Field Defects [8107 days 16 hours and 38 minutes ago]

Sun, 1 Feb 2004 19:26:31 GMT

Please see the corresponding post in povray.beta-test.

 - Slime
 [ http://www.slimeland.com/ ]

[Chris Cason] This group is being retired [8669 days 23 hours and 44 minutes ago]

Fri, 19 Jul 2002 12:19:58 GMT

This group is being retired (for the time being).

It will continue to exist - for reference purposes - but posting will not be
permitted.

-- Chris

[Warp] Re: Bug when viewing www.povray.org with Netscap... [8674 days 18 hours and 55 minutes ago]

Sun, 14 Jul 2002 17:09:09 GMT

Slime <slm### [at] slimelandcom> wrote:
> But if all you want is for a page to "work" in every browser, standards are
> the way to go. 

  If you use all the standards defined by the W3C, using the full capabitilites
they offer, you'll probably make a site which won't work in *any* browser
(because no current browser supports everything standardized by W3C).
  So it's not enough to just stick to the standard. You also have to know
which standards are widely implemented and supported, and which aren't.

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

[Slime] Re: Bug when viewing www.povray.org with Netscap... [8676 days 14 hours and 33 minutes ago]

Fri, 12 Jul 2002 21:31:31 GMT

> exactly why I am sticking to XHTML 1.0 strict from now on (and meeting
> triple A accessability standards :)

Wowee, that's impressive. I use XHTML 1.0 strict, but haven't even read the
specs for AAA standards =)

 - Slime
[ http://www.slimeland.com/ ]

[Rick [Kitty5]] Re: Bug when viewing www.povray.org with Netscap... [8676 days 18 hours and 17 minutes ago]

Fri, 12 Jul 2002 17:47:22 GMT

Slime wrote:
[snip...]

exactly why I am sticking to XHTML 1.0 strict from now on (and meeting
triple A accessability standards :)


--
Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.373 / Virus Database: 208 - Release Date: 03/07/2002

[Mark Wagner] Re: Bug when viewing www.povray.org with Netscap... [8677 days 5 hours and 53 minutes ago]

Fri, 12 Jul 2002 06:11:26 GMT

Warp wrote in message <3d2b6d06@news.povray.org>...
>  I think that the pov-team has quite little chances of fixing a bug
>in Netscape 4. Send the bug report to netscape.com instead.

I've duplicated it with Netscape 4.72 under IRIX.  It appears to be caused
by the fact that the "search" button is about twice as tall under the window
managers those OSs use as it is under Windows/MacOS/etc.

--
Mark

The Universe is expanding.
The budget for its exploration is shrinking.

[Slime] Re: Bug when viewing www.povray.org with Netscap... [8677 days 8 hours and 7 minutes ago]

Fri, 12 Jul 2002 03:57:09 GMT

> if your prepared to throw standards out the window and sometimes do
browser
> specific style sheets, you can get it looking 99% identical in all the top
> browsers (inc NC4.7)


To look identical, yes, you may have to do that.

But if all you want is for a page to "work" in every browser, standards are
the way to go. Take www.webstandards.org for instance. *Because* it uses
valid markup and CSS, its content is accessable in all browsers. Including
Mozilla, IE, NN4.x, Opera, Lynx, Palm Pilot browsers, screen readers, you
name it. A couple of browsers do have some CSS bugs that cause the menu to
be displayed off the screen (this is caused by the fact that the browser
meets the standard halfway; it would be better to ignore the CSS than to
interpret it incorrectly). But if you're going for 99% of the population to
be able to see your site, standards are what you want to use.

Of course, the page won't look identical in every browser. But what's more
important - the visual apperance of the page or the content on it? The site
will look *decent* in most browsers. In all browsers, the content will be
accessable.

Another benefit is that the site is more accessable to handicapped users,
such as someone using a screen reader or something of the sort.

 - Slime
[ http://www.slimeland.com/ ]

[Rick [Kitty5]] Re: Bug when viewing www.povray.org with Netscap... [8678 days 1 hour and 28 minutes ago]

Thu, 11 Jul 2002 10:35:54 GMT

Glen Berry wrote:
> At any rate, I would tend to agree that it is nearly impossible to
> make a classy-looking website that will render as planned in EVERY
> browser that a person might want to use.

if your prepared to throw standards out the window and sometimes do browser
specific style sheets, you can get it looking 99% identical in all the top
browsers (inc NC4.7)

older browser require you to develop specific versions (html 3.2 and below)
--
Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.373 / Virus Database: 208 - Release Date: 02/07/2002

[Tony[B]] Re: Bug when viewing www.povray.org with Netscap... [8678 days 13 hours and 19 minutes ago]

Wed, 10 Jul 2002 22:45:44 GMT

> I have given up supporting it ... no way am
> I spending hours hacking a site to bits just
> to get NS4.x to look perfect

Amen to that, brother...

[Glen Berry] Re: Bug when viewing www.povray.org with Netscap... [8678 days 13 hours and 19 minutes ago]

Wed, 10 Jul 2002 22:45:30 GMT

On Wed, 10 Jul 2002 16:51:25 +0100, "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:

>Warp wrote:
>>   I think that the pov-team has quite little chances of fixing a bug
>> in Netscape 4. Send the bug report to netscape.com instead.
>
>I have given up supporting it (all sites I do from now on will be xhtml
>based), I will check to ensure everything is fully functional, and perhaps
>tweak any style sheets to make the most of a bad situation but no way am I
>spending hours hacking a site to bits just to get NS4.x to look perfect

For what it's worth, Netscape 4.7 on the Windows OS renders the page
mentioned in this thread without a problem on my computer. Perhaps it
might even be some glitch in some graphics library or "toolkit"
peculiar to Solaris?

At any rate, I would tend to agree that it is nearly impossible to
make a classy-looking website that will render as planned in EVERY
browser that a person might want to use. At least this person could
view the POV-Ray website. I've seen a few websites that were totally
non-functional with certain mainstream browsers. There's no excuse for
something like that, but the POV site has nothing in common with a
site like that.

Later,
Glen

7no### [at] ezwvcom     (Remove the numeral "7")

[Rick [Kitty5]] Re: Bug when viewing www.povray.org with Netscap... [8678 days 20 hours and 4 minutes ago]

Wed, 10 Jul 2002 16:00:28 GMT

Warp wrote:
>   I think that the pov-team has quite little chances of fixing a bug
> in Netscape 4. Send the bug report to netscape.com instead.

I have given up supporting it (all sites I do from now on will be xhtml
based), I will check to ensure everything is fully functional, and perhaps
tweak any style sheets to make the most of a bad situation but no way am I
spending hours hacking a site to bits just to get NS4.x to look perfect


--
Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002

[Warp] Re: Bug when viewing www.povray.org with Netscap... [8679 days 12 hours and 55 minutes ago]

Tue, 9 Jul 2002 23:08:54 GMT

I think that the pov-team has quite little chances of fixing a bug
in Netscape 4. Send the bug report to netscape.com instead.

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

[Raphael Quinet] Bug when viewing www.povray.org with Netscape (S... [8679 days 18 hours and 52 minutes ago]

Tue, 9 Jul 2002 17:12:43 GMT

As reported in povray.general, all pages using the new
layout for www.povray.org appear to be broken in Netscape
running on Solaris.  They look fine in Mozilla, though.

The attached image is a screenshot showing the problem:
the circle and the text on the side of the page are broken.

Sorry if this is a bit off-topic for this group, but there
does not seem to be a more appropriate group for posting
that kind of binaries.

-Raphaël

[Christoph Hormann] Re: media scenes from linux version (for Thorsten) [8684 days 7 hours and 10 minutes ago]

Fri, 5 Jul 2002 04:54:22 GMT

Thorsten Froehlich wrote:
> 
> Thanks a lot.  I think I have identified the problem and it should be fixed
> in the next beta.
> 

Great, does it also fix the problems reported in:

Subject: More problems with sample scenes in linux RC6
Date: Thu, 20 Jun 2002 22:38:44 +0200
From: Christoph Hormann <chr### [at] gmxde>
Newsgroups: povray.beta-test
news://news.povray.org/3D123D54.5A360ACD@gmx.de


Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

[Thorsten Froehlich] Re: media scenes from linux version (for Thorsten) [8684 days 14 hours and 50 minutes ago]

Thu, 4 Jul 2002 21:14:32 GMT

Thanks a lot.  I think I have identified the problem and it should be fixed
in the next beta.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

[Christoph Hormann] media scenes from linux version (for Thorsten) [8684 days 16 hours and 48 minutes ago]

Thu, 4 Jul 2002 19:15:52 GMT

Voila.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 30 Jun. 2002 _____./\/^>_*_<^\/\.______

[Philippe Debar] Grid artifact in f_noise3d isosurface [8696 days 1 hour and 25 minutes ago]

Sun, 23 Jun 2002 10:38:53 GMT

Small animation that renders the following scenes :
0) the simple f_noise3d on a plane
1) the "differenced" (there must be a proper name for this...) f_noise3d on
a plane
2) same with noise gen 1
3) same with noise gen 2
4) the "differenced", noise_gen 3, f_noise3d on a sphere
5) the pure f_noise3d on a sphere

See
news:3d14a873@news.povray.org /
http://news.povray.org/povray.advanced-users/25150/
and / or
http://web.wanadoo.be/wbrp0009/pov/qbugs/noisegrid/main.html
for more info.



Povingly,

Philippe

[Kynar] Sky-Sphere and Media CSG problems [8719 days 12 hours and 25 minutes ago]

Thu, 30 May 2002 23:39:27 GMT

Source Code:

// Persistence of Vision Ray Tracer Scene Description File
// File: .pov
// Vers: 3.5
// Desc:
// Date:
// Auth:


// place all settings of globally influenced features here
global_settings {
  ambient_light rgb 0
}

sky_sphere {
  pigment {
    gradient y
    color_map { [0.0 color rgb .85] [1.0 color blue 0.95] }
  }
}

camera {
  location  <0, 0, -5>
  look_at   <0, 0,  0>
  right     4/3*x  // aspect
}


#declare MediaFactor = 0.00125;
#declare InnerRadius=1;
#declare OuterRadius=InnerRadius+2;

#declare OuterTexture=texture {
  pigment {
    color rgb 0
  }
  finish {
    ambient 0
    diffuse 0.09
    reflection 0.04
  }
}

#declare InnerTexture=texture {
  pigment {
    color rgb 1
  }
  finish {
    ambient 0
    diffuse 0.78
    reflection 0.22
  }
}

light_source {   0*x       color rgb <1,1,1>*2     translate <0, 40, -40>  }

#declare Source =     light_source {
  0
  color rgb <1,1,1>*10
  cylinder
  radius degrees(atan2(InnerRadius,OuterRadius)*1.25)
  falloff degrees(atan2(InnerRadius,OuterRadius)*1.25)
  tightness 100
  point_at -1*x
}

difference {
  union {
    light_source{Source}
    cylinder {
      -x,  0*x, 1.1
      pigment {color rgb <0.5,0.5,1>}
    }
    sphere {
      0, 1.1
      pigment {color rgb <0.5,1,0.5>}
    }
  }
  sphere {
    0, 1.1
    pigment {color rgb 1}
  }
  cylinder {
    -2*x,0.25*x,.5
    pigment {color rgb <1,0.5,0.5>}
  }
  rotate -40*y
}

sphere {
  0,100
  material {
    texture {
      pigment {rgbf 1}
    }
    interior {
      ior 1
      media {
       scattering {
          1, //1-5
          color rgb 1*MediaFactor
        }
      }
    }
  }
  hollow
}

[Slime] Smooth mesh2 artifacts - 2 small images [8721 days 8 hours and 42 minutes ago]

Wed, 29 May 2002 03:22:08 GMT

See "smooth mesh2 artifacts" in p.b-t.

The first picture is an example of the artifact the way we've all seen it
(black pixels at the edge of bumps). The second picture is a single triangle
displaying the artifact. (Order of pictures may be reversed.)

 - Slime
[ http://www.slimeland.com/ ]

[Kynar] Photons - light sources [8722 days and 7 minutes ago]

Tue, 28 May 2002 11:57:03 GMT

Here are the source and image files for post in beta-test area.

Kynar

[bob h] Re: mirrors reflect shadows test scene [8722 days 3 hours and 13 minutes ago]

Tue, 28 May 2002 08:51:39 GMT

Yes. Makes sense. I was fairly sure I could try that myself and by using
light_group confine the reflected shadow to one place or another. Now I see
it doesn't, not that I can find. Explanation so far seems to be that
mirrored objects ignore light_groups.

bob h

[Bruno Gimeno] Re: mirrors reflect shadows test scene [8722 days 14 hours and 47 minutes ago]

Mon, 27 May 2002 21:17:32 GMT

"bob h" <omn### [at] charternet> escribió en el mensaje
news:3cf1ea60@news.povray.org...
> "Rune" <run### [at] mobilixnetdk> wrote in message
> news:3cf0af4f$1@news.povray.org...
> >

my idea was to make something similar to this, whitout using a paint program
http://usuarios.lycos.es/game2413/galeria/untitled5.jpg
(i think it's impossible)

i think that is a failure desing (someone says that is better and easy
with a paint program), read opinions here:
http://news.povray.org/povray.general/24666/173330/#173330

well, if l'harmonieux forgeron have the reason, i should accept that
invisible objects still cast shadows

Bruno Gimeno
solo tendreis mi ordenador
cuando me arranqueis el teclado
de mis frios dedos muertos

[bob h] Re: mirrors reflect shadows test scene [8723 days 3 hours and 52 minutes ago]

Mon, 27 May 2002 08:12:16 GMT

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3cf0af4f$1@news.povray.org...
>
> Of course I may have misunderstood what Bruno is trying, but if he
> wanted to remove the shadow in the mirror of the red sphere without
> removing the shadow of the red sphere itself, I don't know how that's
> possible using just those object modifiers.

Isn't, I suppose. Just groping in the dark for a solution. I realized the
non-reflected shadow was probably a neccessity but that wasn't mentioned, so
I went ahead and tossed no_shadow into the mix.
 Seems one of those feats requiring some wizardry.  For example a
light_group, already mentioned by someone else I think, involving a second
sphere to cast the false shadow to replace the missing one. Trying that out
just now I didn't get it right, the mirror (and floor) shows the reflected
shadow even though it isn't a part of the group. At least that could
possibly be a bug, if I'm doing this like it should be.

So, if someone cares to double check on this here's what I was using to
attempt Bruno's desired result:


/* Idea: red sphere should have no shadow.
   Sphere should have a shadow on floor
   but not a shadow in mirror.
*/

#version 3.5;

camera {
  location  <2, 2, -4>
  look_at   <1, 0, 1>
  angle 50
}

// original object
light_group {

light_source {
  <-10, 10, -5>, 1.5
}

sphere { // this is removed from mirror
  0, 1
    pigment {
        color red 1
            }
 // no_image
  no_reflection
  no_shadow
}

plane { // floor here, in other group, anywhere... no matter(?)
  y, -1
  pigment { checker rgb 1/3, rgb 2/3 }
}

 global_lights off
}

// fake shadow... still shows up in mirror
light_group {

light_source {
  <-10, 10, -5>, 1.5
}

sphere { // replacment object
  0, 1
    pigment {
        color green 1
            }
  no_image
 // no_reflection
 // no_shadow
}

 global_lights off
}

// global lighting/objects
light_source {
  <-10, 10, -5>, 1.5
}

plane { // mirror... tied only to this light?
  z, 2
  pigment { color rgb .5 }
  finish {
  reflection {<1,1,0>}
  }
}

[Mike Hough] RC5 and MegaPOV 0.7 - "optics.pov" [8723 days 8 hours and 11 minutes ago]

Mon, 27 May 2002 03:53:44 GMT

See p.b-t for render times.  First image is from RC5, the second from Mega
0.7.

[Bruno Gimeno] mirrors [8724 days and 14 minutes ago]

Sun, 26 May 2002 11:50:05 GMT

rewrited, and reposted in povray.general
http://news.povray.org/povray.general/24666/173330/#173330

sorry for inconveniences

Bruno Gimeno
solo tendreis mi ordenador
cuando me arranqueis el teclado
de mis frios dedos muertos

[Rune] Re: mirrors should not reflect shadows [8724 days 2 hours and 16 minutes ago]

Sun, 26 May 2002 09:47:59 GMT

bob h wrote:
> Add no_shadow to the red sphere.

Err, that would also remove the shadow from the red sphere itself, not
just the reflection of the shadow of the red sphere...

> The three things that seem related here of course are:
> no_image, no_reflection and no_shadow. Any combination
> of those "object modifiers" can be used to get what you
> seem to have been trying.

I don't see how...?

Of course I may have misunderstood what Bruno is trying, but if he
wanted to remove the shadow in the mirror of the red sphere without
removing the shadow of the red sphere itself, I don't know how that's
possible using just those object modifiers.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

[bob h] Re: mirrors should not reflect shadows [8724 days 5 hours and 19 minutes ago]

Sun, 26 May 2002 06:45:42 GMT

If I may, I believe the usual method is to post text about questionable
behavior of 3.5 beta in the povray.beta-test group and then also place any
relevant binary files here in this group, directing to (telling of) each of
those postings. However, in this case you could ask such a thing in
povray.general. And yet, if you have strong suspicions it is a "bug" then by
all means posting to povray.beta-test first and foremost is probably
perfectly acceptable.

Well enough chatter, back to the topic of discussion. :-)

Add no_shadow to the red sphere. I do not know for certain if this was ever
done differently before, i.e. the shadow disappearing along with the
reflection. The three things that seem related here of course are: no_image,
no_reflection and no_shadow. Any combination of those "object modifiers" can
be used to get what you seem to have been trying.

Hope this has been some help.

bob h

[Bruno Gimeno] Re: mirrors should not reflect shadows [8724 days 12 hours and 26 minutes ago]

Sat, 25 May 2002 23:38:18 GMT

> Well, I find it quite obvious that he would like to know a way to avoid
> the shadow of the red ball to show up in the mirror, since the red ball
> itself is not shown in the mirror due to no_reflection.
>
> I don't know if it's an appropriate post in this group though.
>
> Rune
>

In first place, my but humble excuses for sending an incomplete message.
I'm sorry, but it must have sent in a moment in which the hurries had not
urgeed me so much.

Yes, Rune, the problem that I want to indicate is about avoiding the shadow
of an object
reflected "within the mirror"; and analogous avoiding that the shade of an
object marked
with "no_image" shows itself  "outside the mirror".

It is not the appropiate group to ask this subject?
I Though that would be the most suitable, treating about a new function of
Pov-ray 3,5,
that in my opinion, presents a design failure.  or not?

Thanks beforehand to listen to me and please,
understand that I translate this message using several translators online,
my level of english does not allow me to write with the sufficient clarity



En primer lugar, mis mas humildes excusas por enviar un mensaje incompleto.
lo siento, pero debiera haberlo enviado en un momento en el que las prisas
no me hubieran acuciado tanto.

Si, Rune, el problema que quiero señalar es a la hora de evitar que se
muestre
la sombra de un objeto reflejado "dentro del espejo" y analogamente, el
evitar
que la sombra de un objeto marcado con "no_image" se muestre "fuera del
espejo".

¿No es este el grupo adecuado para preguntar este tema?
Crei que sería el más adecuado, tratándose de una nueva función de
POV-RAY
3.5, que a
mi juicio, presenta un fallo de diseño. ¿o no?

Gracias de antemano por escucharme y por favor, comprended
que traduzco este mensaje usando varios traductores on-line, mi nivel de
ingles no me permite escribir con la suficiente claridad


-- Bruno Gimeno --------------------
-- solo tendreis mi ordenador -------
-- cuando me arranqueis el teclado --
-- de mis frios dedos muertos -------

[Rune] Re: mirrors should not reflect shadows [8724 days 22 hours and 26 minutes ago]

Sat, 25 May 2002 13:38:15 GMT

Warp wrote:
>   Thanks for not giving any details about what you
> want to achieve and what's the image about. This
> really helps us giving you the answer you want.

Well, I find it quite obvious that he would like to know a way to avoid
the shadow of the red ball to show up in the mirror, since the red ball
itself is not shown in the mirror due to no_reflection.

I don't know if it's an appropriate post in this group though.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

[Warp] Re: mirrors should not reflect shadows [8725 days and 43 minutes ago]

Sat, 25 May 2002 11:20:54 GMT

Bruno Gimeno <apl### [at] spambillg8jazzfreecom> wrote:
> solutions?

  Thanks for not giving any details about what you want to achieve and
what's the image about. This really helps us giving you the answer you want.

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

[Bruno Gimeno] mirrors should not reflect shadows [8725 days 6 hours and 34 minutes ago]

Sat, 25 May 2002 05:30:30 GMT

solutions?


larger image at:
http://usuarios.lycos.es/game2413/galeria/Untitled800x600.jpg

Bruno Gimeno
 -- solo tendreis mi ordenador --
-- cuando me arranqueis el teclado --
   -- de mis frios dedos muertos --

[Warp] Re: Too many nested variables [8732 days 13 hours and 42 minutes ago]

Fri, 17 May 2002 22:22:40 GMT

Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> Can you give me a brief example of

> "iterations" without "nesting", especially where I could control the # of
> levels with a variable?

  Ever heard of #while-loops?

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

[Lutz-Peter Hooge] Re: Too many nested variables - test3.pov [1/1] [8732 days 17 hours and 59 minutes ago]

Fri, 17 May 2002 18:05:30 GMT

In article <aaaaeugdt980scno5nu0sv1l288qv4653a@4ax.com>, abx### [at] babilonorg 
says...

> Usually recursion/nesting can be replaced with iterations so you can still
> try...

And also a recursion depth of 97 should be enough for everybody ;-)

Really, what he wanted to do should be perfectly possible with a 
recursive macro.

I attached a modifikation of Greg's source that roughly does what I think 
he wanted it to do. But it does use only simple spheres instead of blobs 
components, because blobs can't be nested inside other blobs (but unions 
of spheres can). 

Lutz-Peter

[Greg M Johnson] Re: Too many nested variables [8732 days 18 hours and 49 minutes ago]

Fri, 17 May 2002 17:15:27 GMT

Can you give me a brief example of

"iterations" without "nesting", especially where I could control the # of
levels with a variable?

[] Re: Too many nested variables [8732 days 20 hours ago]

Fri, 17 May 2002 16:04:39 GMT

On Fri, 17 May 2002 09:58:51 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> ii) disappoint me in this extreme limitation of povray.

That's not specific limitation of POV-Ray. Most of languages limits nesting.
Usually recursion/nesting can be replaced with iterations so you can still
try...

ABX

[Greg M Johnson] Re: Too many nested variables [8732 days 22 hours and 4 minutes ago]

Fri, 17 May 2002 14:00:01 GMT

Thanks for the attempts at explanations, but they either
i) go way over my head
or
ii) disappoint me in this extreme limitation of povray.

[Lutz-Peter Hooge] Re: Too many nested variables [8732 days 22 hours and 46 minutes ago]

Fri, 17 May 2002 13:17:52 GMT

In article <3ce4f95f$1@news.povray.org>, "Greg M. Johnson" <gregj:-
)565### [at] aolcom> says...

> The purpose of the code was to make a fractal blob.  I now see how my code
> doesn't do this properly, BUT I'm bothered that I either cannot have nested
> macros or redefine them!

I think the problem is that macros doesn't work the way as you think they 
do. In fact your first declaration of set1() never gets called.

What you assume is: set1() is immediately replaced by the content of the 
last definiton of that macro.
But: In fact this is only done later, when the macro containing the call 
to set1() is called... but at this time you already redefined set1()

This means: your scene is equivalent to

#macro set2()	set1() #end
#macro set1() set2() #end
set1()

-> infinite recursion.

Lutz-Peter

[] Re: Too many nested variables [8732 days 23 hours and 14 minutes ago]

Fri, 17 May 2002 12:50:16 GMT

On Fri, 17 May 2002 08:35:37 -0400, "Greg M. Johnson" <gregj:-)565### [at] aolcom>
wrote:
> The purpose of the code was to make a fractal blob.  I now see how my code
> doesn't do this properly, BUT I'm bothered that I either cannot have nested
> macros or redefine them!

You can have nested macros. Just do it properlny. Note that parser stoped not
during declaration of nested macros but during execution. It hit limit of
nested. Note that creation of macros in loop has no sense becouse in every
loop definiton of macros is not executed.

ABX

[Greg M Johnson] Too many nested variables [8732 days 23 hours and 27 minutes ago]

Fri, 17 May 2002 12:36:47 GMT

The attached file gives a "too many nested variables error."
I posted an incomplete snippet of the code to p.b-t..
Have I hit a fundamental, theoretical limit to macros, or have I simply
buggy code?

The purpose of the code was to make a fractal blob.  I now see how my code
doesn't do this properly, BUT I'm bothered that I either cannot have nested
macros or redefine them!

[Gleb] Catmull-Rom spline bounded by its Bezier control... [8739 days 15 hours and 36 minutes ago]

Fri, 10 May 2002 20:28:37 GMT

This is a code and example image for subj.
It seems that it is necessary to take into account
not only the radius at particular control point,
but radii of its neighbours too.

Can anyone test this code?

Calculations are simple and I hope
it is not difficult to rewrite this code in C
in case it will be found useful.

Any comments?

Gleb

[] Re: RC4 quick summary of my reports - catmull-ro... [8740 days 1 hour and 43 minutes ago]

Fri, 10 May 2002 10:21:14 GMT

On Fri, 10 May 2002 01:36:17 +0200, Tor Olav Kristensen
<tor### [at] hotmailcom> wrote:
> Just differentiate these (to quadratic polynomials) and
> solve for zero to find the max and min points of the
> cubic polynomials. The values of the cubic polynomials
> at these points will give the components for the
> bounding box.

Sounds reasonably and attachement shows it is easy possible (considering I
used proper equation for catmull-rom spline). Of course equations could be
simpler internally becouse it is just solution of quadratic polynomial.
Solution represents t value where p has extremas. When t is outside [0,1]
range then take p1 or p2 otherwise calculate p(t). Add Proper radius to
calculated value. I have no easy access to the C compiler for prepare
corrected MegaPOV function but perhaps somebody could hardcode this.

ABX

[Rune] Catmul-rom spline bounding [8740 days 13 hours and 29 minutes ago]

Thu, 9 May 2002 22:35:15 GMT

The attached file demonstrates how a reasonable close but not too tight
bounding of a catmul-rom spline can be found. It does not take into
account the radius, but that should be very simple to add support for.

Please let me know if this is of any use, or if I have completely
misunderstood what the problem is all about.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

[Tony[B]] Re: Vanish/Ghost/Killer bug [8764 days 8 hours and 3 minutes ago]

Tue, 16 Apr 2002 04:00:48 GMT

>   The best solution is, of course, that POV-Ray would issue an error if
> a 0-vector is normalized (because it can't). Getting a clear error message
> is always better than getting a weird result.

I most definitely agree.

[Warp] Re: Vanish/Ghost/Killer bug [8764 days 10 hours and 4 minutes ago]

Tue, 16 Apr 2002 01:59:55 GMT

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
>   Oh... well, if you use vstr() with vnormalize(<0,0,0>), you will se it 
> returns a vector <nan,nan,nan>. If you look also at the docs, the 
> description for vnormalize() "criptically" states that "vnormalize(<0,0,0>) 
> will not give a usefull result". This sounds more like an undesired side 
> effect than a bug... and from the docs wording I can supose there is no 
> easy solution for the problem. Note this sentence was not on the 3.1 docs, 
> so I suspect it was discussed on a previous bug report...

  This is a case where there's no simple solution, even though it could
look like that at first glance.

  Some people think that vnormalize(<0,0,0>) should return <0,0,0>.
That's *not* a good solution because it breaks the very definition of
vnormalize. vnormalize is defined to always return a vector of lenght 1,
which <0,0,0> is not. If you trust that it always returns a vector of
that length but there's a special case where it doesn't, then you can't
trust it anymore.

  The best solution is, of course, that POV-Ray would issue an error if
a 0-vector is normalized (because it can't). Getting a clear error message
is always better than getting a weird result.

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

[Jaime Vives Piqueres] Re: Vanish/Ghost/Killer bug [8764 days 16 hours and 41 minutes ago]

Mon, 15 Apr 2002 19:23:10 GMT

Tim Nikias wrote:

> This is the minimum scene-file Thorsten Froehlich requested to
> check the bug. When tracing with focal-blur, objects get
> cut in half or vanish, depending on which object you use
> to be translated by vnormalize(<0,0,0>).

  Oh... well, if you use vstr() with vnormalize(<0,0,0>), you will se it 
returns a vector <nan,nan,nan>. If you look also at the docs, the 
description for vnormalize() "criptically" states that "vnormalize(<0,0,0>) 
will not give a usefull result". This sounds more like an undesired side 
effect than a bug... and from the docs wording I can supose there is no 
easy solution for the problem. Note this sentence was not on the 3.1 docs, 
so I suspect it was discussed on a previous bug report...

  Anyhow, if your using vnormalize inside loops, you can test for the 
"special case" to replace it with the apropiate value (if it makes sense at 
all).

  Hope this helps! 

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

[Tim Nikias] Vanish/Ghost/Killer bug [8764 days 17 hours and 20 minutes ago]

Mon, 15 Apr 2002 18:44:26 GMT

This is the minimum scene-file Thorsten Froehlich requested to
check the bug. When tracing with focal-blur, objects get
cut in half or vanish, depending on which object you use
to be translated by vnormalize(<0,0,0>).

Interesting side-effect:
The "cut" is "blurred focally", or at least it appears so.

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

[Tim Nikias] Focal-Blur + Translate [8771 days 14 hours and 46 minutes ago]

Mon, 8 Apr 2002 21:18:09 GMT

See thread "Vanishing-Objects Focal Blur: Prblem Line found" in
beta-test, posted on 8.4.02


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

[Henry Bush] material map bug [8773 days 23 hours and 44 minutes ago]

Sat, 6 Apr 2002 12:20:46 GMT

Ripped straight from the scene file...

// This scene contains a box with a material map on it (80x80x16 colours)

// Two bugs actually: when this scene is rendered several times, I get 
(seemingly random) different colours for the
// space outside the circle (which is palette index 15 and not specified 
in the map), and therefore the other two
// visible sides of the box. I've had black and yellow mostly (indices 0 
and 2-15), but also red occasionally (index 1).
// But I've not got red for quite some time (traced it probs about 100 
times as well, so it's not a 1/16 chance!).


// NOTE: This next bit is not a bug. Just checked the docs. The insert 
material_map states interpolate type 1
// can be used for linear interpolation. Can this be changed?

// (IGNORE) The other bug is that When I use linear interpolation on the 
material_map, I get a black (index 0) box: no image at
// all. This isn't affected by map type. I discover now that it occurs 
with image_maps too. Someone must have found
// this bug before, right? (/IGNORE)



// I've tested this bug with both a BMP and a PNG and the bug still 
occurs in each case.
// Bug has been tested on my system in 3.1g, same thing happens.

// I think I've removed all that I can, including lights. All done with 
ambient.


// POV 3.5 Build 15, Athlon 650 o/c to 682, 512Mb RAM, Windows XP Pro.

[] Re: Known bugs 1 Apr 2002 (beta15) and request [8777 days 22 hours ago]

Tue, 2 Apr 2002 14:04:10 GMT

On Tue, 02 Apr 2002 15:32:03 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> >> * Prism transformation problem
> >>   (Conic prism illumination is not correct after certain rotations. Bug
> >>   status unclear.)
> >
> > Note I have repeated this behaviour with matrix also (coded rotation)
> > http://news.povray.org/d1oh6u821648rvs7frgmt4cl7u41s6cmmo%404ax.com
> >
> >>   (Note: It has been reported that this bug would not happen in POV-Ray 3.1.
> >>     This needs verification.)
> >
> > What about recompilation of 3.1 with the same compiler and settings as current
> > betas to verify compiler issues ?
>
> So you have tried it in 3.1 and it doesn't appear?

No, I haven't. I wrote above becouse somebody said he can reproduce this with
3.5 but can't reproduce with 3.1 on the same machine.

> If it doesn't happen in
> 3.1, could you post an image of the result in 3.5, please?

Again, animation along frame_number best shows appearance, Specification as
usual: POV 3.5 b 15 icl on WinNT Sp 6 PII 233 with 128 MB

ABX

[] Re: Known bugs 1 Apr 2002 (beta15) and request [8777 days 22 hours and 11 minutes ago]

Tue, 2 Apr 2002 13:53:31 GMT

On Tue, 02 Apr 2002 15:32:03 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > >* Media problem
> > >  (A visible whitish line appears at the edge of a transparent container
> > >  box for media. Needs confirmation.)
> > >  Reported in:
> > > Media visible container line in front of object
> > > http://news.povray.org/3bf45a3d@news.povray.org
> >
> > I can confirm appearance of bright line. I have changed camera location in
> > example to location <1+clock, 1.7, -5> and started animation.
> > I have rendered with +FN with standard settings 800x600, AA 0.3.
>
> I tried it and at least don't see anything unexpected.  Could you post an
> image, please?

I don't know it is expected or unexpected behaviour. Only thing I know I can
reproduce bright line described in original report. Here are three images with
original script and complete output stream. Specification as usual:
POV 3.5 b 15 icl on WinNT Sp 6 PII 233 with 128 MB

ABX

[Tim Nikias] Disappearing objects with focal blur (see beta-t... [8778 days 19 hours and 2 minutes ago]

Mon, 1 Apr 2002 17:02:14 GMT

Just the Zip will all needed files...


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

[Christopher James Huff] Re: New feature in POV3.5 [8784 days 14 hours and 49 minutes ago]

Tue, 26 Mar 2002 21:15:42 GMT

In article <3CA0D6E7.ED26AC21@web.de>, Birol Acikgoez <bi.### [at] webde> 
wrote:

> Is there a possibility to add in POV3.5 a new feature, like blurred glas
> in the refraction or ior funktion, as the same with the blurred
> reflections?

First, this is the wrong place for this kind of post. This group 
(povray.beta-test.binaries) is for binary posts relating to bug reports 
in povray.beta-test about the POV-Ray 3.5 beta.
Second, the POV-Team is no longer taking any feature requests for 3.5. 
It is fairly late along in the beta portion of its cycle, the time for 
feature additions is long past.

And finally, you can already do blurred reflection and refraction. Just 
make an averaged texture of several similar textures with the only 
differences being the normals. It is also more flexible, you can use 
this technique to similate different shapes of microscopic bumps and 
grooves. There have been many, many threads and long discussions on this 
subject, I suggest you read the more recent threads here:
http://news.povray.org/search/advanced/?s=blur&b=Search&g=povray.binaries
.images&a=0&p=0

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

[Birol Acikgoez] New feature in POV3.5 [8784 days 15 hours and 50 minutes ago]

Tue, 26 Mar 2002 20:14:20 GMT

Hello dear Povray programmers!

Is there a possibility to add in POV3.5 a new feature, like blurred glas
in the refraction or ior funktion, as the same with the blurred
reflections?

Thanks and regards !

[] Re: Stattering Message Window [8786 days 2 hours and 26 minutes ago]

Mon, 25 Mar 2002 09:38:02 GMT

On Mon, 25 Mar 2002 10:35:18 +0100, W³odzimierz ABX Skiba <abx### [at] babilonorg> 
> Ok. Freash installation on POV 3.5 b 14 icl on WinNT Sp 6 PII 233 with 128 MB.
> Just +FN switch added. All switches are listed on screenshots. Scene file on
> screenshot and as attachement after moment in p.b-t.binaries.

ABX

[Gleb] doc4_2_2.zip [8787 days 10 hours and 33 minutes ago]

Sun, 24 Mar 2002 01:31:42 GMT

Second attempt example to hilight code in docs

[] Re: Stattering Message Window [8789 days 20 hours and 17 minutes ago]

Thu, 21 Mar 2002 15:47:39 GMT

On Thu, 21 Mar 2002 16:45:27 +0100, W³odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:
> I've found this behaviour on 3.5 b 13 icl on WinNT Sp 6 PII 233 with 128 MB.
> It isn't animation. Two images after moment in p.b-t.binaries:
> pane.png shows what appear in message pane and window.png shows what is
> displayed after jump to message window. So, should this be considered normal ?

ABX

[] Re: [std includes] bug in old shape [8790 days 21 hours and 14 minutes ago]

Wed, 20 Mar 2002 14:50:20 GMT

On Wed, 20 Mar 2002 15:47:51 +0100, W³odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:

> I never heard about this bug so I report it. Remembering discusion about
> changes in chess.pov I don't know how you want to treat this report: as
> historical mistake not worth to change, important imformation or known fact.
> [...]
> Images after moment in p.b-t.binaries.

As was promised.

ABX

[Tor Olav Kristensen] Function that will "crash" POV [8792 days 11 hours and 15 minutes ago]

Tue, 19 Mar 2002 00:48:47 GMT

Error message from POV-Ray v3.5 Beta 12:

"The POV-Ray core rendering code caused an access violation exception." 
Windows 2000 Version 5.0 (Build 2195: Service Pack 1) 
(POV-Ray "survived" and seemed to be fully functional afterwards.)

See files within enclosed zip-file for test set-up.

A similar function also crashed Beta 13 severely on
my Win-98 home PC, but I don't have the details at
hand right now.


Tor Olav

[Abe] media attenuation/media_interaction pics [8803 days 11 hours and 49 minutes ago]

Fri, 8 Mar 2002 00:14:48 GMT

The following shows the behavior of a light_source with
media_interaction off illuminating a transparent sphere containing
absorption media as described in povray.beta-test. Rendered in POV 3.1,
MegaPOV 0.7 and POV 3.5 beta 12. 

Abe

[Sebastian H ] (linux beta) adding rotation to camera [8804 days 22 hours and 56 minutes ago]

Wed, 6 Mar 2002 13:07:48 GMT

(using linux beta 12)

When adding rotation to camera statement the whole image gets the 
background color -> totally black/white whatever.

-> works
camera {
   location <0, 2, -5>*1
   look_at <0, 0.5, 0>*1
   //rotate 0*y
}

-> does not works
camera {
   location <0, 2, -5>*1
   look_at <0, 0.5, 0>*1
   rotate 0*y
}

(even with greater rotation values)


With a mesh2 (~400 Polys) scene slows down a LOT!

(These effects weren't there when using beta 11)

Sebastian H.

[] [std include] wrong kerning illustration [8812 days 3 hours and 19 minutes ago]

Wed, 27 Feb 2002 08:45:39 GMT

Image compares kerning of CircleText () macro, text{} object and my kerning()
macro posted some time ago in
http://news.povray.org/sa6q6u8ic6tt2ntql1kt4mm2fiebtf1pih%404ax.com
Note placing dots, commas and hidden "e" under "x" in "Text" word.
I suggest to use my method becouse it considers kerning with the same letters
as in original text instead of sometimes not defined "|". It also considers
kerning with pairs (and large sets) of chars. Any comments ?

Here is source to obtain attached image:

#local String="A,B.C,D,G... - ";
#local Font="Adks____.ttf";
#include "shapes.inc"
#include "kerning.inc" // macros posted some times ago to p.t.scene-files
union{
  object{
    Circle_Text(Font,concat(String,"CircleText()"),1,0,0,4,0,Align_Center,0)
    rotate z*90
  }
  text{ttf Font,concat(String,"text in POV"),0,0 translate <-5,1,0>}
  object{
    text_ttf(Font,concat(String,"kerning() by ABX"),0,0)
    translate <-5,-1,0>
  }
  translate z*10
  pigment{rgb 1}
}
light_source{-100*z 1}

ABX

[William Fex] Help!! color_map Puzzle!!!! [8812 days 10 hours and 53 minutes ago]

Wed, 27 Feb 2002 01:10:49 GMT

Can someone explaine to me the huge difference with this pov when rendered
in 3.1 vs 3.5...I just dont get it...
I understand part of the problem is the change in the way normals are
handled, and I believe I can fix this by simply lowering the value of my
normals, but the part that really has me puzzled is the way the color map
has been displaced.  Could someone please explain the difference that is
causing it and how I can adjust for it with precision rather than inching it
around over a million renders to find the proper values...there has to be a
direct relation but I cannot find it!  Also, could someone explain the new
changes in Normals so that I can adjust my renderings appropriately.

camera{location<0,0,-250>
look_at<0,0,0>}
light_source{<0,0,-4000>color rgb<1,1,1>*1.25}

union{
object{sphere{<0,0,0>,100}texture{pigment{marble
color_map{
[0 color rgb<.35*1.35,.12*1.3,.05*2.75>]
[.05 color rgb<.4*1.35,.12*1.3,.05*3>]
[.075 color rgb<.35*1.35,.12*1.3,.05*2.75>]
[.1 color rgb<.45*1.35,.12*1.3,.05*3>]
[.17 color rgb<.35*1.35,.12*1.3,.05*2.75>]
[.225 color rgb<.45*1.35,.12*1.3,.05*3>]
[.2675 color  rgb<.875,.675,.5*1.1>]
[.325 color  rgb<.875,.675,.5*1.1>]
[.375 color rgb<.35*1.35,.12*1.3,.05>]
[.44 color rgb<.45*1.35,.22*1.3,.05*3>]
[.475 color rgb<.35*1.35,.12*1.3,.05*2.75>]
[.525 color rgb<.875,.675,.5*1.1>]
[.65 color rgb<.5*1.35,.2*1.3,.05*3>]
[.725 color rgb<.35*1.35,.12*1.3,.05*2.75>]
[.76 color rgb<.5*1.35,.2*1.3,.05*3>]
[.775 color rgb<.35*1.35,.12*1.3,.05>]
[.78 color rgb<.5*1.35,.22*1.3,.05*3>]
[.79 color rgb<.35*1.35,.12*1.3,.05>]
[.82 color rgb<.5*1.35,.22*1.3,.05*3>]
[.835 color rgb<.875,.675,.5*1.1>]
[.87 color rgb<.5*1.35,.22*1.3,.05*3>]
[.875 color rgb<.4*1.35,.12*1.3,.05*3>]
[.89 color rgb<.5*1.35,.2*1.3,.05*3>]
[.925 color rgb<.45*1.35,.12*1.3,.05*3>]
[.95 color rgb<.6*1.35,.2*1.3,.05*3>]
[.9575 color rgb<.45*1.35,.12*1.3,.05*3>]
[.97 color rgb<.6*1.35,.2*1.3,.05*3>]
[.975 color rgb<.45*1.35,.12*1.3,.05*3>]
[.9875 color rgb<.6*1.35,.12*1.3,.05*3>]
[.99 color rgb<.45*1.35,.12*1.3,.05*3>]
[1 color rgb<.5*1.35,.2*1.3,.05*3>]
}
rotate<0,0,-90>scale <800,350,800>translate<0,87.5,0>translate<clock*1,0,0>
turbulence <.07,1,.09>lambda 11 omega .3 octaves 256
 rotate<19.5,0,0>
warp{black_hole<0,0,-120>,47 turbulence 5 strength 15 falloff 16 }
warp{black_hole<0,0,-120>,47 turbulence 5 strength 4.25 falloff 2.45
inverse}
rotate<-19.5,0,0>
turbulence <.105,0,.1>
}

normal{marble -60 rotate<0,0,-90> scale <800,350,800>turbulence
<.07,1,.09>lambda 11 omega .2125 octaves 24
rotate<0,45+(clock*3),0>translate<0,87.5,0>translate<clock*8,0,0>
rotate<19.5,0,0>
warp{black_hole<0,0,-120>,47 turbulence 5 strength 15 falloff 16 }
warp{black_hole<0,0,-120>,47 turbulence 5 strength 4.25 falloff 2.45
inverse}
rotate<-19.5,0,0>}}rotate<0,55-(clock*.5),0>}
object{sphere{<0,0,0>,100.75}texture{pigment{rgbt<.8,.75,.8,.95> quick_color
rgb<.45*1.35,.22*1.3,.05*3>}finish{ambient 1}}hollow no_shadow}
}

[Mark Wagner] Comparison of spline types [8813 days 9 hours and 20 minutes ago]

Tue, 26 Feb 2002 02:44:34 GMT

For anyone who was wondering what all the fuss about splines was, I've
created a rendering of the three spline types using the same set of control
points.  The red line is a natural cubic spline, the green line is a linear
spline, and the blue line is a Catmull-Rom spline.

--
Mark

[Bill Brehm] Re: problem with anti-aliasing? [8817 days 5 hours and 54 minutes ago]

Fri, 22 Feb 2002 06:10:45 GMT

I discovered that the reason is that the anti-aliasing parameters are not
being read the same way in 3.1 and 3.5.11. Maybe it's a bug and maybe it's
intentional. I'll describe it.

For some special purposes, I had added entries in the quickres.ini file. The
first entry below is a standard and the second is what I set up.

[640x480, AA 0.3]
Width=640
Height=480
Antialias=On
Antialias_Threshold=0.3

[768x494, AA 0.3]
Width=768
Height=494
Antialias=On
Sampling_Method=2
Antialias_Depth=4
Antialias_Threshold=0.3

This "bug" was detected at 640x480, but was solved at 768x494. So I looked
deeper.

I have a povray.ini file in the same directory as the fiducial.pov source
file. It also specifies the additional anti-aliasing parameters. 3.1 reads
that file, but 3.5.11 does not. I renamed the file to fiducial.ini; neither
version read it. (This would be what I would prefer to work in both cases,
since I can have more than one .pov in a directory and not force them the
share the same povray.ini file. I don't like having to render the .ini
file.) I added the fiducial.pov name into the .ini file and rendered the
.ini file. 3.5.11 worked and 3.1 complained. I added Input_File_Name =
fiducial.pov into the .ini file, and rendered the .ini file and both
versions work. Of course the bad thing is I have to keep the .ini file open
in the editor and remember to switch from the .pov file to the .ini file
before pressing RUN. That's why I'd prefer that when rendering name.pov, the
renderer looked for name.ini to find any additional parameters.

At any rate, that's what happens. Is this a bug or it is an intentional "new
feature"?

Bill



"Anders K." <and### [at] prostard2gcom> wrote in message
news:3c759cc2$1@news.povray.org...
> > That's odd, because the object rendered in 3.1 with AA is placed exactly
> at
> > 0, 0 and the camera is looking at 0, 0 and the object is rendered quite
> > symetrically. Notice the cross at the center of the circle; the pixel
> colors
> > representing where the edge lies seem equally bright both left and
right,
> > and top and bottom.
>
> This is because the object is exactly centered at (320.5, 239.5), which is
> the center of pixel (320, 239). So it will look symmetrical, but it's
> centered around the wrong place.
>
> In fact, the 3.5 beta 11 image is also centered at (320.5, 239.5). Did you
> set #version to 3.1? That would disable the half-pixel bug fix.
>
> Anders
>
>
>

[Anders K ] Re: problem with anti-aliasing? [8817 days 10 hours and 44 minutes ago]

Fri, 22 Feb 2002 01:20:02 GMT

> That's odd, because the object rendered in 3.1 with AA is placed exactly
at
> 0, 0 and the camera is looking at 0, 0 and the object is rendered quite
> symetrically. Notice the cross at the center of the circle; the pixel
colors
> representing where the edge lies seem equally bright both left and right,
> and top and bottom.

This is because the object is exactly centered at (320.5, 239.5), which is
the center of pixel (320, 239). So it will look symmetrical, but it's
centered around the wrong place.

In fact, the 3.5 beta 11 image is also centered at (320.5, 239.5). Did you
set #version to 3.1? That would disable the half-pixel bug fix.

Anders

[Bill Brehm] Re: problem with anti-aliasing? [8817 days 12 hours and 33 minutes ago]

Thu, 21 Feb 2002 23:31:38 GMT

That's odd, because the object rendered in 3.1 with AA is placed exactly at
0, 0 and the camera is looking at 0, 0 and the object is rendered quite
symetrically. Notice the cross at the center of the circle; the pixel colors
representing where the edge lies seem equally bright both left and right,
and top and bottom.

The thing I'm referring to is that those same edges are very rough and
ragged looking in 3.5.11, but smooth looking in 3.1. Actually, it's not just
the edges, but the black material is less uniformly colored in 3.5.11 and
maybe that's affecting the edge with the yellow material. In fact, the whole
image looks a little bit blurry or softened in 3.1, but quite a bit sharper
in 3.5.11.

So I'm thinking that could be a change in the anti-aliasing, but maybe it's
something else too. (like a different aperature, but I don't have focal
blurring intentionally turned on or off).

Bill


"Anders K." <and### [at] prostard2gcom> wrote in message
news:3c757f68$1@news.povray.org...
> You may want to know that in previous versions of POV-Ray (including
3.1g),
> the entire image was erroneously shifted by half a pixel up and right.
This
> was corrected in 3.5 beta 11. This could be part of your "problem".
>
> Anders
>
> --
> light_source{6#local D#macro B(E)#macro A(D)#declare#declare C=mod(E
> D);E=(E-C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)
> }cylinder{0(C=<1 2>).2translate<D+C*A(2)A(4)#else}intersection{torus
> {1 .2}box{-2y}rotate<1 0C>*90translate<D+1A(2)*2+1#end-2 13>pigment{
> rgb x}finish{specular 1}#end#end#end=-8;1B(445000298)B(519053970)B(
> 483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}
>
>
>
>

[Anders K ] Re: problem with anti-aliasing? [8817 days 12 hours and 49 minutes ago]

Thu, 21 Feb 2002 23:14:48 GMT

You may want to know that in previous versions of POV-Ray (including 3.1g),
the entire image was erroneously shifted by half a pixel up and right. This
was corrected in 3.5 beta 11. This could be part of your "problem".

Anders

--
light_source{6#local D#macro B(E)#macro A(D)#declare#declare C=mod(E
D);E=(E-C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)
}cylinder{0(C=<1 2>).2translate<D+C*A(2)A(4)#else}intersection{torus
{1 .2}box{-2y}rotate<1 0C>*90translate<D+1A(2)*2+1#end-2 13>pigment{
rgb x}finish{specular 1}#end#end#end=-8;1B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

[Bill Brehm] Re: problem with anti-aliasing? [8818 days 3 hours and 25 minutes ago]

Thu, 21 Feb 2002 08:39:15 GMT

Hi,

I forgot to mention that when I rendered the file in both 3.1 and 3.5.11
with anti-aliasing turned off, the two images are almost (but not exactly)
identical. I don't think I need to upload those images, unless someone asks.

Bill

"Bill Brehm" <bbr### [at] netzeronet> wrote in message
news:3c739448@news.povray.org...
> Hi,
>
> I rendered the same image with 3.1 and 3.5.11. The image from 3.5 looks
like
> something is wrong with the anti-aliasing. Or has something changed that
I'm
> not aware of that affects the image?
>
> The file:
>
> //
> // Persistence Of Vision
> // Synthetic Fiducial for Matrox and
> //
>
> #version 3.1
> global_settings { assumed_gamma 2.2 }
> global_settings { ambient_light 0.1 }
>
> #include "colors.inc"
> #include "textures.inc"
>
> background { color SteelBlue }
>
> #declare Tiny = 0.001;
>
> // Lighting declarations
>
> #declare ledoffset = .125;
>
> #declare ringleds = 60;
> #declare ringlightdiameter = 5.5;
> #declare ringlightdiffuserthickness = 5/32;
> #declare ringlightthickness = 0.5;
> #declare ringlightheight = 0.25;
>
> #declare onaxisledsx = 8;
> #declare onaxisledsy = 8;
> #declare onaxissizex = 4.620998;
> #declare onaxissizey = 4.620998;
> #declare onaxisdiffuserthickness = 0.125;
>
> #declare Led = light_source{
>   <0,0,0>
>   color White * 0.05
>   /*looks_like {
>     union {
>       sphere{ <0,0,0>, 0.09375}
>       cylinder{ <0,0,0>, <0,-0.25,0> 0.09375}
>     }
>     pigment {color Red}
>   }*/
> }
>
> #declare RingDiffuser = difference {
>   cylinder {
>     <0, 0, -ringlightthickness / 2>,
>     <0, 0, ringlightthickness / 2>,
>     ringlightdiameter / 2
>   }
>   cylinder {
>     <0, 0, -ringlightthickness / 2 - 0.001>,
>     <0, 0, ringlightthickness / 2 + 0.001>,
>     (ringlightdiameter - ringlightdiffuserthickness) / 2
>   }
>   texture {
>     Glass3
>     pigment { rgbf <1, 1, 1, 0.5> }
>   }
> }
>
> #declare RingLight = union {
>   #local Count = 0;
>   #while(Count < ringleds)
>     object { Led rotate <0, 0, 90> translate <(ringlightdiameter/2 +
> ledoffset), 0, 0> rotate <0, 0, (360/ringleds * Count)>}
>     #local Count = Count + 1;
>   #end
>
>   object {RingDiffuser}
> }
>
> #declare OnAxisDiffuser = box {
>   <-onaxissizex / 2, -onaxissizey / 2, 0>,
>   <onaxissizex / 2, onaxissizey / 2, -onaxisdiffuserthickness>
>   texture {
>     Glass3
>     pigment { rgbf <1, 1, 1, 0.5> }
>   }
> }
>
> #declare OnAxisLight = union {
>   #local XCount = 0;
>   #while(XCount < onaxisledsx)
>     #local YCount = 0;
>     #while(YCount < onaxisledsy)
>       #local xposition = (XCount - (onaxisledsx - 1) / 2) * (onaxissizex /
> onaxisledsx);
>       #local yposition = (YCount - (onaxisledsy - 1) / 2) * (onaxissizey /
> onaxisledsy);
>       #local zposition = -ledoffset;
>
>       object { Led rotate <90, 0, 0> translate <xposition, yposition,
> zposition> }
>       #local YCount = YCount + 1;
>     #end
>     #local XCount = XCount + 1;
>   #end
>
>   object {OnAxisDiffuser}
> }
>
> // Size of Strip
> #declare StripL = 4.8;
> #declare StripW = 3.55;
>
> // Center of Strip is bottom center
> // Strip length is in Y axis in Z plane, ie at the position it would be
> loaded
>
> // Body is the Dark Green Plastic Bit
> #local StripBodyL = StripL;
> #local StripBodyW = StripW;
> #local StripBodyH = 1.000;
> #local StripMaskH = 0.050;
>
> #local StripBodyTexture =
>   texture {
>     pigment { color red 0.18 green 0.27 blue 0.30 }
> //    finish  { Phong_Glossy }
>   }
>
> #local StripMaskTexture =
>   texture {
>     pigment { color red 0.18 green 0.27 blue 0.30 }
>     finish  { Phong_Glossy }
>   }
>
> #local StripBody = box {
>   <-StripBodyL/2, -StripBodyW/2, StripBodyH>,
>   <StripBodyL/2, StripBodyW/2, 0>
>   texture {
>     StripBodyTexture
>   }
> }
>
> #local StripMask = box {
>   <-StripBodyL/2, -StripBodyW/2, 0>,
>   <StripBodyL/2, StripBodyW/2, -StripMaskH>
>   texture {
>     StripMaskTexture
>   }
> }
>
> // Fiducial constants [mm]
> #local StripFiducialThickness = 0.050;
>
> #local StripFiducialDiameter = 1.000;
> #local StripFiducialStreetWidth = 0.125 * StripFiducialDiameter;
> #local StripFiducialClearance = 0.400;
>
> #local StripFiducialTexture = texture {Gold_Metal}
>
> // Round crosshair fiducial declaration
>
> #local StripFiducial = difference {
>   cylinder {
>     <0, 0, 0>
>     <0, 0, -StripFiducialThickness>
>     StripFiducialDiameter / 2
>   }
>   box {
>     <-StripFiducialDiameter / 2 - Tiny, StripFiducialStreetWidth /
> 2, -StripFiducialThickness - Tiny>
>     <StripFiducialDiameter / 2 + Tiny, -StripFiducialStreetWidth / 2,
Tiny>
>   }
>   box {
>     <StripFiducialStreetWidth / 2, -StripFiducialDiameter / 2 -
> Tiny, -StripFiducialThickness - Tiny>
>     <-StripFiducialStreetWidth / 2, StripFiducialDiameter / 2 + Tiny,
Tiny>
>   }
>   texture {StripFiducialTexture}
> }
>
> // Camera declaration and instantiation
>
> /*#declare lens_dist = function(x, y, z, a, b) {
>    (x + a * x * sqrt(x*x + y*y) + b * x^3 * sqrt(x*x + y*y) ) ^ 2 +
>    (y + a * y * sqrt(x*x + y*y) + b * y^3 * sqrt(x*x + y*y) ) ^ 2
> } */
>
> #declare a_factor = 0.65;
> #declare b_factor = 0.1;
>
> #declare HFOV = 5.00;
> #declare VFOV = HFOV * 3 / 4;
>
> #declare cameraheight = 10.000;
>
> camera {
>   orthographic
>   location <0, 0, 0>
>   right <HFOV, 0, 0>
>   up <0, VFOV, 0>
>   sky <0, 1, 0>
>   direction <0, 0, cameraheight>
>   look_at <0, 0, 1>
>   translate <0, 0, -cameraheight>
> }
>
> #local ArrayMax = 121;
> #local XPos = array[ArrayMax]
> #local YPos = array[ArrayMax]
> #local Scale = array[ArrayMax]
> #local Rotate = array[ArrayMax]
> #local XPos[0] = 0.0;           // force arrays to be floats
> #local YPos[0] = 0.0;
> #local Scale[0] = 0.0;
> #local Rotate[0] = 0.0;
>
> // Lighting and device instantiations
>
> // Note: lighting is defined in inches and the strip is defined in
> millimeters
>
> //object {RingLight translate (<0, 0, -(ringlightthickness / 2 +
> ringlightheight)>)}
> object {OnAxisLight translate (<0, 0, -20>)}
>
> //sphere {<0, 0, 0> 0.1 pigment {Red}}
>
> #local i = int(clock * ArrayMax + 0.5);
>
> #declare Strip = difference {
>   union {
>     object {StripBody }
>     difference {    // !!! fix this
>       object {StripMask }
>       cylinder {
>         <0, 0, Tiny>
>         <0, 0, -StripMaskH - Tiny>
>         (StripFiducialDiameter + StripFiducialClearance) / 2
>         //translate StripFiducialPosition
>       }
>     }
>     object {StripFiducial scale <Scale[i], Scale[i], 1> rotate <0, 0,
> Rotate[i]> translate <XPos[i], YPos[i], 0>}
>   }
> }
>
> object {Strip}
>
> The local ini file:
>
> ;Initial_Frame = 1
> ;Final_Frame = 121
> ;Subset_Start_Frame = 1
> ;Subset_End_Frame = 1
> ;Cyclic_Animation = True
> ;Quality = 2
>
> Antialias = on
> Sampling_Method = 2
> Antialias_Depth = 4
> ;Antialias_Threshold = 0.3
> Jitter = off
>
> Both renders were set to 640x480 AA 0.3.
>
> Thanks,
>
> Bill
>
>
>
>
>
>
>
>
>

[Tom Bates] Re: Bug with & and | ? [8845 days 17 hours and 8 minutes ago]

Thu, 24 Jan 2002 18:56:28 GMT

ingo <ing### [at] homenl> wrote in message news:Xns### [at] povrayorg...
> in news:3c504e4f@news.povray.org Tom Bates wrote:
>
> > Has the meaning of & and | changed since the tutorial was written?
> >
>
> Yes, I'll update the tutorial section.
>

Thanks.

Is there a document that explains how the new meaning is different from the old, and
how that makes it not work here?

Also, is there still a way of doing this (combining functions) with & and |, or is
the min() and max() methods now the only way?

> Ingo
>

--
Tom Bates

[ingo] Re: Bug with & and | ? [8845 days 17 hours and 34 minutes ago]

Thu, 24 Jan 2002 18:29:54 GMT

in news:3c504e4f@news.povray.org Tom Bates wrote:

> Has the meaning of & and | changed since the tutorial was written?
> 

Yes, I'll update the tutorial section.

Ingo

[Tom Bates] Bug with & and | ? [8845 days 17 hours and 53 minutes ago]

Thu, 24 Jan 2002 18:11:27 GMT

[POV-Ray for Windows v3.5 (b10)]
[400MHz Celeron w/ 320MB]

I decided to try to learn about Isosurfaces, so I went to the Isosurface tutorial in
Help.

Everything was going fine, until I tried combining functions with & and |.

When it rendered, nothing appeared.

I tried using the min() and max() methods of combining functions (as described in the
tutorial) and it worked as expected.

Attached are two image files showing my results, and below is the code that produced
them.

I looked in the 'Known bugs' posts before posting this, but didn't find anything.
I looked in revision.txt that came with beta10, and all I found was this:

        Change 1238 on 2001/11/02 by thorsten@host27

          Fixes problems with #undef of functions
          Fixes & and | operators in functions
          Fixes <= operator in functions

My Questions:
Has the meaning of & and | changed since the tutorial was written?
Or, is this a bug that wasn't quite fixed yet?

Thanks,

Tom Bates.



/* -------------- IsoTest.pov -------------- */

background {rgb 1}

light_source { <100,100,-10>, 1 }

camera {
  location <10,10,15>
  look_at  <0,0,0>
  angle 15
}

// axes
union {
  cylinder { -10*x 10*x 0.02 }
  cylinder { -10*y 10*y 0.02 }
  cylinder { -10*z 10*z 0.02 }
  pigment{green 1}
}

#declare fn_A = function { sqrt(y^2 + z^2) - 0.8 }
#declare fn_B = function { abs(x)+abs(y)-1 }

isosurface {
  #switch (0)
    #case (0)   function { min(fn_A(x,y,z), fn_B(x,y,z)) }  #break
    #case (1)   function { fn_A(x,y,z) | fn_B(x,y,z) }      #break
  #end
  max_gradient 4
  contained_by { box { -2, 2 } }
  pigment {rgb 1}
}

[Tim Nikias] Re: Light/Macro-Chessboard Bug Scene files [8847 days 20 hours and 34 minutes ago]

Tue, 22 Jan 2002 15:30:02 GMT

Here's whats wrong:

On my computer (1.4 GHZ Athlon, POV-Ray Beta 10, Win98, 512 RAM)
the following files create an image with unexpected lighting.

The scene actually generates a mesh (with only two triangles) and several
CSG chess-figurines, which are placed (using Macros) onto their initial
starting positions.
The one and only lightsource in scene is placed just above the middle of the
board.

The bug is as follows:
The figurines aren't lighted properly. Though some are, most were not lit from
the correct direction and throwing wrong shadows. Some even looked like
they were lit from underneath, and though my first guess was that they were lit and
then placed, none of the figurines is created upside down and then rotated...

Well, I'll put an image of that on my homepage for those interested in what
it looked like on my system...

Hope that clears it up!

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

[Jan Walzer] Parse-Error on transform{Transform-Identifier} [8849 days 20 hours and 5 minutes ago]

Sun, 20 Jan 2002 15:59:01 GMT

Look at the file, and tell me, why

transform identifier

works, but

transform {identifier}

doesn't.
I need to wrap the braces around the identifier, to apply the inverse
transformation...

I'm sure, it's my fault....

--
[Talking about cardriving]
"People are opstacles?
Oh...I always treat them as bonus points..." [Ian Burgmyer in p.o-t]
// Jan Walzer <jan### [at] lzernet>

[Tim Nikias] Light/Macro-Chessboard Bug Scene files [8849 days 23 hours and 4 minutes ago]

Sun, 20 Jan 2002 13:00:38 GMT

Here they are.

chs_tst.pov is the scene file, which includes the other two
include-files.
They weren't changed from the image version posted in beta-test.

Tim

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

[Jérôme Grimbert] Re: language specific characters [8853 days 23 hours and 34 minutes ago]

Wed, 16 Jan 2002 12:30:19 GMT

Fabien Mosen wrote:
> 
> J. Grimbert wrote:
> 
> > Exactly!. Thanks for the right spelling.
> > I wonder what the japanese glyph stand for.
> 
> "red haired guy"
Not really.
All I get is :"Horse, (sun/day or say) and (dry/dryness or protection)", 
with 17 lines (10 + 4 +3).
Alas, it is not part of the japanese 1940 recommended symbols,
so it must really be some advanced one (or just a chinese).
It would be rather strange if it was only : "horse body dried by the sun"


-- 
Non Sine Numine
http://grimbert.cjb.net/

[Fabien Mosen] Re: language specific characters [8856 days 14 hours and 16 minutes ago]

Sun, 13 Jan 2002 21:47:52 GMT

J. Grimbert wrote:


> Exactly!. Thanks for the right spelling.
> I wonder what the japanese glyph stand for.


"red haired guy"

Fabien.

[ingo] Re: language specific characters [8858 days 17 hours and 58 minutes ago]

Fri, 11 Jan 2002 18:06:11 GMT

in news:3c3ed0af@news.povray.org Thorsten Froehlich wrote:

> Feel free to use ™

I'll do so and fix the others, but not anymore for the comming beta.

Ingo

[Thorsten Froehlich] Re: language specific characters [8859 days and 17 minutes ago]

Fri, 11 Jan 2002 11:46:55 GMT

In article <3C3EC39B.807D48A6@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> I think
>
> <FONT SIZE="-1"><SUP>TM</SUP></FONT>
>
> is the classical way, but of couse unicode is more elegant.

Feel free to use ™ , the doc generator can always replace it by
something supported by Netscape.  ™ is a standard entity in HTML 4.0
and has been supported by most browsers, except by Netscape 1.x-4.x also it
would have been a one line change in their code to fix it years ago :-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[] Re: language specific characters [8859 days 1 hour ago]

Fri, 11 Jan 2002 11:04:39 GMT

On Fri, 11 Jan 2002 11:51:07 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> I think <FONT SIZE="-1"><SUP>TM</SUP></FONT> is the classical way

font tag is deprecated in lastest specifications

> unicode is more elegant.

but probably depends on installed font
what about css ?

ABX

[Christoph Hormann] Re: language specific characters [8859 days 1 hour and 13 minutes ago]

Fri, 11 Jan 2002 10:51:22 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> Trademark sign should be probably replaced with superscript or unicode code
> http://www.unicode.org/charts/PDF/U2100.pdf
> 

I think

<FONT SIZE="-1"><SUP>TM</SUP></FONT>

is the classical way, but of couse unicode is more elegant.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[J Grimbert] Re: language specific characters [8859 days 1 hour and 24 minutes ago]

Fri, 11 Jan 2002 10:40:44 GMT

"W³odzimierz ABX Skiba" wrote:
 
> Jerome should be "Jérôme" probably

Exactly!. Thanks for the right spelling.
I wonder what the japanese glyph stand for.
-- 
Non Sine Numine
http://grimbert.cjb.net/

[] Re: language specific characters [8859 days 1 hour and 30 minutes ago]

Fri, 11 Jan 2002 10:34:25 GMT

On Fri, 11 Jan 2002 19:14:49 +0900, "R. Suzuki" <r-s### [at] aistgojp> wrote:
> There are a few language specific characters in POV-Help 8.1 and 8.2.3.
> Here is the image of  those characters on Japanese Windows.

Trademark sign should be probably replaced with superscript or unicode code
http://www.unicode.org/charts/PDF/U2100.pdf

Jerome should be "Jérôme" probably

Looks like in help Rene and René can coexist ;-)

ABX

[R Suzuki] language specific characters [8859 days 1 hour and 50 minutes ago]

Fri, 11 Jan 2002 10:14:35 GMT

There are a few language specific characters in POV-Help 8.1 and 8.2.3.
Here is the image of  those characters on Japanese Windows.

[] tiff problems in reading (including crash, inclu... [8866 days and 1 minute ago]

Fri, 4 Jan 2002 12:03:24 GMT

images according to post just sended to beta-test

ABX

[Felix Wiemann] Re: Render Window options [8868 days 16 hours and 45 minutes ago]

Tue, 1 Jan 2002 19:19:45 GMT

> In this beta, you have chosen to make the background of the render
window a
> checker pattern...while this is useful for many different things, I
want a
> way to make this turn back to black because I find it impossible to
work
> with when trying to work on a small section of a scene by doing a
partial
> render.  If it is a dark scene, thechecker pattern tends to overpower
the
> image to the point of making it useless.

You should post this into p.b-t instead of p.b-t.binaries.

[William Fex] Render Window options [8868 days 18 hours and 21 minutes ago]

Tue, 1 Jan 2002 17:43:02 GMT

In this beta, you have chosen to make the background of the render window a
checker pattern...while this is useful for many different things, I want a
way to make this turn back to black because I find it impossible to work
with when trying to work on a small section of a scene by doing a partial
render.  If it is a dark scene, thechecker pattern tends to overpower the
image to the point of making it useless.

[Francois Labreque] Re: CSG difference with text [8869 days 22 hours and 56 minutes ago]

Mon, 31 Dec 2001 13:08:04 GMT

Felix Wiemann wrote:

> See p.b-t.

Another picture that shows the problem...

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

[Felix Wiemann] CSG difference with text [8870 days and 24 minutes ago]

Mon, 31 Dec 2001 11:40:34 GMT

See p.b-t.

[Christian Walther] Re: premultiplied alpha (Screenshot) [8871 days 22 hours and 44 minutes ago]

Sat, 29 Dec 2001 13:20:32 GMT

This is what my program (code name "Zorro") looks at the moment (the user
interface is preliminary): Feed it some image-background-pairs, and it
computes a backgroundless image and a mask (the third output image is
statistics: the blue-cyan parts for example mean that the highlight cannot
be reproduced exactly)

Sorry for the big download, but I didn't want to reduce the color depth so
that one can see the full detail of the input and output images.

[Josh English] Warning information on Mac beta 9 [8874 days 11 hours and 9 minutes ago]

Thu, 27 Dec 2001 00:55:18 GMT

See post in p.b-t.

Josh English
eng### [at] spiritonecom
http://www.spiritone.com/~english

[Rick [Kitty5]] Re: Not really a bug report, but... [8877 days 21 hours and 43 minutes ago]

Sun, 23 Dec 2001 14:21:14 GMT

> > Here are the two images for comparison:
>
> And with Win95 it looks yet different...

all this wonderful variation with out even trying :)


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

[Rune] Re: Not really a bug report, but... [8878 days 1 hour and 59 minutes ago]

Sun, 23 Dec 2001 10:04:52 GMT

"Francois Labreque" wrote:
> Here are the two images for comparison:

And with Win95 it looks yet different...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[Francois Labreque] Re: Not really a bug report, but... [8878 days 6 hours and 6 minutes ago]

Sun, 23 Dec 2001 05:58:16 GMT

Francois Labreque wrote:

> See post in p.b-t.
> 


Here are the two images for comparison:




-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

[Francois Labreque] Not really a bug report, but... [8878 days 15 hours and 12 minutes ago]

Sat, 22 Dec 2001 20:52:40 GMT

See post in p.b-t.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

[KalleK] Re: the lowest pixel getting dimmed [8878 days 22 hours and 32 minutes ago]

Sat, 22 Dec 2001 13:32:24 GMT

The first half is with clock~.1
The scond one with clock~.9

See thread in p.b-t

cukk

[bob h] leaking normals revisited, colors show on opposi... [8883 days 15 hours and 55 minutes ago]

Mon, 17 Dec 2001 20:08:51 GMT

This is no doubt in relation to the following:

Highlight bug (job000137)
(highlights are sometimes visible where they should be in shadow)
http://news.povray.org/3bb4cf08@news.povray.org

where the normals can leak textures through to the opposite side of a
surface.  I just wanted to show what I encountered due to it.  Well, I'm not
100% certain it is the exact same reason but it is similar enough.  It
reminds me of the old reflection inverted normals thing from early 3.1
versions except in this case there shouldn't be any color getting out from
behind a blocking sphere.

To describe the attached renders a little, when the plane or isosurface  is
present the interior of the model shows up outside as red speckles on the
small scale normals present in the metal texture.  Presumably caused by
reflection.  The only openings to the inside are windows hidden beneath
textured disc sections and the hatches on top and bottom.  The inside red
sphere is separate from a outer sphere of another color.

The jpeg messes with it somewhat but you can still see the "leaking" color
on the metal beam near the ground plane of grass, and moreso for the one of
the isosurface.  When the ground is removed no red shows up.

Again, I'm just posting this as example about the problem, if it is indeed
one.

[bob h] Re: Mosaic. Is it noise, hf_gray_16....? [8886 days 14 hours and 34 minutes ago]

Fri, 14 Dec 2001 21:30:43 GMT

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C1### [at] gmxde...
>
> Did i miss something or do you use an image_map in an isosurface function
> without interpolation?  This would lead to infinite gradients and
> therefore serious problems.
>
> Because of this the '.hf' is probably not very useful in most cases since
> it won't work with interpolation.

Went back and checked both with and without interpolate.  Yes, it makes a
big difference.  If not used the isosurface is contoured, and with
interpolate it is contour-free.  I hadn't gotten a sufficient max_gradient
to smooth it without interpolate so now that makes sense.

The previous contouring I was talking about was simply the original
hf_gray_16 output, which turns out to be max_gradient related because of
being a isosurface too.  I was expecting that perhaps max_gradient was being
done differently by default now to where it chose the best automatically.
Maybe my fault for reading between the lines concerning how isosurface
workings had changed.  I was kind of clumping it all together there by using
two isosurfaces in one test  :-)  a regular pigment pattern could have
sufficed.

The major thing is that .hf instead of .gray was the real answer.
--
text{ttf"arial","bob h",.1,0pigment{rgb 9}translate<-1,-.2,3>}

[Christoph Hormann] Re: Mosaic. Is it noise, hf_gray_16....? [8886 days 16 hours and 48 minutes ago]

Fri, 14 Dec 2001 19:16:19 GMT

Did i miss something or do you use an image_map in an isosurface function
without interpolation?  This would lead to infinite gradients and
therefore serious problems.  

Because of this the '.hf' is probably not very useful in most cases since
it won't work with interpolation.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[Mike Williams] Re: Mosaic... some clarifications [8886 days 17 hours and 11 minutes ago]

Fri, 14 Dec 2001 18:52:54 GMT

Wasn't it W³odzimierz ABX Skiba who wrote:
>On Thu, 13 Dec 2001 04:24:52 -0600, "bob h" <omn### [at] charternet> wrote:
>> >         function {y-F_p(x,y,z).hf*.1}
>> > and it may also be worthwhile to increase the max_gradient on your
>> > second isosurface.
>>
>> It's a miracle!  Well, okay, not exactly a real miracle but close enough.  I
>> didn't know about this .hf thing before
>
>I was surprised too. I know - RTFM, but ".hf" is noted only in one place 
>(6.5.4.2), it is connected with function syntax but listed in isosurface chapter 
>and it
>is not listed in index. Also I wonder what about below script:
>
>#local P=function{pigment{granite}}
>#local F1=function{P(1,2,3).red} // works
>#local F2=function{P(1,2,3).hf}  // works
>#local A1=P(1,2,3).red;          // works
>#local A2=P(1,2,3).hf;           // not
>
>is it bug ?

I confirm that it doesn't parse.

However ".hf" is an experimental feature, so perhaps it shouldn't be
heavily documented yet, since "the design and implementation of these
features is likely to change in future versions of POV-Ray."

-- 
Mike Williams
Gentleman of Leisure

[] Re: Mosaic... some clarifications [8887 days 4 hours and 34 minutes ago]

Fri, 14 Dec 2001 07:29:54 GMT

On Thu, 13 Dec 2001 04:24:52 -0600, "bob h" <omn### [at] charternet> wrote:
> >         function {y-F_p(x,y,z).hf*.1}
> > and it may also be worthwhile to increase the max_gradient on your
> > second isosurface.
>
> It's a miracle!  Well, okay, not exactly a real miracle but close enough.  I
> didn't know about this .hf thing before

I was surprised too. I know - RTFM, but ".hf" is noted only in one place (6.5.4.2), it
is connected with function syntax but listed in isosurface chapter and it
is not listed in index. Also I wonder what about below script:

#local P=function{pigment{granite}}
#local F1=function{P(1,2,3).red} // works
#local F2=function{P(1,2,3).hf}  // works
#local A1=P(1,2,3).red;          // works
#local A2=P(1,2,3).hf;           // not

is it bug ?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[bob h] Re: Mosaic... some clarifications [8888 days 1 hour and 39 minutes ago]

Thu, 13 Dec 2001 10:25:35 GMT

"Mike Williams" <mik### [at] nospamplease> wrote in message
news:Gue### [at] econymdemoncouk...
>
> What's happening is that .grey isn't the correct way to extract height
> information from a hf_gray_16 image, it's the way to extract a gray
> equivalent from an RGB image. The data bits are stored in a different
> order in a hf_gray_16 than they are in an RGB image, so the resulting
> pixels are at all sorts of wrong heights.
>
> So change it from ".gray" to the experimental ".hf", like
>
>         function {y-F_p(x,y,z).hf*.1}
>
> and it may also be worthwhile to increase the max_gradient on your
> second isosurface.

It's a miracle!  Well, okay, not exactly a real miracle but close enough.  I
didn't know about this .hf thing before, or simply went in one ear and out
the other; and Context Help doesn't find it.  Worked okay on the Targa image
input but png is still broken.  I thought it had been fixed as of beta 8.

Found out just now I wasn't thorough enough when I went to check on this
before posting.  My search of povray.beta-test for hf_gray_16 png came up
with nothing so I reread some.  I've seen the Known Bugs Dec 10 posting by
you and Ron's reply to that concerning png output.  I remembered it
differently, as Ron saying it had been fixed as of this current beta.  Not
so, apparently for next beta 9.

I've also been under the impression that isosurfaces were now being more
automatic in the way max_gradient was handled.  I need to read up on that
some more too.

So, I'll just go away now and come back when I have something else.  Sorry
for the bother.  Thanks for the help and answer!
--
text{ttf"arial","bob h",.1,0pigment{rgb 9}translate<-1,-.2,3>}

[Mike Williams] Re: Mosaic... some clarifications [8888 days 4 hours and 11 minutes ago]

Thu, 13 Dec 2001 07:53:23 GMT

Wasn't it bob h who wrote:

>Anyway, that isn't the main concern I had.  It's the mosaic produced from
>the hf_gray_16 image when used in a isosurface.  The image being output is
>always nothing but noise instead of smooth pattern (oh yeah, please ignore
>that ppm image unless it means anything.  I just put that in to try it too).
>I thought this was fixed as of beta 8, otherwise I wouldn't have posted
>about it.

What's happening is that .grey isn't the correct way to extract height
information from a hf_gray_16 image, it's the way to extract a gray
equivalent from an RGB image. The data bits are stored in a different
order in a hf_gray_16 than they are in an RGB image, so the resulting
pixels are at all sorts of wrong heights.

So change it from ".gray" to the experimental ".hf", like

        function {y-F_p(x,y,z).hf*.1}

and it may also be worthwhile to increase the max_gradient on your
second isosurface.

-- 
Mike Williams
Gentleman of Leisure

[bob h] Re: Mosaic... some clarifications [8888 days 6 hours and 17 minutes ago]

Thu, 13 Dec 2001 05:46:48 GMT

I realize that the default isosurface max_gradient is at fault for the
contour lines when creating the hf_gray_16 test image.  However, even when
using the suggested max_gradient of 2.187 there was a single dot of white
amidst the otherwise okay pattern when using noise_generator 3.  Type 1 is
of course filled with plateaus and type 2 was okay.

I was under the impression that now max_gradient was found and used without
intervention.

Anyway, that isn't the main concern I had.  It's the mosaic produced from
the hf_gray_16 image when used in a isosurface.  The image being output is
always nothing but noise instead of smooth pattern (oh yeah, please ignore
that ppm image unless it means anything.  I just put that in to try it too).
I thought this was fixed as of beta 8, otherwise I wouldn't have posted
about it.

Thanks for checking this out if you have done so.

[bob h] Mosaic. Is it noise, hf_gray_16....? [8888 days 12 hours and 18 minutes ago]

Wed, 12 Dec 2001 23:45:58 GMT

/* see related message at p.b-t. */

/* use respective cmd comment to render with, depending on GrayImage */

#declare GrayImage=yes; // yes to make input image, no for final output

#if (GrayImage=yes)

/* please note that the +hi file may be different from yours */

// cmd: +hiBeta8fix.inc +fn +w900 +h900 +oc:\images\isogray16.png

// cmd: +hiBeta8fix.inc +ft +w900 +h900 +oc:\images\isogray16.tga

// cmd: +hiBeta8fix.inc +fp +w900 +h900 +oc:\images\isogray16.ppm

#include "functions.inc"

global_settings {
        hf_gray_16 on  // whether on or off, has contour lines
        noise_generator 3  // 1, 2 or 3
         }

camera{
    orthographic
    location  y*10
    up        y*30
    right     x*30
    look_at   0
}

isosurface{
    function{y-f_noise3d(x,y,z)} // could this be the problem?
    contained_by{box{<0,-0.1,-30>,<30,1,0>}}
    // notice the default max_gradient, etc, is used
    texture{pigment{gradient y}finish{ambient 1}}
    translate x*-15+z*15
}

#else

/* be sure to use this command line when GrayImage=no ! */

// cmd: +hiBeta8fix.inc +fn +w320 +h240 +oc:\images\isotest16.png

#declare F_p=function {
       pigment {image_map {
/* use input image intended for test */
        png "isogray16.png"
 //       tga "isogray16.tga"
 //       ppm "isogray16.ppm" // errors, unsupported number of colors
        }
        rotate 90*x translate -.5}
}

isosurface {
        function {y-F_p(x,y,z).gray*.1}
        contained_by {box {-1,1}}
 texture {pigment {rgb 1}}
   scale <10,1,10> rotate -45*x translate <0,.25,2>
}

light_source {<10,10,-10>,1}
#end

[Bryan Valencia] Re: strange inactive save button (0/1) [8896 days 13 hours and 33 minutes ago]

Tue, 4 Dec 2001 22:31:07 GMT

I had a problem like this on NT, I had to download the newest comctl32.dll from
someplace.

Check here http://www.google.com/search?q=comctl32.dll


Adrien Beau wrote:

> autowitch wrote:
> >
> > You may want to bump the hardware acceleration on your video card down a
> > notch or two.  That frequently causes things like this.
>
> And besides some people say that, for cards like GeForce,
> it actually improves performance a bit.
>
> --
> Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
>  Mes propos n'engagent que moi et en aucun cas mes employeurs

[Vampyrium] image_pattern [8899 days 1 hour and 41 minutes ago]

Sun, 2 Dec 2001 10:23:02 GMT

-Hail

Test.png is a Photoshop generated file with pixel values from 0-255, next is
bugtest.png which is the rendering done by pov and last is the source code
of the scene.

[James Hansen] Disappearing Large Sphere bug - .pov and .ini fi... [8899 days 13 hours and 8 minutes ago]

Sat, 1 Dec 2001 22:56:01 GMT

Watch the red sphere disappear....

[koos] installer behaves strangely [8900 days 11 hours and 39 minutes ago]

Sat, 1 Dec 2001 00:25:27 GMT

Hello, 

I just installed the new beta. At a certain moment one is prompted for the 
name in the start menu. When one deletes the text and choose the "back" 
button POVRay is being installed. However one would expect povray to install  
after pressing the "next" button and not the "button". 

greetings, Koos Jan

[Gabriel] Marble + Turbulence + Isosurfaces [8901 days 20 hours and 17 minutes ago]

Thu, 29 Nov 2001 15:47:36 GMT

Make I something wrong or is this bug?
-------------------------------------------------

#version 3.5;

#include "colors.inc"

global_settings {
  assumed_gamma 1.5
}

// ----------------------------------------

camera {
  location  <-1.0, 3.5, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}


light_source {
  <1, 7.5, -8>
  color rgb <1, 1, 1>
}

// ----------------------------------------

plane {
  y, -1.5
  texture {
    pigment {
      marble
      color_map {

        [0.0  color rgb < 1,   1,   1   > ]
        [0.33 color rgb < 0,   0.5, 1   > ]
        [0.67 color rgb < 0,   1,   0.5 > ]
        [1.0  color rgb < 1,   1,   1   > ]
      }
      turbulence 0.3
      scale 4
    }
    finish { ambient 0.5 specular 0.6 }
  }
}

#declare f3 = function {
                  pigment{
                     crackle
                     turbulence 0
                     color_map { [0 rgb 1] [1 rgb 0] }
                  }
              }

isosurface {
 function { abs( - z - f3(x,y,z).gray*0.0 ) - 0.01 }
 // see also
 // function { z }
 // function { abs(y)-0.01 }
 threshold 0
 max_gradient 2
 contained_by {box {<-1.2,-1.2,-1.2>, < 1.2, 1.2, 1.2>}}
 texture {
          pigment { color rgbt <1,0,0,0.8> }
   finish {ambient 1 diffuse 0.6}
 }
}


Gabriel
--------
Kon### [at] GGnatowskide

[Greg M Johnson] Re: Unexpected blob shapes upon scaling [8901 days 22 hours and 55 minutes ago]

Thu, 29 Nov 2001 13:08:57 GMT

oops.

[Rune] Re: Unexpected blob shapes upon scaling [8902 days 12 hours and 22 minutes ago]

Wed, 28 Nov 2001 23:42:16 GMT

The attached scene file shows that a union of a cylinder object and two
sphere objects behave the exact same way. So it has absolutely nothing to so
with blobs. It is a logical and expected result of using non-proportional
scaling.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[Rune] Re: Unexpected blob shapes upon scaling [8902 days 13 hours and 9 minutes ago]

Wed, 28 Nov 2001 22:54:49 GMT

"bob h" wrote:
> Both the upper and lower set look the same  :-)

Yep. The results are 100% correct as I see it. It's basic geometry really
and has nothing to do with blobs. You can observe the same phenomena using a
union of a cylinder and two spheres.

> Anyway, I'm thinking what you are seeing is due to how
> radius and strength are formulating the extents.

The strength is constant in all the examples, so I doubt that's what's
causing the confusion. It's merely a matter of radius and scaling. My best
advise would be to re-read my latest reply in that other thread.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[bob h] Re: Unexpected blob shapes upon scaling [8902 days 13 hours and 42 minutes ago]

Wed, 28 Nov 2001 22:21:56 GMT

"Greg M. Johnson" <"gregj56590[:-0]"@aol.com> wrote in message
news:3C0559E3.14962627@aol.com...
> Re-starting the previous thread, with a better example.

Both the upper and lower set look the same  :-)
Anyway, I'm thinking what you are seeing is due to how radius and strength
are formulating the extents.  But I can only make guesses.

--
text{ttf"arial","bob h",.1,0pigment{rgb 9}translate<-1,-.2,3>}

[Greg M Johnson] Unexpected blob shapes upon scaling [8902 days 14 hours and 22 minutes ago]

Wed, 28 Nov 2001 21:42:14 GMT

Re-starting the previous thread, with a better example.

[bob h] Re: Blob bug/feature: The spiky knee (v. 3.02 to... [8902 days 14 hours and 24 minutes ago]

Wed, 28 Nov 2001 21:40:22 GMT

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3c05573f@news.povray.org...
> "Greg M. Johnson" wrote: in message news:3C05481E.C2CEAFBA@aol.com...
> > No, that's not what I'm doing.
>
> You said that the red and green samples in your original post should look
> the same, but they shouldn't, because you have scaled them differently.
>
> > I scaled the x &  z dimensions of the blob component and get
> > a wacky alteration of the blob in the y!! This is not
> > mathematically correct, IFMSS. Look at the code in my original
> > post here...
>
> I did tell you that you should expect that when scaling the cylinder blob
> component non-proportionally. Just imagine that the cap is a sphere. It
> looks longer in the y dimension if you scale it longer in the y dimension,
> but it also looks longer in the y dimension if you scale it smaller in the
x
> and z dimension.
>
> It seems to me that you forget that you have not just scaled the red
> cylinder blob component down in the x and z dimensions, you have also
given
> it a larger radius (4 times as big). That's why the rounded cap of the red
> cylinder blob component is 4 times as long in the y dimension than that of
> the green cylinder blob component.
>
> I really don't see the problem. Could you explain in a more specific way
> what exactly is the wrong behavior?

You're right.  That's what's going on, basically because of the original
sizes and the strength factor too I guess.  I thought this was about
comparing regular cylinder + sphere ends with blob ones.  Seeing the pov
script I too noticed how the y scaling (or sizing) where the spikes are
extend to a distance (more or less) where the blob surface would reach to
were it not scaled on just the two axes.

--
text{ttf"arial","bob h",.1,0pigment{rgb 9}translate<-1,-.2,3>}

[Rune] Re: Blob bug/feature: The spiky knee (v. 3.02 to... [8902 days 14 hours and 35 minutes ago]

Wed, 28 Nov 2001 21:29:35 GMT

"Greg M. Johnson" wrote: in message news:3C05481E.C2CEAFBA@aol.com...
> No, that's not what I'm doing.

You said that the red and green samples in your original post should look
the same, but they shouldn't, because you have scaled them differently.

> I scaled the x &  z dimensions of the blob component and get
> a wacky alteration of the blob in the y!! This is not
> mathematically correct, IFMSS. Look at the code in my original
> post here...

I did tell you that you should expect that when scaling the cylinder blob
component non-proportionally. Just imagine that the cap is a sphere. It
looks longer in the y dimension if you scale it longer in the y dimension,
but it also looks longer in the y dimension if you scale it smaller in the x
and z dimension.

It seems to me that you forget that you have not just scaled the red
cylinder blob component down in the x and z dimensions, you have also given
it a larger radius (4 times as big). That's why the rounded cap of the red
cylinder blob component is 4 times as long in the y dimension than that of
the green cylinder blob component.

I really don't see the problem. Could you explain in a more specific way
what exactly is the wrong behavior?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[Greg M Johnson] Re: Blob bug/feature: The spiky knee (v. 3.02 to... [8902 days 15 hours and 36 minutes ago]

Wed, 28 Nov 2001 20:28:39 GMT

Forgot to add:
the reason of course for x & z scaling of a y axis blob component becomes apparent
when one is trying to model human muscles & bones in a somewhat realistic manner.
It's not all "cylindrical".

[Greg M Johnson] Re: Blob bug/feature: The spiky knee (v. 3.02 to... [8902 days 15 hours and 38 minutes ago]

Wed, 28 Nov 2001 20:26:28 GMT

Rune wrote:

> > Intuitively, the green and red features ought to be the same.
>
> No.
>
> > If they were cylinders, they would be!
>
> You are confusing cylinder objects with cylinder blob components. Cylinder
> blob components have rounded end caps (like if there were spheres in the
> ends) while cylinder objects don't have that. You can't compare them.

No, that's not what I'm doing. Of course, scaling along the 'y' axis gives
expected results, in changing the roundedness of the end cap.  Examples of the
correct, expected behavior in the code below and the attached image...

blob{
        threshold 0.4
        cylinder {<0,0,0>,<0,10,0> ,0.25,1    scale <1,0.1,1>}
        pigment{Red}
        finish{IsoFinish}
        translate <-1,0.0,0>
        }

blob{
        threshold 0.4
        cylinder {<0,0,0>,<0,.1,0>,   0.25,1 scale <1,10,1>}
        pigment{Green}
        finish{IsoFinish}
        translate <0,0.0,0>
        }


blob{
        threshold 0.4
        cylinder {<0,0,0>,<0,1,0>,   0.25,1 scale 1}
        pigment{Green}
        finish{IsoFinish}
        translate <1,0.0,0>
        }


> If you want to avoid the problem you're describing, don't scale cylinder
> blob components non-proportionally. Instead design them with the correct end
> points in the first place, or at least the correct length between the end
> points.

I scaled the x &  z dimensions of the blob component and get a wacky alteration
of the blob in the y!! This is not mathematically correct, IFMSS. Look at the
code in my original post here....

[Rune] Re: Blob bug/feature: The spiky knee (v. 3.02 to... [8902 days 16 hours and 44 minutes ago]

Wed, 28 Nov 2001 19:20:28 GMT

"Greg M. Johnson" wrote:
> If the cylinders have been scaled considerably, one
> ends up with two spikes sticking out of the "knee".

Of course. Cylinder blob components have rounded end caps, like if there
were spheres at the ends. When you scale a cylinder blob component, the end
cap gets scaled too, just like when you scale a sphere.

> Intuitively, the green and red features ought to be the same.

No.

> If they were cylinders, they would be!

You are confusing cylinder objects with cylinder blob components. Cylinder
blob components have rounded end caps (like if there were spheres in the
ends) while cylinder objects don't have that. You can't compare them.

If you want to avoid the problem you're describing, don't scale cylinder
blob components non-proportionally. Instead design them with the correct end
points in the first place, or at least the correct length between the end
points.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[Greg M Johnson] Blob bug/feature: The spiky knee (v. 3.02 to 3.5) [8902 days 19 hours and 50 minutes ago]

Wed, 28 Nov 2001 16:14:36 GMT

I've been working with blobs for years to make characters.  Years ago I
came up with a workaround for the problem that occurs when you have two
cylinders intersect each other.  If the cylinders have been scaled
considerably, one ends up with two spikes sticking out of the "knee".

After thinking about Rune's complaint about the "twice translated blob
texture," I did some more playing around and began wondering if the
spiky knee feature is more bug than purely expected mathematical result.

Intuitively, the green and red features ought to be the same.  If they
were cylinders, they would be!
Comments?
[  This has existed since at least 3.02, uncle Ken!  8-D   ]

[] Re: bug with bozo pattern [8903 days 1 hour and 53 minutes ago]

Wed, 28 Nov 2001 10:10:59 GMT

On Tue, 27 Nov 2001 14:08:09 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> This is all due to the default color_map.  Bozo gets one with sharp
> borders while wood has a smooth brown color_map by default.  This has been
> standard for a long time, just have a look at the 3.1 source.  I think it
> has already been considered changing this to a default grey gradient for
> all patters, but this would discontinue old standards.

This could be simple to achive if it could work

#default {color_map{[0 color rgb 0][1 color rgb 1]}

This way all old default color_maps could be still active but replaced with
above line to new behaviour. But it is rather feature request so no discuss.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[Christoph Hormann] Re: bug with bozo pattern [8903 days 22 hours and 56 minutes ago]

Tue, 27 Nov 2001 13:08:09 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> Yes. I noticed it however most pigments loks like colored correctly even they
> have no colour_map specified ? If it is correct behaviour then it is report for
> documentation becouse there is no note (or I couldn't find any) about default
> color_map for wood and bozo. I checked 6.7.11.36, 6.7.11.4, 6.7.1.3 and others.
> 
> Also when I use my script with pigment{wood/bozo} for objects I achived sharp
> green, blue, red and white shapes for bozo and light/dark brown for wood with no
> smooth transition however documentations says in 'bozo' section "If two points
> are close together, the noise values at those points are close to each other."
> If they aren't I expect some color_map included. But it looks like it is not
> described anywhere.
> 

This is all due to the default color_map.  Bozo gets one with sharp
borders while wood has a smooth brown color_map by default.  This has been
standard for a long time, just have a look at the 3.1 source.  I think it
has already been considered changing this to a default grey gradient for
all patters, but this would discontinue old standards.

And i think you are right, the default color maps are not documented.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[] Re: bug with bozo pattern [8903 days 23 hours and 13 minutes ago]

Tue, 27 Nov 2001 12:51:15 GMT

On Tue, 27 Nov 2001 13:18:06 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> > > Package with good and bad images, scripts and ini-settings after moment in
> > > povray.beta-test.binaries. Broken patterns are 4B, 7B, 12A, 15A and 16A.
> > 
> > Here it is.
> 
> That's fairly simple, you used the pigments without a color map, therefore
> the bozo ones use the default bozo colo map which is quite inappropriate
> for wood.

Yes. I noticed it however most pigments loks like colored correctly even they
have no colour_map specified ? If it is correct behaviour then it is report for
documentation becouse there is no note (or I couldn't find any) about default
color_map for wood and bozo. I checked 6.7.11.36, 6.7.11.4, 6.7.1.3 and others.

Also when I use my script with pigment{wood/bozo} for objects I achived sharp
green, blue, red and white shapes for bozo and light/dark brown for wood with no
smooth transition however documentations says in 'bozo' section "If two points
are close together, the noise values at those points are close to each other."
If they aren't I expect some color_map included. But it looks like it is not
described anywhere.

>  For 15A and 16A this does not apply, but they look fairly normal to me.

Yes, they could be normal. And they have color_map specified. I wonder why some
of the pigments have color_map specidfied twice (for pigment declaration and
then again for texture declaration).

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[Christoph Hormann] Re: bug with bozo pattern [8903 days 23 hours and 46 minutes ago]

Tue, 27 Nov 2001 12:18:07 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> > Package with good and bad images, scripts and ini-settings after moment in
> > povray.beta-test.binaries. Broken patterns are 4B, 7B, 12A, 15A and 16A.
> 
> Here it is.
> 

That's fairly simple, you used the pigments without a color map, therefore
the bozo ones use the default bozo colo map which is quite inappropriate
for wood.

For 15A and 16A this does not apply, but they look fairly normal to me.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[Rune] Re: Unsmooth smooth HF shading [8904 days 15 hours and 6 minutes ago]

Mon, 26 Nov 2001 20:58:16 GMT

Forgot to say - using P150 win95 beta 7
and POV-Ray 3.1 behaves the same way.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[Rune] Unsmooth smooth HF shading [8904 days 15 hours and 9 minutes ago]

Mon, 26 Nov 2001 20:55:01 GMT

I don't know if this is a bug or a limitation but the shading of
height-fields with abrupt changes is very ugly when smooth shading is turned
on. See attached image. Source code and height-field image are also
attached.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

[] Re: extended insert menu - november bonus pack (... [8905 days 3 hours and 13 minutes ago]

Mon, 26 Nov 2001 08:51:17 GMT

On Fri, 23 Nov 2001 21:09:45 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> Wow, did you do this completely by hand or do you have some automatism? 

Both. I've made lists by hand for povray script. Then runed script to create
files. And finally renumbered some files with 'Multi-raname tool' from Windows
Commander.

> If yes, this could be very useful for custom include files.

I plan to add bitmaps to it for color_maps, pigments, textures and shapes.
Here is example of script used to make it.

  #local Names=array[5]{
    "T_Brass_1A"
    "T_Brass_1B"
    "T_Brass_1C"
    "T_Brass_1D"
    "T_Brass_1E"
  }
  #local Counter=0;
  #while ( Counter<dimension_size(Names,1))
    #fopen File concat(
      "c:\\Program Files\\POV-Ray for Windows v3.5\\",
      "Insert Menu\\21 - Include files - keywords\\",
      "90 - 'metals.inc'",
      "\\",
      "30 - metals textures"
      "\\",Names[Counter],".txt"
    ) write
    #write(File,Names[Counter])
    #fclose File
    #local Counter=Counter+1;
  #end

> Only one inconsistency i recognized until now: The functions
> 'f_hetero_mf', 'f_ridged_mf' and 'f_ridge' should probably go to 'noise
> functions'.

I will change it and upload updated version after new beta  (I hope with some
bitmaps). Thanks.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[bob h] Re: Light_sources in light_groups don't cast sha... [8906 days 4 hours and 52 minutes ago]

Sun, 25 Nov 2001 07:12:33 GMT

"Mark Wagner" <mar### [at] gtenet> wrote in message
news:3c0086cf@news.povray.org...
> Bob H. wrote in message <3bffaaad@news.povray.org>...
>
> >; Sets minimum number of objects before auto bounding kicks in.
> >;
> >Bounding_Threshold = 6
>
> Try changing this to 0.  You've only got two objects in the scene, so
> bounding boxes are not used.  It might be a problem with the bounding box
> code.  Use (or non-use) of bounding boxes has been a cause of apparently
> platform-dependent behavior before.

That changed it alright, very curious.  So must be the bounding/light
buffer.  Too bad I don't know POV program source code to fix it myself.

I went from 0 up to 6 again and not until 6 did it have a shadow, also was
slower to render of course.  Guess I just happened to have that set to the
magic number for this particular example.  I'm supposing 4 letters plus a
torus counts as five things.

--
text{ttf"arial","bob h",.1,0pigment{rgb 9}translate<-1,-.2,3>}

[Mark Wagner] Re: Light_sources in light_groups don't cast sha... [8906 days 6 hours and 13 minutes ago]

Sun, 25 Nov 2001 05:51:11 GMT

Bob H. wrote in message <3bffaaad@news.povray.org>...

>; Sets minimum number of objects before auto bounding kicks in.
>;
>Bounding_Threshold = 6


Try changing this to 0.  You've only got two objects in the scene, so
bounding boxes are not used.  It might be a problem with the bounding box
code.  Use (or non-use) of bounding boxes has been a cause of apparently
platform-dependent behavior before.

--
Mark

[Bob H ] Re: Light_sources in light_groups don't cast sha... [8906 days 21 hours and 52 minutes ago]

Sat, 24 Nov 2001 14:11:57 GMT

"JRG" <jrg### [at] hotmailcom> wrote in message
news:3bffa960@news.povray.org...
> Or are you using any particular ini option?
> Perhaps posting your ini settings might be interesting.

No.  Just:

; Width of image in pixels.  Accepts integer values.
;
Width = 320
;
; Height of image in pixels.  Accepts integer values.
;
Height = 240
;
; File format to write render image to.
;
Output_File_Type=N
;
; File Output Buffer (amount to write to memory before writing to disk)
;
Buffer_Output=On
Buffer_Size=4096
;
; Sets minimum number of objects before auto bounding kicks in.
;
Bounding_Threshold = 6
;
; Turn display on
Display=On
Display_Gamma=2.3
;
; Turn verbose mode on
Verbose=On

And I tried bmp, tga, and png file outputs too, all same.  Didn't expect any
difference really.

bob h

[JRG] Re: Light_sources in light_groups don't cast sha... [8906 days 21 hours and 56 minutes ago]

Sat, 24 Nov 2001 14:08:39 GMT

I got it. -UL makes it work correctly. A bug indeed.

"Bob H." <omn### [at] msncom> ha scritto nel messaggio
news:3bffa88f$1@news.povray.org...
> Interesting because I see the shadowed result here (2nd image) without
> changing the scene.  (v3.5b7 on P3 WinXP)
>
> "JRG" <jrg### [at] hotmailcom> wrote in message
> news:3bffa40d@news.povray.org...
> > Read the same thread in beta.test for explanation.
> >
> > The first image shows the bug. The second one shows how it should look
(I
> > commented out the light_group).
>
>
>

[JRG] Re: Light_sources in light_groups don't cast sha... [8906 days 21 hours and 58 minutes ago]

Sat, 24 Nov 2001 14:06:24 GMT

Or are you using any particular ini option?
Perhaps posting your ini settings might be interesting.

"Bob H." <omn### [at] msncom> ha scritto nel messaggio
news:3bffa88f$1@news.povray.org...
> Interesting because I see the shadowed result here (2nd image) without
> changing the scene.  (v3.5b7 on P3 WinXP)
>
> "JRG" <jrg### [at] hotmailcom> wrote in message
> news:3bffa40d@news.povray.org...
> > Read the same thread in beta.test for explanation.
> >
> > The first image shows the bug. The second one shows how it should look
(I
> > commented out the light_group).
>
>
>

[JRG] Re: Light_sources in light_groups don't cast sha... [8906 days 22 hours ago]

Sat, 24 Nov 2001 14:04:21 GMT

Maybe it's due to the OS?

"Bob H." <omn### [at] msncom> ha scritto nel messaggio
news:3bffa88f$1@news.povray.org...
> Interesting because I see the shadowed result here (2nd image) without
> changing the scene.  (v3.5b7 on P3 WinXP)
>
> "JRG" <jrg### [at] hotmailcom> wrote in message
> news:3bffa40d@news.povray.org...
> > Read the same thread in beta.test for explanation.
> >
> > The first image shows the bug. The second one shows how it should look
(I
> > commented out the light_group).
>
>
>

[Bob H ] Re: Light_sources in light_groups don't cast sha... [8906 days 22 hours and 1 minute ago]

Sat, 24 Nov 2001 14:02:55 GMT

Interesting because I see the shadowed result here (2nd image) without
changing the scene.  (v3.5b7 on P3 WinXP)

"JRG" <jrg### [at] hotmailcom> wrote in message
news:3bffa40d@news.povray.org...
> Read the same thread in beta.test for explanation.
>
> The first image shows the bug. The second one shows how it should look (I
> commented out the light_group).

[JRG] Light_sources in light_groups don't cast shadows. [8906 days 22 hours and 21 minutes ago]

Sat, 24 Nov 2001 13:43:41 GMT

Read the same thread in beta.test for explanation.
This is the scene:
camera
{
  location  <0, 2, -4>
  look_at   <0, 0, 0>
}

light_group {
 light_source
 {
  <0, 5, -3>
  rgb 1
 }

 text {ttf "times.ttf" "TEXT" 1,0 pigment {rgb 1} translate <-1,1,-2>}
 torus {1.75,0.25 pigment {rgb 1}}
}

The first image shows the bug. The second one shows how it should look (I
commented out the light_group).


--
Jonathan.

[Christoph Hormann] Re: extended insert menu - november bonus pack (... [8907 days 15 hours and 55 minutes ago]

Fri, 23 Nov 2001 20:09:46 GMT

"W³odzimierz ABX Skiba" wrote:
> 
> Here is extended insert menu with almost all names from standard include files
> categorized by type. I prefer to upload this here becouse as base POV it will
> change follow next betas. I plan to add some bitmaps to this (textures, colors,
> shapes). Any typing erros? Any comments? Any suggestions for further
> categorization?
> 

Wow, did you do this completely by hand or do you have some automatism? 
If yes, this could be very useful for custom include files.

Only one inconsistency i recognized until now: The functions
'f_hetero_mf', 'f_ridged_mf' and 'f_ridge' should probably go to 'noise
functions'.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[] extended insert menu - november bonus pack (zip ... [8907 days 18 hours and 29 minutes ago]

Fri, 23 Nov 2001 17:34:58 GMT

Here is extended insert menu with almost all names from standard include files
categorized by type. I prefer to upload this here becouse as base POV it will
change follow next betas. I plan to add some bitmaps to this (textures, colors,
shapes). Any typing erros? Any comments? Any suggestions for further
categorization?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[Gilles Tran] Smooth mesh outline images [8913 days 21 hours and 14 minutes ago]

Sat, 17 Nov 2001 14:50:05 GMT

See related post in p.beta-test.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

[Zan Trajkov] Re: glass and radiosity [8915 days 19 hours and 43 minutes ago]

Thu, 15 Nov 2001 16:21:02 GMT

I understood every word too ... :-)
(no, i'm not of polish origin ....) ;-)

Peter Popov schrieb:
> 
> On Tue, 13 Nov 2001 17:39:30 +0100, W³odzimierz ABX Skiba
> <abx### [at] babilonorg> wrote:
> 
> >[ pozdrawiam, jest grupa (povray.international) na tym serwerze w której
mozesz
> >pisac po polsku :-) ]
> 
> Wow, I understood every word! :)
> 
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg

[Peter Popov] Re: glass and radiosity [8916 days 15 hours and 3 minutes ago]

Wed, 14 Nov 2001 21:00:50 GMT

On Wed, 14 Nov 2001 07:19:25 -0500, Francois Labreque
<fla### [at] videotronca> wrote:

>Those are words !!?!?!!?!?!!

Yes, here is what I think it says, word for word:

>>>[ pozdrawiam          , jest        grupa   (povray.international)
     I congratulate [you], [there] is  a group (povray.international)

>>> na tym  serwerze w  której mozesz  pisac po polsku :-) ]
    on this server   in which  you can write in Polish :-)

It sounds to me more like Russian than Bulgarian but I know some
Russian so... :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[Francois Labreque] Re: glass and radiosity [8916 days 23 hours and 39 minutes ago]

Wed, 14 Nov 2001 12:25:01 GMT

Peter Popov wrote:

> On Tue, 13 Nov 2001 17:39:30 +0100, W³odzimierz ABX Skiba
> <abx### [at] babilonorg> wrote:
> 
> 
>>[ pozdrawiam, jest grupa (povray.international) na tym serwerze w której mozesz
>>pisac po polsku :-) ]
>>
> 
> Wow, I understood every word! :)
> 

Those are words !!?!?!!?!?!!

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

[Peter Popov] Re: glass and radiosity [8917 days and 32 minutes ago]

Wed, 14 Nov 2001 11:32:40 GMT

On Tue, 13 Nov 2001 17:39:30 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:

>[ pozdrawiam, jest grupa (povray.international) na tym serwerze w której mozesz
>pisac po polsku :-) ]

Wow, I understood every word! :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[] Re: glass and radiosity [8917 days 18 hours and 52 minutes ago]

Tue, 13 Nov 2001 17:12:11 GMT

On Tue, 13 Nov 2001 17:41:43 +0100, "bARTek" <bro### [at] grafik3dpl> wrote:
> this is source of this scene.

as TonyB mentioned larger max_trace_level (i.e. 10) in global settings remove
dark parts.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[bARTek] Re: glass and radiosity [8917 days 19 hours and 19 minutes ago]

Tue, 13 Nov 2001 16:45:31 GMT

>
> > I have problem (black dots) with glass and radiosity.
> >    bARTek
>
> could you provide some source ?
>
> ABX
>
> [ pozdrawiam, jest grupa (povray.international) na tym serwerze w której
mozesz
> pisac po polsku :-) ]
this is source of this scene.

    bARTek

[] Re: glass and radiosity [8917 days 19 hours and 25 minutes ago]

Tue, 13 Nov 2001 16:39:41 GMT

On Tue, 13 Nov 2001 17:03:15 +0100, "bARTek" <bro### [at] grafik3dpl> wrote:

> I have problem (black dots) with glass and radiosity.
>    bARTek

could you provide some source ?

ABX

[ pozdrawiam, jest grupa (povray.international) na tym serwerze w której mozesz
pisac po polsku :-) ]
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

[Tony[B]] Re: glass and radiosity [8917 days 19 hours and 39 minutes ago]

Tue, 13 Nov 2001 16:25:23 GMT

It's not the glass, it's the reflection. Increase max_trace_level.

PS: I think we need to add some comment in the documentation about this.
It's practically a VFAQ.

[bARTek] glass and radiosity [8917 days 19 hours and 57 minutes ago]

Tue, 13 Nov 2001 16:07:08 GMT

I have problem (black dots) with glass and radiosity.
    bARTek

[Alex Falappa] Re: Alpha problems: text is not antialiased (100... [8919 days 1 hour and 45 minutes ago]

Mon, 12 Nov 2001 10:19:26 GMT

> These two images show the scene rendered and the preview with and without
> alpha-channel display on Macs.  The the thread in povray.beta-test for
> details.

I get the same results as Warp does, while I expected to see something like
yours.

Which antialias method have you used to produce these images?

Anyway it seems from the answers exchange between you and Warp in
povray.beta-test that there's something wrong and the problem is being
tackled on.
It seems I've made a useful bug report.

Keep up with your good work!

Alessandro

[Kevin Loney] max_trace_level problem (see p.b-t same subject) [8920 days 16 hours and 10 minutes ago]

Sat, 10 Nov 2001 19:54:26 GMT

balls1.pov:
    max_trace_level set to 512, crashes on run

balls2.pov
    max_trace_level at default, does not crash on run

in both cases radiosity is turned off

I did a seperate test with max_trace_level set to 256, and it was painfully
slow.

I'm running 850MHz athlon, 786Mg RAM with Win2K

--
Kevin
http://www.geocities.com/qsquared_1999/

[Dean] Re: another photon prob. - test2.jpg [1/1] [8921 days 16 hours and 11 minutes ago]

Fri, 9 Nov 2001 19:53:08 GMT

[Image]

[Thorsten Froehlich] Re: Alpha problems: text is not antialiased (100... [8922 days 15 hours and 43 minutes ago]

Thu, 8 Nov 2001 20:21:26 GMT

In article <3beadbc2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   This is a partial snapshot of the winpov preview window (which has been
> maximized to show the pixels more clearly). The behaviour is exactly the same
> as in the unix version.
>   And no, it's not something with the preview. When opening the image with
> another program (eg. Gimp), the result is identical to that.

I see.  I finally was able to reproduce your problem.  There is indeed
something very wrong with the alpha channel output.  The Mac version allows
to view the alpha channel even if POV-ray does not explicitly outout one.
When activating alpha channel output the whole output is suddenly screwed
up.  Obviously this is not right, so i can confirm this is a bug - alpha
channel output is completely broken.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[Warp] Re: Alpha problems: text is not antialiased (100... [8922 days 16 hours and 41 minutes ago]

Thu, 8 Nov 2001 19:23:46 GMT

This is a partial snapshot of the winpov preview window (which has been
maximized to show the pixels more clearly). The behaviour is exactly the same
as in the unix version.
  And no, it's not something with the preview. When opening the image with
another program (eg. Gimp), the result is identical to that.

[Thorsten Froehlich] Re: Alpha problems: text is not antialiased (100... [8922 days 18 hours and 53 minutes ago]

Thu, 8 Nov 2001 17:10:52 GMT

In article <3beaaf3a@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>  When I render the example scene without +ua, all parts of the the text is
> antialiased equally.
>   If I render it with +ua (and antialiasing method 1), then the part of the
> text which has only background behind it doesn't get antialiased (while the
> part which has the boxes behind does). The preview of POV-Ray shows clearly
> this and when I open the resulting image with Gimp, it is identical (that is,
> the edges really aren't antialiased in those parts).
>
>   I'm using the unix version (yes, it supports preview taking into account
> the alpha channel, as the Windows version does), but I suppose that the
Windows
> version works in the same way (I suppose that the original poster is using
> that).
>
>   However, I think the problem seems to be somewhere else. I tried putting
> another black object in the image (a cylinder) and it didn't get antialiased
in
> the lower half of the image either.
>   It seems to me that the color of the objects has something to do with this.
> If I make the cylinder and the text red, then they get antialiased.
>
>   Could it perhaps be that the antialiasing routine thinks that the background
> is black and thus doesn't perform antialiasing with black objects?
>   This is specially curious since the background is specifically set to white.
> Put perhaps the +ua has some effect here.
>   It's also curious why it works with +am2.

These two images show the scene rendered and the preview with and without
alpha-channel display on Macs.  The the thread in povray.beta-test for
details.

    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[Vampyrium] Animated textures [8923 days 2 hours and 1 minute ago]

Thu, 8 Nov 2001 10:02:51 GMT

[Mark Wagner] Bugs with string/macro handling [8925 days 8 hours ago]

Tue, 6 Nov 2001 04:04:29 GMT

See beta-test for error description.

--
Mark

[Lutz-Peter Hooge] another photon prob. - test2.jpg [1/1] [8925 days 15 hours and 57 minutes ago]

Mon, 5 Nov 2001 20:07:05 GMT

See my post in beta-test.binaries

[Nathan Kopp] Re: marble + turbulence [8927 days 10 hours and 36 minutes ago]

Sun, 4 Nov 2001 01:28:06 GMT

"ingo" <ing### [at] homenl> wrote...
>
[clipped]

Fixed for next beta.

-Nathan

[Bob H ] isosurface planets plus media atmospheres [300K ... [8928 days 22 hours and 31 minutes ago]

Fri, 2 Nov 2001 13:33:21 GMT

Noticed messages about isosurfaces in Beta 7 being slower than previously.
I haven't had much time for this stuff but I managed to get this set of
renders done, using the image maps I got through
http://apollo.spaceports.com/~jhasting/planets.html

Main reason for my posting this here is to point out the way a media sphere
over an isosurface sphere causes concentric circles aligned with the camera
location-look_at axis.  No doubt a increase in either media samples or iso
settings needed but as is this took over 12 hours to do.  When I have the
time I hope to find which setup works best.
What seems changed in this Beta 7 (not sure about previous few) is that the
default (no accuracy or max_gradient stated) setup of a spherical isosurface
doesn't have the concentric circles on the iso itself now, whereas before I
couldn't seem to get rid of it.  But like I say, I haven't been able to go
checking into it enough.  I did try max_trace and all_intersections at one
point.  It's just interesting how the iso affects a surrounding sphere of
media like this shows (Earth is only obvious one).

Sure would be great if the combination of these two features, iso's and
media's, could be sped up  :-)

Both things were vertically exaggerated, and the atmospheres could use some
changes.  The edges are overly bright and patterns aren't much good yet.
Oh, I better say what's what in this: starting top left is Mercury, Venus,
Earth; bottom left, Mars, Pluto, Moon.  You probably could figure most of
that anyway.

Bob H.
--
http://webpages.charter.net/omniverse/omniverse.htm

[Mike Williams] Re: marble + turbulence [8929 days 8 hours and 46 minutes ago]

Fri, 2 Nov 2001 03:18:32 GMT

Wasn't it Nathan Kopp who wrote:

>Is f_ridged_mf "correct' with noise 1 or with 2/3?  (i.e. does it need to be
>re-tweaked for noise 2 & 3)?

It looks to me like f_ridge, f_ridged_mf and f_hetero_mf did just get
tweaked in beta 7. They are a lot more rounded than they were in
previous betas.

-- 
Mike Williams
Gentleman of Leisure

[Nathan Kopp] Re: marble + turbulence [8929 days 8 hours and 48 minutes ago]

Fri, 2 Nov 2001 03:15:59 GMT

"Christoph Hormann" <chr### [at] gmxde> wrote ...
>
>
> RMF parameters are: 0.6, 2.2, 7, 0.7, 0.8
>
> What you can see is that apart from a range problem with all noise
> generators, there are small 'hills' in the lowest parts, with ng 1 they
> are extremely exaggerated.  Such hills can occur with certain parameters,
> but they should not with these.  See the results from other programs for
> comparison.

This looks like it might be a bug in RMF and not with the noise generators
themselves (well, except for NG1, which is way off).

-Nathan

[Christoph Hormann] Re: marble + turbulence [8930 days 3 hours and 38 minutes ago]

Thu, 1 Nov 2001 08:26:30 GMT

Nathan Kopp wrote:
> 
> Is f_ridged_mf "correct' with noise 1 or with 2/3?  (i.e. does it need to be
> re-tweaked for noise 2 & 3)?
> 

I think all versions of f_ridged_mf are somewhat wrong, see the following
pictures and histograms:

http://www.schunter.etc.tu-bs.de/~chris/files/RMF_noise1.png
http://www.schunter.etc.tu-bs.de/~chris/files/RMF_noise2.png
http://www.schunter.etc.tu-bs.de/~chris/files/RMF_noise3.png
http://www.schunter.etc.tu-bs.de/~chris/files/RMF_wilbur.png
http://www.schunter.etc.tu-bs.de/~chris/files/RMF_ategeros.png

http://www.schunter.etc.tu-bs.de/~chris/files/hist_noise1.png
http://www.schunter.etc.tu-bs.de/~chris/files/hist_noise2.png
http://www.schunter.etc.tu-bs.de/~chris/files/hist_noise3.png
http://www.schunter.etc.tu-bs.de/~chris/files/hist_wilbur.png
http://www.schunter.etc.tu-bs.de/~chris/files/hist_ategeros.png

RMF parameters are: 0.6, 2.2, 7, 0.7, 0.8

What you can see is that apart from a range problem with all noise
generators, there are small 'hills' in the lowest parts, with ng 1 they
are extremely exaggerated.  Such hills can occur with certain parameters,
but they should not with these.  See the results from other programs for
comparison.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[Nathan Kopp] Re: marble + turbulence [8930 days 7 hours and 13 minutes ago]

Thu, 1 Nov 2001 04:50:58 GMT

"ingo" <ing### [at] homenl> wrote...
>
> ---%<---%<---
> #version 3.5;
> global_settings {assumed_gamma 1.0 noise_generator 1}
> camera {location  <0, 0, -2.0> look_at 0}
>
[clip]

I can't duplicate this problem in my personal compile of 3.5 (which was
compiled from the latest sources)... hopefully it will be gone in the next
beta.

-Nathan

[Nathan Kopp] Re: marble + turbulence [8930 days 7 hours and 23 minutes ago]

Thu, 1 Nov 2001 04:41:33 GMT

"Christoph Hormann" <chr### [at] gmxde> wrote...
>
> For illustrating the other changes too:
>
> http://www.schunter.etc.tu-bs.de/~chris/files/noise_generator_beta6.png
> http://www.schunter.etc.tu-bs.de/~chris/files/noise_generator_beta7.png
>
> Also note that with 'gradient x triangle_wave' (which should look
> identically) the problem does not occur.

Thanks for this... it is great!

Is f_ridged_mf "correct' with noise 1 or with 2/3?  (i.e. does it need to be
re-tweaked for noise 2 & 3)?

-Nathan

[ingo] Re: marble + turbulence [8930 days 17 hours and 15 minutes ago]

Wed, 31 Oct 2001 18:48:48 GMT

in news:3BE036E1.3DF5C4DB@gmx.de Christoph Hormann wrote:

> http://www.schunter.etc.tu-bs.de/~chris/files/noise_generator_beta7.
> png 

When you put the turbulence inside a warp statement, the problem is 
gone. 
Also try octaves 4, it give a quite nice result actually.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[Christoph Hormann] Re: marble + turbulence [8930 days 18 hours and 27 minutes ago]

Wed, 31 Oct 2001 17:37:38 GMT

For illustrating the other changes too:

http://www.schunter.etc.tu-bs.de/~chris/files/noise_generator_beta6.png
http://www.schunter.etc.tu-bs.de/~chris/files/noise_generator_beta7.png

Also note that with 'gradient x triangle_wave' (which should look
identically) the problem does not occur.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[ingo] marble + turbulence [8931 days 4 hours and 50 minutes ago]

Wed, 31 Oct 2001 07:14:06 GMT

---%<---%<---
#version 3.5;
global_settings {assumed_gamma 1.0 noise_generator 1}
camera {location  <0, 0, -2.0> look_at 0}

plane {
   -z, 0
   texture {
      pigment {
         marble
         turbulence <0.1,0.1,0>
         //octaves 4
         colour_map {
            [0, rgb 0]
            [1, rgb 1]
         }
      }
      finish {ambient 1}
   }
}
---%<---%<---

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[ingo] Re: sphere_sweep bug [8931 days 22 hours and 26 minutes ago]

Tue, 30 Oct 2001 13:38:45 GMT

in news:3BDDF8FB.E69C4E54@usb.ve Alberto wrote:

> Mac OS 8.1 POV-Ray Beta 6 CarbonLib 1.0.3 
> Regards, Alberto.
> 
> //unexpected shape
> 

I can not reproduce this.
PII 233 192MB POV-Ray 3.5-b7

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

[Alberto] sphere_sweep bug [8932 days 11 hours and 19 minutes ago]

Tue, 30 Oct 2001 00:45:25 GMT

Here is the code and the image.

Mac OS 8.1 POV-Ray Beta 6 CarbonLib 1.0.3 
Regards, Alberto.

//unexpected shape

#default{pigment{rgb 1}}

camera{location <0,.1,-20> look_at 0 angle 60}
light_source{<0,.1,-20>  rgb 1 shadowless}
background{rgb<.9,.9,.95>}

sphere_sweep {
 catmull_rom_spline
  6,
  <-4, -5, 0>, 1
  <-5, -5, 0>, 1
  <-5,  5, 0>, 1
  < 5, -5, 0>, 1
  < 5,  5, 0>, 1
  < 4,  5, 0>, 1
  tolerance 1e-6 //.1
 }

[Christoph Hormann] Re: noise_generator histograms [8938 days 3 hours and 7 minutes ago]

Wed, 24 Oct 2001 08:57:25 GMT

Christoph Hormann wrote:
> 
> The structures in granite with noise_generator 3 are really quite obvious,
> In the other patterns they seem to be at least less clearly visible.
> 

In fact they are visible, here some detailed samples:

http://www.schunter.etc.tu-bs.de/~chris/files/wrinkles1.png
http://www.schunter.etc.tu-bs.de/~chris/files/wrinkles3.png
http://www.schunter.etc.tu-bs.de/~chris/files/dents1.png
http://www.schunter.etc.tu-bs.de/~chris/files/dents3.png
http://www.schunter.etc.tu-bs.de/~chris/files/granite1.png
http://www.schunter.etc.tu-bs.de/~chris/files/granite3.png

You can also recognize some star like structure around the origin in the
old noise generator.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[Christoph Hormann] Re: noise_generator histograms [8938 days 3 hours and 18 minutes ago]

Wed, 24 Oct 2001 08:46:30 GMT

Nathan Kopp wrote:
> 
> [...]
> 
> The other functions probably shouldn't be "re-tweaked" because it appears
> there is no tweaking in the current implementation and they are expecting
> plateau-free noise (which is produced by noise generators 2 and 3).
> 
> Re-tweaking is easy.  It is done by taking the output from the new Noise
> function, multiplying by 2 and subtracting 0.5.  Then clipping (to the
> interval [0,1]) is done if necessary.  I applied this method to granite to
> produce the attached results.
> 
> Attached is an image of the re-tweaked granite rendered using the three
> noise generators.  Note that noise_generator 1 has not changed and produces
> the old 3.1-style output perfectly.  It is interesting to note the clear
> patterns that emerge from noise_generator 3.  This seems to confirm some
> reports that noise_generator 3 doesn't seem to be very random.
> 

I made a another test image with various patterns involved:

http://www.schunter.etc.tu-bs.de/~chris/files/noise_generator_A.png

The structures in granite with noise_generator 3 are really quite obvious,
In the other patterns they seem to be at least less clearly visible.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

[Roy Schulz] Re: noise_generator histograms [8938 days 4 hours ago]

Wed, 24 Oct 2001 08:04:13 GMT

The noise you used is scaled too large to give correct histograms. To reduce
statistical errors a large area of noise has to be evaluated. Therefore a
scaled down noise should be rendered at high resolution.

Roy

[Mike Williams] Re: noise_generator histograms [8938 days 5 hours and 22 minutes ago]

Wed, 24 Oct 2001 06:41:48 GMT

Wasn't it Nathan Kopp who wrote:

> It is interesting to note the clear patterns that emerge from 
> noise_generator 3.  This seems to confirm some reports that 
> noise_generator 3 doesn't seem to be very random.

I'd noticed some subtler patterning in some of my own tests, but your
image shows it much more clearly.

It had been noted on another thread that noise_generator 3 produces non-
random results at integer positions. I guess that the grid pattern
visible in this image may be related to integer positions (possibly
scaled down by the code inside the granite pattern).

It looks to me like the stuff between the grid lines is nicely random,
but that the values returned from points on the grid are discontinuous
from the stuff between the lines. I thought that perlin noise was better
than that. Is it possible that there's a bug in the noise_generator 3
code when called for integer locations?

-- 
Mike Williams
Gentleman of Leisure

[Nathan Kopp] Re: noise_generator histograms [8938 days 8 hours and 29 minutes ago]

Wed, 24 Oct 2001 03:35:39 GMT

"Mike Williams" <mik### [at] nospamplease> wrote...
>
> If you're going to "fix" wrinkles, then I reckon that you should do
> "dents" as well.

A little clarity to the nose_generator issues:
Inside POV there are two types of noise: DNoise and Noise.  DNoise returns a
vector, Noise returns a scalar.  Noise is the one that is affected by the
noise_generator.  DNoise is not affected by the noise generator.

Noise (as opposed to DNoise) is used in the following places:
* Isosurface functions:
  - f_hetero_mf
  - f_ridge
  - f_ridged_mf
  - f_noise3d
  - f_noise_generator
* dents
  - When used as a NORMAL, a combination of Noise and
     DNoise is used
  - When used as a PATTERN, the output of dents is Noise^3 (cubed)
* wrinkles
  - When used as a NORMAL, Noise is NOT used.
  - When used as a PATTERN, the Noise function is called
     10 times, and the results are combined by addition.
* crackle solid
* granite
  - Noise is called 6 times in a loop, and the results
     are combined by addition.
* bozo, spotted, bumps patterns
  - bumps only when used as a PATTERN (when used
     as a NORMAL, it uses DNoise)
  - bozo, spotted, and bumps patterns are all direct
     calls to Noise.
* Turbulence (but not DTurbulence)

Note that only the pattern (pigment) versions bumps and wrinkles are
affected.  The normal versions of these functions are not affected

Some patterns appear to have been "tweaked" to use the strange distribution
pattern of the old Noise function.  Such patterns could thus use a
"re-tweaking" so that they work well under all three noise generators.
Those patterns are:
* wrinkles as a pigment
* granite
* possibly dents

Note: Turbulence has already been "re-tweaked" (though there is a bug in the
re-tweaking that needed to be fixed).

The other functions probably shouldn't be "re-tweaked" because it appears
there is no tweaking in the current implementation and they are expecting
plateau-free noise (which is produced by noise generators 2 and 3).

Re-tweaking is easy.  It is done by taking the output from the new Noise
function, multiplying by 2 and subtracting 0.5.  Then clipping (to the
interval [0,1]) is done if necessary.  I applied this method to granite to
produce the attached results.

Attached is an image of the re-tweaked granite rendered using the three
noise generators.  Note that noise_generator 1 has not changed and produces
the old 3.1-style output perfectly.  It is interesting to note the clear
patterns that emerge from noise_generator 3.  This seems to confirm some
reports that noise_generator 3 doesn't seem to be very random.

-Nathan

[Philippe Debar] Strange errors with incorrect array declarations [8938 days 12 hours and 41 minutes ago]

Tue, 23 Oct 2001 23:23:40 GMT

Sometimes I write really dumb things. I know this code should not work. But
pov's behavior is rather unexpected. The attached file is rather
self-explainatory : a switch to test different behavior, very simple (and
very wrong) code and the copy of the errors I got.


Povingly,

Philippe

[Bob H ] Re: noise_generator histograms [8938 days 17 hours and 48 minutes ago]

Tue, 23 Oct 2001 18:16:00 GMT

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3BD56A04.E20EC0F9@pacbell.net...
>
>
> It seems to me it is a hand full of advanced users that are worried
> which default will be used (more for their own selfish reasons) than
> for concern about new users :)

I'd prefer it being the new "fixed" way by default.  This might be a good
reason, advanced versus new users, since people familiar with the program
can easily change it where applicable.  Only thing that hampers this idea is
when new people use old scene files, that would be the primary concern here.
But like I said, noise_generator 3 would be my choice.  Or beyond that,
anything else which is the better overall if it is ever changed before
POV-Ray v3.5 is final.

Bob H.

[Mike Williams] Re: noise_generator histograms [8938 days 18 hours and 19 minutes ago]

Tue, 23 Oct 2001 17:44:56 GMT

Wasn't it Nathan Kopp who wrote:
>
>"ingo" <ing### [at] homenl> wrote...
>> Histograms of the different noise_generators, one with the granite
>> pigment, the other with pigment{function{f_noise3d}}. Images rendered
>> to gamma=1.
>>  Maybe usefull in the docs, section "6.7.12.4".
>
>Actually, I was planning to fix the granite pattern so that it produces
>similar results for all three noise generators.  Any comments?  Also, would
>the wrinkles pattern need to be "fixed" too?

If you're going to "fix" wrinkles, then I reckon that you should do
"dents" as well.

There seem to be four groups of patterns to consider:-

Granite: Considerably different in a way that visibly alters existing
textures.

Dents and Wrinkles: Considerably different, but since they're mainly
used for normals the effect is far less noticeable.

Bozo and Bumps: Considerably different, but the point of the new noise
generators was to fix the existing plateaux problem with these patterns.

Everything else: Not affected.

-- 
Mike Williams
Gentleman of Leisure

[Tom Melly] mesh bug [8938 days 20 hours and 9 minutes ago]

Tue, 23 Oct 2001 15:55:21 GMT

Here are the first and 3rd renders as reported to beta (for some reason
render 2 was also okay - the problem didn't appear until render 3)

No code was changed between renders.