Ok, what about just Copy and paste/Array in groups and then exporting to V-Ray. Is that a thing?
Mostly I want to set one light (specific LED specs) and then array out to thousands of locations.
1 Like
Hi -
That sounds like a new question in the V-Ray category.
-wim
In this thread about including lights in block definitions, I’d like to add here that light management seems to need an overhaul in general.
Apart from wanting to manage iterations of lights in blocks, much of the time other iterations of lights do not behave correctly as it is. Copied and pasted lights often behave as if they themselves are block versions of the original copied light (i.e if one of the copied lights is edited, all the copied lights change their attributes to those new settings.) This week my issue is that copied lights do not have any effect in the new location shown in the model. Their effect only is seen from where they were copied, as if they were copied and pasted into the same position as the light they were copied from. I have copied and pasted 8 lights in a model, and though Rhino shows them in different locations, Rhino (and Enscape) casts all of their light where the original source object is located. I have posted about bugs like this in other places on the forum where lighting is discussed, and been assured that copying and pasting works fine. It definitely doesn’t. I don’t post about this anymore where lighting in general is discussed as it seems to attract little attention other than from users without depth of experience. Maybe the folks on this thread have enough experience to encounter these problems. Maybe together here a work-around can be found. I will probably create every new light from scratch from here on, which is going to be labour intensive.
1 Like
In the latest Rhino 8, spotlights don’t work in Raytrace, so I kluged up a spotlight by putting a linear light inside a can. So now each spotlight is a light and a can. So then I thought it sure would be cool to turn this pair into a block. Oh boy! What an amazing idea! I’m an ecstatic fountain of anticipation! Oh but wait. When I put a light into a block, it simply disappears forever. Heavy sigh…
As I mentioned in your other thread, spotlights work in at least Rhino 8.4 (internal build at this point in time).
Has anything changed about the fact that blocks cannot contain lights?
Happy new year btw.!
Nope, lights still aren’t actual objects that can be added to blocks.
(And happy new year to you too)
Similarly, we note that decals are not functional within blocks. What I’d like is to create a light fixture with a decal. But alas, no.
Programmatically, what I imagined was that blocks are simply selective viewports to items. This would make everything available to any block, each item need not be contained exclusively within a specific block, and each item would retain all of its potential properties and accoutrements.
My context is custom boat building. The money is in luxury boats that people mostly just look at and rarely use. If everything is luxurious eye candy, then money is no object. Like Nike swooshes everywhere. I personally think this is silly, but I’m not the guy spending the money.
Not sure what you mean, decals work fine here. Here a box in a block instance. The box has been decalled before it got put into a block. The block instance is copied three times.
decals_in_blockinstances.3dm (313.7 KB)
I tried to reproduce, and it may be that the problem is not related to blocks, but instead resulted from general decal wonkiness. Possibly I decalled the object with only a render viewport open (no Raytrace), and regardless of whether the object went inside a block, the decal would not have appeared when Raytraced.
Generally, some messing with materials separate from decals gets the decal to appear when Raytraced. Very repeatable is (1) decal not appearing, (2) change the material to something else, (3) turn the decal OFF. The decal appears (when its check-box is unchecked). Then turn the decal back on and it remains.
Decals disappearing while in Raytraced and changing material settings is a know issue: RH-63193 Material updates on objects with decal in Raytraced fails
Note that this is a separate issue from lights in block definitions though.
+1 please!
Light in block.
Please. rhino 7.
1 Like
Hi Arcade -
This is currently still on the “Future” list, and as such not something that is considered for Rhino 9.
→ RH-48093 Light objects should be allowed in Block definitions and instances
-wim
+1 for lights in block instances 
thanks.
please, how is it still being ignored to include lights in blocks.
1 Like
+1 for lights in block instances. Will we have it in Rhino 9 ?
1 Like
Hi Sven -
RH-48093 is public so you can always check the status.
At this point, the release target is set to “Future”, not Rhino 9.
-wim
1 Like
Hi @wim @bobmcneel
Firstly, I am not a developer, only a user / architect. I was reading this thread over here:
I kinda understand that conflict arises with lights as they are special objects.
What if Mcneel worked out a new type of object, as a “multi-instance group” (just like revit groups). I imagine this type of group would allow dynamic changes that would affect all other versions of the same group.
This special new object type could contain multiple other objects, say blocks, lights etc., but could also have constraints, such as it could not allow scaling or complex transformations such as shear, bend etc., It would also disallow nesting over other groups or multi-instance groups.
One could then make a group with say a block (light fitting / shade) and a light and copy / array this ‘dumb’ object around.
On downsave the group simply is exploded.
Regards,
I was thinking along similair lines.
The problem seems to be that the current object type for lights and the current coding vocabulary for blocks aren’t broadly compatible.
I wonder if developing a completely new “Repeating Light” object and/or a new “Multi-Instance” group (similair to Arcade’s suggestion) would be effective. Even if these new object types were exclusively for instancing lights all around, it would be a big improvement.
(These new types of objects would need to be coded so as to have the backwards compatibility which it seems is the biggest obstacle to the current light/block combination.)