-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: New conventions for retrieving renderer information #828
base: main
Are you sure you want to change the base?
Conversation
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:
|
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 |
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. 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 |
05677b8
to
fc520c7
Compare
Add the following conventions for attributes that retrieve information about the renderer: "renderer:name" "renderer:version" "renderer:versionstring" and the following attribute that retrieves an integer frame number: "camera:frame"
Add the following conventions for attributes that retrieve information about
the renderer:
and the following attribute that retrieves an integer frame number: