Hi,

Here's an alum crystal.

The face data (including HKL, distance and colors [not used]) were copied from
KrystalShaper and converted to an array-ready format thanks to a couple of find
& replace operations in notepad++. Because the data works with the cubic
crystalline system, they were easily converted into plane normals and offsets.
The planes were then used in an intersection object. 50 faces total. No
light_sources are present in the scene; just reflections.

(If anyone's wondering why I don't simply export POV-Ray files from
KrystalShaper, it's because in the future I intend to have more customization
options for certain faces.)

Here's the source code (minus luminous bloom):

/*

HKL-cubic-alaun.pov
2021 Samuel B.

Suggested command line options:
 +fn +f +a0.3 +am2 +r1

If outputting to luminous bloom:
 +fh +f +a0.3 +am2 +r1

*/


#version 3.7;

global_settings{
 assumed_gamma 1.0
 max_trace_level 11
}

#default{ finish{ambient 0} }

#declare RGBSun = srgb 1.3*<2, 1.99, 1.97>;
#declare RGBSky = srgb <.45, .475, .5>;

#declare CamPos = <0, 7, -10>;

camera{
 fisheye right x*.7 up y*.7
 location CamPos
 look_at 0
 angle 60/3.5
 aperture .77 focal_point -z blur_samples 30 variance 0
}

#if(1)
 sky_sphere{
  pigment{
   spherical scale 2 translate z
   poly_wave 2
   rotate -x*30
   rotate y*40
   color_map{
    [0 RGBSky]
    [1 RGBSun]
   }
  }
 }
#end

// ground plane
#if(1)
 plane{
  y, -1.001
  pigment{
   pigment_pattern{
    cylindrical
    scale 5
    translate 2*z
   }
   pigment_map{
    [0 rgb 0]
    [1
     granite
     scale 5
     turbulence .2 lambda 3
     poly_wave .2
    ]
   }
  }
  finish{reflection{.2, 1 fresnel metallic 1} conserve_energy}
  normal{granite .05 scale .001}
  interior{ior 1.55}
 }
#end

// KRSCOPY KrystalShaper data copied from program and converted with notepad++
#declare FaceData =
 array[50][7]{
  {1, 0, 0, 1.02, 255, 255, 128},
  {0, 1, 0, 1.02, 255, 255, 128},
  {0, -1, 0, 1.02, 255, 255, 128},
  {-1, 0, 0, 1.02, 255, 255, 128},
  {0, 0, -1, 1.02, 255, 255, 128},
  {0, 0, 1, 1.02, 255, 255, 128},
  {1, 1, 1, 0.7, 0, 255, 255},
  {1, 1, -1, 0.7, 0, 255, 255},
  {1, -1, 1, 0.7, 0, 255, 255},
  {-1, -1, 1, 0.7, 0, 255, 255},
  {-1, 1, 1, 0.7, 0, 255, 255},
  {1, -1, -1, 0.7, 0, 255, 255},
  {-1, -1, -1, 0.7, 0, 255, 255},
  {-1, 1, -1, 0.7, 0, 255, 255},
  {1, 1, 0, 0.799, 255, 128, 128},
  {1, -1, 0, 0.799, 255, 128, 128},
  {-1, -1, 0, 0.799, 255, 128, 128},
  {-1, 1, 0, 0.799, 255, 128, 128},
  {-1, 0, -1, 0.799, 255, 128, 128},
  {0, 1, 1, 0.799, 255, 128, 128},
  {1, 0, -1, 0.799, 255, 128, 128},
  {0, 1, -1, 0.799, 255, 128, 128},
  {1, 0, 1, 0.799, 255, 128, 128},
  {0, -1, -1, 0.799, 255, 128, 128},
  {-1, 0, 1, 0.799, 255, 128, 128},
  {0, -1, 1, 0.799, 255, 128, 128},
  {3, 2, 1, 0.869, 0, 255, 0},
  {-2, -1, -3, 0.869, 0, 255, 0},
  {1, 3, 2, 0.869, 0, 255, 0},
  {-3, -2, -1, 0.869, 0, 255, 0},
  {2, 1, 3, 0.869, 0, 255, 0},
  {-1, -3, -2, 0.869, 0, 255, 0},
  {3, 2, -1, 0.869, 0, 255, 0},
  {-2, -1, 3, 0.869, 0, 255, 0},
  {1, 3, -2, 0.869, 0, 255, 0},
  {-3, -2, 1, 0.869, 0, 255, 0},
  {2, 1, -3, 0.869, 0, 255, 0},
  {-1, -3, 2, 0.869, 0, 255, 0},
  {-1, 3, 2, 0.869, 0, 255, 0},
  {2, -1, 3, 0.869, 0, 255, 0},
  {3, -2, -1, 0.869, 0, 255, 0},
  {-1, 3, -2, 0.869, 0, 255, 0},
  {-2, 1, 3, 0.869, 0, 255, 0},
  {3, -2, 1, 0.869, 0, 255, 0},
  {1, -3, -2, 0.869, 0, 255, 0},
  {-2, 1, -3, 0.869, 0, 255, 0},
  {-3, 2, 1, 0.869, 0, 255, 0},
  {1, -3, 2, 0.869, 0, 255, 0},
  {2, -1, -3, 0.869, 0, 255, 0},
  {-3, 2, -1, 0.869, 0, 255, 0}
 }

