See example images posted in p.b.i

SkySim.inc is the macro, SkySimTestGround.pov is a simple example of a 
scene using the macro.

Post a reply to this message

Attachments:
Download 'windows-1252' (7 KB) Download 'windows-1252' (3 KB)

On 7-6-2013 13:51, scott wrote:
> SkySim.inc is the macro, SkySimTestGround.pov is a simple example of a
> scene using the macro.

Very good. Thanks very much indeed. Much better of course than the 
simple example I gave :-)

Thomas

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> See example images posted in p.b.i
>
> SkySim.inc is the macro, SkySimTestGround.pov is a simple example of a
> scene using the macro.

Hello, I try your macro but I've got an error on line:
#local xyYtoR = function (x,y,Y){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
-0.4986)*Y/SkyMaxLuminance }
where Y seems undefined.
I am wrong?

Post a reply to this message

Le 13-06-30 07:55, Fractracer a écrit :
> scott <sco### [at] scottcom> wrote:
>> See example images posted in p.b.i
>>
>> SkySim.inc is the macro, SkySimTestGround.pov is a simple example of a
>> scene using the macro.
>
> Hello, I try your macro but I've got an error on line:
> #local xyYtoR = function (x,y,Y){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
> -0.4986)*Y/SkyMaxLuminance }
> where Y seems undefined.
> I am wrong?
>

Try calling the function this way:
xyYtoR(x,y,1)

This is a reason to NOT use "X", "Y" or "Z" as user variable names. It 
can lead to some confusion.



Alain

Post a reply to this message

> Hello, I try your macro but I've got an error on line:
> #local xyYtoR = function (x,y,Y){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
> -0.4986)*Y/SkyMaxLuminance }
> where Y seems undefined.
> I am wrong?

Y is one of the parameters for the function, so it becomes defined when 
the function is called. What version of POV are you using? I've tried it 
on 3.6 and 3.7 with no issues.

On 30/06/2013 18:14, Alain wrote:
 > This is a reason to NOT use "X", "Y" or "Z" as user variable names.
 > It can lead to some confusion.

I wouldn't normally do such a thing, but the colour space used by the 
algorithm is Yxy. My POV version didn't complain or get confused about 
using Y and y, so this makes the equations easier to read. I suppose I 
could have used _Y or something.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Hello, I try your macro but I've got an error on line:
> > #local xyYtoR = function (x,y,Y){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
> > -0.4986)*Y/SkyMaxLuminance }
> > where Y seems undefined.
> > I am wrong?
>
> Y is one of the parameters for the function, so it becomes defined when
> the function is called. What version of POV are you using? I've tried it
> on 3.6 and 3.7 with no issues.
>
> On 30/06/2013 18:14, Alain wrote:
>  > This is a reason to NOT use "X", "Y" or "Z" as user variable names.
>  > It can lead to some confusion.
>
> I wouldn't normally do such a thing, but the colour space used by the
> algorithm is Yxy. My POV version didn't complain or get confused about
> using Y and y, so this makes the equations easier to read. I suppose I
> could have used _Y or something.

It works (not fine but with no errors) when I change Y by z:
#local xyYtoR = function (x,y,z){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
-0.4986)*Y/SkyMaxLuminance }
I know this is not the good value but I try to see what happens.
I use v3.6 and v3.7 with the same result.

Post a reply to this message

> It works (not fine but with no errors) when I change Y by z:
> #local xyYtoR = function (x,y,z){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
> -0.4986)*Y/SkyMaxLuminance }
> I know this is not the good value but I try to see what happens.
> I use v3.6 and v3.7 with the same result.

If you change the Y to z in the parameter list then just change the Y to 
z in the equation too:

#local xyYtoR = function (x,y,z){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
-0.4986)*z/SkyMaxLuminance }

That should then work the same as the original version.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > It works (not fine but with no errors) when I change Y by z:
> > #local xyYtoR = function (x,y,z){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
> > -0.4986)*Y/SkyMaxLuminance }
> > I know this is not the good value but I try to see what happens.
> > I use v3.6 and v3.7 with the same result.
>
> If you change the Y to z in the parameter list then just change the Y to
> z in the equation too:
>
> #local xyYtoR = function (x,y,z){ (x/y* 3.2406  -1.5372 + (1-x-y)/y *
> -0.4986)*z/SkyMaxLuminance }
>
> That should then work the same as the original version.

