colors as vectors

50 views
Skip to first unread message

haggi krey

unread,
Aug 16, 2014, 4:51:55 AM8/16/14
to osl...@googlegroups.com
Hi,

while translating the maya hypershade nodes to OSL, I had to discover that it is not always possible to find out if a three float attribute is used as color or as vector.
A suggestion from the ADSK dev support was to use only vectors instead of colors as inputs and outputs. This is the way it works in mantra.

If I need colors, I'd convert them on demand. This will introduce some conversions, but on the other side it makes the translation much more stable and I can get rid of
an automatic colorToVector or vectorToColor translation procedure.

So my question is: Could there be any drawbacks if I follow the suggestion and translate all colors to vectors in my shader nodes?

Steve Agland

unread,
Aug 17, 2014, 7:19:00 PM8/17/14
to osl...@googlegroups.com
Hey Haggi,

Just anecdotally, we're using only vector types (no colors, points or normals) in our node library, both for parameters and internally, and haven't run into any major problems (so far). Since OSL has no generics or templates doing this reduces redundant implementation and compiler warnings since it's common to want to convert between these types.

One downside of using only vectors internally it that you can't rely on overloaded functions like transform() to behave appropriately based on type, so we currently have wrappers called transformv, transformp etc (in the style of the existing transformc function). Arguably this makes for more explicit/readable code.

The reduced type safety has its own risks but I haven't found these to be significant in shader writing. You can use parameter metadata to provide hints to the UI that some vector params should be interpreted as colors.

Cheers

Steve

haggi krey

unread,
Aug 18, 2014, 5:29:08 AM8/18/14
to osl...@googlegroups.com
Ahhh, great! That sounds good. So it is worth a try.

Larry Gritz

unread,
Aug 18, 2014, 5:44:17 PM8/18/14
to osl...@googlegroups.com
I don't have much to add here. Should be fine.

If people think it's generally useful, I'm happy to add ptransform vtransform, ntransform that will handle all the casting for you.

Some renderers, if they allow the idea of a "shader" space (the coordinate system in effect when the shader is declared), may have a semantic difference between instance values passed, if the renderer's practice is that instance values are expressed in local space and automatically transformed into the canonical space (usually world or camera). RenderMan-compliant renderers tend to do it that way. In such a case, you may get unexpected results if everything is declared as a vector, since vectors transform differently than points. But in terms of the body of the shader or shader "connections", it's ok to mix and match the vector-like types, they are actually all the same underneath.

-- 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 post to this group, send email to osl...@googlegroups.com.
Visit this group at http://groups.google.com/group/osl-dev.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@larrygritz.com



Reply all
Reply to author
Forward
0 new messages