// crystal
#if(1)
 intersection{

  #for(I, 0, 49)
   plane{
    <FaceData[I][0], FaceData[I][1], FaceData[I][2]>, FaceData[I][3]
   }
  #end

  // I guessed the proper color :/
  pigment{rgb <.85, .7, 1> filter 1}

  finish{reflection{0, 1 fresnel} conserve_energy}

  normal{granite .03 scale .001}

  interior{
   // alum ior from classicgems.net
   ior 1.453
   media{absorption .3}
   // an unrealistic dispersion value
   dispersion 1.075 dispersion_samples 7
  }

  hollow

  rotate -y*43
 }
#end

Post a reply to this message

Attachments:
Download 'hkl-cubic-alaun9m_07s-plus-lb7b1m_02s.jpg' (29 KB)

Preview of image 'hkl-cubic-alaun9m_07s-plus-lb7b1m_02s.jpg'

"Samuel B." <stb### [at] hotmailcom> wrote:
> Here's an alum crystal.

And here's an image of the crystal as seen in KrystalShaper. It's safe to say
that cubic systems map directly to planes (with the caveat of z being up, and
the handedness possibly being different).

Sam

Post a reply to this message

Attachments:
Download 'alaun-ks.png' (16 KB)

Preview of image 'alaun-ks.png'

> /*
> 
> HKL-cubic-alaun.pov
> 2021 Samuel B.
> 
> Suggested command line options:
>   +fn +f +a0.3 +am2 +r1
> 
> If outputting to luminous bloom:
>   +fh +f +a0.3 +am2 +r1
> 
> */
> 




generate PNG images by default.
Those two switches are default values since version 3.7.
+a0.3 is also the default when antialiasing is used.
The default of +r3 gives you better results.


> // crystal
> #if(1)
>   intersection{
> 
>    #for(I, 0, 49)
>     plane{
>      <FaceData[I][0], FaceData[I][1], FaceData[I][2]>, FaceData[I][3]
>     }
>    #end
> 
>    // I guessed the proper color :/
>    pigment{rgb <.85, .7, 1> filter 1}
For a crystal, this should be :
pigment{rgbt 1}
The colour don't come from the surface but from the substance itself.

> 
>    finish{reflection{0, 1 fresnel} conserve_energy}
> 
>    normal{granite .03 scale .001}
> 
>    interior{
This is where the colour of the crystal should be.
Starting settings :

	fade_color rgb <.85, .7, 1>//desired colour
	fade_power 1001 //how the path length affect the colour
	fade_distance 0.5 //base distance to be used for the fading

Adjust fade_distance to change the intensity of the colour of the crystal.

>     // alum ior from classicgems.net
>     ior 1.453
>     media{absorption .3}
You may also use a colour here.
As a starter, you may try :
{absorbtion rgb<0.15, 0.3, 0>}

Use the complement of your colour. That's 1 minus the desired colour.

>     // an unrealistic dispersion value
>     dispersion 1.075 dispersion_samples 7
>    }
> 
>    hollow
> 
>    rotate -y*43
>   }
> #end
>

Post a reply to this message

