i think layers are more "power user" stuff - so we can be less constrained by immediate intutiveness
i think layers are more "power user" stuff - so we can be less constrained by immediate intutiveness
BThat's true
Athat's not bad
Awe already have the selection tray
Ahow about "if the user tries to change layer with an active selection - they are asked to choose between 2 actions: drop selection or move selection to layer"
Ai don't like interrupting the user with choices - usually
BActually, let's merge the two ideas
Abut dropping the selection is almost as surprising as the current behaviour
BWe have a toggle on the selection tray
BIf it's on, selections survive layer switches
BIf it's off, they don't
BThis way the user gets to choose without being interrupted
Ahmmmmm. how about 3 settings: "ask, always move, always drop"?
BAlso works
Athat way the user gets to learn about the option the first time they use it
BSounds good!
BWe can have it as "always ask" by default and leave instructions on the bottom of the prompt to switch
Adamn. does that mean i have to implement this now? 
BGod I wish I could help out on this one
Ame too! 
BHey if you take long enough, I just might!
BNext week I will finally have access to my main setup but just not to a VR headset so maybe I could still help out on the side
BIsn't monoscopic mode specifically for testing without a headset?
AYeah. You can do a fair amount without needing a headset but testing anything involving 6dof interaction is mostly impossible.
Ayou can paint, click buttons, move panels around.
BWho needs the third dimension anyway
BI'll give it a shot on the main setup then
BIt kept crashing when I worked on OG tilt brush
Afrom the editor you need to also disable steam's "automatically init vr"
Athere's docs on for this if you search "monoscopic"
BOooh that would explain a lot
BThanks!
AJust read through all that.
From a users perspective, the value of layers is in keeping things separate so you can modify similar things without interfering with things you don't want to modify. Typically the advantages of layers are object isolation, and ability to "bulk change" everything on a layer
Open brush is a bit tricky, because in addition to the usual consideration of keeping objects or parts separate, there is huge utility in being able to select by stroke type or color. Presumably imported scenes/objects as well.
In traditional applications, layers create a user-tracking problem. Actively selecting a layer before working on it is needed, and failing to do so creates confusion such as placing content on an incorrect layer, or not being able to create content at all, because the strokes are expected on a different layer, just the active one, or just the top one, for example.
In most VR programs I've seen with this capability, active layer selection (identify layer, work on it) and usually "lock layer" options are how things are handled.
Having the ability to move objects/items from layer to layer is a fairly unique construct, as far as I know. So we're in a bit of new territory here. Especially if we have a mode (such as select all flat brush strokes) that can potentially cross layers or reorganize them. While very powerful, it's likely to be a bit confusing. Even more so, as groups are a form of default layer on their own.
From a users perspective, the value of layers is in keeping things separate so you can modify similar things without interfering with things you don't want to modify. Typically the advantages of layers are object isolation, and ability to "bulk change" everything on a layer
Open brush is a bit tricky, because in addition to the usual consideration of keeping objects or parts separate, there is huge utility in being able to select by stroke type or color. Presumably imported scenes/objects as well.
In traditional applications, layers create a user-tracking problem. Actively selecting a layer before working on it is needed, and failing to do so creates confusion such as placing content on an incorrect layer, or not being able to create content at all, because the strokes are expected on a different layer, just the active one, or just the top one, for example.
In most VR programs I've seen with this capability, active layer selection (identify layer, work on it) and usually "lock layer" options are how things are handled.
Having the ability to move objects/items from layer to layer is a fairly unique construct, as far as I know. So we're in a bit of new territory here. Especially if we have a mode (such as select all flat brush strokes) that can potentially cross layers or reorganize them. While very powerful, it's likely to be a bit confusing. Even more so, as groups are a form of default layer on their own.
AI think in this circumstances the user needs to know if they are:
- Working on all layers
- Working on an individual layer (and exactly which one that is)
- Moving things across layers needs to be an obvious and conscious decision, as it affects structure at a fairly deep level.
AI haven't used layers enough in this program to really be sure about exact implementation.
As a user it's important to know (probably by just glancing at the panel or on-screen ghosting)
As a user it's important to know (probably by just glancing at the panel or on-screen ghosting)
- What area I'm working on
- If I move it or change it, where is it going and what parts are going to be changed
- If there are areas I'm not able to work on, then I want that to be immediately apparent
Ideally I want to know this directly without navigating menus that aren't in plain sight. - Deeper menu access is acceptable for a specific function that is temporarily available
(examples: select strokes by color within jitter range, select instances of disco brush (currently dabbed/selected brush))
AAnyhow, that's where my head space is at in terms of end user goals. Doing all of that elegantly, I'm less certain about
AWhen it comes to something like "select all pink brush strokes"I would like the workflow to be as simple as:
- Select a colour (or colour range)
- Choose "select all strokes of this colour"
AYes, that would be ideal. Although if layers and layer actions become more developed, there are advantages to being able to affect just things on a layer.
I think this would be especially useful with imported objects. Although I can see some form of localization control (current layer or group toggle) being quite helpful when rebrushing complex objects in a complex scene. A lot of times the issue is just 'getting at' mostly subsurface portions of a scene element that are otherwise hard to get at. Or for example, 'the hundreds of dragon scales should be blue, but I don't want to change the cloud colors'
I think this would be especially useful with imported objects. Although I can see some form of localization control (current layer or group toggle) being quite helpful when rebrushing complex objects in a complex scene. A lot of times the issue is just 'getting at' mostly subsurface portions of a scene element that are otherwise hard to get at. Or for example, 'the hundreds of dragon scales should be blue, but I don't want to change the cloud colors'
OBeen a few weeks since I did it, but here is a commit that adds working texture loading for gltfast... I still need to use gltfast for exporting before I feel like the move to gltfast is "complete" https://github.com/omn0mn0m/open-brush/tree/features/gltfast
GitHub
Open Source Fork of Tilt Brush. Contribute to omn0mn0m/open-brush development by creating an account on GitHub.
ASeems like as good a place to put this as any, unless it's changed. Unity cameras data side by side
A
Amay put up an annotated version of this after a bit more experimentation
Awow. That's great progress! From what I've seen export is simpler than import.
OThanks :) I'll get to it eventually, but I've been swamped with school
AIt's unlikely that we'll put out another release on 2019.4 so updating it to match the xr_v2 branch on 2021.3 would be a good idea. I'm happy to have a go at that if you like?
AHave you got any work not yet pushed to your feature branch?
OI think the only reason why I kept it on the older branch was because Unity was giving me errors trying to build
OAnd nope, that's all of it so far :)
Aok. i'll see what i can do in the next few days
OThanks, I appreciate it
AWas just discussion yesterday whether we can support gltf animation inside Open Brush (not editing, but at least showing existing animated models). Any idea how much of that GLTFast supports?