OTOY Forums

Hello peeps,

So I'm doing some OSLing and I'm kind of stuck with something, would appreciate your help

After writing and saving an OSL texture I'm noticing its super cumbersome to have to go into the OSL Texture and bring up the saved OSL script via that dropdown menu. It gets really tedious if its an often used OSL that you reuse in every other material.

So I guess I'm wondering, am I missing something or is there no way to save a custom OSL Texture and have it some closer than having to browse through the dropdown / load it from disk every single time?

Hope I'm making sense here

What's your advice to have a better method?
You can store any OSL node in content browser to re-use again If you like that

Hey Aoktar, thanks for chiming in

So maybe I'm doing it wrong but saving it in the content browser doesn't allow for a drag & drop functionality, at least in R21. Maybe I'm doing something wrong but it just doesn't seem to work.

As for suggesting a different method of quick access... Personally, I'd be immensely excited to see a custom category in the Octane node editor menu (the one on the left) where you could drag & drop different OSL shaders. I know it could get cluttered quickly but thats why that search functionality you've implemented is so great

I do fear that that would require a ton of technical work from your side although I feel like that currently why I'm mostly avoiding OSL tasks is because even for a "simpler" thing such as a complex IOR OSL shader I need to go through the script browsing game every single time. I suppose my argument would be that having custom OSL shaders somewhere more easily accessible would perhaps even popularize their usage more. There are quite a few things we can do with OSL that are really powerful.

So thats just stuff of the top of my head. I'm curious to hear what you / and other users think

I'd love a dedicated OSL sub-category in the Node Editor Side Menu, too. It seems like a good way to take advantage of the power of OSL (which I suspect many people find a bit intimidating to use and explore,) while still conforming to the Octane philosophy of providing just basic nodes for the user to assemble appropriately.

Even without any user generated code or tweaks, there's an awful lot of very useful stuff shipped with Octane over the last couple versions, but it's all hidden away inside the OSL node and its sub-interface. I think the functionality would get a lot more use if it was closer to the surface and more readily accessible.

Since there is already the "external" option for loading OSL, perhaps a dedicated /osl_scripts/menu directory could populate the Side Menu. Those Side Menu scripts would have the "External" option on by default, but could easily be switched to unique code when needed.

Just my 2¢.

frankmci wrote:I'd love a dedicated OSL sub-category in the Node Editor Side Menu, too. It seems like a good way to take advantage of the power of OSL (which I suspect many people find a bit intimidating to use and explore,) while still conforming to the Octane philosophy of providing just basic nodes for the user to assemble appropriately.

It's actually on my todo list. But thanks for confirming how much it's a good idea.

frankmci wrote:I'd love a dedicated OSL sub-category in the Node Editor Side Menu, too. It seems like a good way to take advantage of the power of OSL (which I suspect many people find a bit intimidating to use and explore,) while still conforming to the Octane philosophy of providing just basic nodes for the user to assemble appropriately.

Even without any user generated code or tweaks, there's an awful lot of very useful stuff shipped with Octane over the last couple versions, but it's all hidden away inside the OSL node and its sub-interface. I think the functionality would get a lot more use if it was closer to the surface and more readily accessible.

Since there is already the "external" option for loading OSL, perhaps a dedicated /osl_scripts/menu directory could populate the Side Menu. Those Side Menu scripts would have the "External" option on by default, but could easily be switched to unique code when needed.

Just my 2¢.

Yep, I couldn't have put it any better than this. Thanks for this post, it explains what I had in mind better than my own post. Thank you!

@Aoktar, extremely excited to hear that! Awesome stuff

Very nice idea

First visual from the fresh implementation for new interface

Oooh, I like it!

Shaping it up a little more
https://www.youtube.com/watch?v=1iD0mNm ... e=youtu.be