 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] videotron ca> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.
Oh well. I don't blame anyone for not using Windows... Not only do we have to
pay for a license, but we're now stuck with mandatory updates whenever M$
decides it needs the community to bug test its code (which is several times a
year). (I've been thinking of eventually jumping ship to Linux. From what I
hear, compatibility with Steam games is high thanks to Proton, meaning I have
fewer reasons than ever to abandon ship.)
> Further, I only once in a while publish a tarball(1) that you currently
> have to compile yourself. (...)
Well, I won't be attempting to compile it on Windows any time soon. It would
probably require Visual Studio. I tried downloading the free version a while
back, and what an outdated, over-bloated piece of work it was, imo :S
> (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.
I'm still not sure I understand. Does the equation restrict values due to its
very nature? Or did you impose a restriction so that it doesn't produce
nonsense?
> > 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! :-)
Lots of interesting patterns in there, but I can't help but to notice that the
bright interior reflections on the lower left portion are gone.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
> > (...) I originally used fade_color and supporting statements, but the
> > color was becoming too saturated. (...)
>
> 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.
That was probably the issue. I should have just kept the fade_color and added a
colorless absorbing media which would have probably made it look right.
Something to keep in mind for the next render.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/23/21 6:39 PM, Samuel B. wrote:
> I'm still not sure I understand. Does the equation restrict values due to its
> very nature?
Well on the negative side sort of, maybe. Generally, I'd say the srgb
decode equation mangles values outside the zero to one range making it
hard to control - to get what you want and too easy to not get what you
want.
> Or did you impose a restriction so that it doesn't produce
> nonsense?
Yes. I think it better users make use of rgb* keywords, where they want
to work with values outside the 0-1 range so povr forces this.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
