1.42 - Exposed the quadChamfer functions to maxscript (you need to have the quad chamfer script open, be in the modify panal, be in editable poly, edge subobject selection, one or more edges selected)
how do i have a icon on my tooll bar for the script so i dont have to have to close it every time i restart max, or when i close it i have to run scipt from the MAXScript menu. i can not seam to find it in the Customize user interface.
how do you this script to my tool bar i have to keep running script every time i close it , should i be able to add the icon to tool bar to open script. if so how
I can't anwser that question but I don't see the benefit in turning it into a modifer, can someone explain ?
if you want to use a mesh for high and low it would be good to have it as a modifier because you can easily turn it off.
Chamfer edges to get your high, now when I'm done and want to use the base as my low I can just turn off the modifier.
OR
Which makes more sense (and what most people do) is to create an edit poly mod and make your edits, then turn off whenever. It should work just the same. I don't see why it wouldn't
Ok. Thanks, it looks like an awful thing when you've customized max behaviour down to modifier stack. If you do a modifier version obliviboy, can I ask a simple script alternative ?
Would a modifier be that usefull? most modelling tools dont work that well as a modifier. personally 99% of my modeling is done on the base object using the stack for deformers.
A modifier will be awesome. The question is not wich is better script or modifier. They are complementary. EdgeChEx is a modifer and it's really powerfull. Modifiers is a strong part of max using them allow users better workflows.
Yea I'm not so sure about a modifier version, I probably wouldn't use it unless there some pretty handy workflow I don't know about? Can someone point out how it would be used?
Also most of the time I model in edit poly (not editable poly) because I've customized edit poly the modifier (shortcuts and quad menu) and its too much of a pain to sync up editable poly, the object. Does the script work in edit poly?
I can understand that some users will not be using it. But i'm asking for it because it will be usefull for us. But maybe not for everybody. There's so many workflow.
I cannot show an exemple actually because we're hard working. But modifiers have the power to be additive and can be deactivated on the fly it's like a ctrl+z more powerfull.
That's all i can say. It's really usefull here for trying things quickly.
I'm always leery when people use the words like "powerful" "fully featured" "flexible" "fast" instead of giving examples. That's copy writer fluff that no one care about.
Typically that means "narrow in scope" "not easily adaptable to new ideas" and "not going to do what you imagine".
If the script worked with Edit Poly couldn't you just apply another edit poly modifer and do your chamfers there? Won't that give you the same functionality without having to force him to write something new?
To me it seems like you really don't have a need for it? But are hoping he'll put his time into it and you'll figure out a use for it later? I would rather have people spend their time on things people need rather than create things that sound useful but in practicality aren't. But it's his free time if he thinks its worth it or if it isn't that much effort, might as well go for it.
I think unless someone can come up with a truly inspirational example that proves it would save time, his time is probably better spent on something else but that's just me.
Getting the chamfer as a modifier for me is better because it allow us to change the size of the chamfer even after all chamfer were done. Juste getting back to the modifier into the stack and change the width. Wich is not possible with the actuall script because if it's applied ... it's written in the rock !
Getting the "modifier version" or the "editpoly compatibility" is quiete the same because as you explained we can add an edit poly into the stack and after make the chamfer. Wich thing will keep more time to develop ? Edit poly compatibility or the modifier version ?
My preference go to the modifier for what i explained inside the first paragraph it's smoother and allow to change things later or also deactivate the chamfers.
While
Edit poly compatibility will just allow to activate/deactivate the chamfers without possibility to change things dynamically.
I'm always leery when people use the words like "powerful" "fully featured" "flexible" "fast" instead of giving examples. That's copy writer fluff that no one care about.
Typically that means "narrow in scope" "not easily adaptable to new ideas" and "not going to do what you imagine".
If the script worked with Edit Poly couldn't you just apply another edit poly modifer and do your chamfers there? Won't that give you the same functionality without having to force him to write something new?
To me it seems like you really don't have a need for it? But are hoping he'll put his time into it and you'll figure out a use for it later? I would rather have people spend their time on things people need rather than create things that sound useful but in practicality aren't. But it's his free time if he thinks its worth it or if it isn't that much effort, might as well go for it.
I think unless someone can come up with a truly inspirational example that proves it would save time, his time is probably better spent on something else but that's just me.
I completely agree and making it work with edit poly would be simple enough imho (even though I don't use that modifier, I understand why people would see it as a necessary point)
. Wich thing will keep more time to develop ? Edit poly compatibility or the modifier version ?
Actually I think it's a modifier version and by far, adding edit poly support to a script may take a bit of time but it's very easy.
Still I can be wrong, maxscripting is a new experience to me
I completely agree and making it work with edit poly would be simple enough imho (even though I don't use that modifier, I understand why people would see it as a necessary point)
Even if I'm operating on the base object I never use editable poly, I always apply edit poly. I do this because its easier to customize edit poly and there are times when I need to use the tools in edit poly but I can't collapse the stack. If I optimize the tools in editable poly then I'm cut off from them when I have to use the modifier, so I always use edit poly. Personally I would like to see them do away with Editable poly the object, and instead replace it with "poly object" which has no tools or features. If you wanted to edit, you would apply a modifier.
It would eliminate the double code base and the headache of having to create an elaborate set of checks just to figure out which modifier is active and what command to run.
The things you have to check for are crazy...
Editable poly (the object)
Edit poly (the modifier)
Editable mesh (the object)
Edit mesh (the modifier)
Poly object (the object)
Primitive shape (the object)
Shape (the object)
If anything needs a weed whacker taken to it, its the crazy bloated rats nest of commands they have for editing meshes. Especially when they all do roughly the same things. At the very least I would love for them to eliminate half of the problem by tossing out Editable Mesh and Edit Mesh.
Instead you would have:
Poly object (the object)
Edit Poly (the modifier)
But it would break a lot of scripts, no more than all the scripts and plug-ins they break when they force a recompile (aka 2012). They already break forwards compatibility and disappoint their customer base, they might as well take advantage of it...
The big problem with running maxscript on modifiers is dealing with what else is in the stack. For example if someone creates a box applies edit poly and hasn't collapsed it yet its base object is still a box not a editable poly object. So for a lot of scripts you have to collapse the stack, (which often coverts it to editable mesh instead of poly) and make sure its converted to a editable poly object.
Not a rant, valid points (if I don't use edit poly it's because it's a second set of commands and I'm too lazy to go in customise all my scripts again, but it's a nifty modifier if you want a fail safe modeling but since I've been used to stack-less software I don't mind working on base editable poly).
Editable mesh/edit mesh is so 90's, I'm sure some people still use them for whatever reason but I'm all for going forward even at the cost of some backward compatibility, max needs that badly imho.
As far as i know edit mesh is not supported anymore by Autodesk. Autodesk is really doing a good job actually for max they're on the good path. But cleaning a such soft used by tons of differents user is not a piece of cake.
Cathodeus, there are a lot of modifiers that where built on editable mesh, when collapsed they default to that mesh type. Its a pain for script writers and its a pain for users.
There is a difference between properly removing redundant functionality and choosing to ignore it and not do anything about it.
I'm not sure I buy the excuse that its because some users are stuck in 1992 and can't wrap his head around editing polys instead of triangles. There are plenty of things they have chosen to force on users, (caddies and ribbons being some of them) and they have a "tough sh!t" attitude.
In modifier form you can change the chamfer amount at any time, and you can always make changes easily on the base level, which will be updated automatically.
It's non destructive unlike a script, where you have to decide that the model is done, then chamfer it, then if you need to make changes, you have to revert the chamfer somehow, and re-do it.
Adding an edit poly on top of the stack and run the script on that will not help for this kind of workflow, since if you make any changes at base level, your selection in the edit poly modifier will change.
Note that this sort of workflow go hand in hand with a 'hard edge' (edges in between different smoothing groups) workflow. I set the smoothing groups right at the base level and i never have to hand pick edges to chamfer. It works most of the time, unless you need a different chamfer amount on some areas on the mesh.
It works most of the time, unless you need a different chamfer amount on some areas on the mesh.
THat's what I was wondering, I never see good models with even chamfers on polycount, there's always a part of balance in the modeling and that needs to be the modelers choice imho. So I'm honestly asking: How many people in game art (cause that the purpose of these boards I think, even though everyone's welcome) use the same chamfer settings on their whole mesh ? With that in mind: how useful a modifier that allow changing the whole chamfer settings will be ?
It's not because you're not using it that it's not usefull .... I don't understand at all why do you want to ear that it's not usefull ... Normal maps exist as well as baking ! When you creat assets like gun it's usefull, when you creat mechanical stuff it's usefull, and so on ...
Some time we see inside the engine that baked chamfers are too smalls so having it as a modifer is definitively usefull !!!
But if you want somebody to say that it's not usefull just to make you happy i can do that :-)
It's not because you're not using it that it's not usefull .... I don't understand at all why do you want to ear that it's not usefull ... Normal maps exist as well as baking ! When you creat assets like gun it's usefull, when you creat mechanical stuff it's usefull, and so on ...
Some time we see inside the engine that baked chamfers are too smalls so having it as a modifer is definitively usefull !!!
But if you want somebody to say that it's not usefull just to make you happy i can do that :-)
It's not usefull !
To quote Mark Dygert
To me it seems like you really don't have a need for it? But are hoping he'll put his time into it and you'll figure out a use for it later?
I'm not asking because I want to hear anything, I said I don't care if there's a modifier version, I won't use it.
But I do want to hear what's the real case use on that one. Cause I can't think of one and I'm a curious man.
I finally got this purchased and installed. Oh. Wow.
The ease of using it blows me away and best of all... it has the EXACT method I was looking for for hard surface modeling! By using an Amount of 1.0, Iterations of 1, Parallel Chamfer Type, and Smooth Chamfer Smoothing, I can speed up my workflow significantly!
Just the Parallel Chamfer Type alone is worth the cost of this script. But that you include the other chamfer types amd settings, is just phenomenal! Thank you so much for your amazing work!
For a few models a while back, I did all of my supporting geometry at the end with a separate modifier. I floated the idea around to a few people and was met with the same skepticism. A model and a half later I stopped doing it because it was slowing me down. It left too much up to chance and wasn't flexible at all. It was a pain trying to figure out supporting geometry flow after the fact.
For me its easier to reenforce as I go.
As restrictive and backwards as it was doing the supporting loops in another modifier, I think trying to use this as a modifier would be even more restrictive because you would need different modifiers for different styles and tightnes'es.
Thats a bummer about no edit poly support... I won't be picking it up, but I really like what you did and I'll recommend it to anyone who likes to work only in editable poly!
Sorry for the bump, but since EdgeChEx has been mentioned as a modifier alternative to this script i thought it would be good to add that it has been updated with a new quad chamfer option, similar to this one.
It's not a big loss if he can't do it in Edit Poly, all you need to do it clone the model, collapse all the fancy mods you might not need and start the script on the base Editable Poly. I mean honestly, sometimes you NEED to work around the limitations of a program you know.
@Mark: What do you mean no one liked the idea of a separate modifier? Are you refering to using an Edit poly at the end of my stack to create a support loop layer before applying a TurboSmooth, or are you talking about a specific Modifier?
@Octo: I just popped in a few minutes ago and still no update, it still says 5.0.1, am I missing something?
Now that the realtime mode is usable, it would be great if edge selection change would update the script. Now I have to cancel the script and make it run again manually. Should be easy enough to detect a selection change and making it rerun with previously set setting right?
Sorry this is a bit off subject, but what is the point to sell the entire pack the same price as all script bought one by one ? Don't you think the pack would have more success it was sold with a 20% discount or something ? Also, I know implementing a limited version (in time or on a number of max launches) requires a bit of dev and other pains but the impossibility to test is a bit rebuffing.
Replies
You could define a structure containing your functions and declare it in the global scope. That should work, and it'll be neat.
I dont know how encryption affects this, I doubt it will be a problem though.
1.42 - Exposed the quadChamfer functions to maxscript (you need to have the quad chamfer script open, be in the modify panal, be in editable poly, edge subobject selection, one or more edges selected)
quadChamfer.interactiveQuadChamfer (float amount) (int iterations) (optional)(bool silent:false) -- for round chamfer
quadChamfer.interactivePQuadChamfer (float amount) (int iterations) (optional)(bool silent:false) -- for parallel chamfer
quadChamfer.interactiveFQuadChamfer (float amount) (int iterations) (optional)(bool silent:false) -- for flat chamfer
returns ok on succes and undefined on failure
use the optinal silent variable to turn off the error messages
Love the script works so well.
Chamfer edges to get your high, now when I'm done and want to use the base as my low I can just turn off the modifier.
OR
Which makes more sense (and what most people do) is to create an edit poly mod and make your edits, then turn off whenever. It should work just the same. I don't see why it wouldn't
Also most of the time I model in edit poly (not editable poly) because I've customized edit poly the modifier (shortcuts and quad menu) and its too much of a pain to sync up editable poly, the object. Does the script work in edit poly?
That's all i can say. It's really usefull here for trying things quickly.
Typically that means "narrow in scope" "not easily adaptable to new ideas" and "not going to do what you imagine".
If the script worked with Edit Poly couldn't you just apply another edit poly modifer and do your chamfers there? Won't that give you the same functionality without having to force him to write something new?
To me it seems like you really don't have a need for it? But are hoping he'll put his time into it and you'll figure out a use for it later? I would rather have people spend their time on things people need rather than create things that sound useful but in practicality aren't. But it's his free time if he thinks its worth it or if it isn't that much effort, might as well go for it.
I think unless someone can come up with a truly inspirational example that proves it would save time, his time is probably better spent on something else but that's just me.
Getting the "modifier version" or the "editpoly compatibility" is quiete the same because as you explained we can add an edit poly into the stack and after make the chamfer. Wich thing will keep more time to develop ? Edit poly compatibility or the modifier version ?
My preference go to the modifier for what i explained inside the first paragraph it's smoother and allow to change things later or also deactivate the chamfers.
While
Edit poly compatibility will just allow to activate/deactivate the chamfers without possibility to change things dynamically.
I completely agree and making it work with edit poly would be simple enough imho (even though I don't use that modifier, I understand why people would see it as a necessary point)
Actually I think it's a modifier version and by far, adding edit poly support to a script may take a bit of time but it's very easy.
Still I can be wrong, maxscripting is a new experience to me
It would eliminate the double code base and the headache of having to create an elaborate set of checks just to figure out which modifier is active and what command to run.
The things you have to check for are crazy...
Editable poly (the object)
Edit poly (the modifier)
Editable mesh (the object)
Edit mesh (the modifier)
Poly object (the object)
Primitive shape (the object)
Shape (the object)
If anything needs a weed whacker taken to it, its the crazy bloated rats nest of commands they have for editing meshes. Especially when they all do roughly the same things. At the very least I would love for them to eliminate half of the problem by tossing out Editable Mesh and Edit Mesh.
Instead you would have:
Poly object (the object)
Edit Poly (the modifier)
But it would break a lot of scripts, no more than all the scripts and plug-ins they break when they force a recompile (aka 2012). They already break forwards compatibility and disappoint their customer base, they might as well take advantage of it...
The big problem with running maxscript on modifiers is dealing with what else is in the stack. For example if someone creates a box applies edit poly and hasn't collapsed it yet its base object is still a box not a editable poly object. So for a lot of scripts you have to collapse the stack, (which often coverts it to editable mesh instead of poly) and make sure its converted to a editable poly object.
/rant =P
Editable mesh/edit mesh is so 90's, I'm sure some people still use them for whatever reason but I'm all for going forward even at the cost of some backward compatibility, max needs that badly imho.
There is a difference between properly removing redundant functionality and choosing to ignore it and not do anything about it.
I'm not sure I buy the excuse that its because some users are stuck in 1992 and can't wrap his head around editing polys instead of triangles. There are plenty of things they have chosen to force on users, (caddies and ribbons being some of them) and they have a "tough sh!t" attitude.
The minute this has 2009 support = instant purchase by me
I noticed a lot of people including myself:) would like it.
My studio uses 2009 and I'd love to have it for work.
Looks great! I also downloaded your Quad-Connect.
Thanks again!
B
http://mariussilaghi.com/qchamfer.htm
Thanks again!
B
Do you offer any alternative payment methods other than PayPal? I'm having a heck of a time trying to get PayPal to work for me.
It's non destructive unlike a script, where you have to decide that the model is done, then chamfer it, then if you need to make changes, you have to revert the chamfer somehow, and re-do it.
Adding an edit poly on top of the stack and run the script on that will not help for this kind of workflow, since if you make any changes at base level, your selection in the edit poly modifier will change.
Note that this sort of workflow go hand in hand with a 'hard edge' (edges in between different smoothing groups) workflow. I set the smoothing groups right at the base level and i never have to hand pick edges to chamfer. It works most of the time, unless you need a different chamfer amount on some areas on the mesh.
THat's what I was wondering, I never see good models with even chamfers on polycount, there's always a part of balance in the modeling and that needs to be the modelers choice imho. So I'm honestly asking: How many people in game art (cause that the purpose of these boards I think, even though everyone's welcome) use the same chamfer settings on their whole mesh ? With that in mind: how useful a modifier that allow changing the whole chamfer settings will be ?
Some time we see inside the engine that baked chamfers are too smalls so having it as a modifer is definitively usefull !!!
But if you want somebody to say that it's not usefull just to make you happy i can do that :-)
It's not usefull !
I also will not add edit poly support.
At least for now.
To quote Mark Dygert
I'm not asking because I want to hear anything, I said I don't care if there's a modifier version, I won't use it.
But I do want to hear what's the real case use on that one. Cause I can't think of one and I'm a curious man.
The ease of using it blows me away and best of all... it has the EXACT method I was looking for for hard surface modeling! By using an Amount of 1.0, Iterations of 1, Parallel Chamfer Type, and Smooth Chamfer Smoothing, I can speed up my workflow significantly!
Just the Parallel Chamfer Type alone is worth the cost of this script. But that you include the other chamfer types amd settings, is just phenomenal! Thank you so much for your amazing work!
For me its easier to reenforce as I go.
As restrictive and backwards as it was doing the supporting loops in another modifier, I think trying to use this as a modifier would be even more restrictive because you would need different modifiers for different styles and tightnes'es.
Thats a bummer about no edit poly support... I won't be picking it up, but I really like what you did and I'll recommend it to anyone who likes to work only in editable poly!
@Mark: What do you mean no one liked the idea of a separate modifier? Are you refering to using an Edit poly at the end of my stack to create a support loop layer before applying a TurboSmooth, or are you talking about a specific Modifier?
@Octo: I just popped in a few minutes ago and still no update, it still says 5.0.1, am I missing something?
Current version 6.0.0
Gah, we should really stop derailing Oblivioboys threads, sorry mate :poly122:
Made it A Lot Faster!!!
Now that the realtime mode is usable, it would be great if edge selection change would update the script. Now I have to cancel the script and make it run again manually. Should be easy enough to detect a selection change and making it rerun with previously set setting right?