Yes it is a great feature of Blender to control visibility for viewport/render. But in this particular case it is almost useless. Imagine you have few dozens of species of trees, grass and bushes and tweaking each time visibility all of them is extremely annoying.
Even in mentioned by you Particles System it just reducing overall amount of instances, so in a viewport render you see only this limited amount. It is not really convenient when working with a scene, you can’t see full picture as it has to be.
After all, for a Cycles millions of instances doesn’t make a problem, so no need to reduce their amount for preview, it fast and responsive enough, the only real problem when overlay is enabled.
There’s quite a few issues with this design because in Blender you can render with Cycles right in the viewport, but Cycles’ viewport mode uses the viewport visibility and ignores the renderer visibility. This makes using “Is Viewport” as well as View/Render visibility toggle useless if you want to optimize viewport performance but want to see how full scene looks in Cycles while maintaining interactivity.
I’m not sure what that statement means, is viewport node by itself doesn’t hide anything, but in combination with a switch node it can definitely help get better performance on many situations. (There are other ways without a switch node also, like combining it with math to define a number of particles/instances/etc)
Hmm… you are right. I just tested in another way than when i ran into trouble with it and it does work. I remembered it wrong.
My use case back then was putting a collection of about 200K objects into a geonode tree and then just displaying it unchanged. As soon as you animate an object (one that is not in the node tree, do the camera for example) everything crawls to halt.
No matter if you switch most of the objects off via “is viewport + switch node” or leave it on. You can even disconnect the Collection nodes containing the 200K objects completely and it is still slow. It’s really weird. Geonodes appears to calculate everything inside a node tree no matter if it is hooked up to an output or not.
Oh I know that one. For this reason I had to separate a tree scattering system into three objects : one point cloud with attributes relevant to scattering of instances (always on), and two objects responsible for actually instancing the trees, one for the viewport (using lowdef standins) and one for rendering (using hidef trees). Bundling the whole system in a single object+modifier required using two collection info nodes and a switch using “is viewport”, but the mere presence of the “hidef” collection info node made the scene unusable (even though it was supposedly disabled in viewports).
My goal was to keep interactivity (24+fps) for the purpose of character animation, and this workaround did the job well, but is a bit convoluted.
I saw you’ve got the Attributes Viewer listed in the big list of features you linked to so I was wondering if there are there any plans to include overlays for custom vert/edge/face properties similar to the ones we get for creases, sharps, bevels and seams? Historically it’s not been all that important but between the bevel modifier having recently received support for custom attributes, other modifiers probably getting more support and geometry nodes using them as well it’s getting increasingly important to be able to debug these things. Therefore it would be really helpful to be able to visualize them with a colour overlay similar to the other properties I listed so that you can see at a moments notice what custom properties a vert/edge/face may or may not have.
Here’s a visual example of what I want using the existing overlays we’ve got today. I’ve also got a few custom properties for doing bevels that aren’t getting displayed because they aren’t tied to any of the existing overlays:
I can submit a simple example mesh if desired to better illustrate the problem.
The colour would need to be defined somewhere so I’d consider storing it as a single colour for each property like this:
Alternatively the viewer geometry node could maybe be updated to support doing a colour overlay instead of the text for each property per vert/edge/face. Would ideally need to be able to support debugging multiple different properties with different colours at the same time (maybe multiple Viewer nodes strung together).
Otherwise right now the only way we’ve got to debug these things is using the spreadsheet editor or using the values directly in geometry nodes to create debug geometry (like with the Attribute Viewer) to see what’s going on where aside from just using the values directly in a modifier. It would be a lot better to have an overlay instead IMO.
Nice mockup ! Some thoughts, maybe I would rather see the color defined in the overlays rather than at attribute creation, so as not to tie it too rigidly with a given attribute. Also to consider, a unique color is only really enough to represent a boolean attribute, whereas you might want to color a float attribute with, say, a custom gradient (like weight painting).
Thanks! The problem with defining the colour in the theme or overlays settings is that these attributes are custom attributes which means there can be an indefinite amount of them. If I just had a single attribute I wanted to visualize it would be okay, but in the example above there’s three different custom properties tied to bevels and splits which would mean it’d be difficult to get an overview of what’s what. I could easily see people wanting more properties than the three I’m using in this one example though. I believe the best way to get around this problem would be to have the colours of each attribute defined somewhere per attribute.
I agree that these kind of highlights are best for representing boolean values but they actually do support float values as well as bevel weights (ranging from 0.0-1.0) are already represented using this system with the colour fading out for lower values (towards the wire colour set in your theme settings). Here’s a picture illustrating it using bevel weights ranging from 0.0 to 1.0 in steps of 0.1 per edge:
In the image I posted in my last message with the box I’d like to represent both float and boolean values stored per edge. The system we’ve got for displaying bevel weights and seams would be sufficient for my needs I’d just need it extended to support displaying additional custom properties with a custom colour per property as well.
You point out (@RobinKarlsson) that there could be many attributes. With per-attribute colors Separate meshes by different workers could share the same color for different attributes (per mesh). And attributes could overlap in the same mesh. A color-per-attribute solution might give results that are hard to predict.
Small float attribute values (like 0.05) still need to be visible. And we need to consider negative float attribute values too. Or different types of attributes.
In the overlay, we can show/hide some few hardcoded attributes, like Creases|Sharp|Bevel|Seams.
It would be nice if we can somehow specify a set of attributes we like to show in a more general way. And let the theme do the job.
