As history has shown, features implemented in one unofficial POV-Ray 
branch may wind up in oners, or even in later versions of POV-Ray 
proper; this may make it difficult for scene authors to have their 
scenes automatically detect whether it will render ok on a given 
unofficial POV-Ray version.

I hereby suggest the following POV-Ray language extension to be adopted 
by future unofficial POV-Ray versions:

----------------------------------------------

(1) The #version directive:

Branches adhering to this proposal shall accept either of the following 
#version directive formats:

     #version FLOAT;
     #version unofficial patch FLOAT;

where in both cases the FLOAT specifies the official POV-Ray version the 
branch is based upon, rather than the version of the branch itself.


(2) The version variable:

Branches adhering to this proposal shall default the version variable to 
the official POV-Ray version the branch is based upon, rather than the 
version of the branch itself.


(3) The #patch directive:

Branches adhering to this proposal shall support the following directive:

     #patch STRING FLOAT;

where STRING is the name of a patch required by the scene file, and 
FLOAT is the minimal version of the patch required. A parse error shall 
be generated if the branch does not implement the specified patch at the 
specified or a higher version, and a parse warning shall be generated if 
the branch implements the specified patch at a higher major version 
(integer part of the version number).

The STRING parameter is optional; if omitted, the directive shall apply 
to the version of this proposal itself.


(4) The patch() function:

Branches adhering to this proposal shall support the following function:

     patch(STRING)

where STRING is the name of a patch; the function shall return the 
version number of the specified patch as implemented by the branch.

Again, the STRING parameter is optional, and if omitted the function 
shall apply to the version of this proposal itself.


(5) Versioning of this proposal:

This proposal in its current form shall be considered version 1.00, 
provided it finds general acceptance without change.

The authority to define new revisions of this proposal shall lie wih the 
POV-Ray development team; the intention is to define such revisions 
based on discussions among the community of people developing unofficial 
extensions to POV-Ray.


(6) Naming of patches:

To avoid naming conflicts of similar but incompatible patches, all patch 
names shall include a prefix identifying either the author, or the 
branch as part of which it is maintained (e.g. "clipka-foo" or 
"megapov-bar").

If a patch is modified by a third party, it shall be reported as a 
different patch, while the original patch should also be reported as 
supported provided that backward compatibility is given.

To allow for identifying a particular branch and its version, it is 
suggested that a branch defines a patch named after the branch itself 
(e.g. "megapov").

Patch names shall be case-insensitive.

----------------------------------------------

I'm currently working on a 3.7 branch which will implement the above 
(among a lot of other fancy stuff of course, but it double-features as a 
prototype for a generic "branching framework"); adapting the approach to 
other branches should be easy enough.

Comments, anyone?

(Note that this proposal isn't intended to be a catch-all, but rather a 
solid foundation on which future revisions might add more sophisticated 
patch management features as required.)

Post a reply to this message

> I'm currently working on a 3.7 branch which will implement the above
> (among a lot of other fancy stuff of course, but it double-features as a
> prototype for a generic "branching framework"); adapting the approach to
> other branches should be easy enough.
>
> Comments, anyone?

My concern would be that you release a branch with unbiased rendering 
:-) , I release a branch with sky-coloured fog, someone else does a 
branch for physics simulation, but how to render a scene utilising all 
of those features at once?

Post a reply to this message

Le 26/07/2013 09:46, scott a écrit :
>> I'm currently working on a 3.7 branch which will implement the above
>> (among a lot of other fancy stuff of course, but it double-features as a
>> prototype for a generic "branching framework"); adapting the approach to
>> other branches should be easy enough.
>>
>> Comments, anyone?
> 
> My concern would be that you release a branch with unbiased rendering
> :-) , I release a branch with sky-coloured fog, someone else does a
> branch for physics simulation, but how to render a scene utilising all
> of those features at once?

Well, I would have my own branch integrating these 3 branches...
Or maybe just my own personal local software pulling & merging the
patches from the various branchs.
(above is purely hypothetical, just to answer your question)
From my understanding of proposal, the scene has better check each of
the used features (until they becomes official in some ulterior official
release, at which time the scene would need at least to be updated to
switch from patch identification to usual version identification)