Thanks, I go to try this when my render in works will stop.

Post a reply to this message

> Thanks, I go to try this when my render in works will stop.

OK but I still find it odd you get an error when using Y as a parameter. 
What is the exact error you get, can you copy and paste it here for us 
to see?

If you copy the below code into an empty POV document (so just 1 line) - 
does it work?

#local xyYtoR = function (x,y,Y){ x+y+Y }

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Thanks, I go to try this when my render in works will stop.
>
> OK but I still find it odd you get an error when using Y as a parameter.
> What is the exact error you get, can you copy and paste it here for us
> to see?
>
> If you copy the below code into an empty POV document (so just 1 line) -
> does it work?
>
> #local xyYtoR = function (x,y,Y){ x+y+Y }

It work with a simple scene, I can't understand what's happens!!! With
sky_sim.inc ...
OOOPS!!! I've find, I have a variable declared Y... Excuse me...

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Thanks, I go to try this when my render in works will stop.
>
> OK but I still find it odd you get an error when using Y as a parameter.
> What is the exact error you get, can you copy and paste it here for us
> to see?
>
> If you copy the below code into an empty POV document (so just 1 line) -
> does it work?
>
> #local xyYtoR = function (x,y,Y){ x+y+Y }

OOOPS!!! after trying this (its work) I have re-read my code and I've seen a Y
declared by me (I know, #local is better than #declare).
I'm a stupID!!

Post a reply to this message

>> #local xyYtoR = function (x,y,Y){ x+y+Y }
>
> OOOPS!!! after trying this (its work) I have re-read my code and I've seen a Y
> declared by me (I know, #local is better than #declare).
> I'm a stupID!!

Not your fault, no matter what variable name you choose to use there is 
always the chance someone else is using that same name elsewhere. 
Another reason to stick to x,y,z for function parameters.

Post a reply to this message

> See example images posted in p.b.i
>
> SkySim.inc is the macro, SkySimTestGround.pov is a simple example of a
> scene using the macro.

Updated .inc file attached to fix the bug found by Thomas in p.b.i

Post a reply to this message

Attachments:
Download 'windows-1252' (7 KB)

scott <sco### [at] scottcom> wrote:
> >> #local xyYtoR = function (x,y,Y){ x+y+Y }
> >
> > OOOPS!!! after trying this (its work) I have re-read my code and I've seen a Y
> > declared by me (I know, #local is better than #declare).
> > I'm a stupID!!

You are not stupid, Fractracer.  It is a design flaw in POV-Ray.

> Not your fault, no matter what variable name you choose to use there is
> always the chance someone else is using that same name elsewhere.
> Another reason to stick to x,y,z for function parameters.

If the ideal of using meaningful identifier names isn't reason enough, sticking
to x, y, and z won't help if the function has more than three arguments.  That's
why I do things like this:

   #declare RE_fn_Wheel = function (x, y, z, RE_P0_RMajor, RE_P1_rMinor)

Where "RE_" is a prefix reserved by the include file (i.e., users are instructed
not to declare any identifiers that begin with "RE_").  Cumbersome yes, but
accidents are avoided.

This happens whenever you declare an identifier and then later use that same
name as a function argument.  (I mentioned this in the p.b.i thread where a
similar issue turned up with macro names.)  Oddly, it doesn't happen if you
declare the identifier /after/ the function is defined.

Post a reply to this message

Great work!

I was just about to do the same thing but while struggling with the math 
to express the pigment functions I luckily found your implementation ;)
But I'm wondering: while you cite the Preetham paper you do use 
different values for the A to C parameters and also for the Perez 
formulation.
Actually I do like the resulting renders better with the original values 
from the Preetham paper (might very well just be a matter of individual 
taste) but I'm curious where the other values did come from.

Also I'm wondering about the multiplication factor of 1000 for the 
zenith luminance. As far as I understand it this formula return the
luminance in cd/m2 therefore this additional multiplication just makes 
the exposure factor unnecessary small.

Here is what I do use (with the originalPreetham/Perez values):

// constant factors
#local AY = 0.1787*Turbidity- 1.4630;
#local BY =-0.3554*Turbidity+ 0.4275;
#local CY =-0.0227*Turbidity+ 5.3251;
#local DY = 0.1206*Turbidity- 2.5771;
#local EY =-0.0670*Turbidity+ 0.3703;

#local Ax =-0.0193*Turbidity- 0.2592;
#local Bx =-0.0665*Turbidity+ 0.0008;
#local Cx =-0.0004*Turbidity+ 0.2125;
#local Dx =-0.0641*Turbidity- 0.8989;
#local Ex =-0.0033*Turbidity+ 0.0452;

#local Ay =-0.0167*Turbidity- 0.2608;
#local By =-0.0950*Turbidity+ 0.0092;
#local Cy =-0.0079*Turbidity+ 0.2102;
#local Dy =-0.0441*Turbidity- 1.6537;
#local Ey =-0.0109*Turbidity+ 0.0529;


#macro computeZenithColor(T,thetas)
  // Calculate luminance

  #local zenithLuminance = ((4.0453*T - 4.9710) * tan( (4.0/9.0 - T/120) 
* (pi-2*thetas) ) - 0.2155*T + 2.4192);
  #if(zenithLuminance<=0)
   #local zenithLuminance=1e-11;
  #end

  // Calculate colour
  #local thetas2 = thetas*thetas;
  #local thetas3 = thetas*thetas2;
  #local T2 = T*T;

  #local zx= ( 0.00166*thetas3 - 0.00375*thetas2 + 0.00209*thetas) * T2 +
             (-0.02903*thetas3 + 0.06377*thetas2 - 0.03202*thetas + 
0.00394) * T +
             ( 0.11693*thetas3 - 0.21196*thetas2 + 0.06052*thetas + 
0.25886);

  #local zy= ( 0.00275*thetas3 - 0.00610*thetas2 + 0.00317*thetas) * T2 +
             (-0.04214*thetas3 + 0.08970*thetas2 - 0.04153*thetas + 
0.00516) * T +
             ( 0.15346*thetas3 - 0.26756*thetas2 + 0.06670*thetas + 
0.26688);

  <zx,zy,zenithLuminance>

