I use an array of 10 small linear lights to simulate an LED stripe.
The lights are grouped. When the group is selected, I change “Intensity” and “Color” in the properties panel for all lights simulatanously. So far so good.
But, … no matter if I set the intensity to 100, to 1 or to 0, the image is brutally overexposed and cycles seem to ignore the intensity settings.
I tried to set the color of the lights from white (default) to dark grey, black, and even red just to try if it makes any difference. … Nope. Settings are completely ignored.
Just tested with a single light: Same behavior…
In addition, sometimes the lights are ignored (as in “switched off”), although visible/active. When I toggle through Shaded, Rendered, Shaded and back to Raytraced, voila, the lights are suddenly “switched on” without any other actions involved. Just happen after closing and reopening the file.
I really enjoy working with V6, so many cool new and useful features. I just upgraded 10 licences for my team. Unfortunately, the last hour trying some quick and dirty rendering experiments made me realize that V6 is not ready for prime time in some uses cases. (See me other bug report from half hour ago)
Maybe this is just me or my system. Fixes much appreciated (workarounds too, still I’d prefer fixes
Pls find my system infos below:
Rhino 6 SR4 2018-4-3 (Rhino 6, 6.4.18093.10341, Git hash:master @ bfdc5b98e028aea659372f9a67d36edb21f28713)
Licence type: Testversion, build 2018-04-03
License details: Cloud Zoo. In use by: FrankS ()
Expires on: 2018-04-23
Windows 10.0 SR0.0 or greater (Physical RAM: 16Gb)
GeForce GTX 1080/PCIe/SSE2 (OpenGL ver:4.6.0 NVIDIA 388.13)
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 10-27-2017
Driver Version: 23.21.13.8813
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB
C:\Program Files\Rhino 6\Plug-ins\Commands.rhp "Commands"
C:\Program Files\Rhino 6\Plug-ins\WebBrowser.rhp "WebBrowser"
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp "Renderer Development Kit"
C:\Program Files\Rhino 6\Plug-ins\RhinoScript.rhp "RhinoScript"
C:\Program Files\Rhino 6\Plug-ins\RhinoBonusTools.rhp "Rhino Bonus Tools"
C:\Program Files\Rhino 6\Plug-ins\IdleProcessor.rhp "IdleProcessor"
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp "Rhino Render"
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp "RDK_EtoUI"
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp "Renderer Development Kit UI"
C:\Users\fsp\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\PanelingTools (6caed836-bc06-4ebc-b1fd-e10886a0dc94)\2017.11.17.800\PanelingTools.rhp "PanelingTools"
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp "Snapshots"
C:\Program Files\Rhino 6\Plug-ins\Alerter.rhp "Alerter"
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp "RhinoCycles"
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp "Toolbars"
C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp "3Dconnexion 3D Mouse"
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp "Displacement"
C:\Program Files\Rhino 6\Plug-ins\Calc.rhp "Calc"
C:\Users\fsp\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\SectionTools (fbdb1d7f-8cfb-42c1-9858-87cb6315932c)\2018.1.9.1166\SectionTools.rhp "SectionTools"
The file was V5 before, I imported it into V6.4
Hence, it was never opened in V6.3
As I said before (in the bug report about zombie lights), these behaviors seem hard to reproduce and light system seems quite shakey to me. If I change a few parameters forth and back (exactly), I seem to end up with completely different results. Barely visible light vs brutally overexposed after closing and reopening a file.
Trying to setup / strip down a test file for you, I see a lot of inconsitent behavior, though directly after opening the file everything seems to work fine.
I might have narrowed it down a bit:
While in Raytraced, any changes made to the light intensity are ignored. With each change of the value (hitting enter/tab), Cycles will start counting render passes from 0 (making the user believe that the changes got applied), while the changed settings are in fact not applied. Only when you change to another display mode and back, the changes will be applied.
Same is true for light color, layer visibility (of layers with light objects), …
Ah, linear lights. Somehow I missed the word linear from your original post. The linear lights have indeed been a bit of a headache. They used to update nicely, so I am not sure what changed (probably the fixes I introduced for By Parent material cases on block instances - but that is just guessing atm).
Do you mean sometimes linear lights just turn themselves off, i.e no longer light the scene? That I haven’t been able to reproduce. The only thing I see here is that linear lights in an active Raytraced viewport don’t react properly to changes. Toggling the viewport will show those changes.
Or stay away from linear lights - those are the heaviest anyway, since they aren’t primitive lights for Cycles. Linear light is an actual mesh with a light shader on (emissive). That makes adding multiple linear lights rather expensive to raytrace, especially if you embed them in surfaces as your model does.
Indeed. Here is my user perspective: I know there are differences regarding computation load for light types, still I expected all types to work/behave consistently. Thanks for confirming this is buggy. Looking forward for a fix.
The lights acting as if they were „switched off“ is most likely just a symptom of the same bug.
I create 1 linear light (visual result fine)
I copy the light 10 times (image overexposed)
I reduce intensity incrementally, nothing happens. I end up with intensity set to 0 (image still overexposed)
I switch display modes and back to Raytraced. Lights behave as if they were „switched off“, seemingly without changes in the light settings.
I agree that if you know what is wrong due to the update bug, you could figure out myself why the lights seem to be off. But again, from a user perspective without this knowledge, it is utterly confusing.
Last on the list:
After you had a chance to look at my file and assuming I would like to simulate an LED stripe (think of an electrified scotch tape with LEDs on it, the stripe is concavely bended along the equator/rim of the hemisphere, LED pointing to the center).
Which type of light setup would you suggest to use to for cycles rendering?
An array of point lights?
A mesh stripe with emissive material?
Yes of course - I am not saying this isn’t confusing. I have created the bug report and I will work on it after I finish my current item.
I think the linear light is just fine, especially if you want the physical shape of the light to count. In this case just make sure the light isn’t intersecting with other geometry.
There is a hidden material called Cycles Emissive (it is hidden because it tends to cause sporadic crashes still), which you can add to objects so that you have essentially the same as linear lights.
The difference with Cycles Emissive (and its bad UI) is that you can actually set a fall-off. Rhino lights don’t have a fall-off, which can be confusing as well, because well, the light energy never falls off based on distance (other than energy absorption through BSDF evaluation).
If you are up for testing this then you can use the TestShowPrivateContent and set the Cycles Emissive material to your light leds. I have to look up again what the values are supposed to mean (I kinda left the UI in a developer-y state, naughty me).
I just realised (and verified) that the crashes I am seeing are actually unrelated to the emissive material - I see crashes in my intel driver in OpenGL drawing code of the material preview thumbnails.
Fall-off values can be: 0 constant (no fall-off), 1 linear and 2 quadratic
Realized emissive energy is based on mesh area, i.e. larger object means more powerful energy output for same emissive material
A “hack” light (zero light intensity) needs to be added, since Rhino itself doesn’t know yet that these emissive objects are now to be considered lights. Without the hack light and where no other lights exist, including sun and skylight, Rhino adds a default, directional light which is always over the left shoulder.
I chose boxes since those will be very simple meshes. The linear light is a cylindrical mesh, which will have more faces, thus is a bit more expensive (and has only constant light, no fall-off)
The emissive material helps a lot, as I can assign it to any (simple) object, instead of composing shapes from light objects. Did not crash in one hour playing around with it.
The setting update behavior with emissive materials as light sources is the same (buggy) as with the previous approach. I always have to switch display modes and back to see changes in Cycles. Getting used to it, but would prefer, … you know what
Yah, I run Intel HD Graphics 630 as my main display, its driver crashes in certain cases. I will keep running it as my main display until we have managed to find a fix for the bug.
