Spreadsheet: support showing data of nested instances (alternative 1) #124186
No reviewers
Simon Thommes
Hans Goudey
Falk David
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#124186
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "JacquesLucke/blender:spreadsheet-instances"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Previously, it was not possible to see detailed information about instances in the spreadsheet. Only the attributes on the top level instances were shown. Now, all nested instances can be inspected too.
Combined with #114910 this will make inspecting more complex geometry with the spreadsheet much more feasible. It's also an important part of integrating grease pencil into geometry nodes because it makes it more obvious how layers are converted to curve instances.
I see object and data are displayed separately. Does that mean that if I have an instance object that is outputting both mesh and curve for example it will show both as children of object?
The answer is probably yes, but I'm not sure if I understand correctly. Please provide a specific example.
I have object with geonodes modifier that outputs both curve and mesh
If I put this object in instance collection, will I see both Mesh and Curve domains for that object in instances subtree?
You're question is still kind of vague unfortunately. Ideally you just try it yourself or provide a .blend file with the spreadsheet open so that I can just open the file and screenshot it to show what you want.
It's possible to have instances that have more than one geometry type.
Yep that's what I was interested in. Shreenshot shows it. Thanks.
WIP: Spreadsheet: support showing data of nested instancesto Spreadsheet: support showing data of nested instances@blender-bot build
This works great, the spreadsheet is getting quite powerful now :D
@ -89,0 +94,4 @@*/void to_geometry_set(GeometrySet &r_geometry_set) const;std::string name() const;Better to return
StringRefIMO, I don't think we'd generate this dynamically any time soon?I find it quite confusing how right now the
Instancesdomain and the Geometry Set (?) have the same icon. Especially, since theInstancesdomain is a selectable element and the Geometry Set just selects the first contained domain.I'm not sure the Geometry Set needs an icon at all tbh. This also makes me think that maybe we should draw the selectable elements in the tree differently in general. But for now I'd try removing the icon.
In line with this (but also out of the scope of this task and more of an idea):
We could think about completing the tree view with the top level geometry set (which only really makes sense in combination with #114910 ). To not lose more UI real-estate on the left we could just draw the name of the top level geometry on top with a separator.
This could even be pinned to the top of the region regardless of scrolling and accumulate the headers of additional nesting levels. I'm not sure if my description is clear, I'm thinking of something like for example in VSCode to show the nesting hierarchy of functions and loops at the top of the window.
Not sure if this is necessarily part of this PR but I do think showing the hierarchy in this much detail also makes it necessary to provide a flat view of all the different geometry sets.
Thanks for the feedback, I removed the icon from generic geometry instances now.
Feels like a separate thing to me, but can be useful, yes. Would probably also not be too hard if we know where to put the display setting. Still seems independent from this patch to me.
Not entirely sure what you mean. Do you mean showing the data of multiple selected objects?
Uiui, sounds like something that could be useful, but probably needs a more general implementation in the tree-view itself (which would also benefit tree views in other places in Blender).
The gap with empty space looks fairly ugly to me. Is that purposeful?
This looked worse to me:
I could also not show any icons there, then it could look like this:
TBH I think having an icon for geometries is the best solution and is consistent. I like having the icon for object types, it helps to clarify the behavior for non-geometry objects.
Which icon would you suggest me to use?
That's tricky unfortunately :/
Maybe
CUBEorMESH_CUBEwould work? Or maybeDOTis better than nothing and at least fills the gap?I meant showing the name of the top level geometry set as the root of the hierarchy at the very top. Just as an idea of exposing that in other places than the geometry socket tooltip.
On the icon topic: I agree that the gap looks bad. I'm not super bothered by not having any icon there without the gap but can see how it would be nicer to have something there. I'm not sure tbh, if we can have a sensible icon for 'Geometry' since that is such a non-specific concept. Doesn't really feel to me like that will lead anywhere in the context of this PR. I don't love the dot, but it looks like the best out of the current options imo.
I think that would be just a small enum in the top bar to switch between tree and list view, pretty much. But yes, that can be totally separate.
I see, would be doable, but it's a separate topic from this patch as well. Also it might be annoying when the geometry has no name, or it's not displayed in this case.
Is there something left to do for this patch currently? I added the dot icon already.
@blender-bot build
Seems reasonable to split into separate tree view items. Also makes it easier to read imo.
@ -67,0 +232,4 @@public:GreasePencilLayersViewItem(const GreasePencil *grease_pencil) : grease_pencil_(grease_pencil){label_ = IFACE_("Layer");This should probably be named
Layersto make it consistent withInstances. Maybe that should be done in a separate PR though.Seems to make more sense for it to be consistent with the other attribute domain names which are all singular.
The difference is: Those are not expandable in the spreadsheet. With Layers and Instances, you can actually expand them and see other geometries inside. I think having the plural there makes sense.
The fallback name for the geometry set should also be used in the spreadsheet entries, if it's used for the hierarchy, to make it less confusing.
(side note from Dalai: we could pre-set some names in the primitive geometry nodes to not have everything called geometry, but that's a separate topic)
The dot icon really doesn't work too well imo, we might just need an actual new icon for the geometry set. It seems odd to me why instances, objects, collections, lights, etc. all show up with a proper icon, but geometry sets just have the dot.
I looked a bit more at the existing icons, but nothing really seems to work.
Some ideas:
OBJECT_HIDDENSTICKY_UVS_LOCMaybe even
THREE_DOTSorLIGHTPROBE_VOLUMEcould work better than the single icon tbh.I do still find it problematic how it is not clear which elements in the hierarchy are inspectable in the spreadsheet and which aren't. The fact that now also
Mesh,Curveetc. are also not interactive doesn't really help. Maybe it could help to make them at least expand/collapse on click.But in general I still have a problem with how there is no differentiation between the component and the domain items in the hierarchy. I think it's confusing how both
InstancesandMeshare expandable. But one is a domain and can be instpected, while it does have children and the other cannot.I don't really have a solution to that right now, sorry. Maybe with the changes I suggested it feels fine. So let's try expanding when clicking on the name.
Spreadsheet: support showing data of nested instancesto Spreadsheet: support showing data of nested instances (alternative 1)Closing this in favor of #125293.
Pull request closed