povray.object-collection message digest

[Cousin Ricky] MakeSpectrum 1.2 beta [98 days 2 hours and 44 minutes ago]

Tue, 30 Dec 2025 02:04:29 GMT

I recently started on spectral rendering fan art of one of Trevor G
Quayle's images, and decided I wanted a brighter red than I could get
with MakeSpectrum's "natural" spectral curves.

I decided to tag this update to MakeSpectrum as version 1.2, even though
v1.1 was still in the release candidate stage.  But while reworking the
blue-to-red hues, I discovered that the code for the purples reflected
some outdated pre-1.0 trials that I had somehow skipped updating before
releasing v1.0.  So I made that correction in v1.1, and called that the
final release.

Meanwhile, I figured working on two versions simultaneously would be a
good opportunity to familiarize myself with git branches and pull
requests.  (As you may recall, battling the git learning curve has been
like scaling Yosemite's El Capitan for me.)  So far, I haven't trashed
the repository.  Version 1.2 is in beta at:

https://github.com/CousinRicky/POV-MakeSpectrum/releases/tag/v1.2-beta.1

[Cousin Ricky] Re: My contributions: October 2025 update [131 days 9 hours and 3 minutes ago]

Wed, 26 Nov 2025 19:46:11 GMT

On 2025-10-13 15:18 (-4), Cousin Ricky wrote:
> 
> ScaryCoronaVirus has links to the Centers for Disease Control and
> Prevention (CDC).  As the CDC is now being run by a lunatic, I have
> added an early January link from the Wayback Machine.

It's gotten even worse since last month, so I have outright deleted the
CDC link.  The CDC's virion illustration remains, accompanied by a
Wayback link.

https://github.com/CousinRicky/POV-ScaryCoronavirus/releases/tag/v1.0c-rc.2

[Cousin Ricky] Re: Rope_Sys issue [147 days and 23 minutes ago]

Tue, 11 Nov 2025 04:25:54 GMT

On 2025-11-06 16:54 (-4), Chris R wrote:
> 
> I don't know if this code is being maintained in GitHub or if the library comes
> back alive if there is a way to patch it.  It's not a huge deal, it just always
> bothered me that I couldn't use Rope_ArrayToRope if I wanted anything other than
> a natural spline.
> -- Chris R.

The only GitHub incarnation I know of is at Le Forgeron's mirror of the
Object Collection, and no maintenance is done there other than
occasional scanning of lib.povray.org for updates.

The Object Collection was intended for libraries to be patched.  The
LGPL license allows you to make changes so long as you document the
changes with your name and date.  You can post your changes here or on
your own GitHub account, and when the Object Collection returns online,
upload it there as a modification to the existing contribution.

[jr] Re: Rope_Sys issue [151 days 6 hours and 29 minutes ago]

Thu, 6 Nov 2025 22:20:00 GMT

hi,

"Chris R" <car### [at] comcastnet> wrote:
> I have used Chris Bartlett's rope_sys.inc object collection for several years,
> and just discovered a subtle bug in the code.
> ...
> I don't know if this code is being maintained in GitHub or if the library comes
> back alive if there is a way to patch it.

no idea re "github".  the object collection work has been sidelined this year,
due to (quoting Churchill) "events dear boy, events".  a (corrected) version 1.1
(?) could be one of the first to add when it (OC) gets finished.  (tia :-))

regards, jr.

[Chris R] Rope_Sys issue [151 days 7 hours and 54 minutes ago]

Thu, 6 Nov 2025 20:55:00 GMT

I have used Chris Bartlett's rope_sys.inc object collection for several years,
and just discovered a subtle bug in the code.

I usually create ropes using the Rope_Array related macros, and then call
Rope_ArrayToSpline or Rope_ArrayToRope.  I was playing with the Rope_BreakSpline
macro so I could have a linear section of the rope followed by a natural spline
section.

The first thing I realized was that calling Rope_BreakSpline() sets the spline
type for the segment of the rope following that call.  You can get around this
to set the spline type of the first segment by calling Rope_BreakSpline
immediately after calling the first Rope_AddPoint()

In my test, I just did that:

Rope_AddPoint(MyPoint1)
Rope_BreakSpline("linear_spline")
Rope_AddPoint(MyPoint2)
Rope_AddPoint(MyPoint3)
Rope_ArrayToRope("")

However, the resulting rope used a natural spline.  I looked at the code for
Rope_ArrayToRope and discovered that there is a check for the number of spline
breaks found to be < 2.  If so, it calls Rope_ArrayToSpline("") which uses the
default natural spline, and then calls Rope() on the resulting single spline,
completely ignoring my first Rope_BreakSpline("linear_spline")

I edited my code to make the check < 1, forcing it to look at that first
Rope_BreakSpline and create a spline using that spline type and now it works.

If I had actually added some additional points and called Rope_BreakSpline() a
second time, the code would have worked as written.

I don't know if this code is being maintained in GitHub or if the library comes
back alive if there is a way to patch it.  It's not a huge deal, it just always
bothered me that I couldn't use Rope_ArrayToRope if I wanted anything other than
a natural spline.
-- Chris R.

[Bald Eagle] Re: Bubble 4.0.1 [159 days 10 hours and 59 minutes ago]

Wed, 29 Oct 2025 17:50:00 GMT

Yep.  Trying to get AI to churn out the large majority of the code.

If most of your errors are undeclared identifiers, that's usually because it's
trying to supply a name for the output of a macro, like in c++.

I usually just declare a dummy identifier of that type, but I'm assuming that
you can just delete that identifier from the macro call.

I'll try to get it to stop doing that.

However, I figure that it will at least give people good ideas for creating a
properly coded macro, which makes for a fast entry point for a solution.

- BE

[Leroy] Re: Bubble 4.0.1 [159 days 11 hours and 4 minutes ago]

Wed, 29 Oct 2025 17:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> #declare S_G=9.81; #declare S_RHO_L=1000; #declare S_MU_L=1e-3; #declare
> S_P_SURF=101325; #declare S_H_LIQ=0.30;
> #declare S_LIQUID_LEVEL=0.0;
> #declare OBJECT_CONTAINER = cylinder { <0,-S_H_LIQ,0>, <0,0.02,0>, 0.06 }
> #declare OBJECT_LIQUID = intersection { object{OBJECT_CONTAINER} plane{
> y,S_LIQUID_LEVEL } inverse }
> #declare S_PRESSURE = function(Y){ S_P_SURF + S_RHO_L*S_G*(0 - Y) }
> #declare S_RADIUS_BY_Y=function(R0,Y){ R0*pow(S_P_SURF/S_PRESSURE(Y),1/3) }
> #declare S_CLAMP=function(X,A,B){ min(max(X,A),B) }
> #declare S_CD=function(RE){
>   #local REp=max(RE,1e-6);
>   #local CD_st=24/REp; #local
> t=S_CLAMP((log(REp)-log(1))/(log(200)-log(1)),0,1);
>   (1-t)*CD_st + t*0.44
> }
> #declare S_VTERM=function(R,CD){ sqrt((8/3)*R*S_G/max(CD,1e-6)) }
> #declare S_TAU=function(R,CD){ (4/3)*R/(max(CD,1e-6)*max(S_VTERM(R,CD),1e-6)) }
> #declare S_WOBBLE_AMP=function(R,VT){ 0.5*R*(1-exp(-VT/0.15)) }
> #declare S_WOBBLE_FREQ=function(R,VT){ 0.25*VT/max(R,1e-6) }
> #macro M_RSEED(SEED) #local _r=seed(SEED); _r #end
> #macro M_RAND01(RS) #local _x=rand(RS); _x #end
> #macro M_BUBBLE_RECORD(V_ORIGIN,S_R0,S_TBIRTH,S_SEED)
>   #local RS=M_RSEED(S_SEED);
>   #local XPH=2*pi*M_RAND01(RS); #local ZPH=2*pi*M_RAND01(RS);
>   #local WXY=0.4+0.6*M_RAND01(RS); #local HUE=M_RAND01(RS);
>   array[8]{ V_ORIGIN,S_R0,S_TBIRTH,S_SEED,XPH,ZPH,WXY,HUE }
> #end
> #macro M_BUBBLE_OBJECT(REC,S_TLOCAL,OBJECT_OUT)
>   #local V_O=REC[0]; #local R0=REC[1]; #local TB=REC[2]; #local SEED=REC[3];
>   #local XPH=REC[4]; #local ZPH=REC[5]; #local WXY=REC[6];
>   #local TL=S_TLOCAL; #if (TL<0) #declare OBJECT_OUT=object{sphere{<0,0,0>,0}
> no_shadow}; #else
>     #local CD0=S_CD(100); #local VT0=S_VTERM(R0,CD0); #local TAU0=S_TAU(R0,CD0);
>     #local dY1=VT0*(TL - TAU0*(1-exp(-TL/TAU0))); #local Y1=V_O.y+dY1;
>     #local R1=S_RADIUS_BY_Y(R0,Y1); #local CD1=S_CD( max(
> (2*R1)*VT0*S_RHO_L/S_MU_L,1) );
>     #local VT1=S_VTERM(R1,CD1); #local TAU1=S_TAU(R1,CD1);
>     #local dY=VT1*(TL - TAU1*(1-exp(-TL/TAU1))); #local YY=V_O.y+dY; #local
> RR=S_RADIUS_BY_Y(R0,YY);
>     #local AMP=S_WOBBLE_AMP(RR,VT1); #local F=S_WOBBLE_FREQ(RR,VT1);
>     #local X=V_O.x + AMP*WXY*sin(2*pi*F*TL+XPH);
>     #local Z=V_O.z + AMP     *cos(2*pi*F*TL+ZPH);
>     #declare OBJECT_OUT = object{ sphere{ <X,YY,Z>, RR } texture{ pigment{ rgbt
> <1,1,1,1> } finish{ ambient 0 diffuse 0 } } interior{ ior 1.0 } no_shadow };
>   #end
> #end
> #macro
> M_BUBBLE_SYSTEM(S_N,V_BASE,S_BAND_R,S_RMIN,S_RMAX,S_TMIN,S_TMAX,S_SEED0,ARR_OUT)
>   #local RSYS=M_RSEED(S_SEED0); #local A=array[S_N]; #local I=0; #while(I<S_N)
>     #local ang=2*pi*M_RAND01(RSYS); #local rad=S_BAND_R*sqrt(M_RAND01(RSYS));
>     #local x=V_BASE.x+rad*cos(ang); #local z=V_BASE.z+rad*sin(ang); #local
> y=V_BASE.y;
>     #local r0=S_RMIN+(S_RMAX-S_RMIN)*M_RAND01(RSYS);
>     #local tb=S_TMIN+(S_TMAX-S_TMIN)*M_RAND01(RSYS);
>     #local sd=int(1e6*M_RAND01(RSYS)); #local
> rec=M_BUBBLE_RECORD(<x,y,z>,r0,tb,sd); #local A[I]=rec; #local I=I+1; #end
>   #declare ARR_OUT=A;
> #end
> #macro M_DRAW_BUBBLES(ARR,S_TGLOBAL)
>   #local N=dimension_size(ARR,1); #local i=0; #while(i<N)
>     #local REC=ARR[i]; #local TL=S_TGLOBAL-REC[2]; #local
> OBJ=object{sphere{<0,0,0>,0}}; M_BUBBLE_OBJECT(REC,TL,OBJ) object{OBJ}
>     #local i=i+1; #end
> #end

What is this?
Is it made using one of your fancy new tools to generate it?
I played around with it some and it has lots of errors and no comments.

Have Fun!

[Bald Eagle] Re: Bubble 4.0.1 [160 days 16 hours and 9 minutes ago]

Tue, 28 Oct 2025 12:40:00 GMT

// BUBBLE_RISE.inc — simplified excerpt from conversation
#declare S_G=9.81; #declare S_RHO_L=1000; #declare S_MU_L=1e-3; #declare
S_P_SURF=101325; #declare S_H_LIQ=0.30;
#declare S_LIQUID_LEVEL=0.0;
#declare OBJECT_CONTAINER = cylinder { <0,-S_H_LIQ,0>, <0,0.02,0>, 0.06 }
#declare OBJECT_LIQUID = intersection { object{OBJECT_CONTAINER} plane{
y,S_LIQUID_LEVEL } inverse }
#declare S_PRESSURE = function(Y){ S_P_SURF + S_RHO_L*S_G*(0 - Y) }
#declare S_RADIUS_BY_Y=function(R0,Y){ R0*pow(S_P_SURF/S_PRESSURE(Y),1/3) }
#declare S_CLAMP=function(X,A,B){ min(max(X,A),B) }
#declare S_CD=function(RE){
  #local REp=max(RE,1e-6);
  #local CD_st=24/REp; #local
t=S_CLAMP((log(REp)-log(1))/(log(200)-log(1)),0,1);
  (1-t)*CD_st + t*0.44
}
#declare S_VTERM=function(R,CD){ sqrt((8/3)*R*S_G/max(CD,1e-6)) }
#declare S_TAU=function(R,CD){ (4/3)*R/(max(CD,1e-6)*max(S_VTERM(R,CD),1e-6)) }
#declare S_WOBBLE_AMP=function(R,VT){ 0.5*R*(1-exp(-VT/0.15)) }
#declare S_WOBBLE_FREQ=function(R,VT){ 0.25*VT/max(R,1e-6) }
#macro M_RSEED(SEED) #local _r=seed(SEED); _r #end
#macro M_RAND01(RS) #local _x=rand(RS); _x #end
#macro M_BUBBLE_RECORD(V_ORIGIN,S_R0,S_TBIRTH,S_SEED)
  #local RS=M_RSEED(S_SEED);
  #local XPH=2*pi*M_RAND01(RS); #local ZPH=2*pi*M_RAND01(RS);
  #local WXY=0.4+0.6*M_RAND01(RS); #local HUE=M_RAND01(RS);
  array[8]{ V_ORIGIN,S_R0,S_TBIRTH,S_SEED,XPH,ZPH,WXY,HUE }
#end
#macro M_BUBBLE_OBJECT(REC,S_TLOCAL,OBJECT_OUT)
  #local V_O=REC[0]; #local R0=REC[1]; #local TB=REC[2]; #local SEED=REC[3];
  #local XPH=REC[4]; #local ZPH=REC[5]; #local WXY=REC[6];
  #local TL=S_TLOCAL; #if (TL<0) #declare OBJECT_OUT=object{sphere{<0,0,0>,0}
no_shadow}; #else
    #local CD0=S_CD(100); #local VT0=S_VTERM(R0,CD0); #local TAU0=S_TAU(R0,CD0);
    #local dY1=VT0*(TL - TAU0*(1-exp(-TL/TAU0))); #local Y1=V_O.y+dY1;
    #local R1=S_RADIUS_BY_Y(R0,Y1); #local CD1=S_CD( max(
(2*R1)*VT0*S_RHO_L/S_MU_L,1) );
    #local VT1=S_VTERM(R1,CD1); #local TAU1=S_TAU(R1,CD1);
    #local dY=VT1*(TL - TAU1*(1-exp(-TL/TAU1))); #local YY=V_O.y+dY; #local
RR=S_RADIUS_BY_Y(R0,YY);
    #local AMP=S_WOBBLE_AMP(RR,VT1); #local F=S_WOBBLE_FREQ(RR,VT1);
    #local X=V_O.x + AMP*WXY*sin(2*pi*F*TL+XPH);
    #local Z=V_O.z + AMP     *cos(2*pi*F*TL+ZPH);
    #declare OBJECT_OUT = object{ sphere{ <X,YY,Z>, RR } texture{ pigment{ rgbt
<1,1,1,1> } finish{ ambient 0 diffuse 0 } } interior{ ior 1.0 } no_shadow };
  #end
#end
#macro
M_BUBBLE_SYSTEM(S_N,V_BASE,S_BAND_R,S_RMIN,S_RMAX,S_TMIN,S_TMAX,S_SEED0,ARR_OUT)
  #local RSYS=M_RSEED(S_SEED0); #local A=array[S_N]; #local I=0; #while(I<S_N)
    #local ang=2*pi*M_RAND01(RSYS); #local rad=S_BAND_R*sqrt(M_RAND01(RSYS));
    #local x=V_BASE.x+rad*cos(ang); #local z=V_BASE.z+rad*sin(ang); #local
y=V_BASE.y;
    #local r0=S_RMIN+(S_RMAX-S_RMIN)*M_RAND01(RSYS);
    #local tb=S_TMIN+(S_TMAX-S_TMIN)*M_RAND01(RSYS);
    #local sd=int(1e6*M_RAND01(RSYS)); #local
rec=M_BUBBLE_RECORD(<x,y,z>,r0,tb,sd); #local A[I]=rec; #local I=I+1; #end
  #declare ARR_OUT=A;
#end
#macro M_DRAW_BUBBLES(ARR,S_TGLOBAL)
  #local N=dimension_size(ARR,1); #local i=0; #while(i<N)
    #local REC=ARR[i]; #local TL=S_TGLOBAL-REC[2]; #local
OBJ=object{sphere{<0,0,0>,0}}; M_BUBBLE_OBJECT(REC,TL,OBJ) object{OBJ}
    #local i=i+1; #end
#end

[Bald Eagle] Re: Bubble 4.0.1 [161 days 4 hours and 49 minutes ago]

Tue, 28 Oct 2025 00:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> Clearly Mr. Robertson did not write this with animation in mind.
>
> I have been hesitant to critique the code, not for its age, but because,
> hey, I'm glad he contributed it, and I don't want to denigrate his
> efforts.  But yeah, the code is a hot mess.

We've all written craptastic code at one time or another.
It's publicly posted - it's open to critique.

I like the results you posted, and I think that like many little projects that
people have undertaken over the years, we can celebrate it as an introductory
approach to the topic, and an inspiration to others in future years.

That said, bad code deserves to be rewritten.

If I was Robertson, and visited our little corner of the internet at some time
in the future, I'd be delighted to see that someone was interested enough to
take up the torch and really make it do what I originally set out to accomplish.

Then i could play with it, enjoy the results, and have a grand old time playing
with all of the new features and effects.

- BW

[Cousin Ricky] Re: Bubble 4.0.1 [161 days 5 hours and 17 minutes ago]

Mon, 27 Oct 2025 23:31:31 GMT

On 2025-10-27 11:55 (-4), Leroy wrote:
>
>  I do a lot of animations and it looks like a lot of work to get this code to
> produce something 'Real'. Maybe Rune's Particle System would do a better job.
> As for the code itself, I hate to critique code that's over 15 years old, So I
> wont!

Clearly Mr. Robertson did not write this with animation in mind.

I have been hesitant to critique the code, not for its age, but because,
hey, I'm glad he contributed it, and I don't want to denigrate his
efforts.  But yeah, the code is a hot mess.

[Cousin Ricky] Re: Bubble 4.0.1 [161 days 6 hours and 8 minutes ago]

Mon, 27 Oct 2025 22:41:00 GMT

On 2025-10-26 13:07 (-4), Bald Eagle wrote:
> 
> It looks like he just didn't do a very good job of making the correction.

He didn't even do a good job prior to the "corrections."  His
randomization code yields columns in a box, not a cylinder.  I haven't
bothered to correct that.

> However, perhaps you should <snip>

I'm only tweaking this library because it was already there.  I'm not
going to try to overhaul this thing; to get some comprehensive
improvement, I think it would be better to start a new library from
scratch (which you already seem to be doing).

> The size of a bubble is related to the pressure exerted on it.
> Fluid pressure is dependent solely on the height of the column of liquid.

Does atmospheric pressure figure into this?  Should we pretend that
thereâ€™s an additional 14.7 psi worth of liquid on top?  Or does that
cancel out somehow?

> So you should start with a bubble of some initial size, and then adjust the
> VOLUME of the bubble in a linear fashion as it rises.
> P1V1 = P2V2

For a carbonated beverage, that's not the whole story.  The bubble
absorbs additional CO2 as it rises, which is why my default is greater
than 1/3.

[Bald Eagle] Re: Bubble 4.0.1 [161 days 11 hours and 24 minutes ago]

Mon, 27 Oct 2025 17:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
I have access to a better version, ....

#version 3.7;
#include "colors.inc"
#include "BUBBLE_RISE.inc"   // <-- paste the include above or #include the file

global_settings { assumed_gamma 1 }
background { rgb <0.95,0.97,1.0> }

camera {
  location <0, 0.12, -0.40>
  look_at  <0, -0.05,  0.0>
  right x*image_width/image_height angle 40
}
light_source { <0.3,0.5,-0.5> rgb 1 }
light_source { <-0.5,0.6,0.6> rgb <1,0.95,0.9> }

// Glass container from the include
object { OBJECT_CONTAINER texture { pigment { rgbt <1,1,1,0.95> } finish {
specular .6 roughness .005 } } }

// (Optional) visual liquid body (for shading reference)
object { OBJECT_LIQUID texture { pigment { color rgbf <0.2,0.4,0.6,0.75> }
finish { diffuse 0.6 specular 0.1 } } }

// Spawn bubbles near bottom center
#declare A_BUBBLES = array[0];
M_BUBBLE_SYSTEM(
  120,                  // count
  <0, -S_H_LIQ+0.01, 0>,// base origin (just above bottom)
  0.01,                 // band radius (m)
  0.0015, 0.0035,       // R0 range: 1.5..3.5 mm
  0.00, 0.90,           // birth time window in normalized clock
  12345,                // system seed
  A_BUBBLES
)

// Draw all bubbles for current clock
M_DRAW_BUBBLES(A_BUBBLES, clock)




Minimal scene:

#version 3.7;
#include "colors.inc"
#include "BUBBLE_RISE.inc"   // <-- paste the include above or #include the file

global_settings { assumed_gamma 1 }
background { rgb <0.95,0.97,1.0> }

camera {
  location <0, 0.12, -0.40>
  look_at  <0, -0.05,  0.0>
  right x*image_width/image_height angle 40
}
light_source { <0.3,0.5,-0.5> rgb 1 }
light_source { <-0.5,0.6,0.6> rgb <1,0.95,0.9> }

// Glass container from the include
object { OBJECT_CONTAINER texture { pigment { rgbt <1,1,1,0.95> } finish {
specular .6 roughness .005 } } }

// (Optional) visual liquid body (for shading reference)
object { OBJECT_LIQUID texture { pigment { color rgbf <0.2,0.4,0.6,0.75> }
finish { diffuse 0.6 specular 0.1 } } }

// Spawn bubbles near bottom center
#declare A_BUBBLES = array[0];
M_BUBBLE_SYSTEM(
  120,                  // count
  <0, -S_H_LIQ+0.01, 0>,// base origin (just above bottom)
  0.01,                 // band radius (m)
  0.0015, 0.0035,       // R0 range: 1.5..3.5 mm
  0.00, 0.90,           // birth time window in normalized clock
  12345,                // system seed
  A_BUBBLES
)

// Draw all bubbles for current clock
M_DRAW_BUBBLES(A_BUBBLES, clock)



..ini file for animation:



Input_File_Name=your_scene.pov
Initial_Frame=1
Final_Frame=240
Initial_Clock=0
Final_Clock=1
Cyclic_Animation=off
Pause_When_Done=off
; width/height of your choice
+W1920 +H1080



Why this looks physically right (and how to tune)

Rise speed comes from buoyancy/drag; the simple CDC_DCD blend works
across most of your small bubble sizes. For clean water (low surfactant), path
instability appears for millimetric bubbles; that’s why the wobble scales with
vt/Rv_t/Rvt/R. Tune S_WOBBLE_KA and S_WOBBLE_KF to match your eye/test
footage. [wseas.us], [mdpi.com]
Depth growth by Boyle’s law gives the classic “bubbles get larger as they
rise”
look. If your liquid is carbonated or degassing, you can also bias R0 upward
with time or introduce rare coalescence events (merge two records) for extra
realism. (Coalescence physics depends on surfactants; see review.) [mdpi.com]
Any container: because you supply OBJECT_LIQUID, this works for cylinder,
beaker, intricate glass—anything you can model as a closed manifold. If you want
wall bounces, enable a trace test and reflect/damp the bubble’s lateral motion
when distance_to_wall < R. The POV‑Wiki’s “Trace macro” explains
using ray
intersections conceptually (the built‑in trace() call follows the same
idea). [wiki.povray.org]


Notes, references & further upgrades

If you want closer adherence to fluid literature, swap S_CD() for a Tomiyama
drag (or Clift‑Grace‑Weber) correlation and add a lift correction
near walls; Tomiyama’s review gives CD/CL vs. Re and Eötvös along with
terminal‑velocity models for prolate/oblate bubbles. [hzdr.de]

"If you want, I can integrate true wall collisions (using trace() and
per‑bubble lateral velocity state) and push this into a namespaced
OC‑style module with your naming rules (BUBBLE_RISE_2D/3D) so it’s
plug‑and‑play across your projects."

Just to give you the flavor of how far we could potentially go with this ...

- BE

[Leroy] Re: Bubble 4.0.1 [161 days 12 hours and 49 minutes ago]

Mon, 27 Oct 2025 16:00:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> Bubble version 4.0.1:
>
>   https://github.com/CousinRicky/POV-bubble/releases/tag/v4.0.1

I just went through the code. I was wondering why he used a cylinder to bound a
bubble when a cone would be better. Using Bald Eagle's equation a cone could be
made to size a bubble along the height rather easy.
 I do a lot of animations and it looks like a lot of work to get this code to
produce something 'Real'. Maybe Rune's Particle System would do a better job.
As for the code itself, I hate to critique code that's over 15 years old, So I
wont!

Have Fun!

[Bald Eagle] Re: Bubble 4.0.1 [162 days 11 hours and 24 minutes ago]

Sun, 26 Oct 2025 17:25:00 GMT

I used one of those fancy new tools to generate some starter code.

I think creating a liquid object and then using insidedness tests would be the
way to go.  Maybe define a central axis to correct everything towards - that
would even work with a tilted container.

#macro Bubble(id, startX, startZ, startY, radius, fluidMinX, fluidMaxX,
fluidMinZ, fluidMaxZ, fluidSurfaceY)
  // Rise speed based on radius
  #local riseSpeed = radius * 2;

  // Vertical position based on clock
  #local currentY = startY + (clock * riseSpeed);
  #if (currentY > fluidSurfaceY)
    #local currentY = fluidSurfaceY;
  #end

  // Expansion as bubble rises
  #local scaleFactor = 1 + (currentY - startY) / (fluidSurfaceY - startY) * 0.2;
  #local currentRadius = radius * scaleFactor;

  // Turbulence: horizontal wobble using sine waves
  #local wobbleX = sin(clock * 10 + id) * 0.2;
  #local wobbleZ = cos(clock * 10 + id) * 0.2;

  // Apply turbulence to position
  #local posX = startX + wobbleX;
  #local posZ = startZ + wobbleZ;

  // Clamp to container bounds
  #if (posX < fluidMinX + currentRadius)
    #local posX = fluidMinX + currentRadius;
  #end
  #if (posX > fluidMaxX - currentRadius)
    #local posX = fluidMaxX - currentRadius;
  #end
  #if (posZ < fluidMinZ + currentRadius)
    #local posZ = fluidMinZ + currentRadius;
  #end
  #if (posZ > fluidMaxZ - currentRadius)
    #local posZ = fluidMaxZ - currentRadius;
  #end

  // Create the bubble
  sphere {
    <posX, currentY, posZ>, currentRadius
    texture {
      pigment { color rgbt <1, 1, 1, 0.9> }
      finish { specular 0.6 reflection 0.1 }
    }
    interior { ior 1.0 }
  }
#end



#declare fluidMinX = -2;
#declare fluidMaxX = 2;
#declare fluidMinZ = -2;
#declare fluidMaxZ = 2;
#declare fluidSurfaceY = 10;
#declare bubbleCount = 10;

#declare i = 0;
#while (i < bubbleCount)
  #declare startX = RRand(fluidMinX + 0.3, fluidMaxX - 0.3, i);
  #declare startZ = RRand(fluidMinZ + 0.3, fluidMaxZ - 0.3, i + 100);
  #declare startY = RRand(0.5, 2.0, i + 200);
  #declare radius = RRand(0.1, 0.3, i + 300);

  Bubble(i, startX, startZ, startY, radius, fluidMinX, fluidMaxX, fluidMinZ,
fluidMaxZ, fluidSurfaceY)

  #declare i = i + 1;
#end


If interested, I have access to a better verion, and GPT-5 at work, which seems
to be able to spit out a ton of higher-level code.

There's still a lot of mistakes regarding lowercase reserved identifiers,
macro-vs-function, passing undeclared identifiers into "functions", etc.,
however it gives you a lot of preliminary ideas to work with, and can help
implement tricky equations in code a lot faster.

-BW

[Bald Eagle] Re: Bubble 4.0.1 [162 days 11 hours and 39 minutes ago]

Sun, 26 Oct 2025 17:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> The issue is a section of code that "adjusts" the column positions, and
> ultimately derives from parameters eFluidX, eFluidZ, and fRadius.
> Common sense would suggest that this is an attempt to deal with a
> non-vertical container, but that is not what this code section does.  In
> fact, I cannot figure out what the heck Mr. Robertson is trying to do here.

Since you have a vertical cylinder, then the x and z parameters are there to
keep wandering bubbles inside the cylindrical container.

It looks like he just didn't do a very good job of making the correction.
I'd try collision testing of the spheres with the wall of the cylinder before
the calculations of the next round happen, along with storing the direction of
motion of each bubble from the previous step, and a flag. If a collision will
take place, set the flag, make the bubble move toward the central axis for a
certain number of steps before releasing it from that corrective direction by
turning off the flag.

> Version 4.0.1 suppresses that adjustment, forcing the bubbles to stay
> within their container.  Unfortunately, the Champagne flute must remain
> upright for the bubble columns to be positioned in any quasi-realistic
> manner.

When I get back into "bounding cylinder" mode, I'll try to ponder bounding a
tilted champagne flute.

However, perhaps you should just use trace() to determine the starting position
of the bubble, and then when it collides with the side of the tilted flute, make
it rise along the edge until it's y-value equals the liquid's surface.

>
> As for the bubble expansion rate, I am not an expert on fluid dynamics,
> and clearly neither is Mr. Robertson.  Version 4.0 adds a global
> parameter to control the expansion rate of the bubbles.  Between that
> parameter and varying the height of the bubble container, one should be
> able to find a combination that resembles real life carbonation.

The size of a bubble is related to the pressure exerted on it.
Fluid pressure is dependent solely on the height of the column of liquid.
So you should start with a bubble of some initial size, and then adjust the
VOLUME of the bubble in a linear fashion as it rises.
P1V1 = P2V2

- BW

[Cousin Ricky] Re: Bubble 4.0.1 [162 days 14 hours and 9 minutes ago]

Sun, 26 Oct 2025 14:40:00 GMT

Bubble version 4.0.1:

  https://github.com/CousinRicky/POV-bubble/releases/tag/v4.0.1

[Cousin Ricky] Bubble 4.0.1 [162 days 14 hours and 19 minutes ago]

Sun, 26 Oct 2025 14:29:31 GMT

The bubble contribution keeps throwing me curve balls.  Between the
opacity of the code and it not doing what the comments say it does (or
what anyone other than Charles Robertson expects it to do), I am unable
to figure out how Mr. Robertson expected this code to behave.

My intention with version 4.0 was to slow the expansion of the bubbles
as they rise.  After I uploaded it Wednesday, I was eager to try it out
on my glasses of Champagne, but I got unexpected results.  Fiddling
around with the bubbles revealed that the expansion rate varies
depending on how high the beverage is above the Cartesian origin.  This
has implications for a long-stemmed wineglass.

So I wrote a test program to try out bubble containers of various
heights and sizes, and that's when things got really weird.  The columns
of bubbles would not stay in their lanes.

The issue is a section of code that "adjusts" the column positions, and
ultimately derives from parameters eFluidX, eFluidZ, and fRadius.
Common sense would suggest that this is an attempt to deal with a
non-vertical container, but that is not what this code section does.  In
fact, I cannot figure out what the heck Mr. Robertson is trying to do here.

Version 4.0.1 suppresses that adjustment, forcing the bubbles to stay
within their container.  Unfortunately, the Champagne flute must remain
upright for the bubble columns to be positioned in any quasi-realistic
manner.

As for the bubble expansion rate, I am not an expert on fluid dynamics,
and clearly neither is Mr. Robertson.  Version 4.0 adds a global
parameter to control the expansion rate of the bubbles.  Between that
parameter and varying the height of the bubble container, one should be
able to find a combination that resembles real life carbonation.

(Why did I skip from version 2.* to version 4?  Because the initial
version of this contribution was 3.6, so I wanted to leave 3.* clear.
I'm guessing that the 3.6 was a misunderstanding of the version field of
the Object Collection upload form.)

In the attached images, Bubble_Rate = 1.00 uses the original expansion
code, and Bubble_Rate = 0.45 is the new default expansion rate.  All
containers in these images are vertical, so a tilted orientation cannot
be the reason for the "adjustments."

[Cousin Ricky] Re: My contributions: October 2025 update [168 days 12 hours and 26 minutes ago]

Mon, 20 Oct 2025 16:23:23 GMT

On 2025-10-13 15:18, Cousin Ricky wrote:
> 
> bubble 2.0.1: (B) Bubbles can be untextured; a randomization bias is
> corrected; the SDL is brought into namespace compliance; and HTML
> documentation is added.  This is a production release.

There was an error in the bubble 2.0.1 user manual:  bblTx should be a
texture, not a float.  The manual is now corrected and tagged:

  https://github.com/CousinRicky/POV-bubble/releases/tag/v2.0.1
  https://github.com/CousinRicky/POV-bubble/blob/main/bubble.html

[Mr] Re: My contributions: October 2025 update [174 days 12 hours and 14 minutes ago]

Tue, 14 Oct 2025 16:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> Over the past year, I have been reviewing my contributions in
> anticipation of a restored Object Collection server.  Most of them have
> had significant updates since the crash; I have uploaded these to
> GitHub, with the license upgraded to GNU-LGPL version 3 or later.
> Pending details of the restored Object Collection that I need for the
> user manuals, I am posting most of the contributions as release
> candidates.  The updates, since LeForgeron's archive (A) and the server
> crash (B), are as follows:
>
> AndroidRobot 6.0-rc.1: (A) The 2019 redesign and robot's standalone
> head; (B) the 2023 redesign and accommodation of alternate assumed_gamma
> values.
>
> BeamTest 2.0-rc.1: (B) Media and photons are refactored according to
> lessons learned last month.
>
> BrightStar5 1.2-rc.1: (B) The 3.8 version check for text handling is
> reverted, due to the 3.8 rollback (see also "Changes to text object?"
> thread in p.general).  Instructions are added for how to update the data
> files.
>
> bubble 2.0.1: (B) Bubbles can be untextured; a randomization bias is
> corrected; the SDL is brought into namespace compliance; and HTML
> documentation is added.  This is a production release.
>
> Caption 1.1.1A: (B) Minor update; the license upgrade is not yet uploaded.
>
> CoffeeMug 2.0.1A: (A, B) Minor updates; the license upgrade is not yet
> uploaded.
>
> GemCuts 2.0-rc.1: (B) The gem cut from SpectralRender is added.
>
> IntegrateLight 1.0.3-rc.1: (B) Minor: the demo scenes are gamut-mapped.
>
> lrchairs 1.1.1A: (B) Minor update, plus Leroy's new website.  The
> license upgrade is not yet uploaded.
>
> RC3Metal 2.1-beta.1: (A) Turbulence can be adjusted on galvanized
> textures, and the photons bug on blurred reflection is fixed; (B) Major
> updates: highlight reform, some default settings are changed,
> reflections of objects with blurred reflection also show blurred
> reflection, and most recently, the highlight roughness function can be
> adjusted without the user having to do math.  This update remains in
> beta testing while I review the highlight reform; check the Releases
> link for the tag.  The license upgrade is not yet uploaded.
>
> RoundEdge 2.0A: (A) Rounded boxes with unequal edge radii, and an
> interface to the isosurface evaluate feature; (B) minor update; the
> license upgrade is not yet uploaded.
>
> ScaryCoronavirus 1.0c-rc.1: (B) User manual correction and CDC archive link.
>
> Spectrum 5.0-rc.1: (B) A new gamut mapping method.
>
> SphereSweep 2.1A: (A) An interface to the PointArrays Object Collection
> contribution, and the quadratic Bézier spline type; (B) minor update;
> the license upgrade is not yet uploaded.
>
> TheEarth 1.2a: (B) uv-mapping, gamma decoding, and clouds rotate with
> the Earth.  This is a production release.
>
> TiltedTorus 3.0.1A: (B) Minor update; the license upgrade is not yet
> uploaded.
>
> _________________
>
> The following libraries have been created since the crash, and are
> proposed for the Object Collection:
>
> DeskLamp 2.0.1: Version 2.0 adds flat panel lamps, and version 2.0.1 has
> a workaround for the 3.8 photons bug. The license upgrade is not yet
> uploaded.
>
> MakeSpectrum 1.1-rc.3: The BT.709/2020 transfer function is added, and
> flags are set in the event of unrealistic reflection results.
>
> RC3Wood 2.0: No changes since the initial upload, so the license upgrade
> is not yet uploaded.
>
> ShapeOfTheDay 2.1.1-beta.1: Version 2.1 adds flat panel lamps, and
> version 2.1.1 fixes the bug in lamps near the ceiling center.  This
> update remains in beta testing while I investigate an issue with light
> bulbs; check the Releases link for the tag.
>
> SpiralImage 2.1-rc.1: Version 2.1 adds gamma decoding for image maps.
>
> The updated contributions can be accessed via:
>   https://github.com/CousinRicky/POV-Ray-Object-Collection
>
> _________________
>
> I hate that I have to bring politics into this, but as jr once quoted
> author Bangambiki Habyarimana in another thread, "Life is politics, you
> do it or it does you."  Three of my user manuals have links to USA
> government websites, but lately, the trustworthiness of USA government
> agencies has come into question.
>
> Also, I can't be sure that NSPM-7 doesn't apply to me, so I want to get
> my stuff out before I'm deported to South Sudan.
>
> ScaryCoronaVirus has links to the Centers for Disease Control and
> Prevention (CDC).  As the CDC is now being run by a lunatic, I have
> added an early January link from the Wayback Machine.
>
> DeskLamp links to EnergyStar.  As the president is a climate change
> denier, I will add an early January link from the Wayback Machine.
> Since there are no changes to DeskLamp features since my last upload,
> and (unlike the CDC) EnergyStar misinformation is not a matter of life
> and death, I won't bother uploading the Wayback link before the Object
> Collection comes back online.
>
> One would think that saving money would be enough to value energy
> efficiency, but we have "coal rollers" in the states who deliberately
> waste fuel for no other reason than to pollute the air.  Sanity is lost
> here.  Hopefully, the president values his own pocketbook and will leave
> EnergyStar alone.
>
> BrightStar5 links to a NASA database.  As this site is interactive,
> there's no point in linking to an archive.

I hope staying still, crossing fingers without holding our breaths untill a more
sane situation comes back will bear fruits.

[Cousin Ricky] My contributions: October 2025 update [175 days 9 hours and 31 minutes ago]

Mon, 13 Oct 2025 19:18:22 GMT

Over the past year, I have been reviewing my contributions in
anticipation of a restored Object Collection server.  Most of them have
had significant updates since the crash; I have uploaded these to
GitHub, with the license upgraded to GNU-LGPL version 3 or later.
Pending details of the restored Object Collection that I need for the
user manuals, I am posting most of the contributions as release
candidates.  The updates, since LeForgeron's archive (A) and the server
crash (B), are as follows:

AndroidRobot 6.0-rc.1: (A) The 2019 redesign and robot's standalone
head; (B) the 2023 redesign and accommodation of alternate assumed_gamma
values.

BeamTest 2.0-rc.1: (B) Media and photons are refactored according to
lessons learned last month.

BrightStar5 1.2-rc.1: (B) The 3.8 version check for text handling is
reverted, due to the 3.8 rollback (see also "Changes to text object?"
thread in p.general).  Instructions are added for how to update the data
files.

bubble 2.0.1: (B) Bubbles can be untextured; a randomization bias is
corrected; the SDL is brought into namespace compliance; and HTML
documentation is added.  This is a production release.

Caption 1.1.1A: (B) Minor update; the license upgrade is not yet uploaded.

CoffeeMug 2.0.1A: (A, B) Minor updates; the license upgrade is not yet
uploaded.

GemCuts 2.0-rc.1: (B) The gem cut from SpectralRender is added.

IntegrateLight 1.0.3-rc.1: (B) Minor: the demo scenes are gamut-mapped.

lrchairs 1.1.1A: (B) Minor update, plus Leroy's new website.  The
license upgrade is not yet uploaded.

RC3Metal 2.1-beta.1: (A) Turbulence can be adjusted on galvanized
textures, and the photons bug on blurred reflection is fixed; (B) Major
updates: highlight reform, some default settings are changed,
reflections of objects with blurred reflection also show blurred
reflection, and most recently, the highlight roughness function can be
adjusted without the user having to do math.  This update remains in
beta testing while I review the highlight reform; check the Releases
link for the tag.  The license upgrade is not yet uploaded.

RoundEdge 2.0A: (A) Rounded boxes with unequal edge radii, and an
interface to the isosurface evaluate feature; (B) minor update; the
license upgrade is not yet uploaded.

ScaryCoronavirus 1.0c-rc.1: (B) User manual correction and CDC archive link.

Spectrum 5.0-rc.1: (B) A new gamut mapping method.

SphereSweep 2.1A: (A) An interface to the PointArrays Object Collection
contribution, and the quadratic BÃ©zier spline type; (B) minor update;
the license upgrade is not yet uploaded.

TheEarth 1.2a: (B) uv-mapping, gamma decoding, and clouds rotate with
the Earth.  This is a production release.

TiltedTorus 3.0.1A: (B) Minor update; the license upgrade is not yet
uploaded.

_________________

The following libraries have been created since the crash, and are
proposed for the Object Collection:

DeskLamp 2.0.1: Version 2.0 adds flat panel lamps, and version 2.0.1 has
a workaround for the 3.8 photons bug. The license upgrade is not yet
uploaded.

MakeSpectrum 1.1-rc.3: The BT.709/2020 transfer function is added, and
flags are set in the event of unrealistic reflection results.

RC3Wood 2.0: No changes since the initial upload, so the license upgrade
is not yet uploaded.

ShapeOfTheDay 2.1.1-beta.1: Version 2.1 adds flat panel lamps, and
version 2.1.1 fixes the bug in lamps near the ceiling center.  This
update remains in beta testing while I investigate an issue with light
bulbs; check the Releases link for the tag.

SpiralImage 2.1-rc.1: Version 2.1 adds gamma decoding for image maps.

The updated contributions can be accessed via:
  https://github.com/CousinRicky/POV-Ray-Object-Collection

_________________

I hate that I have to bring politics into this, but as jr once quoted
author Bangambiki Habyarimana in another thread, "Life is politics, you
do it or it does you."  Three of my user manuals have links to USA
government websites, but lately, the trustworthiness of USA government
agencies has come into question.

Also, I can't be sure that NSPM-7 doesn't apply to me, so I want to get
my stuff out before I'm deported to South Sudan.

ScaryCoronaVirus has links to the Centers for Disease Control and
Prevention (CDC).  As the CDC is now being run by a lunatic, I have
added an early January link from the Wayback Machine.

DeskLamp links to EnergyStar.  As the president is a climate change
denier, I will add an early January link from the Wayback Machine.
Since there are no changes to DeskLamp features since my last upload,
and (unlike the CDC) EnergyStar misinformation is not a matter of life
and death, I won't bother uploading the Wayback link before the Object
Collection comes back online.

One would think that saving money would be enough to value energy
efficiency, but we have "coal rollers" in the states who deliberately
waste fuel for no other reason than to pollute the air.  Sanity is lost
here.  Hopefully, the president values his own pocketbook and will leave
EnergyStar alone.

BrightStar5 links to a NASA database.  As this site is interactive,
there's no point in linking to an archive.

[Cousin Ricky] Re: bubble update [247 days and 57 minutes ago]

Sun, 3 Aug 2025 03:51:46 GMT

On 2025-05-22 23:18 (-4), Cousin Ricky wrote:
>
>  - There is *always* a column of bubbles along the y-axis.
>  - As Kenneth noted years ago, the bubble size arguments, to put it
>    mildly, are non-intuitive, and I have yet to figure out how they
>    work.  I also question whether bubbles expand linearly with
>    decreasing pressure.
> 
> ...  I also won't submit an HTML user manual so long as I
> haven't figured out the bubble size arguments.

I believe I have figured out fBblHeightRngS and fBblHeightRngE, and they
are not at all as Mr. Robertson described.  They appear to be the lower
and upper bounds of the radii of bubbles at the lower end of the
container; the sizes of the bubbles as they rise are determined
automatically.

I have created an HTML user manual, which describes these and the other
macro arguments as best as I could figure them out.  I have also
randomized that one column of bubbles that was fixed to the y-axis.
These updates are in version 2.0.1:

  https://github.com/CousinRicky/POV-bubble/releases/tag/v2.0.1

My next task is to figure out realistically how the bubbles should
expand as they rise.  My intuition tells me it should be a cube root
correspondence, rather than linear; but that it also depends on the
fluid density and atmospheric pressure, which are not currently
variables (that I can see) in the macros.

[Cousin Ricky] bubble update [319 days 1 hour and 31 minutes ago]

Fri, 23 May 2025 03:18:25 GMT

I'd like fine bubbles in my glass of Martinelli, and well, look at that!
 There's a convenient bubble generator already in the Object Collection.
 The problem is, in my experiments creating voids in a solid with
Fresnel reflection and media, the only models that rendered comparably
with a simple difference were those with non-textured voids, but
bubble.inc requires a texture.

So I added a macro for non-textured bubbles.

  https://github.com/CousinRicky/POV-bubble

Well... that wasn't the only problem; the original bubble.inc has ...
issues:
 - Most seriously, the bubble randomization is strongly biased towards
   the +x+z sector.
 - Also, despite being self-rated as "fully compliant," none of the
   identifiers are properly prefixed.
 - The bubbles do not conform to a cylinder, but to a box.  (Not a big
   deal)
 - The pseudorandom number stream is simply '1'; I don't know how that
   works.
 - There is *always* a column of bubbles along the y-axis.
 - As Kenneth noted years ago, the bubble size arguments, to put it
   mildly, are non-intuitive, and I have yet to figure out how they
   work.  I also question whether bubbles expand linearly with
   decreasing pressure.
 - The original version is not 1.0, but 3.6, which I take to be a
   misunderstanding of the version field of the upload form.
 - And in the nit-picky department, Mr. Robertson consistently
   misspelled "collumn" with 2 Ls.

In version 2.0:
 - I prefixed the identifiers.
 - I completely replaced the x-z randomization, hoping I didn't break
   anything.  (The original randomization code is an enigma.)
 - I unilaterally upgraded the license to GNU-LGPL 3, which, given the
   wording of the standard Object Collection license statement, is
   permitted by section 13 of the CC-LGPL.
 - I added a demo scene description file.
 - After checking my 'Murican exceptionalism (there's no such thing,
   BTW), consulting a couple of British dictionaries, and verifying that
   there is no variant spelling of "column," I corrected that spelling.
The remaining issues I left alone; I don't want to put a lot of energy
into this module.  I also won't submit an HTML user manual so long as I
haven't figured out the bubble size arguments.

Despite being "optimised for POV-Ray 3.6", the library works perfectly
well in all POV-Ray versions from 3.5 to 3.8.

About the namespace compliance, I did express my concern to Chris
Bartlett about making '3' the default on the upload screen.  His
reasoning was that he wanted to encourage namespace compliance, which is
a goal I 100% agree with.  Unfortunately, the end result of this default
is not actual compliance, but an empty claim of compliance.  The upload
software enforced filename compliance, but it could not verify
identifier compliance.  I don't have a solution to this that doesn't
involve either an AI (and I have trust issues with those) or some
volunteer taking time out from real life to inspect nearly 100 modules.

bubble.inc appears to be a drive-by contribution.  While I very much
appreciate Mr. Robertson's efforts, I have not seen him before or since.
 If you're still around, Charles, can you please explain fBblHeightRngS
and fBblHeightRngE?

[antoine] Re: POVRay object collection ready for use. [447 days 19 hours and 47 minutes ago]

Tue, 14 Jan 2025 09:02:02 GMT

Le 13/01/2025 Ã  22:34, Leroy a Ã©critÂ :
> antoine <map### [at] orangefr> wrote:
>> Hello / Hi
>> I post in this group to present POVRay objects I made and that are
>> available on my github account a this address:
>>
>> https://github.com/WarrenGames/POVRay-objects1
>>
>> I'd like to have your opinion about my creations and constructive
>> advices if you are curious (you have the possibility to see the objects
>> on the repository page with rendered images that appear on the interface).
>> Enjoy !
> 
> Nice work!
> 
> 
> 
Thank you. :-D

[Leroy] Re: POVRay object collection ready for use. [448 days 7 hours and 14 minutes ago]

Mon, 13 Jan 2025 21:35:00 GMT

antoine <map### [at] orangefr> wrote:
> Hello / Hi
> I post in this group to present POVRay objects I made and that are
> available on my github account a this address:
>
> https://github.com/WarrenGames/POVRay-objects1
>
> I'd like to have your opinion about my creations and constructive
> advices if you are curious (you have the possibility to see the objects
> on the repository page with rendered images that appear on the interface).
> Enjoy !

Nice work!

[antoine] POVRay object collection ready for use. [448 days 12 hours ago]

Mon, 13 Jan 2025 16:49:27 GMT

Hello / Hi
I post in this group to present POVRay objects I made and that are 
available on my github account a this address:

https://github.com/WarrenGames/POVRay-objects1

I'd like to have your opinion about my creations and constructive 
advices if you are curious (you have the possibility to see the objects 
on the repository page with rendered images that appear on the interface).
Enjoy !

[Cousin Ricky] AndroidRobot version 6.0-beta.1: the 2023 brandi... [450 days 4 hours and 49 minutes ago]

Sun, 12 Jan 2025 00:00:00 GMT

I have implemented the 2023 redesign of the Android[tm] robot; however,
I am leaving it at a beta stage until the Object Collection returns online.

All past designs and official colors are still available with this
update; see the User Manual for details.  (The unofficial color from
AndroidRobot 1.0 has not been retained; if, for some reason, you feel
nostalgic about it, it was srgbft MediumSpringGreen.)

This beta version is at:

https://github.com/CousinRicky/POV-AndroidRobot/releases/tag/v6.0-beta.1

[Cousin Ricky] Re: Object Collection rules review [466 days 5 hours and 44 minutes ago]

Thu, 26 Dec 2024 23:04:56 GMT

On 2023-03-05 11:01 (-4), Cousin Ricky wrote:
> 
> I am not proposing that we move away from the LGPL.  I'm thinking that
> the upload software could accept "GNU-LGPL" as well as "CC-LGPL," that
> the phrase "Creative Commons" be dropped from the documentation on
> lib.povray.org, and that the documentation link directly to gnu.org.
> But as long as the Creative Commons link redirects to gnu.org, this is
> not a major issue.

... And the Creative Commons link is now dead.  CC-LGPL apparently is no
longer a thing.

Regarding the LGPL version, section 13 of the CC-LGPL allows the user to
choose any version of the LGPL if the work does not specify a
version--which is the case with the Object Collection's required license
text.

While the CC-LGPL remains valid for existing contributions, the GNU-LGPL
and a similar license will be offered going forward.  Stay tuned...

[jr] Re: categorising objects [526 days 16 hours and 19 minutes ago]

Sun, 27 Oct 2024 12:30:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> > yes.  dilemma(s).  fungi too cannot be categorised, really, as is.
>
> There is actually a neologism for fungi, "Funga," apparently coined in
> the early 2000s.  Now that biologists have determined that fungi are
> less closely related to plants than to animals, should we include the
> category "Funga" under Organic Forms?  (One POVer regularly renders
> sentient fungoid beings, though he has not contributed them to the
> Collection.)  Or is it fine to group fungi under Flora?

Wiktionary says the "term is equivalent to the concepts of fauna and flora", so
as a third "Terrestrial" entry, I guess.  thanks.


regards, jr.

[Cousin Ricky] Re: categorising objects [527 days 8 hours and 24 minutes ago]

Sat, 26 Oct 2024 20:25:03 GMT

On 2023-04-22 04:51 (-4), jr wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> On 2023-04-14 01:57 (-4), jr wrote:
>>> coronavirus, it'd be 'organic forms' and 'terrestrial fauna' primarily, I guess,
>>> and 'microscopic' too.
>>
>> I don't think of viruses as fauna.  I still hear dieticians referring to
>> bacteria as "flora," probably a holdover from the days when biologists
>> thought bacteria were plants; but viruses have no analogous history.
> 
> yes.  dilemma(s).  fungi too cannot be categorised, really, as is.

There is actually a neologism for fungi, "Funga," apparently coined in
the early 2000s.  Now that biologists have determined that fungi are
less closely related to plants than to animals, should we include the
category "Funga" under Organic Forms?  (One POVer regularly renders
sentient fungoid beings, though he has not contributed them to the
Collection.)  Or is it fine to group fungi under Flora?

[Cousin Ricky] DeskLamp 2.0.1 and ShapeOfTheDay 2.1: bug workar... [594 days 6 hours and 20 minutes ago]

Tue, 20 Aug 2024 22:29:14 GMT

Last year, the caustics in my POV-Ray 30th anniversary scene went
haywire, and I tracked the problem down to the DeskLamp module.  But I
couldn't figure out what it was about DeskLamp that was causing the
problem.  I assumed that it had something to do with the complexity of
the hooded lamp.  While shopping in OfficeMax, I got inspired to
implement flat panel lamps, hoping that this would solve the problem.
These new lamp styles are available in DeskLamp 2.0.  Version 2.0 also
implements a dimmer dial.

Unfortunately, the freaky caustics did not go away.

I eventually discovered that the bug was in POV-Ray 3.8 itself.  (See
"Photons are broken with true inverse squared lighting" in p.beta-test.)
 DeskLamp 2.0.1 avoids this bug by default:

  https://github.com/CousinRicky/POV-DeskLamp/releases/tag/v2.0.1

ShapeOfTheDay inherited the freaky caustics from DeskLamp, so
downloading DeskLamp 2.0.1 will automatically fix the problem in
ShapeOfTheDay 2.0.

However, as ShapeOfTheDay 2.0 is unaware of the new lamp styles, I added
this option in ShapeOfTheDay 2.1; but ShapeOfTheDay 2.1 requires version
2.0 or later of DeskLamp.  I changed the default lamp style to a round
flat panel because it renders much faster than the hooded lamp.

  https://github.com/CousinRicky/POV-ShapeOfTheDay/releases/tag/v2.1

Errata:  I had already prepared ShapeOfTheDay for submission to the
Object Collection prior to incorporating the new lamp styles, and forgot
to undo those preparations before creating the new release on GitHub.

 - The User Manual and source code comments say that this module is from
   the Object Collection. In fact, it has not yet been submitted to the
   Object Collection.

 - The link in the User Manual to the Object Collection Userâ€™s Guide
is
   to the actual Object Collection site, which, as you know, is not yet
   back online.  Use this Wayback link instead:

https://web.archive.org/web/20120419111948/http://lib.povray.org/usersguide/02using.html

 - The User Manual says that parameter sotd_Solar defaults to about 2770
   with the default indoor setup. In fact, that is the default only if
   the user selects the hooded lamp as the main lamp; otherwise, it is
   about 933.

[Cousin Ricky] Re: Question: HTTPS? [801 days 16 hours and 14 minutes ago]

Fri, 26 Jan 2024 12:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I expect https.  (will confirm in the coming days)
>
> https.
>
> fwiw, you can just write '//www.asite.com/'.  if you omit the protocol it'll
> work for both.

Thank you!

[jr] Re: Question: HTTPS? [801 days 19 hours and 54 minutes ago]

Fri, 26 Jan 2024 08:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> I expect https.  (will confirm in the coming days)

https.

fwiw, you can just write '//www.asite.com/'.  if you omit the protocol it'll
work for both.


regards, jr.

[jr] Re: Question: HTTPS? [803 days 20 hours and 49 minutes ago]

Wed, 24 Jan 2024 08:00:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> When lib.povray.org is restored, will it use the HTTPS protocol, or will
> it remain HTTP as before?  I need to know for the links in my user manuals.

I expect https.  (will confirm in the coming days)


regards, jr.

[Cousin Ricky] Question: HTTPS? [804 days 2 hours and 17 minutes ago]

Wed, 24 Jan 2024 02:31:34 GMT

When lib.povray.org is restored, will it use the HTTPS protocol, or will
it remain HTTP as before?  I need to know for the links in my user manuals.

[Mr] Re: TheEarth version 1.1 [847 days 19 hours and 14 minutes ago]

Mon, 11 Dec 2023 09:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2023-12-10 10:13 (-4), Bald Eagle wrote:
> >
> > So, having looked into inversive geometry, stereographic projection, Mobius
> > transforms, etc. - I think I recall seeing some examples of slightly different
> > ways of projecting the sphere's surface onto a plane.
>
> I suspect that there are an infinite number of such projections.
>
> > Not having delved into this topic to any real extent, are there different image
> > maps that might not result in a correctly mapped sphere?
>
> It all depends on the projection algorithms.
>
> > Or is the main problem just the cylindrical vs uv-mapping in the scene?
>
> In this particular case, it's just cylindrical vs uv-mapping.  The
> images were created in the equidistant cylindrical projection, so that
> is what I had to work with.
>
> > Also just curious if the sphere got scaled to be an oblate spheroid.
>
> The sphere is not scaled.  To account for oblateness, I'd have to know
> whether the maps were prepared with geocentric or geodedic latitudes,
> and *then* I'd have to remember how I handled the difference 30 years
> ago when I worked on USAF satellites.  And then a function would have to
> be applied to distort the image map in the north-south orientation.
>
> My head is already starting to hurt.

Great endeavor !

Indeed, almost as many projection systems... (That's how these calculations are
called in the GIS field (Geographical Information Systems aka modern
cartography))...As there are countries,
(https://en.wikipedia.org/wiki/Map_projection) not even counting the vertical
projection systems.

Each country wants to minimize distortions in its area. The world's shape is
also not much more of a sphere than a potato can be (latitudes vs longitudes
lengths, or Himalayas vs japan's deep seas) so for instance in France use the
Lambert 93 projection. And it's already a good thing that all of the country is
normalized to use the same.

Just as much as the language that "won" for international exchanges is English,
The encoding UTF8...
The projection that did so is WGS84
(https://en.wikipedia.org/wiki/World_Geodetic_System#WGS84)
So that's what anything without specified system is expected to be using (GPS,
etc...).

The awesome free software QGIS can convert between projections.
the hard thing for non specialists is to know were to look for the projection
system of some data when not specified, before converting it and not tempering
too much to avoid corrupting it.

The first thing to do is to search for a file next to the graphical data such as
a TIFF image. it could for instance be a file with the same name but ending with
*.PRJ

the other thing to do whether you have that file around or not is to look at the
numbers for coordinates of one entity in your data : opening it, selecting it,
zooming to it, moving cursor around, whatever software will always show you some
couple or tuple of numbers.

The X and Y value of a point, for a given projection will always be comprised
within some bounding limits in the country accustomed to use it again, in e.g.

France is within:
0 000 000>X>1 300 000
6 000 000>Y>7 200 000
(not that it matters but all in meters)

In fact if you actually know where this point is supposed to be, and provided no
data corruption has occurred, you can identify the original projection of some
data by entering its coordinates in the below tool, and choosing the point that
comes up at its right place:
https://app.dogeo.fr/Projection/#/point-to-coords

That's all folks ! enjoy your open data !

[Thomas de Groot] Re: TheEarth version 1.1 [847 days 21 hours and 28 minutes ago]

Mon, 11 Dec 2023 07:20:55 GMT

Op 10/12/2023 om 18:42 schreef Cousin Ricky:
> On 2023-12-10 10:13 (-4), Bald Eagle wrote:
>>
>> So, having looked into inversive geometry, stereographic projection, Mobius
>> transforms, etc. - I think I recall seeing some examples of slightly different
>> ways of projecting the sphere's surface onto a plane.
> 
> I suspect that there are an infinite number of such projections.
> 
>> Not having delved into this topic to any real extent, are there different image
>> maps that might not result in a correctly mapped sphere?
> 
> It all depends on the projection algorithms.
> 
>> Or is the main problem just the cylindrical vs uv-mapping in the scene?
> 
> In this particular case, it's just cylindrical vs uv-mapping.  The
> images were created in the equidistant cylindrical projection, so that
> is what I had to work with.
> 
>> Also just curious if the sphere got scaled to be an oblate spheroid.
> 
> The sphere is not scaled.  To account for oblateness, I'd have to know
> whether the maps were prepared with geocentric or geodedic latitudes,
> and *then* I'd have to remember how I handled the difference 30 years
> ago when I worked on USAF satellites.  And then a function would have to
> be applied to distort the image map in the north-south orientation.
> 
> My head is already starting to hurt.
> 
> 
Naively, I had never realised things were this /hairy/ at all when I 
simply applied NASA maps of Earth or planets to simple spheres....
I even more appreciate your work on this.
-- 
Thomas

[Bald Eagle] Re: TheEarth version 1.1 [848 days 6 hours and 14 minutes ago]

Sun, 10 Dec 2023 22:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> The sphere is not scaled.  To account for oblateness, I'd have to know
> whether the maps were prepared with geocentric or geodedic latitudes,
> and *then* I'd have to remember how I handled the difference 30 years
> ago when I worked on USAF satellites.  And then a function would have to
> be applied to distort the image map in the north-south orientation.
>
> My head is already starting to hurt.

Oh yeah - I remember when Mike Horvath was doing stuff with that, and I looked
into it, and said, "Nope."

https://news.povray.org/povray.binaries.animations/thread/%3C5b57aea2%241%40news.povray.org%3E/

https://news.povray.org/povray.general/thread/%3C5b511771%241%40news.povray.org%3E/?mtop=423543



I have gained a significant appreciation for how hairy things get once they go
ellipsoidal.  ;)


- BW

[Cousin Ricky] Re: TheEarth version 1.1 [848 days 11 hours and 6 minutes ago]

Sun, 10 Dec 2023 17:42:32 GMT

On 2023-12-10 10:13 (-4), Bald Eagle wrote:
> 
> So, having looked into inversive geometry, stereographic projection, Mobius
> transforms, etc. - I think I recall seeing some examples of slightly different
> ways of projecting the sphere's surface onto a plane.

I suspect that there are an infinite number of such projections.

> Not having delved into this topic to any real extent, are there different image
> maps that might not result in a correctly mapped sphere?

It all depends on the projection algorithms.

> Or is the main problem just the cylindrical vs uv-mapping in the scene?

In this particular case, it's just cylindrical vs uv-mapping.  The
images were created in the equidistant cylindrical projection, so that
is what I had to work with.

> Also just curious if the sphere got scaled to be an oblate spheroid.

The sphere is not scaled.  To account for oblateness, I'd have to know
whether the maps were prepared with geocentric or geodedic latitudes,
and *then* I'd have to remember how I handled the difference 30 years
ago when I worked on USAF satellites.  And then a function would have to
be applied to distort the image map in the north-south orientation.

My head is already starting to hurt.

[Bald Eagle] Re: TheEarth version 1.1 [848 days 14 hours and 34 minutes ago]

Sun, 10 Dec 2023 14:15:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> It irritates me when I see a flat map mapped incorrectly onto a globe.

So, having looked into inversive geometry, stereographic projection, Mobius
transforms, etc. - I think I recall seeing some examples of slightly different
ways of projecting the sphere's surface onto a plane.

Not having delved into this topic to any real extent, are there different image
maps that might not result in a correctly mapped sphere?

Or is the main problem just the cylindrical vs uv-mapping in the scene?

Also just curious if the sphere got scaled to be an oblate spheroid.

- BW

[jr] Re: TheEarth version 1.1 [848 days 22 hours and 59 minutes ago]

Sun, 10 Dec 2023 05:50:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> It irritates me when I see a flat map mapped incorrectly onto a globe.
> ...
> About 10 years ago, I left a feedback comment with the correct mapping
> on the Object Collection website, but by then Chris was no longer around
> to see it.  I finally decided to rectify the error myself:

quick update on the OC.  your comment is still there, see attached :-).  the OC
is running, has been for a while, albeit on a development machine.  RL and
circumstances added unavoidable delays (on both sides).  a couple of "other
issues" are pending still, however, getting 'lib.povray' online again is a
priority for me/us, and should happen early next year.

regards, jr.

[m@b] Re: TheEarth version 1.1 [849 days 3 hours and 7 minutes ago]

Sun, 10 Dec 2023 01:42:20 GMT

On 09/12/2023 11:16 PM, Cousin Ricky wrote:
> It irritates me when I see a flat map mapped incorrectly onto a globe.

Anybody know a source for political map(s) with the correct projection, 
that I can use for a globe?

(This one I know is wrong)

Thanks,
m@

[kurtz le pirate] Re: TheEarth version 1.1 [849 days 12 hours and 5 minutes ago]

Sat, 9 Dec 2023 16:43:44 GMT

On 09/12/2023 16:16, Cousin Ricky wrote:
> It irritates me when I see a flat map mapped incorrectly onto a globe.
> It seems to be a symptom of people having grown up with Mercator maps,
> and never learning the correct relative sizes of land masses.  I've seen
> this done several times in professional settings, and I don't know
> whether the CGI people actually don't know what a globe is supposed to
> look like, or that they *do* know, and they're deliberately doing it
> wrong because they know that their *audience* doesn't know what a globe
> is supposed to look like.
> 
> But I'm sure that in Chris Bartlett's case, it was the former.
> 
> About 10 years ago, I left a feedback comment with the correct mapping
> on the Object Collection website, but by then Chris was no longer around
> to see it.  I finally decided to rectify the error myself:
> 
>   https://github.com/CousinRicky/POV-TheEarth
> 


I think the problem comes from the software used, which nowadays allows
all kinds of projections. The people who use this software don't really
know what this or that option corresponds to. Just right-click and it's
mapped...

Anyway, thanks for the correction.



-- 
Kurtz le pirate
Compagnie de la Banquise

[Thomas de Groot] Re: TheEarth version 1.1 [849 days 13 hours and 7 minutes ago]

Sat, 9 Dec 2023 15:41:41 GMT

Op 9-12-2023 om 16:16 schreef Cousin Ricky:
>    https://github.com/CousinRicky/POV-TheEarth

Excellent initiative. Thank you very much indeed.

-- 
Thomas

[Cousin Ricky] TheEarth version 1.1 [849 days 13 hours and 33 minutes ago]

Sat, 9 Dec 2023 15:16:10 GMT

It irritates me when I see a flat map mapped incorrectly onto a globe.
It seems to be a symptom of people having grown up with Mercator maps,
and never learning the correct relative sizes of land masses.  I've seen
this done several times in professional settings, and I don't know
whether the CGI people actually don't know what a globe is supposed to
look like, or that they *do* know, and they're deliberately doing it
wrong because they know that their *audience* doesn't know what a globe
is supposed to look like.

But I'm sure that in Chris Bartlett's case, it was the former.

About 10 years ago, I left a feedback comment with the correct mapping
on the Object Collection website, but by then Chris was no longer around
to see it.  I finally decided to rectify the error myself:

  https://github.com/CousinRicky/POV-TheEarth

[Cousin Ricky] MakeSpectrum 1.0: a spectral power distribution ... [979 days 14 hours and 37 minutes ago]

Tue, 1 Aug 2023 14:11:52 GMT

MakeSpectrum generates reflective spectral power distribution (SPD)
curves for spectrum-based rendering without recourse to a
spectrophotometer.  The user submits a color specification, and a spline
is returned.  The user can then convert the splines to POV-Ray's native
RGBFT format using other tools, such as Lightsys IV or SpectralRender.

I started this project back in 2014, not being satisfied with
SpectralRender's options for defining colors.  But after taking comments
by clipka into consideration, then running into hue calibration issues,
refining the code took me right up to that toothache I've mentioned
before, and development stalled.

I have already posted several images that used an unfinished version of
MakeSpectrum: CGSphere scenes of stacked convex and stacked concave
glass lenses, and a spectral variation of the GemCuts demo.  For
chromatic dispersion, nothing beats spectral rendering.

However, in the intervening years it seemed to me that the user
interface was unsuitable for public release.  Recently, I decided to
refocus the module in a more goal-oriented direction--that is, to
automatically match the SPDs to the sRGB color system.  This addresses
clipka's concerns as well as being more user friendly, but it was not an
idea that I could entertain back while I couldn't find an oral surgeon
on a weekend.

I intend to submit this to the Object Collection when it comes back
online; meanwhile, it is available at:
  https://github.com/CousinRicky/POV-MakeSpectrum

[And] Re: Procedural wood textures [999 days 20 hours and 14 minutes ago]

Wed, 12 Jul 2023 08:35:00 GMT

Your object collection is interesting.
I like the desk lamp.

I was looking wood textures of different people, too.

[jr] Re: Object Collection rules review [1036 days 13 hours and 9 minutes ago]

Mon, 5 Jun 2023 15:40:00 GMT

hi,

"jr" <cre### [at] gmailcom> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > ...
> > The main considerations are the license, namespace compliance, and what
> > files should be bundled.
> > ...
> the GNU/CC licensing and the ASCII only issues have been mentioned, and, final
> decision pending, will be acted on.  ...

the licensing mention/requirements have been updated, the text only uses 'GNU',
and files can be submitted with either 'GNU-LGPL' or 'CC-LGPL.'

the remaining item (another request for help :-)) is replacing the
'cc-LGPL-a.png'; would appreciate if you could suggest (locate! :-)) a suitable
file; same  WxH, and ideally monochrome (the latter just a personal preference).
 tia.

elsewhere you wrote:
> I have updated the procedural wood texture I used for my hand plane,
> prepared it for the Object Collection when it comes back online ...

currently faced with .pov etc files having different mimetypes/'signatures' if
they include utf-8.  to (mis)use Leroy's phrase: 'Have Fun!' </grin>

regards, jr.

[Cousin Ricky] Procedural wood textures [1037 days 12 hours and 54 minutes ago]

Sun, 4 Jun 2023 15:55:10 GMT

I have updated the procedural wood texture I used for my hand plane,
prepared it for the Object Collection when it comes back online, and
posted it to GitHub.  This is the wood texture that held up my POV-Ray
25th anniversary tribute scene.  The main sticking point has been
finding a normal function for grain that is tapered, rather than
parallel.  But this has gone on too long for me not to share what I
have; besides, for any taper gradual enough to use as lumber, the
difference in appearance should be minimal (I think).

As it stands, this module does not accept user-defined color maps.  I am
wondering whether I should add such a capability.

https://github.com/CousinRicky/POV-RC3Wood

[jr] Re: zip archive from before May 2015 [1045 days 10 hours and 4 minutes ago]

Sat, 27 May 2023 18:45:00 GMT

hi,

"Droj" <803### [at] drojde> wrote:
> here is my contibution. The POV-files are from 2007.

appreciated, thanks.


regards, jr.

[jr] Re: categorising objects [1045 days 10 hours and 4 minutes ago]

Sat, 27 May 2023 18:45:00 GMT

hi,

"Droj" <803### [at] drojde> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > yesbird <sya### [at] gmailcom> wrote:
> > > I like this hierarchy, but only one question: what is a "Scale Model"
> > > category ?
> > thanks (still room for improvement, though :-)).  I guess I'm thinking of
> > projects like 'Ton' does, eg.
> > ...
> but Ton's project would fit in Vehicles>Rail.

just to repeat something I wrote elsethread, as I feel it's important: there is
no 'Vehicles->Rail' category, both categories/labels need selecting.  the
hierarchy is implicit only.

> I guess it's not necessary to have
> an extra category if the model is scaled down from the original. Nobody would
> realise it from the image.

yes and no :-).  take two hypothetical cars, one claims 'scale model'.  then I'd
expect to be able to re-texture either with little fuss, scale, and use.  but
say I want to make a monster truck, already have chassis and wheels, and only
want a body ?  then (I would think and hope) the scale model car would make that
an easier task, as I'd expect it to be built from parts.

regards, jr.

[Droj] Re: categorising objects [1045 days 15 hours and 59 minutes ago]

Sat, 27 May 2023 12:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> yesbird <sya### [at] gmailcom> wrote:
> > I like this hierarchy, but only one question: what is a "Scale Model"
> > category ?
>
> thanks (still room for improvement, though :-)).  I guess I'm thinking of
> projects like 'Ton' does, eg.
>
<https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d05f9ab6bc50fb5939601860%40news.povray.org%3E/>
>
>
>
> regards, jr.

Hi,

but Ton's project would fit in Vehicles>Rail. I guess it's not necessary to have
an extra category if the model is scaled down from the original. Nobody would
realise it from the image.

regards - Oswald

[Droj] Re: zip archive from before May 2015 [1045 days 16 hours and 34 minutes ago]

Sat, 27 May 2023 12:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Droj" <803### [at] drojde> wrote:
> > ...
> > I am sure I have. It takes a bit of time to search my archives.
> > Do you have a special request for the object collection zip?
>
> brilliant, thank you.  if there are several to choose from, the earliest
> download, please.
>
> (interesting thoughts/take on things in L-systems post, will .. cogitate ;-))
>
>
> regards, jr.

Hi,

here is my contibution. The POV-files are from 2007.

regards Oswald

[jr] Re: zip archive from before May 2015 [1045 days 19 hours and 49 minutes ago]

Sat, 27 May 2023 09:00:00 GMT

hi,

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> ...
> Here is Galaxy 1.0, the first module that I ever downloaded, in July 12, 2008.

perfect, thanks.  (2008! :-))


> Thanks for stepping up!

pleasure (currently .. wrestling with the LGPL stuff ;-))


regards, jr.

[Cousin Ricky] Re: zip archive from before May 2015 [1046 days 14 hours and 59 minutes ago]

Fri, 26 May 2023 13:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> > Do you want the entire collection or just one module?  I have plenty of single
> > downloads, but not the whole collection.
>
> thanking you too.  a single unmodified zip archive, ideally the oldest/earliest
> download of those.

Here is Galaxy 1.0, the first module that I ever downloaded, in July 12, 2008.
The module itself was uploaed December 13, 2007.  It is older than the current
version of Galaxy.

Thanks for stepping up!

[jr] Re: zip archive from before May 2015 [1046 days 21 hours and 34 minutes ago]

Fri, 26 May 2023 07:15:00 GMT

hi,

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> Do you want the entire collection or just one module?  I have plenty of single
> downloads, but not the whole collection.

thanking you too.  a single unmodified zip archive, ideally the oldest/earliest
download of those.


regards, jr.

[Cousin Ricky] Re: zip archive from before May 2015 [1047 days 1 hour and 59 minutes ago]

Fri, 26 May 2023 02:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> does anyone have an unmodified zip, downloaded from the object collection before
> May 2015 ?  please post a copy (or send), tia.

Do you want the entire collection or just one module?  I have plenty of single
downloads, but not the whole collection.

[jr] Re: zip archive from before May 2015 [1047 days 5 hours and 54 minutes ago]

Thu, 25 May 2023 22:55:00 GMT

hi,

"Droj" <803### [at] drojde> wrote:
> ...
> I am sure I have. It takes a bit of time to search my archives.
> Do you have a special request for the object collection zip?

brilliant, thank you.  if there are several to choose from, the earliest
download, please.

(interesting thoughts/take on things in L-systems post, will .. cogitate ;-))

regards, jr.

[Droj] Re: zip archive from before May 2015 [1047 days 7 hours and 24 minutes ago]

Thu, 25 May 2023 21:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> (a request for help)
>
> does anyone have an unmodified zip, downloaded from the object collection before
> May 2015 ?  please post a copy (or send), tia.
>
>
> regards, jr.

Hi jr.

I am sure I have. It takes a bit of time to search my archives.
Do you have a special request for the object collection zip?

regards, Oswald

[jr] zip archive from before May 2015 [1047 days 16 hours and 44 minutes ago]

Thu, 25 May 2023 12:05:00 GMT

hi,

(a request for help)

does anyone have an unmodified zip, downloaded from the object collection before
May 2015 ?  please post a copy (or send), tia.


regards, jr.

[jr] Re: categorising objects [1080 days 19 hours and 54 minutes ago]

Sat, 22 Apr 2023 08:55:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2023-04-14 01:57 (-4), jr wrote:
> > coronavirus, it'd be 'organic forms' and 'terrestrial fauna' primarily, I guess,
> > and 'microscopic' too.
>
> I don't think of viruses as fauna.  I still hear dieticians referring to
> bacteria as "flora," probably a holdover from the days when biologists
> thought bacteria were plants; but viruses have no analogous history.

yes.  dilemma(s).  fungi too cannot be categorised, really, as is.

> Would coffee mugs be considered "Furnishings/Decor"?

furnishings.  :-)  not ideal, but definitely not decorative (only).

> >     Transforms
> >     Cameras
> Great additions!

hey, thanks.

given that there have been no other follow-ups, I'll go with the last published
list, plus added 'Splines' (after 'Transforms'), and, maybe, something like
'Utensils' to go with the 'Furnishings/Decor'.

regards, jr.

[Cousin Ricky] Re: categorising objects [1088 days 3 hours and 31 minutes ago]

Sat, 15 Apr 2023 01:18:10 GMT

On 2023-04-14 01:57 (-4), jr wrote:
> 
> unsure (did I mention I'm crap at naming stuff ? :-)), to me they're like
> interior + exterior, "qualifiers", rather than categories per se; eg CR's
> coronavirus, it'd be 'organic forms' and 'terrestrial fauna' primarily, I guess,
> and 'microscopic' too.

I don't think of viruses as fauna.  I still hear dieticians referring to
bacteria as "flora," probably a holdover from the days when biologists
thought bacteria were plants; but viruses have no analogous history.

> [snip]
>     Household/Office Objects
>         Computers
>         Furniture
>         Furnishings/Decor
>             Office
>             Living space
>             Kitchen
>             Bathroom
>             Bedroom

Would coffee mugs be considered "Furnishings/Decor"?

> [snip]
>     Transforms
>     Cameras

Great additions!

[jr] Re: categorising objects [1088 days 22 hours and 49 minutes ago]

Fri, 14 Apr 2023 06:00:01 GMT

hi,

replying to the various categories suggested in reply to WFP,
but thanks, I knew there was more than just an orange stapler ;-).

re "Lakes of Wada" -- wow.


> It would be quite nice if we could find a way to make this a sort of
> collaborative document - perhaps some way to use OpenOffice.
> Then, people could sign up to handle specific items, and hyperlinks could be
> added to items already modeled, thus keeping everything together in one handy
> reference document as well as keeping it up-to-date without having a 500-page
> thread.

everything in one place and collaborative is appealing.  (personally have
no "office" s/ware other than Google Docs/Sheets/etc, which I never use)


> ...
> To whatever extent possible, it would make such things more usable (and
> therefore likely to be used more) if they were parameterized and coded for
> clarity rather than speed/performance.

> Have the object take its pigments/textures as arguments/variables, so that those
> are all easily modified as well.

> Objects that are designed to be placed ON something would likely best be modeled
> with the bottom center at the origin, and likewise, things that get hung by
> ropes, hooks, nails - would have the attachment point at the origin.

> It's often "easy" to model the usual CGI something-or-other, but the more
> sophisticated and sought after objects are the ones that have those added
> elements of imperfection to make them more realistic and less plastic and fake
> looking.

> Also, a certain degree of modularity would help the collection expand more
> rapidly.   It might be nice to make a screwdriver or chisel - but if you made a
> HANDLE, then it would be easy to match that up with a variety of screwdrivers,
> files, chisels, gouges, and other tools, especially if the handle is
> parameterized and the textures can easily be changed from wood to metal to
> plastic to carbon fiber....

> "Combinatorial modeling"

worth repeating, _very_ much agree.  modular, "inter-operating" objects
would be ideal.

thinking that, perhaps, "BE + CR" would make a fine combo to set out a list
of suggested criteria for (future) object collection submissions.  ;-)


regards, jr.

[jr] Re: categorising objects [1088 days 22 hours and 49 minutes ago]

Fri, 14 Apr 2023 06:00:01 GMT

hi,

I see capital letters... He can find the shift keys! Keys which probably
squeak like there is no tomorrow on being used. :-)

YOU AIN'T SEEN NOTHIN' YET...

(<https://www.youtube.com/watch?v=4cia_v4vxfE>  :-))



> The categories Microscopic and Military looked like sub-categories
> by indentation. I'd think they both are major categories?

unsure (did I mention I'm crap at naming stuff ? :-)), to me they're like
interior + exterior, "qualifiers", rather than categories per se; eg CR's
coronavirus, it'd be 'organic forms' and 'terrestrial fauna' primarily, I guess,
and 'microscopic' too.

a v brief recap of the mechanism.  the identation is, in a sense, misleading,
because it shows a hierarchy[*] (in the UI).  though if I select 'rail' for eg
the "rocket", then it is just 'rail'.  it only becomes a 'vehicle' when that
label too is selected.

[*] which could be constructed from the table, but currently isn't.


the recent suggestions (from both you and BE) have been added.  I probably went
over the top with the 'functions', nudged by you; must be all the recent work
on/with functions in the NGs.  :-)

I've decided to add 'inorganic' to the 'abstract forms', as BE points out,
difficult to (sub-)categorise.  'astronomy' under 'space' is meant for "based on
observation/measurement data using/providing objects, as many items in BE's list
imply.  re the architectural, 'infrastructure' standing for dams, canals, etc,
and 'historical/monument' to cover the castles + fortresses and so on.

below the final draft (close to, anyway).

(and sorry re delay, had meant to reply days ago)


regards, jr.

-----<snip>-----

Areas of Interest
    Abstract/Inorganic Forms
    Buildings/Architecture
        Domestic
        Commercial
        Industrial
        Historical/Monument
        Infrastructure
            Interior
            Exterior
    Household/Office Objects
        Computers
        Furniture
        Furnishings/Decor
            Office
            Living space
            Kitchen
            Bathroom
            Bedroom
    Games
        Ball Games
        Board Games
        Puzzles
        Video Games
    Landscapes
        Urban Landscapes
        Natural Landscapes
        Alien/SF Landscapes
    Organic Forms
        Terrestrial Flora
        Terrestrial Fauna
        Alien/SF Flora
        Alien/SF Fauna
            Microscopic
    Space
        Terrestrial
        Alien/SF
        Astronomy
    Sports
    Vehicles
        Aircraft
        Watercraft
        Rail
        Road
            Military
    Characters
        Animal
        Pet
        Humanoid
        Robot
    Gadgets
    Scale Model
Contribution Types
    Objects
        Solid (CSG-able)
        Non-solid (Non-CSG-able)
    Materials
    Textures
        Pigments
        Finishes
        Normals
    Interiors
        Media
    Macros
    Functions
        Isosurface
        Positioning
        Pattern/Object/Image
        Parametric
        HF
        Other
    Transforms
    Cameras
Uncategorised

[William F Pokorny] Re: categorising objects [1096 days 7 hours and 25 minutes ago]

Thu, 6 Apr 2023 21:23:39 GMT

On 4/6/23 08:13, jr wrote:
> the following then is another draft, "RFC" etc.

The categories Microscopic and Military looked like sub-categories by 
indentation. I'd think they both are major categories?

Isosurfaces - perhaps Isosurfaces & Parametrics ?

I see capital letters... He can find the shift keys! Keys which probably 
squeak like there is no tomorrow on being used. :-)

Bill P.

[Bald Eagle] Re: categorising objects [1096 days 10 hours and 24 minutes ago]

Thu, 6 Apr 2023 18:25:00 GMT

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

It would be quite nice if we could find a way to make this a sort of
collaborative document - perhaps some way to use OpenOffice.
https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/Calc_Guide/Sharing_documents_among_reviewers

Then, people could sign up to handle specific items, and hyperlinks could be
added to items already modeled, thus keeping everything together in one handy
reference document as well as keeping it up-to-date without having a 500-page
thread.

>     Abstract Forms

This is a hard one to pin down.  Many of these come about through doodling or
"failed" projects.  They are functions and surfaces and blobs.
I might call this a "meta-category", as it might be a good catch-all for things
like patterns, mathematical surfaces, functions, L-systems and other algorithms,
or even simple scenes using primitives and CSG that _result_ in "abstract forms"
(such as a Wada Basin).

>     Buildings/Architecture
>         Domestic
>         Commercial
>         Industrial
>             Interior
>             Exterior

Monuments, bridges, dams, tunnels, canals, etc.
Castles, earthworks, fortresses, battlements, etc.
Famous / historical buildings / structures.

>     Household/Office Objects
>         Furniture
>         Furnishings/Decor
>             Office
>             Living room
>             Kitchen
>             Bathroom
>             Bedroom
>         Computers
>     Games
>         Ball Games
>         Board Games
>         Puzzles
>         Video Games

Darts, outdoor games (badminton, bocci ball, croquet, lawn darts)

>     Landscapes
>         Urban Landscapes
>         Natural Landscapes
>         Alien/SF Landscapes
>     Organic Forms
>         Terrestrial Flora
>         Terrestrial Fauna
>         Alien/SF Flora
>         Alien/SF Fauna
>             Microscopic
>     Space
>         Terrestrial
>         Alien/SF

Planets.  uv maps, planetary statistics - size, orbital mechanics
nebulae, stars, black holes, quasars, pulsars, asteroids, comets, planetary
rings

>     Sports
>     Vehicles
>         Aircraft
>         Watercraft
>         Rail
>         Road
>             Military
>     Characters
>         Animal
>         Pet
>         Humanoid
>         Robot
>     Gadgets

Workshop tools, jigs, and fixtures.
Radios, stereos, speakers, antennae,

>     Scale Model
> Contribution Types
>     Objects
>         Solid (CSG-able)
>         Non-solid (Non-CSG-able)
>     Materials
>     Textures
>         Pigments
>         Finishes
>         Normals
>     Interiors
>         Media
>     Macros
>     Functions
>         Isosurface
>         Positioning
>         Other
>     Transforms
>     Cameras
> Uncategorised
>
>
> regards, jr.

To whatever extent possible, it would make such things more usable (and
therefore likely to be used more) if they were parameterized and coded for
clarity rather than speed/performance.

Have the object take its pigments/textures as arguments/variables, so that those
are all easily modified as well.

Objects that are designed to be placed ON something would likely best be modeled
with the bottom center at the origin, and likewise, things that get hung by
ropes, hooks, nails - would have the attachment point at the origin.

It's often "easy" to model the usual CGI something-or-other, but the more
sophisticated and sought after objects are the ones that have those added
elements of imperfection to make them more realistic and less plastic and fake
looking.

Also, a certain degree of modularity would help the collection expand more
rapidly.   It might be nice to make a screwdriver or chisel - but if you made a
HANDLE, then it would be easy to match that up with a variety of screwdrivers,
files, chisels, gouges, and other tools, especially if the handle is
parameterized and the textures can easily be changed from wood to metal to
plastic to carbon fiber....

"Combinatorial modeling"

- BW

[jr] Re: categorising objects [1096 days 16 hours and 34 minutes ago]

Thu, 6 Apr 2023 12:15:00 GMT

hi,

thanking everyone for the links and suggestions, looking at stuff helped some
(may have :-)).

the following then is another draft, "RFC" etc.  thanks.


Areas of Interest
    Abstract Forms
    Buildings/Architecture
        Domestic
        Commercial
        Industrial
            Interior
            Exterior
    Household/Office Objects
        Furniture
        Furnishings/Decor
            Office
            Living room
            Kitchen
            Bathroom
            Bedroom
        Computers
    Games
        Ball Games
        Board Games
        Puzzles
        Video Games
    Landscapes
        Urban Landscapes
        Natural Landscapes
        Alien/SF Landscapes
    Organic Forms
        Terrestrial Flora
        Terrestrial Fauna
        Alien/SF Flora
        Alien/SF Fauna
            Microscopic
    Space
        Terrestrial
        Alien/SF
    Sports
    Vehicles
        Aircraft
        Watercraft
        Rail
        Road
            Military
    Characters
        Animal
        Pet
        Humanoid
        Robot
    Gadgets
    Scale Model
Contribution Types
    Objects
        Solid (CSG-able)
        Non-solid (Non-CSG-able)
    Materials
    Textures
        Pigments
        Finishes
        Normals
    Interiors
        Media
    Macros
    Functions
        Isosurface
        Positioning
        Other
    Transforms
    Cameras
Uncategorised


regards, jr.

[jr] Re: Object Collection rules review [1098 days 10 hours and 14 minutes ago]

Tue, 4 Apr 2023 18:35:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> The main considerations are the license, namespace compliance, and what
> files should be bundled.
>
> TL;DR
> -----
> - All modules must be licensed under the LGPL.
> - All modules have a unique name and an optional unique prefix.
> - All filenames and most identifiers must be prefixed with the module
>   name or prefix to avoid namespace collisions with other Object
>   Collection modules.
> - Scene files and include files may contain ASCII only.
> - Your submission should include a sample image and a 160x120 thumbnail.

the GNU/CC licensing and the ASCII only issues have been mentioned, and, final
decision pending, will be acted on.  there is one new, added requirement now:
the descriptive text, ideally including documentation and scene/.inc file
comments, is expected to be in English.

the reason is a legacy of several dozen objects submitted in Spanish, only.
those will likely remain unavailable until translated.  (any native speakers, or
fluent + conversant with Central American cultures, with a little time on their
hands ?  ;-))

> ConvexLens, TextureGen, and TextureGen4.  These 3 modules should *not*
> share a directory with other Object Collection downloads.  Two other
> modules were once self-rated as non-compliant, but they have since been
> edited into full compliance.  ...

so, in the "legacy" data for TextureGen I see three versions, with the following
'standardsconformance:status' values recorded (in order): 3:2, 0:1, 1:1.  :-(

seems to me that when an administrator assesses an object / version for
compliance, all versions need taking into account, and there should only be "one
score", per object ?

(if you have a "private" list of assessments of various contributions, that
could (perhaps) serve as base going forward (o/wise most of the db's content
will remain "self-assessed"))

regards, jr.

[yesbird] Re: categorising objects [1100 days 14 hours and 40 minutes ago]

Sun, 2 Apr 2023 14:09:20 GMT

On 02/04/2023 10:49, jr wrote:
> kitchen, yes, will take that.  (more please)
I looked through this classification, maybe we can use some categories
from it ?

https://www.printables.com/model?category=3
--
YB

[jr] Re: categorising objects [1100 days 20 hours and 59 minutes ago]

Sun, 2 Apr 2023 07:50:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> ... Maybe we can use this property as a tag, ...

yes.  the "rocket", for instance, would then be vehicles, rail and scale model.

(was initially thinking of using 'replica' but like 'scale model' better :-))

"Bald Eagle" <cre### [at] netscapenet> wrote:
> An orange stapler.

maybe we should keep to primary colours, to avoid pulling in 'colors.inc'.  ;-)

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> Humanoids can include aliens as well as terrestrial humans.  ...

agree.  the problem is .. constructing a useful and inclusive hierarchy w/out
"redundant" stuff (find "naming" things difficult)

> How about "Kitchen Items"?

kitchen, yes, will take that.  (more please)

> "Microbes" could round this out.  There is already a coronavirus in the
> collection.

perhaps some 4th level 'microscopic' and 'macroscopic' ?  that said, the whole
'organic forms' "tree" needs revising, bettering.

thanks for all the comments, so far.

regards, jr.

[Cousin Ricky] Re: categorising objects [1101 days 8 hours and 54 minutes ago]

Sat, 1 Apr 2023 19:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> unsure of 'humanoid', in that group.  ought the OC have a 'person/character'
> category at level '2', perhaps with further sub-categories ?

Humanoids can include aliens as well as terrestrial humans.  Of course, the
likelihood of an actual ETI resembling humans is slim to none, but humanoid ETIs
are all over science fiction, an science fiction is all we have to go on, until
some real ETI shows up.

(I mead a *real* ETI.  Not a Frisbee, not a top secret military project, not a
reflection of a streetlight in your car window, not the planet Venus, and not
some hallucination/repressed fantasy of being probed.)

> more feedback will be appreciated, I feel the 'household/office objects'
> category (at least) needs .. something.

How about "Kitchen Items"?

>     Organic Forms
>         Humanoid
>         Terrestrial Flora
>         Terrestrial Fauna
>         Alien/SF Flora
>         Alien/SF Fauna

"Microbes" could round this out.  There is already a coronavirus in the
collection.

[Bald Eagle] Re: categorising objects [1101 days 13 hours and 59 minutes ago]

Sat, 1 Apr 2023 14:50:00 GMT

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

> more feedback will be appreciated, I feel the 'household/office objects'
> category (at least) needs .. something.

An orange stapler.

[yesbird] Re: categorising objects [1101 days 17 hours and 15 minutes ago]

Sat, 1 Apr 2023 11:34:23 GMT

On 01/04/2023 14:01, jr wrote:
> thanks (still room for improvement, though :-)).  I guess I'm thinking of
> projects like 'Ton' does, eg.
>
<https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d05f9ab6bc50fb5939601860%40news.povray.org%3E/>
Aaa ! Yes, now I understand your idea, but it seems to me that scaled
models can be of different categories too. Maybe we can use this
property as a tag, or similar to mark objects in other categories ?
--
YB

[jr] Re: categorising objects [1101 days 17 hours and 44 minutes ago]

Sat, 1 Apr 2023 11:05:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> I like this hierarchy, but only one question: what is a "Scale Model"
> category ?

thanks (still room for improvement, though :-)).  I guess I'm thinking of
projects like 'Ton' does, eg.
<https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d05f9ab6bc50fb5939601860%40news.povray.org%3E/>

regards, jr.

[yesbird] Re: categorising objects [1101 days 18 hours and 3 minutes ago]

Sat, 1 Apr 2023 10:46:24 GMT

On 01/04/2023 13:25, jr wrote:
Hi,
I like this hierarchy, but only one question: what is a "Scale Model"
category ?
--
YB

[jr] Re: categorising objects [1101 days 18 hours and 19 minutes ago]

Sat, 1 Apr 2023 10:30:00 GMT

hi,

an amended list of categories, for review.
Kenneth is right of course, there needs to be some type of "catch all" category.
rather than 'miscellaneous' I chose to use 'uncategorised'; the idea is that if
an author should feel none of the existing categories apply, they can use
'uncategorised' and send an email to admin, with the keyword(s) or phrase(s)
they wanted to see,
it will then be up to an administrator to decide on an action.

the 'organic forms' stuff is in part (I guess) a result of Mike Miller's
phosphorescent "buds" :-)

unsure of 'humanoid', in that group.  ought the OC have a 'person/character'
category at level '2', perhaps with further sub-categories ?

more feedback will be appreciated, I feel the 'household/office objects'
category (at least) needs .. something.


Areas of Interest
    Abstract Forms
    Buildings/Architecture
        Domestic
        Commercial
        Industrial
            Interior
            Exterior
    Household/Office Objects
        Computers
    Games
        Ball Games
        Board Games
        Puzzles
        Video Games
    Landscapes
        Urban Landscapes
        Natural Landscapes
        Alien/SF Landscapes
    Organic Forms
        Humanoid
        Terrestrial Flora
        Terrestrial Fauna
        Alien/SF Flora
        Alien/SF Fauna
    Space
        Terrestrial
        Alien/SF
    Sports
    Vehicles
        Aircraft
        Watercraft
        Rail
        Road
            Military
    Scale Model
Contribution Types
    Objects
        Solid (CSG-able)
        Non-solid (Non-CSG-able)
    Materials
    Textures
        Pigments
        Finishes
        Normals
    Interiors
        Media
    Macros
    Functions
        Isosurface
        Positioning
        Other
    Transforms
    Cameras
Uncategorised


regards, jr.

[yesbird] Re: categorising objects [1112 days 19 hours and 34 minutes ago]

Tue, 21 Mar 2023 09:14:29 GMT

On 21/03/2023 10:38, William F Pokorny wrote:
> Have you looked at the categories offered by some of the online 3D model 
> / material sites ?Â  For example: www.turbosquid.com

Indeed, or my favorite:
https://www.cgtrader.com
(attached)
--
YB

[Thomas de Groot] Re: categorising objects [1112 days 21 hours and 10 minutes ago]

Tue, 21 Mar 2023 07:38:34 GMT

Op 20/03/2023 om 21:15 schreef jr:
> hi,
> 
> am somewhat disappointed, no one (bar two honourable exceptions) interested much
> in improving the OC ?!  tja..  there's some time still, so help will be welcome
> (and needed, as "decisively classifying" things isn't one of my strengths)
> 
> 
To tell the truth, I have no idea what to answer. Except for very 
general categories, I would not go into too much details (at this moment 
in time and content of the Collection). If in future further 
subdivisions would become necessary, then would be the time to implement 
them.

-- 
Thomas

[William F Pokorny] Re: categorising objects [1112 days 21 hours and 11 minutes ago]

Tue, 21 Mar 2023 07:38:13 GMT

On 3/20/23 16:15, jr wrote:
> am somewhat disappointed, no one (bar two honourable exceptions) interested much
> in improving the OC ?!  tja..  there's some time still, so help will be welcome
> (and needed, as "decisively classifying" things isn't one of my strengths)

Interested, just lots of other stuff to do too... (My qualifications as 
honorable are questionable too, as you know...)

Have you looked at the categories offered by some of the online 3D model 
/ material sites ?  For example: www.turbosquid.com

If not already suggested, I feel a strength of POV-Ray is the quick 
abstract image, the quick icon. These are not really objects I guess, 
but I find them interesting. Well, we could require they be framed! :-)
Maybe such a category would get noisy / swamped though...

Bill P.

[jr] Re: categorising objects [1113 days 8 hours and 29 minutes ago]

Mon, 20 Mar 2023 20:20:00 GMT

hi,

am somewhat disappointed, no one (bar two honourable exceptions) interested much
in improving the OC ?!  tja..  there's some time still, so help will be welcome
(and needed, as "decisively classifying" things isn't one of my strengths)

yesbird <sya### [at] gmailcom> wrote:
> On 14/03/2023 12:40, jr wrote:
> Hi,
> I would include some additional categories, for better detalization:
> ...
> >      Landscapes
> >          Urban Landscapes
>             Nature Landscapes
>                 Mountains
>                 Forests
>                 Desert
>                 ...
> >      Organic Forms
>             Flora
>                 Trees
>                 Flowers
>                 Grass
>                 ...
>             Fauna
>                 Animals
>                 Birds
>                 Insects
>                 ...
>         Technics
>             Constructions
>             Fasteners
>             Aerospace
>             Vehicles
>             ...
> >      Space
> > ...

I'll take the 'natural landscapes', and like the 'flora/fauna' under organic
forms.  the "Technics" is a bit "all over" :-), but would like to see your
revised take on those/any categories.

"Kenneth" <kdw### [at] gmailcom> wrote:
> I would add a 'Miscellaneous' category. I can foresee some contributions that
> might not fall under any specific heading-- although I can't think of an example
> off-hand.

personally, and by inclination, I'd agree.  just .. convenient.  but that also
is its downside, it would wind up an overused catch-all, I feel.

> >     Games
> >         Ball Games
> >         Board Games
> >         Puzzles
> >         Video Games
>
> This might be an example of a too-detailed list. I would think that just 'Games'
> would do.

not sure, feel puzzles ought not to be seen as "games", however, you probably
know that on submission you could select, say, just 'Games' and be done.

> ...
> mountains, forests, planetary surfaces, etc etc-- which might make a detailed
> sub-listing endlessly long and too 'granular'.

multiple categories can and should be selected, so "medium granularity" :-) at
least will be ok.  using YB's initial suggestion of flora + fauna as example, I
think that's probably "deep" enough in levels.  on the other hand, the
'Household/Office Objects' (which ought not have been "lumped together" in the
first place) does need stuff like 'Furniture' and quite a few others to make it
useful at all; as mentioned, up to four "levels", but getting the second + third
tier right will be the art.

regards, jr.

[Kenneth] Re: categorising objects [1118 days 15 hours and 14 minutes ago]

Wed, 15 Mar 2023 13:35:00 GMT

I would add a 'Miscellaneous' category. I can foresee some contributions that
might not fall under any specific heading-- although I can't think of an example
off-hand.
>
> Areas of Interest
>...
>     Games
>         Ball Games
>         Board Games
>         Puzzles
>         Video Games

This might be an example of a too-detailed list. I would think that just 'Games'
would do.

>     Landscapes
>         Urban Landscapes

Same here. 'Landscapes' by itself might be inclusive enough. There are probably
LOTS of different types of landscapes that contributors could come up with--
mountains, forests, planetary surfaces, etc etc-- which might make a detailed
sub-listing endlessly long and too 'granular'.

[yesbird] Re: categorising objects [1119 days 17 hours and 7 minutes ago]

Tue, 14 Mar 2023 11:41:34 GMT

On 14/03/2023 12:40, jr wrote:
Hi,
I would include some additional categories, for better detalization:
//---------------------------------------------------------------------
> 
> Areas of Interest
>      Abstract Forms
>      Buildings
>      Household/Office Objects
>          Computers
>      Games
>          Ball Games
>          Board Games
>          Puzzles
>          Video Games
>      Landscapes
>          Urban Landscapes
            Nature Landscapes
                Mountains
                Forests
                Desert
                ...
>      Organic Forms
            Flora
                Trees
                Flowers
                Grass
                ...
            Fauna
                Animals
                Birds
                Insects
                ...
        Technics
            Constructions
            Fasteners
            Aerospace
            Vehicles
            ...
>      Space
>      Sports
> Contribution Types
>      Objects
>          Solid (CSG-able)
>          Non-solid (Non-CSG-able)
>      Textures
>          Pigments
>          Finishes
>          Normals
>      Interiors
>          Media
>      Macros
>      Functions
>          Isosurface
>          Positioning
>          Other
//---------------------------------------------------------------------
--
YB

[jr] categorising objects [1119 days 19 hours and 4 minutes ago]

Tue, 14 Mar 2023 09:45:00 GMT

hi,

submissions to the Object Collection must be categorised, selecting one or more
applicable categories from a list.  the current list, imo, needs improving.  to
that end I've listed the existing below, the level of indentation corresponding
to 'Level' in the hierarchy.  asking all interested parties to discuss, and
propose additional entries.  thanks in advance.  nb adding a fourth level would
be ok and work with the existing code, as would partially re-ordering the below
(if needed).


Areas of Interest
    Abstract Forms
    Buildings
    Household/Office Objects
        Computers
    Games
        Ball Games
        Board Games
        Puzzles
        Video Games
    Landscapes
        Urban Landscapes
    Organic Forms
    Space
    Sports
    Vehicles
Contribution Types
    Objects
        Solid (CSG-able)
        Non-solid (Non-CSG-able)
    Textures
        Pigments
        Finishes
        Normals
    Interiors
        Media
    Macros
    Functions
        Isosurface
        Positioning
        Other


regards, jr.

[jr] Re: Object Collection rules review [1127 days 22 hours and 19 minutes ago]

Mon, 6 Mar 2023 06:30:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> >>> LICENSE
> >>>
> I am not proposing that we move away from the LGPL.  I'm thinking that
> the upload software could accept "GNU-LGPL" as well as "CC-LGPL," that
> the phrase "Creative Commons" be dropped from the documentation on
> lib.povray.org, and that the documentation link directly to gnu.org.
> But as long as the Creative Commons link redirects to gnu.org, this is
> not a major issue.

after a cursory look at the code, I think the upload could be modified to accept
either with little work.  re the whole issue, decisions are for Chris, will
bring it up at the earliest opportunity.

regards, jr.

[Kenneth] Re: Fish14 POV scene file and maps [1128 days 7 hours and 29 minutes ago]

Sun, 5 Mar 2023 21:20:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> Attached is the Fish14 POV scene file and maps.
> Work in progress - I need to look at SSS for the fin textures.

An updated 'fish13'?! I'm in heaven. :-D  I intend to play around with it-- to
see what new tricks an old dog like me can learn. Your ORIGINAL file certainly
helped me, all those years ago.

Thanks, Mike!

[Cousin Ricky] Re: Object Collection rules review [1128 days 13 hours and 27 minutes ago]

Sun, 5 Mar 2023 15:22:06 GMT

On 2023-03-02 21:37 (-4), Cousin Ricky wrote:
> 
> There are other considerations, such as keyword list and topic
> categories, but these will not be important to detail until the Object
> Collection site comes back online.  If you are interested, the upload
> instruction page is archived at:
> 
>
https://web.archive.org/web/20150923194204/http://lib.povray.org/usersguide/04contributing.html
> 
> Note that these instructions have an incorrect name for the license.
> The name has been corrected since that page was last archived.

I got some files mixed up in my mind.  The README file that comes with
each download has been updated.  I cannot tell if the instructions have
been updated.

[Cousin Ricky] Re: Object Collection rules review [1128 days 13 hours and 48 minutes ago]

Sun, 5 Mar 2023 15:01:08 GMT

On 2023-03-05 03:31 (-4), jr wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I have additional comments on these rules.
>>
>> On 2023 21:37 (-4), Cousin Ricky wrote:
>>>
>>> LICENSE
>>> [snip]
>>>   This file is licensed under the terms of the CC-LGPL
>>>
>>> This exact wording is required by the upload software; you will not be
>>> allowed to upload your module without it.  The "CC" is due to Creative
>>> Commons having once provided an online deed for the GNU licenses.
>>
>> Creative Commons has since removed the deed from their website, and the
>> link now redirects to gnu.org.  It has been proposed that the "CC" be
>> removed, but the upload software had not been updated to accept this as
>> of the time of the crash.
> 
> so what, exactly, are/ought-to-be the implications?  the submission as such, and
> aiui, would still require some form of (permissive) licensing by the author(s).
> what, ideally, would the check upon upload look for?

I am not proposing that we move away from the LGPL.  I'm thinking that
the upload software could accept "GNU-LGPL" as well as "CC-LGPL," that
the phrase "Creative Commons" be dropped from the documentation on
lib.povray.org, and that the documentation link directly to gnu.org.
But as long as the Creative Commons link redirects to gnu.org, this is
not a major issue.

[jr] Re: Object Collection rules review [1128 days 21 hours and 14 minutes ago]

Sun, 5 Mar 2023 07:35:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have additional comments on these rules.
>
> On 2023 21:37 (-4), Cousin Ricky wrote:
> >
> > LICENSE
> > [snip]
> >   This file is licensed under the terms of the CC-LGPL
> >
> > This exact wording is required by the upload software; you will not be
> > allowed to upload your module without it.  The "CC" is due to Creative
> > Commons having once provided an online deed for the GNU licenses.
>
> Creative Commons has since removed the deed from their website, and the
> link now redirects to gnu.org.  It has been proposed that the "CC" be
> removed, but the upload software had not been updated to accept this as
> of the time of the crash.

so what, exactly, are/ought-to-be the implications?  the submission as such, and
aiui, would still require some form of (permissive) licensing by the author(s).
what, ideally, would the check upon upload look for?


regards, jr.

[Tor Olav Kristensen] Re: Set of scalable colormaps recommended for sc... [1130 days 14 hours and 9 minutes ago]

Fri, 3 Mar 2023 14:40:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2023-03-01 20:29, Tor Olav Kristensen wrote:
> >
> > I was just a bit surprised when I saw that license, since the license
> > for Inferno, Plasma and Viridis seems to be CC0 (i.e. no copyright).
>
> It may not make much practical difference, but this is better phrased as
> "copyright waived."  In some jurisdictions it is not legally possible to
> give up your copyright, thus the need for dedication licenses such as CC0.

I think that this is a rather strange license.

IIRC Norway is such a jurisdiction where it's not possible to
renounce one's copyright.

On the Wikipedia page I linked to there's a "Open-source software
licenses and how they interact" diagram. If I interpret this
diagram correctly, then it seems that it is actually ok to use
LGPL for works derived from something in the public domain.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[yesbird] Re: Object Collection rules review [1130 days 16 hours and 43 minutes ago]

Fri, 3 Mar 2023 12:05:49 GMT

On 03/03/2023 04:37, Cousin Ricky wrote:
> I see that there is interest in the Object Collection among new users
> and old timers who have returned.  You may or may not know that the
> Object Collection is a formal repository that was hosted on an entire
> subdomain of povray.org, namely lib.povray.org.

Hi,
Thank you for this review, I really didn't know about the formal side of
this group. Now I see that this is the wrong place for my previous
posts, sorry for the inconvenience.
--
YB

[jr] Re: Object Collection rules review [1130 days 17 hours and 19 minutes ago]

Fri, 3 Mar 2023 11:30:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> a site-wide server crash, and while most of the site was quickly
> restored (mostly), lib.povray.org remains offline.
> ...

for now, yes.  however, it "is being looked at".

> The initial administrator of the Object Collection has not been heard
> from since 2009, and there has been no successor.  So far as I can see,
> there is no formal process in place for overseeing the collection.  See
? the thread "License reassessment and other matters" for my thoughts on
> this situation.

I share the impression that the OC has been handled without such a laid down
procedure/process.  quick scan in 200 most recent threads did not find the
above, will try find/read it.  thoughts on how (future) administration
can/should be made more "robust" will be useful/appreciated (but see below).

> LeForgeron's mirror does not record the compliance level of the modules,
> but from the information I had collected previously, all of the
>  contributions were self-rated at level 3 except for the following:
> ConvexLens, TextureGen, and TextureGen4.  These 3 modules should *not*
> share a directory with other Object Collection downloads.

thank you.  will look at the "self-rated" vs confirmed.

> As of the time of the crash, the upload software allowed only 7-bit
> ASCII characters in .inc and .pov files.

ok, thanks.  will add some utf8 to the "mock" object I use while working on
submission.

fyi.  since the crash, no one had (apparently) offered help restoring it (Chris
is .. running at capacity much of the time, aiui), so late last year I jumped
in.  fwiw, it (site code) is an excellent example of why code ought not be
"intertwined" with global variables.  anyway, there were[*] other, real problems
regarding the database, it seems that at least one of those with admin access
missed their calling as comedian. :-(  it seemed opportune to move the OC db
from the server-based implementation to a file-backed one, without changes to
the UI as such (except fewer admin options).  the current state of things: a
fair few things done, but more still to do.  (sorry to be so .. oblique)

[*] and, to an extent, continue to be.  would, personally, prefer the db schema
fully normalised, but cannot afford to break the Javascript + stuff.

admin changes - little from the web UI, only suspending versions/users/feedback
and "health check", for all else person will have to log in to an admin account,
and use utility(-ies) provided.

regards, jr.

[Cousin Ricky] Re: Object Collection rules review [1131 days 2 hours and 22 minutes ago]

Fri, 3 Mar 2023 02:27:15 GMT

I have additional comments on these rules.

On 2023 21:37 (-4), Cousin Ricky wrote:
> 
> LICENSE
> [snip]
>   This file is licensed under the terms of the CC-LGPL
> 
> This exact wording is required by the upload software; you will not be
> allowed to upload your module without it.  The "CC" is due to Creative
> Commons having once provided an online deed for the GNU licenses.

Creative Commons has since removed the deed from their website, and the
link now redirects to gnu.org.  It has been proposed that the "CC" be
removed, but the upload software had not been updated to accept this as
of the time of the crash.

> NAMESPACE COMPLIANCE
> [snip]
> 
>  2. [snip]  Due to namespace scope leakage
>     within POV-Ray, this rule must also apply to #local identifiers and
>     any function formal parameters other than u, v, x, y, and z.
> [snip]
> 
> The modules are currently self-rated by the author.  If the author rates
> their module at compliance level 3, the upload software will reject
> filenames that are out of compliance.  Identifiers are not scanned for
> compliance at this time.

Note that identifier name collisions are possible even with modules
self-rated at level 3.  There was some sort of process for verifying
compliance, the details of which I do not know, but the only modules so
"verified" happen to have been submitted by the administrator
himself--in other words, *none* of the modules can be considered
verified.  As my father once told me, "A priest does not hear his own
confession."

I am very careful about keeping my own contributions level 3 compliant,
yet I have discovered noncompliance in my own code.  To my knowledge, no
one has independently verified my modules, so there could still be some
stray violations.  And I know for a fact that some other contributors
have been less diligent than I.  Caveat emptor.

Add to this, that the scope leakage of #local variables was not
discovered until about 50 modules had already been contributed, so many
of those were rendered de facto non-compliant when the rule was changed.
 Thus far, function formal parameters are not specifically addressed in
the Object Collection rules, but these newsgroups are scattered with
POVers who have been burned by using an identifier that just *happened*
to share a name with a function parameter in some include file.  Caveat
emptor.

LeForgeron's mirror does not record the compliance level of the modules,
but from the information I had collected previously, all of the
contributions were self-rated at level 3 except for the following:
ConvexLens, TextureGen, and TextureGen4.  These 3 modules should *not*
share a directory with other Object Collection downloads.  Two other
modules were once self-rated as non-compliant, but they have since been
edited into full compliance.  All remaining modules are fully filename
compliant, and may share a single directory, even if their identifiers
are not compliant.  All this is to say that you'll probably want to make
your contributions namespace compliant as well.

> CONTENTS OF SDL FILES
> ---------------------
> As of the time of the crash, the upload software allowed only 7-bit
> ASCII characters in .inc and .pov files.

I hope this will change.

[Cousin Ricky] Object Collection rules review [1131 days 3 hours and 12 minutes ago]

Fri, 3 Mar 2023 01:37:25 GMT

I see that there is interest in the Object Collection among new users
and old timers who have returned. You may or may not know that the
Object Collection is a formal repository that was hosted on an entire
subdomain of povray.org, namely lib.povray.org. Early in 2021 there was
a site-wide server crash, and while most of the site was quickly
restored (mostly), lib.povray.org remains offline.

Most of the user contributions have been mirrored at
https://github.com/LeForgeron/PovContributions
but the infrastructure of lib.povray.org, which included user
registration, upload, search, and general instructions, is not
duplicated there.

As a formal repository, the Object Collection has certain rules. If you
wish to submit your objects to lib.povray.org when it comes back online,
you'll need to be familiar with these rules to make whatever edits are
necessary to prepare your files for submission. I will summarize them here.

The main considerations are the license, namespace compliance, and what
files should be bundled.

TL;DR
-----
- All modules must be licensed under the LGPL.
- All modules have a unique name and an optional unique prefix.
- All filenames and most identifiers must be prefixed with the module
name or prefix to avoid namespace collisions with other Object
Collection modules.
- Scene files and include files may contain ASCII only.
- Your submission should include a sample image and a 160x120 thumbnail.

LICENSE
-------
All contributions must be licensed under the GNU Lesser General Public
License (LGPL). To that effect, every .inc and .pov file must contain a
comment with this text:

This file is licensed under the terms of the CC-LGPL

This exact wording is required by the upload software; you will not be
allowed to upload your module without it. The "CC" is due to Creative
Commons having once provided an online deed for the GNU licenses.

If you borrow someone else's work, you will need to certify that you
have the legal right to republish it under the LGPL.

You will note that the above required text does not specify a license
version. However, the link in the Object Collection documentation
(currently offline) does point specifically to version 2.1 of the LGPL.
No formal decision has been made about upgrading to version 3.0.

MODULE NAMES
------------
Every module has a unique name and, optionally, an additional unique
prefix, which are registered with the upload software. The names and
prefixes must begin with a Latin letter and comprise only letters and
digits--the same rules as for POV-Ray identifiers, except underscores
are not allowed. The name and prefix are not case sensitive; for
example, if there is a module called "NetBall," it is not allowed to
create a new module called "NETball."

NAMESPACE COMPLIANCE
--------------------
One of the goals of the Object Collection is interoperability. The
Collection has naming standards to avoid namespace conflicts between
modules. Modules are rated for compliance on a scale of 0 (not at all
compliant) to 3 (fully compliant). By default, only level 3 modules
appeared in search results.

For compliance level 3:

1. All filenames must begin with the module name or prefix, followed
by either a dot or an underscore. This allows all level 3 modules
to share the same directory, so your Library_Path list doesn't grow
out of hand. Filenames should be all lowercase for operating
system portability.

For example, if the name and prefix are NetBall and NB,
respectively, then netball.inc and nb_example.pov are acceptable
filenames. netball1.pov and nb-example would not be accepted, as
the name or prefix is followed by a character other than a dot or
an underscore.

2. All identifiers introduced in the main library files must be the
module name or prefix, or must be prefixed with the module name or
prefix followed by an underscore. Due to namespace scope leakage
within POV-Ray, this rule must also apply to #local identifiers and
any function formal parameters other than u, v, x, y, and z. Macro
formal parameter names are exempt from this rule, as are any demo
scene description files you may bundle to demonstrate how to use
your module.

Using the above example, Netball and NB_BallRadius are acceptable
identifier names, but NBRadius is not.

3. A third rule that has been proposed, but not formally adopted, is
to require all identifiers to have at least one uppercase letter.

The modules are currently self-rated by the author. If the author rates
their module at compliance level 3, the upload software will reject
filenames that are out of compliance. Identifiers are not scanned for
compliance at this time.

No detailed guidance has been provided for self-rating your module at
compliance level 1 or 2.

FILES TO BUNDLE WITH YOUR SUBMISSION
------------------------------------
These are not hard and fast rules, but are typical of Object Collection
contributions.

- A .inc file containing the necessary macros and other features.

- An example .pov scene description file demonstrating how to use your
module.

- A 160 by 120 pixel thumbnail image to be displayed on the Object
Collection search page and index page. The name of this file must be
the module name or prefix, followed immediately by _thumbnail, dot,
and the image type extension; for example, netball_thumbnail.jpg or
nb_thumbnail.png.

- A main image file to be linked to the thumbnail. The name of this
file must be the module name or prefix, followed immediately by dot
and the image type extension; for example, netball.jpg or nb.png.

- HTML documentation. In order to be automatically linked to the Object
Collection search page and index page, the name of the file must be
the module name or prefix, followed immediately by .html; for example,
netball.html or nb.html.

HTML documentation is optional; many existing contributions just have
the documentation as a block comment within the main include file.

Files are limited to the following types: .bmp, .css, .csv, .gif, .htm,
.html, .inc, .ini, .jpeg, .jpg, .js, .mac, .mcr, .mdl, .pgm, .png, .pov,
.ppm, .tga, .tif, .tiff, .txt

CONTENTS OF SDL FILES
---------------------
As of the time of the crash, the upload software allowed only 7-bit
ASCII characters in .inc and .pov files. Greek, Cyrillic, special
characters, etc. could only be used via the "\u" notation. For an
example of this, see:
https://github.com/CousinRicky/POV-BrightStar5/blob/main/brightstar5.inc
and find bsc5__s_Gr_chars.

OTHER CONSIDERATIONS
--------------------
There are other considerations, such as keyword list and topic
categories, but these will not be important to detail until the Object
Collection site comes back online. If you are interested, the upload
instruction page is archived at:

https://web.archive.org/web/20150923194204/http://lib.povray.org/usersguide/04contributing.html

Note that these instructions have an incorrect name for the license.
The name has been corrected since that page was last archived.

ADMINISTRATION
--------------
The initial administrator of the Object Collection has not been heard
from since 2009, and there has been no successor. So far as I can see,
there is no formal process in place for overseeing the collection. See
the thread "License reassessment and other matters" for my thoughts on
this situation.

[Paolo Gibellini] Re: Yes-library [1131 days 6 hours and 50 minutes ago]

Thu, 2 Mar 2023 21:59:28 GMT

Il 01/03/2023 16:29, Alain Martel ha scritto:
> Le 2023-03-01 Ã  01:39, Mike Miller a Ã©crit :
>> yesbird <sya### [at] gmailcom> wrote:
>>> On 23/02/2023 01:42, yesbird wrote:
>>>> Here I'm starting a collection of static and animated objects,
>>>> inspired by Roger Dean's artworks:
>>>> https://github.com/syanenko/pov-yes
>>>
>>> #6 - Spiral path
>>> --YB
>>
>> Hi Yesbird.
>> Hope all is well.
>>
>> While converting my old Fish13 I spent some time finding a better way 
>> to handle
>> some of the forms I used. I picked a method similar to CTDS with a lot 
>> less data
>> points. I'm using sphere_sweep cubic_splines for the body and pointy 
>> spine
>> shapes and 'sliced' lathe cubic splines for the fin parts. I wrote a 
>> CAD utility
>> for each type that converts the circle positions and radius to POV 
>> syntax. In
>> that process I've creating new fish model that you can use if you like.
>>
>> I'll post a zip file with the POV file and images maps used in
>> 'object-collection'.
>> Mike.
>>
> You are not supposed to post photos.ðŸ˜
Awesome Rolex!

[Cousin Ricky] Re: Set of scalable colormaps recommended for sc... [1131 days 7 hours and 33 minutes ago]

Thu, 2 Mar 2023 21:16:18 GMT

On 2023-03-01 20:29, Tor Olav Kristensen wrote:
> 
> I was just a bit surprised when I saw that license, since the license
> for Inferno, Plasma and Viridis seems to be CC0 (i.e. no copyright).

It may not make much practical difference, but this is better phrased as
"copyright waived."  In some jurisdictions it is not legally possible to
give up your copyright, thus the need for dedication licenses such as CC0.

[yesbird] Re: Set of scalable colormaps recommended for sc... [1132 days 3 hours and 57 minutes ago]

Thu, 2 Mar 2023 00:51:52 GMT

On 02/03/2023 03:29, Tor Olav Kristensen wrote:
> Inferno and Plasma was made by Stefan van der Walt and Nathaniel Smith,
> while Viridis was made by Eric Firing and then modified by Stefan van
> der Walt and Nathaniel Smith.
Thanks a lot for this info, I had to find it myself, not you :)

> I recommend that you try to find the original author of each of the
> other color maps and then try to find out if they specified any
> licenses for their code. - Yes; that is probably a lot of work with
> that many color maps.
Agree with you, this work should be done, it's better to do everything
correctly.

> Here's a Wikipedia page that might be useful for you, especially the
> section about compatibility, if you are going to use licenses that are
> different that the ones the original authors specified:
> 
> https://en.wikipedia.org/wiki/Open-source_license
Thanks again, I will read it, in any case it's better to know all
licensing rules for the future.
--
YB

[Tor Olav Kristensen] Re: Set of scalable colormaps recommended for sc... [1132 days 4 hours and 14 minutes ago]

Thu, 2 Mar 2023 00:35:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 01/03/2023 20:56, Tor Olav Kristensen wrote:
> > But are you sure that the "GNU Affero General Public License v3.0" compatible
> > with the licenses from the initial authors?
> >
> > And are you aware that this license is more strict than the original licenses
> > that came with some of the color maps?
> Hi, Tor.
> Thank you for pointing me to this potential problem, I thought about it,
> but unfortunately too far from licensing details. If you have more info
> about that, maybe you can suggest to me the license that will 'best-fit'
> to this publication ? If not, I will need to explore this area more
> seriously.

Note that I'm not claiming that there is a problem - and I do not know
much about copyright law.

I was just a bit surprised when I saw that license, since the license
for Inferno, Plasma and Viridis seems to be CC0 (i.e. no copyright).

https://github.com/BIDS/colormap
http://creativecommons.org/publicdomain/zero/1.0

Inferno and Plasma was made by Stefan van der Walt and Nathaniel Smith,
while Viridis was made by Eric Firing and then modified by Stefan van
der Walt and Nathaniel Smith.

I recommend that you try to find the original author of each of the
other color maps and then try to find out if they specified any
licenses for their code. - Yes; that is probably a lot of work with
that many color maps.

Here's a Wikipedia page that might be useful for you, especially the
section about compatibility, if you are going to use licenses that are
different that the ones the original authors specified:

https://en.wikipedia.org/wiki/Open-source_license

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[yesbird] Re: Set of scalable colormaps recommended for sc... [1132 days 10 hours and 24 minutes ago]

Wed, 1 Mar 2023 18:25:13 GMT

On 01/03/2023 20:56, Tor Olav Kristensen wrote:
> But are you sure that the "GNU Affero General Public License v3.0" compatible
> with the licenses from the initial authors?
> 
> And are you aware that this license is more strict than the original licenses
> that came with some of the color maps?
Hi, Tor.
Thank you for pointing me to this potential problem, I thought about it,
but unfortunately too far from licensing details. If you have more info
about that, maybe you can suggest to me the license that will 'best-fit'
to this publication ? If not, I will need to explore this area more
seriously.

> Also, I think that the original authors will appreciate it if you give them some
> credit by mentioning their names somewhere in the code or on the repository
> page.
This is a good idea, will do it for sure.

All the best,
--
YB

[Tor Olav Kristensen] Re: Set of scalable colormaps recommended for sc... [1132 days 10 hours and 49 minutes ago]

Wed, 1 Mar 2023 18:00:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> This is a set of ready-to-use colormaps, each contains 256 colors. Most
> of them exported from Matlab, other from this page:
> https://www.kennethmoreland.com/color-advice/
>
> Color information stored in 2D array, colormaps are generating by the
> macro, allowing re-scaling and applying desired transparency.
> Usage examples also present.
>
> Download: https://github.com/syanenko/Colormaps

Hi YB

It's good that you have now included a license file in this repository and that
you mention where the color maps came from.

But are you sure that the "GNU Affero General Public License v3.0" compatible
with the licenses from the initial authors?

And are you aware that this license is more strict than the original licenses
that came with some of the color maps?

Also, I think that the original authors will appreciate it if you give them some
credit by mentioning their names somewhere in the code or on the repository
page.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[yesbird] Re: Yes-library [1132 days 12 hours and 56 minutes ago]

Wed, 1 Mar 2023 15:52:44 GMT

On 01/03/2023 17:40, Mike Miller wrote:
> yes, use and texture this fish anyway you'd like. :)
Thanks, I've posted original (at very end):
https://github.com/syanenko/Yes-World
now working on repainting and macro-cloning :)

> I'm re-modeling a few insects that I've Cad'd out using this same method.
Looking forward for new species :)
--
YB

[Alain Martel] Re: Yes-library [1132 days 13 hours and 20 minutes ago]

Wed, 1 Mar 2023 15:29:02 GMT

Le 2023-03-01 Ã  01:39, Mike Miller a Ã©critÂ :
> yesbird <sya### [at] gmailcom> wrote:
>> On 23/02/2023 01:42, yesbird wrote:
>>> Here I'm starting a collection of static and animated objects,
>>> inspiredÂ by Roger Dean's artworks:
>>> https://github.com/syanenko/pov-yes
>>
>> #6 - Spiral path
>> --YB
> 
> Hi Yesbird.
> Hope all is well.
> 
> While converting my old Fish13 I spent some time finding a better way to handle
> some of the forms I used. I picked a method similar to CTDS with a lot less data
> points. I'm using sphere_sweep cubic_splines for the body and pointy spine
> shapes and 'sliced' lathe cubic splines for the fin parts. I wrote a CAD utility
> for each type that converts the circle positions and radius to POV syntax. In
> that process I've creating new fish model that you can use if you like.
> 
> I'll post a zip file with the POV file and images maps used in
> 'object-collection'.
> Mike.
> 
You are not supposed to post photos.ðŸ˜

[Mike Miller] Re: Yes-library [1132 days 14 hours and 4 minutes ago]

Wed, 1 Mar 2023 14:45:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 01/03/2023 09:39, Mike Miller wrote:
> > While converting my old Fish13 I spent some time finding a better way to handle
> > some of the forms I used. I picked a method similar to CTDS with a lot less data
> > points. I'm using sphere_sweep cubic_splines for the body and pointy spine
> > shapes and 'sliced' lathe cubic splines for the fin parts. I wrote a CAD utility
> > for each type that converts the circle positions and radius to POV syntax. In
> > that process I've creating new fish model that you can use if you like.
> Hi, Mike.
>
> Glad to see/read you again. Your new Fish14 is excellent - after
> examining the structure and rendering, I found that it much more
> detailed and realistic, than previous.
>
> I would like to add it to collection in two variants: as you sent it,
> without any modifications and colorized with my gradient techniques -
> can I do it ? Also I like your approach to modelling with schemes,
> I want to add them to the description as they are interesting and well-
> looking too.
>
> You mentioned plugin for CAD and yesterday I wrote the same for my C4D
> to export splines, now thinking about adding spheres. This will
> completely solve the problem of POV editor.
>
> All the best,
> --
> YB


Thanks YB.
yes, use and texture this fish anyway you'd like. :)
I'm re-modeling a few insects that I've Cad'd out using this same method.
Mike.

[yesbird] Re: Yes-library [1132 days 14 hours and 44 minutes ago]

Wed, 1 Mar 2023 14:04:38 GMT

On 01/03/2023 09:39, Mike Miller wrote:
> While converting my old Fish13 I spent some time finding a better way to handle
> some of the forms I used. I picked a method similar to CTDS with a lot less data
> points. I'm using sphere_sweep cubic_splines for the body and pointy spine
> shapes and 'sliced' lathe cubic splines for the fin parts. I wrote a CAD utility
> for each type that converts the circle positions and radius to POV syntax. In
> that process I've creating new fish model that you can use if you like.
Hi, Mike.

Glad to see/read you again. Your new Fish14 is excellent - after
examining the structure and rendering, I found that it much more
detailed and realistic, than previous.

I would like to add it to collection in two variants: as you sent it,
without any modifications and colorized with my gradient techniques -
can I do it ? Also I like your approach to modelling with schemes,
I want to add them to the description as they are interesting and well-
looking too.

You mentioned plugin for CAD and yesterday I wrote the same for my C4D
to export splines, now thinking about adding spheres. This will
completely solve the problem of POV editor.

All the best,
--
YB

[Mike Miller] Re: Yes-library [1132 days 21 hours and 49 minutes ago]

Wed, 1 Mar 2023 07:00:01 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 23/02/2023 01:42, yesbird wrote:
> > Here I'm starting a collection of static and animated objects,
> > inspired by Roger Dean's artworks:
> > https://github.com/syanenko/pov-yes
>
> #6 - Spiral path
> --YB

Here's a screen grab from the CAD process used for fish14.

[Mike Miller] Fish14 POV scene file and maps [1132 days 21 hours and 59 minutes ago]

Wed, 1 Mar 2023 06:50:01 GMT

Attached is the Fish14 POV scene file and maps.
Work in progress - I need to look at SSS for the fin textures.
Mike

[Mike Miller] Re: Yes-library [1132 days 22 hours and 4 minutes ago]

Wed, 1 Mar 2023 06:45:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 23/02/2023 01:42, yesbird wrote:
> > Here I'm starting a collection of static and animated objects,
> > inspired by Roger Dean's artworks:
> > https://github.com/syanenko/pov-yes
>
> #6 - Spiral path
> --YB

Hi Yesbird.
Hope all is well.

While converting my old Fish13 I spent some time finding a better way to handle
some of the forms I used. I picked a method similar to CTDS with a lot less data
points. I'm using sphere_sweep cubic_splines for the body and pointy spine
shapes and 'sliced' lathe cubic splines for the fin parts. I wrote a CAD utility
for each type that converts the circle positions and radius to POV syntax. In
that process I've creating new fish model that you can use if you like.

I'll post a zip file with the POV file and images maps used in
'object-collection'.
Mike.

[yesbird] Re: Yes-library [1134 days 10 hours and 32 minutes ago]

Mon, 27 Feb 2023 18:16:49 GMT

On 23/02/2023 01:42, yesbird wrote:
> Here I'm starting a collection of static and animated objects,
> inspiredÂ by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes

#6 - Spiral path
--YB

[yesbird] Re: Yes-library [1134 days 14 hours and 24 minutes ago]

Mon, 27 Feb 2023 14:25:01 GMT

On 23/02/2023 01:42, yesbird wrote:
> Here I'm starting a collection of static and animated objects,
> inspiredÂ by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes

#5 - Yes-font
--YB

[yesbird] Re: Yes-library [1135 days 6 hours and 31 minutes ago]

Sun, 26 Feb 2023 22:17:56 GMT

On 23/02/2023 01:42, yesbird wrote:
> Here I'm starting a collection of static and animated objects,
> inspiredÂ by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes

#4 - Weed
--
YB

[yesbird] Re: Yes-library [1135 days 9 hours and 33 minutes ago]

Sun, 26 Feb 2023 19:15:57 GMT

On 23/02/2023 01:42, yesbird wrote:
> Here I'm starting a collection of static and animated objects,
> inspiredÂ by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes

#3 - Growing stem (https://www.youtube.com/watch?v=OWSPI5r5Msc)
--
YB

[yesbird] Re: Yes-library [1136 days and 42 minutes ago]

Sun, 26 Feb 2023 04:06:38 GMT

On 23/02/2023 01:42, yesbird wrote:
> Here I'm starting a collection of static and animated objects,
> inspiredÂ by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes

#2 - Fish 13 (https://www.youtube.com/watch?v=NvTMP3XGKms)
--
YB

[yesbird] Re: Yes-library [1136 days and 45 minutes ago]

Sun, 26 Feb 2023 04:04:27 GMT

On 23/02/2023 01:42, yesbird wrote:
> Here I'm starting a collection of static and animated objects,
> inspiredÂ by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes

#1 - Breathing coral (https://www.youtube.com/watch?v=Xfp7ocJBziQ)
--YB

[yesbird] Re: Yes-library [1137 days 7 hours and 38 minutes ago]

Fri, 24 Feb 2023 21:10:56 GMT

On 24/02/2023 23:32, Mike Miller wrote:
> I think these are the right ones
Yes, they are !
Thanks for sharing, will put them into collection.
--
YB

[Mike Miller] Re: Yes-library [1137 days 8 hours and 14 minutes ago]

Fri, 24 Feb 2023 20:35:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Btw, how did you this 'wormish' shapes ? I like them so much !
>
> https://639cef3628e1f.site123.me/p-o-v-r-a-y/item-id-63ab2ae03b610
> --
> YB


Thanks, below are the definitions. I plot these out of CAD and convert using a
utility I wrote. I think these are the right ones.


//--- weed
#declare weed3 =
 union {
   sphere_sweep {
       cubic_spline
       7,
       <-0.0133141,-0.000790786,0.0>,0.131825,
       <-0.0133141,-0.000790786,0.0>,0.131825,
       <0.0852752,0.426277,-0.118113>,0.102224,
       <-0.0994501,1.01313,0.0504987>,0.0503133,
       <-0.082195,1.2748,0.0306135>,0.0251861,
       <-0.0270831,1.38204,-0.0239959>,0.0551861,
       <-0.0270831,1.38204,-0.0239959>,0.0551861
       tolerance 0.000001
       }

}


//--- mushroom
#declare shroom =
lathe {
    cubic_spline
    10
    < 0.0  ,  0.287761 >,
    < 0.0  ,  0.287761 >,
    < 0.110804  ,  0.270507 >,
    < 0.210494  ,  0.199574 >,
    < 0.203634  ,  0.142057 >,
    < 0.0925914  ,  0.13631 >,
    < 0.124224  ,  0.0251171 >,
    < 0.180055  ,  -0.00454055 >,
    < 0.000391543  ,  -0.0259348 >,
    < 0.000391543  ,  -0.0259348 >
    }

[Mike Miller] Re: Yes-library [1137 days 8 hours and 29 minutes ago]

Fri, 24 Feb 2023 20:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > Also,
> > Has POV implemented a way to use 'Normal Maps' for bumps using an image map? I
> > didn't he an example in the help files.
>
> I can't recall an example, and I haven't tried it, but -
> Try using an image_map as the pattern for:
>
> https://wiki.povray.org/content/Reference:Normal_Map
>
> - Bill

Thanks - I'll check it out.

[Bald Eagle] Re: Yes-library [1137 days 10 hours and 34 minutes ago]

Fri, 24 Feb 2023 18:15:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> Also,
> Has POV implemented a way to use 'Normal Maps' for bumps using an image map? I
> didn't he an example in the help files.

I can't recall an example, and I haven't tried it, but -
Try using an image_map as the pattern for:

https://wiki.povray.org/content/Reference:Normal_Map

- Bill

[yesbird] Re: Yes-library [1137 days 11 hours and 45 minutes ago]

Fri, 24 Feb 2023 17:04:05 GMT

Btw, how did you this 'wormish' shapes ? I like them so much !

https://639cef3628e1f.site123.me/p-o-v-r-a-y/item-id-63ab2ae03b610
--
YB

[yesbird] Re: Yes-library [1137 days 11 hours and 56 minutes ago]

Fri, 24 Feb 2023 16:53:16 GMT

On 24/02/2023 18:54, Mike Miller wrote:
> No disappointment here - I'm glad you were able to find the file. I found
> another image map for that fish. You may need to tweak the coordinates.
Oooo, thanks a lot. Texturing in POV is tricky for me, having such good
image map I can improve details now.

> Also,
> Has POV implemented a way to use 'Normal Maps' for bumps using an image map? I
> didn't he an example in the help files.
That's all I was able to find, while doing bumping:
https://wiki.povray.org/content/Reference:Bump_Map
-- 
YB

[Mike Miller] Re: Yes-library [1137 days 12 hours and 54 minutes ago]

Fri, 24 Feb 2023 15:55:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 23/02/2023 23:36, Mike Miller wrote:
>
> > Great, glad I can help. I'll try to contribute to your Roger Dean project when I
> > can. Always loved his work...Cool concept to model and animate.
> >
> > Patrick Woodroffe was my illustration hero when I was in high school. I keep his
> > Mythopoeikon book beside me for inspiration. His early pencil and etching work
> > is very nice.
> >
> > Here a link to some of my early sketches and 3D. I've only had the site up for a
> > few months so it's very much a work in progress ...like the rest of my life. :)
> > I started adding some of my resent POV work. I'm currently modeling bugs for
> > some rendering ideas.
> >
> > https://639cef3628e1f.site123.me/
> > I lost old website...now I'm using a free one. :)
> >
> Hi Mike !
>
> I'm very glad that found here a man, who share my preferences in art and
> technologies. Opposite to you, I'm much more programmer and
> mathematician, but always dreamed to be an artist. 3D graphics somewhere
> in between, and this is the reason why it attracts me so much.
> So, if you will need some assistance in software development or similar,
> I can help you without a problems. I am also working with ceramics
> a little, this gives me a rest after intensive coding:
> https://www.facebook.com/yesbird65
>
> I want to thank you for pointing me to Patrick Woodroffe, I spent half
> of the night exploring his artworks, only wonder, how I can miss him ?
> He is a great artist. For symmetry, I would like to mention Kirill
> Chyolushkin:
> https://illustrators.ru/posts/kirill-chyolushkin
> Sorry, site in Russian, but contains mostly images.
> I have only one of his books, as they are very expensive :)
>
> You site is good and well-organized, some part of chaos is normal for
> creativity, too much order will kill it :). You are very talented, I
> like your old-time sketches and present works. I see you are using
> Sculptris, I have a Z-Brush and now writing plugin for exporting meshes
> to POV, preserving color info.
>
> I like insects also, they have accurate 'construction' and beautiful
> forms, created for rendering, please keep me in loop while working on them.
>
> As to Yes-library: I found Fish-13 in some old archive, cleaned it up,
> recolorized and animated:
> https://www.youtube.com/watch?v=9qSR539hQdo
>
> Hope, you will not be disappointed. Now I am pushing it into macro for
> more easy recolorizing and cloning (so please don't waste your time for
> that), suppose it will be brilliant in my collection :).
> I will post link to final code, after pushing it to repository.
>
> Can't wait for putting hands on your blobs examples - will work with
> them tomorrow.
>
> All the best, and sorry for my English,
> --
> YB


No disappointment here - I'm glad you were able to find the file. I found
another image map for that fish. You may need to tweak the coordinates.
....and your English is great! Probably better than mine...flunked 2 English
classes in college.

Love kirill-chyolushkin - had not seen his work. Thanks for sharing!

Also,
Has POV implemented a way to use 'Normal Maps' for bumps using an image map? I
didn't he an example in the help files.
Mike

[Alain Martel] Re: Yes-library [1137 days 15 hours and 41 minutes ago]

Fri, 24 Feb 2023 13:08:15 GMT

Le 2023-02-23 Ã  18:44, Bald Eagle a Ã©critÂ :
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> I did decide to search the Bible for myself, ...
> (Your translation may vary.)
> 
> 
> Steven Anderson of the Faithful Word Baptist Church has a very interesting video
> about why he's a KJV-only church, and why the other versions are less ...
> reliable.
> 
> 
> 
> 
That's ironic as the KJV is based on an earlier version that is regarded 
as unreliable... How can the derived work be more reliable than it's 
main source ?

[Bald Eagle] Re: Yes-library [1138 days 1 hour and 59 minutes ago]

Fri, 24 Feb 2023 02:50:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> BWA-HA-HA-HA-HA!

^ (knew that was coming  ;) )

> Even if I couldn't figure out on my own that biblical scholarship has
> advanced greatly since 1611, I'm not inclined to listen to that hateful
> bigot.  How hateful is he?  He's been banned from many countries,
> including homophobic countries like Jamaica.

I watch all of them - I don't much care what anyone else says.
Steven Anderson
Roger Jimenez
Vernon Coleman
Walter Vieth
Brother Nathaniel
David Wood
.... dozens of others

I skim through so much content and not much really gets filtered except if I
find the presentation annoying or if I'm short on time or bored.  I might speed
up a video to max speed or skip ahead every few minutes to get through most of
the filler.

If I don't agree with something someone says, or the beliefs they hold -
whatever.
I don't really get in a twist over very much of anything.

We had Fred Phelps' people from Westboro Baptist Church at U of MD outside the
student union for a few days - way back when...  The whole 9 yards with the big
posters and everything.  I was just like, "yep."   Then I went to lunch and got
on with my day.  I had a lot of time-consuming chemistry sh*t to do, and I was
burning daylight.

But y'know - that's just me.

[yesbird] Re: Yes-library [1138 days 2 hours and 7 minutes ago]

Fri, 24 Feb 2023 02:42:02 GMT

On 23/02/2023 23:36, Mike Miller wrote:

> Great, glad I can help. I'll try to contribute to your Roger Dean project when I
> can. Always loved his work...Cool concept to model and animate.
> 
> Patrick Woodroffe was my illustration hero when I was in high school. I keep his
> Mythopoeikon book beside me for inspiration. His early pencil and etching work
> is very nice.
> 
> Here a link to some of my early sketches and 3D. I've only had the site up for a
> few months so it's very much a work in progress ...like the rest of my life. :)
> I started adding some of my resent POV work. I'm currently modeling bugs for
> some rendering ideas.
> 
> https://639cef3628e1f.site123.me/
> I lost old website...now I'm using a free one. :)
> 
Hi Mike !

I'm very glad that found here a man, who share my preferences in art and
technologies. Opposite to you, I'm much more programmer and
mathematician, but always dreamed to be an artist. 3D graphics somewhere
in between, and this is the reason why it attracts me so much.
So, if you will need some assistance in software development or similar,
I can help you without a problems. I am also working with ceramics
a little, this gives me a rest after intensive coding:
https://www.facebook.com/yesbird65

I want to thank you for pointing me to Patrick Woodroffe, I spent half
of the night exploring his artworks, only wonder, how I can miss him ?
He is a great artist. For symmetry, I would like to mention Kirill 
Chyolushkin:
https://illustrators.ru/posts/kirill-chyolushkin
Sorry, site in Russian, but contains mostly images.
I have only one of his books, as they are very expensive :)

You site is good and well-organized, some part of chaos is normal for
creativity, too much order will kill it :). You are very talented, I
like your old-time sketches and present works. I see you are using
Sculptris, I have a Z-Brush and now writing plugin for exporting meshes
to POV, preserving color info.

I like insects also, they have accurate 'construction' and beautiful
forms, created for rendering, please keep me in loop while working on them.

As to Yes-library: I found Fish-13 in some old archive, cleaned it up, 
recolorized and animated:
https://www.youtube.com/watch?v=9qSR539hQdo

Hope, you will not be disappointed. Now I am pushing it into macro for
more easy recolorizing and cloning (so please don't waste your time for
that), suppose it will be brilliant in my collection :).
I will post link to final code, after pushing it to repository.

Can't wait for putting hands on your blobs examples - will work with
them tomorrow.

All the best, and sorry for my English,
--
YB

[Cousin Ricky] Re: Yes-library [1138 days 4 hours and 1 minute ago]

Fri, 24 Feb 2023 00:48:16 GMT

On 2023-02-23 19:44 (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> I did decide to search the Bible for myself, ...
>> (Your translation may vary.)
> 
> 
> Steven Anderson of the Faithful Word Baptist Church has a very interesting video
> about why he's a KJV-only church, and why the other versions are less ...
> reliable.

BWA-HA-HA-HA-HA!

Even if I couldn't figure out on my own that biblical scholarship has
advanced greatly since 1611, I'm not inclined to listen to that hateful
bigot.  How hateful is he?  He's been banned from many countries,
including homophobic countries like Jamaica.  If he utters something
true by sheer accident, I'll surely hear it from someone else more
trustworthy.

On a tangential note, it appears the the Web portal disregards the
Followup-To header.

[Bald Eagle] Re: Yes-library [1138 days 5 hours and 4 minutes ago]

Thu, 23 Feb 2023 23:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> I did decide to search the Bible for myself, ...
(Your translation may vary.)


Steven Anderson of the Faithful Word Baptist Church has a very interesting video
about why he's a KJV-only church, and why the other versions are less ...
reliable.

[Cousin Ricky] Re: Yes-library [1138 days 5 hours and 17 minutes ago]

Thu, 23 Feb 2023 23:32:20 GMT

On 2023-02-23 08:56 (-4), yesbird wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I don't think this came from the Bible.  Do you have a citation?
> 
> I read it in Evangelia, don't remember chapter exactly.

This is what I found in a Web search.  Not even a mention of the Bible.

https://quoteinvestigator.com/2015/08/28/fish/

I ask for two reasons.  First, is that I find quotes mis-attributed so
frequently that I can never take them for granted.  Just reading that
article on just that one quote, you can see how people make up all kinds
of shit, often without realizing it.  Other search results mention
Matthew 4:19, only to say that people remember it wrong.

  "The human brain did not evolve to accurately represent the world
  around us; it evolved only to enhance the survival of our genes."
  --Victor S. Johnston

And it certainly did not evolve to remember quote attributions properly.

(But yes, I did verify the Victor Johnston quote!)

You can look up "Mandela effect" for more on this.

The second reason is that the source you are attributing is the
foundation of the world view of 1/3 of the world's population, yet few
of them seem to know what's in it beyond what their preachers tell them.
 Add to this our propensity to mis-attribute, and we have a real
problem, if a plurality of the world's population is to base their lives
on what's in that document, especially when their preachers have an
agenda.  While I don't tell people what they believe--I find that
unspeakably rude--I can and do challenge them on what is actually
written in their book.

I did decide to search the Bible for myself, and found 80 verses that
mention fish.  (Your translation may vary.)  None of them resembled this
quote.

[Mike Miller] Re: Yes-library [1138 days 8 hours and 9 minutes ago]

Thu, 23 Feb 2023 20:40:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> > Nice job on the breathing coral. Are you using an animation utility or scripting
> > something yourself? I'm using some 'old' cobbled script for replacing flagged
> > values between frames. I need to see if there's something more current.
>
> Hi, Mike.
> Thanks, this is only a start, more serious work will follow. As to
> animation, I am using very straight-forward techniques, described in
> manual: https://wiki.povray.org/content/HowTo:Create_animations
> and setting 'clock' variable for transformations.
>
> I like how It works, at least now for trivial cases, may be in the
> future I will need something more sophisticated.
>
> > I put a scene file together for you showing the use of negative blobs 'carving
> > out' smooth forms in positive strength blobs. Attached is a rendering from that
> > file. One drawback - there's a way to separately texture the voided space.  I'll
> > post the scene file in the binary scene file location.
> > Have a great night.
>
> Many, many thanks for this example, last time you give me a fish, now
> you are teaching me fishing ;). It looks like we thinking the same
> : blobs are very powerful and flexible, but control is not easy and
> intuitive, I spent about an hour setting parameters, trying to achieve
> desired form, that I had in mind. And I started thinking about external
> control, (like you do with point clouds) with CSG methods.
>
> This is exactly what I need for manufacturing artifacts, will play with
> them this night.
>
> Happy rendering,
> --
> YB


Great, glad I can help. I'll try to contribute to your Roger Dean project when I
can. Always loved his work...Cool concept to model and animate.

Patrick Woodroffe was my illustration hero when I was in high school. I keep his
Mythopoeikon book beside me for inspiration. His early pencil and etching work
is very nice.

Here a link to some of my early sketches and 3D. I've only had the site up for a
few months so it's very much a work in progress ...like the rest of my life. :)
I started adding some of my resent POV work. I'm currently modeling bugs for
some rendering ideas.

https://639cef3628e1f.site123.me/
I lost old website...now I'm using a free one. :)

[yesbird] Re: Yes-library [1138 days 15 hours and 49 minutes ago]

Thu, 23 Feb 2023 13:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I don't think this came from the Bible.  Do you have a citation?

I read it in Evangelia, don't remember chapter exactly.
--
YB

[Cousin Ricky] Re: Yes-library [1138 days 16 hours and 3 minutes ago]

Thu, 23 Feb 2023 12:46:12 GMT

On 2023-02-23 06:16 (-4), yesbird wrote:
> â€œGive a man a fish and you feed him for a day; teach a man to fish
and
> you feed him for a lifetime.â€ - Bible.

I don't think this came from the Bible.  Do you have a citation?

[yesbird] Re: Yes-library [1138 days 18 hours and 6 minutes ago]

Thu, 23 Feb 2023 10:42:55 GMT

On 23/02/2023 04:12, Bald Eagle wrote:
> I'll probably have a go at figuring something out on paper and making it from
> scratch.
Interesting, I will be the first reader :)

> That said, Roger Dean employed a lot of Egyptian imagery for Asia, and I have
> all of my stuff I did with regard to the Giza plateau, the Great Pyramid (all
> 1.3 million blocks), the Schist Disk, and whatever else I have lying around.
And I even know what you are taking about (see attachment) :)

> Also see my recent post re: vase stl
After Thomas will finish vase scene, I (or may be someone else) can 
animate it and this animation I can put on my POV-Ray Youtube channel.

> As people know, I kind of work in fits and starts - long periods of inactivity
> might be followed with a sudden burst of inspiration, followed by a need to just
> take a break.   YMMV.
This is about me - I didn't work with code for 3-4 month, but starting
from January can't stop. To give a rest to my mind I am switching to
something material, woodworking or ceramics:
https://www.facebook.com/yesbird65

All the best,
--
YB

[yesbird] Re: Yes-library [1138 days 18 hours and 32 minutes ago]

Thu, 23 Feb 2023 10:16:57 GMT

> Nice job on the breathing coral. Are you using an animation utility or scripting
> something yourself? I'm using some 'old' cobbled script for replacing flagged
> values between frames. I need to see if there's something more current.

Hi, Mike.
Thanks, this is only a start, more serious work will follow. As to
animation, I am using very straight-forward techniques, described in
manual: https://wiki.povray.org/content/HowTo:Create_animations
and setting 'clock' variable for transformations.

I like how It works, at least now for trivial cases, may be in the
future I will need something more sophisticated.

> I put a scene file together for you showing the use of negative blobs 'carving
> out' smooth forms in positive strength blobs. Attached is a rendering from that
> file. One drawback - there's a way to separately texture the voided space.  I'll
> post the scene file in the binary scene file location.
> Have a great night.
â€œGive a man a fish and you feed him for a day; teach a man to fish
and 
you feed him for a lifetime.â€ - Bible.

Many, many thanks for this example, last time you give me a fish, now
you are teaching me fishing ;). It looks like we thinking the same
: blobs are very powerful and flexible, but control is not easy and
intuitive, I spent about an hour setting parameters, trying to achieve
desired form, that I had in mind. And I started thinking about external
control, (like you do with point clouds) with CSG methods.

This is exactly what I need for manufacturing artifacts, will play with
them this night.

Happy rendering,
--
YB

[Mike Miller] Re: Yes-library [1138 days 22 hours and 29 minutes ago]

Thu, 23 Feb 2023 06:20:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Here I'm starting a collection of static and animated objects,
> inspired by Roger Dean's artworks:
> https://github.com/syanenko/pov-yes
>
> Most of them will be implemented as parameterized macros for more
> easy reproduction with visual varietivity. Everyone, who is
passionate
> on Yes and/or Dean's art can join this project and contribute whatever
> he want/can.
>
> As the first seed of this library I've rendered this short animation of
> the breathing coral:
> https://www.youtube.com/watch?v=Xfp7ocJBziQ
>
> Comments, ideas and suggestions are always welcome !
> --YB

Hi yesbird.
Nice job on the breathing coral. Are you using an animation utility or scripting
something yourself? I'm using some 'old' cobbled script for replacing flagged
values between frames. I need to see if there's something more current.

I put a scene file together for you showing the use of negative blobs 'carving
out' smooth forms in positive strength blobs. Attached is a rendering from that
file. One drawback - there's a way to separately texture the voided space.  I'll
post the scene file in the binary scene file location.
Have a great night.

[Bald Eagle] Re: Yes-library [1139 days 3 hours and 34 minutes ago]

Thu, 23 Feb 2023 01:15:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> Most of them will be implemented as parameterized macros for more
> easy reproduction with visual varietivity. Everyone, who is
passionate
> on Yes and/or Dean's art can join this project and contribute whatever
> he want/can.

I only got so far on the single-image photogrammetry of the ship - Applying
dozens of matrix transforms to the in-plane points of my trace and viewing from
several vantage points shows just how challenging a task it is, and just how
much what your brain thinks your eyes are telling you is there just .... isn't.

I'll probably have a go at figuring something out on paper and making it from
scratch.

That said, Roger Dean employed a lot of Egyptian imagery for Asia, and I have
all of my stuff I did with regard to the Giza plateau, the Great Pyramid (all
1.3 million blocks), the Schist Disk, and whatever else I have lying around.

Also see my recent post re: vase stl

As people know, I kind of work in fits and starts - long periods of inactivity
might be followed with a sudden burst of inspiration, followed by a need to just
take a break.   YMMV.

[yesbird] Yes-library [1139 days 6 hours and 7 minutes ago]

Wed, 22 Feb 2023 22:42:06 GMT

Here I'm starting a collection of static and animated objects,
inspiredÂ by Roger Dean's artworks:
https://github.com/syanenko/pov-yes

Most of them will be implemented as parameterizedÂ macros for more
easyÂ reproduction
withÂ visualÂ varietivity.Â Everyone, who is passionate
on Yes and/orÂ Dean's art can join this project and contribute whatever
he want/can.

As the first seed of this library I've rendered this short animation of
the breathing coral:
https://www.youtube.com/watch?v=Xfp7ocJBziQ

Comments, ideas and suggestions are always welcome !
--YB

[yesbird] Re: Plants collection [1140 days 11 hours and 9 minutes ago]

Tue, 21 Feb 2023 17:40:03 GMT

On 21/02/2023 19:07, Thomas de Groot wrote:
> I use Arbaro once in a while. Didn't Friedrich Lohmueller provide a 
> small collection of trees he made with it?
Yes, exactly, this is the way I came to it:
https://povlab.online/povtutorial/plants/plants_00e.html

The great advantage of Arbaro is the ability to include native and 
custom POV objects in constructions it produces. Now I am teaching it to 
grow flowers.

> As said elsewhere, I shall look in my archive tomorrow.
Ooo, thanks in advance.
--
YB

[yesbird] Re: Plants collection [1140 days 11 hours and 14 minutes ago]

Tue, 21 Feb 2023 17:34:40 GMT

On 21/02/2023 19:03, kurtz le pirate wrote:
> There is also <http://ngplant.org/>
> With some explanations and example here :
> <http://louisbel.free.fr/macros/ngplant/ngplant.html>
Thanks a lot, will play with it this night.
--
YB

[Thomas de Groot] Re: Plants collection [1140 days 12 hours and 41 minutes ago]

Tue, 21 Feb 2023 16:07:36 GMT

Op 21-2-2023 om 13:17 schreef yesbird:
> Inflammation of your arm and neck joints, and muscle pain may
>> be your unlooked for reward too... :-/
> This is exactly what I want avoid, when talking about algorithmic 
> methods... )))
> 


Of course. :-)

-- 
Thomas

[Thomas de Groot] Re: Plants collection [1140 days 12 hours and 42 minutes ago]

Tue, 21 Feb 2023 16:07:00 GMT

Op 21-2-2023 om 13:28 schreef yesbird:
>> Indeed, and I am afraid that each different plant (I do not mean 
>> within the /Gaillardia_pulchella/ bunch) may show a different grouping 
>> arrangement which would need a different approach in the worst case. 
>> However, this petal grouping reduces work somewhat ;-]
> Last night I found optimal solution for growing plants:
> https://github.com/wdiestel/arbaro
> This is implementation of ideas in attached paper, works fine, but
> written in Java (I hate it). It has a simpler plant structure
> description, than L-systems.
> 
I use Arbaro once in a while. Didn't Friedrich Lohmueller provide a 
small collection of trees he made with it?

> Now I'm looking for this editor, but still can't find it:
> http://povray.tashcorp.net/tutorials/qd_povtree/
> 
As said elsewhere, I shall look in my archive tomorrow.

-- 
Thomas

[kurtz le pirate] Re: Plants collection [1140 days 12 hours and 45 minutes ago]

Tue, 21 Feb 2023 16:03:52 GMT

On 21/02/2023 13:28, yesbird wrote:
>> Indeed, and I am afraid that each different plant (I do not mean within 
>> the /Gaillardia_pulchella/ bunch) may show a different grouping 
>> arrangement which would need a different approach in the worst case. 
>> However, this petal grouping reduces work somewhat ;-]
> Last night I found optimal solution for growing plants:
> https://github.com/wdiestel/arbaro
> This is implementation of ideas in attached paper, works fine, but
> written in Java (I hate it). It has a simpler plant structure
> description, than L-systems.
> 
> Now I'm looking for this editor, but still can't find it:
> http://povray.tashcorp.net/tutorials/qd_povtree/
> --
> YB
> 

There is also <http://ngplant.org/>

With some explanations and example here :
<http://louisbel.free.fr/macros/ngplant/ngplant.html>




-- 
Kurtz le pirate
Compagnie de la Banquise

[yesbird] Re: Plants collection [1140 days 16 hours and 20 minutes ago]

Tue, 21 Feb 2023 12:29:14 GMT

> Indeed, and I am afraid that each different plant (I do not mean within 
> the /Gaillardia_pulchella/ bunch) may show a different grouping 
> arrangement which would need a different approach in the worst case. 
> However, this petal grouping reduces work somewhat ;-]
Last night I found optimal solution for growing plants:
https://github.com/wdiestel/arbaro
This is implementation of ideas in attached paper, works fine, but
written in Java (I hate it). It has a simpler plant structure
description, than L-systems.

Now I'm looking for this editor, but still can't find it:
http://povray.tashcorp.net/tutorials/qd_povtree/
--
YB

[yesbird] Re: Plants collection [1140 days 16 hours and 32 minutes ago]

Tue, 21 Feb 2023 12:17:04 GMT

Inflammation of your arm and neck joints, and muscle pain may
> be your unlooked for reward too... :-/
This is exactly what I want avoid, when talking about algorithmic 
methods... )))
--
YB

[Thomas de Groot] Re: Plants collection [1140 days 21 hours and 8 minutes ago]

Tue, 21 Feb 2023 07:40:30 GMT

Op 20/02/2023 om 18:21 schreef yesbird:
> Thanks, Thomas, you give me a good idea about reducing manual work, 
> analysis of groups and regrouping can help to do it.
> 
> May be I will write script to assign different materials to groups
> and then merge them. I need to know more about OBJ format for that.
> 
Are there other formats than OBJ you could export to? Sometimes that may 
help circumvent the problem.

> But autocolorizing still interesting to me. For example, what if I want 
> to highlight edges or peaks of the complex mesh with selected color ?
> Will try to dig into this problem ...
> 
That would be interesting to try but...

Each mesh is a single closed (?) unit and ideally you would need some 
way to recognise those 'peaks' of 'edges'. In a well-behaved model those 
would be already textured in the MTL corresponding file or - in more 
elaborate models - uv_mapped on the mesh. Again, can be done at some 
pain, but with the help of a modeller afaik. I have done that kind of 
work at great pain for some downloaded models I wanted absolutely to 
tweak in my favour, and it took me days and sometimes weeks to achieve 
properly. Inflammation of your arm and neck joints, and muscle pain may 
be your unlooked for reward too... :-/

-- 
Thomas

[Thomas de Groot] Re: Plants collection [1140 days 21 hours and 27 minutes ago]

Tue, 21 Feb 2023 07:21:46 GMT

Op 20/02/2023 om 18:32 schreef yesbird:
> As you can see here groups are not exactly reflects plant's structure.
> -- 
> YB

Indeed, and I am afraid that each different plant (I do not mean within 
the /Gaillardia_pulchella/ bunch) may show a different grouping 
arrangement which would need a different approach in the worst case. 
However, this petal grouping reduces work somewhat ;-]

-- 
Thomas

[yesbird] Re: Plants collection [1141 days 10 hours ago]

Mon, 20 Feb 2023 18:48:49 GMT

> What i would be tempted to do is use the software to create the plant, and then
> dissect it into its component pieces.
You are right - this is the main task, unfortunately I have no access to
sources of LS to make export properly and do grouping by plant parts,
so some manual work should be done, I'm only trying to minimize it.
--
YB

[Bald Eagle] Re: Plants collection [1141 days 10 hours and 9 minutes ago]

Mon, 20 Feb 2023 18:40:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> Some of them has no color due to bug in L-studio export module.
> Btw, now I am looking for methods of coloring automation, based, say on
> normals, mesh density or similar.
>
> Have anyone ideas about such methods ?

What i would be tempted to do is use the software to create the plant, and then
dissect it into its component pieces.

Then you could have a reasonably manageable assortment of stems, leaves, flower
centers, flower petals, etc that you could store as objects in an array.

Then you could just write a macro to choose random parts and reassemble the
plant.

Once you had all of the pieces, it would probably be fairly straightforward to
fit a standard texture or a uv-map to each part type.   Always try to break down
a complex task into a series of smaller, simpler tasks.

[yesbird] Re: Plants collection [1141 days 11 hours and 17 minutes ago]

Mon, 20 Feb 2023 17:32:06 GMT

As you can see here groups are not exactly reflects plant's structure.
--
YB

[yesbird] Re: Plants collection [1141 days 11 hours and 28 minutes ago]

Mon, 20 Feb 2023 17:21:08 GMT

Thanks, Thomas, you give me a good idea about reducing manual work, 
analysis of groups and regrouping can help to do it.

May be I will write script to assign different materials to groups
and then merge them. I need to know more about OBJ format for that.

But autocolorizing still interesting to me. For example, what if I want 
to highlight edges or peaks of the complex mesh with selected color ?
Will try to dig into this problem ...
--
YB

[yesbird] Re: Plants collection [1141 days 11 hours and 59 minutes ago]

Mon, 20 Feb 2023 16:50:28 GMT

On 20/02/2023 19:45, Thomas de Groot wrote:
> Just wanted to add: the meshes are very fine and well-built. I have seen 
> far, far worse for some proprietary ones...

Agree with you - this is the reason why I don't leave L-studio.
Despite it being a little bit raw, it's potential is huge and it is FREE.
--
YB

[Thomas de Groot] Re: Plants collection [1141 days 12 hours and 4 minutes ago]

Mon, 20 Feb 2023 16:45:14 GMT

Just wanted to add: the meshes are very fine and well-built. I have seen 
far, far worse for some proprietary ones...

-- 
Thomas

[Thomas de Groot] Re: Plants collection [1141 days 12 hours and 10 minutes ago]

Mon, 20 Feb 2023 16:38:50 GMT

Got a closer look at /Gaillardia_pulchella/. I opened the corresponding 
plant.obj file into Silo (my modeller) and must say that texturing the 
plant would not be impossible but a lot of work manually.

"group0 - group208" for instance, represent one complete flower, 
starting with the leaves, then the flower s.s., finally the stem 
(group208). Forgive me if I mention things you probably know quite well 
but I am kind of thinking aloud here. ;-)

A couple of options present themselves:
1) create the different colours: stem, leaves, petals, heart.
2) select together all the groupxxxx representing one element, for 
instance leaves, and assign the leaf colour.
3) repeat procedure for each plant element group.

alternatively, you could group together all similar elements (if you can 
recognise them easily) and colour the group in the same manner as above.

Frankly, I do not see any other method to do this at the moment.

-- 
Thomas

[yesbird] Re: Plants collection [1141 days 12 hours and 26 minutes ago]

Mon, 20 Feb 2023 16:22:40 GMT

I guess that each element has its own geometry: stem, branch,
> leaf, flower petals, etc.
Unfortunately, no, after export to OBJ, I have a list of
triangles, without grouping. I can colorize it manually in Z-Brush
and sometimes it's fun, but in most cases too boring :)

Despite the L-Studio export problem, I find auto-colorization task 
interesting from an algorithmic perspective.

Ideally, I would like to have an auto-colorization method for meshes 
with subsequent manual color correction and detalization.
--
YB

[Thomas de Groot] Re: Plants collection [1141 days 13 hours and 6 minutes ago]

Mon, 20 Feb 2023 15:42:32 GMT

Op 20-2-2023 om 15:34 schreef yesbird:
> Here I want to share my small collection of plants obtained from
> L-Studio: http://algorithmicbotany.org/virtual_laboratory/
> 
> The reason I started using L-studo is because of difficulties in
> producing such detailed and complicated objects by native POV methods.
> 
> I will fill it out from time to time as creating new species.
> 
> Some of them has no color due to bug in L-studio export module.
> Btw, now I am looking for methods of coloring automation, based, say on
> normals, mesh density or similar.
> 
> Have anyone ideas about such methods ?
> 
> Download: https://github.com/syanenko/pov-plants
> -- 
> YB

At first approximation (I would need to see one of the models more in 
detail) I guess that each element has its own geometry: stem, branch, 
leaf, flower petals, etc. Normally, each geometry can get its own 
texturing, maybe even uv_mapped if L-Studio supports that feature. Using 
Poseray could be your friend then for what you want to do. 
Alternatively, you may need a modelling program first, but that is 
another matter.

-- 
Thomas

[yesbird] Plants collection [1141 days 14 hours and 14 minutes ago]

Mon, 20 Feb 2023 14:34:58 GMT

Here I want to share my small collection of plants obtained from
L-Studio: http://algorithmicbotany.org/virtual_laboratory/

The reason I started using L-studo is because of difficulties in
producing such detailed and complicated objects by native POV methods.

I will fill it out from time to time as creating new species.

Some of them has no color due to bug in L-studio export module.
Btw, now I am looking for methods of coloring automation, based, say on
normals, mesh density or similar.

Have anyone ideas about such methods ?

Download: https://github.com/syanenko/pov-plants
--
YB

[yesbird] Re: Set of scalable colormaps recommended for sc... [1141 days 18 hours and 42 minutes ago]

Mon, 20 Feb 2023 10:06:44 GMT

> I see no mention of gamma in Mr. Moreland's article, nor in any of the
> papers he linked.

Hi Cousin,
Thanks for your comment and interesting question. I am not sure that 
gamma correction is so important for scientific visualization. This is 
not photography, where we trying to achieve highest realistic level, 
colors only helps to interpret model more accurate, they are 
'suppositive' here.

I any case, if someone need it, he can implement macro, processing data 
array according his requirements (thanks to Bald for advice to store 
data separately of their interpretation).

 > I am unfamiliar with MatLab.  Does it address color gamma?

As to Matlab, yes, it has methods for gamma correction, but not at 
colormap, but at image level:
https://www.mathworks.com/help/images/ref/lin2rgb.html
--
YB

[Cousin Ricky] Re: Set of scalable colormaps recommended for sc... [1142 days 2 hours and 59 minutes ago]

Mon, 20 Feb 2023 01:50:25 GMT

On 2023-02-19 19:29 (-4), yesbird wrote:
> This is a set of ready-to-use colormaps, each contains 256 colors. Most
> of them exported from Matlab, other from this page:
> https://www.kennethmoreland.com/color-advice/
> 
> Color information stored in 2D array, colormaps are generating by the
> macro, allowing re-scaling and applying desired transparency.
> Usage examples also present.
> 
> Download: https://github.com/syanenko/Colormaps

I see no mention of gamma in Mr. Moreland's article, nor in any of the
papers he linked.  Online colors are typically sRGB or gamma 2.2 (with
good reason), but your tool is set to gamma 1.0 (also with good reason),
and there are no srgb keywords or exponentiation in your code.  In the
absence of documentation to the contrary, color definitions tend to
default to sRGB, often simply because the author is completely unaware
that color non-linearity is a thing.  How can we be sure that you have
interpreted Mr. Moreland's colors correctly?

I am unfamiliar with MatLab.  Does it address color gamma?

[yesbird] Set of scalable colormaps recommended for scient... [1142 days 5 hours and 19 minutes ago]

Sun, 19 Feb 2023 23:29:46 GMT

This is a set of ready-to-use colormaps, each contains 256 colors. Most 
of them exported from Matlab, other from this page: 
https://www.kennethmoreland.com/color-advice/

Color information stored in 2D array, colormaps are generating by the 
macro, allowing re-scaling and applying desired transparency.
Usage examples also present.

Download: https://github.com/syanenko/Colormaps
--
YB

[Cousin Ricky] Re: ShapeOfTheDay render rig pre-release [1209 days 11 hours and 19 minutes ago]

Wed, 14 Dec 2022 17:30:27 GMT

On 10/14/22 00:01, Cousin Ricky wrote:
> I have decided to publish my 4th generation render rig.  It still needs
> cleanup and debugging, but I have at least linked it with DeskLamp,
> which was my last major task before I would consider publishing it.

I forgot to mention, I released the completed module on November 1.

> https://github.com/CousinRicky/POV-ShapeOfTheDay

[Cousin Ricky] Re: ShapeOfTheDay render rig pre-release [1270 days 12 hours and 39 minutes ago]

Fri, 14 Oct 2022 16:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> I have not yet added a license (I must first edit the copyright texts in
> the files), but you are free to take a look on a Fair Use/Fair Dealing
> basis.
>
> https://github.com/CousinRicky/POV-ShapeOfTheDay

I have modified the copyright texts and added a license.  The project is still
unfinished, though.

[Cousin Ricky] ShapeOfTheDay render rig pre-release [1271 days and 48 minutes ago]

Fri, 14 Oct 2022 04:01:11 GMT

I have decided to publish my 4th generation render rig.  It still needs
cleanup and debugging, but I have at least linked it with DeskLamp,
which was my last major task before I would consider publishing it.

I have not yet added a license (I must first edit the copyright texts in
the files), but you are free to take a look on a Fair Use/Fair Dealing
basis.

https://github.com/CousinRicky/POV-ShapeOfTheDay

[Cousin Ricky] DeskLamp: a flex-neck desk lamp [1308 days 5 hours and 14 minutes ago]

Tue, 6 Sep 2022 23:34:33 GMT

Back in 2005, I thought my 3rd generation prefab render rig needed some
sort of physical light fixture for its indoor setting, so I modeled a
flex-neck desk lamp for that purpose.  This lamp has photobombed a
couple of my pbi posts, and I posted an image of one in Bernard's "The
Spider" thread ("Another CSG scene" from April 2013).  However, this
model had several features that made it unsuitable for general use.

I have rewritten the lamp code for a more general audience, and prepared
it for the Object Collection when it comes back online.  It is currently
hosted on GitHub:

https://github.com/CousinRicky/POV-DeskLamp

The module's lumens calibration can be synchronized with Lightsys IV.

[Thomas de Groot] Re: RC3Metal 2.0 [1500 days 13 hours and 10 minutes ago]

Sat, 26 Feb 2022 15:39:10 GMT

Op 2-2-2022 om 02:21 schreef Cousin Ricky:
> As I brought up in p.b.i, RC3Metal failed to take into account the
> diffuse finish in setting highlights.  This oversight has been corrected
> in version 2.0 of RC3Metal, but you may have to increase the Hilite
> argument to RC3M_Set_functions() or RC3M_Set_highlight() to get textures
> similar to those of previous versions.  For textures with a high
> Specularity argument, this change makes little or no difference.
> 
> Another change is that the default highlighting has been made uniform
> across POV-Ray versions 3.5 to 3.8.  A side effect of this change is
> that parameter RC3M_Albedo is forced off, so if you want RC3Metal to use
> 'diffuse albedo', you need to set it *after* including rc3metal.inc.
> Nevertheless, I recommend using RC3M_Set_highlight() for brilliance
> coordination, rather than setting RC3M_Albedo.
> 
> For those who want zero ambient on your metals, instructions are given
> for this.  RC3Metal has always had this capability, but it was not made
> explicit in the User Manual until now.
> 
> https://github.com/CousinRicky/POV-RC3Metal/releases/tag/v2.0

Also, for this set, thank you very much indeed. I had not the 
opportunity earlier to work with this and just started today. I am 
impressed.

-- 
Thomas

[Cousin Ricky] Re: Spiral image macro, version 2.0 [1513 days 6 hours and 51 minutes ago]

Sun, 13 Feb 2022 21:57:39 GMT

On 2022-02-03 20:49 (-4), Cousin Ricky wrote:
> I don't know how Matthew did his, but this is my take.
> 
> You will need SphereSweep from the Object Collection as a prerequisite.
> SphereSweep can be obtained at:
>   https://github.com/CousinRicky/POV-SphereSweep

I added some macros to compute sizes and scale the image map (pigment,
actually), and prepared it for the Object Collection when it comes back
online. It us currently hosted on GitHub:
  https://github.com/CousinRicky/POV-SpiralImage

[Cousin Ricky] RC3Metal 2.0 [1525 days 3 hours and 27 minutes ago]

Wed, 2 Feb 2022 01:21:30 GMT

As I brought up in p.b.i, RC3Metal failed to take into account the
diffuse finish in setting highlights.  This oversight has been corrected
in version 2.0 of RC3Metal, but you may have to increase the Hilite
argument to RC3M_Set_functions() or RC3M_Set_highlight() to get textures
similar to those of previous versions.  For textures with a high
Specularity argument, this change makes little or no difference.

Another change is that the default highlighting has been made uniform
across POV-Ray versions 3.5 to 3.8.  A side effect of this change is
that parameter RC3M_Albedo is forced off, so if you want RC3Metal to use
'diffuse albedo', you need to set it *after* including rc3metal.inc.
Nevertheless, I recommend using RC3M_Set_highlight() for brilliance
coordination, rather than setting RC3M_Albedo.

For those who want zero ambient on your metals, instructions are given
for this.  RC3Metal has always had this capability, but it was not made
explicit in the User Manual until now.

https://github.com/CousinRicky/POV-RC3Metal/releases/tag/v2.0

[Cousin Ricky] Re: Accessing Object Collection modules while th... [1635 days and 24 minutes ago]

Fri, 15 Oct 2021 04:25:12 GMT

On 2021-10-14 1:27 PM (-4), William F Pokorny wrote:
> 
> Under https://github.com/CousinRicky/POV-Ray-Object-Collection I am
> still seeing a BrightStar5 directory?

That's because I already announced that URL here, and I didn't want to
orphan anyone who might follow it.  All that's in that folder is a link
to the BrightStar5 repo.  I'll probably delete it later.

[William F Pokorny] Re: Accessing Object Collection modules while th... [1635 days 11 hours and 22 minutes ago]

Thu, 14 Oct 2021 17:27:07 GMT

On 10/13/21 12:29 PM, Cousin Ricky wrote:
> On 2021-08-15 3:21 PM (-4), Cousin Ricky wrote:
>>
>> Due to my modules residing in multiple repositories even after the
>> Object Collection server is restored, I will be updating my remaining
>> user manuals in the same way over time.
> 
> All 14 of the Object Collection modules that I have contributed or
> modified are uploaded to my GitHub account.  Each module now has its own
> repository; they are all linked in the README.md at:
>    https://github.com/CousinRicky/POV-Ray-Object-Collection
> 
> The subfolders under the above repo have been deleted.
> 
> Module Name       Version  Status
> -----------       -------  ------
> AndroidRobot      5.0A     Updated since 2019 April 5
> BrightStar5       1.1.2    3.8 compatibility update since server crash
> CoffeeMug         2.0.1A   Updated since 2019 April 5
> GemCuts           1.0.1    Minor update since the server crash
> RC3Metal          1.3A     Updated since 2019 April 5
> RoundEdge         2.0A     Updated since 2019 April 5
> ScaryCoronavirus  1.0B     New since 2019 April 5
> SphereSweep       2.1A     Updated since 2019 April 5
> BeamTest          1.2.1A   Unchanged except for documentation
> Caption           1.1.1A   Unchanged except for documentation
> IntegrateLight    1.0.1A   Unchanged except for documentation
> lrchairs          1.1.1A   Unchanged except for documentation and
>                             Leroy's URL
> Spectrum          4.0.1A   Unchanged except for documentation
> TiltedTorus       3.0.1A   Unchanged except for documentation
> 

Cool.

Under https://github.com/CousinRicky/POV-Ray-Object-Collection I am 
still seeing a BrightStar5 directory?

Bill P.

[Cousin Ricky] Re: Accessing Object Collection modules while th... [1636 days 12 hours and 19 minutes ago]

Wed, 13 Oct 2021 16:29:59 GMT

On 2021-08-15 3:21 PM (-4), Cousin Ricky wrote:
> 
> Due to my modules residing in multiple repositories even after the
> Object Collection server is restored, I will be updating my remaining
> user manuals in the same way over time.

All 14 of the Object Collection modules that I have contributed or
modified are uploaded to my GitHub account.  Each module now has its own
repository; they are all linked in the README.md at:
  https://github.com/CousinRicky/POV-Ray-Object-Collection

The subfolders under the above repo have been deleted.

Module Name       Version  Status
-----------       -------  ------
AndroidRobot      5.0A     Updated since 2019 April 5
BrightStar5       1.1.2    3.8 compatibility update since server crash
CoffeeMug         2.0.1A   Updated since 2019 April 5
GemCuts           1.0.1    Minor update since the server crash
RC3Metal          1.3A     Updated since 2019 April 5
RoundEdge         2.0A     Updated since 2019 April 5
ScaryCoronavirus  1.0B     New since 2019 April 5
SphereSweep       2.1A     Updated since 2019 April 5
BeamTest          1.2.1A   Unchanged except for documentation
Caption           1.1.1A   Unchanged except for documentation
IntegrateLight    1.0.1A   Unchanged except for documentation
lrchairs          1.1.1A   Unchanged except for documentation and
                           Leroy's URL
Spectrum          4.0.1A   Unchanged except for documentation
TiltedTorus       3.0.1A   Unchanged except for documentation

[Alain Martel] Re: Accessing Object Collection modules while th... [1687 days 11 hours and 50 minutes ago]

Mon, 23 Aug 2021 16:58:38 GMT

Le 2021-08-20 à 12:44, Nekar Xenos a écrit :

> The usual; my hard-drive crashed again. And now I'm using my son's computer...
> 
> Greetings
> 
> Nekar Xenos
> 
> 
> 
I hope that you have some good backup.

[Nekar Xenos] Re: Accessing Object Collection modules while th... [1690 days 12 hours and 4 minutes ago]

Fri, 20 Aug 2021 16:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> As a reminder, Le Forgeron has a mirror at:
>   https://github.com/LeForgeron/PovContributions
>
-------snip------

Thank you so much. It's a long time since I've been here and I was looking for
my nxplanets.inc.

The usual; my hard-drive crashed again. And now I'm using my son's computer...

Greetings

Nekar Xenos

[Mr] Re: Accessing Object Collection modules while th... [1690 days 19 hours and 29 minutes ago]

Fri, 20 Aug 2021 09:20:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2015/21-08-15 3:21 PM (-4), Cousin Ricky wrote:
> >
> > Due to the 3.8 rollback, the latest version of BrightStar5, 1.1.1, will
> > not work properly with the beta versions of POV-Ray 3.8 if #version is
> > set to 3.8.  BrightStar5 1.1.2 will correct this and will be uploaded to
> > my repository shortly.  In the meantime, the previous version, 1.1,
> > works and is still available at Le Forgeron's GitHub repository.
>
> BrightStar5 1.1.2 is now uploaded to GitHub at
> https://github.com/CousinRicky/POV-Ray-Object-Collection/tree/main/BrightStar5
>
> BrightStar5 1.1.2 is updated for POV-Ray 3.8 beta, and the JRASC link is
> updated in the acknowledgments section of the User Manual.

Thanks a lot for the work you do on all this !

[Cousin Ricky] Re: Accessing Object Collection modules while th... [1694 days 10 hours and 38 minutes ago]

Mon, 16 Aug 2021 18:10:44 GMT

On 2015/21-08-15 3:21 PM (-4), Cousin Ricky wrote:
> 
> Due to the 3.8 rollback, the latest version of BrightStar5, 1.1.1, will
> not work properly with the beta versions of POV-Ray 3.8 if #version is
> set to 3.8.  BrightStar5 1.1.2 will correct this and will be uploaded to
> my repository shortly.  In the meantime, the previous version, 1.1,
> works and is still available at Le Forgeron's GitHub repository.

BrightStar5 1.1.2 is now uploaded to GitHub at
https://github.com/CousinRicky/POV-Ray-Object-Collection/tree/main/BrightStar5

BrightStar5 1.1.2 is updated for POV-Ray 3.8 beta, and the JRASC link is
updated in the acknowledgments section of the User Manual.

[Cousin Ricky] Accessing Object Collection modules while the se... [1695 days 9 hours and 27 minutes ago]

Sun, 15 Aug 2021 19:21:49 GMT

As a reminder, Le Forgeron has a mirror at:
  https://github.com/LeForgeron/PovContributions

However, there have been several updates to the Object Collection
between Le Forgeron's last GitHub refresh and the server crash earlier
this year.  Six of these were mine, and I have created a GitHub
repository with these.  This repository is at:

  https://github.com/CousinRicky/POV-Ray-Object-Collection

The Object Collection server created several administrative files that
are not included in the GitHub repos.  Since I list these files in my
user manuals, I have needed to update the user manuals accordingly.
Since one of these files was a README with information about using the
Object Collection and a brief note about the user's rights under the
LGPL, I have also added some of this information to the user manuals and
SDL header comments.  To avoid confusion over these minor edits, I
modified the version numbers, but there are no functional differences
from the latest POV server uploads.

The 6 updated modules are:
  AndroidRobot 5.0A
  CoffeeMug 2.0.1A
  RC3Metal 1.3A
  RoundEdge 2.0A
  ScaryCoronavirus 1.0B
  SphereSweep 2.1A

Due to my modules residing in multiple repositories even after the
Object Collection server is restored, I will be updating my remaining
user manuals in the same way over time.

Due to the 3.8 rollback, the latest version of BrightStar5, 1.1.1, will
not work properly with the beta versions of POV-Ray 3.8 if #version is
set to 3.8.  BrightStar5 1.1.2 will correct this and will be uploaded to
my repository shortly.  In the meantime, the previous version, 1.1,
works and is still available at Le Forgeron's GitHub repository.

Rafael also added a couple dozen contributions during this period.  His
repository is at:
  http://freeray.juegosenlazaruscostarricenses.com/

[jr] Re: License reassessment and other matters [1764 days 21 hours and 4 minutes ago]

Mon, 7 Jun 2021 07:45:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-06-05 5:20 AM (-4), jr wrote:
> >
> > I use the GPL v3+ routinely (ie unthinkingly :-)) for everything I "publish".
> >  appreciate that you (too) are not a lawyer, however, questions: should I change
> > from v3+ to another, eg LGPL?  what would be the "real" difference?
>
> Have a look at: https://www.gnu.org/licenses/why-not-lgpl.html
>
> As you know, I cannot give legal advice.

thanks.  did look, still no clearer which of the GNU licences is the "best fit"
for include files and such.  also unsure how/whether GNU v3+ "conflicts" with
Creative Commons license.

(since neither of us is a lawyer, it'd be simply your opinion.  however, you've
concerned yourself with the matter and thus your opinion is of interest (to me))

regards, jr.

[Cousin Ricky] Re: License reassessment and other matters [1766 days 11 hours and 27 minutes ago]

Sat, 5 Jun 2021 17:21:45 GMT

On 2021-06-05 5:20 AM (-4), jr wrote:
> 
> I use the GPL v3+ routinely (ie unthinkingly :-)) for everything I "publish".
>  appreciate that you (too) are not a lawyer, however, questions: should I change
> from v3+ to another, eg LGPL?  what would be the "real" difference?

Have a look at: https://www.gnu.org/licenses/why-not-lgpl.html

As you know, I cannot give legal advice.

[jr] Re: License reassessment and other matters [1766 days 19 hours and 24 minutes ago]

Sat, 5 Jun 2021 09:25:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-05-10 6:50 PM (-4), Cousin Ricky wrote:
> >
> > The LGPL has been updated to version 3.0.  Should we switch to that as a
> > collection?  Should we leave it up to the author of the module?
> > ...
> I've been reading more commentary on the LGPL 3 vs. 2.1, well, as much
> as a Web search can get you on such a narrow topic.  It seems that the
> main rationale for the GPL/LGPL 3 was to prevent TiVo from de facto
> mooting the right to modify its code.  In a nutshell, you are legally
> permitted to modify TiVo's software, but then it will no longer work on
> TiVo's hardware.
> ...

I use the GPL v3+ routinely (ie unthinkingly :-)) for everything I "publish".
 appreciate that you (too) are not a lawyer, however, questions: should I change
from v3+ to another, eg LGPL?  what would be the "real" difference?


regards, jr.

[Cousin Ricky] Re: License reassessment and other matters [1771 days 6 hours and 17 minutes ago]

Mon, 31 May 2021 22:32:10 GMT

On 2021-05-10 6:50 PM (-4), Cousin Ricky wrote:
> 
> Above all, can someone be granted all the administrative powers that
> Chris Bartlett had before he disappeared?  Decisions need to be made,
> the license being only one.  Another example is whether my suggestion to
> avoid all-lowercase identifiers should be formalized.  The community
> thinks it's a good idea, but there seems to be no formal mechanism to
> adopt it.

I would still like some discussion on how to formalize Object Collection
policies.

[Cousin Ricky] Re: License reassessment and other matters [1771 days 6 hours and 19 minutes ago]

Mon, 31 May 2021 22:29:36 GMT

On 2021-05-10 6:50 PM (-4), Cousin Ricky wrote:
> 
> The LGPL has been updated to version 3.0.  Should we switch to that as a
> collection?  Should we leave it up to the author of the module?
> 
> The one liner required by the old Object Collection upload software does
> not include the LGPL version.  This seems potentially problematic.  A
> statement to the effect of "2.1 or later" or "3.0 or later" seems
> appropriate.  Or should we keep the required one liner as is, and leave
> it up to the author of the module to specify an LGPL version on a
> separate line of SDL comment?
> 
> Can any lawyer among us explain in plain English the differences between
> v2.1 and v3.0?

I've been reading more commentary on the LGPL 3 vs. 2.1, well, as much
as a Web search can get you on such a narrow topic.  It seems that the
main rationale for the GPL/LGPL 3 was to prevent TiVo from de facto
mooting the right to modify its code.  In a nutshell, you are legally
permitted to modify TiVo's software, but then it will no longer work on
TiVo's hardware.

Richard Stallman, who created the GPL/LGPL as well as some of the
software utilized by TiVo, considers TiVo's action a violation of the
spirit of the GPL.  Linus Torvalds, who also wrote some of software the
utilized by TiVo says it's not his call.  Stallman acknowledged that
Torvalds was legally correct, and wrote GPL 3 to close that loophole.
The Linux kernel remains under GPL 2 with no license upgrade provision,
so there!

Other considerations were expanding license compatibility and preventing
patent restrictions.

Unless one of you is an attorney and sees weaknesses in the LGPL 2.1
that are relevant to SDL contributions, I see no compelling reason to
upgrade the license.  If 2.0 is good enough for Linus, then 2.1 is good
enough for me.  But I also see no reason to prevent a contributor from
writing "or later" into their SDL comments, though IANAL and I don't
know if "or later" clause would affect the legal interoperability of the
Collection in any way that would matter to a POV-Ray user.

However, now that there is at least one Object Collection repo (Le
Forgeron's) that is not on an official POV-Ray server--and is therefore
separated from the website explications and README files--I think it
would be *prudent* to write the LGPL version, the LGPL URL, and the
warranty disclaimer directly into all SDL files submitted to the Collection.

[Cousin Ricky] Object Collection origin story (discussion threa... [1781 days 9 hours and 8 minutes ago]

Fri, 21 May 2021 19:40:33 GMT

These are the discussion threads that led to the creation of the Object
Collection:

povray standard include files (original proposal by nemesis, 2006-Nov-13)

https://news.povray.org/povray.general/thread/%3Cweb.4558993a8d8f92ab3976a8750%40news.povray.org%3E/

POV-Ray Includes - Licensing (2006-Nov-23)

https://news.povray.org/povray.general/thread/%3C4565c6d0%40news.povray.org%3E/

https://news.povray.org/povray.general/thread/%3C457bcee3%241%40news.povray.org%3E/

POV-Ray Includes - Organisation (2006-Nov-27)

https://news.povray.org/povray.general/thread/%3C456b29c7%241%40news.povray.org%3E/

POV-Ray Includes - Standards (2006-Nov-27)

https://news.povray.org/povray.general/thread/%3C456b5ae2%40news.povray.org%3E/

POV-Ray Object Collection - Next (2007-Jan-06)

https://news.povray.org/povray.general/thread/%3C459faa35%241%40news.povray.org%3E/

"Discussion wasn't in vain" (2007-Oct-11)

https://news.povray.org/povray.general/thread/%3C470dd41e%241%40news.povray.org%3E/

[Cousin Ricky] Re: License reassessment and other matters [1791 days 22 hours and 35 minutes ago]

Tue, 11 May 2021 06:14:17 GMT

On 2021-05-10 7:57 PM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> The LGPL has been updated to version 3.0.  Should we switch to that as a
>> collection?  Should we leave it up to the author of the module?
> 
> We can, assuming they are still around.   Is there some time period after which
> it becomes public domain or at least under the custodianship of the site
> maintainer?

IIRC, the death of the author, plus 70 years.  Out of the hands of us
contemporary mortals.

>> Another example is whether my suggestion to
>> avoid all-lowercase identifiers should be formalized.  The community
>> thinks it's a good idea, but there seems to be no formal mechanism to
>> adopt it.
> 
> Perhaps a term for submission to the object collection can be agreement to edit
> code to align with compliance standards, changes in SDL syntax, and namespace
> considerations.

Such an agreement is already implied in the LGPL.  The question is what
formal mechanism should we use to make such changes, if we decide to.
More generally, how do we formalize the rules for this collection?

>> If a module is found to be out of compliance for its declared level, how
>> should the issue be rectified?  This is a likely situation, as
>> compliance requirements have changed since the Collection was inaugurated.
> 
> I think that some of those modules are, at this date, and given the
> circumstances, the equivalent of abandoned property.  Sometimes there are
> mechanic's liens, salvage Rights, for certain things there's usually some legal
> requirement that an announcement/notification be published in a (local)
> newspaper for a certain period of time - but I have no idea what the global
> internet equivalent of that would be.

IANAL, but it doesn't seem to me that copyrighted works can be
"abandoned."  Does a writer or an artist lose the rights to their works
if they don't regularly issue new editions?  (Trademarks *can* be
declared abandoned, but we are not dealing with trademarks here.  Well,
except for AndroidRobot, but Karl and I are not the trademark holders,
so that's still no concern here.)

> I'd say just edit them and retain the original.  Post a notice that "If you have
> a complaint, then you can request that the edited version be taken down."
> I mean, it's an object, written in SDL, for a 25-year-old raytracer.  I would
> hope that they'd take some sort of pride that their object is even being used
> after the time elapsed since they've coded it.  Not to mention - why submit it
> to the object collection unless you wanted to distribute it freely for others to
> USE in the first place?

Again, this is why the LGPL was chosen for this collection.  The module
author must check some agreement boxes on the upload form, and the
upload engine scans the SDL to make sure that an LGPL license statement
is present.  In other words, the upload form will not allow you upload a
module unless you first agree that anyone and their grandmother have the
right to modify the code, within the terms of the LGPL.

Those terms do require modified files to prominently note the date of
the changes and who made them.  License violations obviously cannot be
detected by the upload engine, but a human administrator can resolve
such problems upon request.

> Anyway, those are my thoughts on the topic.
> I'm more of a Patrick Henry guy concerning licenses, anyway.

Licenses don't get much more Patrick Henry than the LGPL.  See for
yourself at https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

[Bald Eagle] Re: License reassessment and other matters [1792 days 4 hours and 49 minutes ago]

Tue, 11 May 2021 00:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> The LGPL has been updated to version 3.0.  Should we switch to that as a
> collection?  Should we leave it up to the author of the module?

We can, assuming they are still around.   Is there some time period after which
it becomes public domain or at least under the custodianship of the site
maintainer?

> Above all, can someone be granted all the administrative powers that
> Chris Bartlett had before he disappeared?  Decisions need to be made,
> the license being only one.

I think there should always be multiple keyholders and redundancy.  Anything
could happen to any one of us, and given the state of the world, internet access
and communications in any country could become . . . spotty to nonexistant.

> Another example is whether my suggestion to
> avoid all-lowercase identifiers should be formalized.  The community
> thinks it's a good idea, but there seems to be no formal mechanism to
> adopt it.

Perhaps a term for submission to the object collection can be agreement to edit
code to align with compliance standards, changes in SDL syntax, and namespace
considerations.

> Can there be a method of succession, so the Collection is not again left
> without an administrator?

> If a module is found to be out of compliance for its declared level, how
> should the issue be rectified?  This is a likely situation, as
> compliance requirements have changed since the Collection was inaugurated.

I think that some of those modules are, at this date, and given the
circumstances, the equivalent of abandoned property.  Sometimes there are
mechanic's liens, salvage Rights, for certain things there's usually some legal
requirement that an announcement/notification be published in a (local)
newspaper for a certain period of time - but I have no idea what the global
internet equivalent of that would be.

I'd say just edit them and retain the original.  Post a notice that "If you have
a complaint, then you can request that the edited version be taken down."
I mean, it's an object, written in SDL, for a 25-year-old raytracer.  I would
hope that they'd take some sort of pride that their object is even being used
after the time elapsed since they've coded it.  Not to mention - why submit it
to the object collection unless you wanted to distribute it freely for others to
USE in the first place?

Anyway, those are my thoughts on the topic.
I'm more of a Patrick Henry guy concerning licenses, anyway.

[Cousin Ricky] License reassessment and other matters [1792 days 5 hours and 58 minutes ago]

Mon, 10 May 2021 22:50:32 GMT

While we are waiting for the Object Collection website to be restored,
this is probably a good time to discuss the license and management of
the Collection.  These are some concerns and questions I have:

The LGPL has been updated to version 3.0.  Should we switch to that as a
collection?  Should we leave it up to the author of the module?

The one liner required by the old Object Collection upload software does
not include the LGPL version.  This seems potentially problematic.  A
statement to the effect of "2.1 or later" or "3.0 or later" seems
appropriate.  Or should we keep the required one liner as is, and leave
it up to the author of the module to specify an LGPL version on a
separate line of SDL comment?

Can any lawyer among us explain in plain English the differences between
v2.1 and v3.0?

The LGPL 3.0 is essentially an addendum to the GPL 3.0.  If we upgrade
as a collection, how should the README handle the two-part nature of the
license?

Should we change the link to point directly to the GNU website, skipping
Creative Commons altogether?  (If so, we'll need a new icon.  There is
one on the GNU website for the LGPL 3.0, but not for 2.1.)

If we upgrade to LGPL 3.0, is there even a CC wrapper?  The CC website
appears to have orphaned all the pages for its older licenses, and the
GNU wrappers appear to be among those.  (If someone can find a link from
anywhere on their website, please let us know!)

The recommended LGPL notice, aside from being wordier than the one liner
required by the old Object Collection upload software, implies that a
copy of the license itself should accompany the module downloads.
Should we do this?  GNU's instructions are at
  https://www.gnu.org/licenses/gpl-howto.html

Above all, can someone be granted all the administrative powers that
Chris Bartlett had before he disappeared?  Decisions need to be made,
the license being only one.  Another example is whether my suggestion to
avoid all-lowercase identifiers should be formalized.  The community
thinks it's a good idea, but there seems to be no formal mechanism to
adopt it.

Can there be a method of succession, so the Collection is not again left
without an administrator?

There was also supposed to be a validation process to insure that
modules marked as compliant meet those standards.  So far, only 12
modules have been validated--all written by the previous administrator.
If the administrator himself validated his own modules, then effectively
*none* of the modules have been validated.

If a module is found to be out of compliance for its declared level, how
should the issue be rectified?  This is a likely situation, as
compliance requirements have changed since the Collection was inaugurated.

[Mike Horvath] Re: More Detail not rendering [1838 days and 58 minutes ago]

Fri, 26 Mar 2021 03:50:40 GMT

On 3/6/2021 2:40 AM, Thomas de Groot wrote:
> Op 05/03/2021 om 13:00 schreef Le_Forgeron:
>> Le 12/11/2020 Ã  21:52, Bill Pragnell a Ã©critÂ :
>>> Was just browsing the collection, I found that all the 'More Detail' 
>>> links on
>>> the various submissions don't get rendered by my browser. All I get 
>>> is the .html
>>> source code in plaintext.
>>>
>>> Is my browser broken, or does anybody else see this?
>>>
>>> Bill
>>>
>>>
>>
>> Nice investigations everyone, BUT the current serving of html as text by
>> the server IS DONE ON PURPOSE.
>>
>> It was, IIRC, a reaction to spam-bots filling entries with html to catch
>> unprotected readers.
>>
>> Maybe it was not the best move, but it was done.
>>
> 
> Indeed. I do remember this. The object collection had become quite 
> useless because of those bots. :-/
> 

Should not try to show/serve an HTML page at all in that case. Maybe 
show some other safer type of markup instead, or just a text file.


Mike

[Thomas de Groot] Re: More Detail not rendering [1857 days 21 hours and 8 minutes ago]

Sat, 6 Mar 2021 07:40:50 GMT

Op 05/03/2021 om 13:00 schreef Le_Forgeron:
> Le 12/11/2020 Ã  21:52, Bill Pragnell a Ã©critÂ :
>> Was just browsing the collection, I found that all the 'More Detail' links on
>> the various submissions don't get rendered by my browser. All I get is the .html
>> source code in plaintext.
>>
>> Is my browser broken, or does anybody else see this?
>>
>> Bill
>>
>>
> 
> Nice investigations everyone, BUT the current serving of html as text by
> the server IS DONE ON PURPOSE.
> 
> It was, IIRC, a reaction to spam-bots filling entries with html to catch
> unprotected readers.
> 
> Maybe it was not the best move, but it was done.
> 

Indeed. I do remember this. The object collection had become quite 
useless because of those bots. :-/

-- 
Thomas

[Le Forgeron] Re: More Detail not rendering [1858 days 16 hours and 49 minutes ago]

Fri, 5 Mar 2021 12:00:27 GMT

Le 12/11/2020 Ã  21:52, Bill Pragnell a Ã©critÂ :
> Was just browsing the collection, I found that all the 'More Detail' links on
> the various submissions don't get rendered by my browser. All I get is the .html
> source code in plaintext.
> 
> Is my browser broken, or does anybody else see this?
> 
> Bill
> 
> 

Nice investigations everyone, BUT the current serving of html as text by
the server IS DONE ON PURPOSE.

It was, IIRC, a reaction to spam-bots filling entries with html to catch
unprotected readers.

Maybe it was not the best move, but it was done.

[Dick Balaska] Re: More Detail not rendering [1859 days 10 hours and 40 minutes ago]

Thu, 4 Mar 2021 18:08:29 GMT

On 3/4/2021 6:32 AM, zebulon 1er wrote:
> Hello,
> 
> In Firefox (86.0 (64 bits)) I notice the same display bug.
> 
> Maybe the answer is in the html source...
> 
> lib.povray.org detail pages begin with
> 
> <!DOCTYPE html>
> 
> only, instead of
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
> 
> in all other povray.org pages.
> 
> So, I tried by changing this 1st line, in a new local saved file. Then I opened
> it in Firefox, and it works. The HTML page is displayed correctly.
> 
> Now, you know what to do :)
> 
> 

That's not it.  Browsers, Firefox in particular, are very generous in 
what they accept.  I believe if you save that file with the original 
html5 DOCTYPE, it would render just as fine.

The issue is the apache server config, which needs:

AddType text/html .html

to set the output content-type to

Content-Type: text/html; charset=ISO-8859-1

instead of

Content-Type: text/plain

-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[jr] Re: More Detail not rendering [1859 days 14 hours and 49 minutes ago]

Thu, 4 Mar 2021 14:00:07 GMT

hi,

"zebulon 1er" <nomail@nomail> wrote:
> Hello,
>
> In Firefox (86.0 (64 bits)) I notice the same display bug.
>
> Maybe the answer is in the html source...
>
> lib.povray.org detail pages begin with
>
> <!DOCTYPE html>
>
> only, instead of
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
>
> in all other povray.org pages.
>
> So, I tried by changing this 1st line, in a new local saved file. Then I opened
> it in Firefox, and it works. The HTML page is displayed correctly.
>
> Now, you know what to do :)

nice catch.


regards, jr.

[zebulon 1er] Re: More Detail not rendering [1859 days 17 hours and 14 minutes ago]

Thu, 4 Mar 2021 11:35:00 GMT

Hello,

In Firefox (86.0 (64 bits)) I notice the same display bug.

Maybe the answer is in the html source...

lib.povray.org detail pages begin with

<!DOCTYPE html>

only, instead of

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

in all other povray.org pages.

So, I tried by changing this 1st line, in a new local saved file. Then I opened
it in Firefox, and it works. The HTML page is displayed correctly.

Now, you know what to do :)

[zebulon 1er] Re: Vector images [1859 days 17 hours and 44 minutes ago]

Thu, 4 Mar 2021 11:05:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> On 3/9/2019 9:35 AM, Bald Eagle wrote:
> > Mike Horvath <mik### [at] gmailcom> wrote:
> >> I created some vector images that I (after converting them to PNG) used
> >> for axis, label, measurement, etc. graphics. I want to keep them with my
> >> collection, but I don't think I am allowed to upload them. Would it be
> >> possible to make an exception for a vector format of some type? I use
> >> SVG, but I understand that can be a risk since it is possible to insert
> >> JavaScript into it. Maybe a different format would be better? Thanks.
> >>
> >>
> >> Mike
> >
> > How large are the SVG files?
> > Aren't they all just a text-based format like HTML?
> >
> > You could rename them to .txt and likely post them.
> >
> > Alternatively, you can embed them into the header of a jpg file of the same
> > image.   Then I think you can just rename it to .svg and it's instantly useable
> > as one.
> >
> >
>
>
> They are not very large at all. Renaming the extension is a good idea. I
> will try that.
>
>
> Mike

Hello,

As I saw elsewhere here, you can just add .txt (or .dat) at end : file.svg ->
file.svg.txt

[Bill Pragnell] Re: More Detail not rendering [1971 days 6 hours and 24 minutes ago]

Thu, 12 Nov 2020 22:25:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> It has been that way for a long, long time, my friend.
>
>
http://news.povray.org/povray.object-collection/thread/%3C54e8061c%241%40news.povray.org%3E/
>
> You have to make a local copy and then manually edit it so it displays right.
> :|

Oh well, as long as it's a known issue. No worries!

[jr] Re: More Detail not rendering [1971 days 6 hours and 34 minutes ago]

Thu, 12 Nov 2020 22:15:01 GMT

hi,

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> Was just browsing the collection, I found that all the 'More Detail' links on
> the various submissions don't get rendered by my browser. All I get is the .html
> source code in plaintext.
>
> Is my browser broken, or does anybody else see this?

same here (Chrome 86.0.4240.183).


regards, jr.

[Bald Eagle] Re: More Detail not rendering [1971 days 6 hours and 39 minutes ago]

Thu, 12 Nov 2020 22:10:01 GMT

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> Was just browsing the collection, I found that all the 'More Detail' links on
> the various submissions don't get rendered by my browser. All I get is the .html
> source code in plaintext.
>
> Is my browser broken, or does anybody else see this?
>
> Bill

It has been that way for a long, long time, my friend.

http://news.povray.org/povray.object-collection/thread/%3C54e8061c%241%40news.povray.org%3E/

You have to make a local copy and then manually edit it so it displays right.
:|

[Bill Pragnell] More Detail not rendering [1971 days 7 hours and 54 minutes ago]

Thu, 12 Nov 2020 20:55:08 GMT

Was just browsing the collection, I found that all the 'More Detail' links on
the various submissions don't get rendered by my browser. All I get is the .html
source code in plaintext.

Is my browser broken, or does anybody else see this?

Bill

[Thomas de Groot] [2016 days 22 hours and 25 minutes ago]

Mon, 28 Sep 2020 06:24:09 GMT

Op 27/09/2020 om 22:18 schreef Cousin Ricky:
[snip]
> 
> As I said I would do in another thread, I have changed all "order" 
> terminology to "degree," including some variable names.Â  The delay in 
> uploading 2.1 was to retest the module.Â  Now, why should I have to do 
> substantial retesting after a simple search and replace?Â  It's because I 
> have seen too many coders get burned by taking seemingly minor changes 
> for granted.Â  You never know when you'll slip up, or what the other end 
> of that strand of spaghetti is attached to.

Very wise and to the point. Well done, and thanks for your work indeed.

-- 
Thomas

[Cousin Ricky] [2017 days 8 hours and 31 minutes ago]

Sun, 27 Sep 2020 20:18:27 GMT

SphereSweep now does quadratic (2nd degree) BÃ©zier sweeps natively.

Bill, I trust that this will simplify your code.

http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky

More Adventures in Verification

Last time, during final proofreading of the User Manual, I discovered a
major error in my understanding of BÃ©zier math that would have been
quite embarrassing to have uploaded. This time, I discovered a gap in
the test procedure for the PointArrays conversion. PointArrays is good
all the way back to POV-Ray 3.6.1, but my test scene was #versioned at
3.7. Not wanting to take anything for granted, I rolled back the
#version and retested it.

Fortunately, it only took removing an unnecessary pigment and converting
the #elseif and the #for loops in the test scene to verify that the
PointArrays conversions that I already uploaded work fine in 3.6.1.
That said, the SphereSweep_Approx() artifacts in 3.6.1 were the stuff of
nightmares! There were no artifacts in the PointArrays equivalents. It
seems that using a linear sphere_sweep with numerous short segments
along non-linear splines (which PointArrays doesn't do) can overwhelm
the 3.6 engine. When the objects were replaced with SphereSweep_CSG(),
there were no artifacts.

As for that unnecessary pigment, apparently there are situations where
3.6 balks when presented with a textured object, but where 3.7 doesn't
care. This affected the test scene only, and has no direct bearing on
SphereSweep.

As I said I would do in another thread, I have changed all "order"
terminology to "degree," including some variable names. The delay in
uploading 2.1 was to retest the module. Now, why should I have to do
substantial retesting after a simple search and replace? It's because I
have seen too many coders get burned by taking seemingly minor changes
for granted. You never know when you'll slip up, or what the other end
of that strand of spaghetti is attached to.

[Cousin Ricky] AndroidRobot 5.0: the 2019 branding update [2025 days 6 hours and 11 minutes ago]

Sat, 19 Sep 2020 22:37:41 GMT

The new Android[TM] logo is just a disembodied head, so a new macro has
been created to do just that. The obvious name for such a macro would
be AndroidRobot_Head(), but The Google didn't tell me they were going to
pull this stunt 5 years ago, so I had already used that name for
something else. So it goes.

The official Android green has been updated, and since the head has
changed noticeably from past logos, the overall proportions of the robot
have been adjusted to fit. All past designs and official colors are
still available with this update; see the User Manual for details. (The
unofficial color from AndroidRobot 1.0 has not been retained; if, for
some reason, you feel nostalgic about it, it was srgbft MediumSpringGreen.)

http://lib.povray.org/searchcollection/index2.php?objectName=AndroidRobot&contributorTag=Cousin%20Ricky

The changes to this module over the years have required repeated
breaking up of existing code into smaller internal macros. It feels
kind of weird doing all this surgery on someone else's code outside of a
collaborative context; I have to keep telling myself that Karl Ostmo
checked all 4 of those little boxes on the submission page before he
uploaded the module.

Caveat: The standard Object Collection README file says that you may
use images that you generate using these files without restriction. As
the Android robot is trademarked, this is obviously not true for this
particular module. Again, see the User Manual for the licensing details.

[Cousin Ricky] Re: AndroidRobot 3.0a [2029 days 9 hours and 25 minutes ago]

Tue, 15 Sep 2020 19:24:20 GMT

On 2015-04-27 3:22 PM (-4), Cousin Ricky wrote:
> 
> I found an SVG version of the logo, which is claimed to have originated 
> from a Web page on the Android developer site, although in keeping with 
> The Google's typical practice, the page no longer exists.Â  (I know 
> someone on these newsgroups works for The Google.Â  Tell 'em to stop 
> that.)Â  I ran the coordinates from the SVG source code through a 
> spreadsheet so that the new model would have the same size and position 
> as Karl's (burning bridges also makes me crazy), but with official 
> proportions.

Just when you think you sufficiently documented a past project, or 
thought you could get away with not declaring magic numbers...

The new head design issued last year has changed from the previous heads 
to the extent that I need to go back to that spreadsheet to 
re-proportion the entire robot.  I've reacquainted myself with both the 
SVG file and the spreadsheet, added comments  to the SVG file, 
and created identifiers in androidrobot.inc for most of the magic 
numbers that correspond to the spreadsheet numbers.  But I've run into a 
strange snag: two of the numbers in the spreadsheet do not show up in 
the relevant macro, and the two would-be corresponding numbers in the 
macro do not show up in the spreadsheet!

I will have to figure out where my head was 5 years ago, and how those 
two macro numbers relate to the spreadsheet.

[Cousin Ricky] SphereSweep 2.0 and PointArrays [2035 days 3 hours and 14 minutes ago]

Thu, 10 Sep 2020 01:34:31 GMT

Android's new logo is just a disembodied head, and it turns out that
extrapolating the head to reporportion the rest of the robot takes a bit
of math. Well, arithmetic mostly, but you need math to figure out how
to apply the arithmetic. So, even though I wrote in the last thread
that AndroidRobot has priority, SphereSweep 2.0, though unfinished, was
at a stopping point, and all I had to do was excise the unfinished code,
update the user manual, and do final tests.

It turned out that, thanks to the _correct_ way to downgrade a cubic
BÃ©zier to a quadratic, the BÃ©zier bug in SphereSweep 1.2 wasn't
as
consequential as it initially appeared to be, reducing the urgency of
this upgrade. But if I hadn't decided to post the upgrade, with the
final scrutiny I give my modules before uploading them, I wouldn't have
discovered my error on how to downgrade the cubic. The apparent urgency
of the upgrade is what revealed that it wasn't urgent! But the module
is done, so here it is.

The main new feature of SphereSweep 2.0 is conversion macros between
SphereSweep and another Object Collection module, PointArrays. As I was
finishing up SphereSweep 1.2, I discovered there was quite a bit of
overlap between SphereSweep and PointArrays, and I figured maybe some
POVers might want to take advantage of features of both modules.
However, their data structures are incompatible, so I wrote the
conversion macros. I hope you find them useful.

Since downgrading a cubic BÃ©zier isn't as simple as I thought, there
will definitely be a quadratic BÃ©zier spline in a future version of
SphereSweep.

http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky

[Bald Eagle] Re: Sphere Sweep 1.2 Quadratic spline question -... [2036 days 5 hours and 29 minutes ago]

Tue, 8 Sep 2020 23:20:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> The end points are the same for both methods, right?  So why would they
> need any influence from the other points?

See below.

> https://commons.wikimedia.org/wiki/File:Quadratic_to_cubic_Bezier_curve.svg

> You can see that the 2nd point
> is on the line between P1 and P2, which needs no input from P3; and the
> 3rd point is on the line between P2 and P3, which needs no input from P1.
>
> Each point on the cubic BÃ©zier curve is computed as:
>    P(t) = (1-t)Â³*P1 + 3*(1-t)Â²*t*P2 + 3*(1-t)*tÂ²*P3
+ tÂ³*P4

Yeah - I got it now, it "clicked".
The fatigue was like a brick wall and any information was just bouncing off like
ping pong balls.

My tired brain was comingling the Bernstein polynomial terms for the control
points with your calculation of the coordinates OF the control points for the
array.

Thanks, Richard - all is clear now.
It works just fine in the SVG conversion too.  Doesn't look materially different
from the wrong way - likely because the control points are all so close together
and there's not much overall "curve" to the spline.

[Cousin Ricky] Re: Sphere Sweep 1.2 Quadratic spline question -... [2036 days 7 hours and 39 minutes ago]

Tue, 8 Sep 2020 21:09:40 GMT

On 2020-09-08 2:32 PM (-4), Bald Eagle wrote:
> 
> The initial suggestion was to do:
>>>     Â  array { P1, P2, P2, P3 },
> (seemed totally reasonable to me, and seemed to give good results)

Seemed totally reasonable to me, too, which is why I made that mistake. 
But human brains are notoriously bad at math.

> So what I'm asking is: why aren't ALL 3 control points appearing as terms in the
> equations for each of the array elements?
> 
> I'm not doubting that the correction you're proposing is right, I'd just like
> you to articulate, for my own benefit, why, in light of the corrections to the
> 2nd and 3rd elements, the first and last elements are still solitary control
> points, and why the second doesn't have a term for P3, and the third doesn't
> have a term for P1.

The end points are the same for both methods, right?  So why would they 
need any influence from the other points?

As for the 2nd and 3rd points, I think they are best explained with an 
illustration:

https://commons.wikimedia.org/wiki/File:Quadratic_to_cubic_Bezier_curve.svg

P1 and P3 are the gray circles, and P2 is the magenta circle.  The 2nd 
and 3rd cubic points are the yellow circles, and the quadratic curve is 
the yellow curve with the black border.  You can see that the 2nd point 
is on the line between P1 and P2, which needs no input from P3; and the 
3rd point is on the line between P2 and P3, which needs no input from P1.

Each point on the cubic BÃ©zier curve is computed as:
   P(t) = (1-t)Â³*P1 + 3*(1-t)Â²*t*P2 + 3*(1-t)*tÂ²*P3 +
tÂ³*P4

As this one formula includes all 4 control points, all the curve needs 
is for each of the quadratic points to be accounted for in _at least_ 
one cubic point.  There is simply no need for each of the cubic points 
to include all 3 of the quadratic points.

[Bald Eagle] Re: Sphere Sweep 1.2 Quadratic spline question -... [2036 days 10 hours and 14 minutes ago]

Tue, 8 Sep 2020 18:35:00 GMT

What I mean is:

The "usual" array is {P1, P2, P3, P4}

The initial suggestion was to do:
> >  Â Â Â  array { P1, P2, P2, P3 },
(seemed totally reasonable to me, and seemed to give good results)

Which is just P3 = P2.

Now you're saying:
>    SphereSweep_Approx
>    ( SSWP_BEZIER_SPLINE,
array {
P1,
P1 * 1/3 + P2 * 2/3,
P2 * 2/3 + P3 * 1/3,
P3 },

So what I'm asking is: why aren't ALL 3 control points appearing as terms in the
equations for each of the array elements?

I'm not doubting that the correction you're proposing is right, I'd just like
you to articulate, for my own benefit, why, in light of the corrections to the
2nd and 3rd elements, the first and last elements are still solitary control
points, and why the second doesn't have a term for P3, and the third doesn't
have a term for P1.

[Cousin Ricky] Re: Sphere Sweep 1.2 Quadratic spline question -... [2036 days 10 hours and 46 minutes ago]

Tue, 8 Sep 2020 18:02:50 GMT

On 2020-09-08 1:36 PM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> That is wrong!  Something didn't look right about the curve, so I went
>> back and double-checked the BÃ©zier theory.  The correct solution is
this:
>>
>>   SphereSweep_Approx
>>   ( SSWP_BEZIER_SPLINE,
>>     array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 },
>>     array { Line, Line, Line, Line}, 100, 0
>>   )
>>
>> I will post an example illustration in p.b.i.
> 
> Without picking through the underlying code of the spheresweep, I'll just say
> that the curve indeed looks correct, but (now, to me,)
> array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 }
> does not.
> 
> Since a Bezier spline uses some fraction of all of the control points across the
> entire spline (except for the absolute endpoints), shouldn't there be a P3 and a
> P1 term in there - or does that somehow get (partially) accounted for under the
> hood?

I don't know what you mean; all 3 terms are in the array.  The 2nd term 
is 2/3 of the way from P1 to P2, and the 3rd term is 2/3 of the way from 
P3 to P2.

Under the hood, the formula draws from all 4 control points, so each of 
the 3 quadratic points gets its input.

[Bald Eagle] Re: Sphere Sweep 1.2 Quadratic spline question -... [2036 days 11 hours and 9 minutes ago]

Tue, 8 Sep 2020 17:40:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> That is wrong!  Something didn't look right about the curve, so I went
> back and double-checked the BÃ©zier theory.  The correct solution is this:
>
>    SphereSweep_Approx
>    ( SSWP_BEZIER_SPLINE,
>      array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 },
>      array { Line, Line, Line, Line}, 100, 0
>    )
>
> I will post an example illustration in p.b.i.

Without picking through the underlying code of the spheresweep, I'll just say
that the curve indeed looks correct, but (now, to me,)
array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 }
does not.

Since a Bezier spline uses some fraction of all of the control points across the
entire spline (except for the absolute endpoints), shouldn't there be a P3 and a
P1 term in there - or does that somehow get (partially) accounted for under the
hood?

I was too tired to work out the correct derivatives of the Bernstein polynomial
terms the other day, and I have things to do before I will have a chance to look
into this any further.

Just asking to clarify and triple check.  ;)

[Cousin Ricky] Re: Sphere Sweep 1.2 Quadratic spline question -... [2036 days 21 hours and 42 minutes ago]

Tue, 8 Sep 2020 07:07:11 GMT

On 2020-08-31 1:22 PM (-4), Cousin Ricky wrote:
> 
> To get an SVG style quadratic curve, you would need to use 
> SSWP_BEZIER_SPLINE, and clone the middle control point:
> 
>  Â  SphereSweep_Approx
>  Â  ( SSWP_BEZIER_SPLINE,
>  Â Â Â  array { P1, P2, P2, P3 },
>  Â Â Â  array { Line, Line, Line, Line}, 100, 0
>  Â  )

That is wrong!  Something didn't look right about the curve, so I went 
back and double-checked the BÃ©zier theory.  The correct solution is this:

   SphereSweep_Approx
   ( SSWP_BEZIER_SPLINE,
     array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 },
     array { Line, Line, Line, Line}, 100, 0
   )

I will post an example illustration in p.b.i.

[Cousin Ricky] Re: Sphere Sweep 1.2 Quadratic spline question [2044 days 3 hours and 47 minutes ago]

Tue, 1 Sep 2020 01:01:32 GMT

On 2020-08-31 7:30 PM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> To get an SVG style quadratic curve, you would need to use
>> SSWP_BEZIER_SPLINE, and clone the middle control point:
> 
>> Unfortunately, the BÃ©zier algorithm in SphereSweep 1.2 does not handle
>> such cloning properly.  You'll need to replace macro SSwp__Bezier_calc()
>> in spheresweep.inc with the following:
> 
> Weird, but glad you had a quick fix all ready to plug in.  :)

It's been sitting on the shelf, while I try to figure out how to 
reproduce one of Hgpovray's sphere_sweep features using official 
POV-Ray.  But now that this graceful degradation failure (that's "bug" 
in English) has turned up, I'm moving the patch up in the queue.  (An 
update to AndroidRobot has priority, though.  The Google keeps changing 
things.)

> Thanks very much - that fixed the bumpiness of the outlines.
> Now I have to figure out why the SVG splines render oh-so-very nicely in a
> browser, but have all sorts of apparently extraneous lines and scribble when
> converted over to sphere sweeps...

Such problems are why I wrote the SphereSweep module in the first place.

[Bald Eagle] Re: Sphere Sweep 1.2 Quadratic spline question [2044 days 5 hours and 14 minutes ago]

Mon, 31 Aug 2020 23:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> SVG's quadratic curve uses 2nd order BÃ©zier splines, while
> SSWP_QUADRATIC_SPLINE uses POV-Ray's built-in quadratic spline type,
> which connects the control points with parabolic curves.  They are two
> different spline types.

I /thought/ that might be the case.

> To get an SVG style quadratic curve, you would need to use
> SSWP_BEZIER_SPLINE, and clone the middle control point:

> Unfortunately, the BÃ©zier algorithm in SphereSweep 1.2 does not handle
> such cloning properly.  You'll need to replace macro SSwp__Bezier_calc()
> in spheresweep.inc with the following:

Weird, but glad you had a quick fix all ready to plug in.  :)

> It is under consideration.  In any case, the BÃ©zier algorithm patch will
> definitely be in the next update.

Thanks very much - that fixed the bumpiness of the outlines.
Now I have to figure out why the SVG splines render oh-so-very nicely in a
browser, but have all sorts of apparently extraneous lines and scribble when
converted over to sphere sweeps...

[Cousin Ricky] Re: Sphere Sweep 1.2 Quadratic spline question [2044 days 11 hours and 26 minutes ago]

Mon, 31 Aug 2020 17:22:30 GMT

On 2020-08-30 8:04 PM (-4), Bald Eagle wrote:
> I'm using SphereSweep_Approx (SSWP_QUADRATIC_SPLINE ....)
> to draw some SVG data, and I noticed that the control point is intersected by
> the curve, whereas in SVG, they show the curve being inside of the convex hull
> of control points.
> Is this intentional behaviour of the macros?
> Am I doing something wrong, using it improperly?

SVG's quadratic curve uses 2nd order BÃ©zier splines, while 
SSWP_QUADRATIC_SPLINE uses POV-Ray's built-in quadratic spline type, 
which connects the control points with parabolic curves.  They are two 
different spline types.

To get an SVG style quadratic curve, you would need to use 
SSWP_BEZIER_SPLINE, and clone the middle control point:

   SphereSweep_Approx
   ( SSWP_BEZIER_SPLINE,
     array { P1, P2, P2, P3 },
     array { Line, Line, Line, Line}, 100, 0
   )

Unfortunately, the BÃ©zier algorithm in SphereSweep 1.2 does not handle 
such cloning properly.  You'll need to replace macro SSwp__Bezier_calc() 
in spheresweep.inc with the following:

----------[BEGIN CODE]----------
#macro SSwp__Bezier_calc (T, pv_Points, Radii, s_Macro)
   #local sswp_NPts = dimension_size (pv_Points, 1);
   #local sswp_Pt0 = floor (T / 4) * 4; // index of 1st point in segment
   #local sswp_T0 = (T - sswp_Pt0) / 3; // t, within segment
   #local sswp_T1 = 1 - sswp_T0; // 1 - t, within segment
   #if (sswp_T0 > 1 | T < 0 | T >= sswp_NPts)
     SSwp__Report
     ( s_Macro,
       concat
       ( "SSwp__Bezier_calc() was called with T = ", str (T, 0, -1),
         " for ", str (sswp_NPts, 0, 0), " points."
       )
     )
   #end
   #local sswp_MaxR = dimension_size (Radii, 1) - 1;
   #local sswp_Pt = <0,0,0>
   + pow (sswp_T1, 3) * pv_Points [sswp_Pt0]
   + 3 * pow (sswp_T1, 2) * sswp_T0 * pv_Points [sswp_Pt0+1]
   + 3 * sswp_T1 * pow (sswp_T0, 2) * pv_Points [sswp_Pt0+2]
   + pow (sswp_T0, 3) * pv_Points [sswp_Pt0+3];
   #local sswp_R =
     pow (sswp_T1, 3) * Radii [min (sswp_Pt0, sswp_MaxR)]
   + 3 * pow (sswp_T1, 2) * sswp_T0 * Radii [min (sswp_Pt0+1, sswp_MaxR)]
   + 3 * sswp_T1 * pow (sswp_T0, 2) * Radii [min (sswp_Pt0+2, sswp_MaxR)]
   + pow (sswp_T0, 3) * Radii [min (sswp_Pt0+3, sswp_MaxR)];
   <sswp_Pt.x, sswp_Pt.y, sswp_Pt.z, sswp_R>
#end
-----------[END CODE]-----------

> Would it be possible to have an additional, alternative quadratic spline added?

It is under consideration.  In any case, the BÃ©zier algorithm patch will 
definitely be in the next update.

 > Thanks!   :)

No problem!

[Bald Eagle] Sphere Sweep 1.2 Quadratic spline question [2045 days 4 hours and 44 minutes ago]

Mon, 31 Aug 2020 00:05:01 GMT

I'm using SphereSweep_Approx (SSWP_QUADRATIC_SPLINE ....)
to draw some SVG data, and I noticed that the control point is intersected by
the curve, whereas in SVG, they show the curve being inside of the convex hull
of control points.
Is this intentional behaviour of the macros?
Am I doing something wrong, using it improperly?

Would it be possible to have an additional, alternative quadratic spline added?

https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths


Thanks!   :)




#version 3.8;
global_settings {assumed_gamma 1.0}

camera {
 location <0.5, 0.5, -1.25>
 right x*image_width/image_height
 up y
 look_at <0.5, 0.5, 0>
}

light_source {<3, 2, -10> rgb 1}

sky_sphere {pigment {rgb <0.3, 0.3, 0.75>}}

#include "BezierInclude.inc"
#include "spheresweep.inc"

#declare P1 = <0, 0, 0>;
#declare P2 = <0.5, 1.0, 0>;
#declare P3 = <1, 0, 0>;

object {
SphereSweep_Approx (SSWP_QUADRATIC_SPLINE, array {P1, P2, P3}, array {Line,
Line, Line}, 100, 0)
pigment {rgb <0, 0, 0>}
}


Point (P1,  2, texture {pigment {rgb <1, 0, 0>}})
Point (P2,  2, texture {pigment {rgb <1, 0, 0>}})
Point (P3,  2, texture {pigment {rgb <1, 0, 0>}})

cylinder { P1, P2, Line pigment {rgb <1, 0, 0>}}
cylinder { P2, P3, Line pigment {rgb <1, 0, 0>}}

[Cousin Ricky] Re: The Bright Star Catalogue [2088 days 12 hours and 36 minutes ago]

Sat, 18 Jul 2020 16:12:30 GMT

On 2020-07-16 12:36 PM (-4), Le_Forgeron wrote:
> Le 08/02/2017 Ã  14:08, Cousin Ricky a Ã©critÂ :
> 
> I currently have a strange interest on constellations, is there a way to
> have them nicely drawn as the sample for Orion ?

A general procedure would not be straightforward.  I chose Orion 
specifically because it is on the celestial equator, and would not 
require a fancy map projection.  I had not considered map projection 
within the scope of the module, as different persons would have 
different needs.

> I tried to have a look at the include files, and the sample scene, but
> I'm afraid the data to connect the stars as per the constellation is
> missing and hard coded for orion in the sample.

There is no official set of constellation lines.  It is up to the 
imagination of the person drawing the chart.

[Le Forgeron] Re: The Bright Star Catalogue [2090 days 12 hours and 12 minutes ago]

Thu, 16 Jul 2020 16:36:56 GMT

Le 08/02/2017 Ã  14:08, Cousin Ricky a Ã©critÂ :
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted them to SDL.Â  This catalog contains all
> nighttime stars of magnitude 6.5 and brighter (roughly all nighttime
> stars visible to the naked eye), plus a few dimmer ones.Â  The
> BrightStar5 module includes more data fields than the include file
> Rarius published a while back, including catalog designations and color
> data.Â  Macros are included for star coloration and Bayer designation
> labels.Â  You can also seek individual stars by Bayer, Draper, Flamsteed,
> or SAO designations.
> 
Thanks for that, and ulterior versions (1.1.1).

I currently have a strange interest on constellations, is there a way to
have them nicely drawn as the sample for Orion ?


I tried to have a look at the include files, and the sample scene, but
I'm afraid the data to connect the stars as per the constellation is
missing and hard coded for orion in the sample.

[Cousin Ricky] ScaryCoronavirus [2158 days 6 hours and 1 minute ago]

Sat, 9 May 2020 22:48:20 GMT

For your cathartic pleasure(?), I present a scary-looking Gorgon-like 
coronavirus based on the SARS-CoV-2 agent that causes COVID-19. The 
protein spikes have demonic-looking faces.

Disclaimer: I am not a microbiologist.

http://lib.povray.org/searchcollection/index2.php?objectName=ScaryCoronavirus&contributorTag=Cousin%20Ricky

[William F Pokorny] Re: RoundEdge 2.0: unequal edge radii [2165 days 12 hours and 5 minutes ago]

Sat, 2 May 2020 16:43:48 GMT

On 5/2/20 9:51 AM, Bald Eagle wrote:
> 
...
> I also have to bring up the parametric object speed again - I haven't yet dug
> into the source for that, but it doesn't really make any sense why that should
> be any slower than any of the rest of the object primitives, or at least THAT
> much slower.
> Maybe the reason for its drag can point to clues for speeding up ALL of the
> function evaluations?
> 
...
> 

I don't use it, but forgot about your mention of parametric...

I'm not sure why so slow either though suppose we should expect it to be 
3x slower as a sort of baseline. Never looked at it with any of the 
performance tools. Next time I have a compile set up for profiling I'll 
try to remember to run a parametric or two. Maybe something will pop out.

I've dug a little into parametric shadow issues. I think Jerome has a 
github issue open on the parametric for something similar. Didn't dig 
deep, but looked to me like the code only returns one root which can be 
an problem for shadows.

Bill P.

[William F Pokorny] Re: RoundEdge 2.0: unequal edge radii [2165 days 12 hours and 59 minutes ago]

Sat, 2 May 2020 15:49:55 GMT

On 5/2/20 9:51 AM, Bald Eagle wrote:
> 
> Given all of the isosurface stuff I [try to] do, and the functions that are
> needed to do them, I really do have to say that it seems like something is
> amiss.
> 
> I mean, I watch people code shaders, and then I follow along the best I can with
> analogous POV-Ray code, and things quickly get SLOW - for a single render -
> while they are still happily running at 30+ fps.
> 
> (and damn - RT vortices...   :O
> https://www.shadertoy.com/view/MlS3Rh
> https://www.win.tue.nl/~vanwijk/ibfv/ibfv.pdf
> )
> 
> Is it a function evaluation issue?
> Do vector functions make thing THAT much faster?
> (they even use swizzling)
> Is it a core isosurface code issue?
> Can the pigment pattern - to - isosurface trick help to speed that up?
> Is it that the shaders use GPU rather than cpu (ShaderToy runs in a browser...)
> Does the shader stuff somehow get compiled beforehand?
> 
> I also have to bring up the parametric object speed again - I haven't yet dug
> into the source for that, but it doesn't really make any sense why that should
> be any slower than any of the rest of the object primitives, or at least THAT
> much slower.
> Maybe the reason for its drag can point to clues for speeding up ALL of the
> function evaluations?
> 
> I would of course like to help - you could always point to filenames in 3.7/3.8
> and approximate line numbers so I can familiarize myself with the moving parts
> and begin to more fully wrap my head around what's going on and let my
> subconscious crunch on it.
> 

It's complicated and you've guessed a lot of it.

I think the biggest speed differences come from gpu/simd optimization. 
If you can break down a problem in a way which lets you feed those very 
wide compute units with huge chunks of the problem at a go, you speed 
things up by many multiples - even with simd which isn't that wide(1).

Exploiting gpus / simd units in a general way - which doesn't perch you 
at the top of a massive software stack - doesn't look easy to me(2).

Bill P.

(1) - I think even the massively parallel gpu cards are not too far off 
from running out of gas. You can only make parallel so much of the job. 
With the cpu core counts going ever higher - should we bother with a lot 
of gpu optimization?

(2) - I have looked at using GPUs with isosurfaces. A 5000 way min, no 
problem... Each time I take a peak at gpu code, it's just too much, ever 
changing, software infrastructure. I cannot find a way in that's easy 
enough and of general enough use.

[Bald Eagle] Re: RoundEdge 2.0: unequal edge radii [2165 days 14 hours and 54 minutes ago]

Sat, 2 May 2020 13:55:01 GMT

Given all of the isosurface stuff I [try to] do, and the functions that are
needed to do them, I really do have to say that it seems like something is
amiss.

I mean, I watch people code shaders, and then I follow along the best I can with
analogous POV-Ray code, and things quickly get SLOW - for a single render -
while they are still happily running at 30+ fps.

(and damn - RT vortices...   :O
https://www.shadertoy.com/view/MlS3Rh
https://www.win.tue.nl/~vanwijk/ibfv/ibfv.pdf
)

Is it a function evaluation issue?
Do vector functions make thing THAT much faster?
(they even use swizzling)
Is it a core isosurface code issue?
Can the pigment pattern - to - isosurface trick help to speed that up?
Is it that the shaders use GPU rather than cpu (ShaderToy runs in a browser...)
Does the shader stuff somehow get compiled beforehand?

I also have to bring up the parametric object speed again - I haven't yet dug
into the source for that, but it doesn't really make any sense why that should
be any slower than any of the rest of the object primitives, or at least THAT
much slower.
Maybe the reason for its drag can point to clues for speeding up ALL of the
function evaluations?

I would of course like to help - you could always point to filenames in 3.7/3.8
and approximate line numbers so I can familiarize myself with the moving parts
and begin to more fully wrap my head around what's going on and let my
subconscious crunch on it.

[William F Pokorny] Re: RoundEdge 2.0: unequal edge radii [2165 days 16 hours and 32 minutes ago]

Sat, 2 May 2020 12:17:27 GMT

On 4/30/20 12:21 PM, Cousin Ricky wrote:
...
> 
>> I've never gotten to where evaluate is part of my isosurface flow... 
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've 
>> also not stuck with using it. Am I'm missing bigger possible gains?
> 
> In my experience it helps with POV-Ray 3.6, but slows things down with 
> POV-Ray 3.7--for the same isosurface function!Â  I once had a mind to ask 
> the group about this anomaly, but I never got a round tuit (POVers 
> charge a premium for those!), and I cannot find my records of the timing 
> statistics.Â  I don't normally use it, but I believe Thomas de Groot uses 
> it a great deal.

Hmm, That stinks of a thread safety issue. Let me take a quick look at 
the code.

On a quick read I agree with comments left long ago from the core 
developers - evaluate is not thread safe... ;-)

Also sort of looks like the on the fly evaluate adjustments are sticky 
for the isosurface. Meaning they are not done on a ray by ray basis 
which itself is questionable except with really well behaved functions 
(no sharp edges / local high gradients).

All doesn't mean things won't kinda sorta work if you set the right 
limiting parameters. Isosurfaces are like that...

Will take a deeper look before 'boom,' but think this feature just made 
my povr nuke it list. There is considerable overhead for it even when 
not using it.

If someone wants to test how much performance we get in v37, v38 by 
using it, running with one thread best for accuracy. Unsure what to 
trust results wise. A box with sharpish edges - it might adjust the 
internal gradient downward to where the image at the sharp edges changes 
(sharper bits get missed). Who knows, maybe this would make for a 
smoother image on average, certainly would render faster.

If folks do turn up performance numbers, I am still interested.

Bill P.

[Thomas de Groot] Re: RoundEdge 2.0: unequal edge radii [2165 days 22 hours and 18 minutes ago]

Sat, 2 May 2020 06:31:12 GMT

Op 01/05/2020 om 18:44 schreef Cousin Ricky:
> On 2020-05-01 2:51 AM (-4), Thomas de Groot wrote:
>> Op 30/04/2020 om 18:21 schreef Cousin Ricky:
>>>
>>> In my experience it helps with POV-Ray 3.6, but slows things down 
>>> with POV-Ray 3.7--for the same isosurface function!Â  I once had a 
>>> mind to ask the group about this anomaly, but I never got a round 
>>> tuit (POVers charge a premium for those!), and I cannot find my 
>>> records of the timing statistics.Â  I don't normally use it, but I 
>>> believe Thomas de Groot uses it a great deal.
>>
>> I have not really used 'evaluate' in my isosurfaces. I have played 
>> with it of course but as far as I can remember, I did not find any 
>> significant use for it in my scenes. I browsed a couple of them and 
>> 'evalate' is never used.
> 
> Hmmmm.Â  Perhaps I'm mixing you up with one of the many POVers doing 
> Landscapes Of The Week many years ago.Â  The search continues for a 
> satisfied evaluate user...

Christoph Hormann perhaps?

-- 
Thomas

[Cousin Ricky] Re: RoundEdge 2.0: unequal edge radii [2166 days 12 hours and 4 minutes ago]

Fri, 1 May 2020 16:44:35 GMT

On 2020-05-01 2:51 AM (-4), Thomas de Groot wrote:
> Op 30/04/2020 om 18:21 schreef Cousin Ricky:
>>
>> In my experience it helps with POV-Ray 3.6, but slows things down with 
>> POV-Ray 3.7--for the same isosurface function!Â  I once had a mind to 
>> ask the group about this anomaly, but I never got a round tuit (POVers 
>> charge a premium for those!), and I cannot find my records of the 
>> timing statistics.Â  I don't normally use it, but I believe Thomas de 
>> Groot uses it a great deal.
> 
> I have not really used 'evaluate' in my isosurfaces. I have played with 
> it of course but as far as I can remember, I did not find any 
> significant use for it in my scenes. I browsed a couple of them and 
> 'evalate' is never used.

Hmmmm.  Perhaps I'm mixing you up with one of the many POVers doing 
Landscapes Of The Week many years ago.  The search continues for a 
satisfied evaluate user...

[Thomas de Groot] Re: RoundEdge 2.0: unequal edge radii [2166 days 21 hours and 58 minutes ago]

Fri, 1 May 2020 06:51:14 GMT

Op 30/04/2020 om 18:21 schreef Cousin Ricky:
> On 2020-04-30 7:23 AM (-4), William F Pokorny wrote:
>>
>> I've never gotten to where evaluate is part of my isosurface flow... 
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've 
>> also not stuck with using it. Am I'm missing bigger possible gains?
> 
> In my experience it helps with POV-Ray 3.6, but slows things down with 
> POV-Ray 3.7--for the same isosurface function!Â  I once had a mind to ask 
> the group about this anomaly, but I never got a round tuit (POVers 
> charge a premium for those!), and I cannot find my records of the timing 
> statistics.Â  I don't normally use it, but I believe Thomas de Groot uses 
> it a great deal.

I have not really used 'evaluate' in my isosurfaces. I have played with 
it of course but as far as I can remember, I did not find any 
significant use for it in my scenes. I browsed a couple of them and 
'evalate' is never used.

-- 
Thomas

[Cousin Ricky] Re: RoundEdge 2.0: unequal edge radii [2167 days 1 hour and 5 minutes ago]

Fri, 1 May 2020 03:44:05 GMT

On 2020-04-30 1:29 PM (-4), Bald Eagle wrote:
> 
> Is there a way to access and record the max_gradient that was found and write
> that to a file?

The Warning_Console option (+GW) should do it.  But beware that 3.7 
neglects to report the max_gradient under certain conditions.  See:

https://news.povray.org/povray.beta-test/thread/%3Cweb.51c722c522807ec9540235480%40news.povray.org%3E/

[Bald Eagle] Re: RoundEdge 2.0: unequal edge radii [2167 days 11 hours and 19 minutes ago]

Thu, 30 Apr 2020 17:30:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> In my experience it helps with POV-Ray 3.6, but slows things down with
> POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask
> the group about this anomaly, but I never got a round tuit (POVers
> charge a premium for those!), and I cannot find my records of the timing
> statistics.  I don't normally use it, but I believe Thomas de Groot uses
> it a great deal.

Hmmm.   I didn't know about the 3.6 to 3.7 issue.

I use it ... maybe 50% of the time?
Because I'm fantastically lazy with experimental / developmental code, and just
copy existing code from whatever file or open tab is closest at hand.

I have been meaning to get 'round to writing a nice concise isosurface code
block for my Insert Menu stuff, but I haven't gotten there yet.   Maybe by
2021...

If I can remember to do it, I can record times for with/without evaluate in the
future.

Maybe I'll just collect a bunch of functions into an array and see if I can
figure out how to record the render times automagically when I run them all as
an animation.

Is there a way to access and record the max_gradient that was found and write
that to a file?

[Cousin Ricky] Re: RoundEdge 2.0: unequal edge radii [2167 days 12 hours and 27 minutes ago]

Thu, 30 Apr 2020 16:21:42 GMT

On 2020-04-30 7:23 AM (-4), William F Pokorny wrote:
> 
> Thanks for the update.

You're welcome.

> I've never gotten to where evaluate is part of my isosurface flow... How 
> much does the evaluate feature typically buy you?
> 
> In my experiments 10-15% at most - and it's sometimes slower, but I've 
> also not stuck with using it. Am I'm missing bigger possible gains?

In my experience it helps with POV-Ray 3.6, but slows things down with 
POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask 
the group about this anomaly, but I never got a round tuit (POVers 
charge a premium for those!), and I cannot find my records of the timing 
statistics.  I don't normally use it, but I believe Thomas de Groot uses 
it a great deal.

[William F Pokorny] Re: RoundEdge 2.0: unequal edge radii [2167 days 17 hours and 26 minutes ago]

Thu, 30 Apr 2020 11:23:22 GMT

On 4/29/20 5:23 PM, Cousin Ricky wrote:
> RoundEdge 2.0 now has macros for rounded boxes with unequal edge radii. 
> As a bonus, a wrapper is added for POV-Ray's cryptic isosurface evaluate 
> feature.
> 

Thanks for the update.

I've never gotten to where evaluate is part of my isosurface flow... How 
much does the evaluate feature typically buy you?

In my experiments 10-15% at most - and it's sometimes slower, but I've 
also not stuck with using it. Am I'm missing bigger possible gains?

Suppose my issue with feature is I don't know what it really does beyond 
adjust the gradient on the fly within some bounding(1). The code is 
there, I could figure it out, but given I've never seen big gains...

Aside: v38's optional parameters are tempting additions to your evaluate 
wrapper. :-)

Bill P.

(1) - What happens inside that black box when I play games with ever 
changing (dis-continuous) - or even significantly flat gradients? Tricks 
workable if the roots are kept 'away' from the discontinuities (within 
continuous value regions/envelopes) - and the sampling periodicity is 
high enough over the whole isosurface with respect to rays such that the 
continuous value envelopes are not missed.

[Cousin Ricky] RoundEdge 2.0: unequal edge radii [2168 days 7 hours and 26 minutes ago]

Wed, 29 Apr 2020 21:23:17 GMT

RoundEdge 2.0 now has macros for rounded boxes with unequal edge radii. 
As a bonus, a wrapper is added for POV-Ray's cryptic isosurface evaluate 
feature.

In January of 2016, I posted an update to RoundEdge to correct a torus 
artifact.  More recently, while working on RoundEdge 2.0, I noticed that 
I had made the torus change in February 2015, and didn't post it until 
after clipka mentioned the artifact in December that year.  Why did I 
wait 350 days to post it?

I think it must have been that I was already working on the unequal edge 
radii when I made the torus correction, and planned to roll out the fix 
along with the new feature.  But the unequal edge radii turned out to 
have far more variations than I anticipated, so I put the whole update 
on the back burner--until clipka's comment induced me to rethink holding 
up the torus correction.  A massive toothache in early 2015 may have 
also been a factor in pausing development.

Well, it's 5 years later, and the new unequal edge macros are now 
completed and uploaded.

http://lib.povray.org/searchcollection/index2.php?objectName=RoundEdge&contributorTag=Cousin%20Ricky

An isosurface elliptical toroid is still on my wish list.  Although I've 
already implemented mesh toroids, they cannot be deformed or blobbed. 
Back in 2008, Nicolas George proposed a function which, upon 
implementation, I found unsatisfactory.  (He projected lines from the 
origin through the central ellipse, which I had previously determined to 
be a bad approach.)  In 2006, Sebastian H. posted a function that 
appears to create the exact shape I desire, but I have been unable to 
verify that the gradients are stable.  Stable gradients would be 
essential for isosurface blobbing.

[ingo] public domain 3D models from musea [2230 days 15 hours and 34 minutes ago]

Thu, 27 Feb 2020 13:15:16 GMT

public domain 3D models from musea:

https://sketchfab.com/blogs/community/sketchfab-launches-public-domain-
dedication-for-3d-cultural-heritage/

[Bald Eagle] Re: The Bright Star Catalogue [2232 days 5 hours and 4 minutes ago]

Tue, 25 Feb 2020 23:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> I just punted in despair, figuring each project might require a somewhat
> specialized solution, but I didn't notice the new thread activity until now.

Well, I think that something like the sunpos include file is mostly what I'm
looking for.

Given a longitude and latitude, a date, and an hour of the day, create a
celestial sphere.  Make it so that no matter what, each star is at least 1 pixel
wide.

I'm primarily interested in the geometry - the proper alignment.

"Look - that notch in that rock at Stonehenge really DOES line up with Rigel at
midnight on the winter solstice..."

------------------------

Aside from that, you could add some sort of mechanism that allows the _USER_ to
tweak the catalogue.

So - whatever array you use to do the basic stuff, and then maybe a user array
that modifies the values or sets some flags before rendering.

That way someone could highlight a star with an object{} (torus, [under]line,
arrow, etc), put a text label, change the apparent size, replace the simple
sphere for the star with a fancy object{}, or apply a multiplier to the star's
brightness/color.

I'd probably start with like 10 stars or a few constellations, and give it a
whirl, and then get some user feedback before doing anything bigger.

[Cousin Ricky] Re: The Bright Star Catalogue [2232 days 8 hours and 31 minutes ago]

Tue, 25 Feb 2020 20:18:11 GMT

On 2020-01-14 9:20 PM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> A sky sphere would use a different formula, but the math would be similar.
> 
> Has anyone to date used the catalogue to generate a fairly realistic spherical
> sky shell or a flat image useful for uv-mapping a sphere?
> 
> I'd like to be able to incorporate this into the solar system scene I've worked
> on, if I get the time to focus on it, and I have another project where I'd like
> to be able to look up from a given position on earth at a certain angle at a
> given date and time and see a reasonably accurate view.

I had been thinking about this around the beginning of the year, but the 
more I pondered, the more complications there seemed to consider.  How 
bright?  How to deal with dynamic range?  What resolution?  In general, 
how would I make one tool that would apply across various scales and 
lighting conditions?  (Similar considerations are why I haven't put 
beverage materials in the CoffeeMug include file.)

I just punted in despair, figuring each project might require a somewhat 
specialized solution, but I didn't notice the new thread activity until now.

[Melody] Re: The Bright Star Catalogue [2272 days and 24 minutes ago]

Fri, 17 Jan 2020 04:25:00 GMT

I see that Flam_Bayer.inc is not in 3D. That's used in java script, which can
generate a library view in a split sec, it doesn't have to use trig.
Could be quickly rewritten to any format you want.

ra dec is simple, just get the right order.
#local v = <cos(radians(ra))*cos(radians(dec)),
sin(radians(dec)),
sin(radians(ra))*cos(radians(dec))>;

dec * -1

if you want to y+ down output

[Melody] Re: The Bright Star Catalogue [2272 days 1 hour and 14 minutes ago]

Fri, 17 Jan 2020 03:35:00 GMT

One thing you can't do without is the ability to easily sort and rewrite text
files to your needs. One of those "vitamins" that give u a boost to what you can
get done, why there is something like Poseray. Got data and can't use it? No
problem. Even without Poseray, you'd do it DIY.

[Melody] Re: The Bright Star Catalogue [2272 days 1 hour and 24 minutes ago]

Fri, 17 Jan 2020 03:25:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Melody" <nomail@nomail> wrote:
> > POV
> > http://trueinnerbeing.x10host.com/planetarium45.zip
>
> Yes, that worked.
>
>
> I will fiddle with it as time allows.
> Very nice little site you have.   Lots of very interesting information.
> I need whatever vitamins you take   :D
lol

Don't know if the last one posted. Version 3.63 or Mega POV for date.
That will not run. thought you just wanted the data. to run that you need maps.

 http://trueinnerbeing.x10host.com/maps1.zip
but that link is not working yet. is there another place?
10 meg for the maps

3 sub dirs
clouds
maps
sats

[Bald Eagle] Re: The Bright Star Catalogue [2272 days 3 hours and 4 minutes ago]

Fri, 17 Jan 2020 01:45:00 GMT

"Melody" <nomail@nomail> wrote:
> POV
> http://trueinnerbeing.x10host.com/planetarium45.zip

Yes, that worked.

When trying to run pld.pov, I get:

Parse Error: Cannot pass uninitialized identifier to non-optional LValue.
at File: megatime.inc Line: 80 Col: 17

/////////////////////////////////////////////////////////////// AutoDate
MegaPov
//#version unofficial MegaPov 1.21;
#version 3.63;

#declare Time = date("%H:%M:%S")
#declare Date = date("%B %d %Y")
////////////////////////////////////////////////////////////// TimeZone
#declare DST = 1;
#declare GMT = 0;
#declare TimeZone = -6 + DST;
#declare JulianDate = julian(val(date("%Y")),val(date("%m")),val(date("%d")));
#declare ctime = j2ctime(JulianDate);

j2datetime(JulianDate)


presumably that needs to be updated to use datetime()
http://wiki.povray.org/content/Reference:Numeric_Expressions
#local CurrentTime = datetime(now); // current date and time as a string


I will fiddle with it as time allows.
Very nice little site you have.   Lots of very interesting information.
I need whatever vitamins you take   :D

[Melody] Re: The Bright Star Catalogue [2272 days 4 hours and 14 minutes ago]

Fri, 17 Jan 2020 00:35:01 GMT

"Melody" <nomail@nomail> wrote:
> POV
> http://trueinnerbeing.x10host.com/planetarium45.zip

here's the fleet,

http://news.povray.org/povray.binaries.images/attachment/%3Cweb.485747fce7b65d90d361a0c10%40news.povray.org%3E/fleet05.
png

using the glow function for the stars, (too much glow)
and type for the color.

so you want to go star trek, then, I got many models.

[Melody] Re: The Bright Star Catalogue [2272 days 4 hours and 39 minutes ago]

Fri, 17 Jan 2020 00:10:01 GMT

POV
http://trueinnerbeing.x10host.com/planetarium45.zip

JS
http://trueinnerbeing.x10host.com/jtarium232full-opac.zip

maybe those?

well I should have checked the links, server is being finicky.
I can ftp /charts/ links, browser says not there.

[Melody] Re: The Bright Star Catalogue [2272 days 5 hours and 14 minutes ago]

Thu, 16 Jan 2020 23:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Melody" <nomail@nomail> wrote:
>
> > I already made a bright star catalog converted to pov, in 3D points, if anyone
> > is interested.
>
> Yes, that would be a very useful thing, indeed.
> Are there comments of any sort to assist in highlighting the various
> constellations, or is it just bare-bones at the moment?
>
> I still have to wrap my head around the ephemerides and the orbital elements to
> be able to position everything where it needs to be at the proper times...

Constellation boundaries points is another set of points.
Got it all in 3 languages.

POV
http://trueinnerbeing.x10host.com/charts/planetarium45.zip

JS
http://trueinnerbeing.x10host.com/charts/jtarium232full-opac.zip
http://trueinnerbeing.x10host.com/charts/jtarium.html
(ctrl-F8 titles are links to APOD)

OpenGL
http://trueinnerbeing.x10host.com/code/gamemode.zip
http://trueinnerbeing.x10host.com/code/code.html

all to grok really, is that camera matrix is "inverted"
and you just pipe everything thru the world matrix.

[Bald Eagle] Re: The Bright Star Catalogue [2272 days 9 hours and 44 minutes ago]

Thu, 16 Jan 2020 19:05:00 GMT

"Melody" <nomail@nomail> wrote:

> I already made a bright star catalog converted to pov, in 3D points, if anyone
> is interested.

Yes, that would be a very useful thing, indeed.
Are there comments of any sort to assist in highlighting the various
constellations, or is it just bare-bones at the moment?

I still have to wrap my head around the ephemerides and the orbital elements to
be able to position everything where it needs to be at the proper times...

[Melody] Re: The Bright Star Catalogue [2272 days 19 hours and 4 minutes ago]

Thu, 16 Jan 2020 09:45:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted ...

Hum when it comes time to generate a view if this library,
if your library is in 3D points, not ra dec, you'll save thousands of trig
functions, and the time.

seta(1,146180222.862047,-139516389.855953,-37392435.96208,5.1);
seta(2,65647206.128445,-80763375.119065,-16312013.815614,4.7);
seta(3,135031719.98319,-145513040.060053,-31389042.949954,5.3);

times 10,000,000 = miles, and there's your distance.

I already made a bright star catalog converted to pov, in 3D points, if anyone
is interested.

[Dick Balaska] Re: The Bright Star Catalogue [2274 days 2 hours and 10 minutes ago]

Wed, 15 Jan 2020 02:39:23 GMT

Am 1/14/20 8:38 PM, also sprach Bald Eagle:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
> 
> Does anyone here know [how to contact] this chap?
> https://www.youtube.com/watch?v=bvpEWuxBBRw
> 
How many Geoff Dallimore(s) can there be?  Google thinks you want the
UK patent attorney, who looks like the guy in the thumbnail on youtube.

If you comment on the video, I'm pretty sure he'll get an email.  Or you 
can try his contact form: http://xpatent.co.uk/contact/

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Bald Eagle] Re: The Bright Star Catalogue [2274 days 3 hours and 9 minutes ago]

Wed, 15 Jan 2020 01:40:00 GMT

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

> Has anyone to date used the catalogue to generate a fairly realistic spherical
> sky shell or a flat image useful for uv-mapping a sphere?

Does anyone here know [how to contact] this chap?
https://www.youtube.com/watch?v=bvpEWuxBBRw

[Bald Eagle] Re: The Bright Star Catalogue [2274 days 3 hours and 24 minutes ago]

Wed, 15 Jan 2020 01:25:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> A sky sphere would use a different formula, but the math would be similar.

Has anyone to date used the catalogue to generate a fairly realistic spherical
sky shell or a flat image useful for uv-mapping a sphere?

I'd like to be able to incorporate this into the solar system scene I've worked
on, if I get the time to focus on it, and I have another project where I'd like
to be able to look up from a given position on earth at a certain angle at a
given date and time and see a reasonably accurate view.

[Dick Balaska] next button [2281 days 23 hours and 41 minutes ago]

Tue, 7 Jan 2020 05:08:26 GMT

I have fixed the next button (yay).

I want to change the main page to mention that the "Thumbnails" button 
is an excellent alternate interface to the database, but I'm not sure 
how to express that.

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Cousin Ricky] Re: FranciscoMunoz and Unix [2377 days 4 hours and 49 minutes ago]

Fri, 4 Oct 2019 00:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> In addition, FMunoz_DeskItems.inc refers to the Microsoft font file
> Arial.ttf.  On my system, that font name is all lowercase, so I modified
> my copy of FMunoz_DeskItems.inc accordingly.  YMMV.

Clarification: Microsoft does not own Arial; it licenses it from Monotype
Imaging.

[Cousin Ricky] RC3Metal 1.3: a new galvanized macro, and photon... [2396 days 6 hours and 17 minutes ago]

Sat, 14 Sep 2019 22:31:54 GMT

RC3Metal 1.3 is updated with a galvanized texture macro that takes a 
turbulence argument.  Also, "Galvanised" may now be spelled with an 's'.

One of the optimizations in RC3Metal 1.2.1 caused photons to fail on 
objects with blurred reflection.  This bug has been corrected.

Other changes include;
  - RC3Metal 1.3 detects POV-Ray 3.8 and sets the default ambient
    parameter accordingly.
  - The message to the debug stream stating that rc3metal.inc is
    included is suppressed by default.
  - The RC3M_Albedo parameter now controls only diffuse albedo; whether
    to use specular albedo is now controlled solely by the POV-Ray
    version.  There is no functional difference, as RC3Metal has always
    calculated a fake specular albedo when the albedo keyword was not
    specified.

To Le Forgeron: I also posted a minor update to CoffeeMug in mid April.

[Cousin Ricky] Re: View_POV_Include_Stack? [2558 days 12 hours and 6 minutes ago]

Fri, 5 Apr 2019 16:43:25 GMT

On 2019-04-05 11:42 AM (-4), Le_Forgeron wrote:
> Le 05/04/2019 Ã  03:58, Cousin Ricky a Ã©critÂ :
>>
>> But wouldn't you know it, I just discovered brand new errors in 6 of the
>> user manuals.Â  If I upload the corrected manuals to p.b.misc, can you do
>> me the favor of copying them to the Object Collection server?
> 
> You mean updating/replacing the file in your last upload ?
> Probably yes.

They are now posted in povray.binaries.misc.  TIA.

[Le Forgeron] Re: View_POV_Include_Stack? [2558 days 13 hours and 6 minutes ago]

Fri, 5 Apr 2019 15:42:42 GMT

Le 05/04/2019 Ã  03:58, Cousin Ricky a Ã©critÂ :
> On 2019-03-21 3:30 PM (-4), Le_Forgeron wrote:
>> 2. when done, please drop a little message (here), and I will resync the
>> collection with the repository.
> 
> I have updated these 8 modules:
> 
> Â  AndroidRobot 4.0.1
> Â  BeamTest 1.2.1
> Â  BrightStar5 1.1.1
> Â  Caption 1.1.1
> Â  IntegrateLight 1.0.1
> Â  lrchairs 1.1.1
> Â  Spectrum 4.0.1
> Â  TiltedTorus 3.0.1
> 
> Most of these have only the suppression of the include message and minor
> tweaks, but BrightStar5 has a bug fix and IntegrateLight has some
> corrections to the user manual.
> 
> But wouldn't you know it, I just discovered brand new errors in 6 of the
> user manuals.Â  If I upload the corrected manuals to p.b.misc, can you do
> me the favor of copying them to the Object Collection server?

You mean updating/replacing the file in your last upload ?
Probably yes.

[Cousin Ricky] Re: View_POV_Include_Stack? [2559 days 2 hours and 51 minutes ago]

Fri, 5 Apr 2019 01:58:08 GMT

On 2019-03-21 3:30 PM (-4), Le_Forgeron wrote:
> 2. when done, please drop a little message (here), and I will resync the
> collection with the repository.

I have updated these 8 modules:

   AndroidRobot 4.0.1
   BeamTest 1.2.1
   BrightStar5 1.1.1
   Caption 1.1.1
   IntegrateLight 1.0.1
   lrchairs 1.1.1
   Spectrum 4.0.1
   TiltedTorus 3.0.1

Most of these have only the suppression of the include message and minor 
tweaks, but BrightStar5 has a bug fix and IntegrateLight has some 
corrections to the user manual.

But wouldn't you know it, I just discovered brand new errors in 6 of the 
user manuals.  If I upload the corrected manuals to p.b.misc, can you do 
me the favor of copying them to the Object Collection server?

[Cousin Ricky] Re: View_POV_Include_Stack? [2571 days 13 hours and 47 minutes ago]

Sat, 23 Mar 2019 15:02:07 GMT

On 2019-03-21 3:30 PM, Le_Forgeron wrote:
> 
> copying practice from official include files seems a good karma.

... Unless it's setting high ambients on metals.

[Thorsten Froehlich] Re: Secure login? [2571 days 23 hours and 19 minutes ago]

Sat, 23 Mar 2019 05:30:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> Can lib.povray.org be converted to HTTPS, or do we need Chris Bartlett
> for that as well?  Asking for my browser.

A secure login, just like expecting encryption for all websites is pointless. It
is just a publicity stunt by huge US data collectors like Google to give them
exclusive control over your data and keeping others out. Ignore it, you gain
nothing by encryption.

Thorsten

[Cousin Ricky] Secure login? [2572 days 7 hours and 42 minutes ago]

Fri, 22 Mar 2019 21:07:15 GMT

Can lib.povray.org be converted to HTTPS, or do we need Chris Bartlett 
for that as well?  Asking for my browser.

[Le Forgeron] Re: View_POV_Include_Stack? [2573 days 9 hours and 18 minutes ago]

Thu, 21 Mar 2019 19:30:36 GMT

Le 21/03/2019 Ã  19:54, Cousin Ricky a Ã©critÂ :
> In my contributions, it has been my practice to write an "#include" line
> automatically to the debug stream.Â  While I haven't gotten any feedback
> over this practice, it is starting to annoy me, the author!Â  The
> messages just add clutter to my #debug output.
> 
> Going forward, I plan to use View_POV_Include_Stack such that these
> notices are suppressed by default, as is done with the standard include
> files.Â  Several Object Collection modules already do this.Â 
(As this
> identifier is defined in a standard include file and referenced by most,
> I would not consider the lack of a prefix to be a violation of the
> naming standards; and in fact, using the prefix would complicate matters
> for a user taking advantage of this practice.)
> 
> So my question to myself is, is it worth updating all 13 of my modules
> in one shot, or should I just make this change to each module as I
> update them over time?Â  Some of my modules I have no further plans for,
> so this would be the only change, aside from some possible minor tweaks.
> 
> Does anyone care?

Yes, I do.

1. do as you want.
2. when done, please drop a little message (here), and I will resync the
collection with the repository.

copying practice from official include files seems a good karma.

I have to confess I barely care about the stack of includes.

[Cousin Ricky] View_POV_Include_Stack? [2573 days 9 hours and 54 minutes ago]

Thu, 21 Mar 2019 18:54:59 GMT

In my contributions, it has been my practice to write an "#include" line 
automatically to the debug stream.  While I haven't gotten any feedback 
over this practice, it is starting to annoy me, the author!  The 
messages just add clutter to my #debug output.

Going forward, I plan to use View_POV_Include_Stack such that these 
notices are suppressed by default, as is done with the standard include 
files.  Several Object Collection modules already do this.  (As this 
identifier is defined in a standard include file and referenced by most, 
I would not consider the lack of a prefix to be a violation of the 
naming standards; and in fact, using the prefix would complicate matters 
for a user taking advantage of this practice.)

So my question to myself is, is it worth updating all 13 of my modules 
in one shot, or should I just make this change to each module as I 
update them over time?  Some of my modules I have no further plans for, 
so this would be the only change, aside from some possible minor tweaks.

Does anyone care?

[Mike Horvath] Re: Vector images [2581 days 22 hours and 41 minutes ago]

Wed, 13 Mar 2019 06:07:59 GMT

On 3/9/2019 9:35 AM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I created some vector images that I (after converting them to PNG) used
>> for axis, label, measurement, etc. graphics. I want to keep them with my
>> collection, but I don't think I am allowed to upload them. Would it be
>> possible to make an exception for a vector format of some type? I use
>> SVG, but I understand that can be a risk since it is possible to insert
>> JavaScript into it. Maybe a different format would be better? Thanks.
>>
>>
>> Mike
> 
> How large are the SVG files?
> Aren't they all just a text-based format like HTML?
> 
> You could rename them to .txt and likely post them.
> 
> Alternatively, you can embed them into the header of a jpg file of the same
> image.   Then I think you can just rename it to .svg and it's instantly useable
> as one.
> 
> 


They are not very large at all. Renaming the extension is a good idea. I 
will try that.


Mike

[Bald Eagle] Re: Vector images [2585 days 14 hours and 9 minutes ago]

Sat, 9 Mar 2019 14:40:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I created some vector images that I (after converting them to PNG) used
> for axis, label, measurement, etc. graphics. I want to keep them with my
> collection, but I don't think I am allowed to upload them. Would it be
> possible to make an exception for a vector format of some type? I use
> SVG, but I understand that can be a risk since it is possible to insert
> JavaScript into it. Maybe a different format would be better? Thanks.
>
>
> Mike

How large are the SVG files?
Aren't they all just a text-based format like HTML?

You could rename them to .txt and likely post them.

Alternatively, you can embed them into the header of a jpg file of the same
image.   Then I think you can just rename it to .svg and it's instantly useable
as one.

[Cousin Ricky] Re: Vector images [2589 days and 37 minutes ago]

Wed, 6 Mar 2019 04:11:50 GMT

On 2019-03-03 12:00 PM (-4), Mike Horvath wrote:
> On 3/2/2019 2:42 PM, Cousin Ricky wrote:
>> Chris Bartlett
> 
> Does he own the server the collection is residing on?

I do not know.  I doubt it, though; it would be highly unusual for a 
server to be running this long with no sign of its owner.  At the very 
least, bills must be paid and/or collected.

[Mike Horvath] Re: Vector images [2591 days 12 hours and 49 minutes ago]

Sun, 3 Mar 2019 16:00:05 GMT

On 3/2/2019 2:42 PM, Cousin Ricky wrote:
> Chris Bartlett

Does he own the server the collection is residing on?


Mike

[Cousin Ricky] Re: Vector images [2592 days 9 hours and 7 minutes ago]

Sat, 2 Mar 2019 19:42:26 GMT

On 2019-02-28 1:10 PM (-4), Mike Horvath wrote:
> I created some vector images that I (after converting them to PNG) used 
> for axis, label, measurement, etc. graphics. I want to keep them with my 
> collection, but I don't think I am allowed to upload them. Would it be 
> possible to make an exception for a vector format of some type? I use 
> SVG, but I understand that can be a risk since it is possible to insert 
> JavaScript into it. Maybe a different format would be better? Thanks.

The JavaScript risk is probably not a big issue, since JavaScript can 
also be inserted into HTML documents.  The biggest problem with the 
Collection right now is access to the server; the Collection 
administrator (Chris Bartlett) has not been heard from in almost 10 
years.  Le Forgeron has some level of access, but there's only so much 
he's permitted to do.

[Mike Horvath] Vector images [2594 days 11 hours and 39 minutes ago]

Thu, 28 Feb 2019 17:10:12 GMT

I created some vector images that I (after converting them to PNG) used 
for axis, label, measurement, etc. graphics. I want to keep them with my 
collection, but I don't think I am allowed to upload them. Would it be 
possible to make an exception for a vector format of some type? I use 
SVG, but I understand that can be a risk since it is possible to insert 
JavaScript into it. Maybe a different format would be better? Thanks.


Mike

[Mike Horvath] Re: Ping SharkD: legal question about the Munsel... [2597 days 18 hours and 21 minutes ago]

Mon, 25 Feb 2019 10:27:58 GMT

On 12/19/2014 12:20 PM, Cousin Ricky wrote:
> First of all, the Web page URL has changed:
> 
>  Â  http://www.rit.edu/cos/colorscience/rc_munsell_renotation.php
> 
> But my main concern is RIT's terms of use.Â  According to these terms, 
> the contents of the Web site are for personal, noncommercial use only. 
> IANAL, but to me, these terms don't appear to be compatible with the 
> LGPL.Â  Do you have some assurance (preferably written) that the Munsell 
> data are not covered by these restrictions, or have you otherwise 
> contacted RIT about their use?

I updated the module.

Anyway, I asked at Wikipedia (where I have uploaded the image) about the 
licensing issue, and they said you can't copyright factual/experimental 
data. You can copyright the words describing the data, but not the data 
itself. Or something like that.

Mike

[Cousin Ricky] AndroidRobot 4.0: a new official color [2752 days 12 hours and 7 minutes ago]

Sun, 23 Sep 2018 16:42:27 GMT

Google has changed the official Android[TM] color.  AndroidRobot 4.0 is 
updated with the new color.

There is another change that won't affect renders, but can save typing. 
When Karl Ostmo uploaded version 1.0 of this module, he included a file 
droid.pov.  Since he had marked the module as non-compliant, I thought 
nothing of it; but earlier this year I discovered that "droid" was 
registered as the short prefix, presumably by Karl, as I have no memory 
of doing so.

Then the other day, while searching my files for URLs to be upgraded to 
HTTPS, I discovered the color change.  Upgrading AndroidRobot with the 
new color gave me the excuse to reinstate the short prefix, as well as 
update the User Manual to clarify a licensing issue specific to this module.

http://lib.povray.org/searchcollection/index2.php?objectName=AndroidRobot&contributorTag=Cousin%20Ricky

Caveat:  The standard Object Collection README file says that you may 
use images that you generate using these files without restriction.  As 
the Android robot is trademarked, this is obviously not true for this 
particular module.  Please see the User Manual for more information.

[Mike Horvath] Re: SolarSystemOrrery [2758 days 2 hours and 41 minutes ago]

Tue, 18 Sep 2018 02:08:06 GMT

I just realized I have a copy of "fbruder_kepler.inc" which does all I 
wanted, plus more. Sigh.

:|


Mike

[clipka] Re: SolarSystemOrrery [2759 days 4 hours and 20 minutes ago]

Mon, 17 Sep 2018 00:29:23 GMT

Am 17.09.2018 um 01:38 schrieb Kenneth:

> What I find strange about Ceres is its orbital period around the Sun-- 4,999
> years. The table of orbital periods given there shows that all the planets (and
> Pluto) naturally orbit slower the farther away they are from the Sun--

Yes, of course; that's inevitable.

> with
> Ceres being *by far* the slowest; but it's Sun-distance is *closer* than either
> Pluto or Jupiter. It should be rotating faster than Jupiter, but isn't.

Is it not?

The table linked to specifies 11.8 yrs for Jupiter, as compared to 4.599
for Ceres. That makes it faster (in terms of angular speed) than Jupiter.


(It's also faster in terms of km/s; again, inevitable.)

[Kenneth] Re: SolarSystemOrrery [2759 days 4 hours and 49 minutes ago]

Mon, 17 Sep 2018 00:00:00 GMT

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

>
> Oops-- that's 4.99 years (off by only 10 to the third power!!) My eyes played
> tricks on me.
>
> But's that's still quite strange, given its relative distance from the sun.

Hmm, not so strange after all. It's faster than Jupiter, which makes sense.

Never mind.  ;-)

[Kenneth] Re: SolarSystemOrrery [2759 days 4 hours and 59 minutes ago]

Sun, 16 Sep 2018 23:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > https://www.windows2universe.org/our_solar_system/planets_orbits_table.html
>
> What I find strange about Ceres is its orbital period around the Sun-- 4,999
> years.

Oops-- that's 4.99 years (off by only 10 to the third power!!) My eyes played
tricks on me.

But's that's still quite strange, given its relative distance from the sun.

[Kenneth] Re: SolarSystemOrrery [2759 days 5 hours and 9 minutes ago]

Sun, 16 Sep 2018 23:40:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>
> https://www.windows2universe.org/our_solar_system/planets_orbits_table.html

What I find strange about Ceres is its orbital period around the Sun-- 4,999
years. The table of orbital periods given there shows that all the planets (and
Pluto) naturally orbit slower the farther away they are from the Sun-- with
Ceres being *by far* the slowest; but it's Sun-distance is *closer* than either
Pluto or Jupiter. It should be rotating faster than Jupiter, but isn't. Maybe
it's caught in some kind of gravitational tug-of-war with Jupiter and the Sun?
Interesting!

[Mike Horvath] Re: SolarSystemOrrery [2759 days 8 hours and 56 minutes ago]

Sun, 16 Sep 2018 19:52:45 GMT

On 9/15/2018 11:20 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I would like to
>> add Pluto and Ceres as well, but I could not find all the necessary data
>> for them.
>>
>>
>> Mike
> 
> https://lite.qwant.com/?q=ceres+orbital+data
> 
> https://www.windows2universe.org/our_solar_system/planets_orbits_table.html
> 
> 


I will take a look at those, thanks. As soon as I can find the bugs in 
my code that is. :(

Mike

[Bald Eagle] Re: SolarSystemOrrery [2760 days 1 hour and 24 minutes ago]

Sun, 16 Sep 2018 03:25:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I would like to
> add Pluto and Ceres as well, but I could not find all the necessary data
> for them.
>
>
> Mike

https://lite.qwant.com/?q=ceres+orbital+data

https://www.windows2universe.org/our_solar_system/planets_orbits_table.html

[Bald Eagle] Re: SolarSystemOrrery [2760 days 1 hour and 29 minutes ago]

Sun, 16 Sep 2018 03:20:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

>  > I would like to
> > add Pluto and Ceres as well, but I could not find all the necessary data
> > for them.
>
> What?  This is size-ism!

Size matters.




The data I have for Pluto is

// Pluto discovered by Clyde Tombaugh February 18, 1930
#declare PlutoRad = 1189.9*KM*I;    // (ER*0.18)*Miles*I; // Pluto Radius [1150
KM]
#declare PlutoRot = -360*(OC/6.387230);   // Pluto Rotation: -360 deg every 6.38
days [retrograde rotation] [-6.39]
#declare PlutoTilt = 122.53;     // Pluto tilt to orbital plane
#declare PlutoDist = SunRad+(5913520000*KM)*Scale; //SunRad+(EarthDist*39.44);
// Pluto distance from Sun
#declare PlutoSemiMaj = 5906.38*GM*Scale;  // [1] Pluto semimajor Axis
#declare PlutoEpoch = J2000;     // [2] Pluto Epoch
#declare PlutoRev = 360*(Clock/248.00);   // Pluto Revolution: 360 deg every
248.00 years (90560 days)(orbital period)
#declare PlutoIncl = 17.16;     // [4] Pluto orbital inclination to Earth
orbital plane
#declare PlutoEccen = 0.2488;     // [3] Pluto orbital Eccentricity
#declare PlutoArgPeri = 113.834;    // [5] Pluto Argument of Perihelion
#declare PlutoLongAsc = 110.299;    // [6] Pluto Longitude of Ascending Node
#declare PlutoPrecA = 0;      // Pluto Axial precession ?
#declare PlutoPrecO = 0;      // Pluto Orbital precession ?
#declare PlutoMat = material {texture {pigment {Gray90} normal {bumps scale
0.00001} finish {diffuse  0.55}}}
// 5 satellites


I have nothing (yet) for Ceres.
(But I'm only 1300 lines of code into it...)

[Cousin Ricky] Re: SolarSystemOrrery [2760 days 3 hours and 13 minutes ago]

Sun, 16 Sep 2018 01:35:53 GMT

On 2018-09-15 05:23 AM (-4), Mike Horvath wrote:
> I added a new item to the Object Collection.
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=SolarSystemOrrery&version=1.0&contributorTag=SharkD
>
>
> A model of the solar system. Includes all eight planets. Can be animated
> by setting the Orrery_StopDate parameter to the clock.

Neat!

 > I would like to
> add Pluto and Ceres as well, but I could not find all the necessary data
> for them.

What?  This is size-ism!

[Mike Horvath] SolarSystemOrrery [2760 days 19 hours and 26 minutes ago]

Sat, 15 Sep 2018 09:23:25 GMT

I added a new item to the Object Collection.

http://lib.povray.org/searchcollection/index2.php?objectName=SolarSystemOrrery&version=1.0&contributorTag=SharkD

A model of the solar system. Includes all eight planets. Can be animated 
by setting the Orrery_StopDate parameter to the clock. I would like to 
add Pluto and Ceres as well, but I could not find all the necessary data 
for them.


Mike

[Jaime Vives Piqueres] Re: Lightsys, broken links, and user manual upda... [2771 days 20 hours and 1 minute ago]

Tue, 4 Sep 2018 08:48:04 GMT

El 31/08/18 a las 03:26, Cousin Ricky escribiÃ³:
> I just discovered that Jaime has reorganized his website.Â  This is all 
> well and good, except that I have 5 Object Collection modules whose user 
> manuals link to Lightsys IV, and now those links are broken. 

   Oops... I'm sorry: I forgot to put there some redirections for the 
old URLs: I will do it next weekend, so you don't have to update the links.

   Regards,

--
jaime

[Cousin Ricky] Lightsys, broken links, and user manual updates [2776 days 3 hours and 24 minutes ago]

Fri, 31 Aug 2018 01:24:50 GMT

I just discovered that Jaime has reorganized his website.  This is all 
well and good, except that I have 5 Object Collection modules whose user 
manuals link to Lightsys IV, and now those links are broken.  For two of 
those modules, Lightsys is a prerequisite.

   BeamTest (optional)
   BrightStar5 (acknowledgment)
   IntegrateLight (prerequisite)
   RC3Metal (recommendation)
   Spectrum (prerequisite)

For those who have downloaded these modules since mid-May and been 
unable to download Lightsys, the new URL is:
   http://www.ignorancia.org/index.php/technical/lightsys/

I'm trying to decide whether I should re-upload these modules with 
updated user manuals, even if I don't have any changes for the include 
files.  The IntegrateLight user manual makes an incorrect assumption 
about Lightsys anyway, so that needs to be corrected as well.  (I would 
like to add line spectrum capability to IntegrateLight, but I do not 
sufficiently understand how Lightsys deals with line spectra, so that 
will have to wait.)

It has also been bothering me that the AndroidRobot user manual may not 
be sufficiently clear about the Google license vis-a-vis the README 
file; I do not wish to be perceived as crossing The Google.  Perhaps 
that's excuse enough to go tweak the module itself?

[Mike Horvath] Re: CC-LGPL [2796 days 2 hours and 52 minutes ago]

Sat, 11 Aug 2018 01:56:41 GMT

On 8/10/2018 7:58 PM, Cousin Ricky wrote:
>> Whatever, it would need the direct action of Chris Bartlett to change
>> the license, as my power does not extend to changing the impacted files.
>> (the license is in the README.html within the created zip file, that one
>> I can change, but for the website it is in another page(s) to which I
>> have no writing access)
> 
> Unfortunately, Chris has not been heard from since ca. late 2009.Â  Which 
> is a problem if he is the only one on the planet who can modify the 
> administrative files.Â  Last I heard, Chris Cason was trying to contact 
> him, but that was many, many years ago.
> 

Who is in charge of the web-based newsgroup interface? That thing is 
almost impossible to read on my phone.

And my smartphone newsgroup app does not support binary groups/messages.


Mike

[Cousin Ricky] Re: CC-LGPL [2796 days 4 hours and 40 minutes ago]

Sat, 11 Aug 2018 00:08:54 GMT

On 2018-08-06 01:50 PM (-4), Mike Horvath wrote:
> On 8/6/2018 12:08 PM, Le_Forgeron wrote:
>> As far as I know, the link is correct.
>>
>
> The link is to http://creativecommons.org/licenses/LGPL/2.1/
> which gets redirected to https://www.gnu.org/licenses/lgpl-2.1.html
>
> We could update the link to avoid the redirect.
>
> I think "CC-LGPL" is no longer a thing. It should just be "LGPL".

It seems to me that GNU was just piggybacking on Creative Commons for 
this.  I don't think it makes any difference.  However, note that the 
logo file has a "CC" on it, so we would have to obtain a new graphic for 
the server.

[Cousin Ricky] Re: CC-LGPL [2796 days 4 hours and 52 minutes ago]

Fri, 10 Aug 2018 23:57:28 GMT

On 2018-08-06 12:08 PM (-4), Le_Forgeron wrote:
> Le 06/08/2018 Ã  09:25, Mike Horvath a Ã©crit :
>
>> 2. Is there a reason we use LGPL version 2.1 instead of 3? Does the
>> object collection predate version 3? Do we want to switch to version 3?
>
> Oh yes, it predates LGPL v3.0 (29 June 2007)
> LGPL v2.1 is from August 2005
> and the site was designed at least before the 22 December 2006, even if
> there is trace of getting documented in late September 2007.
> (2006 is the date of the CC-LGPL logo for this site)
>
> I have found pictures as old as 14 Aug 2005 (in staircase by chrisb 2.0)
>
> The real life of the website seems to be the 28 September 2007.

There are 7 modules with this date stamp (all by chrisb), and none earlier.

StairCase was uploaded 2008 March 26.  Looking at my hard disk, it seems 
that there are some files in these early modules that are stamped 
earlier than the upload date.  This does not happen nowadays; they all 
have the upload time as the OS date stamp.  (And for me, for some 
reason, my time zone is disregarded; so if I upload a module at 9 p.m., 
the downloaded files are stamped with 1 a.m. the next day!)

The cc-LGPL-a.png file is stamped 2006 December 22.

(Note that I am referring to the OS date stamp in all cases, which may 
be later than the date recorded in the image metadata.)

> Whatever, it would need the direct action of Chris Bartlett to change
> the license, as my power does not extend to changing the impacted files.
> (the license is in the README.html within the created zip file, that one
> I can change, but for the website it is in another page(s) to which I
> have no writing access)

Unfortunately, Chris has not been heard from since ca. late 2009.  Which 
is a problem if he is the only one on the planet who can modify the 
administrative files.  Last I heard, Chris Cason was trying to contact 
him, but that was many, many years ago.

> Whatever, is there really a difference between 2.1 and 3.0 (excepted
> that 3.0 is adding exception to GPL 3.0, whereas LGPL 2.1 is setting the
> rights alone) ?

I recall reading that LGPL 3.0, or perhaps 3.0, was created to close a 
loophole in 2.1/2.0.  Some powerful corporation exploited the loophole 
(such entities are not known for observing the spirit of a law or 
contract), and the non-profit and/or little guy who created the software 
got royally screwed.

I do not recall the details of the case, but I would love to upgrade to 
LGPL 3.0 if it can be done.

[Mike Horvath] Re: CC-LGPL [2800 days 10 hours and 59 minutes ago]

Mon, 6 Aug 2018 17:50:25 GMT

On 8/6/2018 12:08 PM, Le_Forgeron wrote:
> As far as I know, the link is correct.
> 

The link is to http://creativecommons.org/licenses/LGPL/2.1/
which gets redirected to https://www.gnu.org/licenses/lgpl-2.1.html

We could update the link to avoid the redirect.

I think "CC-LGPL" is no longer a thing. It should just be "LGPL".



>> 2. Is there a reason we use LGPL version 2.1 instead of 3? Does the
>> object collection predate version 3? Do we want to switch to version 3?
> 
> Oh yes, it predates LGPL v3.0 (29 June 2007)
> LGPL v2.1 is from August 2005
> and the site was designed at least before the 22 December 2006, even if
> there is trace of getting documented in late September 2007.
> (2006 is the date of the CC-LGPL logo for this site)
> 
> I have found pictures as old as 14 Aug 2005 (in staircase by chrisb 2.0)
> 
> The real life of the website seems to be the 28 September 2007.
> 

Interesting.

> Whatever, it would need the direct action of Chris Bartlett to change
> the license, as my power does not extend to changing the impacted files.
> (the license is in the README.html within the created zip file, that one
> I can change, but for the website it is in another page(s) to which I
> have no writing access)
> 
> Whatever, is there really a difference between 2.1 and 3.0 (excepted
> that 3.0 is adding exception to GPL 3.0, whereas LGPL 2.1 is setting the
> rights alone) ?
> 

Dunno. Just asking.


Mike

[Le Forgeron] Re: CC-LGPL [2800 days 12 hours and 40 minutes ago]

Mon, 6 Aug 2018 16:08:53 GMT

Le 06/08/2018 Ã  09:25, Mike Horvath a Ã©critÂ :
> A couple of remarks.
> 
> 1. The link to CC-LGPL at http://lib.povray.org/contributeobject/ now
> redirects to the GNU page for GNU Lesser General Public License, version
> 2.1. Do we want to update the link?
> 

To what ? the LGPL v3.0 ?

As far as I know, the link is correct.

> 2. Is there a reason we use LGPL version 2.1 instead of 3? Does the
> object collection predate version 3? Do we want to switch to version 3?

Oh yes, it predates LGPL v3.0 (29 June 2007)
LGPL v2.1 is from August 2005
and the site was designed at least before the 22 December 2006, even if
there is trace of getting documented in late September 2007.
(2006 is the date of the CC-LGPL logo for this site)

I have found pictures as old as 14 Aug 2005 (in staircase by chrisb 2.0)

The real life of the website seems to be the 28 September 2007.

Whatever, it would need the direct action of Chris Bartlett to change
the license, as my power does not extend to changing the impacted files.
(the license is in the README.html within the created zip file, that one
I can change, but for the website it is in another page(s) to which I
have no writing access)

Whatever, is there really a difference between 2.1 and 3.0 (excepted
that 3.0 is adding exception to GPL 3.0, whereas LGPL 2.1 is setting the
rights alone) ?


> 
> 
> Mike

[Mike Horvath] CC-LGPL [2800 days 21 hours and 24 minutes ago]

Mon, 6 Aug 2018 07:25:24 GMT

A couple of remarks.

1. The link to CC-LGPL at http://lib.povray.org/contributeobject/ now 
redirects to the GNU page for GNU Lesser General Public License, version 
2.1. Do we want to update the link?

2. Is there a reason we use LGPL version 2.1 instead of 3? Does the 
object collection predate version 3? Do we want to switch to version 3?


Mike

[Le Forgeron] Re: Where do I send them? [2801 days 14 hours and 57 minutes ago]

Sun, 5 Aug 2018 13:52:25 GMT

Le 05/08/2018 Ã  04:02, Mike Horvath a Ã©critÂ :
> On 7/28/2018 11:20 AM, Le_Forgeron wrote:
>> Le 28/07/2018 Ã  05:28, Mike Horvath a Ã©critÂ :
>>> If I have updated some objects in the collection, do I send them to
>>> lib.povray.org or to GitHub?
>>>
>>>
>>> Mike
>>
>> In lib.povray.org, please.
>>
> 
> Do you get notified automatically when something gets uploaded?
> 
> 
> Mike

Nope.No notification. I just have to perform a manual check from time to
time.

[Mike Horvath] Re: Where do I send them? [2802 days 2 hours and 47 minutes ago]

Sun, 5 Aug 2018 02:01:47 GMT

On 7/28/2018 11:20 AM, Le_Forgeron wrote:
> Le 28/07/2018 Ã  05:28, Mike Horvath a Ã©critÂ :
>> If I have updated some objects in the collection, do I send them to
>> lib.povray.org or to GitHub?
>>
>>
>> Mike
> 
> In lib.povray.org, please.
> 

Do you get notified automatically when something gets uploaded?


Mike

[Le Forgeron] Re: Where do I send them? [2809 days 13 hours and 29 minutes ago]

Sat, 28 Jul 2018 15:20:05 GMT

Le 28/07/2018 Ã  05:28, Mike Horvath a Ã©critÂ :
> If I have updated some objects in the collection, do I send them to
> lib.povray.org or to GitHub?
> 
> 
> Mike

In lib.povray.org, please.

[Mike Horvath] Where do I send them? [2810 days 1 hour and 21 minutes ago]

Sat, 28 Jul 2018 03:28:14 GMT

If I have updated some objects in the collection, do I send them to 
lib.povray.org or to GitHub?


Mike

[Mike Horvath] Links to latest versions of objects [2813 days 3 hours and 23 minutes ago]

Wed, 25 Jul 2018 01:25:29 GMT

Is there a way to link to the latest version of an object in the 
collection? For instance,

http://lib.povray.org/searchcollection/index2.php?objectName=ShapeGrid&version=1.11&contributorTag=SharkD

leads to version 1.11, but

http://lib.povray.org/searchcollection/index2.php?objectName=ShapeGrid

is kind of borked.


Mike

[clipka] Re: Electric cars searched [2910 days 1 hour and 45 minutes ago]

Thu, 19 Apr 2018 03:03:37 GMT

Am 19.04.2018 um 04:27 schrieb Mike Horvath:

> The batteries are kind of fragile and also somewhat toxic. I'm still not
> sure whether that balances the lack of CO2. The same could be said about
> CFL bulbs, your smartphone, etc. etc.

I believe you want to defer this discussion to povray.off-topic.

[Mike Horvath] Re: Electric cars searched [2910 days 2 hours and 22 minutes ago]

Thu, 19 Apr 2018 02:27:01 GMT

On 3/21/2018 4:01 AM, alhess wrote:
> Electric cars are on the way to become the future of the world. The
â€˜Fuel Cell
> Technologyâ€™ is the newest technology in the engine of the electric
cars for the
> battery power. In the 2017 Tokyo Motor Show that includes products based on EV
> platform like Sports EV, Urban EV and NeuV Concept and other models like Honda
> CR-V and Clarity PHEV. Some electric cars which are running on the road:
> https://autoportal.com/newcars/electric-cars-in-india-cf/
> 
> 
> 
> 
> 
> 

The batteries are kind of fragile and also somewhat toxic. I'm still not 
sure whether that balances the lack of CO2. The same could be said about 
CFL bulbs, your smartphone, etc. etc.


Mike

[alhess] Re: Electric cars searched [2938 days 20 hours and 44 minutes ago]

Wed, 21 Mar 2018 08:05:00 GMT

=?ISO-8859-1?Q?Roland_M=F6sl?= <fou### [at] pegeorg> wrote:
> I just have a new project
> where I need different
> electric cars for the scene
>
> Special important,
> thy BYD e6
> http://car.pege.org/type/byd-e6.htm
>
> Also wanted Nissan Leaf
> Chevrolet Volt
> BYD F3DM
> Opel Ampera

Electric cars are on the way to become the future of the world. The ‘Fuel Cell
Technology’ is the newest technology in the engine of the electric cars for the
battery power. In the 2017 Tokyo Motor Show that includes products based on EV
platform like Sports EV, Urban EV and NeuV Concept and other models like Honda
CR-V and Clarity PHEV. Some electric cars which are running on the road:
https://autoportal.com/newcars/electric-cars-in-india-cf/

[Cousin Ricky] GemCuts: gem cuts and settings [2957 days 13 hours and 15 minutes ago]

Fri, 2 Mar 2018 15:34:05 GMT

The GemCuts module is finally uploaded.  The initial version defines the 
emerald and round brilliant cuts, but I hope to add more in future 
versions.  This version also includes macros for rings and prong settings.

I got electricity restored in early January, and much to my surprise, 
the sample scene suddenly started rendering twice as fast.  My only 
guess is that with the room being previously ventilated with a tiny 6 
inch (15 cm) fan, my computer wasn't cooling itself efficiently, and the 
CPU throttled back accordingly.  Just a guess.

However, even after the hurricane delay, I'm glad I didn't rush the 
testing.  As recently as less than two weeks ago, I found a bug in the 
ring shank, of all places.  One would think a simple toroid lathe is the 
least likely part to screw up.  Lesson: do comprehensive testing!  Don't 
skimp, and don't take anything for granted.

http://lib.povray.org/searchcollection/index2.php?objectName=GemCuts&contributorTag=Cousin%20Ricky

[Cousin Ricky] Re: The Bright Star Catalogue [2970 days 5 hours and 17 minutes ago]

Sat, 17 Feb 2018 23:32:24 GMT

On 2018-02-09 10:28 PM (-4), Mike Horvath wrote:
> The fuzzy circles don't look so great. I don't know if anything can be
> done to improve them however. In video games, stars are often reduced to
> 1 pixel. But I don't think in POVray there's an easy way to make a star
> exactly 1 pixel big. Maybe with some trigonometry?

Yes, of course they can be improved!  The purpose of the demo was merely 
to demonstrate how to use the data.  I consider attempting a realistic 
sky beyond the scope of the demo.

This works if you are representing the stars as actual objects:

----------[BEGIN CODE]----------
#version 3.7;

global_settings { assumed_gamma 1 }

#declare Cam_angle = 60;
#declare RSky = 10000; // arbitrary distance to the stars
#declare R = RSky * tan (radians (Cam_angle / 2)) / image_width;

camera
{ location 1.64 * y
   look_at <0.5, 2.64, 2.5>
   angle Cam_angle
}

plane { y, 0 pigment { checker } }

#include "brightstar5.inc"

#default { finish { ambient 0 diffuse 0 emission 1 } }
union
{ #for (I, 0, BSC5_N - 1)
     #if (BSC5_Data [I] [BSC5_HD] != BSC5_NO_DATA)
       sphere
       { RSky * y, R
         pigment { rgb BSC5_fn_Brightness (BSC5_Data [I] [BSC5_MAG], 0) }
         rotate
         < 90 - BSC5_Data [I] [BSC5_DEC],
           -15 * BSC5_Data [I] [BSC5_RA],
           0
         >
       }
     #end
   #end
   rotate <0, 120, 71.7>
}
-----------[END CODE]-----------

I disregarded image_height in the formula because the POV-Ray camera 
considers only image_width for its field angle.  Also note that if the 
camera is significantly distant from the origin, you will need to make 
appropriate adjustments.

Note that with a diameter of 1 pixel, an adaptive anti-aliasing trace 
will miss quite a few stars.  To avoid this, you'll need to either use 
+A0.0 (slow), or use a diameter slightly larger than 1 pixel (times 
sqrt(2) should do).  As far as using boxes instead of spheres, I don't 
think it would be worth the effort.

If Orion looks strangely oriented in the above code, it's because I'm 
stargazing from the northeast Caribbean.

Yes, there is some distortion as you move away from the center of the 
image, as explained in the knowledge base:
   http://wiki.povray.org/content/Knowledgebase:Misconceptions#Topic_3

The orthographic camera will preserve the star shape, but the star 
positions will still be distorted, for the reason you learned in 4th 
grade geography.  Also, the orthographic camera would be quite awkward 
to use if you are rendering, say, a landscape.

A sky sphere would use a different formula, but the math would be similar.

[Mike Horvath] Re: The Bright Star Catalogue [2977 days 1 hour and 21 minutes ago]

Sun, 11 Feb 2018 03:27:51 GMT

On 2/10/2018 10:22 PM, Mike Horvath wrote:
> Interesting. Would it work better with a cube oriented to face the 
> camera? I suppose the perspective distortion might make the cubes look 
> weird if they're toward the edges of the image. But spheres would end up 
> looking distorted too.
> 
> 
> Mike
> 

E.g. a true "one-pixel" POV-Ray object would not be distorted by 
perspective, which I think is realistic since stars are so distant and 
tiny that visual perspective has no effect on their perceived 
dimensions/brightness.

Mike

[Mike Horvath] Re: The Bright Star Catalogue [2977 days 1 hour and 27 minutes ago]

Sun, 11 Feb 2018 03:21:56 GMT

On 2/10/2018 9:44 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I kinda wish there were a POV-Ray object that would be guaranteed to
>> always be 1 pixel big.
> 
> I snipped this out of something I wrote last April, and haven't tested it out
> tonight in a scene all by itself, but it gives you the broad strokes.
> 
> 
> Location is the camera location.
> (So do
> #declare Location = <0, 0, -10>;
> camera { ... location Location  ...}
> )
> Vector is the center of the object you want to be 1 pixel.
> The macro returns the radius of a sphere/cylinder so it is a pixel wide.
> you can work the rest out from there.
> 
> // Minimum radius for solid visibility is (Z/image_width)*Aspect
> // Minimum radius for threshold visibility is (Z/image_width)
> 
> #macro MinRad (Vector)
>     #local Aspect = image_width/image_height;
>     #local Dist = vlength (Vector-Location);
>     #local M = (0.5*Aspect)/tan(radians(Angle/2));
>     #local ZA = Dist/M;
>     #local Rad = (ZA/image_width)*Aspect;
>     Rad
> #end // end macro MinRad
> 
> 

Interesting. Would it work better with a cube oriented to face the 
camera? I suppose the perspective distortion might make the cubes look 
weird if they're toward the edges of the image. But spheres would end up 
looking distorted too.


Mike

[Bald Eagle] Re: The Bright Star Catalogue [2977 days 2 hours and 4 minutes ago]

Sun, 11 Feb 2018 02:45:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I kinda wish there were a POV-Ray object that would be guaranteed to
> always be 1 pixel big.

I snipped this out of something I wrote last April, and haven't tested it out
tonight in a scene all by itself, but it gives you the broad strokes.

Location is the camera location.
(So do
#declare Location = <0, 0, -10>;
camera { ... location Location  ...}
)
Vector is the center of the object you want to be 1 pixel.
The macro returns the radius of a sphere/cylinder so it is a pixel wide.
you can work the rest out from there.

// Minimum radius for solid visibility is (Z/image_width)*Aspect
// Minimum radius for threshold visibility is (Z/image_width)

#macro MinRad (Vector)
   #local Aspect = image_width/image_height;
   #local Dist = vlength (Vector-Location);
   #local M = (0.5*Aspect)/tan(radians(Angle/2));
   #local ZA = Dist/M;
   #local Rad = (ZA/image_width)*Aspect;
   Rad
#end // end macro MinRad

[Mike Horvath] Re: The Bright Star Catalogue [2977 days 3 hours and 52 minutes ago]

Sun, 11 Feb 2018 00:56:46 GMT

I kinda wish there were a POV-Ray object that would be guaranteed to 
always be 1 pixel big.

Mike



On 2/10/2018 5:14 PM, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> not really.
>> Unless your default camera is
>> ...
>>    up image_height*y
>>    right image_width*x
>> ...
>> but that's not the camera you get from
>>
>> camera{ orthographic }
>>
>> || up: 0.000, 1.000, 0.000
>> || right: 1.330, 0.000, 0.000
>> || location: 0.000, 0.000, 0.000
>> || direction: 0.000, 0.000, 1.000
> 
> Well, then I guess I didn't remember correctly  ;)
> 
> I vaguely recalled this discussion:
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5845a06cc97737fcc437ac910%40news.povray.org%3E/
> 
> So modifying that so Pixel "size" is described in POV-units, then we could have
> 
> #macro Zoom (PixelSize)
> camera {
>   orthographic
>   location <0, 0, -PixelSize>
>   look_at  <0, 0, 0>
>   right (x*image_width )*PixelSize
>   up    (y*image_height)*PixelSize
>   }
> #end
> 
> 
> (I haven't entirely determined what the best camera-to-lookAt distance is to
> avoid some weird things happening)
> 
> 
> 
>

[Bald Eagle] Re: The Bright Star Catalogue [2977 days 6 hours and 34 minutes ago]

Sat, 10 Feb 2018 22:15:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:

> not really.
> Unless your default camera is
> ...
>   up image_height*y
>   right image_width*x
> ...
> but that's not the camera you get from
>
> camera{ orthographic }
>
> || up: 0.000, 1.000, 0.000
> || right: 1.330, 0.000, 0.000
> || location: 0.000, 0.000, 0.000
> || direction: 0.000, 0.000, 1.000

Well, then I guess I didn't remember correctly  ;)

I vaguely recalled this discussion:
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5845a06cc97737fcc437ac910%40news.povray.org%3E/

So modifying that so Pixel "size" is described in POV-units, then we could have

#macro Zoom (PixelSize)
camera {
 orthographic
 location <0, 0, -PixelSize>
 look_at  <0, 0, 0>
 right (x*image_width )*PixelSize
 up    (y*image_height)*PixelSize
 }
#end


(I haven't entirely determined what the best camera-to-lookAt distance is to
avoid some weird things happening)

[Le Forgeron] Re: The Bright Star Catalogue [2977 days 10 hours and 8 minutes ago]

Sat, 10 Feb 2018 18:41:25 GMT

Le 10/02/2018 Ã  04:23, Bald Eagle a Ã©critÂ :
> Mike Horvath <mik### [at] gmailcom> wrote:
> But I don't think in POVray there's an easy way to make a star
>> exactly 1 pixel big. Maybe with some trigonometry?
> 
> I worked that out obtain a constant-apparent-width cylinder for a bounding box,
> and a Dupin cyclide for orbital trajectories.
> Obtaining a constant 1-pixel width is pretty trivial with the orthographic
> camera, since with the default camera, IIRC, 1 POV-unit = 1 pixel.

not really.
Unless your default camera is
...
  up image_height*y
  right image_width*x
...
but that's not the camera you get from

camera{ orthographic }

|| up: 0.000, 1.000, 0.000
|| right: 1.330, 0.000, 0.000
|| location: 0.000, 0.000, 0.000
|| direction: 0.000, 0.000, 1.000

[Bald Eagle] Re: The Bright Star Catalogue [2978 days 1 hour and 24 minutes ago]

Sat, 10 Feb 2018 03:25:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
But I don't think in POVray there's an easy way to make a star
> exactly 1 pixel big. Maybe with some trigonometry?

I worked that out obtain a constant-apparent-width cylinder for a bounding box,
and a Dupin cyclide for orbital trajectories.
Obtaining a constant 1-pixel width is pretty trivial with the orthographic
camera, since with the default camera, IIRC, 1 POV-unit = 1 pixel.

[Mike Horvath] Re: The Bright Star Catalogue [2978 days 2 hours and 21 minutes ago]

Sat, 10 Feb 2018 02:27:58 GMT

On 2/8/2017 8:08 AM, Cousin Ricky wrote:
> I have extracted some of the data fields from the Yale Bright Star 
> Catalogue and converted them to SDL.Â  This catalog contains all 
> nighttime stars of magnitude 6.5 and brighter (roughly all nighttime 
> stars visible to the naked eye), plus a few dimmer ones.Â  The 
> BrightStar5 module includes more data fields than the include file 
> Rarius published a while back, including catalog designations and color 
> data.Â  Macros are included for star coloration and Bayer designation 
> labels.Â  You can also seek individual stars by Bayer, Draper, Flamsteed, 
> or SAO designations.
> 
> Rarius stated that the catalog is in the public domain.Â  I could not 
> determine the intellectual property status from the published sources, 
> and in the process of trying to find out, I ended up having a very nice 
> phone conversation with one of the authors, Dr. Warren!
> 
> The 5th edition of the catalog, as it stands, is in a preliminary state. 
>  Â (The primary author died in 2007.)Â  There is no projected
date for 
> final publication.
> 
> POV-Ray 3.7.1 beta 2 will crash hard with this module.Â  Think Bayer 
> designations, and if you've been following p.beta-test, you'll know 
> exactly why it crashes.Â  Some of the 3.7.1 alphas (including some 2015 
> vintages) also crashed, but 3.7.0 works fine.Â  The latest master passes, 
> so everything should be fine when beta 3 is released.
> 
>
http://lib.povray.org/searchcollection/index2.php?objectName=BrightStar5&contributorTag=Cousin%20Ricky

> 

The fuzzy circles don't look so great. I don't know if anything can be 
done to improve them however. In video games, stars are often reduced to 
1 pixel. But I don't think in POVray there's an easy way to make a star 
exactly 1 pixel big. Maybe with some trigonometry?


Mike

[Cousin Ricky] Re: The Bright Star Catalogue [3042 days 6 hours and 9 minutes ago]

Thu, 7 Dec 2017 22:39:40 GMT

On 2017-02-08 08:08 AM (-5), Cousin Ricky wrote:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted them to SDL. [snip]
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=BrightStar5&contributorTag=Cousin%20Ricky

I have uploaded BrightStar5 version 1.1, which has indexes on the data 
arrays.  The seek macros run *much* faster now.

[Le Forgeron] Re: Result. 59 percent works. [3204 days 15 hours and 25 minutes ago]

Wed, 28 Jun 2017 13:24:28 GMT

Le 28/06/2017 Ã  11:58, Mike Horvath a Ã©crit :
> On 5/31/2017 2:43 AM, Thomas de Groot wrote:
>> On 31-5-2017 7:54, Le_Forgeron wrote:
>>
>>> You can now find everything from the collections (and more: 3dclouds was
>>> added there) in github:
>>>
>>> https://github.com/LeForgeron/PovContributions
>>>
>>
>> This is working very nicely!
>>
> 
> If something happens to Le_Forgeron then it will stop working too.
> 

Even if I'm not anymore on the Internet, you could always fork it and 
even try to reclaim it from github later (if you care).

Or do you have a plan to get github's server down ?

[Mike Horvath] Re: Result. 59 percent works. [3204 days 18 hours and 50 minutes ago]

Wed, 28 Jun 2017 09:58:36 GMT

On 5/31/2017 2:43 AM, Thomas de Groot wrote:
> On 31-5-2017 7:54, Le_Forgeron wrote:
> 
>> You can now find everything from the collections (and more: 3dclouds was
>> added there) in github:
>>
>> https://github.com/LeForgeron/PovContributions
>>
> 
> This is working very nicely!
> 

If something happens to Le_Forgeron then it will stop working too.


Mike

[Thomas de Groot] Re: Result. 59 percent works. [3232 days 22 hours and 5 minutes ago]

Wed, 31 May 2017 06:43:52 GMT

On 31-5-2017 7:54, Le_Forgeron wrote:

> You can now find everything from the collections (and more: 3dclouds was
> added there) in github:
>
> https://github.com/LeForgeron/PovContributions
>

This is working very nicely!

-- 
Thomas

[Le Forgeron] Re: Result. 59 percent works. [3232 days 22 hours and 54 minutes ago]

Wed, 31 May 2017 05:54:39 GMT

Le 31/05/2017 Ã  00:39, p a Ã©crit :
> I tried to download everything from the thumbnail view at
> http://lib.povray.org/searchcollection/index2.php. I count 91 files offered for
> download. Some zip files I could not download. I downloaded 89 .zip files. 54
> ..zip files have 80 .pov files that compile correctly into 80 .png files. The
> other 35 .zip files have 68 .pov files that would not compile. In povray.org,
> the same file is listed several times, but with diffrent names. Case in some
> filenames do not match case in the .pov script. I renamed some files, but I did
> not try to fix them all. My result is posted at
> http://pdscript.com/p/debian/povorg8/povorg8.htm. I used povray version
> 1:3.7.0.0-8, which is in debian 8.5.
>
>
The object collection is painfully case-blind: some contributions were 
made from Windows at a time where the local filesystem was transforming 
filename to a single case (either all lower or all uppercase, IIRC DOS 
was all uppercase).

It take a bit of debugging when using on a filesystem which honors the 
case of filename.

You can now find everything from the collections (and more: 3dclouds was 
added there) in github:

https://github.com/LeForgeron/PovContributions

[p] Result. 59 percent works. [3233 days 6 hours and 4 minutes ago]

Tue, 30 May 2017 22:45:00 GMT

I tried to download everything from the thumbnail view at
http://lib.povray.org/searchcollection/index2.php. I count 91 files offered for
download. Some zip files I could not download. I downloaded 89 .zip files. 54
..zip files have 80 .pov files that compile correctly into 80 .png files. The
other 35 .zip files have 68 .pov files that would not compile. In povray.org,
the same file is listed several times, but with diffrent names. Case in some
filenames do not match case in the .pov script. I renamed some files, but I did
not try to fix them all. My result is posted at
http://pdscript.com/p/debian/povorg8/povorg8.htm. I used povray version
1:3.7.0.0-8, which is in debian 8.5.

[Thomas de Groot] Re: povray Object Collection download wanted. [3293 days 21 hours and 58 minutes ago]

Fri, 31 Mar 2017 06:51:02 GMT

On 30-3-2017 23:41, p wrote:
> I would like to download all the *.pov files in the povray Object Collection.
> How many files are there? Message says 91 objects found.
> Is there only 91 *.pov files in the povray Object Collection?
>
> Message says Objects 1 to 10 displayed. But the Next button does not work.
> How to access more?
>
> The only way I see to get all the files is to manually download each one
> individually, and only if the next button works.  Is there a better way? Is
> there one zip file of the collection?  Can someone send the collection to me?
>
> I wrote a bash script to run the 355 povray examples in
> debian 8.5 software repository /usr/share/doc/povray/examples/***.pov.
> The result can be accessed from
> http://pdscript.com/p/debian/example/Computer/index.htm. I would like more *.pov
> examples to run and post.
>
>

There is .pov, but also .inc, and maybe .mcr, possibly .txt at least.

I would suggest /manual/ if you want to be sure. That Next button 
problem is an old recurring one I am afraid. :-(

-- 
Thomas

[p] Re: povray Object Collection download wanted. [3294 days 6 hours and 34 minutes ago]

Thu, 30 Mar 2017 22:15:01 GMT

Yes, the thumbnail helps. Thank you.  It shows 107 files.
I can manually click that many times.
I ask again: Is that all there is in this collection?
So what other collections are there?
Debian has 355 povray example files.

[Mike Horvath] Re: povray Object Collection download wanted. [3294 days 6 hours and 56 minutes ago]

Thu, 30 Mar 2017 21:52:51 GMT

On 3/30/2017 5:41 PM, p wrote:
> I would like to download all the *.pov files in the povray Object Collection.
> How many files are there? Message says 91 objects found.
> Is there only 91 *.pov files in the povray Object Collection?
>
> Message says Objects 1 to 10 displayed. But the Next button does not work.
> How to access more?
>
> The only way I see to get all the files is to manually download each one
> individually, and only if the next button works.  Is there a better way? Is
> there one zip file of the collection?  Can someone send the collection to me?
>
> I wrote a bash script to run the 355 povray examples in
> debian 8.5 software repository /usr/share/doc/povray/examples/***.pov.
> The result can be accessed from
> http://pdscript.com/p/debian/example/Computer/index.htm. I would like more *.pov
> examples to run and post.
>
>


There is a thumbnail view that might help.

http://lib.povray.org/searchcollection/index2.php

No, you can't download the entire collection at once.


Mike

[p] povray Object Collection download wanted. [3294 days 7 hours and 4 minutes ago]

Thu, 30 Mar 2017 21:45:01 GMT

I would like to download all the *.pov files in the povray Object Collection.
How many files are there? Message says 91 objects found.
Is there only 91 *.pov files in the povray Object Collection?

Message says Objects 1 to 10 displayed. But the Next button does not work.
How to access more?

The only way I see to get all the files is to manually download each one
individually, and only if the next button works.  Is there a better way? Is
there one zip file of the collection?  Can someone send the collection to me?

I wrote a bash script to run the 355 povray examples in
debian 8.5 software repository /usr/share/doc/povray/examples/***.pov.
The result can be accessed from
http://pdscript.com/p/debian/example/Computer/index.htm. I would like more *.pov
examples to run and post.

[Mr] Re: File types [3309 days 19 hours and 29 minutes ago]

Wed, 15 Mar 2017 09:20:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> On 3/8/2017 12:35 PM, Le_Forgeron wrote:
> > I'm afraid you are limited to the following file type: (as stated on the
> > contribution page)
> > BMP, CSS, CSV, GIF, HTM, HTML, INC, INI, JPEG, JPG, JS, MAC, MCR, MDL,
> > PGM, PNG, POV, PPM, TGA, TIF, TIFF, TXT
> >
> > (once connected:
> > http://lib.povray.org/contributeobject/
> > )
> >
> > svg is text, unless you use the compressed format, so that could be a
> > way (with some text to explain)
> >
> > .TeX , IIRC, is also text.
> >
> > But for the other files, It seems to be a no go.
> >
> > As a side note, the object collection is really a collection of povray
> > usable objects (scene, macro, utility), not an universal library for
> > graphical discussion.
> > (even if MDL is tied to moray.
> >
> > Maybe it could be easier to use your personal page on the povray-wiki
> > (hint: make a subpage, it can grow fast on a single page)
> >
> > The rules there are different. ( http://wiki.povray.org/content/Main_Page )
> >
>
> I wonder if it's worth the trouble to upload the files to GitHub? I
> haven't mastered the GitHub software yet. And, it seems like a waste for
> such a small project.
>
> Are there any other POV-Ray projects on GitHub? (Besides POV-Ray itself.)
>
>
> Mike

The Alternative POV-Ray exporter of Lanuhum is on GitHub ,
https://github.com/Lanuhum/BlendPov-alternative and official Blender to POV-Ray
exporter uses a Blender Git for all the addons
git://git.blender.org/blender-addons.git

[Mike Horvath] Re: File types [3310 days 8 hours and 35 minutes ago]

Tue, 14 Mar 2017 20:14:23 GMT

On 3/8/2017 12:35 PM, Le_Forgeron wrote:
> I'm afraid you are limited to the following file type: (as stated on the
> contribution page)
> BMP, CSS, CSV, GIF, HTM, HTML, INC, INI, JPEG, JPG, JS, MAC, MCR, MDL,
> PGM, PNG, POV, PPM, TGA, TIF, TIFF, TXT
>
> (once connected:
> http://lib.povray.org/contributeobject/
> )
>
> svg is text, unless you use the compressed format, so that could be a
> way (with some text to explain)
>
> .TeX , IIRC, is also text.
>
> But for the other files, It seems to be a no go.
>
> As a side note, the object collection is really a collection of povray
> usable objects (scene, macro, utility), not an universal library for
> graphical discussion.
> (even if MDL is tied to moray.
>
> Maybe it could be easier to use your personal page on the povray-wiki
> (hint: make a subpage, it can grow fast on a single page)
>
> The rules there are different. ( http://wiki.povray.org/content/Main_Page )
>

I wonder if it's worth the trouble to upload the files to GitHub? I 
haven't mastered the GitHub software yet. And, it seems like a waste for 
such a small project.

Are there any other POV-Ray projects on GitHub? (Besides POV-Ray itself.)


Mike

[Mike Horvath] Re: File types [3316 days 5 hours and 5 minutes ago]

Wed, 8 Mar 2017 23:44:12 GMT

On 3/8/2017 12:35 PM, Le_Forgeron wrote:
> Le 08/03/2017 Ã  14:02, Mike Horvath a Ã©crit :
>> I would like to upload some stuff I've been working on to the Object
>> Collection, but the files include stuff like GeoGebra (.ggb, .ggt), TeX
>> (.tex), Scalable Vector Graphics (.svg) and other files. I'm kind of at
>> a loss as to what to do.
>>
>> Mike
>
> I'm afraid you are limited to the following file type: (as stated on the
> contribution page)
> BMP, CSS, CSV, GIF, HTM, HTML, INC, INI, JPEG, JPG, JS, MAC, MCR, MDL,
> PGM, PNG, POV, PPM, TGA, TIF, TIFF, TXT
>
> (once connected:
> http://lib.povray.org/contributeobject/
> )
>
> svg is text, unless you use the compressed format, so that could be a
> way (with some text to explain)
>
> .TeX , IIRC, is also text.
>
> But for the other files, It seems to be a no go.
>
> As a side note, the object collection is really a collection of povray
> usable objects (scene, macro, utility), not an universal library for
> graphical discussion.
> (even if MDL is tied to moray.
>
> Maybe it could be easier to use your personal page on the povray-wiki
> (hint: make a subpage, it can grow fast on a single page)
>
> The rules there are different. ( http://wiki.povray.org/content/Main_Page )
>

How will people know where to look for my stuff when they visit the 
Object Collection? Also, can I store ZIP or other files on the wiki server?


Mike

[Le Forgeron] Re: File types [3316 days 11 hours and 13 minutes ago]

Wed, 8 Mar 2017 17:35:32 GMT

Le 08/03/2017 Ã  14:02, Mike Horvath a Ã©crit :
> I would like to upload some stuff I've been working on to the Object
> Collection, but the files include stuff like GeoGebra (.ggb, .ggt), TeX
> (.tex), Scalable Vector Graphics (.svg) and other files. I'm kind of at
> a loss as to what to do.
> 
> Mike

I'm afraid you are limited to the following file type: (as stated on the
contribution page)
BMP, CSS, CSV, GIF, HTM, HTML, INC, INI, JPEG, JPG, JS, MAC, MCR, MDL,
PGM, PNG, POV, PPM, TGA, TIF, TIFF, TXT

(once connected:
http://lib.povray.org/contributeobject/
)

svg is text, unless you use the compressed format, so that could be a
way (with some text to explain)

.TeX , IIRC, is also text.

But for the other files, It seems to be a no go.

As a side note, the object collection is really a collection of povray
usable objects (scene, macro, utility), not an universal library for
graphical discussion.
(even if MDL is tied to moray.

Maybe it could be easier to use your personal page on the povray-wiki
(hint: make a subpage, it can grow fast on a single page)

The rules there are different. ( http://wiki.povray.org/content/Main_Page )

[Mike Horvath] File types [3316 days 15 hours and 47 minutes ago]

Wed, 8 Mar 2017 13:02:09 GMT

I would like to upload some stuff I've been working on to the Object 
Collection, but the files include stuff like GeoGebra (.ggb, .ggt), TeX 
(.tex), Scalable Vector Graphics (.svg) and other files. I'm kind of at 
a loss as to what to do.

Mike

[Cousin Ricky] Re: Next button doesn't work [3322 days 15 hours and 25 minutes ago]

Thu, 2 Mar 2017 13:24:24 GMT

On 2017-03-01 06:26 PM (-4), dick balaska wrote:
> I thought I'd take a gander through the object collection.
> I seem to be only to look at the first page of a result set.
> The "Next" button does nothing.

The whereabouts of the Collection administrator have been unknown for 
more than 7 years, so it is difficult to get access to fix some 
problems.  In the meantime, you can click on the Thumbnails link at the 
top of the page to see all of the contributions.

[dick balaska] Next button doesn't work [3323 days 6 hours and 22 minutes ago]

Wed, 1 Mar 2017 22:26:30 GMT

I thought I'd take a gander through the object collection.
I seem to be only to look at the first page of a result set.
The "Next" button does nothing.

-- 
dik

[Cousin Ricky] Re: The Bright Star Catalogue [3333 days 15 hours and 58 minutes ago]

Sun, 19 Feb 2017 12:51:01 GMT

On 2017-02-08 09:08 AM (-4), Cousin Ricky wrote:
> POV-Ray 3.7.1 beta 2 will crash hard with this module.  Think Bayer
> designations, and if you've been following p.beta-test, you'll know
> exactly why it crashes.  Some of the 3.7.1 alphas (including some 2015
> vintages) also crashed, but 3.7.0 works fine.  The latest master passes,
> so everything should be fine when beta 3 is released.

POV-Ray 3.7.1 beta 3 works fine with this module.

[omniverse] Re: The Bright Star Catalogue [3344 days 11 hours and 54 minutes ago]

Wed, 8 Feb 2017 16:55:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted them to SDL.

Thanks Richard! Great way to use the data. All of it impressive work.

Bob

[Paolo Gibellini] Re: The Bright Star Catalogue [3344 days 15 hours and 25 minutes ago]

Wed, 8 Feb 2017 13:24:03 GMT

Cousin Ricky wrote on 08/02/2017 14:08:
> I have extracted some of the data fields from the Yale Bright Star
> Catalogue and converted them to SDL.  This catalog contains all
> nighttime stars of magnitude 6.5 and brighter (roughly all nighttime
> stars visible to the naked eye), plus a few dimmer ones.  The
> BrightStar5 module includes more data fields than the include file
> Rarius published a while back, including catalog designations and color
> data.  Macros are included for star coloration and Bayer designation
> labels.  You can also seek individual stars by Bayer, Draper, Flamsteed,
> or SAO designations.
>
> Rarius stated that the catalog is in the public domain.  I could not
> determine the intellectual property status from the published sources,
> and in the process of trying to find out, I ended up having a very nice
> phone conversation with one of the authors, Dr. Warren!
>
> The 5th edition of the catalog, as it stands, is in a preliminary state.
>  (The primary author died in 2007.)  There is no projected date for
> final publication.
>
> POV-Ray 3.7.1 beta 2 will crash hard with this module.  Think Bayer
> designations, and if you've been following p.beta-test, you'll know
> exactly why it crashes.  Some of the 3.7.1 alphas (including some 2015
> vintages) also crashed, but 3.7.0 works fine.  The latest master passes,
> so everything should be fine when beta 3 is released.
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=BrightStar5&contributorTag=Cousin%20Ricky
>

It seems very interesting.
I hope to see soon some examples,
Paolo

[Cousin Ricky] The Bright Star Catalogue [3344 days 15 hours and 44 minutes ago]

Wed, 8 Feb 2017 13:04:29 GMT

I have extracted some of the data fields from the Yale Bright Star 
Catalogue and converted them to SDL.  This catalog contains all 
nighttime stars of magnitude 6.5 and brighter (roughly all nighttime 
stars visible to the naked eye), plus a few dimmer ones.  The 
BrightStar5 module includes more data fields than the include file 
Rarius published a while back, including catalog designations and color 
data.  Macros are included for star coloration and Bayer designation 
labels.  You can also seek individual stars by Bayer, Draper, Flamsteed, 
or SAO designations.

Rarius stated that the catalog is in the public domain.  I could not 
determine the intellectual property status from the published sources, 
and in the process of trying to find out, I ended up having a very nice 
phone conversation with one of the authors, Dr. Warren!

The 5th edition of the catalog, as it stands, is in a preliminary state. 
  (The primary author died in 2007.)  There is no projected date for 
final publication.

POV-Ray 3.7.1 beta 2 will crash hard with this module.  Think Bayer 
designations, and if you've been following p.beta-test, you'll know 
exactly why it crashes.  Some of the 3.7.1 alphas (including some 2015 
vintages) also crashed, but 3.7.0 works fine.  The latest master passes, 
so everything should be fine when beta 3 is released.

http://lib.povray.org/searchcollection/index2.php?objectName=BrightStar5&contributorTag=Cousin%20Ricky

[Cousin Ricky] IntegrateLight: an add-on for SpectralRender [3430 days 2 hours and 10 minutes ago]

Tue, 15 Nov 2016 02:38:44 GMT

In Ive's SpectralRender package, a comment in spectral_lights.inc reads:

   "NOTE: I'm cheating a bit with the Phillips[sic] lamps as they have
   sometimes significant peaks in between the 10nm steps and as those
   peaks are the most interesting part for specular rendering I won't
   miss them."

I wasn't satisfied, so I wrote a module that integrates the spectral 
curves instead of just sampling them.  Not only for the Philips lamps, 
but the Mitsubishi lamps as well, the difference is noticeable.

The user is also given better control over light source luminosities, 
and the luminosities of the preview mode are coordinated with those of 
the final spectral mode render.  Many thanks to Scott for your 
assistance in this matter.

http://lib.povray.org/searchcollection/index2.php?objectName=IntegrateLight&contributorTag=Cousin%20Ricky

[Cousin Ricky] Re: Caption 1.1 [3430 days 2 hours and 13 minutes ago]

Tue, 15 Nov 2016 02:35:43 GMT

On 11/14/2016 12:42 AM, Mike Horvath wrote:
> Does your caption script work when using focal blur?

The caption objects are part of the scene, so as such, they are affected 
by focal blur in the same way as other objects.  If the captions are in 
the focal plane, they will not be blurred.

If you are using screen.inc to place the captions (as in the example 
scene), then you can't use focal blur anyway, unless you perform even 
more surgery on screen.inc.  But if you do make such a change, be 
prepared for a Screen_Object() to place a lot of blurry objects.

[Mike Horvath] Re: Caption 1.1 [3431 days and 7 minutes ago]

Mon, 14 Nov 2016 04:42:01 GMT

On 5/7/2016 8:53 PM, Cousin Ricky wrote:
> Recently, in another Object Collection module, I deprecated a global parameter
> that should have been applied as needed to each object, i.e., a macro argument.
> For this update, I introduce a global parameter.  Always a judgment call.
>
> In Caption 1.0.1 and earlier, a caption with descenders and a caption without
> descenders will not center on the same baseline.  A global parameter seemed
> right in this case for maintaining consistency between macro calls.  Of course,
> the same result can be achieved by passing the same value in every macro call,
> but at what point does adding yet another argument make sticking to a principle
> more unwieldy that it's worth?
>
> In Caption version 1.1:
>  - The top padding may differ from the bottom padding.
>  - There is an option to pad around the font metrics rather than the
>    text itself.
>  - A texture may be obtained without being attached to an object.
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=Caption&contributorTag=Cousin%20Ricky
>
>
>

Does your caption script work when using focal blur?

Mike

[Dave Blandston] Re: Caption 1.1 [3432 days 20 hours and 54 minutes ago]

Sat, 12 Nov 2016 07:55:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> In Caption 1.0.1 and earlier, a caption with descenders and a caption without
> descenders will not center on the same baseline.  A global parameter seemed
> right in this case for maintaining consistency between macro calls.  Of course,
> the same result can be achieved by passing the same value in every macro call,
> but at what point does adding yet another argument make sticking to a principle
> more unwieldy that it's worth?

Agreed. My high school English teacher said, "You have to learn what the rules
are before you can break them." I think that was great advice.

[Mike Horvath] Re: screen.inc [3439 days 3 hours and 15 minutes ago]

Sun, 6 Nov 2016 01:33:47 GMT

On 10/27/2016 10:57 AM, Cousin Ricky wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> Also, does the object collection use the same license as the include
>> files that come with POV-Ray?
>
> No, they are quite different.  The Object Collection uses the GNU Lesser General
> Public License 2.1, as explained in the README files.  (Note there is an error
> in terminology, as I have brought up in a previous thread.)  The 3.7 version of
> screen.inc uses the Creative Commons Attribution-ShareAlike 3.0 Unported
> License.  Earlier versions of screen.inc are presumably covered by povlegal.doc,
> which every POVer prior to 2013 November 6 should be well familiar with.
>
> For the GNU and Creative Commons licenses, I suggest you follow the links given
> in the Object Collection README files and screen.inc 3.7, respectively.
>
> Disclaimer: IANAL.
>
>
>


If I change the 3.7 version of the script instead, why not make a 
substitution and include it with the program?

Mike

[Cousin Ricky] Re: screen.inc [3448 days 13 hours and 49 minutes ago]

Thu, 27 Oct 2016 15:00:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> Also, does the object collection use the same license as the include
> files that come with POV-Ray?

No, they are quite different.  The Object Collection uses the GNU Lesser General
Public License 2.1, as explained in the README files.  (Note there is an error
in terminology, as I have brought up in a previous thread.)  The 3.7 version of
screen.inc uses the Creative Commons Attribution-ShareAlike 3.0 Unported
License.  Earlier versions of screen.inc are presumably covered by povlegal.doc,
which every POVer prior to 2013 November 6 should be well familiar with.

For the GNU and Creative Commons licenses, I suggest you follow the links given
in the Object Collection README files and screen.inc 3.7, respectively.

Disclaimer: IANAL.

[Mike Horvath] Re: screen.inc [3451 days 4 hours and 42 minutes ago]

Tue, 25 Oct 2016 00:06:41 GMT

On 10/1/2016 10:59 AM, Cousin Ricky wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> Can I upload my modified version of "screen.inc" to the object
>> collection? Are the software licenses compatible?
>
> I would call it by a different name.
>
>
>
>

It's the same file, though. Just with a few minor alterations.

Also, does the object collection use the same license as the include 
files that come with POV-Ray?

Mike

[Cousin Ricky] Re: screen.inc [3474 days 13 hours and 49 minutes ago]

Sat, 1 Oct 2016 15:00:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> Can I upload my modified version of "screen.inc" to the object
> collection? Are the software licenses compatible?

I would call it by a different name.

[Mike Horvath] screen.inc [3483 days 5 hours and 43 minutes ago]

Thu, 22 Sep 2016 23:06:21 GMT

Can I upload my modified version of "screen.inc" to the object 
collection? Are the software licenses compatible?


Mike

[Cousin Ricky] Re: Licensing [3567 days 17 hours and 4 minutes ago]

Thu, 30 Jun 2016 11:45:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> Arial, Trebuchet, and Verdana (Microsoft) though proprietary, are available for
> free.

Clarification:  Microsoft does not actually own Arial; it licenses Arial from
Monotype Imaging.

[Cousin Ricky] Caption 1.1 [3621 days 3 hours and 54 minutes ago]

Sun, 8 May 2016 00:55:04 GMT

Recently, in another Object Collection module, I deprecated a global parameter
that should have been applied as needed to each object, i.e., a macro argument.
For this update, I introduce a global parameter.  Always a judgment call.

In Caption 1.0.1 and earlier, a caption with descenders and a caption without
descenders will not center on the same baseline.  A global parameter seemed
right in this case for maintaining consistency between macro calls.  Of course,
the same result can be achieved by passing the same value in every macro call,
but at what point does adding yet another argument make sticking to a principle
more unwieldy that it's worth?

In Caption version 1.1:
 - The top padding may differ from the bottom padding.
 - There is an option to pad around the font metrics rather than the
   text itself.
 - A texture may be obtained without being attached to an object.

http://lib.povray.org/searchcollection/index2.php?objectName=Caption&contributorTag=Cousin%20Ricky

[Cousin Ricky] TiltedTorus 3.0: no regrets [3655 days 7 hours and 24 minutes ago]

Sun, 3 Apr 2016 21:25:01 GMT

The English language has allowed me to name a new macro by simply adding a
single letter to the name of the old, while conveying the same meaning.  In the
unlikely event that there exist any scene files that use TiltedTorus 2.0 or
2.0a, they will render unaltered with version 3.0

It also occurred to me that the lathe examples could be jazzed up with some uv
mapping, and so it is done.

http://lib.povray.org/searchcollection/index2.php?objectName=TiltedTorus&contributorTag=Cousin%20Ricky

[clipka] Re: Regrets [3658 days 16 hours and 8 minutes ago]

Thu, 31 Mar 2016 12:41:16 GMT

Am 29.03.2016 um 23:18 schrieb Cousin Ricky:
> On 2016-03-27 09:49 AM (-4), clipka wrote:
>> Version numbering best practices (such as the "semantic versioning"
>> scheme) would suggest that you call the new include file "TiltedTorus
>> 3.0" (the major version number increment indicating backward
>> incompatibilities), and archival best practices would suggest that you
>> upload it as a new file, rather than replacing the old one. This way,
>> anyone who for some reason cannot or does not want to change their scene
>> can still get hold of a compatible include file.
> 
> What do you mean by "upload it as a new file, rather than replacing the
> old one" in this context?  New versions of Object Collection modules do
> not erase the old versions, although no guarantee has been made that the
> old versions will remain available in perpetuity.

If old versions are automatically retained, then forget the "archival
best practices" part of what I said. I must confess that I'm not
familiar with the details of the object collection.

> One way for me to avoid the issue is to use a different name for the new
> lathe macro, and deprecate the old identifiers.

I'm not sure if I would do that. But yes, it would be the safest option
in terms of backward compatibility.

[Cousin Ricky] Re: Regrets [3660 days 7 hours and 30 minutes ago]

Tue, 29 Mar 2016 21:18:36 GMT

On 2016-03-27 09:49 AM (-4), clipka wrote:
> Version numbering best practices (such as the "semantic versioning"
> scheme) would suggest that you call the new include file "TiltedTorus
> 3.0" (the major version number increment indicating backward
> incompatibilities), and archival best practices would suggest that you
> upload it as a new file, rather than replacing the old one. This way,
> anyone who for some reason cannot or does not want to change their scene
> can still get hold of a compatible include file.

What do you mean by "upload it as a new file, rather than replacing the 
old one" in this context?  New versions of Object Collection modules do 
not erase the old versions, although no guarantee has been made that the 
old versions will remain available in perpetuity.

One way for me to avoid the issue is to use a different name for the new 
lathe macro, and deprecate the old identifiers.

[clipka] Re: Regrets [3662 days 14 hours and 59 minutes ago]

Sun, 27 Mar 2016 13:49:53 GMT

Am 27.03.2016 um 04:01 schrieb Cousin Ricky:
> Some months after I uploaded TiltedTorus 2.0a, I looked back on one of its
> features in horror.  In order to invoke the Sturmian root solver in
> TiltedTorus_Lathe(), I used a global parameter, rather than a macro argument!
> If I'd submitted this module as an assignment in one of my computer science
> classes, I'd get 20 points deducted just for that.
...
> This is easily fixed, but it would do something that I've never done in an
> Object Collection update (save AndroidRobot[1]): break older scenes.
> 
> Should I do it?  Older scenes could be quite easily updated, and I don't suppose
> many such scenes even exist.  I created this module in response to a request in
> p.general, and the OP ended up not using it anyway.

Version numbering best practices (such as the "semantic versioning"
scheme) would suggest that you call the new include file "TiltedTorus
3.0" (the major version number increment indicating backward
incompatibilities), and archival best practices would suggest that you
upload it as a new file, rather than replacing the old one. This way,
anyone who for some reason cannot or does not want to change their scene
can still get hold of a compatible include file.

[Thomas de Groot] Re: Regrets [3662 days 21 hours and 29 minutes ago]

Sun, 27 Mar 2016 07:19:50 GMT

On 27-3-2016 4:01, Cousin Ricky wrote:
> Some months after I uploaded TiltedTorus 2.0a, I looked back on one of its
> features in horror.

I think you can safely do it.


-- 
Thomas

[Cousin Ricky] Regrets [3663 days 2 hours and 44 minutes ago]

Sun, 27 Mar 2016 02:05:03 GMT

Some months after I uploaded TiltedTorus 2.0a, I looked back on one of its
features in horror.  In order to invoke the Sturmian root solver in
TiltedTorus_Lathe(), I used a global parameter, rather than a macro argument!
If I'd submitted this module as an assignment in one of my computer science
classes, I'd get 20 points deducted just for that.

That's quite a brain fart (though not nearly as bad as having totally unrelated
macro names and function formal parameters override local identifiers).

This is easily fixed, but it would do something that I've never done in an
Object Collection update (save AndroidRobot[1]): break older scenes.

Should I do it?  Older scenes could be quite easily updated, and I don't suppose
many such scenes even exist.  I created this module in response to a request in
p.general, and the OP ended up not using it anyway.

________________________
[1] AndroidRobot's initial incarnation was rather inflexible, and it didn't show
up in the default search anyway, so I figured the benefits to my changes would
outweigh any damage.

[LanuHum] Re: RC3Metal 1.2.1: blurred reflection speed-up [3664 days 5 hours and 59 minutes ago]

Fri, 25 Mar 2016 22:50:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:

>
> Scaling can be easily achieved this way:
>
> #declare T = RC3Metal_Galvanized_t (...)
> texture { T scale MyScale }
>
> Unfortunately, this syntax is not accepted for turbulence, so I will consider
> your suggestion.

One bald person (he was called Lenin) spoke:
"To study, to learn and to study once again..."
Thanks!   :))))))))

[Cousin Ricky] Re: RC3Metal 1.2.1: blurred reflection speed-up [3664 days 6 hours and 44 minutes ago]

Fri, 25 Mar 2016 22:05:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Thanks! Very Good! But...
> Update rc3metal.inc:
>
> #macro RC3Metal_Galvanized_t (c_Dull, c_Shiny, Dull, Shiny, Dark, Light, Shine,
> Turb, Scale)
>   #if (RC3M_Debug) #debug "RC3Metal_Galvanized_t()...\n" #end
>   texture
>   { crackle solid texture_map
>     { [0 RC3Metal (c_Shiny, Shiny, Light)]
>       [Shine RC3Metal (c_Dull, Dull, Light)]
>       [1 RC3Metal (c_Dull, Dull, Dark)]
>     }
>     turbulence Turb
>     scale Scale
>   }
> #end
>
> Scaling crackle is required surely!  :)

Scaling can be easily achieved this way:

#declare T = RC3Metal_Galvanized_t (...)
texture { T scale MyScale }

Unfortunately, this syntax is not accepted for turbulence, so I will consider
your suggestion.

[LanuHum] Re: RC3Metal 1.2.1: blurred reflection speed-up [3676 days 11 hours and 9 minutes ago]

Sun, 13 Mar 2016 17:40:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> I have improved the rendering speed of objects with blurred reflection and
> radiosity.  In order to see this improvement:
>
> - You must use macro RC3Metal_Blur() or RC3Metal_Normal_blur().
>   The improvement does not apply to macros RC3Metal_Blur_t() and
>   RC3Metal_Normal_blur_t().
>
> - You must use POV-Ray 3.7 or later for any significant speedup.
>
> Theoretically, there should be a slight speedup for non-radiosity and pre-3.7
> scenes, but said theoretical speedup is too insignificant to notice.
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=RC3Metal&contributorTag=Cousin%20Ricky

Thanks! Very Good! But...
Update rc3metal.inc:

#macro RC3Metal_Galvanized_t (c_Dull, c_Shiny, Dull, Shiny, Dark, Light, Shine,
Turb, Scale)
  #if (RC3M_Debug) #debug "RC3Metal_Galvanized_t()...\n" #end
  texture
  { crackle solid texture_map
    { [0 RC3Metal (c_Shiny, Shiny, Light)]
      [Shine RC3Metal (c_Dull, Dull, Light)]
      [1 RC3Metal (c_Dull, Dull, Dark)]
    }
    turbulence Turb
    scale Scale
  }
#end

Scaling crackle is required surely!  :)

[Cousin Ricky] RC3Metal 1.2.1: blurred reflection speed-up [3678 days 6 hours and 24 minutes ago]

Fri, 11 Mar 2016 22:25:00 GMT

I have improved the rendering speed of objects with blurred reflection and
radiosity.  In order to see this improvement:

- You must use macro RC3Metal_Blur() or RC3Metal_Normal_blur().
  The improvement does not apply to macros RC3Metal_Blur_t() and
  RC3Metal_Normal_blur_t().

- You must use POV-Ray 3.7 or later for any significant speedup.

Theoretically, there should be a slight speedup for non-radiosity and pre-3.7
scenes, but said theoretical speedup is too insignificant to notice.

http://lib.povray.org/searchcollection/index2.php?objectName=RC3Metal&contributorTag=Cousin%20Ricky

[clipka] Re: RoundEdge 1.3.1: elimination of torus artifact [3724 days 9 hours and 24 minutes ago]

Mon, 25 Jan 2016 19:25:14 GMT

Am 25.01.2016 um 19:15 schrieb Cousin Ricky:

> I almost immediately realized why my torus-cylinder merges showed this artifact,
> which is why I never reported this as a bug.  But bug or not, it is annoying, so
> it is fixed in RoundEdge 1.3.1.

... and it is also fixed (kind of, that is) in POV-Ray 3.7.1 ;)

You may want to change your RE__torus macro as follows:


#macro RE__torus (RMajor, rMinor, Use_merge)
  #if (RMajor * 2 < rMinor & Use_merge)
    #if (RoundEdge_Inc_Temp >= 3.7.1)
      torus { RMajor, rMinor merge }
    #else
      merge
      { difference
        { torus { RMajor, rMinor }
          sphere { 0, re_R }
        }
        sphere { 0, (re_R + rMinor) / 2 }
      }
    #end
  #else
    torus { RMajor, rMinor }
  #end
#end


Specifying the "merge" keyword after the major & minor radii of a torus
will cause interior surfaces of a spindle torus to be suppressed.

The "difference", "intersection" and "union" keywords also work there as
you might expect (though "union" is only included for completeness, as
it's the default anyway).

[Cousin Ricky] RoundEdge 1.3.1: elimination of torus artifact [3724 days 10 hours and 29 minutes ago]

Mon, 25 Jan 2016 18:20:00 GMT

See
http://news.povray.org/povray.general/message/%3C5682b65f%241%40news.povray.org%3E/

This artifact rears its ugly head when merging a torus and a cylinder into a
very fat discus-like object.  See p.b.i for an illustration.

I thought surely I had discovered this problem while I was fiddling with the
meniscus code for CoffeeMug in 2013.  But checking the dates on my test files,
it turns out I'd discovered it in 2008, a mere three days after starting work on
RoundEdge.  (I'm not too surprised at this recall failure; meat-based brains are
known to be unreliable.)

I almost immediately realized why my torus-cylinder merges showed this artifact,
which is why I never reported this as a bug.  But bug or not, it is annoying, so
it is fixed in RoundEdge 1.3.1.

http://lib.povray.org/searchcollection/index2.php?objectName=RoundEdge&contributorTag=Cousin%20Ricky

Why I didn't take steps to correct the problem in RoundEdge 1.0 is a mystery.
Another meat brain failure, perhaps?

[Mike Horvath] Re: Login ID [3727 days 6 hours and 6 minutes ago]

Fri, 22 Jan 2016 22:42:36 GMT

That's true. I am no longer using the Juno account.


Mike


On 1/22/2016 12:13 PM, Le_Forgeron wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Le 19/01/2016 07:16, Mike Horvath a Ã©crit :
>> I forgot my login ID and password. Is there any way to retrieve or
>> reset them?
>>
>>
>> Mike
>
> Yes, I can help you.
>
> It just seems you are not using the same email than the one that was
> used for confirmation.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iJwEAQEIAAYFAlaiYyQACgkQhKAm8mTpkW37MgP/dc6+rx7pJIq1ERPiT90g7nVI
> E/B7CohN7EKOClIUrv/f+y2dcJ/8SU2WkpjVo0oSAWfasCb7dpnY9hKU2A2u7dpe
> fI+fKPmoSlkIn7n4obIPSYA4aDTw+7Y6v3NX56K+YDmUS86GS+UuYDFUG395763J
> AzhCBx7NFcZ7bKJEdaY=
> =h297
> -----END PGP SIGNATURE-----
>

[Le Forgeron] Re: Login ID [3727 days 11 hours and 36 minutes ago]

Fri, 22 Jan 2016 17:13:09 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 19/01/2016 07:16, Mike Horvath a Ã©crit :
> I forgot my login ID and password. Is there any way to retrieve or
> reset them?
> 
> 
> Mike

Yes, I can help you.

It just seems you are not using the same email than the one that was
used for confirmation.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlaiYyQACgkQhKAm8mTpkW37MgP/dc6+rx7pJIq1ERPiT90g7nVI
E/B7CohN7EKOClIUrv/f+y2dcJ/8SU2WkpjVo0oSAWfasCb7dpnY9hKU2A2u7dpe
fI+fKPmoSlkIn7n4obIPSYA4aDTw+7Y6v3NX56K+YDmUS86GS+UuYDFUG395763J
AzhCBx7NFcZ7bKJEdaY=
=h297
-----END PGP SIGNATURE-----

[Mike Horvath] Login ID [3730 days 22 hours and 32 minutes ago]

Tue, 19 Jan 2016 06:16:48 GMT

I forgot my login ID and password. Is there any way to retrieve or reset 
them?


Mike

[Thomas de Groot] Re: Object Collection page issue (work around) [3747 days 20 hours and 49 minutes ago]

Sat, 2 Jan 2016 07:59:51 GMT

On 1-1-2016 19:54, StephenS wrote:
>
> Thomas de Groot posted in p.general
> news://news.povray.org:119/5677b275$1@news.povray.org
>
> There can be a problem using the search functions, scroll next page.
>
> As a temporary work around try using the "Thumbnails" way of listing the
> contents.
>
> Stephen S

Indeed. Good tip. Thanks!

-- 
Thomas

[StephenS] Object Collection page issue (work around) [3748 days 9 hours and 54 minutes ago]

Fri, 1 Jan 2016 18:55:06 GMT

Thomas de Groot posted in p.general
news://news.povray.org:119/5677b275$1@news.povray.org

There can be a problem using the search functions, scroll next page.

As a temporary work around try using the "Thumbnails" way of listing the 
contents.

Stephen S

[Cousin Ricky] Re: Licensing [3753 days 10 hours and 54 minutes ago]

Sun, 27 Dec 2015 17:55:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> My project requires bitmap images of text. The text is currently made
> using whatever fonts InkScape uses by default.

In that case, if Cyrvetic does not serve your purposes, then have a look at
these, and read the fine print very carefully:

https://en.wikipedia.org/wiki/DejaVu_fonts
http://dejavu-fonts.org/wiki/index.php?title=License

https://fedorahosted.org/liberation-fonts/
https://fedoraproject.org/wiki/Licensing:LiberationFontLicense?rd=Licensing/LiberationFontLicense

https://en.wikipedia.org/wiki/Droid_fonts
http://www.droidfonts.com/
http://www.apache.org/licenses/LICENSE-2.0 (for Droid)

And above all, remember that IANAL.

[Mike Horvath] Re: Licensing [3753 days 12 hours and 12 minutes ago]

Sun, 27 Dec 2015 16:37:07 GMT

On 12/27/2015 9:39 AM, Cousin Ricky wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> What about fonts? If we include a font with our project does it have to
>> be LGPL as well? Do you know of any nice LGPL sans serif fonts?
>
> If your project requires a proprietary font, my suggestion would be to list it
> as a prerequisite, and include in your documentation directions on how to obtain
> it.  The Object Collection uploader doesn't allow font files anyway.
>
> Arial, Trebuchet, and Verdana (Microsoft) though proprietary, are available for
> free.  Microsoft no longer has them available for download, but they let the cat
> out of the bag and they can't stuff it back in.  I would definitely NOT bundle
> these with an Object Collection project (even if the uploader allowed it), but
> anyone smart enough to write SDL should be able to find them on-line, in the
> extremely unlikely event that all three weren't already on their PC when they
> bought it.
>
> My GNU/Linux installation comes with a few nice font families, Liberation and
> Droid (both Ascender Corp.), and DejaVu.  The DejaVu and Liberation fonts come
> with a full set of condensed, bold, and italic sans serif variations.  Droid
> only has regular and bold.  All three have liberal licenses; there have been
> issues with Liberation, but as long as you're not uploading it for distribution,
> the issues are irrelevant.  My recommendation for these is the same as for the
> proprietary fonts: list them as prerequisites and give directions on how to
> obtain them.
>
>
>

My project requires bitmap images of text. The text is currently made 
using whatever fonts InkScape uses by default.


Mike

[Cousin Ricky] Re: Licensing [3753 days 14 hours and 4 minutes ago]

Sun, 27 Dec 2015 14:45:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> What about fonts? If we include a font with our project does it have to
> be LGPL as well? Do you know of any nice LGPL sans serif fonts?

If your project requires a proprietary font, my suggestion would be to list it
as a prerequisite, and include in your documentation directions on how to obtain
it.  The Object Collection uploader doesn't allow font files anyway.

Arial, Trebuchet, and Verdana (Microsoft) though proprietary, are available for
free.  Microsoft no longer has them available for download, but they let the cat
out of the bag and they can't stuff it back in.  I would definitely NOT bundle
these with an Object Collection project (even if the uploader allowed it), but
anyone smart enough to write SDL should be able to find them on-line, in the
extremely unlikely event that all three weren't already on their PC when they
bought it.

My GNU/Linux installation comes with a few nice font families, Liberation and
Droid (both Ascender Corp.), and DejaVu.  The DejaVu and Liberation fonts come
with a full set of condensed, bold, and italic sans serif variations.  Droid
only has regular and bold.  All three have liberal licenses; there have been
issues with Liberation, but as long as you're not uploading it for distribution,
the issues are irrelevant.  My recommendation for these is the same as for the
proprietary fonts: list them as prerequisites and give directions on how to
obtain them.

[Mike Horvath] Re: Licensing [3754 days 8 hours and 21 minutes ago]

Sat, 26 Dec 2015 20:27:42 GMT

On 12/25/2015 8:02 AM, Cousin Ricky wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> If the code is CC-LGPL, what about the images rendered using the code?
>> Use the same license?
>
> According to the README file, "You may use images that you generate using these
> files without restriction."
>
> There is at least one exception:  The AndroidRobot module depicts an image
> trademarked by The Google, which bears a Creative Commons attribution license.
>
>
>
>

What about fonts? If we include a font with our project does it have to 
be LGPL as well? Do you know of any nice LGPL sans serif fonts?


Mike

[Cousin Ricky] Re: Licensing [3755 days 15 hours and 44 minutes ago]

Fri, 25 Dec 2015 13:05:07 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> If the code is CC-LGPL, what about the images rendered using the code?
> Use the same license?

According to the README file, "You may use images that you generate using these
files without restriction."

There is at least one exception:  The AndroidRobot module depicts an image
trademarked by The Google, which bears a Creative Commons attribution license.

[Mike Horvath] Licensing [3755 days 22 hours and 29 minutes ago]

Fri, 25 Dec 2015 06:20:11 GMT

If the code is CC-LGPL, what about the images rendered using the code? 
Use the same license?


Mike

[Mike Horvath] Re: Ping SharkD: legal question about the Munsel... [3786 days 21 hours and 30 minutes ago]

Tue, 24 Nov 2015 07:19:13 GMT

On 11/23/2015 2:57 PM, Mike Horvath wrote:
> Just wanted to add that the "renotations" of the 1929 data are from 1949.
>
>
> Mike
>


1943 rather. Anyway, it might be safer to remove the item from the 
object collection.


Mike

[Cousin Ricky] Re: SphereSweep 1.2, with Bezier splines [3787 days and 17 minutes ago]

Tue, 24 Nov 2015 04:32:16 GMT

On 09/12/2015 09:38 AM, clipka wrote:
> Am 12.09.2015 um 02:21 schrieb Cousin Ricky:
>
>> Unlike the
>> curve sections of all the other spline types, BÃ©zier segments are not
>> logically tied to each other.  This necessitated handling BÃ©zier objects
>> separately from all the others, as well as writing new macros dedicated
>> to negotiating the splicing of curve segments when and only when the
>> segments are physically contiguous.
>
> Why not just require that the end point of one BÃ©zier segment is equal
> to the starting point of the next one?

It just occurred to me that I may have misinterpreted your question.  If 
it's why I don't disallow discontinuous segments, I just made a decision 
to allow maximum flexibility.

[Mike Horvath] Re: Ping SharkD: legal question about the Munsel... [3787 days 8 hours and 52 minutes ago]

Mon, 23 Nov 2015 19:56:41 GMT

On 12/19/2014 1:35 PM, Le_Forgeron wrote:
> Le 19/12/2014 18:20, Cousin Ricky a Ã©crit :
>> First of all, the Web page URL has changed:
>>
>>    http://www.rit.edu/cos/colorscience/rc_munsell_renotation.php
>>
>> But my main concern is RIT's terms of use.  According to these terms,
>> the contents of the Web site are for personal, noncommercial use only.
>> IANAL, but to me, these terms don't appear to be compatible with the
>> LGPL.  Do you have some assurance (preferably written) that the Munsell
>> data are not covered by these restrictions, or have you otherwise
>> contacted RIT about their use?
>
> But aren't 1929 data now in public domain ?
>  From 1909's law, 1929 would have gain a 28 years protection. Did they
> renewed it ? If yes, then the original date for public domain would have
> moved from 1985 to 2024.

Just wanted to add that the "renotations" of the 1929 data are from 1949.


Mike

[And] Re: SphereSweep 1.2, with Bezier splines [3858 days and 59 minutes ago]

Mon, 14 Sep 2015 03:50:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> In SphereSweep 1.2, the BÃ©zier spline is implemented for all the object
> macros except SphereSweep_Native().
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
>

congratulations.!

>
> I've recently discovered that the PointArrays module has BÃ©zier sphere
> sweep capability.  Previously, I had only noticed the lathe and prism
> features.  With all the talk about sphere sweeps lately, I'm surprised
> that Matthew (a.k.a. Blue Herring) never chimed in.  (Are you still
> around, Matthew?)  There is considerable overlap between the two
> modules, including variable radius capability.  Matthew seems to have
> approached the problems similarly to the way I did, although we use
> different user interfaces.  (And, you can check out the SDL for both
> modules, to see how straightforward it was to accommodate varying
> radii.)  I have focused more on sphere sweeps, and have provided more
> options for these than PointArrays does.  PointArrays, for its part, has
> more array manipulation capability.

Well, it is a good module indeed. Thanks.

[Cousin Ricky] Re: SphereSweep 1.2, with Bezier splines [3859 days 9 hours and 49 minutes ago]

Sat, 12 Sep 2015 19:00:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Why not just require that the end point of one BÃ©zier segment is equal
> to the starting point of the next one?

The criteria were obvious enough.  Loop control was another matter, and worse,
the solution differed depending on whether I was constructing the object out of
cones and spheres, blob components, or linear_spline sphere_sweeps.

[LanuHum] Re: SphereSweep 1.2, with Bezier splines [3859 days 13 hours and 24 minutes ago]

Sat, 12 Sep 2015 15:25:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > In the Blender it is possible to scale only control points.
> > At you
> > #declare Arm_def = array[4][3]
> > #declare Arm_rs = array[12]
> > Unclear, as to control it.
>
> Arm_def is not used as-is by Bezier algorithms.  It describes Bezier curves in a
> format that I find easier to control.  The format is described in the user
> manual.
>
> The macro SSwp_Bezier() converts Arm_def to Arm_pts.  Arm_pts is the
> one-dimensional array of control points that is in the form expected by Bezier
> algorithms.  If you look at the message window from a spheresweep_cockpit.pov
> render, you will see the Arm_pts array in its final form.
>
> Arm_rs is the array of the radii that correspond to the control points.

In vector graphics all curve bezier are provided as sequence of bezier-splines
(cairo, inkscape, blender).
One spline:
move_to (x, y) - control point 0
curve_to (x0, y0, x1, y1, x2, y2)
Where
x0, y0 - right handle control point 0
x1, y1 - left handle control point 1
x2, y2 - control point 1
That the user could transfer data from the editor to your macro, it is necessary
to follow the standard.
If the end of a spline 0 is the beginning of a spline 1
move_to (x, y)
curve_to (x0, y0, x1, y1, x2, y2)
curve_to (x3, y3, x4, y4, x5, y5)
curve_to (x6, y6, x7, y7, x8, y8)
curve_to (x9, y9, x10, y10, x11, y11)
If splines are broken off,
move_to (x, y)
curve_to (x0, y0, x1, y1, x2, y2)
move_to (x3, y3)
curve_to (x4, y4, x5, y5, x6, y6)

[clipka] Re: SphereSweep 1.2, with Bezier splines [3859 days 15 hours and 9 minutes ago]

Sat, 12 Sep 2015 13:39:32 GMT

Am 12.09.2015 um 02:21 schrieb Cousin Ricky:

> Unlike the
> curve sections of all the other spline types, BÃ©zier segments are not
> logically tied to each other.  This necessitated handling BÃ©zier objects
> separately from all the others, as well as writing new macros dedicated
> to negotiating the splicing of curve segments when and only when the
> segments are physically contiguous.

Why not just require that the end point of one BÃ©zier segment is equal
to the starting point of the next one?

[Cousin Ricky] Re: SphereSweep 1.2, with Bezier splines [3859 days 16 hours and 34 minutes ago]

Sat, 12 Sep 2015 12:15:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> In the Blender it is possible to scale only control points.
> At you
> #declare Arm_def = array[4][3]
> #declare Arm_rs = array[12]
> Unclear, as to control it.

Arm_def is not used as-is by Bezier algorithms.  It describes Bezier curves in a
format that I find easier to control.  The format is described in the user
manual.

The macro SSwp_Bezier() converts Arm_def to Arm_pts.  Arm_pts is the
one-dimensional array of control points that is in the form expected by Bezier
algorithms.  If you look at the message window from a spheresweep_cockpit.pov
render, you will see the Arm_pts array in its final form.

Arm_rs is the array of the radii that correspond to the control points.

[LanuHum] Re: SphereSweep 1.2, with Bezier splines [3859 days 20 hours and 14 minutes ago]

Sat, 12 Sep 2015 08:35:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> In SphereSweep 1.2, the BÃ©zier spline is implemented for all the object
> macros except SphereSweep_Native().
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
>

In the Blender it is possible to scale only control points.
At you
#declare Arm_def = array[4][3]
#declare Arm_rs = array[12]
Unclear, as to control it.

[Cousin Ricky] SphereSweep 1.2, with Bezier splines [3860 days 4 hours and 27 minutes ago]

Sat, 12 Sep 2015 00:21:40 GMT

http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky

The new include file is nearly twice the size of the previous version.
The actual BÃ©zier calculation is done in macro SSwp__Bezier_calc(), and
is remarkably simple. But, as I have mentioned before, integrating this
calculation into functional objects was not straightforward. The bulk
of the new code is for managing the different segments. Unlike the
curve sections of all the other spline types, BÃ©zier segments are not
logically tied to each other. This necessitated handling BÃ©zier objects
separately from all the others, as well as writing new macros dedicated
to negotiating the splicing of curve segments when and only when the
segments are physically contiguous.

My calculation uses brute force rather than the single reduced formula
with all the pow() calls. This was because my ability to concentrate is
so bad nowadays that I just gave up on trying to figure it out. I
figured that the internal math of the reduced formula would be more
complicated anyway. Had I known how simple the final formula was, and
recalled Clipka's observation that the complexity of the SDL always
trumps the math, I would have taken that route. However, the parse time
is so short, there would be little difference either way.

If you examine the SDL code, you will notice that all of the local
variables are prefixed with sswp_. This would seem redundant with the
#local directives, and makes the code rather hard to follow. The reason
for this policy is to circumvent an unfortunate POV-Ray namespace scope
leakage; it is a requirement for Object Collection compliance level 3.
(Not all "compliant" modules follow this rule, because it wasn't
instituted until the scope leakage was discovered, which was well after
the creation of the Object Collection.)

I've recently discovered that the PointArrays module has BÃ©zier sphere
sweep capability. Previously, I had only noticed the lathe and prism
features. With all the talk about sphere sweeps lately, I'm surprised
that Matthew (a.k.a. Blue Herring) never chimed in. (Are you still
around, Matthew?) There is considerable overlap between the two
modules, including variable radius capability. Matthew seems to have
approached the problems similarly to the way I did, although we use
different user interfaces. (And, you can check out the SDL for both
modules, to see how straightforward it was to accommodate varying
radii.) I have focused more on sphere sweeps, and have provided more
options for these than PointArrays does. PointArrays, for its part, has
more array manipulation capability.

[Cousin Ricky] Re: SphereSweep 1.1, with B-splines [3864 days 5 hours and 18 minutes ago]

Mon, 7 Sep 2015 23:31:18 GMT

On 09/05/2015 10:35 AM, And wrote:
> Well, I wondering what the radius formula do others like you apply? I think that
> it can be the similar form as the bezier curve in a sense:
>
> r = r0*pow(1-t,3) + r1*pow(1-t,2)*t + r2*(1-t)*pow(t,2) + r3*pow(t,3)
> 0 <= t <= 1
> That is, four points and four radii decide a segment.
> Wondering how do you think?

I am treating the radii simply as a 4th vector component, just as with 
all the other spline types.  This seems consistent with how POV-Ray 
determines the radii of B-spline and cubic sphere_sweeps.

SphereSweep 1.2 is in testing phase right now.  I had to create a test 
suite just for the Bézier sphere sweep, as the possibility of disjointed 
segments made them trickier to implement than the other spline types.  I 
am still working on the test cases for variable radius sweeps.

As it turns out, I did not need your code, so there is no concern about 
licensing.

[And] Re: SphereSweep 1.1, with B-splines [3866 days 14 hours and 9 minutes ago]

Sat, 5 Sep 2015 14:40:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> > >
> > > I am moving BÃ©zier spline up on the priority list for a future
version.
> > >   However, implementation will not be straightforward, due to the
> > > possibility of disjointed spline segments.
> >
> >
> > Hello, Cousin Ricky, I'm not sure that you have the plane to make the Bezier
> > spline sphere sweep macros during the next weeks. Basically I've written one, at
> >
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.55d0c6ee48951ba98423d9aa0%40news.povray.org%3E/
> >
> > And maybe I will write a more general version that put a 'merge' feature and the
> > variant radius feature on it. We can discuss it.
>
> I began work on the Bezier sphere sweep last week.  The Bezier calculation macro
> is already complete, and accommodates variable radii.  The hard part is to
> integrate the Bezier calculation into my existing macros.
>
> I will take a look at your file.  Please be aware that the Object Collection
> requires the GNU Lesser General Public License (LGPL) 2.1, so if I end up
> borrowing any of your code, you will need to consent to offering that license
> before I can upload it.  The LGPL is just about the most generous license out
> there, leaving you with little more than token ownership of your intellectual
> property, so you'll want to read it very carefully before consenting to offer
> it.

Ok. Thank you very much.

Well, I wondering what the radius formula do others like you apply? I think that
it can be the similar form as the bezier curve in a sense:

r = r0*pow(1-t,3) + r1*pow(1-t,2)*t + r2*(1-t)*pow(t,2) + r3*pow(t,3)
0 <= t <= 1
That is, four points and four radii decide a segment.
Wondering how do you think?

[Cousin Ricky] Re: SphereSweep 1.1, with B-splines [3868 days 9 hours and 44 minutes ago]

Thu, 3 Sep 2015 19:05:00 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> >
> > I am moving BÃ©zier spline up on the priority list for a future version.
> >   However, implementation will not be straightforward, due to the
> > possibility of disjointed spline segments.
>
>
> Hello, Cousin Ricky, I'm not sure that you have the plane to make the Bezier
> spline sphere sweep macros during the next weeks. Basically I've written one, at
>
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.55d0c6ee48951ba98423d9aa0%40news.povray.org%3E/
>
> And maybe I will write a more general version that put a 'merge' feature and the
> variant radius feature on it. We can discuss it.

I began work on the Bezier sphere sweep last week.  The Bezier calculation macro
is already complete, and accommodates variable radii.  The hard part is to
integrate the Bezier calculation into my existing macros.

I will take a look at your file.  Please be aware that the Object Collection
requires the GNU Lesser General Public License (LGPL) 2.1, so if I end up
borrowing any of your code, you will need to consent to offering that license
before I can upload it.  The LGPL is just about the most generous license out
there, leaving you with little more than token ownership of your intellectual
property, so you'll want to read it very carefully before consenting to offer
it.

[Le Forgeron] Re: Bad HTTP-headers in detail pages [3868 days 12 hours and 1 minute ago]

Thu, 3 Sep 2015 16:47:44 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 03/09/2015 12:06, Warp a Ã©crit :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> I will say: It is known, and was done on purpose to fight
>> spam-bot.
> 
> I don't understand how returning a content-type of text/plain
> instead of text/html helps fighting any spam-bots.
> 
Well... it turn the html injection into useless text, disabling links
the spammer wanted to add. (might be tied to robot, search engine and
references for scoring)

That's my understanding, I came after such change, I did not suggest it.

Anyway, I cannot change that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXoea4ACgkQhKAm8mTpkW05hQP9EA1iXx+0J3SxpZuOQoVfeRMV
hT/ONLceOWPPxvglwD7tf8euysjMyzXJlOltOSNmxicfAGlu2PgPFg4OZNsg9jGQ
exqxvaolENj7jhkFPfHC2YIZu4i/2DefwqgyrmPLAxx2flEp8lQdpbM7vexupuTQ
QZ6z8/7IIkKznlqCGFk=
=ND5o
-----END PGP SIGNATURE-----

[Warp] Re: Bad HTTP-headers in detail pages [3868 days 18 hours and 43 minutes ago]

Thu, 3 Sep 2015 10:06:13 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> I will say: It is known, and was done on purpose to fight spam-bot.

I don't understand how returning a content-type of text/plain instead
of text/html helps fighting any spam-bots.

-- 
                                                          - Warp

[And] Re: SphereSweep 1.1, with B-splines [3869 days and 19 minutes ago]

Thu, 3 Sep 2015 04:30:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
> > "LanuHum" <Lan### [at] yandexru> wrote:
> > > Cousin Ricky <ric### [at] yahoocom> wrote:
> > > >
> > > > I am moving Bezier spline up on the priority list for a future version.
> > > >   However, implementation will not be straightforward, due to the
> > > > possibility of disjointed spline segments.
> > >
> > > It is interesting! :)
> >
> > Hello, LanuHum.
> > I'm sorry. I didn't see this message by you:
> >
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.55d0c6ee48951ba98423d9aa0%40news.povray.org%3E/
> >
> > And I've replied it.
>
> I control events. I already included your macro in the exporter. It is good that
> it compact and available to understanding. I wait for change of radius along a
> curve. :)
> If the macro from Cousin Ricky has interesting features, I also want them to
> see.:)

Well.

[LanuHum] Re: SphereSweep 1.1, with B-splines [3869 days 10 hours and 14 minutes ago]

Wed, 2 Sep 2015 18:35:01 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> > >
> > > I am moving Bezier spline up on the priority list for a future version.
> > >   However, implementation will not be straightforward, due to the
> > > possibility of disjointed spline segments.
> >
> > It is interesting! :)
>
> Hello, LanuHum.
> I'm sorry. I didn't see this message by you:
>
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.55d0c6ee48951ba98423d9aa0%40news.povray.org%3E/
>
> And I've replied it.

I control events. I already included your macro in the exporter. It is good that
it compact and available to understanding. I wait for change of radius along a
curve. :)
If the macro from Cousin Ricky has interesting features, I also want them to
see.:)

[And] Re: SphereSweep 1.1, with B-splines [3870 days and 44 minutes ago]

Wed, 2 Sep 2015 04:05:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> >
> > I am moving Bezier spline up on the priority list for a future version.
> >   However, implementation will not be straightforward, due to the
> > possibility of disjointed spline segments.
>
> It is interesting! :)

Hello, LanuHum.
I'm sorry. I didn't see this message by you:
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.55d0c6ee48951ba98423d9aa0%40news.povray.org%3E/

And I've replied it.

[And] Re: SphereSweep 1.1, with B-splines [3870 days and 59 minutes ago]

Wed, 2 Sep 2015 03:50:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> In SphereSweep 1.1, the B-spline has been implemented for the
> sphere_sweep alternatives.  It can now be used with all of the object
> macros, not just with SphereSweep_Native() as in version 1.0.
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
>
> I am moving BÃ©zier spline up on the priority list for a future version.
>   However, implementation will not be straightforward, due to the
> possibility of disjointed spline segments.

Hello, Cousin Ricky, I'm not sure that you have the plane to make the Bezier
spline sphere sweep macros during the next weeks. Basically I've written one, at
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.55d0c6ee48951ba98423d9aa0%40news.povray.org%3E/

And maybe I will write a more general version that put a 'merge' feature and the
variant radius feature on it. We can discuss it.

[LanuHum] Re: SphereSweep 1.1, with B-splines [3873 days 20 hours and 59 minutes ago]

Sat, 29 Aug 2015 07:50:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> I am moving Bezier spline up on the priority list for a future version.
>   However, implementation will not be straightforward, due to the
> possibility of disjointed spline segments.

It is interesting! :)

[Cousin Ricky] SphereSweep 1.1, with B-splines [3874 days 5 hours and 33 minutes ago]

Fri, 28 Aug 2015 23:15:52 GMT

In SphereSweep 1.1, the B-spline has been implemented for the 
sphere_sweep alternatives.  It can now be used with all of the object 
macros, not just with SphereSweep_Native() as in version 1.0.

http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky

I am moving BÃ©zier spline up on the priority list for a future version. 
  However, implementation will not be straightforward, due to the 
possibility of disjointed spline segments.

[Le Forgeron] Re: Bad HTTP-headers in detail pages [3880 days 14 hours and 32 minutes ago]

Sat, 22 Aug 2015 14:17:18 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 22/08/2015 10:44, Michael Scharrer a Ã©crit :
> The detail pages for objects are re served with bad http headers 
> which causes them to be rendered as text files. Basically the html
>  source is shown. Example: 
> http://lib.povray.org/collection/roundedge/cousin%20ricky%201.3/rounde
dge.html
>
>
>
> 
The cause seems to be this line in the http header: "Content-Type:
> text/plain" Which should instead be "Content-Type: text/html" as is
> the case with all other pages on povray.org
> 
> This is how it looks for me: https://i.imgur.com/OSQBQjZ.png
> 

I will say: It is known, and was done on purpose to fight spam-bot.

The html file is rendered fine when looking at the local file, but not
on the server.

As stated already (2014-09-03), it's a shame, and would Internet be a
nicer place it wouldn't be so.

My best hint, but not a fix : have a look at

http://stackoverflow.com/questions/4807132/view-as-mime-type-in-chrome-o
r-firefox

> http://stackoverflow.com/questions/4807132/view-as-mime-type-in-chrome
- -or-firefox
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXYhG0ACgkQhKAm8mTpkW1hNAQAqlMTkolBLcaV9o2f8Uwsk1bR
KYI/7qiGIxSvUtkjEd2eSSIvzpCKoJLH+AXLwBNa3QBwQUBofAxTipyNnfdpD7GG
wGSYWtsvfTba4/w8ZLEKYYFGSWbODnxFUG2ZfdNoZlzAr0acQjbQne5W/MVSMcl4
j1Qq60kT7d5fD1GtvpY=
=Ydci
-----END PGP SIGNATURE-----

[Michael Scharrer] Bad HTTP-headers in detail pages [3880 days 20 hours and 4 minutes ago]

Sat, 22 Aug 2015 08:45:01 GMT

The detail pages for objects are re served with bad http headers which causes
them to be rendered as text files. Basically the html source is shown. Example:
http://lib.povray.org/collection/roundedge/cousin%20ricky%201.3/roundedge.html

The cause seems to be this line in the http header:
    "Content-Type: text/plain"
Which should instead be
    "Content-Type: text/html"
as is the case with all other pages on povray.org

This is how it looks for me:
https://i.imgur.com/OSQBQjZ.png


Michael Scharrer, https://mscharrer.net

[Le Forgeron] Re: The registration page is down. [3883 days 9 hours and 26 minutes ago]

Wed, 19 Aug 2015 19:22:48 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 19/08/2015 15:06, Michael Scharrer a Ã©crit :
> Hi,
> 
> I can't seem to register as a new user for the object collection.
> 
> http://lib.povray.org/members/register/
> 

IIRC, it was disabled due to a spam attack a long time ago.

> Does anyone here know how to get an account.
> 
Yep, I can create it manually for you. if you email me the details
(and once created, the first thing you do is to change
the dummy weak password I will have put in it).

You can use my public key on that email address (look at the sender of
this message) if you want. It's on the various key-servers (if you
know what I'm talking about, you know them).

I need (same as for the registration form):
* An email address to validate the registration (not displayed on site)
* A nickname
* First name & Surname
* Country of residence

If you have additional info (website, public email...) , you can
update your profile once created.

The login has to be a 6 digits value, some are already used, but I
guess you can have a bit of a choice on that too.

Best regards.


> I have quite a few things to upload.
> 
> 
Give me about 28 hours to process your registration. (I do not want to
perform such thing when tired)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXU14gACgkQhKAm8mTpkW3q1QP/ZJUFAXr+OITKO1dhRsV+Y23W
obCWTuLVWvURKhoA9jCapKzovl8EM8DJsV3kums8FI0h4GSetD0OIDeRCkjfxFsE
vXgRSOO6gkf05XNzcjj54jEDp5+H2/5Vzff8MuDnf98BfEdqNaftpqMKiBAKJXAJ
GQD98FUaZGudoX/fmm0=
=3WOu
-----END PGP SIGNATURE-----

[Michael Scharrer] The registration page is down. [3883 days 15 hours and 39 minutes ago]

Wed, 19 Aug 2015 13:10:06 GMT

Hi,

I can't seem to register as a new user for the object collection.

http://lib.povray.org/members/register/

Does anyone here know how to get an account.

I have quite a few things to upload.

[Cousin Ricky] Re: Space 1999 - Povray Collectionobjet "Eagle" ... [3888 days 3 hours and 59 minutes ago]

Sat, 15 Aug 2015 00:50:08 GMT

On 2015-28-06 09:17 AM (-4), Albun wrote:
> I just want to know the Ko of the collection objet "Eagle" at this place :
>
http://lib.povray.org/searchcollection/download.php?objectName=Eagle&contributorTag=chrisb&version=1.0
>
> I try to download it, but up to 1 Mo i cant get anything...

I had no trouble downloading it.

The module will fail on operating systems with case-sensitive file 
names, but that is easily fixed.  It should run without alteration on 
Microsoft Windows.

[Albun] Space 1999 - Povray Collectionobjet "Eagle" and ... [3935 days 15 hours and 29 minutes ago]

Sun, 28 Jun 2015 13:20:01 GMT

Hi,

I just want to know the Ko of the collection objet "Eagle" at this place :
http://lib.povray.org/searchcollection/download.php?objectName=Eagle&contributorTag=chrisb&v

ersion=1.0

I try to download it, but up to 1 Mo i cant get anything...

If there is fan who know an Alpha Moonbase Pov model.. thank for responding to
this message.

(I wrote a short story, and "look" for a soft animation)

Thanks

Albun

[Cousin Ricky] Bug in Caption is fixed [3963 days 5 hours and 21 minutes ago]

Sun, 31 May 2015 23:27:36 GMT

Oops!

It appears that passing a color as the Emission argument causes a parse 
error.  This has been corrected in version 1.0.1.

http://lib.povray.org/searchcollection/index2.php?objectName=Caption&contributorTag=Cousin%20Ricky

[clipka] Re: 3D Loop [3968 days 12 hours and 29 minutes ago]

Tue, 26 May 2015 16:20:04 GMT

Am 26.05.2015 um 17:53 schrieb Le_Forgeron:

>>> Changing the default right vector (even to something like
>>> image_width:image_height ratio, assuming square pixel
>>> everywhere) would only have one sure effect: break every
>>> historical scenes. Without providing 100% satisfaction to all
>>> users. Better not move.
>>
>> I totally agree - except when it comes to defaulting to square
>> pixels, which /does/ make sense nowadays; after all, that's what
>> any reasonable image handling software defaults to as well if the
>> input image material provides no embedded resolution information.
>>
>
> Yep... until you want to make a DVD (none of NTSC and PAL have square
> pixels...)

(Actually NTSC and PAL don't have any pixels at all; they just have 
contiguous scan lines with a specified maximum signal frequency. But I 
guess you're right about NTSC/PAL compatible DVD content. ;))

Even so, I'd expect that even contemporary professional or 
semi-professional video editing software will presume input images to 
have square pixels - unless explicitly told otherwise by the image 
header, the user, or the software administrator.

Also, when you export a PAL or NTSC DVD movie sequence as a series of 
images, I'd expect any sane video handling software to write them in a 
square-pixel format, even when additional resolution information is 
written to the image header. (Again, unless told otherwise of course)

[Le Forgeron] Re: 3D Loop [3968 days 12 hours and 55 minutes ago]

Tue, 26 May 2015 15:53:57 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 26/05/2015 17:41, clipka a Ã©crit :
> Am 25.05.2015 um 08:49 schrieb Le_Forgeron:
> 
>> Le 24/05/2015 22:08, Lars Rohwedder a Ã©crit :
> [...]
>>> That was _not_ my question. I asked when 16:9 will become the 
>>> _default_ in Povray so such scaling of the right vector
>>> becomes unnecessary. oO
>>> 
>>> Lars R.
>>> 
>> Unnecessary for you... my screen are 1920x1200, I would need
>> 16:10.
>> 
>> Changing the default right vector (even to something like 
>> image_width:image_height ratio, assuming square pixel
>> everywhere) would only have one sure effect: break every
>> historical scenes. Without providing 100% satisfaction to all
>> users. Better not move.
> 
> I totally agree - except when it comes to defaulting to square
> pixels, which /does/ make sense nowadays; after all, that's what
> any reasonable image handling software defaults to as well if the
> input image material provides no embedded resolution information.
> 

Yep... until you want to make a DVD (none of NTSC and PAL have square
pixels...)

> 
>> And guess what: 4K screens are coming... and there is at least 5 
>> different resolution under the name 4K, none with exactly the
>> same ratio ..
>> 
>> So far:
>> 
>> * 4096 x 2160 ( 256:135) [DCI native] * 3840 x 2160 ( 16:9 )
>> [UHD-1] * 5120 x 2160 ( 21:9 ) [UWT] * 5120 x 3200 ( 16:10 )
>> [WHXGA] * 4096 x 1716 ( 2.39: 1 ) [DCI cinemascope cropped] *
>> 3996 x 2160 ( 1.85: 1 ) [DCI flat cropped]
> 
> (Um... that looks more like 8K to me... or am I missing
> something?)

4K is about the width.
To be compared to camera sensor which are sold by millions of pixels
(2 millions... 10 millions... 40 millions... none advertising
aspect-ratio): marketing is all about getting people confused...
especially after selling TV screen as 720i, 720p, 1080p... where it
was the height, not the width... a delight of confusion.

8K varies from 7680 to 10080 pixels for width.

> 
> It might be worth noting that of all those aspect ratios, 16:10 is 
> closest to the famous Golden Ratio (1.618...:1), which has been 
> considered an aesthetically superior ratio for literally thousands
> of years.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVklxcACgkQhKAm8mTpkW1yBAQA1ROThtqNUg/83u6qzY0SXuA4
eTy8RFJSwiAKgJ78+TafHlXZ9286aMKMZy6iG7WLqy5SOyvH/fwlmkM1cCZ+t73y
K9EFe7K+8SXts9/qpJ5Fr/EAS290iD1B3ZJ+N05e/nDJwg5ot9eB5iMOxirmcdrI
RP95Rx6MLwgZauFVOOg=
=lWmQ
-----END PGP SIGNATURE-----

[clipka] Re: 3D Loop [3968 days 13 hours and 8 minutes ago]

Tue, 26 May 2015 15:40:57 GMT

Am 25.05.2015 um 08:49 schrieb Le_Forgeron:

> Le 24/05/2015 22:08, Lars Rohwedder a Ã©crit :
[...]
>> That was _not_ my question. I asked when 16:9 will become the
>> _default_ in Povray so such scaling of the right vector becomes
>> unnecessary. oO
>>
>> Lars R.
>>
> Unnecessary for you... my screen are 1920x1200, I would need 16:10.
>
> Changing the default right vector (even to something like
> image_width:image_height ratio, assuming square pixel everywhere)
> would only have one sure effect: break every historical scenes.
> Without providing 100% satisfaction to all users. Better not move.

I totally agree - except when it comes to defaulting to square pixels, 
which /does/ make sense nowadays; after all, that's what any reasonable 
image handling software defaults to as well if the input image material 
provides no embedded resolution information.


> And guess what: 4K screens are coming... and there is at least 5
> different resolution under the name 4K, none with exactly the same ratio
> ..
>
> So far:
>
>   * 4096 x 2160 ( 256:135) [DCI native]
>   * 3840 x 2160 ( 16:9 ) [UHD-1]
>   * 5120 x 2160 ( 21:9 ) [UWT]
>   * 5120 x 3200 ( 16:10 ) [WHXGA]
>   * 4096 x 1716 ( 2.39: 1 ) [DCI cinemascope cropped]
>   * 3996 x 2160 ( 1.85: 1 ) [DCI flat cropped]

(Um... that looks more like 8K to me... or am I missing something?)

It might be worth noting that of all those aspect ratios, 16:10 is 
closest to the famous Golden Ratio (1.618...:1), which has been 
considered an aesthetically superior ratio for literally thousands of years.

[Le Forgeron] Re: 3D Loop [3969 days 21 hours and 59 minutes ago]

Mon, 25 May 2015 06:49:44 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 24/05/2015 22:08, Lars Rohwedder a Ã©crit :
> Am 22.05.2015 um 08:52 schrieb And:
>> Lars Rohwedder <rok### [at] gmxde> wrote:
>>> 
>>> Oh, when will 16:9 aspect ratio will be the default in Povray?
>>> ;-)
>>> 
>>> L.
>> 
>> camera { location  <-1.4, 1.0 ,1.4> right     16/9*x       //
>> 16:9 look_at   <0.0 , 0.0 , 0.5> }
> 
> What do you want to do me with that snippet?
> 
> I do know how to adjust the camera to render 16:9 images in
> Povray.
> 
> That was _not_ my question. I asked when 16:9 will become the
> _default_ in Povray so such scaling of the right vector becomes
> unnecessary. oO
> 
> Lars R.
> 
Unnecessary for you... my screen are 1920x1200, I would need 16:10.

Changing the default right vector (even to something like
image_width:image_height ratio, assuming square pixel everywhere)
would only have one sure effect: break every historical scenes.
Without providing 100% satisfaction to all users. Better not move.

And guess what: 4K screens are coming... and there is at least 5
different resolution under the name 4K, none with exactly the same ratio
.

So far:

 * 4096 x 2160 ( 256:135) [DCI native]
 * 3840 x 2160 ( 16:9 ) [UHD-1]
 * 5120 x 2160 ( 21:9 ) [UWT]
 * 5120 x 3200 ( 16:10 ) [WHXGA]
 * 4096 x 1716 ( 2.39: 1 ) [DCI cinemascope cropped]
 * 3996 x 2160 ( 1.85: 1 ) [DCI flat cropped]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVixgoACgkQhKAm8mTpkW1HfgP7B8G2YKrRboyCWKJYiQ07jAZF
uVgAwANufZEaWmv3WqG8HxQKUnEkiv9LZsrr0/evrPFko2kPuCVW7FAV/2aHn4tG
cw02JVNiky4SHta90MRCIsXuBtmT77CKG7fFA7F/sn93q25ebmgD3jdQRWrVVCdi
80kSEC3dg2c6SWp2JAU=
=5JrD
-----END PGP SIGNATURE-----

[Lars Rohwedder] Re: 3D Loop [3970 days 8 hours and 41 minutes ago]

Sun, 24 May 2015 20:08:10 GMT

Am 22.05.2015 um 08:52 schrieb And:
> Lars Rohwedder <rok### [at] gmxde> wrote:
>>
>> Oh, when will 16:9 aspect ratio will be the default in Povray? ;-)
>>
>> L.
> 
> camera {
>     location  <-1.4, 1.0 ,1.4>
>     right     16/9*x       // 16:9
>     look_at   <0.0 , 0.0 , 0.5>
> }

What do you want to do me with that snippet?

I do know how to adjust the camera to render 16:9 images in Povray.

That was _not_ my question. I asked when 16:9 will become the _default_
in Povray so such scaling of the right vector becomes unnecessary. oO

Lars R.

[And] Re: 3D Loop [3972 days 21 hours and 54 minutes ago]

Fri, 22 May 2015 06:55:01 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:
>
> Oh, when will 16:9 aspect ratio will be the default in Povray? ;-)
>
> L.

camera {
    location  <-1.4, 1.0 ,1.4>
    right     16/9*x       // 16:9
    look_at   <0.0 , 0.0 , 0.5>
}

[LanuHum] Re: 3D Loop [3975 days 11 hours and 39 minutes ago]

Tue, 19 May 2015 17:10:00 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:
> Am 15.05.2015 um 20:18 schrieb LanuHum:
> > Example:
> >
> > // POV-Ray scene. It is created in the Blender-2.74
> >
> > […]
>
> Nice one. But there are quite sharp curves at the transition between the
> straight and the curved parts of the loop (marked read on the attached
> image)
>
> >
> >   right <-1.7777777777777777, 0, 0>
> >   up <0, 1, 0>
>
> Oh, when will 16:9 aspect ratio will be the default in Povray? ;-)
>
> L.

#version 3.7;

global_settings {
}
background {rgbt<0.00971, 0.271, 0.985, 0>}

#declare Default_texture = pigment {rgb 0.8}

#declare data_Torus_Knot_001_orig =
union {
    sphere_sweep { cubic_spline 83,
        <0.1889,-3.04,-0.7471>,0.565,
        <-0.1152,-2.87,-0.842>,0.565,
        <-0.3964,-2.646,-0.8663>,0.565,
        <-0.6436,-2.379,-0.8232>,0.565,
        <-0.8529,-2.076,-0.7224>,0.565,
        <-1.026,-1.743,-0.5749>,0.565,
        <-1.164,-1.381,-0.3898>,0.565,
        <-1.267,-0.9939,-0.1751>,0.565,
        <-1.332,-0.5868,0.06163>,0.565,
        <-1.353,-0.1668,0.3122>,0.565,
        <-1.326,0.2574,0.5671>,0.565,
        <-1.246,0.6765,0.8154>,0.565,
        <-1.11,1.083,1.045>,0.565,
        <-0.9191,1.468,1.241>,0.565,
        <-0.6758,1.828,1.387>,0.565,
        <-0.3872,2.154,1.47>,0.565,
        <-0.06428,2.436,1.479>,0.565,
        <0.2778,2.662,1.413>,0.565,
        <0.6228,2.823,1.277>,0.565,
        <0.9578,2.916,1.086>,0.565,
        <1.274,2.943,0.854>,0.565,
        <1.566,2.907,0.5949>,0.565,
        <1.83,2.812,0.3217>,0.565,
        <2.06,2.661,0.04721>,0.565,
        <2.253,2.456,-0.2153>,0.565,
        <2.402,2.202,-0.4518>,0.565,
        <2.502,1.903,-0.6472>,0.565,
        <2.546,1.569,-0.7864>,0.565,
        <2.532,1.217,-0.858>,0.565,
        <2.46,0.8624,-0.859>,0.565,
        <2.335,0.5193,-0.7955>,0.565,
        <2.162,0.1922,-0.6779>,0.565,
        <1.945,-0.1188,-0.5169>,0.565,
        <1.687,-0.4137,-0.3212>,0.565,
        <1.391,-0.6896,-0.09828>,0.565,
        <1.06,-0.9399,0.1441>,0.565,
        <0.6969,-1.156,0.3972>,0.565,
        <0.3079,-1.329,0.6512>,0.565,
        <-0.1013,-1.452,0.8947>,0.565,
        <-0.5249,-1.518,1.114>,0.565,
        <-0.9566,-1.526,1.296>,0.565,
        <-1.389,-1.476,1.423>,0.565,
        <-1.81,-1.372,1.482>,0.565,
        <-2.205,-1.217,1.465>,0.565,
        <-2.554,-1.021,1.374>,0.565,
        <-2.846,-0.7931,1.219>,0.565,
        <-3.072,-0.5433,1.013>,0.565,
        <-3.231,-0.2789,0.77>,0.565,
        <-3.325,-0.005833,0.5048>,0.565,
        <-3.352,0.2704,0.2297>,0.565,
        <-3.315,0.5444,-0.0423>,0.565,
        <-3.212,0.8102,-0.2978>,0.565,
        <-3.045,1.061,-0.5223>,0.565,
        <-2.816,1.288,-0.7005>,0.565,
        <-2.532,1.48,-0.8181>,0.565,
        <-2.208,1.628,-0.8661>,0.565,
        <-1.858,1.726,-0.8446>,0.565,
        <-1.495,1.772,-0.7617>,0.565,
        <-1.122,1.77,-0.6286>,0.565,
        <-0.7421,1.723,-0.4552>,0.565,
        <-0.3564,1.633,-0.2495>,0.565,
        <0.02999,1.501,-0.01925>,0.565,
        <0.4091,1.324,0.2277>,0.565,
        <0.7709,1.103,0.4823>,0.565,
        <1.105,0.8383,0.7341>,0.565,
        <1.403,0.5314,0.9713>,0.565,
        <1.657,0.1851,1.18>,0.565,
        <1.863,-0.1956,1.345>,0.565,
        <2.019,-0.6024,1.45>,0.565,
        <2.12,-1.022,1.485>,0.565,
        <2.164,-1.437,1.443>,0.565,
        <2.15,-1.828,1.329>,0.565,
        <2.081,-2.18,1.155>,0.565,
        <1.962,-2.485,0.9351>,0.565,
        <1.798,-2.737,0.6835>,0.565,
        <1.596,-2.937,0.4135>,0.565,
        <1.36,-3.08,0.138>,0.565,
        <1.095,-3.165,-0.13>,0.565,
        <0.8061,-3.188,-0.3768>,0.565,
        <0.5008,-3.147,-0.5876>,0.565,
        <0.1889,-3.04,-0.7471>,0.565,
        <-0.1152,-2.87,-0.842>,0.565,
        <-0.3964,-2.646,-0.8663>,0.565
    }
    texture {Default_texture}
}
object { data_Torus_Knot_001_orig
matrix <0.877638, -0.479323, 0.000000,  0.000000, -0.000000, -1.000000,
0.479323, 0.877638, -0.000000,  0.000000, 0.000000, 0.000000>}
light_source {
    <4.08,5.9,-1.01>
    color rgb<1, 1, 1>
}

camera {
    location  <0, 0, 0>
    look_at  <0, 0, -1>
    right <-1.7777777777777777, 0, 0>
    up <0, 1, 0>
    angle  49.134343
    rotate  <-27.098163, 46.688390, -0.903519>
    translate <7.481132, 5.343666, 6.507640>
}

[Lars Rohwedder] Re: 3D Loop [3975 days 18 hours and 53 minutes ago]

Tue, 19 May 2015 09:55:55 GMT

Am 15.05.2015 um 20:18 schrieb LanuHum:
> Example:
> 
> // POV-Ray scene. It is created in the Blender-2.74
> 
> […]

Nice one. But there are quite sharp curves at the transition between the
straight and the curved parts of the loop (marked read on the attached
image)

>
>   right <-1.7777777777777777, 0, 0>
>   up <0, 1, 0>

Oh, when will 16:9 aspect ratio will be the default in Povray? ;-)

L.

[Cousin Ricky] Re: Error in license statements [3976 days 12 hours and 19 minutes ago]

Mon, 18 May 2015 16:30:18 GMT

On 05/16/2015 11:07 AM, Le_Forgeron wrote:
> Your contribution have been updated, including the removal of a tr tag
> in rc3metal and change of text in spectrum.

Thanks!

> The change of the wording (Public / Purpose for Lesser Generic ) was
> rather easy, vi rules.

Really?  I was once informed that the only thing you need to know about 
vi is <Esc>:q!

;-)

[Le Forgeron] Re: Error in license statements [3978 days 13 hours and 42 minutes ago]

Sat, 16 May 2015 15:07:15 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 15/05/2015 21:51, Cousin Ricky a Ã©crit :
> On 05/15/2015 09:22 AM, Le_Forgeron wrote:
>> I should be able to correct the term in each contribution, it's
>> just one file to edit per contribution (but write access there is
>> easier)
> 
> I have uploaded the corrected files to povray.binaries.scene-files.
> In addition, I took the opportunity to clarify some unrelated
> sections of spectrum.html.  This should be easier than having you
> hunt down and correct my errors.
> 
Your contribution have been updated, including the removal of a tr tag
in rc3metal and change of text in spectrum.

The change of the wording (Public / Purpose for Lesser Generic ) was
rather easy, vi rules.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVXXSQACgkQhKAm8mTpkW1IrQP8DOTh01vViMmkGbkxHJMR31KG
+GIoyc/KVgLWU8gknyPCjSSujznEzYPxLsAMccZTBug7PbfF6yx62b52nDq3omNt
5E9HMICh57IOuiP5Lw5xiDofKDdQQfyqoDBGHwcXCC2rMytHAk65pKXyED28Psfv
hO8PqNku5oXXCwfSw5o=
=8R2H
-----END PGP SIGNATURE-----

[Cousin Ricky] Re: Error in license statements [3979 days 8 hours and 57 minutes ago]

Fri, 15 May 2015 19:51:46 GMT

On 05/15/2015 09:22 AM, Le_Forgeron wrote:
> I should be able to correct the term in each contribution, it's just
> one file to edit per contribution (but write access there is easier)

I have uploaded the corrected files to povray.binaries.scene-files.  In 
addition, I took the opportunity to clarify some unrelated sections of 
spectrum.html.  This should be easier than having you hunt down and 
correct my errors.

[LanuHum] Re: 3D Loop [3979 days 10 hours and 29 minutes ago]

Fri, 15 May 2015 18:20:00 GMT

Example:

// POV-Ray scene. It is created in the Blender-2.74

#version 3.7;

global_settings {
}
background {rgbt<0.05, 0.05, 0.05, 0>}

#declare Default_texture = pigment {rgb 0.8}

#declare data_Torus_Knot_orig =
union {
    sphere_sweep { cubic_spline 102,
        <2.958,-0.3775,-0.1893>,0.343,
        <3,0,0>,0.343,
        <2.958,0.3775,0.1893>,0.343,
        <2.835,0.7355,0.3717>,0.343,
        <2.638,1.056,0.5406>,0.343,
        <2.38,1.324,0.6901>,0.343,
        <2.078,1.53,0.8146>,0.343,
        <1.748,1.667,0.9096>,0.343,
        <1.41,1.735,0.9718>,0.343,
        <1.08,1.74,0.9989>,0.343,
        <0.7717,1.69,0.9898>,0.343,
        <0.4967,1.597,0.945>,0.343,
        <0.2605,1.477,0.866>,0.343,
        <0.064,1.344,0.7557>,0.343,
        <-0.09621,1.21,0.6182>,0.343,
        <-0.2276,1.088,0.4582>,0.343,
        <-0.3403,0.9833,0.2817>,0.343,
        <-0.4461,0.9001,0.09506>,0.343,
        <-0.5564,0.8363,-0.09506>,0.343,
        <-0.6814,0.7864,-0.2817>,0.343,
        <-0.8281,0.7409,-0.4582>,0.343,
        <-0.9999,0.6884,-0.6182>,0.343,
        <-1.196,0.6164,-0.7557>,0.343,
        <-1.41,0.513,-0.866>,0.343,
        <-1.632,0.3686,-0.945>,0.343,
        <-1.849,0.1766,-0.9898>,0.343,
        <-2.047,-0.06497,-0.9989>,0.343,
        <-2.208,-0.3533,-0.9718>,0.343,
        <-2.318,-0.6805,-0.9096>,0.343,
        <-2.364,-1.034,-0.8146>,0.343,
        <-2.337,-1.399,-0.6901>,0.343,
        <-2.233,-1.756,-0.5406>,0.343,
        <-2.054,-2.087,-0.3717>,0.343,
        <-1.806,-2.373,-0.1893>,0.343,
        <-1.5,-2.598,6.432e-16>,0.343,
        <-1.152,-2.75,0.1893>,0.343,
        <-0.7803,-2.822,0.3717>,0.343,
        <-0.4044,-2.812,0.5406>,0.343,
        <-0.04321,-2.723,0.6901>,0.343,
        <0.286,-2.564,0.8146>,0.343,
        <0.5695,-2.347,0.9096>,0.343,
        <0.7979,-2.089,0.9718>,0.343,
        <0.967,-1.805,0.9989>,0.343,
        <1.078,-1.513,0.9898>,0.343,
        <1.135,-1.229,0.945>,0.343,
        <1.149,-0.9642,0.866>,0.343,
        <1.132,-0.7272,0.7557>,0.343,
        <1.096,-0.5217,0.6182>,0.343,
        <1.056,-0.3467,0.4582>,0.343,
        <1.022,-0.1969,0.2817>,0.343,
        <1.003,-0.06371,0.09506>,0.343,
        <1.003,0.06371,-0.09506>,0.343,
        <1.022,0.1969,-0.2817>,0.343,
        <1.056,0.3467,-0.4582>,0.343,
        <1.096,0.5217,-0.6182>,0.343,
        <1.132,0.7272,-0.7557>,0.343,
        <1.149,0.9642,-0.866>,0.343,
        <1.135,1.229,-0.945>,0.343,
        <1.078,1.513,-0.9898>,0.343,
        <0.967,1.805,-0.9989>,0.343,
        <0.7979,2.089,-0.9718>,0.343,
        <0.5695,2.347,-0.9096>,0.343,
        <0.286,2.564,-0.8146>,0.343,
        <-0.04321,2.723,-0.6901>,0.343,
        <-0.4044,2.812,-0.5406>,0.343,
        <-0.7803,2.822,-0.3717>,0.343,
        <-1.152,2.75,-0.1893>,0.343,
        <-1.5,2.598,1.286e-15>,0.343,
        <-1.806,2.373,0.1893>,0.343,
        <-2.054,2.087,0.3717>,0.343,
        <-2.233,1.756,0.5406>,0.343,
        <-2.337,1.399,0.6901>,0.343,
        <-2.364,1.034,0.8146>,0.343,
        <-2.318,0.6805,0.9096>,0.343,
        <-2.208,0.3533,0.9718>,0.343,
        <-2.047,0.06497,0.9989>,0.343,
        <-1.849,-0.1766,0.9898>,0.343,
        <-1.632,-0.3686,0.945>,0.343,
        <-1.41,-0.513,0.866>,0.343,
        <-1.196,-0.6164,0.7557>,0.343,
        <-0.9999,-0.6884,0.6182>,0.343,
        <-0.8281,-0.7409,0.4582>,0.343,
        <-0.6814,-0.7864,0.2817>,0.343,
        <-0.5564,-0.8363,0.09506>,0.343,
        <-0.4461,-0.9001,-0.09506>,0.343,
        <-0.3403,-0.9833,-0.2817>,0.343,
        <-0.2276,-1.088,-0.4582>,0.343,
        <-0.09621,-1.21,-0.6182>,0.343,
        <0.064,-1.344,-0.7557>,0.343,
        <0.2605,-1.477,-0.866>,0.343,
        <0.4967,-1.597,-0.945>,0.343,
        <0.7717,-1.69,-0.9898>,0.343,
        <1.08,-1.74,-0.9989>,0.343,
        <1.41,-1.735,-0.9718>,0.343,
        <1.748,-1.667,-0.9096>,0.343,
        <2.078,-1.53,-0.8146>,0.343,
        <2.38,-1.324,-0.6901>,0.343,
        <2.638,-1.056,-0.5406>,0.343,
        <2.835,-0.7355,-0.3717>,0.343,
        <2.958,-0.3775,-0.1893>,0.343,
        <3,0,0>,0.343,
        <2.958,0.3775,0.1893>,0.343
    }
    texture {Default_texture}
}
object { data_Torus_Knot_orig
matrix <0.011995, -0.831861, 0.000000,  0.000000, -0.000000, -0.831948,
0.831861, 0.011995, -0.000000,  0.000000, 0.000000, 0.000000>}

light_source {
    <4.08,5.9,5.1>
    color rgb<1, 1, 1>
}

camera {
    location  <0, 0, 0>
    look_at  <0, 0, -1>
    right <-1.7777777777777777, 0, 0>
    up <0, 1, 0>
    angle  49.134343
    rotate  <-27.098163, 46.688390, -0.903519>
    translate <7.481132, 5.343666, 6.507640>
}

[LanuHum] Re: 3D Loop [3979 days 12 hours and 9 minutes ago]

Fri, 15 May 2015 16:40:00 GMT

Lars Rohwedder <rok### [at] gmxde> wrote:
> Inspired by this object:
>
>
http://www.shutterstock.com/pic-94505617/stock-photo--d-infinity-shape-d-render-illustration.html
>

>
> I would like to change the whole object into a single "sphere_sweep" and
> I'd like to have a closed formula that calculates the positions of all
> spheres at once, with "smooth" transitions between the 3 3/4 torii, so
> no cylindrical parts between them.
>

>
> Any ideas, suggestions?

Python in the Blender creates it so:

def Torus_Knot(self):
    p = self.torus_p
    q = self.torus_q
    w = self.torus_w
    res = self.torus_res
    h = self.torus_h
    u = self.torus_u
    v = self.torus_v
    rounds = self.torus_rounds

    newPoints = []
    angle = 2*rounds
    step = angle/(res-1)
    scale = h
    height = w

    for i in range(res-1):
        t = ( i*step*pi)

        x = (2 * scale + cos((q*t)/p*v)) * cos(t * u)
        y = (2 * scale + cos((q*t)/p*v)) * sin(t * u)
        z = sin(q*t/p) * height

        newPoints.extend([x,y,z,1])

    return newPoints

From the received verts cubic_spline is created

[Lars Rohwedder] Re: 3D Loop [3979 days 13 hours and 14 minutes ago]

Fri, 15 May 2015 15:35:04 GMT

> search "Trefoil knot"

Nice one. It is a bit "flattened" compared to my object and the 3 "ears"
are not perpendicular to each other.

But I think I can use if for my ideas :-)

Thank you!

			Lars R.

[Le Forgeron] Re: 3D Loop [3979 days 14 hours and 14 minutes ago]

Fri, 15 May 2015 14:35:01 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 15/05/2015 15:44, Lars Rohwedder a Ã©crit :
> Inspired by this object:
> 
> http://www.shutterstock.com/pic-94505617/stock-photo--d-infinity-shape
- -d-render-illustration.html
>
>  I created a simple Povray union. The resuld you can see attached.
> 
> I would like to change the whole object into a single
> "sphere_sweep" and I'd like to have a closed formula that
> calculates the positions of all spheres at once, with "smooth"
> transitions between the 3 3/4 torii, so no cylindrical parts
> between them.
> 
> I tried 3 polynomials (one for each of the X, Y, Z coordinates) but
> it was harder than it looked to me. :-(
> 
> Any ideas, suggestions?
> 

search "Trefoil knot"

Beware, it's chiral, so there is a left and a right version.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVWBBUACgkQhKAm8mTpkW1glQP/epMnH8+Ssj5Z54zy1S+cSknE
SPLkgZe4dceeciBhjh5k6Q3NawdubtH/gNaFiC9mjj7fho+Vf1Aow6E7naCUR+ab
r4SIgvFvufA5zgf8l/0Lek4kWpcckL5P6PoMaF6dwXxCLchMGxX5WMwpgQtTfyWV
EsED8/AUM+2Up4agmR0=
=BCOo
-----END PGP SIGNATURE-----

[Lars Rohwedder] 3D Loop [3979 days 15 hours and 5 minutes ago]

Fri, 15 May 2015 13:44:24 GMT

Inspired by this object:

http://www.shutterstock.com/pic-94505617/stock-photo--d-infinity-shape-d-render-illustration.html

I created a simple Povray union. The resuld you can see attached.

I would like to change the whole object into a single "sphere_sweep" and
I'd like to have a closed formula that calculates the positions of all
spheres at once, with "smooth" transitions between the 3 3/4 torii, so
no cylindrical parts between them.

I tried 3 polynomials (one for each of the X, Y, Z coordinates) but it
was harder than it looked to me. :-(

Any ideas, suggestions?

[Le Forgeron] Re: Error in license statements [3979 days 15 hours and 27 minutes ago]

Fri, 15 May 2015 13:22:10 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 15/05/2015 07:42, Cousin Ricky a Ã©crit :
> On 01/20/2014 11:08 PM, Cousin Ricky wrote:
>> On the Object Collection submission screen, in the help
>> documents 02using.html and 04contributing.html, and in all the
>> downloaded README*.html files, the license statement reads
>> "Lesser General Purpose License."  It should actually be "Lesser
>> General Public License."  Can someone, perhaps Jerome, fix this
>> error?
> 
> This error is also present on the search page: 
> http://lib.povray.org/searchcollection/index.php
> 

Alas, I do not have write access to that part of the site for the time
being.

I should be able to correct the term in each contribution, it's just
one file to edit per contribution (but write access there is easier)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVV8wIACgkQhKAm8mTpkW0EFgP/VwxJ+l+kE27o0jNXiNRPn5Q9
6EzZne5J+V98n7nRsAdNqKJtpRCWRcWZ3p40vQepsROVpXtG4XhcVLUZyFL6pWrM
SICZ5+lIhrggB2hRhR9vo3eBrrEdk+ZNB3ImrFTX4ZK7+49SAtmzcbnE9vcFAHQb
RYk+h6SROByJFXfJ0ZQ=
=mbJb
-----END PGP SIGNATURE-----

[Cousin Ricky] Re: Error in license statements [3979 days 23 hours and 6 minutes ago]

Fri, 15 May 2015 05:42:50 GMT

On 01/20/2014 11:08 PM, Cousin Ricky wrote:
> On the Object Collection submission screen, in the help documents 02using.html
> and 04contributing.html, and in all the downloaded README*.html files, the
> license statement reads "Lesser General Purpose License."  It should actually be
> "Lesser General Public License."  Can someone, perhaps Jerome, fix this error?

This error is also present on the search page: 
http://lib.povray.org/searchcollection/index.php

[Cousin Ricky] AndroidRobot 3.0a [3997 days 9 hours and 27 minutes ago]

Mon, 27 Apr 2015 19:22:09 GMT

I discovered an error in the AndroidRobot 2.2 documentation last month,
and the prospect of correcting it prompted me to make some other changes
as well.

Last fall, while testing AndroidRobot 2.2 with an orthographic camera,
it became evident that Karl's model was noticeably different from the
images from The Google's Web pages. I toyed with the idea of remodeling
it, but tabled it in favor of other projects, such as a RoundEdge
update, two brand new modules to deal with spectral rendering, an
operating system upgrade, brushing up on my Spanish, (re)starting an
exercise program (again), and recovering from the worst toothache of my
life. But finding errors in documentation makes me crazy. (/Another/
documentation error explains the rapid update from 3.0 to 3.0a. This is
why professional writers have someone else proofread their work.)

I found an SVG version of the logo, which is claimed to have originated
from a Web page on the Android developer site, although in keeping with
The Google's typical practice, the page no longer exists. (I know
someone on these newsgroups works for The Google. Tell 'em to stop
that.) I ran the coordinates from the SVG source code through a
spreadsheet so that the new model would have the same size and position
as Karl's (burning bridges also makes me crazy), but with official
proportions.

Speaking of not burning bridges, Karl's model may be summoned from 3.0a
by setting a version switch.

The branding page (linked from the AndroidRobot 3.0a User Manual) has an
Adobe Illustrator image, which may be the best source for the exact
proportions. It is loaded with neat stuff such as CMYK data for your
properly profiled color printer. Alas, I don't have access to Adobe
Illustrator, and the SVG image was good enough for my purpose.

In addition to the revised model, AndroidRobot 3.0a has new tools to
assist with creating user-defined eyes. The 3-D model's eyes are just
dark holes, and leave a bit of a spooky impression. Hopefully, the user
can mitigate this soullessness with these new tools.

http://lib.povray.org/searchcollection/index2.php?objectName=AndroidRobot&contributorTag=Cousin%20Ricky

Note: The standard Object Collection README file says that you may use
images that you generate using these files without restriction. As the
Android robot is trademarked, this is obviously not true for this
particular module. The User Manual has the proper licensing notices.

I am curious to know if anyone has used this module in association with
their app for Android.

[Cousin Ricky] FranciscoMunoz and Unix [4048 days 6 hours and 14 minutes ago]

Sat, 7 Mar 2015 22:35:24 GMT

The FranciscoMunoz SDL code makes references to mixed-case file names, 
but the file names, as downloaded, are all lowercase.  Therefore, the 
module will not work in Unix and similar operating systems such as 
GNU/Linux.  The following shell script will rename the necessary files 
so that the code will run unaltered in POV-Ray for Unix.  It was written 
for bash, but I believe it will work for any Bourne-compatible shell.

----------------[BEGIN CODE]----------------
#!/bin/sh
mv fmunoz_android.inc FMunoz_Android.inc
mv fmunoz_babydino.inc FMunoz_BabyDino.inc
mv fmunoz_column.inc FMunoz_Column.inc
mv fmunoz_deskitems.inc FMunoz_DeskItems.inc
mv fmunoz_drinks.inc FMunoz_Drinks.inc
mv fmunoz_fruit.inc FMunoz_Fruit.inc
mv fmunoz_homid.inc FMunoz_Homid.inc
mv fmunoz_jarron.inc FMunoz_Jarron.inc
mv fmunoz_mano.inc FMunoz_Mano.inc
mv fmunoz_minimech.inc FMunoz_MiniMech.inc
mv fmunoz_minitank.inc FMunoz_MiniTank.inc
mv fmunoz_swords.inc FMunoz_Swords.inc
-----------------[END CODE]-----------------

In addition, FMunoz_DeskItems.inc refers to the Microsoft font file 
Arial.ttf.  On my system, that font name is all lowercase, so I modified 
my copy of FMunoz_DeskItems.inc accordingly.  YMMV.

[Cousin Ricky] CoffeeMug 2.0 with textures! [4050 days 5 hours and 11 minutes ago]

Thu, 5 Mar 2015 23:37:57 GMT

I lied.  A couple of function arguments slipped by me in versions 1.3 
and 1.3a, with the result that these versions are not /completely/ 
namespace compliant.  (Although function arguments are not specifically 
mentioned in the compliance rules, they can cause problems.)  The 
offending function, which was not documented in the user manual (and 
which you therefore should not have been using), has been deleted in 
version 2.0.  If you are incurious about the wonderful 2.0 improvements, 
and are satisfied with the severely limited and inadequate texture 
options in version 1.3a, you can fix coffeemug.inc 1.3a by globally 
replacing RMajor and rMinor with CoffeeMug_P0 and CoffeeMug_P1, 
respectively.

However, you will no doubt want to apply patterns and image maps to your 
coffee mugs without going through a whole lot of trouble.  In CoffeeMug 
2.0, the pigment and texture macros can apply general pigments and 
textures to the mug with cylindrical mapping.  Previously, the macros 
could only apply object masks.

But wait, there's more!

  - A macro is added to compute the stacking height of a mug, so
    you can show some mugs neatly stored on a shelf.

  - A shortened prefix has been introduced to save typing and
    unwieldy-looking code.  The old prefix still works, of course.

http://lib.povray.org/searchcollection/index2.php?objectName=CoffeeMug&contributorTag=Cousin%20Ricky

[Cousin Ricky] Re: HTML docs broken [4061 days 21 hours and 36 minutes ago]

Sun, 22 Feb 2015 07:13:11 GMT

On 02/21/2015 04:20 AM, Thomas de Groot wrote:
> On 21-2-2015 5:14, Mike Horvath wrote:
>> This page doesn't render properly:
>>
>> http://lib.povray.org/collection/caption/cousin%20ricky%201.0/caption.html
>>
>>
>> In Chrome all I see is HTML code, not the intended rendered document.
> idem in Firefox.

Older, less secure versions of Micro$haft Internet Exploder have been 
programmed to second-guess the server, and render the documents in all 
their richly-styled glory.  (I dare you.)

[Le Forgeron] Re: HTML docs broken [4062 days 17 hours and 39 minutes ago]

Sat, 21 Feb 2015 11:10:04 GMT

Le 21/02/2015 12:08, Mike Horvath a Ã©crit :

> 
> You mean bots were making Object Collection submissions? Where are all
> these awesome scene files?

Just posting links and similar to viagra and other usual spam.

[Mike Horvath] Re: HTML docs broken [4062 days 17 hours and 41 minutes ago]

Sat, 21 Feb 2015 11:07:47 GMT

On 2/21/2015 4:59 AM, Le_Forgeron wrote:
> Le 21/02/2015 09:20, Thomas de Groot a Ã©crit :
>> On 21-2-2015 5:14, Mike Horvath wrote:
>>> This page doesn't render properly:
>>>
>>> http://lib.povray.org/collection/caption/cousin%20ricky%201.0/caption.html
>>>
>>>
>>> In Chrome all I see is HTML code, not the intended rendered document.
>> idem in Firefox.
>>
>
> it has been already covered by the subject "lib.povray.org sending html
> in text/plain.
>
> As stated then (2014-09-03):
>
> It was "done on purpose"... against bots. It's a shame, and html
> breaks the navigation too, but I have no solution.
>
>
>
> ===
>
> At least when you download the submission, you get to read it correctly.
> But still no solution for online.
>


You mean bots were making Object Collection submissions? Where are all 
these awesome scene files?

[Le Forgeron] Re: HTML docs broken [4062 days 18 hours and 50 minutes ago]

Sat, 21 Feb 2015 09:59:15 GMT

Le 21/02/2015 09:20, Thomas de Groot a Ã©crit :
> On 21-2-2015 5:14, Mike Horvath wrote:
>> This page doesn't render properly:
>>
>> http://lib.povray.org/collection/caption/cousin%20ricky%201.0/caption.html
>>
>>
>> In Chrome all I see is HTML code, not the intended rendered document.
> idem in Firefox.
> 

it has been already covered by the subject "lib.povray.org sending html
in text/plain.

As stated then (2014-09-03):

It was "done on purpose"... against bots. It's a shame, and html
breaks the navigation too, but I have no solution.

===

At least when you download the submission, you get to read it correctly.
But still no solution for online.

[Thomas de Groot] Re: HTML docs broken [4062 days 20 hours and 29 minutes ago]

Sat, 21 Feb 2015 08:20:17 GMT

On 21-2-2015 5:14, Mike Horvath wrote:
> This page doesn't render properly:
>
> http://lib.povray.org/collection/caption/cousin%20ricky%201.0/caption.html
>
> In Chrome all I see is HTML code, not the intended rendered document.
idem in Firefox.

-- 
Thomas

[Mike Horvath] HTML docs broken [4063 days and 35 minutes ago]

Sat, 21 Feb 2015 04:14:20 GMT

This page doesn't render properly:

http://lib.povray.org/collection/caption/cousin%20ricky%201.0/caption.html

In Chrome all I see is HTML code, not the intended rendered document.

[Mike Horvath] Re: Ping SharkD: legal question about the Munsel... [4063 days and 37 minutes ago]

Sat, 21 Feb 2015 04:12:25 GMT

On 12/19/2014 12:20 PM, Cousin Ricky wrote:
> First of all, the Web page URL has changed:
>
>    http://www.rit.edu/cos/colorscience/rc_munsell_renotation.php
>
> But my main concern is RIT's terms of use.  According to these terms,
> the contents of the Web site are for personal, noncommercial use only.
> IANAL, but to me, these terms don't appear to be compatible with the
> LGPL.  Do you have some assurance (preferably written) that the Munsell
> data are not covered by these restrictions, or have you otherwise
> contacted RIT about their use?


No, I never thought to ask for permission.

[Cousin Ricky] lrchairs version 1.1 [4114 days 4 hours and 52 minutes ago]

Wed, 31 Dec 2014 23:56:44 GMT

I think Leroy Whetstone's cheap chair deserves wider exposure, so to 
that end, I have brought the module into complete namespace compliance 
so that it shows up in the default search.  I also:

- Added HTML documentation.
- Added scale conversion constants, as both Leroy and I live in a
   country with an antiquated system of weights and measures, and the
   scaling of the chair reflects that circumstance.
- Tested the module in POV-Ray 3.5 and added #version statements to
   the SDL files.

I have left the modeling of his chair entirely unchanged.

http://lib.povray.org/searchcollection/index2.php?objectName=lrchairs&contributorTag=Cousin%20Ricky

[Cousin Ricky] Re: Ping SharkD: legal question about the Munsel... [4126 days 9 hours and 26 minutes ago]

Fri, 19 Dec 2014 19:22:41 GMT

On 12/19/2014 02:35 PM, Le_Forgeron wrote:
> But aren't 1929 data now in public domain ?
>  From 1909's law, 1929 would have gain a 28 years protection. Did they
> renewed it ? If yes, then the original date for public domain would have
> moved from 1985 to 2024.

Good point.

[Le Forgeron] Re: Ping SharkD: legal question about the Munsel... [4126 days 10 hours and 13 minutes ago]

Fri, 19 Dec 2014 18:35:48 GMT

Le 19/12/2014 18:20, Cousin Ricky a Ã©crit :
> First of all, the Web page URL has changed:
> 
>   http://www.rit.edu/cos/colorscience/rc_munsell_renotation.php
> 
> But my main concern is RIT's terms of use.  According to these terms,
> the contents of the Web site are for personal, noncommercial use only.
> IANAL, but to me, these terms don't appear to be compatible with the
> LGPL.  Do you have some assurance (preferably written) that the Munsell
> data are not covered by these restrictions, or have you otherwise
> contacted RIT about their use?

But aren't 1929 data now in public domain ?
From 1909's law, 1929 would have gain a 28 years protection. Did they
renewed it ? If yes, then the original date for public domain would have
moved from 1985 to 2024.

Yet, the data of 1929 were made from work made before the death of
Munsell (1918). Ergo a work that is now in public domain under USA
federal law (any copyrighted work published before 1923-01-01 is public
domain by effect of the 1976 Act).

And for discussion's sack: as a promoting a system and set of data, did
they even copyrighted these pieces of data ?

Devil's advocate: can we assert that the previous license was not more
permissive ?

[Cousin Ricky] Ping SharkD: legal question about the Munsell mo... [4126 days 11 hours and 28 minutes ago]

Fri, 19 Dec 2014 17:20:40 GMT

First of all, the Web page URL has changed:

   http://www.rit.edu/cos/colorscience/rc_munsell_renotation.php

But my main concern is RIT's terms of use.  According to these terms, 
the contents of the Web site are for personal, noncommercial use only. 
IANAL, but to me, these terms don't appear to be compatible with the 
LGPL.  Do you have some assurance (preferably written) that the Munsell 
data are not covered by these restrictions, or have you otherwise 
contacted RIT about their use?

[clipka] Re: My recent updates [4162 days 14 hours and 34 minutes ago]

Thu, 13 Nov 2014 14:15:19 GMT

Am 07.11.2014 16:37, schrieb Bald Eagle:

> We'll see what bitcoin does....

Delibarately wasting computing power, thereby needlessly gobbling up 
energy, that's what it does.

[Cousin Ricky] Re: My recent updates [4168 days 8 hours and 9 minutes ago]

Fri, 7 Nov 2014 20:40:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> 2014 October 9 - TiltedTorus 2.0
>  - A long overdue lathe version is added.

Wouldn't you know it, /now/ I find a serious error in the user manual that had
been just sitting there for more than 2 years.  Version 2.0a is now uploaded
with the corrected user manual.

http://lib.povray.org/searchcollection/index2.php?objectName=TiltedTorus&contributorTag=Cousin%20Ricky

[Bald Eagle] Re: My recent updates [4168 days 13 hours and 9 minutes ago]

Fri, 7 Nov 2014 15:40:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:

> I am on a fixed income, so I have to guard my savings carefully.  I've already
> blown too much on what, in retrospect, I should have seen as cash sinkholes.

Like that time I got married...

I have some savings, and at the moment a fixed income - zero.
Be practical.  See what you can get without needing to buy anything.
Ask people to look at or borrow something that they own.
Ask someone in the trade to show you things and let you photograph them.
I don't know what sort of specific information you need to gather, but I would
think that there have to be an endless number of photographs on the internet of
different types of metal.

If you need images of super-clean metal, maybe look up plating,
dissolution/dissolving, chemistry, elemental metal, refining, etching, etc.
Those keywords might net you some pristine surfaces.

> Another question I thought of: Is there a significant difference in appearance
> between pure gold and the 14K gold used in jewelry?

There sure is.  Hit some of the jewelry supply companies' websites like Rio
Grande, Stuller, and Gesswein.

AFAIK, silver just came way back down.  I should have spent every cent I had on
silver back when it was $8 an oz.  I can only imagine that it's set to go back
up.  We'll see what bitcoin does....

[Le Forgeron] Re: My recent updates [4169 days 9 hours and 38 minutes ago]

Thu, 6 Nov 2014 19:10:53 GMT

On 06/11/2014 19:04, Cousin Ricky wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> You could see if you could get gold leaf from an art supply store - they (still)
>> use it for gilding high-end frames.  Maybe see if a coin shop will let you
>> photograph something.  Then there is the obvious jewelry store or maybe less
>> obvious - precious metal refinery.  I suppose the same goes for silver - and I
>> know a LOT of people who are heavily into silver rounds, since the US Federal
>> Reserve Note is becoming more & more worthless by the moment...
> 
> I am on a fixed income, so I have to guard my savings carefully.  I've already
> blown too much on what, in retrospect, I should have seen as cash sinkholes.
> 
> Another question I thought of: Is there a significant difference in appearance
> between pure gold and the 14K gold used in jewelry?
> 
> 
> 
Yes, There is even a significant difference between 18k, 14k and 9k
yellow gold.

And plated is even more recognizable.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

[Cousin Ricky] Re: My recent updates [4169 days 10 hours and 44 minutes ago]

Thu, 6 Nov 2014 18:05:02 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> You could see if you could get gold leaf from an art supply store - they (still)
> use it for gilding high-end frames.  Maybe see if a coin shop will let you
> photograph something.  Then there is the obvious jewelry store or maybe less
> obvious - precious metal refinery.  I suppose the same goes for silver - and I
> know a LOT of people who are heavily into silver rounds, since the US Federal
> Reserve Note is becoming more & more worthless by the moment...

I am on a fixed income, so I have to guard my savings carefully.  I've already
blown too much on what, in retrospect, I should have seen as cash sinkholes.

Another question I thought of: Is there a significant difference in appearance
between pure gold and the 14K gold used in jewelry?

[Cousin Ricky] Spectral BeamTest [4173 days 7 hours and 4 minutes ago]

Sun, 2 Nov 2014 21:45:01 GMT

BeamTest is a test bed for examining the behavior of light in POV-Ray.  In
version 1.2 there is a new demo file, plus several minor updates:

 - A demo scene is added that uses Ive's SpectralRender package.
   SpectralRender and its prerequisite are not in the Object Collection,
   but download links are provided in the documentation.

 - A parameter is introduced to color the environmental lighting.  This
   was done to accommodate SpectralRender, as a flat emission spectrum
   does not appear white to humans.

 - The orthographic camera is introduced, and made the default.

 - A parameter is introduced to control the image height.  BeamTest
   normally does this automatically, but it ASSumes that the pixels are
   square.  The POV-Ray docs warn that this is not always the case,
   although I personally have not seen such machines since the 1980s.
   Still, it was trivial to add.

http://lib.povray.org/searchcollection/index2.php?objectName=BeamTest&contributorTag=Cousin%20Ricky

[Bald Eagle] Re: My recent updates [4182 days 7 hours and 9 minutes ago]

Fri, 24 Oct 2014 21:40:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:

> Bronze is Copper+Tin (Cu / Sn), Brass is Copper+Zinc (Cu / Zn). No Zinc
> in Bronze. (memotrick: you got only one Z, either in component or in
> alloy's name)
>
> Dezincified bronze seems a non-sense. It does exist for brass, nevertheless.

I suppose it gets confusing with the poor nomenclature and definitions out
there.

"Commercial bronze (90% copper and 10% zinc) and architectural bronze (57%
copper, 3% lead, 40% zinc) are more properly regarded as brass alloys because
they contain zinc as the main alloying ingredient. "

So who knows what my box is actually constructed out of..

[Le Forgeron] Re: My recent updates [4182 days 9 hours and 20 minutes ago]

Fri, 24 Oct 2014 19:28:58 GMT

On 24/10/2014 02:54, Bald Eagle wrote:
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> 
>  RC3Metal
>    - Derive updated metal colors from analysis of digital photos.  I
>      believe I have a system to compensate for environment biases.  At
>      this time I have no idea where I will get gold, silver, and bronze
>      specimens.
> 
> I have a bronze box manufactured by Tiffany.  It has 3 major colorations - that
> "shiny new copper" color, the usual "old patina'd penny" look, and then on the
> inside of the cover is - as far as I can tell, and example of the very reddish
> copper color which I believe arises from "dezincified bronze"

Bronze is Copper+Tin (Cu / Sn), Brass is Copper+Zinc (Cu / Zn). No Zinc
in Bronze. (memotrick: you got only one Z, either in component or in
alloy's name)

Dezincified bronze seems a non-sense. It does exist for brass, nevertheless.

http://corrosion-doctors.org/Forms-selective/dezinc-valve.htm

Pure copper is rich pink/orange, not deep red. Oxydized copper can be
green or blue. The usual green stains on outside statues are
copper-oxyde leaking from the bronze alloy.

Beware, both Bronze and Brass might be abbreviated Br inadvertently, but
usually Brass is Br, and Bronze Bz.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

[Bald Eagle] Re: My recent updates [4183 days 3 hours and 54 minutes ago]

Fri, 24 Oct 2014 00:55:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:

 RC3Metal
   - Derive updated metal colors from analysis of digital photos.  I
     believe I have a system to compensate for environment biases.  At
     this time I have no idea where I will get gold, silver, and bronze
     specimens.

I have a bronze box manufactured by Tiffany.  It has 3 major colorations - that
"shiny new copper" color, the usual "old patina'd penny" look, and then on the
inside of the cover is - as far as I can tell, and example of the very reddish
copper color which I believe arises from "dezincified bronze"

I believe various bronze alloys are used for marine purposes like screw
propellers, due to their resistance to salt water, and there are a lot of bronze
alloys used for motor bearings and gun barrel cleaning brushes are "phosphor
bronze" - not sure how you'd get a good look at a bristle...

You could see if you could get gold leaf from an art supply store - they (still)
use it for gilding high-end frames.  Maybe see if a coin shop will let you
photograph something.  Then there is the obvious jewelry store or maybe less
obvious - precious metal refinery.  I suppose the same goes for silver - and I
know a LOT of people who are heavily into silver rounds, since the US Federal
Reserve Note is becoming more & more worthless by the moment...

Thanks for what looks like an awful lot of hard work.  Perhaps some time in the
future I can look at and experiment with any of the innumerable features that
POV-Ray has that I haven't even begun to explore...

[Cousin Ricky] My recent updates [4194 days 5 hours and 29 minutes ago]

Sun, 12 Oct 2014 23:20:01 GMT

With no quarterly reports in 5 years and very little feedback from the users, I
thought I'd mention what I've been up to.

2013 June 15 - RoundEdge 1.3
 - Blob-related functions are given more intuitive names.
 - Important notes are added to the documentation concerning sqrt()
   calls with the alternate isosurface blob function, and the demo
   scene is changed accordingly.
 - The missing illustrations have been added to the Collection.

2013 July 22 - SphereSweep 1.0
 - The sphere_sweep primitive is prone to artifacts.  This module gives
   various workarounds.

2013 September 6 - RC3Metal 1.2
 - I added a macro to coordinate specular highlights with brilliance.
   It gives good results.

2013 December 23 - Caption 1.0
 - Annotations are sometimes hard to read over a busy scene.  With this
   module you can easily add legible captions to such scenes.

2014 January 10 - Spectrum 4.0
 - This module creates calibrated color maps and pigments of the visible
   spectrum.
 - The initial public version is 4.0.  You have seen output from earlier
   versions in my p.b.i postings, but due to copyright restrictions, the
   source code for those versions shall remain forever private.

2014 October 5 - AndroidRobot 2.2
 - The arms are now separated from the body, as in the 2-D logo.

2014 October 9 - TiltedTorus 2.0
 - A long overdue lathe version is added.

Planned updates:

  BeamTest
   - Why didn't I think of using the orthographic camera way back in
     2007?
   - Add a parameter to better accommodate Ive's SpectralRender and (if
     it is as seamless as I hope) CLipka's spectral patch.  (The current
     version of BeamTest can be used as-is with SpectralRender, but the
     environmental lighting looks terrible.)

  CoffeeMug
   - In 2008 when I first submitted this, I had not yet discovered the
     cylindrical warp.  I can probably use it for more elaborate mug
     textures without having the user resort to the Labeller module.

  RC3Metal
   - Derive updated metal colors from analysis of digital photos.  I
     believe I have a system to compensate for environment biases.  At
     this time I have no idea where I will get gold, silver, and bronze
     specimens.

  RoundEdge
   - The module already includes elliptical toroids in mesh form, but
     an isosurface function or two is still a dream of mine.  I have
     formulas by Nicholas George, Sebastian H., and myself, but I'm not
     satisfied with any of them.  Nicholas' formula doesn't yield the
     correct shape.  Sebastian's formula may be correct--it yields a
     shape that is virtually satisfactory--but I haven't vetted his
     math, and the max_gradient is a nightmare.  My own formula was a
     hack that I used for one project, but it is certainly not library
     quality.

  SphereSweep
   - Implement B-splines and Bézier splines.
   - Enable gradient textures along the sweep, most likely concurrent
     with a mesh version.

I also have several brand new modules in development, and ideas for even more.

[Maurizio Paolini] Re: Rubik's Magic added to the object collection [4232 days 6 hours and 49 minutes ago]

Thu, 4 Sep 2014 22:00:00 GMT

The new version (2.0) adds support for intermediate angles.
Added decoration with dogs (a clone that I bought many years ago, I don't
know the brand name)

Maurizio

"Maurizio Paolini" <pao### [at] dmfunicattit> wrote:
> I just added an include file (and some jpg files) to render some 3D
> configurations
> of the Rubik's Magic puzzle
>
> http://lib.povray.org/collection/rubiksmagic/maurizio%201.0/rubiksmagic.jpg
>
> The configuration is described using a string that encodes the relative
> position of the tiles in the chain, the syntax is described in the include
> file itself.
>
> I will soon upload a new version that will fix a lower-case/upper-case
> issue in the example provided (the upload process transformed all file-names
> to lower-case).
>
> Support for angles different from 90 degrees between tiles is not yet
> present, but it could be a future addition; that would allow to create
> animations.
>
> Question: is there a way to upload an archive containing all the jpegs
> instead of uploading the images one-by-one, which is quite inconvenient?
>
> Maurizio

[Maurizio Paolini] Rubik's Magic added to the object collection [4232 days 18 hours and 19 minutes ago]

Thu, 4 Sep 2014 10:30:01 GMT

I just added an include file (and some jpg files) to render some 3D
configurations
of the Rubik's Magic puzzle

http://lib.povray.org/collection/rubiksmagic/maurizio%201.0/rubiksmagic.jpg

The configuration is described using a string that encodes the relative
position of the tiles in the chain, the syntax is described in the include
file itself.

I will soon upload a new version that will fix a lower-case/upper-case
issue in the example provided (the upload process transformed all file-names
to lower-case).

Support for angles different from 90 degrees between tiles is not yet
present, but it could be a future addition; that would allow to create
animations.

Question: is there a way to upload an archive containing all the jpegs
instead of uploading the images one-by-one, which is quite inconvenient?

Maurizio

[Warp] Re: lib.povray.org sending html files in text/pl... [4233 days 10 hours and 24 minutes ago]

Wed, 3 Sep 2014 18:25:23 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> On 03/09/2014 17:58, Warp wrote:
> > For some reason lib.povray.org is sending html files with the
> > text/plain mime type, which means that the browser will show the
> > HTML source rather than the rendered page. For example
> > 
> > http://lib.povray.org/collection/warprubikscube/warp%201.01/wrc.html
> >
> > 
> It was "done on purpose"... against bots. It's a shame, and html
> breaks the navigation too, but I have no solution.

It makes the documentation included with the library basically
useless if you try to view it online, directly from lib.povray.org.

-- 
                                                          - Warp

[Le Forgeron] Re: lib.povray.org sending html files in text/pl... [4233 days 12 hours and 18 minutes ago]

Wed, 3 Sep 2014 16:30:47 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/09/2014 17:58, Warp wrote:
> For some reason lib.povray.org is sending html files with the
> text/plain mime type, which means that the browser will show the
> HTML source rather than the rendered page. For example
> 
> http://lib.povray.org/collection/warprubikscube/warp%201.01/wrc.html
>
> 
It was "done on purpose"... against bots. It's a shame, and html
breaks the navigation too, but I have no solution.

- -- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iJwEAQECAAYFAlQHQjYACgkQhKAm8mTpkW2dBAP/SyvNd3rQ3QU0V+zMyaxsT3KM
CZHek37bZHre/wRMtBzzvkIHX6jm47w4RUUkRDhr5FHrD5yR/SjEHMlU2eEM4Au8
1jkdYat8u7f2kNDMOW2SzFwVsoZO57CBYRYyABIzzcdMj6ehsec+m0ZvwwQRtErE
/aH3h2hjRSCpaaHdYtY=
=9FeT
-----END PGP SIGNATURE-----

[Le Forgeron] Re: Contributing to the object library [4233 days 12 hours and 20 minutes ago]

Wed, 3 Sep 2014 16:28:50 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/09/2014 12:26, Le_Forgeron wrote:
> Le 03/09/2014 12:17, Maurizio Paolini a Ã©crit :
>> As additional info: when I try to "login" into lib.povray.org the
>> form that appears asks for "Your six-digit user ID (supplied in
>> confirmation email)." I don't have any confirmation email, and it
>> sounds strange that it does not ask for a username.
>> 
> 
> IIRC, there is no user name at login, only the six digit (which map
> to the user).
> 
> It's an old system.

Yep, as I now remember, registration was disabled due to spamming bots.
(and I do not have rights to change that.)

I should be able to create your user's account for you, if you email
me the details (and once created, the first thing you do is to change
the dummy weak password I will have put in it).

You can use my public key on that email address (look at the sender of
this message) if you want. It's on the various key-servers (if you
know what I'm talking about, you know them).

I need (same as for the registration form):
* An email address to validate the registration (not displayed on site)
* A nickname
* First name & Surname
* Country of residence

If you have additional info (website, public email...) , you can
update your profile once created.

The login has to be a 6 digits value, some are already used, but I
guess you can have a bit of a choice on that too.

Best regards.

> 
>> Maurizio
>> 
>> Le_Forgeron <lef### [at] freefr> wrote:
>>> Le 02/09/2014 22:04, Maurizio Paolini a ÃƒÂ©crit :
>>>> Hello all,
>>>> 
>>>> I would like to contribute to the object library
>>>> (lib.povray.org) with an include file for the Rubik's Magic.
>>>> 
>>>> When I try to register an error appears saying "Too many
>>>> registrations from your address".  However I think I never
>>>> registered before and in any case if I try to login I cannot
>>>> find any way to recover a "forgotten" password.
>>>> 
>>>> What am I doing wrong?
>>>> 
>>>> Cheers, Maurizio Paolini
>>>> 
>>>> 
>>> I will try to look at it, once back at home.
>>> 
>>> 
>>> 
>>> -- Just because nobody complains does not mean all parachutes
>>> are perfect.
>> 
>> 
>> 
> 
> 


- -- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iJwEAQECAAYFAlQHQbQACgkQhKAm8mTpkW3RagP9FbC5rsPe+IQwfntS1rINkEPV
IaVB+kECa2oQapM4jU8quhWDqIuHjBAjenxzdYFY/ggQ35LQR23HWejVUmBXHJiL
9doyhxfTwq/46EvZ9nVTaVTFki2sMwJH7FiDoeeyJHP5HCvhtaelGFn34LlXPYsN
FHZKyhiOE3TnfXUpC7w=
=RYem
-----END PGP SIGNATURE-----

[Warp] lib.povray.org sending html files in text/plain [4233 days 12 hours and 50 minutes ago]

Wed, 3 Sep 2014 15:58:30 GMT

For some reason lib.povray.org is sending html files with the text/plain
mime type, which means that the browser will show the HTML source rather
than the rendered page. For example

http://lib.povray.org/collection/warprubikscube/warp%201.01/wrc.html

-- 
                                                          - Warp

[Le Forgeron] Re: Contributing to the object library [4233 days 18 hours and 23 minutes ago]

Wed, 3 Sep 2014 10:26:18 GMT

Le 03/09/2014 12:17, Maurizio Paolini a Ã©crit :
> As additional info: when I try to "login" into lib.povray.org the form that
> appears asks for "Your six-digit user ID (supplied in confirmation email)."
> I don't have any confirmation email, and it sounds strange that it does not
> ask for a username.
> 

IIRC, there is no user name at login, only the six digit (which map to
the user).

It's an old system.

> Maurizio
> 
> Le_Forgeron <lef### [at] freefr> wrote:
>> Le 02/09/2014 22:04, Maurizio Paolini a ÃƒÂ©crit :
>>> Hello all,
>>>
>>> I would like to contribute to the object library (lib.povray.org) with
>>> an include file for the Rubik's Magic.
>>>
>>> When I try to register an error appears saying "Too many registrations
>>> from your address".  However I think I never registered before and
>>> in any case if I try to login I cannot find any way to recover a "forgotten"
>>> password.
>>>
>>> What am I doing wrong?
>>>
>>> Cheers,
>>> Maurizio Paolini
>>>
>>>
>> I will try to look at it, once back at home.
>>
>>
>>
>> --
>> Just because nobody complains does not mean all parachutes are perfect.
> 
> 
> 


-- 
Just because nobody complains does not mean all parachutes are perfect.

[Maurizio Paolini] Re: Contributing to the object library [4233 days 18 hours and 29 minutes ago]

Wed, 3 Sep 2014 10:20:00 GMT

As additional info: when I try to "login" into lib.povray.org the form that
appears asks for "Your six-digit user ID (supplied in confirmation email)."
I don't have any confirmation email, and it sounds strange that it does not
ask for a username.

Maurizio

Le_Forgeron <lef### [at] freefr> wrote:
> Le 02/09/2014 22:04, Maurizio Paolini a Ã©crit :
> > Hello all,
> >
> > I would like to contribute to the object library (lib.povray.org) with
> > an include file for the Rubik's Magic.
> >
> > When I try to register an error appears saying "Too many registrations
> > from your address".  However I think I never registered before and
> > in any case if I try to login I cannot find any way to recover a "forgotten"
> > password.
> >
> > What am I doing wrong?
> >
> > Cheers,
> > Maurizio Paolini
> >
> >
> I will try to look at it, once back at home.
>
>
>
> --
> Just because nobody complains does not mean all parachutes are perfect.

[Le Forgeron] Re: Contributing to the object library [4233 days 22 hours and 48 minutes ago]

Wed, 3 Sep 2014 06:00:41 GMT

Le 02/09/2014 22:04, Maurizio Paolini a Ã©crit :
> Hello all,
> 
> I would like to contribute to the object library (lib.povray.org) with
> an include file for the Rubik's Magic.
> 
> When I try to register an error appears saying "Too many registrations
> from your address".  However I think I never registered before and
> in any case if I try to login I cannot find any way to recover a "forgotten"
> password.
> 
> What am I doing wrong?
> 
> Cheers,
> Maurizio Paolini
> 
> 
I will try to look at it, once back at home.



-- 
Just because nobody complains does not mean all parachutes are perfect.

[Maurizio Paolini] Contributing to the object library [4234 days 8 hours and 44 minutes ago]

Tue, 2 Sep 2014 20:05:01 GMT

Hello all,

I would like to contribute to the object library (lib.povray.org) with
an include file for the Rubik's Magic.

When I try to register an error appears saying "Too many registrations
from your address".  However I think I never registered before and
in any case if I try to login I cannot find any way to recover a "forgotten"
password.

What am I doing wrong?

Cheers,
Maurizio Paolini

[Cousin Ricky] Re: noisy rendering of a polynomial "cube" [4353 days 4 hours and 24 minutes ago]

Wed, 7 May 2014 00:25:01 GMT

"Lars R." <rou### [at] gmxnet> wrote:
> Problem: The object looks noisy, even with "sturm" enabled. :-(
>
> How can I get a smooth rendering? Is it possible for "poly" objects to
> enforce some "precomputing" or the like?
>
> I rendered with
>
>   -ibutterfly.pov +d +v -p +w800 +h600 +sp8 +ep8 +a0.1 +am2 +r3
>
> it took 3½ minutes, with -a it took 27 seconds but looks very ugly due
> to the noises. :-(

I converted it to an isosurface.  It takes 80% more time, but at least it's
smooth.
________________________________________________

isosurface
{ function
  {   pow (x, 6) + pow (y, 6) + pow (z, 6)
    - 3 * (pow (x, 4) + pow (y, 4) + pow (z, 4))
  }
  max_gradient 115
  contained_by { box { -2, 2 } }

  pigment { color rgbf<1,0.7,0.2,0.5> }
//  normal { granite 0.1 }
  finish { phong 0.6 }
  interior { ior 1.5 }
}
________________________________________________

[FractRacer] Re: noisy rendering of a polynomial "cube" [4386 days 14 hours and 51 minutes ago]

Thu, 3 Apr 2014 13:58:20 GMT

Le 01/04/2014 21:32, FractRacer a Ã©crit :
> Le 01/04/2014 13:19, Lars R. a Ã©crit :
>>> [â€¦]
>>> If you don't need transparent object
>>
>> I need it, hence I made it semi-transparent and refractive. I like the
>> "gummi bear look".
>>
>> Lars R.
>>
> I don't know why but, after some tries, it seems that only the
> polynomial and poly objects are affected by this noise with filtered
> colors.
> We need developper's help here, I can't explain more, sorry.
>
> Lionel :(

See the post /noise with polynomial object/ in p.bugreports.

Lionel.

-- 
Do not judge my words, judge my actions.

---
Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
http://www.avast.com

[FractRacer] Re: noisy rendering of a polynomial "cube" [4388 days 9 hours and 16 minutes ago]

Tue, 1 Apr 2014 19:32:39 GMT

Le 01/04/2014 13:19, Lars R. a Ã©crit :
>> [â€¦]
>> If you don't need transparent object
>
> I need it, hence I made it semi-transparent and refractive. I like the
> "gummi bear look".
>
> Lars R.
>
I don't know why but, after some tries, it seems that only the 
polynomial and poly objects are affected by this noise with filtered 
colors.
We need developper's help here, I can't explain more, sorry.

Lionel :(
-- 
Do not judge my words, judge my actions.

---
Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
http://www.avast.com

[Lars R ] Re: noisy rendering of a polynomial "cube" [4388 days 17 hours and 29 minutes ago]

Tue, 1 Apr 2014 11:19:56 GMT

> [â€¦]
> If you don't need transparent object

I need it, hence I made it semi-transparent and refractive. I like the
"gummi bear look".

Lars R.

[FractRacer] Re: noisy rendering of a polynomial "cube" [4388 days 19 hours and 23 minutes ago]

Tue, 1 Apr 2014 09:25:32 GMT

Le 01/04/2014 10:23, Lars R. a Ã©crit :
>>> The noisy look is a combined effect of the filtered color of the
>>> object and the checkered plane which is reflected on and in the
>>> object. If you want no noisy effect here, you have to set filter to
>>> 0 or change the pattern of the plane.
>>
>> I have said some stupidity, the checkered plane is not in cause,
>> only the filtered color cause the noisy effect. Maybe it is a
>> side-effect of the polynomial object, since the noise is not present
>> with a box.
>
> I know. But how can I fix that? (No, replacing the poly with a box is
> not an option. ;-))
>
> L.
>
>
If you don't need transparent object, you just have to change the color 
like this:

pigment { color rgb <1,0.7,0.2> }
and remove the interior statement.

Lionel.
-- 
Do not judge my words, judge my actions.

---
Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
http://www.avast.com

[Lars R ] Re: noisy rendering of a polynomial "cube" [4388 days 20 hours and 26 minutes ago]

Tue, 1 Apr 2014 08:23:00 GMT

>> The noisy look is a combined effect of the filtered color of the 
>> object and the checkered plane which is reflected on and in the 
>> object. If you want no noisy effect here, you have to set filter to
>> 0 or change the pattern of the plane.
> 
> I have said some stupidity, the checkered plane is not in cause,
> only the filtered color cause the noisy effect. Maybe it is a
> side-effect of the polynomial object, since the noise is not present
> with a box.

I know. But how can I fix that? (No, replacing the poly with a box is
not an option. ;-))

L.

[FractRacer] Re: noisy rendering of a polynomial "cube" [4389 days 13 hours and 16 minutes ago]

Mon, 31 Mar 2014 15:33:22 GMT

Le 31/03/2014 17:17, FractRacer a Ã©crit :
>   The noisy look is a combined effect of the filtered color of the
> object and the checkered plane which is reflected on and in the object.
> If you want no noisy effect here, you have to set filter to 0 or change
> the pattern of the plane.
>

I have said some stupidity, the checkered plane is not in cause, only 
the filtered color cause the noisy effect. Maybe it is a side-effect of 
the polynomial object, since the noise is not present with a box.

Lionel.

-- 
Do not judge my words, judge my actions.

---
Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
http://www.avast.com

[FractRacer] Re: noisy rendering of a polynomial "cube" [4389 days 13 hours and 32 minutes ago]

Mon, 31 Mar 2014 15:17:06 GMT

Le 31/03/2014 15:16, Lars R. a Ã©crit :
> Problem: The object looks noisy, even with "sturm" enabled. :-(
>
> How can I get a smooth rendering? Is it possible for "poly" objects to
> enforce some "precomputing" or the like?
>
> I rendered with
>
>    -ibutterfly.pov +d +v -p +w800 +h600 +sp8 +ep8 +a0.1 +am2 +r3
>
> it took 3Â½ minutes, with -a it took 27 seconds but looks very ugly due
> to the noises. :-(
>
>
> Lars R.
>
  The noisy look is a combined effect of the filtered color of the 
object and the checkered plane which is reflected on and in the object. 
If you want no noisy effect here, you have to set filter to 0 or change 
the pattern of the plane.

Lionel.

-- 
Do not judge my words, judge my actions.

---
Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
http://www.avast.com

[Lars R ] noisy rendering of a polynomial "cube" [4389 days 15 hours and 32 minutes ago]

Mon, 31 Mar 2014 13:16:43 GMT

Problem: The object looks noisy, even with "sturm" enabled. :-(

How can I get a smooth rendering? Is it possible for "poly" objects to
enforce some "precomputing" or the like?

I rendered with

  -ibutterfly.pov +d +v -p +w800 +h600 +sp8 +ep8 +a0.1 +am2 +r3

it took 3Â½ minutes, with -a it took 27 seconds but looks very ugly due
to the noises. :-(


Lars R.

[Kenneth] Re: Problems with bubble.inc [4417 days 15 hours and 54 minutes ago]

Mon, 3 Mar 2014 12:55:01 GMT

"mone" <mon### [at] alienenterprisesde> wrote:

>
> #include "bubble.inc"
> // Example from bubble.inc file
> #declare bblTexture = texture {finish {ambient 0.3 diffuse 0.1 reflection 0.25
> specular 1 roughness 0.001} pigment {color rgbf <1,1,1,0.7>}}
> #declare bubbleGenerator =
> mBubbleGenerator(0,0.9,0,0,6.5,0,2.4,2.7,0.0005,0.0006,70,bblTexture)

The #declare is not really necessary (even though the author of the bubbles code
suggests it.) You can instead just place this in your scene:

mBubbleGenerator(0,0.9,0,0,6.5,0,2.4,2.7,0.0005,0.0006,70,bblTexture)

.... with no object{...} wrapper. This is because, inside the bubble #macro, the
bubbles are in a union{...}. So the macro itself is like an already- #declared
'object', waiting to be used. (However, if you want to translate or scale the
bubbles in your scene, then an object wrapper would be necessary.)

I had not worked with this macro before; it's very interesting and produces a
nice result. But the two values fBblHeightRngS and fBblHeightRngE seem to be
somewhat non-intuitive.

[mone] Re: Problems with bubble.inc [4418 days 15 hours and 34 minutes ago]

Sun, 2 Mar 2014 13:15:01 GMT

>
> Hello,
>
> The last line of your code declare only the object, you must call the
> object, add the following to your code:
> object {bubbleGenerator}
>
> Lionel.
>
> --
> Do not judge my words, judge my actions.
>
> ---
> Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est
 active.
> http://www.avast.com



Ah, I see. Now it works! Thank you very much, Lionel!


Simone

[FractRacer] Re: Problems with bubble.inc [4418 days 15 hours and 44 minutes ago]

Sun, 2 Mar 2014 13:04:35 GMT

Le 02/03/2014 13:52, mone a écrit :
> // perspective (default) camera
> camera {
>    location  <0.0, 2.0, -8.0>
>    look_at   <0.0, 0.0,  0.0>
>    right     x*image_width/image_height
>
> }
>
> // An area light (creates soft shadows)
> // WARNING: This special light can significantly slow down rendering times!
> light_source {
>    0*x                 // light's position (translated below)
>    color rgb 1.0       // light's color
>    area_light
>    <8, 0, 0> <0, 0, 8> // lights spread out across this distance (x * z)
>    4, 4                // total number of lights in grid (4x*4z = 16 lights)
>    adaptive 0          // 0,1,2,3...
>    jitter              // adds random softening of light
>    circular            // make the shape of the light circular
>    orient              // orient light
>    translate <40, 80, -40>   // <x y z> position of light
> }
>
>
>
>
> // An area light (creates soft shadows)
> // WARNING: This special light can significantly slow down rendering times!
> light_source {
>    0*x                 // light's position (translated below)
>    color rgb 1.0       // light's color
>    area_light
>    <8, 0, 0> <0, 0, 8> // lights spread out across this distance (x * z)
>    4, 4                // total number of lights in grid (4x*4z = 16 lights)
>    adaptive 0          // 0,1,2,3...
>    jitter              // adds random softening of light
>    circular            // make the shape of the light circular
>    orient              // orient light
>    translate <40, 80, 40>   // <x y z> position of light
> }
>
>   // set a color of the background (sky)
> background { color rgb <0.4, 0.4, 0.4> }
>
>
>
> #include "bubble.inc"
> // Example from bubble.inc file
> #declare bblTexture = texture {finish {ambient 0.3 diffuse 0.1 reflection 0.25
> specular 1 roughness 0.001} pigment {color rgbf <1,1,1,0.7>}}
> #declare bubbleGenerator =
> mBubbleGenerator(0,0.9,0,0,6.5,0,2.4,2.7,0.0005,0.0006,70,bblTexture)

Hello,

The last line of your code declare only the object, you must call the 
object, add the following to your code:
object {bubbleGenerator}

Lionel.

-- 
Do not judge my words, judge my actions.

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.com

[mone] Problems with bubble.inc [4418 days 15 hours and 54 minutes ago]

Sun, 2 Mar 2014 12:55:01 GMT

Hi,

I need some nice bubbles for a nearly finished illustration, so I've checked out
the "Carbonated fluid bubble generator" from the objects collection.


I just dumped a camera and two area lights and a background into the scene (see
below) and added the lines with the example from the .inc file.

However, I can't find a single bubble in the rendered image (tried to fiddle
around with the camera position and lights abit, but still I don't see
anything).

Any suggestions, what could be the problem?

Thanks a lot,

Simone

--------

// perspective (default) camera
camera {
  location  <0.0, 2.0, -8.0>
  look_at   <0.0, 0.0,  0.0>
  right     x*image_width/image_height

}

// An area light (creates soft shadows)
// WARNING: This special light can significantly slow down rendering times!
light_source {
  0*x                 // light's position (translated below)
  color rgb 1.0       // light's color
  area_light
  <8, 0, 0> <0, 0, 8> // lights spread out across this distance (x * z)
  4, 4                // total number of lights in grid (4x*4z = 16 lights)
  adaptive 0          // 0,1,2,3...
  jitter              // adds random softening of light
  circular            // make the shape of the light circular
  orient              // orient light
  translate <40, 80, -40>   // <x y z> position of light
}




// An area light (creates soft shadows)
// WARNING: This special light can significantly slow down rendering times!
light_source {
  0*x                 // light's position (translated below)
  color rgb 1.0       // light's color
  area_light
  <8, 0, 0> <0, 0, 8> // lights spread out across this distance (x * z)
  4, 4                // total number of lights in grid (4x*4z = 16 lights)
  adaptive 0          // 0,1,2,3...
  jitter              // adds random softening of light
  circular            // make the shape of the light circular
  orient              // orient light
  translate <40, 80, 40>   // <x y z> position of light
}

 // set a color of the background (sky)
background { color rgb <0.4, 0.4, 0.4> }



#include "bubble.inc"
// Example from bubble.inc file
#declare bblTexture = texture {finish {ambient 0.3 diffuse 0.1 reflection 0.25
specular 1 roughness 0.001} pigment {color rgbf <1,1,1,0.7>}}
#declare bubbleGenerator =
mBubbleGenerator(0,0.9,0,0,6.5,0,2.4,2.7,0.0005,0.0006,70,bblTexture)

[Cousin Ricky] Error in license statements [4459 days 1 hour and 39 minutes ago]

Tue, 21 Jan 2014 03:10:01 GMT

On the Object Collection submission screen, in the help documents 02using.html
and 04contributing.html, and in all the downloaded README*.html files, the
license statement reads "Lesser General Purpose License."  It should actually be
"Lesser General Public License."  Can someone, perhaps Jerome, fix this error?

Also, I faithfully reproduced this error in all of my submissions.  I have
already made the corrections on my local system; if it isn't too much trouble,
may I upload them to p.b.s-f to replace those on the server?

[Friedrich] Re: Povray3.7 "pavement" pattern collection [4482 days 14 hours and 17 minutes ago]

Sat, 28 Dec 2013 14:31:52 GMT

Am 23.12.2013 12:20, schrieb Lars R.:
> I discovered the new "pavement" pattern in Pov 3.7 and I like it. But
> the documentation of it is very limited.
>
> So I created a gallery of objects that show all possible pavements and
> ... found its rule, I think.
>
> I think the documentation should contain an image showing all possible
> pavements, in a rendered or in a schematic image.  Visual examples that
> show how 'form', 'interior' and 'exterior' influenced the pattern are
> still missing.
>
> I'd also like to see a formula for the gradient within each tile.
>

May be it help also if you look at the examples in:
scenes/templates/Textures_Materials/pavement/__index.htm
and:
scenes/templates/Textures_Materials/tiling/__index.htm

Respective in the Windows version:
insert menu/Pattern 2/ ...


Friedrich

[Samuel Benge] Re: Povray3.7 "pavement" pattern collection [4486 days 9 hours and 14 minutes ago]

Tue, 24 Dec 2013 19:35:01 GMT

Thanks, Lars. I made a couple feeble attempts at puzzling out the rules
governing the pavement pattern, but being only halfhearted attempts, I didn't
get very far. Downloaded for future reference!

Sam

[Thomas de Groot] Re: Povray3.7 "pavement" pattern collection [4487 days 16 hours and 34 minutes ago]

Mon, 23 Dec 2013 12:15:12 GMT

On 23-12-2013 12:20, Lars R. wrote:
> What do you think?
>

This seems very useful to me.

Thomas

[Lars R ] Povray3.7 "pavement" pattern collection [4487 days 17 hours and 28 minutes ago]

Mon, 23 Dec 2013 11:21:12 GMT

I discovered the new "pavement" pattern in Pov 3.7 and I like it. But
the documentation of it is very limited.

So I created a gallery of objects that show all possible pavements and
... found its rule, I think.

I think the documentation should contain an image showing all possible
pavements, in a rendered or in a schematic image.  Visual examples that
show how 'form', 'interior' and 'exterior' influenced the pattern are
still missing.

I'd also like to see a formula for the gradient within each tile.


What do you think?

				Lars R.

[Cousin Ricky] Re: Problems with Object Collection uploader [4664 days 5 hours and 54 minutes ago]

Sat, 29 Jun 2013 22:55:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> A quick note: the upload limit of 20 is now removed (well, far higher,
> but do not abuse that :-) ).

This will be hard to abuse.  Uploading my 36 files was tedious enough!

ASSuming that the previous administrator would not set a bad example, 53 files
is not abuse, because that's how many files are in Chris Bartlett's Rope module.

> Thanks Cousin Ricky for reporting the problem.

You're welcome.

[Cousin Ricky] Re: Problems with Object Collection uploader [4664 days 8 hours and 54 minutes ago]

Sat, 29 Jun 2013 19:55:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> If you have more than 20 files for a contribution, I would suggest that
> you create the contribution (even if only 20 files get in) and then post
> a message in this group with a pointer to the missing files so that I
> add then manually afterwards.

I have posted the missing files to povray.binaries.images.

[Le Forgeron] Re: Problems with Object Collection uploader [4669 days 17 hours and 20 minutes ago]

Mon, 24 Jun 2013 11:28:30 GMT

A quick note: the upload limit of 20 is now removed (well, far higher,
but do not abuse that :-) ).

Thanks Cousin Ricky for reporting the problem.

[Le Forgeron] Re: Problems with Object Collection uploader [4673 days 17 hours and 26 minutes ago]

Thu, 20 Jun 2013 11:22:45 GMT

Le 19/06/2013 23:51, Cousin Ricky nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>>
>> From previous investigation, the uploading process stops as soon as one
>> filename is not conform: only lower case, no special characters.
> 
> My filenames are all vanilla lowercase a-z, 0-9, underscore, and the occasional
> hyphen.  No hyphens in my latest attempt.
> 

Good :-)
>> I did not find any limit of 20 in scripts, but may be it is more related
>> to the length-limit of the URL ? or something else.
>> I need to investigate.
> 
> Such a limit would not make sense in the scripts.  Someone would have had to
> deliberately set the limit at least 2 years after the Object Collection was up
> and running; but some of Chris Bartlett's contributions have more than 20 files,
> so it wouldn't have made sense for /him/ to do it.

It seems that 20 is the default of php.
(well, not "seems", "is", at least for the current version on various
systems)
For the time being, that's the limiting factor.
If you have more than 20 files for a contribution, I would suggest that
you create the contribution (even if only 20 files get in) and then post
a message in this group with a pointer to the missing files so that I
add then manually afterwards.

> 
> I don't know much about PHP, but an unintentional configuration change doesn't
> sound implausible, perhaps during an upgrade.
> 
>> Is there a reason you need a colon ?
> 
> This was my intended description for RoundEdge 1.3:
> ________________________________________________________________________________
> 
> A set of macros and functions to facilitate modeling of rounded edges with CSG,
> isosurfaces, and blobs.
> 
> In version 1.3:
>  - Some of the functions are given more intuitive names.
>  - Important notes are added to the documentation concerning sqrt() calls with
> the alternate isosurface blob function, and the demo scene is changed
> accordingly.
> ________________________________________________________________________________

The colon has been added in the description of 1.3 of rounded edges.
I do not have the power to allow the colon in the submission form :-/

[Cousin Ricky] Re: Problems with Object Collection uploader [4674 days 6 hours and 54 minutes ago]

Wed, 19 Jun 2013 21:55:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
>
> From previous investigation, the uploading process stops as soon as one
> filename is not conform: only lower case, no special characters.

My filenames are all vanilla lowercase a-z, 0-9, underscore, and the occasional
hyphen.  No hyphens in my latest attempt.

> I did not find any limit of 20 in scripts, but may be it is more related
> to the length-limit of the URL ? or something else.
> I need to investigate.

Such a limit would not make sense in the scripts.  Someone would have had to
deliberately set the limit at least 2 years after the Object Collection was up
and running; but some of Chris Bartlett's contributions have more than 20 files,
so it wouldn't have made sense for /him/ to do it.

I don't know much about PHP, but an unintentional configuration change doesn't
sound implausible, perhaps during an upgrade.

> Is there a reason you need a colon ?

This was my intended description for RoundEdge 1.3:
________________________________________________________________________________

A set of macros and functions to facilitate modeling of rounded edges with CSG,
isosurfaces, and blobs.

In version 1.3:
 - Some of the functions are given more intuitive names.
 - Important notes are added to the documentation concerning sqrt() calls with
the alternate isosurface blob function, and the demo scene is changed
accordingly.
________________________________________________________________________________

[Le Forgeron] Re: Problems with Object Collection uploader [4674 days 14 hours and 50 minutes ago]

Wed, 19 Jun 2013 13:59:10 GMT

Le 17/06/2013 11:16, Le_Forgeron nous fit lire :
> Le 16/06/2013 20:44, Cousin Ricky nous fit lire :
>> My past few times updating RoundEdge uploaded only 20 files each time.  The one
>> change on my end I could think of was that I had switched from Windows to Linux.
>>  At the first failure, the Web browser I used was either Opera or Konqueror, so
>> I then tried Chrome.  Same problem.  I then looked at my Linux configuration,
>> but couldn't find anything relevant, other than possibly a limitation of 1024
>> simultaneous open files (which certainly couldn't have been responsible for this
>> problem).
>>
>> Last night, I tried an upload from Windows 7, something I was loathe to do, as I
>> find Windows 7 a stressful and infuriating experience.  Even worse, the upload
>> screen would not function properly in Chrome, so I had to resort to Internet
>> Explorer.  Same problem.
>>
>> Here are my findings:
>>  - The 20 file upload limitation is independent of the Web Browser.
>>  - The 20 file upload limitation is independent of operating system.
>>  - This has not always been a problem.  Some contributions from 2009 or
>>    earlier (including version 1.0 of RoundEdge) have more than 20 files.
> 
> From previous investigation, the uploading process stops as soon as one
> filename is not conform: only lower case, no special characters.
> The sad thing is that the check is performed only when sending the page,
> and the feedback in case of error is not that good (and already
> processed files are kept, IIRC).
> 
> I did not find any limit of 20 in scripts, but may be it is more related
> to the length-limit of the URL ? or something else.
> I need to investigate.
> 

Indeed, nothing in the code, but the default configuration of php on the
server.

> 
>>  - The file upload buttons ("Choose File") do not work in Chrome for
>>    Windows 7.  They work fine in Chrome for Linux.
>>  - Colons are not allowed in the description field!  Is there a reason
>>    for this?
> 
> Colons are not alone on that (# & { | } [ ] < > / and \ are also not
> allowed). semi-colons are ok, as well as dot.
> I do not know the reason to not allow : in description, maybe due to
> protection against url-spamming, or avoiding pre-formatted text. or just
> no reason (anyway, only classical-7 bits ascii)
> 
> Is there a reason you need a colon ?
>

[Le Forgeron] Re: Problems with Object Collection uploader [4676 days 19 hours and 32 minutes ago]

Mon, 17 Jun 2013 09:16:55 GMT

Le 16/06/2013 20:44, Cousin Ricky nous fit lire :
> My past few times updating RoundEdge uploaded only 20 files each time.  The one
> change on my end I could think of was that I had switched from Windows to Linux.
>  At the first failure, the Web browser I used was either Opera or Konqueror, so
> I then tried Chrome.  Same problem.  I then looked at my Linux configuration,
> but couldn't find anything relevant, other than possibly a limitation of 1024
> simultaneous open files (which certainly couldn't have been responsible for this
> problem).
> 
> Last night, I tried an upload from Windows 7, something I was loathe to do, as I
> find Windows 7 a stressful and infuriating experience.  Even worse, the upload
> screen would not function properly in Chrome, so I had to resort to Internet
> Explorer.  Same problem.
> 
> Here are my findings:
>  - The 20 file upload limitation is independent of the Web Browser.
>  - The 20 file upload limitation is independent of operating system.
>  - This has not always been a problem.  Some contributions from 2009 or
>    earlier (including version 1.0 of RoundEdge) have more than 20 files.

From previous investigation, the uploading process stops as soon as one
filename is not conform: only lower case, no special characters.
The sad thing is that the check is performed only when sending the page,
and the feedback in case of error is not that good (and already
processed files are kept, IIRC).

I did not find any limit of 20 in scripts, but may be it is more related
to the length-limit of the URL ? or something else.
I need to investigate.


>  - The file upload buttons ("Choose File") do not work in Chrome for
>    Windows 7.  They work fine in Chrome for Linux.
>  - Colons are not allowed in the description field!  Is there a reason
>    for this?

Colons are not alone on that (# & { | } [ ] < > / and \ are also not
allowed). semi-colons are ok, as well as dot.
I do not know the reason to not allow : in description, maybe due to
protection against url-spamming, or avoiding pre-formatted text. or just
no reason (anyway, only classical-7 bits ascii)

Is there a reason you need a colon ?

> 
> Unrelated:
>  - Checking the server for updates from the README file fails if the
>    contributor's username contains spaces.
> 
> I hope someone can be found soon to take over administration of the Object
> Collection server, so that these problems can be addressed.
> 
>

[Cousin Ricky] Problems with Object Collection uploader [4677 days 9 hours and 59 minutes ago]

Sun, 16 Jun 2013 18:50:01 GMT

My past few times updating RoundEdge uploaded only 20 files each time.  The one
change on my end I could think of was that I had switched from Windows to Linux.
 At the first failure, the Web browser I used was either Opera or Konqueror, so
I then tried Chrome.  Same problem.  I then looked at my Linux configuration,
but couldn't find anything relevant, other than possibly a limitation of 1024
simultaneous open files (which certainly couldn't have been responsible for this
problem).

Last night, I tried an upload from Windows 7, something I was loathe to do, as I
find Windows 7 a stressful and infuriating experience.  Even worse, the upload
screen would not function properly in Chrome, so I had to resort to Internet
Explorer.  Same problem.

Here are my findings:
 - The 20 file upload limitation is independent of the Web Browser.
 - The 20 file upload limitation is independent of operating system.
 - This has not always been a problem.  Some contributions from 2009 or
   earlier (including version 1.0 of RoundEdge) have more than 20 files.
 - The file upload buttons ("Choose File") do not work in Chrome for
   Windows 7.  They work fine in Chrome for Linux.
 - Colons are not allowed in the description field!  Is there a reason
   for this?

Unrelated:
 - Checking the server for updates from the README file fails if the
   contributor's username contains spaces.

I hope someone can be found soon to take over administration of the Object
Collection server, so that these problems can be addressed.

[Cousin Ricky] CoffeeMug upgraded slightly [4704 days 2 hours and 9 minutes ago]

Tue, 21 May 2013 02:40:01 GMT

The other day, while trying to model black coffee (high absorption, no
scattering), I noticed an artifact where the top of the coffee met the wall of
the mug.  This looked superficially like an epsilon-related artifact, but
scaling the whole scene to use a smaller POV-unit would have been too difficult.
 Instead, I introduced a contact angle to the meniscus, hoping that would
mitigate the problem.

Alas, unless I used an unrealistically wide contact angle, there was little
difference.  Still, I figured, I went through figuring out all this geometry, I
might as well share it, so I’ve uploaded a new version of CoffeeMug with user
control of the meniscus.  The new version is 1.3a.  Carbonation for the rum and
Coke is still not included, but the documentation now provides a link to where
you can get some.

Much to my surprise, CoffeeMug has been my most popular contribution, with 1723
downloads (not including my own sanity checks).  It is the 13th most popular
object overall, out of 87.

[Cousin Ricky] Re: Metal textures uploaded [4731 days 3 hours and 59 minutes ago]

Wed, 24 Apr 2013 00:50:00 GMT

On March 9, 2013 "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> After a short exchange with clipka yesterday in the "HDRI settings" thread in
> p.b.i, and a quick trip to a hardware store, I decided to go with a combination
> of specular highlight and high brilliance for diffuse surfaces.  However, when I
> started adapting my macros for the Object Collection in 2011, mindful of my
> ignorance of quantum electrodynamics, I implemented the transfer functions as,
> well, functions.  This was comforting.  If you don't like my decision from
> yesterday, you can always do something like:
>
> #include "rc3metal.inc"
> #undef RC3M_fn_Brilliance
> #declare RC3M_fn_Brilliance = function (x) { 1 }
> #undef RC3M_fn_Specular
> #declare RC3M_fn_Specular = function (x) { x }

Always one to second-guess myself, I wrote a macro that enables me to second-
guess myself with one line of code.  It is part of RC3Metal version 1.1.  To
make the above adjustment in RC3Metal 1.1, use:

   RC3Metal_Set_functions (0.0, 1.0)

[Le Forgeron] Re: RoundEdge update and Object Collection uploa... [4765 days 11 hours ago]

Wed, 20 Mar 2013 17:49:04 GMT

Le 20/03/2013 17:01, Cousin Ricky nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Thanks. I took on me to fix your rlp entry in the Object Collection,
>> adding the missing files (with rename to lower cases, and dismissal of
>> '&' symbol), and changing square to Square on the relevant file.
> 
> I notice that no new version was added, and that the old one was fixed in-place,
> still under Sam's name.  Does this mean that you have privileged access to the
> server?

Indeed, it's just fresh on me.

[Cousin Ricky] Re: RoundEdge update and Object Collection uploa... [4765 days 12 hours and 24 minutes ago]

Wed, 20 Mar 2013 16:25:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Thanks. I took on me to fix your rlp entry in the Object Collection,
> adding the missing files (with rename to lower cases, and dismissal of
> '&' symbol), and changing square to Square on the relevant file.

I notice that no new version was added, and that the old one was fixed in-place,
still under Sam's name.  Does this mean that you have privileged access to the
server?

[Le Forgeron] Re: RoundEdge update and Object Collection uploa... [4768 days 9 hours and 50 minutes ago]

Sun, 17 Mar 2013 18:58:49 GMT

Le 05/03/2013 20:55, Samuel Benge nous fit lire :
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
>> "Samuel Benge" <stb### [at] hotmailcom> wrote:
>>> What is up with the Object Collection, anyway? Has it been hacked or something?
>>> When I go to download my file, it's called "POVCollection_507620.zip-_r_n_r_n"
>>> and doesn't contain the include file, the html help file or the example scenes.
>>> Is this happening with all submissions?
>>
>> It's not happening with all of them; rlp and possibly ConvexLens are the only
>> ones I've downloaded that seem deficient.
> 
> I went ahead and uploaded it to p.b.s-f for now:
> 
>
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.5136498a673f3afd2165ae730%40news.povray.org%3E/

Thanks. I took on me to fix your rlp entry in the Object Collection,
adding the missing files (with rename to lower cases, and dismissal of
'&' symbol), and changing square to Square on the relevant file.

( http://lib.povray.org/usersguide/04contributing.html#Files )

ConvexLens is rather empty (a single gif, non conformant filename) which
just stat "test" all over the image. Anyone has a working copy ?

[Cousin Ricky] Metal textures uploaded [4776 days 8 hours and 44 minutes ago]

Sat, 9 Mar 2013 20:05:01 GMT

I have uploaded module RC3Metal for creating metallic textures. It can be
downloaded at:

http://lib.povray.org/searchcollection/index2.php?objectName=RC3Metal&contributorTag=Cousin%20Ricky

Soon after downloading POV-Ray in 2003, I noticed a couple of problems with the
metallic textures in the standard include files: they don't take advantage of
POV-Ray's built-in metallic reflection, and they have unrealistically high
ambient values. The second issue has been noted by other POVers, and becomes a
problem when radiosity is used. The POV-Ray textures are probably the way they
are for legacy reasons, so I don't expect them to change.

It quickly became clear to me that diffuse and ambient levels should decrease as
specular reflection increases, so in 2004, I wrote a macro to do just that. The
radiosity problem is mooted by POV-Ray 3.7, but it's still useful to have finish
values automatically adjusted in response to specular reflection.

Along the way, I tried gathering spectral reflectance data for various metals.
This was a frustrating, and probably futile, effort. Search "RSOCP overkill"
for some 2007 results of that effort. Since 2011, I've been procrastinating
about finding more confident colors (entailing spending money on or borrowing
equipment), but finally decided to post what I have, mindful that the user is
not obligated to use them. My sense is that many of the values are good for
new, polished surfaces, but too high for most every day surfaces.

After a short exchange with clipka yesterday in the "HDRI settings" thread in
p.b.i, and a quick trip to a hardware store, I decided to go with a combination
of specular highlight and high brilliance for diffuse surfaces. However, when I
started adapting my macros for the Object Collection in 2011, mindful of my
ignorance of quantum electrodynamics, I implemented the transfer functions as,
well, functions. This was comforting. If you don't like my decision from
yesterday, you can always do something like:

#include "rc3metal.inc"
#undef RC3M_fn_Brilliance
#declare RC3M_fn_Brilliance = function (x) { 1 }
#undef RC3M_fn_Specular
#declare RC3M_fn_Specular = function (x) { x }

[Samuel Benge] Re: RoundEdge update and Object Collection uploa... [4780 days 8 hours and 49 minutes ago]

Tue, 5 Mar 2013 20:00:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "Samuel Benge" <stb### [at] hotmailcom> wrote:
> > What is up with the Object Collection, anyway? Has it been hacked or something?
> > When I go to download my file, it's called "POVCollection_507620.zip-_r_n_r_n"
> > and doesn't contain the include file, the html help file or the example scenes.
> > Is this happening with all submissions?
>
> It's not happening with all of them; rlp and possibly ConvexLens are the only
> ones I've downloaded that seem deficient.

I went ahead and uploaded it to p.b.s-f for now:

http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.5136498a673f3afd2165ae730%40news.povray.org%3E/

[Cousin Ricky] Re: RoundEdge update and Object Collection uploa... [4781 days 23 hours and 14 minutes ago]

Mon, 4 Mar 2013 05:35:00 GMT

"Samuel Benge" <stb### [at] hotmailcom> wrote:
> What is up with the Object Collection, anyway? Has it been hacked or something?
> When I go to download my file, it's called "POVCollection_507620.zip-_r_n_r_n"
> and doesn't contain the include file, the html help file or the example scenes.
> Is this happening with all submissions?

It's not happening with all of them; rlp and possibly ConvexLens are the only
ones I've downloaded that seem deficient.  (I do not know the story with
ConvexLens.)  What's been happening to me is that it limits uploads to 20 files.
The upload page will let you select as many files as you like, but it fails to
upload any more than the first 20.  This has not always been the case, so
something broke somewhere along the line.

At this time, no information is available about the state of the Object
Collection.  Chris Cason is looking into it; I'll leave it up to him to make any
announcements. On my end, I'm investigating the possibility of some file limit
deep within my Linux configuration that's breaking my uploads.

[Samuel Benge] Re: RoundEdge update and Object Collection uploa... [4782 days 6 hours and 4 minutes ago]

Sun, 3 Mar 2013 22:45:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "Samuel Benge" <stb### [at] hotmailcom> wrote:
> > If you meant that my rlp upload is broken somehow, then fixing it is something I
> > /can/ do :)
>
> Yes, that is what I meant.

What is up with the Object Collection, anyway? Has it been hacked or something?
When I go to download my file, it's called "POVCollection_507620.zip-_r_n_r_n"
and doesn't contain the include file, the html help file or the example scenes.
Is this happening with all submissions?

Sam

[Cousin Ricky] Re: RoundEdge update and Object Collection uploa... [4782 days 6 hours and 59 minutes ago]

Sun, 3 Mar 2013 21:50:00 GMT

"Samuel Benge" <stb### [at] hotmailcom> wrote:
> If you meant that my rlp upload is broken somehow, then fixing it is something I
> /can/ do :)

Yes, that is what I meant.

[Samuel Benge] Re: RoundEdge update and Object Collection uploa... [4782 days 8 hours and 4 minutes ago]

Sun, 3 Mar 2013 20:45:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
>
> To Sam Benge:  If you can get a working upload of rlp, that would be most
> welcome.

Hi Ricky,

You want a version that works with your macros? If so, that might be quite
difficult given that rlp objects are composed of many types of geometries, torii
being one.

If you meant that my rlp upload is broken somehow, then fixing it is something I
/can/ do :)

Sam

[Cousin Ricky] RoundEdge update and Object Collection upload pr... [4784 days 5 hours and 49 minutes ago]

Fri, 1 Mar 2013 23:00:01 GMT

I added elliptical toroid meshes to RoundEdge, and also #version'd it to 3.5, as
that version is still used in circumstances where upgrading is not feasible.
The module is at:

http://lib.povray.org/searchcollection/index2.php?objectName=RoundEdge&contributorTag=Cousin%20Ricky

(An isosurface implementation of elliptical toroids is still on my wish list, as
meshes cannot be blobbed without a modeling tool; however, my brain isn't as
mathematically adept as it was during my first semester of college.)

To Sam Benge: If you can get a working upload of rlp, that would be most
welcome.
_________________________________________

I decided to upload the new RoundEdge on the chance that the previous upload
failed due to a network glitch on my end. Again, the upload was incomplete. In
both attempts, exactly 20 files were uploaded, making a random glitch unlikely.
I used different Web clients for the two uploads, so that isn't the issue
either.

As before, the missing files are all illustrations for the user manual. They
are named roundedge_nn.jpg, where nn is a number from 14 to 30. The images will
have to be regenerated even if you are installing over an old version of
RoundEdge, as the numbering of the illustrations has changed. You can do this
by running POV-Ray with these command line arguments:

+iroundedge.pov +w240 +h180 declare=Rad=1 +a0.05 +am2 +r3 +kff30 +oroundedge_
+sf14

If you are using POV-Ray 3.7, add +fj Compression=90 to the command line. If
you are using POV-Ray 3.5 or 3.6, you will need to convert the illustrations to
JPEG format. To match the quality of the other illustrations, use quality 90
and subsampling 1x1,1x1,1x1.

[Cousin Ricky] Re: HTML documents served as text/plain [4847 days 22 hours and 14 minutes ago]

Fri, 28 Dec 2012 06:35:10 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> Is a collection administrator aware that HTML documentation is served as
> text/plain?

Chris Cason reports that this is intentional, for security reasons.

So, never mind.

[Alain] Re: Avoid all-lowercase identifiers [4988 days 6 hours and 55 minutes ago]

Thu, 9 Aug 2012 21:54:08 GMT

Le 8/8/2012 11:29 AM, Cousin Ricky a écrit :
> "BertvdB" <ber### [at] kpnmailnl> wrote:
>>   Rape, Murder
>> Before you know they will stop attending church on sunday
>
> I stopped going to church less than 2 years after discovering POV-Ray.
> Coincidence?
>
> I haven't raped or murdered anyone yet, though.  Satan needs to work on me a
> little more.
>
>

In my case, it's been over 40 years since I last went to a church. OK, I 
did visite some, but in the same way as one visit a museum, so, it don't 
count.

Nothing bad yet... :P

[Cousin Ricky] Re: Avoid all-lowercase identifiers [4989 days 13 hours and 14 minutes ago]

Wed, 8 Aug 2012 15:35:01 GMT

"BertvdB" <ber### [at] kpnmailnl> wrote:
>  Rape, Murder
> Before you know they will stop attending church on sunday

I stopped going to church less than 2 years after discovering POV-Ray.
Coincidence?

I haven't raped or murdered anyone yet, though.  Satan needs to work on me a
little more.

[Le Forgeron] Re: Avoid all-lowercase identifiers [4992 days 20 hours and 43 minutes ago]

Sun, 5 Aug 2012 08:06:03 GMT

Le 04/08/2012 18:43, clipka nous fit lire :
> 
> It's dead because modern IDEs have stuff like "IntelliSense" that allow
> you to see a variable's type just by hovering the mouse over it.
> POV-Ray's IDE doesn't have such a feature.

Well, povclipse does.

The povray's Window editor does not, due to its old age.

[Thomas de Groot] Re: Avoid all-lowercase identifiers [4992 days 21 hours and 56 minutes ago]

Sun, 5 Aug 2012 06:52:39 GMT

On 5-8-2012 4:11, Alain wrote:
> Anyway, religions are only feeble attempts at making sence of the world
> around us when you lack the proper tools and knowlege.
> Look at the Bible, ponder how many centuries it have been passed along
> by oral tradition, and you can only conclude that it's a compilation of
> legends, miths, tall tales, fables and fire side stories...

Amen :-)

Thomas

[Cousin Ricky] Re: Avoid all-lowercase identifiers [4993 days 2 hours and 14 minutes ago]

Sun, 5 Aug 2012 02:35:00 GMT

"BertvdB" <ber### [at] kpnmailnl> wrote:
> As a addition to this, why don't we use the hungarian notation. Makes coding
> much clearer.
> http://en.wikipedia.org/wiki/Hungarian_notation
> This will explain what I mean

The purpose of the naming standard is to insure that the various modules work
well with each other, not to enforce political correctness.  I would add playing
nice with POV-Ray itself, which is why I made my suggestion.  While Hungarian
notation, or a less dogmatic variation thereof, may be a good idea, it does not
further the purpose of the standard.

[Alain] Re: Avoid all-lowercase identifiers [4993 days 2 hours and 38 minutes ago]

Sun, 5 Aug 2012 02:10:51 GMT

Le 8/4/2012 4:20 PM, BertvdB a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>> That said, I absolutely, positively agree that Hungarian notation should
>> /not/ be forced on anyone - just like any other religion :-P
>>
>>
>>> Better use meaningful identifiers!
>>
>> Always a good idea, whether using Hungarian notation or not.
>   Rape, Murder
> Before you know they will stop attending church on sunday
>
>
>
Anyway, religions are only feeble attempts at making sence of the world 
around us when you lack the proper tools and knowlege.
Look at the Bible, ponder how many centuries it have been passed along 
by oral tradition, and you can only conclude that it's a compilation of 
legends, miths, tall tales, fables and fire side stories...

[BertvdB] Re: Avoid all-lowercase identifiers [4993 days 8 hours and 24 minutes ago]

Sat, 4 Aug 2012 20:25:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> That said, I absolutely, positively agree that Hungarian notation should
> /not/ be forced on anyone - just like any other religion :-P
>
>
> > Better use meaningful identifiers!
>
> Always a good idea, whether using Hungarian notation or not.
 Rape, Murder
Before you know they will stop attending church on sunday

[clipka] Re: Avoid all-lowercase identifiers [4993 days 12 hours and 5 minutes ago]

Sat, 4 Aug 2012 16:43:54 GMT

Am 04.08.2012 18:16, schrieb Le_Forgeron:
> Le 04/08/2012 10:15, BertvdB nous fit lire :
>> As a addition to this, why don't we use the hungarian notation. Makes coding
>> much clearer.
>> http://en.wikipedia.org/wiki/Hungarian_notation
>> This will explain what I mean
>
> Because there is so few "types" in SDL. Value, vectors... from 2D to 5D...
> what else ? a spline ?
>
> Hungarian notation is dead. Let it rest.

It's dead because modern IDEs have stuff like "IntelliSense" that allow 
you to see a variable's type just by hovering the mouse over it. 
POV-Ray's IDE doesn't have such a feature.

It's also quite a common practice in POV-Ray to prefix function names 
with "f", texture variables with "t" or "tx", material variables with 
"m" or "mt", etc.

That said, I absolutely, positively agree that Hungarian notation should 
/not/ be forced on anyone - just like any other religion :-P


> Better use meaningful identifiers!

Always a good idea, whether using Hungarian notation or not.

[Le Forgeron] Re: Avoid all-lowercase identifiers [4993 days 12 hours and 32 minutes ago]

Sat, 4 Aug 2012 16:16:54 GMT

Le 04/08/2012 10:15, BertvdB nous fit lire :
> As a addition to this, why don't we use the hungarian notation. Makes coding
> much clearer.
> http://en.wikipedia.org/wiki/Hungarian_notation
> This will explain what I mean

Because there is so few "types" in SDL. Value, vectors... from 2D to 5D...
what else ? a spline ?

Hungarian notation is dead. Let it rest.

Better use meaningful identifiers!

[BertvdB] Re: Avoid all-lowercase identifiers [4993 days 20 hours and 29 minutes ago]

Sat, 4 Aug 2012 08:20:01 GMT

As a addition to this, why don't we use the hungarian notation. Makes coding
much clearer.
http://en.wikipedia.org/wiki/Hungarian_notation
This will explain what I mean

[Alain] Re: Avoid all-lowercase identifiers [4994 days 5 hours and 31 minutes ago]

Fri, 3 Aug 2012 23:18:03 GMT

Le 8/1/2012 10:55 AM, clipka a écrit :
> Am 01.08.2012 08:59, schrieb Thomas de Groot:
>> On 1-8-2012 5:46, Cousin Ricky wrote:
>>> It has long been a POV-Ray recommendation that identifiers have at
>>> least one
>>> uppercase letter, although this is not enforced.  This recommendation
>>> has
>>> practical significance, as we recently saw in "Spanish Patio -Parse
>>> Error" in
>>> povray.general.
>>>
>>> I propose that this recommendation be incorporated as policy into the
>>> Object
>>> Collection naming standards.  In other words, in order for a
>>> submission to be
>>> rated "fully compliant," all identifiers introduced must have at least
>>> one
>>> uppercase letter.
>>>
>>
>> I second that.
>
> I third that.
>
I totaly agree with all of you.

[clipka] Re: Avoid all-lowercase identifiers [4996 days 13 hours and 54 minutes ago]

Wed, 1 Aug 2012 14:55:18 GMT

Am 01.08.2012 08:59, schrieb Thomas de Groot:
> On 1-8-2012 5:46, Cousin Ricky wrote:
>> It has long been a POV-Ray recommendation that identifiers have at
>> least one
>> uppercase letter, although this is not enforced.  This recommendation has
>> practical significance, as we recently saw in "Spanish Patio -Parse
>> Error" in
>> povray.general.
>>
>> I propose that this recommendation be incorporated as policy into the
>> Object
>> Collection naming standards.  In other words, in order for a
>> submission to be
>> rated "fully compliant," all identifiers introduced must have at least
>> one
>> uppercase letter.
>>
>
> I second that.

I third that.

[Thomas de Groot] Re: Avoid all-lowercase identifiers [4996 days 21 hours and 49 minutes ago]

Wed, 1 Aug 2012 06:59:49 GMT

On 1-8-2012 5:46, Cousin Ricky wrote:
> It has long been a POV-Ray recommendation that identifiers have at least one
> uppercase letter, although this is not enforced.  This recommendation has
> practical significance, as we recently saw in "Spanish Patio -Parse Error" in
> povray.general.
>
> I propose that this recommendation be incorporated as policy into the Object
> Collection naming standards.  In other words, in order for a submission to be
> rated "fully compliant," all identifiers introduced must have at least one
> uppercase letter.
>

I second that.

Thomas

[Cousin Ricky] Avoid all-lowercase identifiers [4997 days and 59 minutes ago]

Wed, 1 Aug 2012 03:50:01 GMT

It has long been a POV-Ray recommendation that identifiers have at least one
uppercase letter, although this is not enforced.  This recommendation has
practical significance, as we recently saw in "Spanish Patio -Parse Error" in
povray.general.

I propose that this recommendation be incorporated as policy into the Object
Collection naming standards.  In other words, in order for a submission to be
rated "fully compliant," all identifiers introduced must have at least one
uppercase letter.

[Cousin Ricky] Should the POV-Ray version be included in the pr... [5008 days and 39 minutes ago]

Sat, 21 Jul 2012 04:10:00 GMT

The Object Collection help says, "You should avoid prerequisites and
dependencies wherever possible, ..." but mentions "a specific version of
POV-Ray" as a possible dependency.

I cannot guarantee that any of my contributions will work with any POV-Ray
earlier than 3.5, and one of them works only with 3.6 or later.  My practice so
far has been to put an appropriate #version (usually 3.6) in my .inc files, but
(in keeping with common practice) to leave the prereqs blank.  Is there a
working assumption that the user will be using a reasonably recent version of
POV-Ray?

Nearly all of the objects in the collection have empty prereqs files, but I
cannot believe that all of them will work with POV-Ray 3.1 and older, given the
major syntax changes mentioned in the 3.5 documentation.  It seems that some
sort of unwritten assumption is already being made by the contributors.

[Cousin Ricky] Re: Upload skipped almost half my files [5046 days 2 hours and 24 minutes ago]

Wed, 13 Jun 2012 02:25:01 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> I just tried to update the RoundEdge module.  It has 34 files, but only 20 of
> them were uploaded.

The missing files are all illustrations for the user manual, named
roundedge_nn.jpg, where nn is a number from 15 to 28.  They can be generated by
running POV-Ray with these command line arguments:

+iroundedge.pov +w240 +h180 declare=Rad=1 +a0.05 +am2 +r3 +kff28 +oroundedge_
+sf15

If you are using POV-Ray 3.7, add +fj Compression=90 to the command line.

If you are using POV-Ray 3.6, you will need to convert the illustrations to JPEG
format.  To match the quality of the other illustrations, use quality 90 and
subsampling 1x1,1x1,1x1.

I will re-upload the module after I am assured that the problem will not recur.

[Cousin Ricky] Upload skipped almost half my files [5049 days 16 hours and 34 minutes ago]

Sat, 9 Jun 2012 12:15:01 GMT

I just tried to update the RoundEdge module.  It has 34 files, but only 20 of
them were uploaded.

[Tail Kinker] Re: IK Skeleton [5158 days 17 hours and 18 minutes ago]

Tue, 21 Feb 2012 11:31:25 GMT

Uploaded a new version of IK Skeleton.  Added a waist joint, and allowed 
for rotating it in three dimensions instead of only one.  The 
documentation reflects these changes, and the html version includes two 
flash animations showing off what the package can do.  (I'll be adding 
at least four more of those over time.)

You can grab it at http://tailkinker.contrabandent.com/software.htm

[Tail Kinker] Re: IK Skeleton [5160 days and 8 minutes ago]

Mon, 20 Feb 2012 04:41:24 GMT

On 12-02-18 01:36 PM, Tail Kinker wrote:
> I have created an IK skeleton macro package, if anybody is interested.
> You can grab it from my web page, at:
>
> <http://tailkinker.contrabandent.com/software.htm>

Whoops!  A bug got past me.  I've uploaded a fixed version.

[Tail Kinker] IK Skeleton [5161 days 10 hours and 13 minutes ago]

Sat, 18 Feb 2012 18:36:02 GMT

I have created an IK skeleton macro package, if anybody is interested. 
You can grab it from my web page, at:

<http://tailkinker.contrabandent.com/software.htm>

[Cousin Ricky] HTML documents served as text/plain [5168 days 8 hours and 39 minutes ago]

Sat, 11 Feb 2012 20:10:01 GMT

Is a collection administrator aware that HTML documentation is served as
text/plain?  If the object comes with an HTML file (e.g., NetBall), and one
clicks on the "i" icon on the Object Categories page or "More Detail" on the
Object Search page, the file is displayed as unformatted source text.

[Le Forgeron] Re: Has this interesting isosurface a common name? [5192 days 7 hours and 1 minute ago]

Wed, 18 Jan 2012 21:47:46 GMT

Le 18/01/2012 11:34, Lars R. nous fit lire :
> Do anyone know a common name of this nice thing? :-)
> 
> 		Lars R.

As a 6th order polynomial, it might (unchecked!) be some aspect of Boy's
Surface.

You might enjoy Goursat's dodecaedric surfaces...

http://www.mathcurve.com/surfaces/goursat/goursat.shtml

[Alain] Re: Has this interesting isosurface a common name? [5192 days 7 hours and 3 minutes ago]

Wed, 18 Jan 2012 21:46:26 GMT

Le 2012/01/18 05:34, Lars R. a écrit :
> I tried to render a 3D version of the quadrifolium
> (http://mathworld.wolfram.com/Quadrifolium.html)
> but my first try of a 3D variant of its formula does not work. So I
> changed the formula arbitrarily and got a nice object, see attachment.
>
> Do anyone know a common name of this nice thing? :-)
>
> 		Lars R.
>
>
> -----<snip>-----
> isosurface
> {
> // does not work:
> //	function { pow(x*x + y*y + z*z  , 3) - 12 * x*x * y*y * z*z }
>
> // works and looks interesting:
>          function { pow(x*x + y*y + z*z  , 3) - 12 * x*y*z }
>          contained_by { box{ -1,+1 } }
>          accuracy 0.001
>          max_gradient 100
>
>
>          pigment { color rgb<0.3,0.6,0.9>  }
>          finish { phong 0.1 reflection 0.2 }
>
>          rotate y*30
> }
>
>
> light_source {<-3,6,-9>  color 1
>          area_light<0.5,0,0>,<0, 0.5, 0>, 4,4 jitter
> }
>
> //light_source {<1,9,-2>  color 0.4 }
>
> box
> {
>          <-9.9,-9.9,-9.9>  ,<+9.9,+9.9, +9.9>
>          pigment { checker color rgb 0.5 color rgb 0.77 }
> }
>
> camera
> {
>          location<0,5,-9>
>          look_at<0,0,0>
>          angle 20.3
> }
>
> -----<snap>-----
It looks like the SP hybrid electron orbitals.

Alain

[Lars R ] Has this interesting isosurface a common name? [5192 days 18 hours and 14 minutes ago]

Wed, 18 Jan 2012 10:34:54 GMT

I tried to render a 3D version of the quadrifolium
(http://mathworld.wolfram.com/Quadrifolium.html)
but my first try of a 3D variant of its formula does not work. So I
changed the formula arbitrarily and got a nice object, see attachment.

Do anyone know a common name of this nice thing? :-)

		Lars R.


-----<snip>-----
isosurface
{
// does not work:
//	function { pow(x*x + y*y + z*z  , 3) - 12 * x*x * y*y * z*z }

// works and looks interesting:
        function { pow(x*x + y*y + z*z  , 3) - 12 * x*y*z }
        contained_by { box{ -1,+1 } }
        accuracy 0.001
        max_gradient 100


        pigment { color rgb<0.3,0.6,0.9> }
        finish { phong 0.1 reflection 0.2 }

        rotate y*30
}


light_source { <-3,6,-9> color 1
        area_light <0.5,0,0>, <0, 0.5, 0>, 4,4 jitter
}

//light_source { <1,9,-2> color 0.4 }

box
{
        <-9.9,-9.9,-9.9> , <+9.9,+9.9, +9.9>
        pigment { checker color rgb 0.5 color rgb 0.77 }
}

camera
{
        location <0,5,-9>
        look_at <0,0,0>
        angle 20.3
}

-----<snap>-----

[Cousin Ricky] Re: OC modules by the numbers [5369 days 8 hours and 34 minutes ago]

Mon, 25 Jul 2011 20:15:01 GMT

Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
> And so...? Conclusions?   :-)

Well, I wasn't looking for conclusions, but one thing does stand out:  There is
some mechanism that prioritizes the primary administrator's submissions for
compliance review.  What that mechanism might be, I'm not going to speculate.

[Warp] Re: OC modules by the numbers [5369 days 17 hours and 9 minutes ago]

Mon, 25 Jul 2011 11:39:39 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> Number of user-rated modules: 3
> Average rating: 4.33

> Number of modules with user comments: 3

  I feel a bit sad because I'm pretty certain that if this service had been
set up 10 years ago, in the same timespan that it has been now there would
probably have been several hundreds (if not over a thousand) modules, and
a significantly higher percentage of ratings and comments.

  (OTOH the average *quality* of the modules would probably have been
significantly lower. If there's anything positive about the situation is
that mostly the experienced hard-core users are submitting their include
files, and they tend to be of rather high quality.)

-- 
                                                          - Warp

[Thomas de Groot] Re: OC modules by the numbers [5369 days 21 hours and 27 minutes ago]

Mon, 25 Jul 2011 07:21:56 GMT

And so...? Conclusions?   :-)

Thomas

[Cousin Ricky] OC modules by the numbers [5370 days 3 hours and 9 minutes ago]

Mon, 25 Jul 2011 01:40:01 GMT

So I was bored.  I went through the Object Collection search page, and this is
what I came up with:

Number of modules: 84

Number of modules with on-line documentation: 32

Number of modules that include thumbnails: 83

Number of modules with multiple versions: 27

Number of modules with multiple contributors: 3

Number of modules rated "Completely Compliant" by the contributor: 81

Number of modules confirmed "Completely Compliant" by an administrator: 12

Number of modules contributed by someone other than chrisb that are confirmed
"Completely Compliant" by an administrator: 1

Number of modules with prerequisites: 1
(I did not count DisplayCase or Galaxy.)

Number of user-rated modules: 3
Average rating: 4.33

Number of modules with user comments: 3

[Cousin Ricky] Got an error checking for updates from a README ... [5371 days 22 hours and 14 minutes ago]

Sat, 23 Jul 2011 06:35:01 GMT

The error message is:

   GF002 - Error: Contributor 0 contains more than one word/entry.

It seems to happen whenever the name of the contributor is 2 words.

[Patrick Elliott] Re: Electric cars searched [5444 days 9 hours ago]

Wed, 11 May 2011 19:48:32 GMT

On 5/11/2011 6:03 AM, Roland Mösl wrote:
> On 2011-05-10 00:27, Patrick Elliott wrote:
>> On 5/9/2011 9:29 AM, Roland Mösl wrote:
>>> I just have a new project
>>> where I need different
>>> electric cars for the scene
>>>
>>> Special important,
>>> thy BYD e6
>>> http://car.pege.org/type/byd-e6.htm
>>>
>>> Also wanted Nissan Leaf
>>> Chevrolet Volt
>>> BYD F3DM
>>> Opel Ampera
>>>
>> No Tesla?
>>
>> That said, you could try google search, then clicking "images", to just
>> get pictures of them.
>
> I have pictures most of them myself.
>
> But I would like to have 3D data for rendering.
Ah.. That isn't likely. Someone has to build the models, and since they 
are so new, the only people likely to have those are the companies that 
made them in the first place.

[Roland Mösl] Re: Electric cars searched [5444 days 15 hours and 45 minutes ago]

Wed, 11 May 2011 13:03:54 GMT

On 2011-05-10 00:27, Patrick Elliott wrote:
> On 5/9/2011 9:29 AM, Roland Mösl wrote:
>> I just have a new project
>> where I need different
>> electric cars for the scene
>>
>> Special important,
>> thy BYD e6
>> http://car.pege.org/type/byd-e6.htm
>>
>> Also wanted Nissan Leaf
>> Chevrolet Volt
>> BYD F3DM
>> Opel Ampera
>>
> No Tesla?
>
> That said, you could try google search, then clicking "images", to just
> get pictures of them.

I have pictures most of them myself.

But I would like to have 3D data for rendering.

[Patrick Elliott] Re: Electric cars searched [5446 days 6 hours and 22 minutes ago]

Mon, 9 May 2011 22:27:21 GMT

On 5/9/2011 9:29 AM, Roland Mösl wrote:
> I just have a new project
> where I need different
> electric cars for the scene
>
> Special important,
> thy BYD e6
> http://car.pege.org/type/byd-e6.htm
>
> Also wanted Nissan Leaf
> Chevrolet Volt
> BYD F3DM
> Opel Ampera
>
No Tesla?

That said, you could try google search, then clicking "images", to just 
get pictures of them.

[Roland Mösl] Electric cars searched [5446 days 12 hours and 19 minutes ago]

Mon, 9 May 2011 16:29:59 GMT

I just have a new project
where I need different
electric cars for the scene

Special important,
thy BYD e6
http://car.pege.org/type/byd-e6.htm

Also wanted Nissan Leaf
Chevrolet Volt
BYD F3DM
Opel Ampera

[Cor] Re: Rope macros [5458 days 14 hours and 49 minutes ago]

Wed, 27 Apr 2011 14:00:00 GMT

I have another question about the rope macro:
Is it possible to create a rope composed of a different number of strands than
3?
Two twisted strands for example?

[stbenge] Re: Rounded L-Prism (rlp) v0.2 [5672 days 6 hours and 50 minutes ago]

Sat, 25 Sep 2010 21:59:06 GMT

Carlo C. wrote:
> Sam, thanks! but I think you forgot several files in the zip file.

Hmm. I used Filzip, am looking at the archive now, and everything is 
there as it should be. These are the items that should be present:

rlp.inc
rlp.html
rlp_Arch.pov
rlp_Bevel&Types.pov
rlp_Border.pov
rlp_Compound.pov
rlp_Multi.pov
rlp_P.pov
rlp_Shapes.pov

I've attached a .7z file, so hopefully everything is OK with it. Sorry, 
I don't know what went wrong \:

If any moderators are reading this, I wonder how I can edit my 
contribution to the objects collection? If I upload the files again with 
the same version number, will it overwrite the previous files? I'd also 
like to make the documentation visible, as I seemed to have botched that...

Sam

[Carlo C ] Re: Rounded L-Prism (rlp) v0.2 [5672 days 10 hours and 19 minutes ago]

Sat, 25 Sep 2010 18:30:01 GMT

stbenge <myu### [at] hotmailcom> wrote:
> Hello,
>
> I've released a second version of rlp. New in this version: sharp
> corners; pointset transforms; improved autofitting; and more.
>
> You can get it here:
>
http://lib.povray.org/searchcollection/index2.php?objectName=rlp&version=0.2&contributorTag=Sam
>
> Here's a demo image:
> http://lib.povray.org/collection/rlp/sam%200.2/rlp.jpg
>
>  From the upper left:
>
> 1) joining an rlp object with existing geometry
> 2) custom beveling and bevel types for individual subsets
> 3) the obligatory 'P'
> 4) the four subset shape primitives with various styles
> 5) making borders by shifting a subset
> 6) joining more than one rlp object
> 7) using subset transforms
>
> All of the above are from the examples included in the package.
>
> I hope you like it!
>
> Sam

Sam, thanks! but I think you forgot several files in the zip file.

[stbenge] Rounded L-Prism (rlp) v0.2 [5673 days 3 hours and 4 minutes ago]

Sat, 25 Sep 2010 01:45:25 GMT

Hello,

I've released a second version of rlp. New in this version: sharp 
corners; pointset transforms; improved autofitting; and more.

You can get it here:
http://lib.povray.org/searchcollection/index2.php?objectName=rlp&version=0.2&contributorTag=Sam

Here's a demo image:
http://lib.povray.org/collection/rlp/sam%200.2/rlp.jpg

 From the upper left:

1) joining an rlp object with existing geometry
2) custom beveling and bevel types for individual subsets
3) the obligatory 'P'
4) the four subset shape primitives with various styles
5) making borders by shifting a subset
6) joining more than one rlp object
7) using subset transforms

All of the above are from the examples included in the package.

I hope you like it!

Sam