Hey JacopoS! Im running maya 2018.5 (new update that just came out), and when I put in the Mel Command in the user doc its just crashes. I see the node popup in the inputs and then BAM hard crash.
I made sure the UVs are all in 0-1 space, Unwelded, Thin, and separate objects. Not sure what Im doing wrong.
Do you have zippers or pipings or stuff like that? If so, make sure they're turned off while exporting. Also, you wrote "separate objects" in your comment. Is that the case? If so, I would recommend "single object".
You can do a few different tests: one would be to call the command without fill: "jQuadrangulateCloth -f off". That will prevent most of the computation reducing the risk of a hard crash straight away. If that works, it means it's a matter of instability of the current version of the plugin. You can try modifying the density and switch fill back on and cross your fingers.
Another thing you could try is to test it on a super simple case and see if it behaves properly. If it does, it means there's something about the case you tested before that gets it confused...
@Dumbanana Thank you! I'm glad it passed the test! About the relaxation, I think I should be able to do that provided that your retopo mesh shares the same UV layout as the original mesh. I'll keep that in mind next time I go back working on this.
JacopoS, i tried the command "jQuadrangulateCloth -f off" in the mel line and it still crashed on me a few times but now randomly it started working LOL! Maya does what Maya wants I guess! Thanks for that! I think the -f command helps and then i can go into the node and set it to on with no issues.
@jacopoS I did some simple tests and got some crashes, not worried about it yet. When you say that it only works on MD output, what specifically is it looking for in a mesh? Just trying to get a feel for what I can get away with here for non-MD models.
@Heorogar That's strange! It should either work or chrash consistently! Oh well... I hope it's not being too frustrating.
@throttlekitty First of all, it looks for boundary vertices. So, if you are trying to feed it non MD meshes, make sure it's not a continuous solid. Then it looks at the UVs. But if there isn't exactly one UV per vertex, the current version just breaks. If all of that passes, then it looks for harsh corners in the UVs. For now, that simply means every angle greater than 30° is a corner. Those are the things that it looks for while it initialises itself. Also, it creates a little acceleration structure for reprojecting vertices on the original shape. But that's a temporary implementation and it's very rough around the edges. That's what crashes the application with UVs outside [0-1]. If you keep those things in mind, it might work with non MD meshes.
@shogunato I think you might have forgot to load the plugin from the plugin editor. Let me know it that's not the case.
tried it out without any luck in maya 2018 importet a simple md mesh "single unwelded thin" selected it, called console with "jQuadrangulateCloth" than this popup appears with text: "Fatal Error. Attempting to save in X:/Users/MyName/AppData/Local/Temp/MyName.20181204.1553.ma" and it crashes
ps: also calling "jQuadrangulateCloth -f off" did crash it
@goekbenjamin Oh that's no good. I was expecting it to at least handle simple cases no problem... Would it be ok for you to share the obj you're testing on so that I can investigate the issue?
@goekbenjamin Oh that's no good. I was expecting it to at least handle simple cases no problem... Would it be ok for you to share the obj you're testing on so that I can investigate the issue?
Ok I see the problem: the UVs are way beyound the [0-1] domain. When exporting from MD, try to switch on the option "Unified UV Coordinates". I just didn't realize that would make a big difference and forgot about specifying it in the doc. MD usually sets your UV space automatically but it's possible to specify it manually. If you want to learn more about that, take a look at this video: https://www.youtube.com/watch?v=kiS1QiiECnE
@jacopoS hey i tried it again with "unified" uvs (which does not quite work as i guess?)
MD Export settings (i just exported that highlighted one)
that is waht i get when i import it into maya, isnt that a bug of MD that the uv is not inside og 0-1 space?
i tried with uv with above position, and also inside 0-1 space, but still i got this error, i select the mesh, than type jQuadrangulateCloth into the console and hot enter:
@goekbenjamin I'm not sure it's a bug. I think you should just click the "Edit UV" button in MD before exporting. A little dotted rectangle should appear and it should surround all of your patterns. I guess the correction you've made inside of Maya would work as long as you make sure to leave at least a little margin around your UV island. If you let it touch the borders, you still run into the risk of precision errors. So I would test that again but this time scale your UV island down so that it doesn't touch the borders.
I promise I'll fix this shit one day but for now just bear with me guys.
@pasha_sevez Yea you're right! That would confuse it quite a lot! Also it wouldn't work correctly if you have UV islands on top of eachother. I think that wouldn't cause a crash but it would do the reprojection all wrong.
@jacopoS Honestly, I'm really impressed with what your plug-in can do. From my standpoint, it's a real game changer for those ones who have to deal with marvelous designer and clothes production. Neither software can offer a clean re-topo AND the vertices aligned on the seams at the same time. It's only can be achieved via tedious manual work. So I'm looking forward to see you making it a robust and stable production tool (right now it's more like walking on a minefield ^^) to let us use it at full potential.
@goekbenjamin I'm not sure it's a bug. I think you should just click the "Edit UV" button in MD before exporting. A little dotted rectangle should appear and it should surround all of your patterns. I guess the correction you've made inside of Maya would work as long as you make sure to leave at least a little margin around your UV island. If you let it touch the borders, you still run into the risk of precision errors. So I would test that again but this time scale your UV island down so that it doesn't touch the borders.
I promise I'll fix this shit one day but for now just bear with me guys.
No worries! Thanks alot i will try it with margin on the uvs! Thanks for sharing it with us!
@pasha_sevez Thank you! I really appreciate your feedback. I realize in the current state it's demanding way too much caution. But it was either that or letting you people wait much longer 'cause as I mentioned before, I won't be working on this for some time. So I figured I would just let you try it already. I'm not sure what you mean with the "double faced geometry". Can you show me that?
@goekbenjamin You're welcome. And thank you for being patient!
Hey @pasha_sevez I was investigating the case you sent me. I'm a little bit baffled: there's definitely something weird going on in your base mesh. Maybe you could double check the stitchings in the shoulder area and make sure they end up in the right point. However, that doesn't really explain why it's behaving so dumb. In this specific case, I would expect it to ignore the issue... I'll keep this obj for further testing. I think it's going to be very helpful for debugging.
@goekbenjamin Sorry it didn't work for you. If you want, you can throw the obj at me so that I can investigate the reason why it's not behaving as you expect and make sure to fix that problem in a future release.
@pasha_sevez I don't know about the first case you sent. But I can tell the second one is clearly a stitching problem. If you go back in MD, you'll realize the stitchings aren't snapped in the right point. The algorithm is working fine on that front. It's simply catching up with the fact that those pattern corners are misaligned. However, the end result is made a little worse by the fact that the current build will neves subdivide things in odd numbers. So it's basicly putting two extra subdivisions around there instead of just one.
Hi, strongly recommend trying "jQuadrangulateCloth -f off" if you face crashes, the successful rate is higher. But some of the vertices somehow move to the origin. Am I doing something wrong? I already take out the bows.
pasha_sevez and it worked the first time, and the second time, after playing around with the node values it crashed again. Restarted maya, imported the obj executed the command it crashed again. I than exported something from MD, aligned the uv to 0-1 space (i dont know why MD does not align it when exported with "Unify") and it worked again, after playing around with the node values it crashed again.
I randomly seems to crash on me.
The times it works, the retopoed mesh seems pretty damn good!
@justin1230 you're most likely not doing anything wrong. Vertices go to the origin when for any reason they end up outside the boundary of the UV island. I'd be curious to see a before and after of the affected UV islands. That might help me understand why the vertices fall outside the boundary.
@goekbenjamin I guess that's something. At least you were able to see a result. If you're trying scrubbing the density slider (like I was doing in my last gif), that would make the plugin face thousands of different cases and the chances for a chrash are much bigger. So I'd recommend avoid doing that and just input the values by typing them.
@goekbenjamin I see: some patterns have their UVs flipped. So, the program interprets those as holes instead of patterns. That's something I'm already planning on fixing along with all other UV related issues. But for the time being, this won't work properly with flipped UVs.
@jacopoS in the meantime how can i prevent this without having to change all or rebuild all that again? I did not tried it, but maybe i just delete all uvs, and re-uving it again, would that help to prevent "throwing away my mesh"? ----- after this post i actually had to try it myself! i deleted the uvs, and since it is unwelded i could: - UV -> Create -> Planar
@goekbenjamin I'm glad you got a result that works in the end! I wouldn't recommend to recreate the UVs from scratch. you could simply flip them instead. Just select the entire UV shell you want to flip and use the dedicated command in the UV toolkit. This way you don't need to redo stuff that is already there.
hey @goekbenjamin, not yet. But I've been thinking about how to fix all of the UV related problems. So, in my next update, I'm planning on doing that and I'm expecting it to actually become even faster in the process. Though, all of the random bugs that make it crash while scrabbing the attributes won't be wiped yet. Those are going to be next. I don't know yet when am I going to work on it: maybe half way through february or so. I'll let you guys know. And by the way, thanks to all of you who have been patiently testing the tool and to those who have sent "coffee". That really motivates me to support this monstruosity in the future.
hey @goekbenjamin, not yet. But I've been thinking about how to fix all of the UV related problems. So, in my next update, I'm planning on doing that and I'm expecting it to actually become even faster in the process. Though, all of the random bugs that make it crash while scrabbing the attributes won't be wiped yet. Those are going to be next. I don't know yet when am I going to work on it: maybe half way through february or so. I'll let you guys know. And by the way, thanks to all of you who have been patiently testing the tool and to those who have sent "coffee". That really motivates me to support this monstruosity in the future.
Great to hear that jacopoS! I am super excited to see where this is going!
Hey JacopoS, i experimented now some time with your great tool
Is it possible that verts wont line up because the uv have been scaled a bit?
I have two simple planes and stiched together, exported like that:
this is what it look in maya, also uvs are way ov the 01 space so i relayout the uvs via "Layout -> Layout UVs", so the size of both uv-shells will keep consistent
this is what it looks after your tool has changed it (also why is there a gap in it?)
and after i scaled the upper part a bit down i get this result
is this by design, or is this a bug?
Does the orientation also plays an important role?
How would you manage that stuff with uvs from MD? i guess you also have to realign them in maya/max?
Was the gap not there before you run the command? If the gap was there already, that would explain why the vertices are not aligned. If not, please send me the obj so that I can use it for debugging. And yes: the uv size plays a role in how the density is computed. That's by design. But if no gap was there, the tool would have to try to force the vertices to aligne, no matter the scale.
I never really have to do anything in Maya: I export my objects from MD with uvs already normalized in [0:1]. Did that tutorial that I posted not help? Anyway, that won't be an issue anymore as soon as I release the new build. That should be in a couple of weeks from now.
Replies
You're welcome!
@myclay
Sorry, the standalone version doesn't exist yet. That will have to wait a while.
I made sure the UVs are all in 0-1 space, Unwelded, Thin, and separate objects. Not sure what Im doing wrong.
Thanks man!!!
Oh crap!
Do you have zippers or pipings or stuff like that? If so, make sure they're turned off while exporting.
Also, you wrote "separate objects" in your comment. Is that the case? If so, I would recommend "single object".
You can do a few different tests:
one would be to call the command without fill: "jQuadrangulateCloth -f off". That will prevent most of the computation reducing the risk of a hard crash straight away. If that works, it means it's a matter of instability of the current version of the plugin. You can try modifying the density and switch fill back on and cross your fingers.
Another thing you could try is to test it on a super simple case and see if it behaves properly. If it does, it means there's something about the case you tested before that gets it confused...
Let me know what you find!
One thing I would love is the relaxation aspect of the script to be a standalone for use with other manual retopo meshes, if that makes sense.
Great job!
Thank you! I'm glad it passed the test!
About the relaxation, I think I should be able to do that provided that your retopo mesh shares the same UV layout as the original mesh. I'll keep that in mind next time I go back working on this.
@throttlekitty
You're welcome!
Thanks man!
That's strange! It should either work or chrash consistently! Oh well... I hope it's not being too frustrating.
@throttlekitty
First of all, it looks for boundary vertices. So, if you are trying to feed it non MD meshes, make sure it's not a continuous solid.
Then it looks at the UVs. But if there isn't exactly one UV per vertex, the current version just breaks. If all of that passes, then it looks for harsh corners in the UVs. For now, that simply means every angle greater than 30° is a corner.
Those are the things that it looks for while it initialises itself.
Also, it creates a little acceleration structure for reprojecting vertices on the original shape. But that's a temporary implementation and it's very rough around the edges. That's what crashes the application with UVs outside [0-1].
If you keep those things in mind, it might work with non MD meshes.
@shogunato
I think you might have forgot to load the plugin from the plugin editor. Let me know it that's not the case.
importet a simple md mesh "single unwelded thin"
selected it, called console with "jQuadrangulateCloth"
than this popup appears with text:
"Fatal Error. Attempting to save in X:/Users/MyName/AppData/Local/Temp/MyName.20181204.1553.ma"
and it crashes
ps: also calling "jQuadrangulateCloth -f off" did crash it
Oh that's no good. I was expecting it to at least handle simple cases no problem...
Would it be ok for you to share the obj you're testing on so that I can investigate the issue?
When exporting from MD, try to switch on the option "Unified UV Coordinates". I just didn't realize that would make a big difference and forgot about specifying it in the doc.
MD usually sets your UV space automatically but it's possible to specify it manually. If you want to learn more about that, take a look at this video:
Once you sort that out, it should work.
Thanks alot for sorting this out! I will try it as fast as possible, and give a response if it solved the problem.
Edit: i just saw it is also stated in the pdf, that non 0-1 uvs will lead to a hard crash actually, sorry for bothering you :-)
It's no problem.
Yes, the 0-1 UV limit is a pretty bad inconvenience in this build. Sorry for that everyone!
@OccultMonk
There is no 3ds Max implementation. A standalone version is planned but you'll have to wait a while for that.
MD Export settings (i just exported that highlighted one)
that is waht i get when i import it into maya,
isnt that a bug of MD that the uv is not inside og 0-1 space?
i tried with uv with above position, and also inside 0-1 space, but still i got this error,
i select the mesh, than type jQuadrangulateCloth into the console and hot enter:
You're welcome!
@goekbenjamin
I'm not sure it's a bug. I think you should just click the "Edit UV" button in MD before exporting. A little dotted rectangle should appear and it should surround all of your patterns.
I guess the correction you've made inside of Maya would work as long as you make sure to leave at least a little margin around your UV island. If you let it touch the borders, you still run into the risk of precision errors. So I would test that again but this time scale your UV island down so that it doesn't touch the borders.
I promise I'll fix this shit one day but for now just bear with me guys.
Yea you're right! That would confuse it quite a lot!
Also it wouldn't work correctly if you have UV islands on top of eachother. I think that wouldn't cause a crash but it would do the reprojection all wrong.
Honestly, I'm really impressed with what your plug-in can do. From my standpoint, it's a real game changer for those ones who have to deal with marvelous designer and clothes production. Neither software can offer a clean re-topo AND the vertices aligned on the seams at the same time. It's only can be achieved via tedious manual work. So I'm looking forward to see you making it a robust and stable production tool (right now it's more like walking on a minefield ^^) to let us use it at full potential.
Thank you! I really appreciate your feedback.
I realize in the current state it's demanding way too much caution. But it was either that or letting you people wait much longer 'cause as I mentioned before, I won't be working on this for some time. So I figured I would just let you try it already.
I'm not sure what you mean with the "double faced geometry". Can you show me that?
@goekbenjamin
You're welcome. And thank you for being patient!
now when i try it, it just loads and loads and loads and freezes maya and its gui
But I've spotted another repeated problem with mismatching vertices on the seams.
Attached a sample OBJ for your tests.
I was investigating the case you sent me. I'm a little bit baffled: there's definitely something weird going on in your base mesh. Maybe you could double check the stitchings in the shoulder area and make sure they end up in the right point.
However, that doesn't really explain why it's behaving so dumb. In this specific case, I would expect it to ignore the issue...
I'll keep this obj for further testing. I think it's going to be very helpful for debugging.
@goekbenjamin
Sorry it didn't work for you. If you want, you can throw the obj at me so that I can investigate the reason why it's not behaving as you expect and make sure to fix that problem in a future release.
Checked. Everything's fine there.
Also found one more non-critical, but persisting bug on a specific cloth - border skewing.
No problem!
@pasha_sevez
I don't know about the first case you sent. But I can tell the second one is clearly a stitching problem.
If you go back in MD, you'll realize the stitchings aren't snapped in the right point.
The algorithm is working fine on that front. It's simply catching up with the fact that those pattern corners are misaligned.
However, the end result is made a little worse by the fact that the current build will neves subdivide things in odd numbers. So it's basicly putting two extra subdivisions around there instead of just one.
But some of the vertices somehow move to the origin.
Am I doing something wrong? I already take out the bows.
pasha_sevez and it worked the first time, and the second time, after playing around with the node values it crashed again.
Restarted maya, imported the obj executed the command it crashed again.
I than exported something from MD, aligned the uv to 0-1 space (i dont know why MD does not align it when exported with "Unify") and it worked again, after playing around with the node values it crashed again.
I randomly seems to crash on me.
The times it works, the retopoed mesh seems pretty damn good!
No problem
@justin1230
you're most likely not doing anything wrong. Vertices go to the origin when for any reason they end up outside the boundary of the UV island.
I'd be curious to see a before and after of the affected UV islands. That might help me understand why the vertices fall outside the boundary.
@goekbenjamin
I guess that's something. At least you were able to see a result.
If you're trying scrubbing the density slider (like I was doing in my last gif), that would make the plugin face thousands of different cases and the chances for a chrash are much bigger. So I'd recommend avoid doing that and just input the values by typing them.
i have this jacket:
after executing your script, part of the mesh and uvs are gone:
I see: some patterns have their UVs flipped. So, the program interprets those as holes instead of patterns. That's something I'm already planning on fixing along with all other UV related issues. But for the time being, this won't work properly with flipped UVs.
I did not tried it, but maybe i just delete all uvs, and re-uving it again, would that help to prevent "throwing away my mesh"?
-----
after this post i actually had to try it myself!
i deleted the uvs, and since it is unwelded i could:
- UV -> Create -> Planar
and DAMN, the rows actually does line up!
what black magic is this?!
I'm glad you got a result that works in the end!
I wouldn't recommend to recreate the UVs from scratch. you could simply flip them instead.
Just select the entire UV shell you want to flip and use the dedicated command in the UV toolkit. This way you don't need to redo stuff that is already there.
not yet. But I've been thinking about how to fix all of the UV related problems. So, in my next update, I'm planning on doing that and I'm expecting it to actually become even faster in the process. Though, all of the random bugs that make it crash while scrabbing the attributes won't be wiped yet. Those are going to be next.
I don't know yet when am I going to work on it: maybe half way through february or so. I'll let you guys know.
And by the way, thanks to all of you who have been patiently testing the tool and to those who have sent "coffee". That really motivates me to support this monstruosity in the future.
I am super excited to see where this is going!
Is it possible that verts wont line up because the uv have been scaled a bit?
I have two simple planes and stiched together, exported like that:
this is what it look in maya, also uvs are way ov the 01 space
so i relayout the uvs via "Layout -> Layout UVs", so the size of both uv-shells will keep consistent
this is what it looks after your tool has changed it (also why is there a gap in it?)
and after i scaled the upper part a bit down i get this result
is this by design, or is this a bug?
Does the orientation also plays an important role?
How would you manage that stuff with uvs from MD? i guess you also have to realign them in maya/max?
If the gap was there already, that would explain why the vertices are not aligned. If not, please send me the obj so that I can use it for debugging.
And yes: the uv size plays a role in how the density is computed. That's by design. But if no gap was there, the tool would have to try to force the vertices to aligne, no matter the scale.
I never really have to do anything in Maya: I export my objects from MD with uvs already normalized in [0:1]. Did that tutorial that I posted not help?
Anyway, that won't be an issue anymore as soon as I release the new build. That should be in a couple of weeks from now.