I'll push out a new beta later today

just did a quick test, yes many of the animations have returned. But I see a couple so far that are broken: an_elephant.glb cc_ns_flag3.glb The cc_ns_flag3 is a big one for me, it's in use in a lot of ways for me. I'll have to test all the models to have a more comprehensive report.

Also, I don't know how to know I have the latest beta. Under Settings, the release and model number info was showing the same so I did an Uninstall / Install to be sure. But I would want to avoid all that just to make sure I'm on the latest

It should just autoupdate from the Meta Store. I've never seen it take more than 10m from when we finish publishing. Can you remember what the release numbers said?

(if you revert from beta back to normal release I think you do have to uninstall/reinstall because it sees it as an older version)

this is turning out to be tricky. i suspect it might be shader stripping in builds as it works in the editor

but without shader stripping builds are taking about 10hrs (which github cancels after 6 so i can't even use our automated builds)

I know you switched plugin but with glTFast at envoke, a cache miss would take about 3 hours but once it was cached it was about 40

yeah. i think that's what we had before i added the missing variants

(i'm not actually trying to build all variants - just the full set that ships with UnityGLTF. it's a lot bigger than the list i made myself)

I created a small "integration test" suite in Open Brush, for image and model api commands.

Here is what I have so far. I can also maintain this in github readme if you wish, where I can update it online. 1) the default brush position is now 0,0,4(?) It has been 0,10,0 for the longest time 2) model.position is not working anymore 3) does ob.image.scale scale the image to that size param provided in y? i.e. scale=1 means a brush length of 1 for y length / height of the image? this was the observed behavior. if this is how it works, this is actually desired behavior b/c I know ob will do the work of determining the correct resize to achieve ob unit length 1, in y. However, I would also really like this same behavior for ob.model, which is currently not the case. 4) the largest bug, which I brought up sometime back when the plug-in stuff was in its own branch, is that draw.path is coming up short when on the end points. The following would be a perfect square in Release. ob draw.path=[0,0,0],[0,1,0] ob draw.path=[0,1,0],[1,1,0] ob draw.path=[1,1,0],[1,0,0] ob draw.path=[1,0,0],[0,0,0] It looks like this in the Beta:

Didn't we have a conversation about the last point? If it's the issue I think it is then it varies from brush to brush. Some close perfectly and some don't. It's hard to think of a fix that wouldn't have adverse side effects

Could you just stick to brushes that do close perfectly or add some overshoot for those that don't?

This is not that same issue for me. Indeed, I became very familiar with different brushes and I remember shortlisting Icing and DiamondHull (maybe 1-2 more) as the only brushes I could rely on to draw every point. This is with Icing which I can rely on to complete this square, here it is in Release:

Basically, a lot of my drawings "broke" in Beta and it was the first thing I noticed was the dashed effect or truncated strokes from draw.path.

ah. i see.

i think i just need to implement a command to match the "resample" command in lua.

it used to apply that by default but it doesn't now.

ok. the problem is a bit tricker than i thought. If I change fix this issue then the behaviour of connected strokes becomes worse.

for example - here's a connected square: draw.path=[0,0,0],[0,1,0],[0,1,0],[1,1,0],[1,1,0],[1,0,0],[1,0,0],[0,0,0]

i wonder if i can make a special case for the start and end 🤔

ah. that fixes it.

model.position had accidentally changed to model.set.position. I've changed it back

Brush origin is 0, 13, 3 - and that doesn't seem to have changed?

can you check that last one. maybe there's a different bug causing this

I could've sworn the brush home was starting at 0,10,0 in Release. It is showing as 0,13,3 in both Release and Beta now though. I'll keep an eye on this but doesn't look like a problem now...