#end


-Ive

Post a reply to this message

> But I'm wondering: while you cite the Preetham paper you do use
> different values for the A to C parameters and also for the Perez
> formulation.

I took the values that the Stellarium source code used rather than the 
paper itself, I guess the authors of Stellarium tweaked them a bit. I 
guess you can use whichever set look better for you.

> Also I'm wondering about the multiplication factor of 1000 for the
> zenith luminance. As far as I understand it this formula return the
> luminance in cd/m2 therefore this additional multiplication just makes
> the exposure factor unnecessary small.

The formula in the paper gives the luminance in K cd/m2, that's why the 
1000 factor is in there.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > But I'm wondering: while you cite the Preetham paper you do use
> > different values for the A to C parameters and also for the Perez
> > formulation.
>
> I took the values that the Stellarium source code used rather than the
> paper itself, I guess the authors of Stellarium tweaked them a bit. I
> guess you can use whichever set look better for you.
>
> > Also I'm wondering about the multiplication factor of 1000 for the
> > zenith luminance. As far as I understand it this formula return the
> > luminance in cd/m2 therefore this additional multiplication just makes
> > the exposure factor unnecessary small.
>
> The formula in the paper gives the luminance in K cd/m2, that's why the
> 1000 factor is in there.

Quick question:

How do I convert the units of ExposureFactor to my scene?

In my scene, 20 units = 1 foot.

Thanks!!


Mike

Post a reply to this message

Le 18-03-06 à 09:13, posfan12 a écrit :
> scott <sco### [at] scottcom> wrote:
>>> But I'm wondering: while you cite the Preetham paper you do use
>>> different values for the A to C parameters and also for the Perez
>>> formulation.
>>
>> I took the values that the Stellarium source code used rather than the
>> paper itself, I guess the authors of Stellarium tweaked them a bit. I
>> guess you can use whichever set look better for you.
>>
>>> Also I'm wondering about the multiplication factor of 1000 for the
>>> zenith luminance. As far as I understand it this formula return the
>>> luminance in cd/m2 therefore this additional multiplication just makes
>>> the exposure factor unnecessary small.
>>
>> The formula in the paper gives the luminance in K cd/m2, that's why the
>> 1000 factor is in there.
> 
> Quick question:
> 
> How do I convert the units of ExposureFactor to my scene?
> 
> In my scene, 20 units = 1 foot.
> 
> Thanks!!
> 
> 
> Mike
> 

