@jhn
i am really interested in your attempt to write a scripted mod. post here as soon as you make any progress.
@lfshade
thanks for tuning in. i hope you will find some time and have a look at it.
@ googlo
cool
this is really a good solution. if you agree, i will include this into my script later.
unfortunately i don`t have the time to work on the script at the moment. i am working on my diploma and i have only one month left. as soon as i am finished with this i will continue scripting.
but i hope that the development of the script will go on, without me.
thank you all for sharing your ideas and time.
I’m going to try and spend a few minutes looking into this tonight or tomorrow. I have some ideas I’d like to bounce off Max; I might have a way to get the automatic update working without too much lag (very iffy right now since I can’t do any testing yet). I’ll post the results as soon as I prove myself either right or wrong:)
proteus2002: You’re not the only one working on a diploma… I have 2 months left, and the deadline is closing fast, so don’t expect an daily updates… :annoyed:
But this will work eventually, I’ll post a wip as soon as it’s working more proper…
everybody keep posting!
jhn
no need to hurry.
i have made the experience that scripting is a lot of fun, but a timekiller. so don´t spend to much time on it right now. i have made the same “mistake”. your diploma should be prior.
Interssant! ich schaus mir mal an sobald ich dazu komme
what about the performance when using this script?
the performance on mid and hires models with iterations set to more than 1 is rather slow (also depends on the hardware you are using).
i recommend setting the iterations to 1, to get an impression of the edgeflow and keep working fluently.
if you mainly work on the basemesh and use the script only for checking the smoothlines or visualisation you can set the iterations higher.
make sure you also check the script googlo posted here. it is slightly faster, because it doesn´t need the “convert_to_poly”-modifier.
also keep in mind what tamas varga posted in the “theoretical sub-d” thread. he had a legitim issue with working like this:
“Regarding Lightwave’s subpatch preview, I generally don’t like it. It encourages the bad habit of trying to work with too few polygons, and also what’s called ‘crossover’. …, where polygons are overlapping each other so that the smoothed mesh will get the desired curvature… It’ll bite you when you try to animate or texture your model. “
but nevertheless try it
proteus2002
Hey,
Here’s the fixed version from the earlier post. I was playing around with the original version and realized that Max would crash when one tried to undo things. This version also doesn’t interfere with sub-object selections at the base level of the object like the other one did (it would erase them), now it doesn’t.
Also it has an update button now. Update is for changes to the mesh while the utility is active. You can still double click on teh activate button (off then on essentially), but that takes two clicks everytime, as opposed to just one click for the update button after it's been activated.
I also modified how it was done internally, I think it's faster and more efficient with less reopening of mod panal/sub selections.
Just copy it like before into a new maxscript editor window and ctrl-e to run it or highlight it all and drag it over to a blank spot on a tool bar to make it into a macroscript (push button to activate).
rollout quickOutliner “Show Polylines”
(local originalss checkbutton dotracker "Activate Polylines" button updater "Update Polylines" enabled:false checkBox cageshow "Show Poly Cage" enabled:false on cageshow changed arg1 do ( if arg1 \ then ($.showcage=true) else ($.showcage=false) ) on dotracker changed arg1 do ( undo off ( -- prevents enclosed code from crashing max -- when trying to undy history to the object -- but doesn't actually affect undo history -- of anything else outside of the paranthesis -- i.e. actual editing history of the -- editable poly is safe :) originalss=subObjectLevel --*used so the utility can -- can keep track of user -- subselections try ( if arg1 then ( dotracker.caption="Deactivate Polylines" cageshow.enabled=true updater.enabled=true modPanel.addModToSelection (Edit_Mesh name:"Polylines") ui:on --*applies editMesh modifier to polyobject z=copy $.baseObject --*Stores poly info in variable polyOp.setEdgeSelection z #All --*sets poly edges internally z.surfsubdivide=$.baseObject.surfSubDivide; --*performs what has happend z.iterations=$.baseObject.iterations --to the poly object in Max --to the poly object in the --variable y=z.mesh; --*Convert and store the poly object into y -- NURMS Results 'baked' into mesh object and as a result -- poly subobject selections are carried over -- as well :) yes=getEdgeSelection y -- get the mesh edges that are selected setEdgeSelection $ $.modifiers["Polylines"] -yes --*Invert selection and apply to -- them to the editMesh modifier modPanel.setCurrentObject $.modifiers["Polylines"] --*Make all selected edges in subobjectLevel = 2 --mesh modifier invisible meshOps.invisibleEdge $.modifiers["Polylines"] subObjectLevel = 0 modPanel.setCurrentObject $.baseObject --*resets the modify panel back to the subObjectLevel=originalss -- the poly object level and user -- subobject selection showendresult=true --*Places focus at top of the modifier stack so smooth -- polylines will be seen while still at editable poly -- level ) else( try( --*this causes the utility to not explode if there isn't deleteModifier $ $.modifiers["Polylines"] -- a modifer to delete (editMesh) updater.enabled=false cageshow.enabled=true dotracker.caption="Activate Polylines" showendresult=true subObjectLevel=originalss )catch( ) ) ) catch( messageBox "Select an object that is at it'sbase level an Editable Poly”
doTracker.state=false
)) -- undo context end )-- dotracker button end on updater pressed do ( undo off ( originalss=subObjectLevel deleteModifier $ $.modifiers["Polylines"] modPanel.addModToSelection (Edit_Mesh name:"Polylines") ui:on z=copy $.baseObject polyOp.setEdgeSelection z #All z.surfsubdivide=$.baseObject.surfSubDivide; z.iterations=$.baseObject.iterations y=z.mesh yes=getEdgeSelection y setEdgeSelection $ $.modifiers["Polylines"] -yes modPanel.setCurrentObject $.modifiers["Polylines"] subobjectLevel = 2 meshOps.invisibleEdge $.modifiers["Polylines"] subObjectLevel = 0 modPanel.setCurrentObject $.baseObject subObjectLevel=originalss showendresult=true ) ) -- end updater button)
pDialogue=newRolloutFloater “Smooth Polylines Thing” 150 120
addRollout quickOutliner pDialogue
If there was a way that edges could be hidden in the EditMesh modifier without having to directly go up to it in the mod panel, then open it’s edge subobject level to use the meshOp edge hiding stuff, I think it would be pretty easy to get it to update automatically.
I thought about setting up a change handler to monitor the poly's topology, and then just run this script when the topology changes, but one of the problems is that it crashes every time because while one is extruding, etc, the topology is changing constantly and so Max is trying to move to the right place in the modifier stack, open panels, select subobject levels, etc.. All of which is way to slow to keep up with the practically instantaneous calls to do all of that over and over again as the topoplogy is repeatedly registering as changed.
At least I think that’s why Max is crashing.
Then I thought that maybe there could be a way to extend the Mesh modifier as scripted plugin and make it's ui invisible, so that all the commands could be used, but without all of the active ui visually changing. I don't have that much experience (ok none) with writing scripted extended plugins.
I tried it, but Max would crash then too, I think because when I told the scripted modifier to go to the ui that was hidden, it didn't really have a ui to go to and so it would get 'confused' and crash.
So then I tried a normal utility floater type of script that would just use a change handler that could somehow selectively tell when the topology changed at the right time to activat the internal edge hiding part of the script.
I've gotten it to work with one click-then-drag editing (live update works :) ) like when extruding a poly, but when it comes to click-drag-drag like bevelling a poly, it crashes because I haven't figured out a way yet to tell the difference between when someone is click-drag-drag'ing for something like bevelling as opposed to click-drag-drag'ing because they finished and are just moving the mouse, like after extruding.
Really, I think the block to getting this whole thing to update automatically is that regardless if how it's down, we still have to go to the editMesh level of the stack with the mod panel open and be at the edge Sub Object level to use the meshOp command for invisiblizing specific edges.
I think if we didn't have to do that, we could use a change handler watching the objects topology without it having any crash problems.
I gave up on trying to just hide edges on the base poly while it’s in NURMS subdivision mode. I don’t think there is any maxscript access granted for that.
Anyone know if there is?
like if you look at it while it's like at some Nurm's iteration (and prior to that some edges were already hidden) you can see how the topology has changed via the highlighed edges, but the only acces we have at that level with maxscript is BEFORE the NURMS algorithm as been applied, not after, unless we add an editMesh modifier or something similar on top of it to capture the change.
But all of the topology dependent modifiers like EditMesh don't have any options for procedurally updating themselves if the underlying topology changes. It's like they just capture what has happend below them the moment they are applied and that's it, once it's done, it's done! And I don't think there is a way in Maxscript to tell a modifier like that to update or 'look' again at what has happend below and reacquire the changes automatically.
Example:
Make box with only 6 polys/faces ie. with only 1 segments for it’s legnth,width, and hieght.
Convert it to an editable poly.
Then apply a level 3 NURM’ing :).
If you apply say level 3 iterations in the NURMS subd part of the editable poly and then type this into the listener window and hit enter;
polyOp.setEdgeSelection $ #All;polyOp.getEdgeSelection $
You should get;
OK
#{1…12}
Which is how many there should be for a 6 sided cube, but obviously the NURMS preview shows that the result is many more than that.
I wonder if there is a way to tell the preview edges to remain invisible without having to ‘bake’ the results higher up the stack above the base poly object, finagle this and that, etc, to get rid of them?
ok i’ll test it out asap… and i’m always modelling with just one iterations, because working on complex meshes with 2 Iterations is just a pain
I tried a couple of ideas out last night. The first was actually similar to googlo’s version, trying as much as possible to optimize the process. While faster than the original version, it unfortunately still suffers crippling problems when you try to make it update automatically. My second experiment called on an idea I had used in my CleanCut and DeselectLoop scripts: drawing the edges in with calls to gw. This offered the advantage of a much faster update (no modifiers required) and supported auto-updates without crashing, but was still way too slow working with a reasonable poly count. It also introduced some distracting visual artifacts such as flickering and “x-ray-ing” through the object. In other words, it’s back-end worked better than the invisibleEdges method, but the visuals suffered beyond useability IMO.
I’ve pretty much come to the conclusion that this probably isn’t viable through scripting. The speed and interactivity that is required on anything more than a small number of polygons really seems more in the domain of highly optimized drawing code, written into a plugin dll. Ideally, this would be incorporated directly into the Editable Poly object itself. I am not a C++ programmer, so I won’t volunteer for that project;)
-RH
@googlo
that is cool.
my original script has many unnecessary stuff in it. your version is reduced to the important thing.
I gave up on trying to just hide edges on the base poly while it’s in NURMS subdivision mode. I don’t think there is any maxscript access granted for that.
i tried the same, but failed too.
I wonder if there is a way to tell the preview edges to remain invisible without having to ‘bake’ the results higher up the stack above the base poly object, finagle this and that, etc, to get rid of them?
i had the idea with setting edgeflags. but i found no way to get or set the edgeflags in the e-mesh modifier.
@lfshade
i think you are right. the best way is to write a c++ plugin for that purpose. thank you anyway, for having a look.
@neox
hau rein. i hoffe wir lernen uns mal kennen auf dem nächsten ttt.