Il 20/09/2021 01:09, Samuel B. ha scritto:
 > Hi,
 >
 > Here's an alum crystal.
 >
 > The face data (including HKL, distance and colors [not used]) were 
copied from
 > KrystalShaper and converted to an array-ready format thanks to a 
couple of find
 > & replace operations in notepad++. Because the data works with the cubic
 > crystalline system, they were easily converted into plane normals and 
offsets.
 > The planes were then used in an intersection object. 50 faces total. No
 > light_sources are present in the scene; just reflections.
 >
 > (If anyone's wondering why I don't simply export POV-Ray files from
 > KrystalShaper, it's because in the future I intend to have more 
customization
 > options for certain faces.)
 >


This image is poetic, Sam!

Paolo

Post a reply to this message

On 9/19/21 7:09 PM, Samuel B. wrote:
> Here's the source code (minus luminous bloom):

Cool. Thank you for posting the code.

I used your scene to do a little crude bench-marking of my povr branch.

To create the attached image, I changed:

#declare RGBSun = srgb 1.3*<2, 1.99, 1.97>;

to

#declare RGBSun = srgb <1, 0.99, 0.97>;
#declare RGBSun = 2.7*RGBSun;

because my povr branch now doesn't allow srgb channel specifications 
outside the 0-1 range.

Plus, I changed the crystal's normal to the povr branch's quilted normal 
- but still scaled very small - and aiming for a blurred reflection.

Given you are using camera blur to over sample, I wanted to see how 
povr's big jitter would compare time wise. The big jitter approach took 
2.4x longer to render at +a0.0 +am2 +r4 +j62.111 than your blur samples 
method of oversampling. I can tell from the render statistics I was too 
aggressive at r4 - as I shot roughly 2.7x more rays. I'd say the mothods 
are in the ballpark performance wise, with other differences in control 
and result which might matter or not. FWIW.

Bill P.

Post a reply to this message

Attachments:
Download 'sam_.jpg' (47 KB)

Preview of image 'sam_.jpg'

Alain Martel <kua### [at] videotronca> wrote:
> generate PNG images by default.
> Those two switches are default values since version 3.7.
> +a0.3 is also the default when antialiasing is used.

I know some things are enabled by default, but I like to include all the options
that I plan to change later on... because I'm lazy :D

> The default of +r3 gives you better results.

True that, but +r1 is faster and better than no antialiasing at all, imo. (It
lends a softer look to the rendering.)

> Use the complement of your colour. That's 1 minus the desired colour.

Thanks, Alain. I originally used fade_color and supporting statements, but the
color was becoming too saturated. So I cheaped out instead, which is
regrettable. Because by doing so, I only managed to simulate surface dyes, which
are highly frowned upon in the mineral community ;)

Sam

Post a reply to this message

Paolo Gibellini <p.g### [at] gmailcom> wrote:
> Il 20/09/2021 01:09, Samuel B. ha scritto:
>  > Here's an alum crystal.
>
> This image is poetic, Sam!

Thanks Paolo!

Sam

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/19/21 7:09 PM, Samuel B. wrote:
> > Here's the source code (minus luminous bloom):
>
> Cool. Thank you for posting the code.
>
> I used your scene to do a little crude bench-marking of my povr branch.

Thanks, Bill. Is there a binary of povr for Windows, or am I just not seeing it?

> To create the attached image, I changed:
>
> #declare RGBSun = srgb 1.3*<2, 1.99, 1.97>;
>
> to
>
> #declare RGBSun = srgb <1, 0.99, 0.97>;
> #declare RGBSun = 2.7*RGBSun;
>
> because my povr branch now doesn't allow srgb channel specifications
> outside the 0-1 range.

Is that why the image is darker overall? (Why the clamping, btw?)

> Plus, I changed the crystal's normal to the povr branch's quilted normal
> - but still scaled very small - and aiming for a blurred reflection.

Right away I can see that the quilted pattern seems superior in this instance.
The reflection on the plane starts out much sharper, whereas the granite pattern
I used starts out way too blurry.