The formula use meter, a meter = about 39 inches, or 3 feet and 3 inches 
(3.25 feet in 1 m).
There are 10.5625 square feet in a square meter.

Post a reply to this message

Am 07.03.2018 um 03:48 schrieb Alain:

> The formula use meter, a meter = about 39 inches, or 3 feet and 3 inches
> (3.25 feet in 1 m).
> There are 10.5625 square feet in a square meter.

Sorry to be blunt, but with that many decimals, that number is a lie, as
it implies a precision it doesn't have.

As a rule of thumb, whenever you're doing mathematical computations with
approximate values, it is good practice to round the end result to the
lowest number of significant digits of any of the "input" values.

Also, since the UK imperial and US customary units are defined in terms
of the metric system (yes, you UK folks have been using the metric
system ever since 1930, and you US folks even since 1893(*); it's just
been hidden from you :P), that's what I'd recommend to start with:

(A) from the 1930 BSI (UK) / 1933 ASA (US) definition:

1 inch = 25.4 mm = 0.0254 m
1 foot = 12 inch = 0.3048 m

(B) from the 1959 International Yard and Pound Agreement:

1 yard = 0.9144 m
1 foot = 1/3 yard = 0.3048 m

Either way:

1 square foot = 0.09290303 m^2
1/0.09290303 square feet = 1 m^2

These numbers are exact, by virtue of definition of the UK imperial and
US customary units. Alternatively, here's a high-precision approximation:

10,7639104167097223083335055559 square feet = 1 m^2


(* The 1893 Mendenhall Order (US) definition had 1 yard = 3600/3937 m,
which gives slightly different results, and has remained the basis for
the survey foot.)

Post a reply to this message

On 07/03/2018 11:44, clipka wrote:
> Sorry to be blunt, but with that many decimals, that number is a lie, as
> it implies a precision it doesn't have.
> 

You are right of course, if bluntly put.

> As a rule of thumb, whenever you're doing mathematical computations with
> approximate values, it is good practice to round the end result to the
> lowest number of significant digits of any of the "input" values.
> 
> Also, since the UK imperial and US customary units are defined in terms
> of the metric system (yes, you UK folks have been using the metric
> system ever since 1930, and you US folks even since 1893(*); it's just
> been hidden from you :P), that's what I'd recommend to start with:

Now, I would be surprised if people in the UK did not know that. I guess 
I was about 15 or 16 when I was taught it at school.
But as a rule of thumb that an inch is about the length of your thumb's 
distal phalanx. Is good enough for children as they more resemble the 
size of an adult of bygone years.

BTW has anyone heard or seen a ruler where feet are divided into tenths?
Giving the impression that there are 10 "X inches" to a foot.
I saw one once about 30 years ago.


-- 

Regards
     Stephen

Post a reply to this message

Le 18-03-07 à 07:21, Stephen a écrit :

> BTW has anyone heard or seen a ruler where feet are divided into tenths?
> Giving the impression that there are 10 "X inches" to a foot.
> I saw one once about 30 years ago.
> 
> 

Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 1/6, 
1/9 and 1/12.
I've seen one with foot divided into 1/3 and 1/4.

Post a reply to this message

On 07/03/2018 21:00, Alain wrote:
> Le 18-03-07 à 07:21, Stephen a écrit :
> 
>> BTW has anyone heard or seen a ruler where feet are divided into tenths?
>> Giving the impression that there are 10 "X inches" to a foot.
>> I saw one once about 30 years ago.
>>
>>
> 
> Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 1/6, 
> 1/9 and 1/12.
> I've seen one with foot divided into 1/3 and 1/4.

