OSL in testrender

127 views
Skip to first unread message

Simon Bunker

unread,
Sep 17, 2012, 9:35:48 AM9/17/12
to osl-dev
I've been having a bit of a look at testrender and have a couple of
questions. I am not expecting testrender to have everything in the OSL
specification, but there are a couple of things which are confusing me
a bit.

Firstly the specification states that there is a form of emission()
which takes an axis and and angle which seems useful for distant
lights, but this doesn't seem to work in testrender. I get this error
message:

area_emitter.osl:20: error: No matching function call to 'emission
(vector, float)'
Candidates are:
closure color emission (...)
closure color emission (float, ...)
closure color emission (float, float, ...)
area_emitter.osl:20: error: Not allowed: 'color * unknown'
area_emitter.osl:20: error: Cannot assign 'unknown' to 'closure color'
FAILED area_emitter.osl

or are these valid emission() polymorphic versions? If so how are they used?

Also there is a translucence() function defined in the specification
and I found reference to translucent() in the code for testrender, but
neither worked. Is one of these correct and how should I use it?

And finally I noticed a holdout() function in the test suite, but this
is not mentioned at all in the specification. Is this an omission or
is this supposed to be handled internally by the renderer? oslc
compiles shaders with a holdout() closure in them, but testrender
warns that it is unsupported.

thanks

Simon

Christopher Kulla

unread,
Sep 17, 2012, 1:52:01 PM9/17/12
to osl...@googlegroups.com
Thanks for the feedback, this is exactly the kind of documentation /
integration issues we hoped to clarify by having an example
implementation out there. I think these are all areas where the spec
is just out of sync with the implementation.

I don't think we ever had a axis/angle emission closure, in stdosl.h we have:

closure color emission(float inner_angle, float outer_angle) BUILTIN;
closure color emission(float outer_angle) BUILTIN;

Both of those are intended to work off of the geometric normal of the
emitter. The spec should probably be updated, or we may want to
revisit exactly what this should be (currently neither our renderer at
Sony, nor testrender support these variants). If you have ideas about
what should be standardized here (if anything) let us know. We
generally try to standardize things that are well documented in papers
that everyone is likely to want to have, and leave fancier closures to
be renderer specific.

The translucent closure should work, could you send me your scene and
shaders so I can debug it? We'll turn it into a testsuite entry to
make sure it keeps working.

It sounds like we just forgot to document the holdout closure in the
spec. We do use it in our renderer. Its purpose is simply to be able
to "punch holes" in the alpha channel. The code "Ci = holdout();" for
example would give you an alpha channel of 0 where that object is.
Since testrender only outputs RGB images without alpha it didn't make
sense to support this, but I can at least make the closure be
recognized at runtime.
> --
> You received this message because you are subscribed to the Google Groups "OSL Developers" group.
> To post to this group, send email to osl...@googlegroups.com.
> To unsubscribe from this group, send email to osl-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.
>

Simon Bunker

unread,
Sep 19, 2012, 8:16:27 AM9/19/12
to osl...@googlegroups.com
Hi Chris

It looks like translucent() is a case of the docs being out of date.
The specification says:

closure color translucence (...params...)

But it seems that the actual function it wants is:

closure color translucent (normal N, ...params...)

and then it works fine.

I don't really have any opinions about emission(). It would be nice to
have some penumbra / coneangle control, but I don't mind how it's done
so I'll leave that with you guys :)

I also forgot is there any sort of standard uniform sampling closure?
ie for volumes and contact shadows.

Also I was wondering if it might be worth changing the test suite
slightly so that all the shaders are together in one directory? That
way you can minimize duplicate shaders and update them more easily.
testrender seems to be fine with working this way.

Simon

Christopher Kulla

unread,
Sep 19, 2012, 1:26:12 PM9/19/12
to osl...@googlegroups.com
> I also forgot is there any sort of standard uniform sampling closure?
> ie for volumes and contact shadows.

I don't think we discuss volumes at all in the spec yet, but in our
renderer we added the following closures:

isotropic();
henyey_greenstein(float g);
absorption();

The emission() and holdout() closures are overloaded to work in the
volumetric context as well (with appropriate units).

What do you mean by contact shadows exactly? Ambient occlusion? This
is more of a rendering technique than a material description, so we
felt it was best to leave it out of the standard. In our renderer we
added the closure "occlusion(normal N, float maxdist)", but didn't
feel it belonged in the standard.


>
> Also I was wondering if it might be worth changing the test suite
> slightly so that all the shaders are together in one directory? That
> way you can minimize duplicate shaders and update them more easily.
> testrender seems to be fine with working this way.

Yes, this sounds like a good idea. It would also be nice if the
testsuite could access the "official" shaders we ship with OSL so we
can exercise them inside the testsuite.
Reply all
Reply to author
Forward
0 new messages