Hi, there is something I want to do with the version directive, could you
confirm it's possible? I want to add some options to a texture which are
specific
to uberpov in a scene, but still be able to run it with pov 3.7 just ignoring
them. would it be possible?

i am trying something along:


#declare Test = sphere
{ -1, 1
  pigment { rgb <0.9713, 0.7420, 0.3277> }
  finish
  { ambient 0 diffuse 0
    reflection { 1 metallic
    # ifdef ("upov-reflection-roughness")
        roughness 0.1
        #end
    }
    specular 1 metallic 1 roughness 0.0002
  }
}


but UPOV doesnt recognize the string so render is just plain reflection.

Post a reply to this message

Am 27.01.2015 um 09:34 schrieb Mr:
> Hi, there is something I want to do with the version directive, could you
> confirm it's possible? I want to add some options to a texture which are
> specific
> to uberpov in a scene, but still be able to run it with pov 3.7 just ignoring
> them. would it be possible?

Not yet, but I'm currently building UberPOV v1.37.1.0-beta.9, which will 
auto-define a variable for this purpose, allowing you to use the 
following procedure for feature detection:

#ifdef(unofficial)

   // UberPOV predefines a global variable "unofficial" to identify
   // as an unofficial branch, containing a string value for further
   // identification.

   #if(unofficial = "patch")

     // UberPOV identifies as "patch" (rather than "UberPOV") to
     // indicate that it is a collection of various patches, and
     // that it defines a function "patch(STRING)" returning a
     // numeric value to retrieve further information.

     #if(patch("upov-reflection-roughness") > 0)

       // UberPOV returns a non-zero value for this function call
       // to indicate that it supports the "roughness" keyword
       // in the reflection block. The return value also serves as
       // a feature-specific version number in case the functionality
       // changes in the future.

       // Note that the mechanism is not intended to tell you whether
       // this actually /is/ UberPOV; the intention is that any
       // unofficial POV-Ray branch that supports the same feature
       // in the same way as UberPOV would have the patch() function
       // behave in exactly the same manner.

       roughness 0.1

     #end
   #end
#end

Post a reply to this message

Am 31.01.2015 um 09:25 schrieb clipka:
> Am 27.01.2015 um 09:34 schrieb Mr:
>> Hi, there is something I want to do with the version directive, could you
>> confirm it's possible? I want to add some options to a texture which are
>> specific
>> to uberpov in a scene, but still be able to run it with pov 3.7 just
>> ignoring
>> them. would it be possible?
>
> Not yet, but I'm currently building UberPOV v1.37.1.0-beta.9, which will
> auto-define a variable for this purpose, allowing you to use the
> following procedure for feature detection:

There. Dunnit:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 31.01.2015 um 09:25 schrieb clipka:
> > Am 27.01.2015 um 09:34 schrieb Mr:
> >> Hi, there is something I want to do with the version directive, could you
> >> confirm it's possible? I want to add some options to a texture which are
> >> specific
> >> to uberpov in a scene, but still be able to run it with pov 3.7 just
> >> ignoring
> >> them. would it be possible?
> >
> > Not yet, but I'm currently building UberPOV v1.37.1.0-beta.9, which will
> > auto-define a variable for this purpose, allowing you to use the
> > following procedure for feature detection:
>
> There. Dunnit:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9

Just tested and it works like a charm, that's exactly what I meant. Thank You!

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 31.01.2015 um 09:25 schrieb clipka:
> > > Am 27.01.2015 um 09:34 schrieb Mr:
> > >> Hi, there is something I want to do with the version directive, could you
> > >> confirm it's possible? I want to add some options to a texture which are
> > >> specific
> > >> to uberpov in a scene, but still be able to run it with pov 3.7 just
> > >> ignoring
> > >> them. would it be possible?
> > >
> > > Not yet, but I'm currently building UberPOV v1.37.1.0-beta.9, which will
> > > auto-define a variable for this purpose, allowing you to use the
> > > following procedure for feature detection:
> >
> > There. Dunnit:
> >
> > https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9
>
> Just tested and it works like a charm, that's exactly what I meant. Thank You!

However, what I have so far in the exporter is that it tests for the string
"uber" in the name of the engine found and if so, activates the plain writing of
the feature and this keeps a cleaner readable pov scene file with less
conditions. at the price of some more complex Python, so now I'm hesitating to
implement this procedure instead, what do you think? probably this is more
reliable and futureproof?

Post a reply to this message

On 01/02/2015 21:55, Mr wrote:
> However, what I have so far in the exporter is

I have been following this and your other posts with great interest.
I have a scene that I have started which will take about a couple of 
months to create several Poser figures. Then I will build it in Blender.
I've never had a modeller that could export to UberPov (or mega Pov, 
before that). So I am quite excited about this.
Keep up the good work.

-- 

Regards
     Stephen

Post a reply to this message