I think it might be industry specific rule.
About 30 years ago. My boss, offshore, took some measurements in the 
toolpusher's office using a rule he found there. After getting whatever 
it was made. It did not fit. He got a bit of a slagging for it. As you 
would. ;-)
He went back up to check only to find that there was 10 "inches" to the 
foot.
Drillers use some strange terms. The anchor chain tension is measured in 
Kilo-pound-inches. I had never heard of that measurement before I had to 
calibrate the load sensors.

-- 

Regards
     Stephen

Post a reply to this message

On 3/7/2018 7:21 AM, Stephen wrote:
> Now, I would be surprised if people in the UK did not know that. I guess 
> I was about 15 or 16 when I was taught it at school.
> But as a rule of thumb that an inch is about the length of your thumb's 
> distal phalanx. Is good enough for children as they more resemble the 
> size of an adult of bygone years.
> 
> BTW has anyone heard or seen a ruler where feet are divided into tenths?
> Giving the impression that there are 10 "X inches" to a foot.
> I saw one once about 30 years ago.
> 
> 

I have a triangular drafting ruler that is like that.


Mike

Post a reply to this message

On 7-3-2018 22:44, Stephen wrote:
> On 07/03/2018 21:00, Alain wrote:
>> Le 18-03-07 à 07:21, Stephen a écrit :
>>
>>> BTW has anyone heard or seen a ruler where feet are divided into tenths?
>>> Giving the impression that there are 10 "X inches" to a foot.
>>> I saw one once about 30 years ago.
>>>
>>>
>>
>> Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 1/6, 
>> 1/9 and 1/12.
>> I've seen one with foot divided into 1/3 and 1/4.
> 
> I think it might be industry specific rule.
> About 30 years ago. My boss, offshore, took some measurements in the 
> toolpusher's office using a rule he found there. After getting whatever 
> it was made. It did not fit. He got a bit of a slagging for it. As you 
> would. ;-)
> He went back up to check only to find that there was 10 "inches" to the 
> foot.
> Drillers use some strange terms. The anchor chain tension is measured in 
> Kilo-pound-inches. I had never heard of that measurement before I had to 
> calibrate the load sensors.
> 

Interesting story. "kilo-pound-inches", could that mean 'thousand pounds 
per inch'? the word kilo being used for the thousand's value?

-- 
Thomas

Post a reply to this message

On 08/03/2018 07:54, Thomas de Groot wrote:
> On 7-3-2018 22:44, Stephen wrote:

>> Drillers use some strange terms. The anchor chain tension is measured 
>> in Kilo-pound-inches. I had never heard of that measurement before I 
>> had to calibrate the load sensors.
>>
> 
> Interesting story. "kilo-pound-inches", could that mean 'thousand pounds 
> per inch'? the word kilo being used for the thousand's value?
> 

Yes kilo is a multiplier and since it is a unit of work it should have 
been KIP, kilo inch pounds which is 112.98 Nm.
I got kpi stuck in my head. :-)

For something so important the transmitter was a simple op amp. Check 
the zero and span against the supplied load cell manufacturers data 
sheet. Easy peasy. :-)


-- 

Regards
     Stephen

Post a reply to this message

On 8-3-2018 9:25, Stephen wrote:
> On 08/03/2018 07:54, Thomas de Groot wrote:
>> On 7-3-2018 22:44, Stephen wrote:
> 
>>> Drillers use some strange terms. The anchor chain tension is measured 
>>> in Kilo-pound-inches. I had never heard of that measurement before I 
>>> had to calibrate the load sensors.
>>>
>>
>> Interesting story. "kilo-pound-inches", could that mean 'thousand 
>> pounds per inch'? the word kilo being used for the thousand's value?
>>
> 
> Yes kilo is a multiplier and since it is a unit of work it should have 
> been KIP, kilo inch pounds which is 112.98 Nm.
> I got kpi stuck in my head. :-)
> 
> For something so important the transmitter was a simple op amp. Check 
> the zero and span against the supplied load cell manufacturers data 
> sheet. Easy peasy. :-)
> 

Easy peasy indeed. I imagine the guys calibrating those data sheets: 
"Hey John! Lets give it a pound more!"  BANG!  ;-)

I am always surprised that we got to the Moon at all, or Mars for that 
matter, where we were able to crash at least once because of 
imperial/metrics confusion... ;-)

-- 
Thomas

