OSL performance has some issues.

[houourin]

I know that OSL is not fine tuned in max still but when used with Vray things don't go smooth. OSL bitmapLookup can take up to 2times to render the exact same scene.
And I encountered other little issues... that I need to start tracking.

I think you guys are already working into proper PBR viewport visualization right?

Thank You.

[hermit.crab]

Thank you for the report. We'll see what we can do about the issue.

[^Lele^]

I know that OSL is not fine tuned in max still but when used with Vray things don't go smooth. OSL bitmapLookup can take up to 2times to render the exact same scene.
And I encountered other little issues... that I need to start tracking.

I think you guys are already working into proper PBR viewport visualization right?

Thank You.

Yes, OSL *is* roughly 100% slower across the board compared to native max loaders, and a bit more against custom render engine loaders, in V-Ray, Corona and Arnold *).
Max 2021.1 fixes a bug which would make rendering any decently sized scene a neverending affair with OSL (due to cache filling), so any Max version before that is going to perform in unusable ways, regardless of engine.

With V-Ray's OSL implementation (i.e. use our OSL texture, load the OSL bitmap loader), we get around as much as we can from OIIO, which results in slightly better performance, at the price of a slightly more convoluted workflow (i.e. load a vraybitmap, instead of passing the OSL loader a bitmap path.).

There may be cases where the performance stays manageable (generally, very simple setups only.), but i have so far found *none* where OSL justifies using their bitmap loader, based on performance alone.

Further to this, there is currently no way to change filtering type on the bitmaps, besides editing the OSL code for the loader in obscure ways.

The behaviour is repeated with CC maps: OSL is twice as slow than max's own CC map doing the same hue shift to textures.

All in all, the recommendation is to *avoid OSL* unless strictly necessary.
If it's for viewport only that you need it, then i'd suggest scripting a swapper, and make yourself a render-ready scene: all the time spent doing so will come back tenfold once rendering starts.

*) Arnold is a strange thing, as its use of max native loaders is enormously (4X) slower than either native or OSL. OSL is still a wee bit slower than Arnold Image.

[houourin]

Very informative, thankyou. So overall you don't recommend any OSL use then?
when you say "CC map" you meant the ColorCorrector node right? I see, I was doing some tests with the composite node and although multiply was quite fast the OSL version wasn't so far behind though.

Well again thank you for the clarification.

[^Lele^]

Yes, i meant the colorcorrection node.
I took a few evermotion scenes, on top of a synthetic one i made (100 x 4k, 16bpc textures), and ran a script to pseudo-randomly change hue to each.
I should add that yes, the testing has been quite fraught with pitfalls, odd performance, and nonsensical numbers.
I will be running a few more tests soon, i'll update you if anything gets better.