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