Post a reply to this message

On 08/03/2018 09:04, Thomas de Groot wrote:
> On 8-3-2018 9:25, Stephen wrote:
>> On 08/03/2018 07:54, Thomas de Groot wrote:
>>> On 7-3-2018 22:44, Stephen wrote:
>>
>>>> Drillers use some strange terms. The anchor chain tension is 
>>>> measured in Kilo-pound-inches. I had never heard of that measurement 
>>>> before I had to calibrate the load sensors.
>>>>
>>>
>>> Interesting story. "kilo-pound-inches", could that mean 'thousand 
>>> pounds per inch'? the word kilo being used for the thousand's value?
>>>
>>
>> Yes kilo is a multiplier and since it is a unit of work it should have 
>> been KIP, kilo inch pounds which is 112.98 Nm.
>> I got kpi stuck in my head. :-)
>>
>> For something so important the transmitter was a simple op amp. Check 
>> the zero and span against the supplied load cell manufacturers data 
>> sheet. Easy peasy. :-)
>>
> 
> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
> "Hey John! Lets give it a pound more!"  BANG!  ;-)
> 

More likely Pop. The materials used are designed to take the weight and 
are over rated.


> I am always surprised that we got to the Moon at all, or Mars for that 
> matter, where we were able to crash at least once because of 
> imperial/metrics confusion... ;-)
> 

Big mistake mixing units. I may think in imperial but work in metric 
when I can.

-- 

Regards
     Stephen

Post a reply to this message

On 8-3-2018 10:34, Stephen wrote:
> On 08/03/2018 09:04, Thomas de Groot wrote:
>> On 8-3-2018 9:25, Stephen wrote:
>>> On 08/03/2018 07:54, Thomas de Groot wrote:
>>>> On 7-3-2018 22:44, Stephen wrote:
>>>
>>>>> Drillers use some strange terms. The anchor chain tension is 
>>>>> measured in Kilo-pound-inches. I had never heard of that 
>>>>> measurement before I had to calibrate the load sensors.
>>>>>
>>>>
>>>> Interesting story. "kilo-pound-inches", could that mean 'thousand 
>>>> pounds per inch'? the word kilo being used for the thousand's value?
>>>>
>>>
>>> Yes kilo is a multiplier and since it is a unit of work it should 
>>> have been KIP, kilo inch pounds which is 112.98 Nm.
>>> I got kpi stuck in my head. :-)
>>>
>>> For something so important the transmitter was a simple op amp. Check 
>>> the zero and span against the supplied load cell manufacturers data 
>>> sheet. Easy peasy. :-)
>>>
>>
>> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
>> "Hey John! Lets give it a pound more!"  BANG!  ;-)
>>
> 
> More likely Pop. The materials used are designed to take the weight and 
> are over rated.

Sad. I would like a bit of drama ;-)

> 
> 
>> I am always surprised that we got to the Moon at all, or Mars for that 
>> matter, where we were able to crash at least once because of 
>> imperial/metrics confusion... ;-)
>>
> 
> Big mistake mixing units. I may think in imperial but work in metric 
> when I can.
> 

smart. But then you grew up with imperial of course. I find it difficult 
(not that I need it).

-- 
Thomas

Post a reply to this message

On 08/03/2018 12:23, Thomas de Groot wrote:
> On 8-3-2018 10:34, Stephen wrote:

>>>>
>>>
>>> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
>>> "Hey John! Lets give it a pound more!"  BANG!  ;-)
>>>
>>
>> More likely Pop. The materials used are designed to take the weight 
>> and are over rated.
> 
> Sad. I would like a bit of drama ;-)
> 

Your slightest wish is my command.

https://youtu.be/CjzykTQM-4w?t=78

A similar incident happened on the platform I was on. Unfortunately the 
crane driver was not so lucky. He got trapped in the cabin for hours and 
lost a foot and part of his lower leg.

>>
>>
>>> I am always surprised that we got to the Moon at all, or Mars for 
>>> that matter, where we were able to crash at least once because of 
>>> imperial/metrics confusion... ;-)
>>>
>>
>> Big mistake mixing units. I may think in imperial but work in metric 
>> when I can.
>>
> 
> smart. But then you grew up with imperial of course. I find it difficult 
> (not that I need it).
> 