> Given you are using camera blur to over sample, I wanted to see how
> povr's big jitter would compare time wise. The big jitter approach took
> 2.4x longer to render at +a0.0 +am2 +r4 +j62.111 than your blur samples
> method of oversampling. I can tell from the render statistics I was too
> aggressive at r4 - as I shot roughly 2.7x more rays. I'd say the mothods
> are in the ballpark performance wise, with other differences in control
> and result which might matter or not. FWIW.

The blur is exaggerated in your render compared to mine, so perhaps the
performance would be more comparative with a reduced bump_size and lower +r
value?

Sam

Post a reply to this message

On 9/21/21 8:05 PM, Samuel B. wrote:
> ... Is there a binary of povr for Windows, or am I just not seeing it?

No, it's a linux / unix / macos only effort. I don't use windows.

Further, I only once in a while publish a tarball(1) that you currently 
have to compile yourself. I've not yet gotten to what I want to be my 
initial, public, git repository. It's my playpen, but hope some find 
bits of the play/work useful.

(1) - To povray.binaries.programming

>> because my povr branch now doesn't allow srgb channel specifications
>> outside the 0-1 range.
> Is that why the image is darker overall? 
Yes.

(Why the clamping, btw?)

It isn't about clamping values, but rather restricting the srgb* keyword 
use to values which make sense. There is an underlying equation - and it 
runs for any input channel value - but only values in the [0..1] range 
make sense.

//--- Limit srgb use to [0..1] range!
#version 3.8;
global_settings {assumed_gamma 1.0}

#declare RGBSun  = srgb 1.30*<2, 1.99, 1.97>;
#declare RGBSun_0 = rgb 1.30*<2, 1.99, 1.97>;
#declare RGBSun_1 = rgb 4.58*<2, 1.99, 1.97>;
#declare RGBSun_2 = srgb <2.0, 0.9, 0.8>;
#declare RGBSun_3 = srgb <2.0,-0.9,-1.8>;

#declare SRGBSun  = srgb <1.0, 0.45, 0.4>;
#declare RGBSun_4 = 9.16*SRGBSun;

#debug "\n"
#debug concat("srgb 1.30*<2, 1.99, 1.97> = rgb <",
     vstr(3,RGBSun,",", 0,-1),">\n")
#debug concat("rgb  1.30*<2, 1.99, 1.97> = rgb <",
     vstr(3,RGBSun_0,",", 0,-1),">\n")
#debug concat("rgb  4.58*<2, 1.99, 1.97> = rgb <",
     vstr(3,RGBSun_1,",", 0,-1),">\n")
#debug concat("srgb      <2.0, 0.9, 0.8> = rgb <",
     vstr(3,RGBSun_2,",", 0,-1),">\n")
#debug concat("srgb      <2.0,-0.9,-1.8> = rgb <",
     vstr(3,RGBSun_3,",", 0,-1),">\n")
#debug "\n"
#debug concat("9.16*SRGBSun              = rgb <",
     vstr(3,RGBSun_4,",", 0,-1),">\n")
#debug "\n"

#error "Parsing test. Stop early."
//---

> The blur is exaggerated in your render compared to mine, so perhaps the
> performance would be more comparative with a reduced bump_size and lower +r
> value?
Yes, I expect you are correct.

Attaching another image. Here playing with one of the prototype normal 
patterns in povr's bevy normal wrapper. It's kind of a non-drifting(1) 
wrinkles rotation about a specified axis (or was it toward a point...). 
Anyhow, it's perturbing/mangling the normal and for the image use a 
negative bump to intentionally 'sometimes' invert the normals. Doesn't 
represent anything real, but I think it looks neat! :-)

(1) - Elsewhere I posted about our current "normal wrinkles pattern bias."

Bill P.

Post a reply to this message

Attachments:
Download 'sam_bevy_normal_6_negbmp.jpg' (49 KB)

Preview of image 'sam_bevy_normal_6_negbmp.jpg'

> Thanks, Alain. I originally used fade_color and supporting statements, but the
> color was becoming too saturated. So I cheaped out instead, which is
> regrettable. Because by doing so, I only managed to simulate surface dyes, which
> are highly frowned upon in the mineral community ;)
> 
> Sam
> 

If your colour get to saturated, that mean that your fade_distance is to 
short, so, just increase fade_distance as needed.
Also, to get realistic results, fade_power need to be 1001 or 1, not 2.

Post a reply to this message