Paint strokes shifting on guides
There has been an issue with the brush strokes moving away from the guides on each brush stroke, it eventually is off the guide itself the more brush strokes you do. It’s almost as if each paint stroke on the guide becomes like a new “guide” increasing the distance of the stroke from the original one. Any way that can be tweaked a bit? It’s a noticeable bug since TB.
27 Replies
The only issue I'm aware of also affects TB itself - i.e. it's something we inherited. If you mean something that's changed since TB then I don't think I'm aware of it.
(the reason it's useful to know for sure if this issue existed in Tilt Brush, is that it makes a big difference to how we would start hunting down the cause)
Purely inherited…. 😁
Yeah. It's been discussed a few times. Here's one: https://discord.com/channels/783806589991780412/783806589991780415/963710249548779561
When we looked into it, I think we reached the conclusion that it was a necessary compromise to fix z-fighting
It's very dependent on scale, if I recall. It's not that noticeable at regular scales.
Got ya. Yeah z clipping would be an issue. Bummer.
Wonder if even dropping it a little would make it not so noticeable yet still be a stoke width above it where doesn’t intersect?
I suspect it's pretty optimized as it is. The original team was pretty thorough.
Wonder if this is something that could be addressed after the fact with a trim tool, while the guide is still active? Basically just force the strokes to resize so they fit the plane or whatever is being used as a guide?
merge vertices by distance? that would fix z fighting
I think you might be misunderstanding what causes z-fighting. You need vertices to be different to nearby ones - not the same
z-fighting is when two triangles share the same or very similar positions
The "lift" we add to strokes is intended to keep them separate as you paint on a guide. Each stroke gets slightly higher. If we didn't do this, they would all sit on the guide and you'd get lots of flicker.
The merge by distance merges the nearby vertices and deletes others that overlap. When I use it in post it reduces z fighting.
Just a thought
All strokes would have to be selected and on one layer
OK. So this is in the case where you want to remove overlapping brush strokes? I was thinking more about cases where the overlapping/layering was intentional.
It wouldn't help in some common cases like when a small triangle is inside a bigger triangle but they are co-planar.
In that situation the vertices of the larger triangle are nowhere near and wouldn't be merged.
I'd like to see a simple example of a couple of brush strokes where merging vertices does help. I wonder if that's more a case of "delete triangles entirely if they are too similar to another one with the same material" (this would only make sense for non-transparent brushes - for transparent brushes, the layering is most likely intentional)
Hard to think of a rule that would a) make a difference and b) not break things that were intentional
but some examples would help
I understand. It would help reduce vertices at the same time though as well. Just thinking out loud some solutions. I understand if it’s pretty optimized now that’s good but it is weird how it works. If the intention is to reduce z fighting maybe an option would be to have it work on the guide and overlap and merge vertices on the entire piece by brushstroke since now they are joined on export.
Still the more optimized the export the more people will use OB as a serious tool for production. I know you can always export to blender and do work there but it’s about what saves people time in the long run. That’s the tool they will use more. And we all know polys are huge out of TB/OB because of the individual paint strokes. If the joined brush strokes are one mesh that also reduces polys/vertices it would be a total game changer
Thinking this is especially true for all hulls. The mesh exported for hulls don’t have proper UV’s and always have to be remapped for any texture to bake.
Still the more optimized the export the more people will use OB as a serious tool for production.I'm not disagreeing with the value of this - I just can't quite settle on an implementation that is feasible without tons of work.
I understand
I can't grasp how the vertex merging would work in this case.
If I have some time today I’ll play around in blender and perhaps send over an example if you think that would be helpful to see what happens to the piece.
Just let me know
A really simple example might help - two or three strokes similar to something that might occur naturally when painting, that benefit from vertex merging
anything more complex and it might be too hard to unpick what's going on
Got ya
but - there's no guarantee there's a way to do this without killing performance while painting.
and if we didn't do it while painting, then it wouldn't fix z-fighting in the headset
and leaving it as an optimization on export would be hard - as at that point we've already applied "lift" to each stroke and would have to figure out where the stroke was meant to be
I understand. But the optimizing could just occur on export not while painting correct?
No. See above
That is potentially difficult as well
Got ya
It's all doable - but it gets complex and we won't know how much it pays off in real-world scenarios without doing it. So it's a gamble.
Ok
A gamble with my time and sanity 😉
I tend to favour low-hanging fruit and obvious wins.
But I know you love challenges.
no. i'm getting a bit tired of them! I like easy things now 🙂
I’ll keep this in mind 😉
So many things would be cool with OB. Tough to keep some requests simple.