OK thankyou , so basically I better leave ngons for when I will feel more comphortable and strong with subdmodeling ...
Definitely recommend experimenting so you learn what the limitations of them are and exactly what about them can be problematic. There are no absolutes in 3d art so understanding why things happen allow you to work as fast as possible without worrying about "rules"
"@PolyHertz , I think it would be well worth your while polishing this, adding a few features(inset preview top of the list) and flogging it on Gumroad. I'm sure it would be a huge success. "
I would gladly pay for this right now, I went to a recent max user group meeting where 2017 was demoe'd and actually asked why we dont have this exact feature.
What's the "functionality" you're referring to,out of curiosity ? If i'm working on my personal sci fi scene and have the ability to pull multiples props with this technique,why would i care about the functionality as long as i know what i'm doing and pumping the expected result ?
The functionality would be, having a very light weight basemesh to manipulate with a nice and smooth high density mesh as output. As you said, its highpoly the polycount of the highpoly doesnt matter. But what matters is a simple and leightweight mesh you can edit quickly. Most of the examples here might be detailled but still are pretty simple, as they are flat surfaces with booled on or in details, which are easy to edit anyways. this methos will super easily fail on anything that is more complex organic hard surfaces with curvature on more than one axis. Not being able to turbosmooth it for higher res versions is kinda counterintuitive. But yeah in certain cases it will work just fine.
Also, @perna , here's an example from the Proboolean thread done by @kanga A sub-D modelers dream...realised in booleans.... ... Even the 'The Division' weapons team said back in 2014 that adopting the boolean approach over trad sub-d completely changed their asset turnaround time.
Er, quads in the base mesh were a coincidence. musashidan is 100% correct when he said 'A sub-D modeler's dream realised in booleans'. The rifle was a test I would never have attempted with traditional means. The improvement in Booleans and the ability to reduce a mesh in ZB to a kind of quad rasta plus being able to polish that rasta by poly groups left me with a modelling process where I could put curved or complex cuts into curved forms and then even punch holes in those forms wherever I wanted. Dynamesh master by polygroups allowed me to blend and fillet forms easily and they look professional in quality. Something my life is way too short for to master in pure sub-D. What I see here is the ability to create the same result and cut out the ZB Dynamesh process, meaning for hi poly, just a bit of tidying up and you have a mesh for bake and painting in apps like quixel and substance, but in the end have no need of a smooth modifier and polys where you need then and not where you don't. Those meshes would even be suitable for high poly animations or presentations. For low poly connect the verts and simplify the bevels (or on internal curves and fillets remove the chamfers entirely and reduce them to a single edge) uv and ready to bake/paint in quixel or substance.
I am not exactly sure what the qualms are with accuracy as all the products made here on polycount just have to look accurate, not be accurate. For real product production we step over to software like solid works, perish the thought. Could be I am missing something here though.
I spent 2 weeks on the rifle (back and forth between ZB and Max) because I was experimenting with a process that freed me up to be able to make any hard surface forms I want without worrying about quads or complex edgeloop insertions. This method plus the Boolean/dynamesh one blows my mind,... in a good way!
The stand-alone version is fully working atp. It still lacks support for Edit_Poly modifiers, and the preview feature is a little hack'ish, but otherwise it's working pretty well atp.
Yesterday I looked into converting the script into a modifier. Unfortunately it seems maxscript modifiers will be too limited, so I'm looking into converting it to a C++ based modifier instead. Max creation graphs were also considered, but that would limit it to users of Max 2016+ .
this methos will super easily fail on anything that is more complex organic hard surfaces with curvature on more than one axis.
Neox Dunno how this method works in Max but in Maya i definitely agree with you on this.In the end this method is still very young but there is room for experimentation and things look promising so far.The workflow can be non-destructive if you use tools like KTools or CreasePlus in Maya,too.
This method is ideal for making certain assets likes crates,which are just super fun to work on if you have proper boolean tools and the inset+bevel technique. I already have scripts that automatically unwrap my low polies for me,and when the biggest work on a high poly is just to insert hundreds of loops, slapping a few bevels with different widths is definitely going to be my option number one unless the shape requires complex organic and hard-surface transitions.
Er, quads in the base mesh were a coincidence. musashidan is 100% correct when he said 'A sub-D modeler's dream realised in booleans'. The rifle was a test I would never have attempted with traditional means. The improvement in Booleans and the ability to reduce a mesh in ZB to a kind of quad rasta plus being able to polish that rasta by poly groups left me with a modelling process where I could put curved or complex cuts into curved forms and then even punch holes in those forms wherever I wanted. Dynamesh master by polygroups allowed me to blend and fillet forms easily and they look professional in quality. Something my life is way too short for to master in pure sub-D. What I see here is the ability to create the same result and cut out the ZB Dynamesh process, meaning for hi poly, just a bit of tidying up and you have a mesh for bake and painting in apps like quixel and substance, but in the end have no need of a smooth modifier and polys where you need then and not where you don't. Those meshes would even be suitable for high poly animations or presentations. For low poly connect the verts and simplify the bevels (or on internal curves and fillets remove the chamfers entirely and reduce them to a single edge) uv and ready to bake/paint in quixel or substance.
I spent 2 weeks on the rifle (back and forth between ZB and Max) because I was experimenting with a process that freed me up to be able to make any hard surface forms I want without worrying about quads or complex edgeloop insertions. This method plus the Boolean/dynamesh one blows my mind,... in a good way!
@kanga, and let's also not forget that this method is 100% non-destructive. Once you have a saved version of your raw boolean set aside you can drastically make extreme form changes, remove /add extra operands, at any time. Not something that's easily achieved in sub-d without a shit load of manual edgeflow re-routing. Yes, you can sub-d with multiple edit poly mods in the stack, but that's a pain in the arse way to work.
Plus you can pump out a mesh quickly, run the operation, send it to a team lead or client, and not curse the skies when told that a radical revision or extreme change is required.
The stand-alone version is fully working atp. It still lacks support for Edit_Poly modifiers, and the preview feature is a little hack'ish, but otherwise it's working pretty well atp.
Yesterday I looked into converting the script into a modifier. Unfortunately it seems maxscript modifiers will be too limited, so I'm looking into converting it to a C++ based modifier instead. Max creation graphs were also considered, but that would limit it to users of Max 2016+ .
I'll post more updates as things progress.
@Polyherz A modifier version would be awesome :-) Far better than a script because everything remains editable. The problem with C++ modifiers is of course they need to be updated for almost every release of 3dsmax. So you have to plan to update it for a very long time, or release the source. Otherwise we are in for trouble when we try to open the scene somewhere in the future. Since this would be a core part of my workflow it's important for me. Thanks for the great work!
The stand-alone version is fully working atp. It still lacks support for Edit_Poly modifiers, and the preview feature is a little hack'ish, but otherwise it's working pretty well atp.
Yesterday I looked into converting the script into a modifier. Unfortunately it seems maxscript modifiers will be too limited, so I'm looking into converting it to a C++ based modifier instead. Max creation graphs were also considered, but that would limit it to users of Max 2016+ .
I'll post more updates as things progress.
@PolyHertz What about maxscript modifiers seem too limited, I wonder? Provided that we are talking about SimpleMeshMod, as you cannot work directly with the topology in any of the others. Within a modifier like this, you will always work with a TriMesh so the methods available in maxscript and C++ are not really that different - the ready-made one, that is. When making your own methods (let's say quad chamfer), the only limit in maxscript compared to C++ is the speed - and from my experience writing quite a few maxscript modifiers, it should still offer a realtime experience for a <100k meshes.
Btw. MCG in its current state is more or less a toy, although it might be different in ten years. As of now, it lacks support for poly editing - polygons are handled as separate meshes and to work on them, you have to (internally, inside the modifier) explode mesh first, do your ops on polygons and weld them back... while unsure what weld threshold to use, and of course changing vertex indexing. Some basic operations (as of now) result in losing your mapping channels, others will wipe your vertex channel and use it to store their data, as that's the easiest way... I've made an inset/bevel/extrude compound to at least be able to do that, however it's orders of magnitude slower than maxscript version. Likewise, there's no chamfer compound or anything similar. That said, I believe in ten years the situation will be different.
In fact from my point of view and from what i tried we just need an inset by smoothing group modifier. Than we can Quad chamfer.
not quite,
If you take a look in the equivalent Maya thread you'll see a few examples (some are mine) where just slapping a quad chamfer on an inset mesh doesn't give you great results - it often results in awkward pinching and triangulation particularly on non convex n-gons.
The selection of mostly appropriate edges to chamfer doesn't appear to be too tricky from my own experiments but it'll depend on how polyhertz is implementing all the prior steps as to how much information there is to play with.
All these things are sooooooooooo easy to do in Autodesk's Fusion 360, I wonder what the fuzz is all about
If taken a liiittle bit further we could just as well get to 'Making images is sooooooooooo easy to do in Photoshop, I wonder what the fuzz with 3d rendering is all about'
Disclaimer: some time before I fell for the Fusion 360 hype and tried to make the most of it, only to find that for what I do, quad-based workflow is still the fastest approach. Different uses, different mileage, of course, just don't shove your opinions down the others' throats.
Note that it still has the issues of the max chamfer modifier, i.e. the corners where diagonal (hence longer) edges appear from the inset will be kinda pinched. The QuadChamfer modifier might not have the issue so if you have it, use it instead.
Did you install the mcg package via the Max Creation Graph > File > Install Max Creation Graph...? I you did that and it won't work, open the mcg file as a zipfile (rename it to .zip or open with 7zip directly) and copy the InsetBySmoothingGroup to the same directory where the InsetBySmoothingGroup.maxtool file is. Then try Reload > Reload Operators and see if it helps.
Edited : Ho got it .... I'm under 2016 ... Will upgrade to 2017. Sorry man and thanks for this. I was doing it by hand before .... Spliting hard edges than insetting element by element ... than weld ... Oh god in fact i love you.
By that maxtool file I meant that one at 'C:\Users\Massimo\Autodesk\3ds Max 2016\Max Creation Graph\Tools\Downloads\InsetBySmoothingGroup.maxtool' In the same folder, i.e. 'C:\Users\Massimo\Autodesk\3ds Max 2016\Max Creation Graph\Tools\Downloads' there should be a folder InsetBySmoothingGroup and if it isn't there, you can unzip it from the mcg file and then reload operators, open the InsetBySmoothingGroup.maxtool file in mcg and try to evaluate it (CTRL+E). And the gif file showing the process is on max 2016 as well so no need to upgrade (although I like max 2017).
Hahaha ok ... But i'm already installing 2017 and uninstalled 2016 ssd too small here at home. [My subscription need to be usefull sometime]. I will tell you if i have more sucess [8 min remaining for completing install].
i just tried the insetChamfer in 2017 but got this error.
Hmmm, looks like the input order sometimes go wonky and I have no idea why, I've repackaged the mcg file on scriptspot in 2017, hope it will help. If the graph won't compile, open the maxtool file and connect the BevelPoly inputs like in this image (zero to height, mesh to mesh, false to open, remaining negative float to outline), sorry about that:
After evaluating it again and then evaluating the .ms file, it should work.
In case anything looks out of ordinary, redownload the package from scriptspot, the last one is checked on both 2016 and 2017 and I've chained a few ignoreSeconds nodes in there to enforce fixed input order.
hey guys i dont know how to edit in the Max Creation Graph any help on that issue cant find anything online aswell to specificly help me thanks (as in i dont know how to change positioning within the BevelPoly operator)
Swordslayer, thanks for your work. But for me it isn't working, script installed ok, but chamfer parameter isn't beveling geo... or doing anything.
Neither the mcg nor ms did throw any error? Are you trying it on one-object selection? What does the stack look like - and when you expand the Modified Object tree in Track View, do you see something like this?
...with the highlighted properties in bold, which means they are instanced in the stack, i.e. setting the top modifier attributes controls the properties of the modifiers below. You can always change them (and other properties) at the level of the specific modifier, but you should be able to control those basic ones from the top modifier.
Here is a screenshot. We tested on 2 machines 2016 sp3/2017 sp2, no errors on installing stage, but script is only insetting, no chamfering...
Okay, I'm confounded, it looks alright... there might be some parameter of the chamfer modifier that I'm overlooking, could you post a screenshot of yours? Does the amount value there reflect the chamfer value of the InsetChamfer modifier? Thank you for your patience, here's what the chamfer values look like on my end:
Hmmm, is 0,069m the expected amount, or is it maybe some orders of magnitude smaller? I've updated the script to use worldUnits instead, but that shouldn't make a difference in your case as both Chamfer and InsetBySmoothingGroup use worldUnits so the inset amount should be just as small even with unitless input...
it's strange. i get the same error i described in my post above in 2016 and 2017 when i try use the insetChamfer modifer. the insetbySmoothingGroup works fine on its own though.
Swordslayer, found the bug. In my case Vertex Weld in the stack was 0.0 for meters. So vertexes weren't merged and chamfer simply tried chamfer unwelded edges, so why nothing happened.
Swordslayer, found the bug. In my case Vertex Weld in the stack was 0.0 for meters. So vertexes weren't merged and chamfer simply tried chamfer unwelded edges, so why nothing happened.
Damn, that's hard to avoid... I'm making it convert the value from 0.1 millimeters and you're right, with units big enough, the decimals just get cut off... there's no universal value, so.. I've added Weld Thresh spinner to the udpated .ms modifier so that you can change it when needed.
If you are using the same unit setup most of the time, consider replacing the 0.1mm value in the line Vertex_Weld threshold:(units.decodeValue "0.1mm") with a better value. You can set all the 'default' values for the modifiers added there, so if you have any question or suggestion, don't hesitate to ask.
it's strange. i get the same error i described in my post above in 2016 and 2017 when i try use the insetChamfer modifer. the insetbySmoothingGroup works fine on its own though.
Great! If you have any further suggestions (not necessarily for this modifier), feel free to send them to the facebook MCG group if they don't fit the topic of this thread - I don't watch polycount that closely. And check the mcg section on scriptspot, vu creates some useful primitives, controllers and modifiers all the time.
Replies
I would gladly pay for this right now, I went to a recent max user group meeting where 2017 was demoe'd and actually asked why we dont have this exact feature.
Please keep us up to date on the status.
best
Todd
I am not exactly sure what the qualms are with accuracy as all the products made here on polycount just have to look accurate, not be accurate. For real product production we step over to software like solid works, perish the thought. Could be I am missing something here though.
I spent 2 weeks on the rifle (back and forth between ZB and Max) because I was experimenting with a process that freed me up to be able to make any hard surface forms I want without worrying about quads or complex edgeloop insertions. This method plus the Boolean/dynamesh one blows my mind,... in a good way!
The stand-alone version is fully working atp. It still lacks support for Edit_Poly modifiers, and the preview feature is a little hack'ish, but otherwise it's working pretty well atp.
Yesterday I looked into converting the script into a modifier. Unfortunately it seems maxscript modifiers will be too limited, so I'm looking into converting it to a C++ based modifier instead. Max creation graphs were also considered, but that would limit it to users of Max 2016+ .
I'll post more updates as things progress.
This method is ideal for making certain assets likes crates,which are just super fun to work on if you have proper boolean tools and the inset+bevel technique.
I already have scripts that automatically unwrap my low polies for me,and when the biggest work on a high poly is just to insert hundreds of loops, slapping a few bevels with different widths is definitely going to be my option number one unless the shape requires complex organic and hard-surface transitions.
Plus you can pump out a mesh quickly, run the operation, send it to a team lead or client, and not curse the skies when told that a radical revision or extreme change is required.
not quite,
If you take a look in the equivalent Maya thread you'll see a few examples (some are mine) where just slapping a quad chamfer on an inset mesh doesn't give you great results - it often results in awkward pinching and triangulation particularly on non convex n-gons.
The selection of mostly appropriate edges to chamfer doesn't appear to be too tricky from my own experiments but it'll depend on how polyhertz is implementing all the prior steps as to how much information there is to play with.
Disclaimer: some time before I fell for the Fusion 360 hype and tried to make the most of it, only to find that for what I do, quad-based workflow is still the fastest approach. Different uses, different mileage, of course, just don't shove your opinions down the others' throats.
Here is the facebook post where i requested the MCG and where Vojtěch posted it.
https://www.facebook.com/groups/1611269852441897/permalink/1796677843901096/
needs a 'welder' modifier above the inset but works great. thanks Vojtěch
join the MCG facebook group https://www.facebook.com/groups/1611269852441897/
Needs max 2016 and higher, you can download it here: http://www.scriptspot.com/3ds-max/mcg/inset-chamfer
Note that it still has the issues of the max chamfer modifier, i.e. the corners where diagonal (hence longer) edges appear from the inset will be kinda pinched. The QuadChamfer modifier might not have the issue so if you have it, use it instead.
When i try to install the creation graph i have this error message :
Validation failed for C:\Users\Massimo\Autodesk\3ds Max 2016\Max Creation Graph\Tools\Downloads\InsetBySmoothingGroup.maxtool : Error occurred deserializing node: Can't find operator BevelPoly
Any idea ?
In the same folder, i.e. 'C:\Users\Massimo\Autodesk\3ds Max 2016\Max Creation Graph\Tools\Downloads' there should be a folder InsetBySmoothingGroup and if it isn't there, you can unzip it from the mcg file and then reload operators, open the InsetBySmoothingGroup.maxtool file in mcg and try to evaluate it (CTRL+E). And the gif file showing the process is on max 2016 as well so no need to upgrade (although I like max 2017).
After evaluating it again and then evaluating the .ms file, it should work.
...with the highlighted properties in bold, which means they are instanced in the stack, i.e. setting the top modifier attributes controls the properties of the modifiers below. You can always change them (and other properties) at the level of the specific modifier, but you should be able to control those basic ones from the top modifier.
CompanionCube, what SP you have installed?
If you are using the same unit setup most of the time, consider replacing the 0.1mm value in the line Vertex_Weld threshold:(units.decodeValue "0.1mm") with a better value. You can set all the 'default' values for the modifiers added there, so if you have any question or suggestion, don't hesitate to ask.
Are using the latest script version?
thanks again Vojtěch