It is difficult and took years of repetition before it became second 
nature. But after learning things like there are 5280 ft in a mile and 
60 mph is 88 ft/s. Not to mention the currency. The metric system is a 
walk in the park.
Also we oldies can add up in our head. Unlike the youth of today.


-- 

Regards
     Stephen

Post a reply to this message

On 08/03/2018 13:26, Stephen wrote:
> Your slightest wish is my command.
> 
> https://youtu.be/CjzykTQM-4w?t=78

I just noticed a follow up video.
The cage the guys are in is galled a Billy Pugh and you are supposed to 
stand on the outside so you don't get trapped if it goes into the sea. I 
used them for my one trip on the Piper. A white knuckle job.

https://www.youtube.com/watch?v=ZD8y7Slx2ow


-- 

Regards
     Stephen

Post a reply to this message

On 07/03/2018 23:29, Mike Horvath wrote:
> On 3/7/2018 7:21 AM, Stephen wrote:
>> Now, I would be surprised if people in the UK did not know that. I 
>> guess I was about 15 or 16 when I was taught it at school.
>> But as a rule of thumb that an inch is about the length of your 
>> thumb's distal phalanx. Is good enough for children as they more 
>> resemble the size of an adult of bygone years.
>>
>> BTW has anyone heard or seen a ruler where feet are divided into tenths?
>> Giving the impression that there are 10 "X inches" to a foot.
>> I saw one once about 30 years ago.
>>
>>
> 
> I have a triangular drafting ruler that is like that.
> 
> 


Hmm I got a set of drafting scale rulers, somewhere in storage. I must 
have a look at them. I think the one I saw was a folding yardstick. My 
great uncle gave them to me when I was at school.


-- 

Regards
     Stephen

Post a reply to this message

Le 18-03-08 à 02:54, Thomas de Groot a écrit :
> On 7-3-2018 22:44, Stephen wrote:
>> On 07/03/2018 21:00, Alain wrote:
>>> Le 18-03-07 à 07:21, Stephen a écrit :
>>>
>>>> BTW has anyone heard or seen a ruler where feet are divided into 
>>>> tenths?
>>>> Giving the impression that there are 10 "X inches" to a foot.
>>>> I saw one once about 30 years ago.
>>>>
>>>>
>>>
>>> Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 
>>> 1/6, 1/9 and 1/12.
>>> I've seen one with foot divided into 1/3 and 1/4.
>>
>> I think it might be industry specific rule.
>> About 30 years ago. My boss, offshore, took some measurements in the 
>> toolpusher's office using a rule he found there. After getting 
>> whatever it was made. It did not fit. He got a bit of a slagging for 
>> it. As you would. ;-)
>> He went back up to check only to find that there was 10 "inches" to 
>> the foot.
>> Drillers use some strange terms. The anchor chain tension is measured 
>> in Kilo-pound-inches. I had never heard of that measurement before I 
>> had to calibrate the load sensors.
>>
> 
> Interesting story. "kilo-pound-inches", could that mean 'thousand pounds 
> per inch'? the word kilo being used for the thousand's value?
> 

Very reasonable assumption. Values in pound per inches would require 
uselessly large values with some not very significant trailing zeros.

Post a reply to this message

On 8-3-2018 14:38, Stephen wrote:
> On 08/03/2018 13:26, Stephen wrote:
>> Your slightest wish is my command.
>>
>> https://youtu.be/CjzykTQM-4w?t=78
> 
> I just noticed a follow up video.
> The cage the guys are in is galled a Billy Pugh and you are supposed to 
> stand on the outside so you don't get trapped if it goes into the sea. I 
> used them for my one trip on the Piper. A white knuckle job.
> 
> https://www.youtube.com/watch?v=ZD8y7Slx2ow
> 
> 

Wow... that is nasty. I guess the operator got a well-earned spanking.

I suppose that with high seas this can happen very easily all by itself...

-- 
Thomas

Post a reply to this message

