Today I finished converting a rather complex node tree material into an OSL script and found some results that may be of interest.
The original node tree is by Rasmus Seerup and is explained at http://materialw.wordpress.com/materials/rock-material/
A preview of the final material -
And a blend file that includes the original nodes and the script so you can play along - rock_material.blend (1.29 MB)
NOTE - this script highlights an osl bug that was fixed a few days ago - you don’t want to compile this script if you have not updated osl in the last few days.
Remember to enable osl for the script material and you may want to disable it for the nodes (see later)
So lets start with a 300x300 preview render. On my corei5 the original node setup renders in about 3.9 seconds. The osl script version renders in about 6.5 seconds. Well that doesn’t sound too good. If you follow along and watch the renders you will notice that the node setup starts rendering straight away and the script version takes about 4 seconds before updating the render, drawing the rest of it in 2.5 seconds. Well that is something I submitted to the bug tracker to look at but for now lets not worry about that.
If we ignore the first 4 second delay the nodes render in 4 seconds and the osl script in 2.5. Well let’s see if we can prove that theory. Let’s increase the render resolution to 500% and see what we get -
nodes render - 1:15
osl render - 0:34
That’s one minute fifteen seconds against thirty four seconds - so in a large render the osl version renders in less than half the time of the nodes setup, which is even better than the 4 to 2.5 seconds we guessed at with the small preview.
So is osl that much better? NO. But it does give you the opportunity to cut corners, so how did this script get that boost?
(and out of interest the original nodes setup rendered with osl enabled gets times similar to the original node setup - plus the extra 4 second start delay)
By looking over the original nodes I saw that a concentration value is input and always divided by 10 before going anywhere - I reduced the input value and removed the divide by 10 - that removed about 10 calculations. That can also be done with the original node setup (you can try that one).
The nodes included a noise texture node - well looking through the blender source code you can find the original osl script for that node. I copied the noise function into my script and removed the calculations for a colour value that we are going to ignore anyway - there’s some more excess calculations thrown away.
Not sure of the figures but there is some overhead added within the node setup to pass information between each node so squashing it all together into one script can reduce that overhead as well.
Well we removed 10 divisions and 10 colour calculations that we didn’t need to do to get the result we wanted. the built-in nodes are good and are designed to cater to the needs of every render that will be done - does your need every feature? OSL gives you the opportunity to skip the calculations you don’t need and speed up your render times.
(sheeeesh I sound like an advert there 
)
Attachments
