just wanted to let you know I’m back at fixing the shaders now that I’ve fixed some other bugs (planar environment, linear light support, crashes, etc).
I made a video of improving Glass and Picture material shaders:
Note that these new shaders aren’t yet in Rhino WIP, just wanted to let you in on what I’m working on at the moment.
Next up from where I left the work in the video: Plastic. Then Paint, then Custom.
Your example of the roughness being better in a range about 0 > 0.15 might be right, however it’s maybe good to consider adding an option to overstep these limits. A GUI way would be to allow for both a slider input and a numerical box. The numerical box would not adhere to the slider limits and maybe even stretch it.
i guess the “picture” material could just be named “constant” material if it does not get diffuse light. But it should still work using a texture so it acts like a pictureframe in the regular display modes.
btw. adding an emission material (with texture) would be a useful standard material as well since there is no way to add a texture to a rectangular light.
Also a default rubber material should be included along with a fully featured subsurface scattering material. btw. i´m not able to get that to work with GH yet.
I agree, all render engines support this, and in studio photography they call it “gel”, either as single color filters, or more complex sheets.
So either that or have proper light emitting materials with brighter than 100% as option.
That probably could be fine for the specific Cycles versions of the materials. These specific shaders I’m working on are to be conversions of the Rhino basic materials as they currently exist. The polish/clearity/etc sliders already can take numerical input, but those will still clamp. That means for those Rhino Basic materials it probably won’t happen.
Now, the way I am adding these conversions is through specific Cycles render contents, as you already can see in the material list when adding new ones. For those I could eventually add More Options To Play with.
If you mean by pictureframe the Picture command, then sure, it will do that. I noticed just now that I still have to do greyscale, self-illuminated toggle (current version then is with greyscale off, and self-illumination toggle on, no transparency) - but I’ll add that tomorrow then. Something for a new screencast!
Note though that this won’t make objects with such emissive materials work as projectors, since there isn’t a sense of direction in these (mesh) lights. At least there won’t be too much detail:
There are many material types that should be added, but let me first do the currently existing Rhino basic materials
You mean that the subsurface scattering node doesn’t work for you?
Brighter than 100% what? For Cycles assigning an emissive material to a mesh, i.e. making it a mesh light the strength is W/m2 (see bottom of page on Cycles Emission shader). For a Cycles emission shader - and emission shaders are used for all primitive lights too, you could set strength to something staggeringly large, like 1000. But that will in most cases blow out nearby objects, and that is currently not really an option, since at the moment from Raytraced you can’t save HDR renderers (would be nice to have though, i.e. as EXR).
Anyway, note that in the screenshot above I have strength set to 1.3, which is already 0.3 larger than one normally would.
Hi Nathan, sorry for not being spesific, it was ment as a general comment to how Rhino has handled this:
As I think it is crucial that this is handled on a general level and not only on a cycles level. OpenGL, Rhino Render and all 3rd party renderers should also be able to read those values imo.
(Here is cycles showing 100% pure white Emission, and it’s not very bright:
So I wote that Rhino materials are given an extra workover rather than having cycles just simulate their limits
I get it now. I’ve opened a feature request for that here: RH-34435
edit: I realised that emission isn’t a very good example in this case, since there’s no separate strength modifier… Not sure if this request will go anywhere
[quote]Hmm, I don’t quite get that If you have a Blender Cycles node setup, you could post a screenshot of what you mean. That might help a lot
[/quote]
Sure, i mean something like this should control the backfacing, or make an emission shader cast light only in one direction:
But it does not work in rhino cycles, maybe because i am using the blend component, as there is no shader mix component ?
btw. the color of the transparent component is set to black, if i turn it to white, if still does not show the red of the emission component, but i can see that the backface is colored differently…but no red.
…edit, ok, it seems that the default strength for the emission is set to zero, if i change this to 1, the red color shows up. Is this the correct way to make backfacing materials, in this case make an emission cast only into one direction ?
it does not seem to work using the groundplane feature though, so i added a plane below the half cylindric shape.
Weird, it should all just work. This is what I can get:
Yes, something I need to fix still. Annoys me too
For the transparent BSDF to work (be completely transparent) you indeed have to set it to pure white. Any other color = tinted transparency.
Yes, backfacing or frontfacing, depending on what you put into Closure 1, what in Closure 2 For the Blend node (which is just another name for the Cycles mix closure node) if Fac is 1.0 it will be completely Closure 2, if it is 0.0 it will be completely Closure 1. If a face is viewed from the back the Geometry::Backfacing output will indeed be 1.0
It works with ground-plane, just not that well with the shadow-only version, because well - it is only catching shadows, not light! If you want to magical ground-plane, make sure it has a material.
i´ve found the reason, it seems to happen only when rendering using GPU (Tahiti), using my CPUs it renders in color instead of black. Hm, does cycles support SSS via GPU ?
When I get otherwise Rhino features working on CPU/CUDA rendering I’m sure we’ll make a jab at all those missing stuff as well. OpenCL isn’t the highest priority yet, unfortunately (I do have a Tahiti in my dev machine as well, but it isn’t my default render device)
@nathanletwory, please try to assign a texture to a shaders color slot as well. It fails to render the image over here properly when GH is used, i only get a distorted result with strange banding. This happens with GPU and CPU. Also i do not know how to make it use UV texture coordinates yet.
Not with this plug-in. This one is specifically for Rhino WIP, as it relies on the ChangeQueue. The ChangeQueue is a new piece of SDK, which does not exist in Rhino 5.