"exists" parameter for gettextureinfo

30 views
Skip to first unread message

Stephen Hart

unread,
Mar 29, 2020, 4:18:40 PM3/29/20
to OSL Developers
This is probably pretty low priority :-)

The behavior of gettextureinfo using the "exists" parameter is confusing, at least to me.

The spec reads...

int gettextureinfo (string texturename, string paramname, output type destination)

Retrieves a parameter from a named texture file. If the file is found, and has a parameter that matches the name and type specified, its value will be stored in destination and gettextureinfo will return 1. If the file is not found, or doesn’t have a matching parameter (including if the type does not match), destination will not be modified and gettextureinfo will return 0. Valid parameters recognized are listed below:


Name                Type                Description

"exists"        int        Result is 1 if the file exists and is an texture format that Open Shading Language can read, or 0 if the file does not exist, or could not be properly read as a texture. Note that unlike all other queries, this query will “succeed” (return 1) if the file does not exist  


The main paragraph starting "Retrieves a parameter..." can, in my opinion, be reconciled with the description of the "exists" flag. But the interpretation I derive isn't the behavior I actually see using Blender and OSL. I believe the actual behavior matches the description of the "exists" flag, but contradicts the paragraph starting "Retrieves a parameter...".

Maybe that is the intention. In my opinion it results in slightly uglier and less safe code. For example, currently I think you can't tell the difference between does not exist and exists but is not a readable texture. But if the current behavior is what everyone expects and is using then I suggest the spec should be clarified. Maybe even add a canonical example.

I can post my detailed analysis, code samples, and suggested spec re-wording here (or you can see it all here).

Actually, my personal preference, assuming my analysis is correct, would be to implement this the way I analyse it, and clarify the spec to make my interpretation clear, and the current behavior clearly incorrect. I realize that might break some exist code. But actually I think the two versions would be such that existing code would still work because I'm guessing all existing code doesn't care about the subtle difference between does not exist and exists but is not a readable texture.

Stephen


Larry Gritz

unread,
Mar 29, 2020, 4:45:13 PM3/29/20
to OSL Developers List
So the intent was that *in general*, gettextureinfo retrieves the given metadata from the named texture -- succeeding if the texture exists, can be read as a texture, and has that named data (which is then stored in the destination variable). It returns 1 upon success and 0 upon failure (for any of those reasons). But as a SPECIAL CASE, the "exists" query never fails -- it will always return 1, and place a 0 or 1 in the destination depending on whether the named file exists and seems to be a valid texture.

Are you seeking a change in the behavior? If so, can you as briefly as possible (ELI5) describe the particular case you think is incorrect and how you think it should behave?

Or are you saying that the behavior is ok but the description in the spec is unclear and you want better wording there?

Or are you saying you want a better way to distinguish between the case where the file doesn't exist versus the case where a file exists but it can't be read as a texture?

-- lg


--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/7ff3e026-0e68-4f83-93ba-9b42de15b259%40googlegroups.com.

--
Larry Gritz




Larry Gritz

unread,
Mar 29, 2020, 5:06:36 PM3/29/20
to OSL Developers List
An even simpler way of putting it:

gettextureinfo is a way of saying "Please tell me some information about a named texture."

The return value of 1 or 0 means "OSL was able to find the information you wanted, and stored it in the destination", or "OSL was not able to retrieve that information, destination is unchanged."

When the information you are asking is whether or not the texture exists (as a valid texture), then it can ALWAYS give you an answer, and it ALWAYS stores that answer in the destination. So the return value is 1.


Stephen Hart

unread,
Mar 29, 2020, 7:45:28 PM3/29/20
to OSL Developers
ELI5: Please make the spec clearer. Your "gettextureinfo is a way of saying..." explanation is much clearer than the wording in the spec. Now I understand, and it makes sense.

I also think it may be slightly useful to have a "way to distinguish between the case where the file doesn't exist versus the case where a file exists but it can't be read as a texture". Maybe an "isreadabletexture" parameter ? But I actually have no use-case for that. So for me at least that's very low priority.

Stephen
To unsubscribe from this group and stop receiving emails from it, send an email to osl...@googlegroups.com.

--
Larry Gritz





--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl...@googlegroups.com.

--
Larry Gritz




Larry Gritz

unread,
Mar 29, 2020, 9:16:17 PM3/29/20
to OSL Developers List
OK, I'll take a whack at trying to make the spec more clear. I do appreciate hearing when anything doesn't seem to make sense.

I am very happy to add another query to distinguish between "file doesn't exist" and "does not appear to be a valid texture," if people think that's useful.

But I wrote my first shader 30 years ago and in all that time I don't recall a compelling use case for making this distinction inside the shader itself. Sometimes I want to know "can I use this texture," but I don't really care -- certainly not in the middle of a shader, which is called in the innermost loop of the renderer -- about distinguishing between all the different reasons why that may not be the case or handling lots of error cases there.

-- lg


To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/aedbde89-c584-4984-8421-1c564d60b892%40googlegroups.com.

--
Larry Gritz




Reply all
Reply to author
Forward
0 new messages