I converted the my version from maxscript to python and I was insanely surprised, when I realized that the same code (or almost 99% the same) is about 4x -8x times faster under maya python then in maxscript. Then I made a simple test. Simple addition inside maya python is about 10x faster then in maxscript, which is really annoying.
I made a simple addition test as well, which was also 10x faster in python.
Maxscript is really slow when it comes to basic math, see for example the comments here, almost instant result in python, two and a half minutes in maxscript. That said, the major slowdown here (at least for me) were the poly operations on bigger meshes, finding the right values is fast (it's basically five lerps in succession). For example, creating the same 10 verts and a polygon out of them (measured after creating the test geometry), gives 0ms on 10x10 plane, ~14 ms on 100x100 plane, ~140 ms on 100x1000 plane and ~1400ms on 1000x1000 plane:
(<br> seed = 0<br> widthSegs = 10<br> lengthSegs = 10<br> count = (widthSegs + 1) * (lengthSegs + 1)<br> poly = convertToPoly (plane lengthSegs:lengthSegs widthSegs:widthSegs)<br><br> start = timestamp()<br><br> pts = for i = 1 to 10 do polyOp.createVert poly (random [0,0,0] [1,1,1])<br> polyOp.createPolygon poly (for i = count + 1 to count + 10 collect i)<br><br> format "time: %\n" (timestamp() - start)<br>)
@CrazyButcher: oh man, that's really crazy in the best way, made an edit to the original post. Looking at the page, I noticed you are using tangents to approximate the curvature instead of lerping the values:
Is that because of the support of irregular borders where triangles have to be inserted? Or maybe I misunderstood, it's just that the distance-based (weight-off) result seems to be a bit different from what I'd expect (that'd be more in line with the last image).
Thanks, with more complex shapes, taking the original "mesh flow" into account and adding some tweaking values for the developer felt necessary. Just lerping didn't work so well imo. It's not so much about non-4 corner case, but rather non perfect-grid spacing of the outlines. It doesn't show so well here on the simple shape, but if you look at the more organic painted strips that the tool was intended to fill foremost, spacing, curvatures etc. change a lot more
The first result looks sort of overcompensated, though, I'd expect something more in line with the last image from lerp. Wait a few mins, I'll try it out.
Agreed, hence the options it's not always obvious how to extrapolate, there are discontinuities in the original shape. There is room for better heuristics to "guess" which flows are more important than others. For example I should have weighted the corner angles stronger. Cause the corners already hint that the base-shape has a discontinuity along U for top & bottom edges. Preserving that discontinuity should have yielded the last solution by default.
@CrazyButcher I have used your script before and it worked very good for closing holes. unfortunately it does not work in newer versions of 3dsmax :-( Maybe share the source?
Damn, cannot test it, 2016 crashes on startup with it and and I don't have a lower version Could you be bothered to attach a mesh like that in the picture? I tried replicating it (with the sharp bends) but I'm probably still missing some details that would make the lerp method spit out something like that. Thanks in advance.
Keeping the plugin working for the quirks in the various 3dsmax version burned me over the years and given the little success the plugin had and a rather demanding fulltime job, my motivation was gone. I no longer have 3dsmax installed etc. completely turned to the dark side of coding
when i have the polyModOp in my stplugs/stdscripts folder i get an error with splines for some reason. the error occurs when i pick 'refine' in editable spline from the quad menu and i get the message 'spline editing' 'operation failed' and refine doesn't work. using 2018. when i remove polymodop_v0.2a.ms from stplugs/stdscripts the error goes away.
not sure how polyModOp could be affecting splines but it seems to be. any ideas?
I converted the my version from maxscript to python and I was insanely surprised, when I realized that the same code (or almost 99% the same) is about 4x -8x times faster under maya python then in maxscript.
Replies
Maxscript is really slow when it comes to basic math, see for example the comments here, almost instant result in python, two and a half minutes in maxscript. That said, the major slowdown here (at least for me) were the poly operations on bigger meshes, finding the right values is fast (it's basically five lerps in succession). For example, creating the same 10 verts and a polygon out of them (measured after creating the test geometry), gives 0ms on 10x10 plane, ~14 ms on 100x100 plane, ~140 ms on 100x1000 plane and ~1400ms on 1000x1000 plane:
http://polycount.com/discussion/130016/alles-im-fluss-3ds-max-modelling-plugin-released/p1
I no longer actively code on the tool, but made it available for free
http://allesimfluss.biz/
Is that because of the support of irregular borders where triangles have to be inserted? Or maybe I misunderstood, it's just that the distance-based (weight-off) result seems to be a bit different from what I'd expect (that'd be more in line with the last image).
it's not always obvious how to extrapolate, there are discontinuities in the original shape. There is room for better heuristics to "guess" which flows are more important than others. For example I should have weighted the corner angles stronger. Cause the corners already hint that the base-shape has a discontinuity along U for top & bottom edges. Preserving that discontinuity should have yielded the last solution by default.
@OccultMonk some of the source is open (GPL however) actually the "corner angle" method I just described was something I started experimenting with, just never finished judging by the #if 0 in here https://github.com/pixeljetstream/allesimfluss_maxplugin/blob/master/src/gridfill.cpp#L836 (haven't looked into that code for 6 years or so)
hopefully that makes somewhat sense, the trick is to use various "relative" spaces for the different calculations.
Inserting the triangles is rather hardcore, I used this algorithm http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8659.2009.01417.x/abstract
just googling showed there seems to be a even better version with a freely available pdf https://igl.ethz.ch/projects/sketch-retopo/robust-and-controllable-quadrangulation-techreport.pdf
not sure how polyModOp could be affecting splines but it seems to be. any ideas?