Am 01.09.2016 um 08:54 schrieb Thomas de Groot:
> By the way, version still:
> 
> #version unofficial patch 3.7;
> 
> ?

You /can/ use `unofficial patch 3.7`, but if the scene makes use of any
features from official POV-Ray introduced after 3.7.0, I'd recommend
`unofficial patch 3.71`.

Post a reply to this message

Am 01.09.2016 um 10:54 schrieb Mr:

> Though I already spent quite some time to emulate Blender Shaders in POV as they
> get exported, I would like to try to link the exporter to these new shading
> models to find out if it gives closer results.
> 
> Oren Nayar seems straightforward because Blender has its implementation of that
> very model, but what would you say is the closest to Lommel-Seeliger in Blender
> shading models?

Since I'm no Blender user, I need to do a bit of guesswork here...

> -Fresnel?

Nope. Fresnel isn't actually a shading model, but rather a mathematical
term that appears in various shading models. From what I gather on the
internet, it seems that in Blender you can slap it onto every proper
shading model as an option (whether it makes sense or not; I suspect
some models may be sophisticated enough to already account for the
fresnel effect by themselves), and you can do the same in POV-Ray 3.7.1
by using the `fresnel` keyword directly in the `finish` block.

To the contrary: As you view the surface at a more shallow angle,
applying a Fresnel term will make the diffuse component fall off; using
the Lommel-Seeliger model, the diffuse brightness instead intensifies.

> -Lambert with a Normal input ramp?

Dunno. I wasn't able to find any reference to "Normal input ramp" on the
Internet, so someone would have to explain to me what a "Normal input
ramp" is, and how it would be plugged into the Lambert model.

> -Minnaert?

Nope. Again, to the contrary: Minnaert also makes the diffuse component
fall off at shallower angles.


I suspect Lommel-Seeliger is no suitable substitute for any of the
Blender shaders. And if you were to try to go the reverse route and try
to simulate Lommel-Seeliger in Blender, a mix of Lambert and Oren-Nayar
with a particular set of parameter settings (possibly 100% roughness,
but that's just a quick guess) might actually be the best approximation.

Post a reply to this message

On 1-9-2016 12:29, clipka wrote:
> Am 01.09.2016 um 08:54 schrieb Thomas de Groot:
>> By the way, version still:
>>
>> #version unofficial patch 3.7;
>>
>> ?
>
> You /can/ use `unofficial patch 3.7`, but if the scene makes use of any
> features from official POV-Ray introduced after 3.7.0, I'd recommend
> `unofficial patch 3.71`.
>

Of course. Thanks!

-- 
Thomas

Post a reply to this message

Am 01.09.2016 um 10:29 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
>> FYI, I've just put UberPOV back on the tracks.
>>
>> The current development version includes all the latest and greatest
>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>
>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
> 
> Are HG POV goodies also candidates to be merged one day?

There are some Hg-Povray features that I've already set my eyes on, yes.
But I haven't found the time yet to steal(*) them.

(* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
have to label those features as original UberPOV features. And I might
actually use different syntax.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.09.2016 um 10:29 schrieb Mr:
> > clipka <ano### [at] anonymousorg> wrote:
> >> FYI, I've just put UberPOV back on the tracks.
> >>
> >> The current development version includes all the latest and greatest
> >> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
> >> (Oren-Nayar and Lommel-Seeliger), and can be found here:
> >>
> >> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
> >
> > Are HG POV goodies also candidates to be merged one day?
>
> There are some Hg-Povray features that I've already set my eyes on, yes.
> But I haven't found the time yet to steal(*) them.
>
> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
> have to label those features as original UberPOV features. And I might
> actually use different syntax.)

I, for one would be very happy for it, hoping the original author is not
offended, and I'm sure he can be credited somewhere properly for his
contribution...

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Since I'm no Blender user, I need to do a bit of guesswork here...


Here is the fast illustrated summary of what's available:

https://www.blender.org/manual/render/blender_render/materials/properties/diffuse_shaders.html

In Blender Internal, you specify both a diffuse and a specular shader plus the
fresnel effect used for the "reflection block" which has nothing to do with the
one you can use in the diffuse, the later acts just as if you put some color_map
to alter object luminosity, darkening it along the vector of the lamp directed
at it.
>
> To the contrary: As you view the surface at a more shallow angle,
> applying a Fresnel term will make the diffuse component fall off; using
> the Lommel-Seeliger model, the diffuse brightness instead intensifies.
>

indeed!... But angles to the lamp vector


> > -Lambert with a Normal input ramp?
in Blender you can also use a color_map along the viewing direction, just like
povray slope_map
specifying the "normal" option makes the gradient apply in viewing direction.
whereas "energy" for instance applies it along the lamp vector


> > -Minnaert?
>
> Nope. Again, to the contrary: Minnaert also makes the diffuse component
> fall off at shallower angles.
>

Blender's implementation can also do the opposite: lightening faces as their
normals get perpendicular to the viewing direction, kind of like oren Nayer also
does , but orders of magnitude stronger.  (" if Dark is 1 you get exactly the
Lambertian result. Higher darkness values will darken the center of an object
(where it points towards the viewer). Lower darkness values will lighten the
edges of the object, making it look somewhat velvet")

So maybe we could say that Lommel-Seeliger  is a good model to emulate all
darkness values of Blender Minnaert below 1 wile values above could switch to a
darkening slope_map/aoi pattern ?

And Brilliance parameter would be better to emulate Fresnel as it's more light
dependant than viewing angle dependant???


Anyway, at the moment I meet a bigger issue, as I see no variation when trying
to use the two new models in pov, are they confirmed to work in your Windows 64
build?



The Minnaert shader in POV was the topic of this work:
http://news.povray.org/povray.binaries.images/thread/%3C3f6ccdf7%40news.povray.org%3E/

Has it been used for this feature or can it still be added to all the options?

Thanks a lot to all devs for your work so far!

Post a reply to this message

Am 01.09.2016 um 14:14 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 01.09.2016 um 10:29 schrieb Mr:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> FYI, I've just put UberPOV back on the tracks.
>>>>
>>>> The current development version includes all the latest and greatest
>>>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>>>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>>>
>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>>
>>> Are HG POV goodies also candidates to be merged one day?
>>
>> There are some Hg-Povray features that I've already set my eyes on, yes.
>> But I haven't found the time yet to steal(*) them.
>>
>> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
>> have to label those features as original UberPOV features. And I might
>> actually use different syntax.)
> 
> I, for one would be very happy for it, hoping the original author is not
> offended, and I'm sure he can be credited somewhere properly for his
> contribution...

He certainly would get credited. And as for being offended, I have some
hope that Jerome's wrath would be contained within a reasonably small
bounding box ;)

Post a reply to this message

Am 01.09.2016 um 16:06 schrieb Mr:

>>> -Minnaert?
>>
>> Nope. Again, to the contrary: Minnaert also makes the diffuse component
>> fall off at shallower angles.
> 
> Blender's implementation can also do the opposite: lightening faces as their
> normals get perpendicular to the viewing direction, kind of like oren Nayer also
> does , but orders of magnitude stronger.  (" if Dark is 1 you get exactly the
> Lambertian result. Higher darkness values will darken the center of an object
> (where it points towards the viewer). Lower darkness values will lighten the
> edges of the object, making it look somewhat velvet")

I must confess that I'm digging into the Minnaert model only just now.
And yes, it seems indeed to be capable of doing something like the
Oren-Nayar and Lommel-Seeliger models.

> So maybe we could say that Lommel-Seeliger  is a good model to emulate all
> darkness values of Blender Minnaert below 1 wile values above could switch to a
> darkening slope_map/aoi pattern ?

If you want to emulate Blender's Minnaert in POV-Ray, wait for a couple
of hours until the next UberPOV release ;)

> And Brilliance parameter would be better to emulate Fresnel as it's more light
> dependant than viewing angle dependant???

The Brilliance parameter is primarily a poor hack with no physical
legitimation. I suspect the best way to emulate it would be with
something like an aoi pattern. While it might indeed have been used as a
poor man's attempt at approximating a fresnel term, it would have
succeeded in that only for the outgoing light, ingoing that there should
be a symmetric term for the incoming light.

(After some research, I have a hunch that the brilliance parameter
/might/ actually have originated as a failed attempt to implement the
Minnaert model. But that's just speculation, and it's probably far too
late to find out the truth about it.)

> Anyway, at the moment I meet a bigger issue, as I see no variation when trying
> to use the two new models in pov, are they confirmed to work in your Windows 64
> build?

