Collecting TreeView UI Ideas

I’ve been collecting some ideas about a possible nomad tree UI and instancing in a Google Slides presentation… No idea why but I’ve been enjoying doing that recently :crazy_face:

Still missing a number of things, for example no idea yet if groups would have their own transform … But maybe these pictures serve as a basis for discussions. This is the link to the Google Slides presentation, anyone can edit and add pages if they like: TreeView Scratch - Google Slides (not sure if a google account is needed…)

SLIDE1 (click to zoom)

SLIDE2 (click to zoom)

SLIDE3 (click to zoom)



Note that the scene hierarchy is a big thing and it might take some time before I start working on it.

Instances will work as you described, basically a shared mesh with separate transform.
Not sure about Material, I’ll see the time being (opacity, visibility, chosen matcap).

The “merge voxel/simple” part for the selection is indeed not ideal in the current implementation (scroll at bottom). I was thinking about a popup rather than a separate menu, but both could work.


Dang, those are really nice mock-ups!
Must’ve took a fair bit of time to make (at least for me it would take a lot of time).

Also, I like the header font :smile:

All this reading on instances makes me want to build some low poly meshes to be used inside Nomad!
I’ll have to experiment with importing some low poly objects and see how well they get voxelized.

Really neeeeeeeeeeeed that group tbh. :smile:

1 Like

Thx PXgeek, the Slides app has a nice symbols library (from google images I guess) Icons can be recolored and shadows added, that makes it designing a lot easier.

About the material, I was thinking painting and materials would be shared like the mesh itself. Is there a downside to that? If someone needs to change the material, he could do a “toMesh” then change, and then make instances off that new one.

Awesome work Ray!

Instances will change the game entirely - lay down a bunch of low poly instances to block out a model and then add detail to one & end up with a fully detailed sculpt. Endless possibilities. I may even need a newer iPad to keep up with the things I want to sculpt :nerd_face:

Thanks Bezzo!

I added Group and Ungroup buttons which were missing. Probably would make more sense to hide the “ungroup” button instead of disabling when sth other than a group is selected, not sure

Yes it’s probably only asthetic differences, I was thinking of showing the selection menu in a tab in the same menu, the kind that is usually only shown when there’s little space on the screen

Just thinking out loud … If technically possible, instances of unvalidated objects would be a nice addition to all of this.

For example when changing the ctrl points of a tube, 20 other tubes change along. Any selected instance would show the ctrl poits then and could be validated, which validates all the other intances too.


A lock / freeze option would be very good.

An “add to selection” automatism. If one selects a bunch of objects and tap “hide / eye” all should be hidden.
Same for delete etc.


just wondering… if checkmark means object and all children are selected, no checkmark means object and all children are not selected.
what would be a good way of displaying that some children are selected?

A common hi pattern for “some children are selected” is a checkbox with a horizontal line in it.

A common hi pattern for “some children are selected” is a checkbox with a horizontal line in it.

that could even work as a background graphic in the box so it could be combined with the checkmark.

might be too confusing having 6 different symbols in that box

I don’t think all of those are necessary. I’m struggling to come up with a scenario in which you’d need to see at a glance that all the children are selected but parent isn’t, that parent is but children aren’t.

I’d say just the three-state checkbox is enough.

Do the relationships have to be directly mesh > mesh, or can groups just be groups without a parent needing to be a mesh (like how photoshop groups aren’t a direct layer hierarchy)?

Parents just being conceptual containers rather than meshes themselves would alleviate confusion over the current mesh selection and child mesh selection, since operations on a group wouldjust be to the whole group (though, I think this idea works with mesh parents too).

I think being able to parent meshes would be quite important. Building a character hierarchy with groups only would require twice the amount of items (for example, upper arm group that contains the upper arm mesh and the group with the lower arm mesh and the hand group etc)

Not sure about what the group’s role really would be in that whole thing, just acting like empty meshes maybe for moving things around simulatenously that don’t have a common mesh parent.

Maybe what I think of as “groups” should really just be a null object, and a third “special item” (actual “groups”) make sense that are more like the photoshop groups.

True, single-purpose “groups” would add a lot of hierarchy items (though not necessarily double the amount, since many objects, like finger groups, could be siblings of one another), but I think they’d be clearer in purpose than being able to parent one mesh directly to another.

With direct object parenting, groups or null objects, like you mentioned (which, use-wise, would be effectively the same), would probably be necessary, so that you can have siblings without an actual parent mesh.

I think, though, even with direct-mesh parenting, there’s not much need to see, for example, when children are selected but the parent isn’t. At least, not at a glance in a collapsed hierarchy view. I see the checkbox as more of a button than a particularly-informative display. If you’ve opened up and selected some children, the parent’s checkbox is a line. If you click it, it selects the parent and all children. If you click it again, it deselects the parent and all children (though, Nomad doesn’t currently have a way to deselect the current mesh, which I think it either should, or the checkbox icon should change).

Rambling a bit to brainstorm now:

I guess the display method should depend on what it actually means. Like, what does object/parent selection mean? Right now, if I have multiple objects selected, I can only really merge them or transform them. The checkbox currently serves to indicate selection and to allow multiple selection without holding the Smooth button.

Can that be indicated? With hierarchy likely taking the place of Simple Merge, will we be able to sculpt on all child members of a selected parent like we can with Simple-Merged objects? Can we smooth between them (omg that would be nice)?


About the icons, if it’s presented in a subtle way, getting the additional info in the box for “free” can’t hurt I guess. But 6 states are indeed a bit much, maybe 4 would do, like a slightly brighter background indicating there’s something selected below.

About groups, in other 3d apps like Clarisse they’re usually on the top-level and not related to the scene hierarchy. There’s only references to the scene objects in them, so the same object could be in multiple groups.
Groups in Clarisse can even have “rules” that add scene objects to them automatically. Groups are then usually used to override object’s properties like visibilty, or rendering details. I think this would be a good place where the “groups” concept could go.

At the moment probably out of scope for Nomad. Maybe a compromise until they might become useful is to have something like “folders” that could fit the needs of both users who like specialized objects for scene organization, and those who need nulls so these “folders” would have their own transforms. But still probably I couldn’t live without direct mesh parenting (once it would be there!)

Maybe Stephane has already made up his mind about all this, this thread is just meant for something for him to cherry pick from anyway :slight_smile: