Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lgritz
Copy link
Collaborator

@lgritz lgritz commented Dec 6, 2017

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"

@lgritz
Copy link
Collaborator Author

lgritz commented Dec 6, 2017

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.)

@johnhaddon
Copy link
Contributor

"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...

@lgritz
Copy link
Collaborator Author

lgritz commented Dec 6, 2017

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!

@MasterZap
Copy link

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

@lgritz
Copy link
Collaborator Author

lgritz commented Dec 6, 2017

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.

@fpsunflower
Copy link
Contributor

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).

@lgritz
Copy link
Collaborator Author

lgritz commented Dec 7, 2017

sure

@danieldresser-ie
Copy link
Contributor

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

@lgritz
Copy link
Collaborator Author

lgritz commented Jun 2, 2018

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

@fpsunflower
Copy link
Contributor

Is this still something we care about?

@MasterZap
Copy link

MasterZap commented Nov 4, 2019

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

@MasterZap
Copy link

MasterZap commented Nov 4, 2019

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

@lgritz lgritz force-pushed the lg-doc branch 3 times, most recently from 05677b8 to fc520c7 Compare May 8, 2020 00:45
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"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants