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