Am 01.02.2015 um 22:55 schrieb Mr:
> However, what I have so far in the exporter is that it tests for the string
> "uber" in the name of the engine found and if so, activates the plain writing of
> the feature and this keeps a cleaner readable pov scene file with less
> conditions. at the price of some more complex Python, so now I'm hesitating to
> implement this procedure instead, what do you think? probably this is more
> reliable and futureproof?

Why not add an option to the exporter, to let the user decide whether 
they want...

(a) plain POV-Ray code,

(b) plain UberPOV code that uses the "#version" and "#patch" directives 
to make sure the expected features are supported,

(c) hybrid code that will make use of UberPOV features if present but 
will still render on official POV-Ray.

The upside of (c) is that UberPOV users can share their exported scenes 
with people who use official POV-Ray, and sometimes people may want 
that. The downside is that it will be slower to parse and more difficult 
to read, and sometimes people may /not/ want that.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.02.2015 um 22:55 schrieb Mr:
> > However, what I have so far in the exporter is that it tests for the string
> > "uber" in the name of the engine found and if so, activates the plain writing of
> > the feature and this keeps a cleaner readable pov scene file with less
> > conditions. at the price of some more complex Python, so now I'm hesitating to
> > implement this procedure instead, what do you think? probably this is more
> > reliable and futureproof?
>
> Why not add an option to the exporter, to let the user decide whether
> they want...
>
> (a) plain POV-Ray code,
>
> (b) plain UberPOV code that uses the "#version" and "#patch" directives
> to make sure the expected features are supported,
>
> (c) hybrid code that will make use of UberPOV features if present but
> will still render on official POV-Ray.
>
> The upside of (c) is that UberPOV users can share their exported scenes
> with people who use official POV-Ray, and sometimes people may want
> that. The downside is that it will be slower to parse and more difficult
> to read, and sometimes people may /not/ want that.


Thanks, these pros and cons help:

First, at this stage we want more users and even more developers of the
exporter, so simpler is better: With this feature you just added B and c COULD
be gathered in one Uberpov AND Vanillapov safe option

Yet the pritority is speed, because people using blender with povray will be
using it to create heavy sculpting, or furry creatures or complex textures and
all this is atm a little slow to export and parse when using blender with pov
compared to blender with other renderers, though in the long run it might be
more robust however: I already tested that we are able to rendrer more hair with
pov than with other renderers.

So for now the parsing argument would incline me to go on thus: detect uberpov
>> create slow parsed uberpov code that is POV safe; detect official POV >>
create fast parsed pov code...


The decisive question, is also: how slow can it really get? the UberPOV features
we are talking about are mainly Montecarlo Antialiasing, blurry reflections and
later blink for motion blur

If I'm not mistaken the Version tests would only be done once at parsing if
written once in a declaration? not everytime the shader is called, right? like
if someone used blurry reflection on hair strands (currently rendered with
spheresweeps) the ifdef version,etc. would be done before reading the roughness
keyword of the declared texture one, not at every strand calling this texture?

Since anti aliasing is global, I assume even less problem

The blink feature could get much trickier: with lots of moving objects declared
in the scene, the ifdef version would have to be added for each of their motion
blur copies instanced... I think this gets me back to my first idea, let python
check whether uberpov is there, if so and object motionblur is enabled, write
all the instances without conditions to avoid parsing hell.


Only I feel that my detection of the POV/UBERPOV binary only with its name
string checking is clumsy. Is it?

Post a reply to this message

On 04/02/2015 09:32, Mr wrote:
> Only I feel that my detection of the POV/UBERPOV binary only with its name
> string checking is clumsy. Is it?

Just a thought. To use any renderer you have to select it in User 
Preferences. Could you not have a flag to tell Blender which 
version/patch to use?

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 04/02/2015 09:32, Mr wrote:
> > Only I feel that my detection of the POV/UBERPOV binary only with its name
> > string checking is clumsy. Is it?
>
> Just a thought. To use any renderer you have to select it in User
> Preferences. Could you not have a flag to tell Blender which
> version/patch to use?
>
> --
>
> Regards
>      Stephen

OK, I did a compromise:


The path you chose in preferences is the binary that will render. you can pick
any engine, pov or uberpov.

previously it then detected from the binary name and would generate the suited
pov file. Assuming that Uberpov and POV will be in different directories, if you
do not specify any path, it will try to find vanilla pov from environment
variables (successfully form test reports), but if you have uberpov in the same
directory, it will rather use it. The idea was less user interactions, but as
many supported features as possible. That's why I planned to add the new version
test to define uberpov features inside the scope of its condition.

Now, instead I added a Feature Set rolldown in the Blender user preferences to
make user choose whether to write these feature down or not independantly of the
binary chosen. when they are on, they get written inside the version condition
to make the scene still compatible with POV 3.7

http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/POV-Ray#Rendering_with_UberPOV

I am trying to make everyone happy, but this might make maintenance work
heavier, so version condition might get removed in the future when most
features are available in both branches

Post a reply to this message