Haha, it turns out we DID implement this in our renderer! But I didn't document it in the OSL spec. And it has different names than I picked here.

I'm not 100% sure which set of names I like best, so let me sleep on it.

Questions for the peanut gallery:

• "renderer:name" versus something more generic/aspirational to keep from denigrating uses that aren't renderers? Like "appname" or "app:name" or something?

• Get rid of the 4-part version, too much trouble, just use one int and let the renderers decide how they want to encode it. (For example, they are free to do something like 10000major+100minor+patch, or whatever they want.)

"renderer:name" versus something more generic/aspirational to keep from denigrating uses that aren't renderers? Like "appname" or "app:name" or something?

Gaffer (ab)uses OSL in a few separate non-rendering contexts, but all within the same app. I'm not sure how likely we would be to need to query which context we were in, but if we did, we'd probably want to distinguish between the contexts ("gafferExpression", "gafferImage" etc) rather than have a single "app:name" query return "gaffer". But I tend to think that "renderer:name" is fine given that OSL's primary purpose is rendering...

Up to each app. It's fine to be fully detailed, or just use "gaffer" for the app/renderer name and if you need to distinguish contexts, you can always have a second gaffer-specific attribute that can be queried to reveal the context.

But anyway, thanks for the input!

Personally don't care about the names as long as you pick them. Or I would have picked things like "osl:host" or similar :P

/Z

After mulling it over, I prefer "renderer:name" and "renderer:version", though I'm going to change the version from an int[4] to a single int, and let the renderers decide how their own version numbers should be encoded instead of imposing a fixed structure on it.

While the "appname"/"app:name" seemed like a high-minded nod to non-renderer uses of OSL, I think it hardly matters considering we have RendererServices, and probably a bunch of other places where we use that word, and nobody has complained that they feel like we are treating them as second class citizens.

Just bike-shedding a bit more: I would vote for something like global:frame instead of camera:frame to make it clear we are talking about the output frame number as opposed to which frame the camera was loaded from (which could be different than geometry in bullet time or other retimed scenarios).

sure

Is there any reason why this hasn't been merged yet? I'd like to start pestering people to implement it.

Um... I think fell through the cracks as we were debating what the names ought to be. I will revive it next week.

Is this still something we care about?

I still care, and will start acting as if this was merged as of this second... :)

Edit: Looking in my code, seems I cared since december 11:th 2018, LOL

/Z

So turns out, I added this almost a year ago and then forgot, I blame the Chrismtas Schnapps:

For anyone who cares, 3ds Max OSL has for the last year or so returned the following values

renderer:name "3dsmax" for the C++ backend and "3dsmax:hlsl" for the HLSL backend.
renderer::version Whatever the currend 3ds max SDK "MAX_RELEASE" macro expanded to at the time of compilation (an integer).
renderer::versionstring That same integer just as a string. PROBABLY should be something more "human readable" but currently that's what it is.

When rendering with any embedded renderer that has it's own OSL implementation (like Arnold) obviously it will return whatever that OSL implementation does.

/Z