nvm
[SUP][SUB](10char)[/SUB][/SUP]
Sorry earlier wasnt good this should do it. it flips attribute of hide AND disable_render.
import bpy
bpy.ops.object.select_pattern(pattern="Suz*")
for obj in bpy.context.selected_objects:
obj.hide = not obj.hide
obj.hide_render = not obj.hide_render
BTolputt, with all “due” respect, you’re acting like a child. You’re effectively engaged in a “debate” with me, yet presumably you aren’t even reading what I say, because I am on your “ignore list”. It’s ridiculous.
Just from a cursory search there’s over a thousand places in the code where the layer mask is used, you ignored a great deal of them (including the use in Cycles, which I oversaw as well), but yet you come to the broad conclusion that there is “no good reason” not to change the layer system? For the sake of your clients and/or coworkers, I hope you don’t apply this sort of sloppy reasoning in your commercial projects…
I’ll admit it used to confuse me a bit when I was starting out with Blender in the 2.4 days, but now I find it very valuable.
I’ll admit it used to confuse me a bit when I was starting out with Blender in the 2.4 days, but now I find it very valuable.
quoted in agree. you may want a light to effect only an object on a layer, yet that object to be in other layers to receive light & shadows, in complex scenes with dynamic lighting this is important.
Zeauro, no. The whole point is that 20 layers are not enough. Blender is not a CAD app, so? 3DS Max is not a CAD app either or any other 3d packages on the market. The layer-based organizational approach is widespread and very useful for handling scenes, also helps migrating to Blender (bigger user base = more resources for development).
Anyway, the typical cad to 3d workflow includes cleaning up layers with every app/platforms as incomong cad data could contain dozens of layers and a lots of unnecessary informations.
I should have been more precised.
Blender is a free open source software. Any question is open.
I was just talking about current state.
Blender is not 3dsmax, either. In the last decade, it did not evolve as a CG product complementary to an ecosystem of CAD apps like 3DSmax.
As explained in technical posts, there are lots of things built using current layer system.
So if you want to build a scene that correspond to Brep primitives editability, right now, use FreeCAD.
But don’t expect a change soon in next 2.7x releases.
Layers are one solution to this, another one is to have light object/group exclude/include list for light influence.
I can’t say that it is ‘good’. It is more like ‘traditional’ and has some good points. A really good layer system would use features from both Blender and max, maybe from other apps, too.
I don’t know if it’s “the best” but it certainly is better than the current Blender layers system. 20 Layers is just not enough in many cases. Not to mention that 3ds max recently got nested layers functionality (ability to put layers within layers) which makes managing large scenes even more convenient.
I want to make sure this doesn’t get lost in the thread. We have here a developer pointing out the performance impact of simple bitflag layering. any ‘trivial’ impact to the layer code may have a ‘significant’ effect on performance within cycles.
Since Cycles is also a standalone render engine does this mean that it can only be used effectively inside of applications whose layer systems can be effectively described by a 32-bit bitfield? I would certainly hope not.
Thanks. Let me to be honest, from user side I see that it was solved in all other apps somehow and they are still incredibly usable and could offer very good screen and rendering performance.
If there is a way to rewrite this part in the official Blender, I would support it with EUR100 from my side, and I’m pretty sure we could get a few dozen supporters for it.
Correct me if I’m wrong but are we talking about Exclude/Include functions here? In Max it could be performed per object and per layer, too, also this function exists for lights, but I’m not sure I get it right.
Not at all. The bit-flags can be compiled out of any combination of factors and need not come as one bit per scene layer. After all, there is no practical difference between five visible layers as five bits or five (to fifty) visible layers represented to Cycles as one bit. The Cycles renderer is limited to twenty combinations of visibility, but that does not mean Blender’s scene organisation layers should be limited to that.
Physics has it’s own layer flags separate from & in addition to the scene organisation ones. I see no reason why that’s anathema for the renderer.
All the chatter about performance is misleading. Performance is not the problem.
Tinkering with the code I found out that the problem is that, quite surprisingly, Blender doesn’t have Layers. Blender has integers that are coincidentally used to represent layers. And not even all of them, just 20.
The bad news is that integers are stubborn: you can’t change the way they behave, add properties or otherwise relate them. All they want to be is frigging integers. You want something else? Talk to the floats, they might listen.
Because of this very specific representation, you cannot adapt the current system, you’re throwing it out of the window entirely, with all the code that even dares to think about it.
The replacement requires a decision from the blender foundation because it can impact how the rest of the system works.
Can an object belong to multiple layers? Which states of parent layers should propagate to children layers?
Or even “should we drop the layer concept entirely and replace them with groups?”
Groups got lucky, they are actually Groups.
I wasn’t trying to advocate for any particular side, I just hate to see users asking for something from the developers, only to drown out the developers when they actually chime in. I just didn’t want to see Lucas’ input pushed out of sight.
As a user, I would love to see more layers, which are nameable and COLORABLE(!*) . I’d rather have 10 layers that I can name and color than 100 layers that I can’t distinguish from eachother. Frankly it’s hard enough keeping track of just 20 layers at this point, so it’s hard for me to vote for more. I want quality of layer management, not quantity.
*Yeah, I’m kicking the colored wireframe beehive.
I understand that SterlingRoth. I was simply pointing out that an optimisation limitation in a renderer need not be a limitation on the DCC application itself. Bullet already shows that bit flags for a special purpose are acceptable in Blender. That same principle can be applied to Cycles.
Which is precisely the sort of use-case that bitfields excel at, in terms of efficiency.
Not true, other applications like Lightwave and Unity3D also use bitfields for layers, they have the same limitation. If an application implements layers differently, they can’t do the same tricks with bitmasks.
Wait, you “just found out” about this? I basically said that in my very first post. Apparently, you didn’t even understand the problem at all. Those integers are the bitfields! And they’re all about performance.
In the usual fashion, you have shifted your claim from “we could just replace this system with something else and the performance difference wouldn’t matter” to essentially “we could have a separate system for this use-case” (which is what I was saying from the beginning).
Obviously, if you raised the scene layer limit by superficially replacing it with something else and then handle the special cases under-the-hood, you still need to keep the 20 layer limit around somehow. Certain features would then only work on the first twenty layers, or you would need a layer system nested inside the existing layer system. Either solution is confusing, and it’s not an easy design decision.
Instead, the old system could just stay as it is, while there could be a new system designed specifically for organization, which is cleanly separated from the other system. The biggest problem I see is finding a good name for it… (Organization Layers?)
Dear Beerbaron:
‘Not true, other applications like Lightwave and Unity3D also use bitfields for layers, they have the same limitation. If an application implements layers differently, they can’t do the same tricks with bitmasks.’
I’m not surprised at LightWave, they are promising integrated Modeler/Layout (or how they call it, I haven’t used it since a decade) since 10 years? It is not a miracle they have smaller and smaller piece of the cake.
Unity - and other real-time engines are not DCC tools and are lightyear behind Blender or any DCC tool in usability and toolset.
Also there are Layer systems as add-ons for Unity.
Instead, the old system could just stay as it is, while there could be a new system designed specifically for organization, which is cleanly separated from the other system. The biggest problem I see is finding a good name for it… (Organization Layers?)
Organization Layers are fine (maybe too long), but I still don’t understand why we should have 2 layer systems (beyond that it is a ‘legacy’). For me SceneLayers are for organization purposes primarily what could be combined with visibility options, colors, ‘freezing’, by layer properties, etc.