They should be working fine in UberPOV 1.37.1.1-alpha.8756754, but I'll
check again.

> The Minnaert shader in POV was the topic of this work:
>
http://news.povray.org/povray.binaries.images/thread/%3C3f6ccdf7%40news.povray.org%3E/
> 
> Has it been used for this feature or can it still be added to all the options?

I didn't even know about Kevin's work until right now that you've
mentioned it (and I'm not sure whether I would be able to dig up his
code on the Internet). I had even started on my own Minnaert
implementation already.

Post a reply to this message

Le 01/09/2016 à 18:03, clipka a écrit :
> Am 01.09.2016 um 14:14 schrieb Mr:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 01.09.2016 um 10:29 schrieb Mr:
>>>> clipka <ano### [at] anonymousorg> wrote:
>>>>> FYI, I've just put UberPOV back on the tracks.
>>>>>
>>>>> The current development version includes all the latest and greatest
>>>>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>>>>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>>>>
>>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>>>
>>>> Are HG POV goodies also candidates to be merged one day?
>>>
>>> There are some Hg-Povray features that I've already set my eyes on, yes.
>>> But I haven't found the time yet to steal(*) them.
>>>
>>> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
>>> have to label those features as original UberPOV features. And I might
>>> actually use different syntax.)

I never understood that proposal, or how to use it, from the coding side.

And I do not really care, as I use only the official povray and hgpovray, my little
pet.

>>
>> I, for one would be very happy for it, hoping the original author is not
>> offended, and I'm sure he can be credited somewhere properly for his
>> contribution...
> 
> He certainly would get credited. And as for being offended, I have some
> hope that Jerome's wrath would be contained within a reasonably small
> bounding box ;)
> 
Since the start of the refactoring (3 years ago?), I'm waiting for the code to
stabilize (in term of change to C++ objects) before moving the changes of hg-povray in
compatible code. I usually check once a year, at summer holiday, but it is not easy.
(and the change of directory hierarchy is not friendly with automerging tools)

I tried to write the nurbs in both, but it turns out to be painful to maintain. Not
something I'm going to do again.

So far my plan is to finish the normal computation of nurbs in hg-povray (something
where reading M. S. Floater in text is a must go, and no, I'm not going for
approximation),
then (when more time become available here), trying to merge the head of master povray
into hg-povray... unless there is another refactoring happening just 2 weeks before I
would have merged).


Your evolution of ovus has been made, but got little echo.

And I'm probably late also on some documentation too.

Post a reply to this message

Am 01.09.2016 um 19:08 schrieb Le_Forgeron:
> Le 01/09/2016 à 18:03, clipka a écrit :
>> Am 01.09.2016 um 14:14 schrieb Mr:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> Am 01.09.2016 um 10:29 schrieb Mr:
>>>>> clipka <ano### [at] anonymousorg> wrote:
>>>>>> FYI, I've just put UberPOV back on the tracks.
>>>>>>
>>>>>> The current development version includes all the latest and greatest
>>>>>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>>>>>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>>>>>
>>>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>>>>
>>>>> Are HG POV goodies also candidates to be merged one day?
>>>>
>>>> There are some Hg-Povray features that I've already set my eyes on, yes.
>>>> But I haven't found the time yet to steal(*) them.
>>>>
>>>> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
>>>> have to label those features as original UberPOV features. And I might
>>>> actually use different syntax.)
> 
> I never understood that proposal, or how to use it, from the coding side.

From the "[patch] coding side" it might be as simple as borrowing the
corresponding code from UberPOV.

From the "[scene] coding side" it is not fundamentally different from
the way we're already specifying what POV-Ray version a scene needs:

    // (1) State that you use patches conforming to that proposal,
    //     and what baseline of official POV-Ray features your scene
    //     is making use of:
    #version unofficial patch 3.71;

    // (2a) State what individual additional features your scene is
    //      making use of, and the minimum versions thereof:
    #patch "upov-oren_nayar" 0.9;
    #patch "wfpokorny-density_file-refine" 1.10;

Given this header, the scene will render fine on any patched version of
POV-Ray that intentionally supports the Oren-Nayar shading with the same
syntax as UberPOV, as well as the density file extensions originally
developed by William F. Pokorny -- no matter whether that patched
version of POV-Ray happens to be UberPOV, or an entirely different patch
collection that just cherry-picked these two features, as long as it
does adhere to the `unofficial patch` proposal.