I think it might also works more closely with the repository system
itself. Instead of branches, some systems also have patch queues... but
I'm not fluent in anything, and i do not know what would/could happen.

It reminds me of a period of superpov / megapov which worked as
aggregating various patches from various authors in the same code. It
was not easy either, and it was somehow a kind of centralised thing
(whereas today everything goes distributed).

Post a reply to this message

Am 26.07.2013 09:46, schrieb scott:
>> I'm currently working on a 3.7 branch which will implement the above
>> (among a lot of other fancy stuff of course, but it double-features as a
>> prototype for a generic "branching framework"); adapting the approach to
>> other branches should be easy enough.
>>
>> Comments, anyone?
>
> My concern would be that you release a branch with unbiased rendering
> :-) , I release a branch with sky-coloured fog, someone else does a
> branch for physics simulation, but how to render a scene utilising all
> of those features at once?

By finding someone to release yet another branch that pulls all of these 
together and also adheres to this proposal.

In the scene file you can then test for the presence of all the features 
you need, using multiple "#patch" statements.

That's exactly the purpose of this proposal: To allow people to compile 
collections of multiple patches, while still providing a standard 
interface to identify each and every one of them.

Post a reply to this message

Am 26.07.2013 12:24, schrieb Le_Forgeron:

>  From my understanding of proposal, the scene has better check each of
> the used features (until they becomes official in some ulterior official
> release, at which time the scene would need at least to be updated to
> switch from patch identification to usual version identification)

Actually I hope this mechanism will become part of official POV-Ray 
itself; future official versions would then also identify all those 
patches that have made it into the official version, so that scenes 
relying on any of those patches can be rendered with official POV-Ray 
without change (provided of course the patch was integrated without 
modifications).

Post a reply to this message

On 26-7-2013 13:09, clipka wrote:

> That's exactly the purpose of this proposal: To allow people to compile
> collections of multiple patches, while still providing a standard
> interface to identify each and every one of them.
>

Smart. And very useful / important imo for the dynamic progress of POV-Ray.

Thomas

Post a reply to this message

> By finding someone to release yet another branch that pulls all of these
> together and also adheres to this proposal.

And eventually, if appropriate, I assume someone to incorporate that 
branch into the main release?

> In the scene file you can then test for the presence of all the features
> you need, using multiple "#patch" statements.
>
> That's exactly the purpose of this proposal: To allow people to compile
> collections of multiple patches, while still providing a standard
> interface to identify each and every one of them.

I assume that then once a load of patches make it into the official 4.2 
(or whatever) release you could then use #version 4.2 in new scenes 
rather than having to list a load of #patch statements?

Post a reply to this message

Am 26.07.2013 13:52, schrieb scott:
>> By finding someone to release yet another branch that pulls all of these
>> together and also adheres to this proposal.
>
> And eventually, if appropriate, I assume someone to incorporate that
> branch into the main release?

That, or individual patches from that branch. Or none at all, if they 
turn out to be too useless, too exotic or too far from what POV-Ray 
aspires to be. (For instance, I suspect that a patch to render objects 
in motion at relativistic speeds won't ever make it into official 
POV-Ray, and a patch to support spectral rendering may or may not make 
it depending on how much the feature impacts performance of classic RGB 
rendering.)

>> In the scene file you can then test for the presence of all the features
>> you need, using multiple "#patch" statements.
>>
>> That's exactly the purpose of this proposal: To allow people to compile
>> collections of multiple patches, while still providing a standard
>> interface to identify each and every one of them.
>
> I assume that then once a load of patches make it into the official 4.2
> (or whatever) release you could then use #version 4.2 in new scenes
> rather than having to list a load of #patch statements?

Yes, once a patch becomes part of official POV-Ray I'd expect it to be 
supported by all branches claiming to inherit from that official version 
(except maybe for features that even official POV-Ray does not always 
support, as had been the case for the OpenEXR file format during the 3.7 
beta phase).

Post a reply to this message