It kept crashing when I worked on OG tilt brush
It 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?
OLoaded with some geometry errors, but meh
MShould support animations fine, I use that in production in other apps. May need the import settings tweaking?
AYowzer!
MAlso our build times are gonna skyrocket 
ODefinitely needs some import setting tweaks. Not all the textures are loading
OWhat it should be looking like https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/BrainStem/screenshot/screenshot.gif
GitHub
glTF Sample Models. Contribute to KhronosGroup/glTF-Sample-Models development by creating an account on GitHub.
OI've been doing web development the past few years and working on this has made me realise I kinda miss compile time coffee breaks
Asave/load of sketches with imported models seems to work!
ABiggest bug I've found so far is that the scale of the thumbnail model is sometimes so big that it fills the scene
ATry the first couple of models in the Khronos samples repo
Atbh I forgot you were working on this so to see it in this state feels like an early Xmas present!
OLol I barely did anything to get this working XD Just added shaders to the right paths and everything fell into place
OYeah I noticed that as well :/ I think also the way that the thumbnails are staying loaded ends up costing too many resources (on the quest at least). Haven't looked too far into that
AI found the async bits tricky but I've done very little async in C#
AGLTFast was async only - how did you work round that?
OLmao I just used your code from your first go
OTried giving it a fresh look and couldn't really think of a different enough way of doing it
Aha! glad it was useful. I expected you to rip it out and start again.
AMaybe just a button to "unload all thumbnails"?
OI started to, but ended up having to balance my dev time between trying to get this working and getting some sort of workable app using the Open Brush API for a teaching session soon
ARemind me what you're doing with the API and teaching?
A(Ah. Loading a scene with imported models fails after restarting the app. Probably because the models aren't initialized properly if the thumbs aren't loaded?)
OI'm wondering if this would be any better? IDK if y'all are already using it. If that's the case, sorry for the redundancy. https://docs.unity3d.com/ScriptReference/AssetPreview.html
Oyeah currently it looks like clicking the asset to load the thumbnail will create the object. And I think clicking the thumbnail again just duplicates it into the scene
ALoading the scene twice works. So first time is correctly initing the thumbs but not the scene models.
OHuh interesting
AProbably related to async completion.