- User Since
- Mar 9 2013, 6:17 PM (344 w, 1 d)
Fri, Oct 11
@Dalai Felinto (dfelinto) how thorough do you want this testing to be? Just a simple subjective test or what?
I looked into the quadriflow code, but I didn't see any quick and easy fix sadly :/
Tue, Oct 8
Yes absolutely! We'll keep this open until you have done some more testing.
I'll but this on "waiting for dev..." as I don't think this needs to be triaged further. Only discussion is we are going to change this again or not.
This is an intended change https://developer.blender.org/D5931
We talked a bit about this outside of the tracker and this seems just to be a result of too high SSS values.
Let me know if you manage to figure out what is causing this as it seems like it must be a scene setting or something. I'm just as confused as you.
The plan for 2.82 is to rip out the entire particle system and replace it with a new one. So issues like this will probably not be worked on until the new system is in place.
For this case instead of using quadriflow, I would merge by distance and then use the tris to quads operator.
Then use the decimate modifier (with the un-subdivide option) to get the polygon count down.
The issue with this file is that none of the triangles in the mesh is connected to each other. So it does not form a continuous surface and thus quadriflow can't create a mesh for it.
Mon, Oct 7
You could just be able to load factory default under File -> Defaults -> Load Factory Settings and it should overwrite anything unless you explicitly save your settings after resetting.
I can reproduce with that .blend file but not the default scene.
Sure, that is fine by me as both of these are quite small patches.
LGTM. But I haven't really tested this excessively, only with a few simple objects.
So the current shrink wrap code fails in some cases currently? Or is it simply that is produces undesirable results?
Can't reproduce this.
Fri, Oct 4
I can try to look into this again on the quadriflow side if you guys want. I might be able to solve that the verts are sometimes moving off the border edges, but I can't promise anything.
This is because the mesh you are trying to remesh is non manifold.
Updated with the latest feedback
Thu, Oct 3
Sorry for the long delay. I waited to make any changes in case we decided to make bigger changes first.
Wed, Sep 25
We talked a bit about this and came to the conclusion that we will not support this use case (adjusting drivers in edit mode).
Updated the patch based on given feedback
Tue, Sep 24
I can reproduce this issue with the standalone QuadriFlow program, so this is not a bug with the blender code.
I've filed a bug report for QuadriFlow here: https://github.com/hjwdzh/QuadriFlow/issues/43
I've updated the patch to adress the feedback given.
Those non manifold edges does not help with the remeshing and is undefined behavior that might crash quadriflow. I'm not really sure what you are trying to argue here.
Quadriflow specifically states that it only works on manifold meshes (except that border edges are somewhat supported).
Not really, it still supports borders. So I'm unsure which other cases you are talking about.
Mon, Sep 23
Aha, I see what is happening now. It is just crashing after quadriflow made a mess as it can't handle the non manifold data.
I've posted a fix here: https://developer.blender.org/D5877
And it crashes still if you use Null or SDL?
Actually, could you see if you still get crashes if you change sound system backend to "Null" in the preferences? It seems like some people get sound crashes when running the operator for some reason.
Yes, I suspect that the error you get is an issue with the background job system I'm using for quadriflow.
I can't reproduce this issue on my test meshes. So unless you actually provide an example file there is nothing I can do.
@Martin Capitanio (capnm) it does work with boundaries of course (otherwise the "preserve boundary" option would not be there).
The issue here is that the mesh is non manifold. Even the voxel remesher has issues with the mesh provided.
Thu, Sep 19
Wed, Sep 18
Mon, Sep 16
Sun, Sep 15
Sat, Sep 14
Need steps to reproduce this. Just stating that it is a problem with no reproduction steps is not helpful.
Sep 14 2019
Sep 13 2019
Sep 12 2019
Sep 11 2019
Hopefully everything is fixed now. *fingers crossed*