The proposal also allows to choose alternative scene code depending on
what patches are available. For instance, suppose you know that two
different patched versions of POV-Ray provide an implementation of the
Oren-Nayar shading model, but use different syntax. You could then
define a texture as follows:

    #declare MyFinish = finish {
      #if (patch("upov-oren_nayar"))
        // UberPOV's current Oren-Nayar implementation interprets
        // the parameter as the sigma
        oren_nayar SIGMA
      #elseif (patch("snugglepov-oren_nayar"))
        // SnugglePOV happens to use the same keyword, but interprets
        // the parameter as the square of sigma
        oren_nayar SIGMA*SIGMA
      #end
    }

This is actually the part of the `unofficial patch` proposal that I find
the most useful: Back when I was still juggling with POV-Ray 3.7,
MegaPOV and MCPov, I found it frustrating that I couldn't have my scenes
auto-detect whether they were running on MCPov (in which case I would
want blurred reflections, but would also have to use different diffuse
values because MCPov got them wrong by a factor of 2, and would have to
define light sources as emissive spheres) or one of the others (in which
case I would want radiosity, and use classic light sources).


> And I do not really care, as I use only the official povray and hgpovray, my little
pet.

For such cases, the `unofficial patch` proposal also has something in store:

    // (1) State that your scene is designed for a patched version
    //     of POV-Ray supporting the `unofficial patch` proposal,
    //     and what baseline of official POV-Ray features your scene
    //     is making use of:
    #version unofficial patch 3.71;

    // (2b) State what patched version of POV-Ray your scene is
    //      designed for:
    #patch "upov" 137.1;

Given this header, the scene will render fine on UberPOV 1.37.1.1 or
higher -- *OR* on any other patched version of POV-Ray that includes
support for the full set of UberPOV 1.37.1.1's features.


>>> I, for one would be very happy for it, hoping the original author is not
>>> offended, and I'm sure he can be credited somewhere properly for his
>>> contribution...
>>
>> He certainly would get credited. And as for being offended, I have some
>> hope that Jerome's wrath would be contained within a reasonably small
>> bounding box ;)
>>
> Since the start of the refactoring (3 years ago?), I'm waiting for the code
> to stabilize (in term of change to C++ objects) before moving the changes
> of hg-povray in compatible code. I usually check once a year, at summer holiday,
> but it is not easy. (and the change of directory hierarchy is not friendly with
> automerging tools)

3 years ago was 2013 -- the year 3.7.0 was finally released (in December).

No, refactoring didn't start 3 years ago -- it started after 3.6.1 (or
maybe even before that, in a separate branch), and was interrupted only
briefly in 2013 to get a stable version out the door, after refactoring
had changed the architecture enough to be able to implement
single-machine symmetric multiprocessing support for all features.

Refactoring was never meant to stop there: Distributed rendering was the
original goal of the refactoring, and still is one of the goals. And
another goal has been added: To turn POV-Ray's rendering engine into
something that can be used as a library.

Changes to the directory hierarchy have been -- and to some degree still
are -- a necessary evil of that ongoing process, as it greatly
simplifies the process of partitioning the code into clear-cut modules.


As for tracking moved files, I was pleasantly surprised by the
capabilities of Atlassian's SourceTree in this respect when I recently
brought UberPOV up to date -- though I should say that I merged in
stages, making sure to "pause" right before and after each commit that
moved around any files, and then squashed those stages into a single
commit. SourceTree is free, supports both Git and Mercurial, and is
available for Windows and OS X.

I'm also making heavy use of BeyondCompare, without which I couldn't
code a single thing. Besides using it as an external 3-way merge tool
for SourceTree, I'm also using it to sync my actual working directory
with the so-called "working directory" of my local repo, which I'm not
actually working on directly. It is available for Windows, OS X and
Linux, and although it costs a few bucks, I'd say it is worth every cent
of the Pro version's $60.


> So far my plan is to finish the normal computation of nurbs in hg-povray
> (something where reading M. S. Floater in text is a must go, and no,
> I'm not going for approximation), then (when more time become available
> here), trying to merge the head of master povray into hg-povray...
> unless there is another refactoring happening just 2 weeks before I would
> have merged).

Don't expect refactoring to stop any time soon; there's still a shitload
of work to do until we have nice clean C++ code.

Post a reply to this message