On 8-3-2018 14:26, Stephen wrote:
> On 08/03/2018 12:23, Thomas de Groot wrote:
>> On 8-3-2018 10:34, Stephen wrote:
> 
>>>>>
>>>>
>>>> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
>>>> "Hey John! Lets give it a pound more!"  BANG!  ;-)
>>>>
>>>
>>> More likely Pop. The materials used are designed to take the weight 
>>> and are over rated.
>>
>> Sad. I would like a bit of drama ;-)
>>
> 
> Your slightest wish is my command.
> 
> https://youtu.be/CjzykTQM-4w?t=78
> 
> A similar incident happened on the platform I was on. Unfortunately the 
> crane driver was not so lucky. He got trapped in the cabin for hours and 
> lost a foot and part of his lower leg.

Yes... I was joking but I am very aware of the dangers. At the Survey 
one day, we got a sampler stuck at the base of a borehole. The tension 
on the hoisting cable gradually increased until you saw it vibrate like 
a violin string. We rapidly backed away from the site as you can imagine.

> 
>>>
>>>
>>>> I am always surprised that we got to the Moon at all, or Mars for 
>>>> that matter, where we were able to crash at least once because of 
>>>> imperial/metrics confusion... ;-)
>>>>
>>>
>>> Big mistake mixing units. I may think in imperial but work in metric 
>>> when I can.
>>>
>>
>> smart. But then you grew up with imperial of course. I find it 
>> difficult (not that I need it).
>>
> 
> It is difficult and took years of repetition before it became second 
> nature. But after learning things like there are 5280 ft in a mile and 
> 60 mph is 88 ft/s. Not to mention the currency. The metric system is a 
> walk in the park.

Yes indeed. I struggled with the currency... In the bar, it got easier 
with the hour. :-]

> Also we oldies can add up in our head. Unlike the youth of today.
> 

Yep :-)


-- 
Thomas

Post a reply to this message

On 3/6/2018 9:48 PM, Alain wrote:
>> Quick question:
>>
>> How do I convert the units of ExposureFactor to my scene?
>>
>> In my scene, 20 units = 1 foot.
>>
>> Thanks!!
>>
>>
>> Mike
>>
> 
> The formula use meter, a meter = about 39 inches, or 3 feet and 3 inches 
> (3.25 feet in 1 m).
> There are 10.5625 square feet in a square meter.
> 

I still don't know what the effect on the value of ExposureFactor should be.


//  ExposureFactor A conversion factor between the luminance of the
//                 sky calculated (in cd/m2) to POV values. As the sky
//                 luminance can be very high (around 10000 cd/m2)
//                 then an ExposureFactor around 1e-5 will be needed to
//                 get a correct exposure when looking at the sky


Mike

Post a reply to this message

Should this macro use srgb in its pigments or rgb?


Mike

Post a reply to this message

Le 18-03-10 à 20:48, Mike Horvath a écrit :
> On 3/6/2018 9:48 PM, Alain wrote:
>>> Quick question:
>>>
>>> How do I convert the units of ExposureFactor to my scene?
>>>
>>> In my scene, 20 units = 1 foot.
>>>
>>> Thanks!!
>>>
>>>
>>> Mike
>>>
>>
>> The formula use meter, a meter = about 39 inches, or 3 feet and 3 
>> inches (3.25 feet in 1 m).
>> There are 10.5625 square feet in a square meter.
>>
> 
> I still don't know what the effect on the value of ExposureFactor should 
> be.
> 
> 
> //  ExposureFactor A conversion factor between the luminance of the
> //                 sky calculated (in cd/m2) to POV values. As the sky
> //                 luminance can be very high (around 10000 cd/m2)
> //                 then an ExposureFactor around 1e-5 will be needed to
> //                 get a correct exposure when looking at the sky
> 
> 
> Mike

Just start with 1/100000.
If it's to bright, use a lower value. If it's to dark, use a higher value.
Repeat until you get a pleasing result.

Post a reply to this message

Le 18-03-10 à 20:53, Mike Horvath a écrit :
> Should this macro use srgb in its pigments or rgb?
> 
> 
> Mike

It looks like it's based on lightsys. That mean that you should use rgb.

Rule of thumb : If the colour is from some colour picker or a paint 
application, use srgb. If it's from a formula calculated within the SDL, 
use rgb unless the documentation for that code tells you to use srgb.


Alain

Post a reply to this message