I delivered 5 tutorials for Autodesk;s 3dsMax Leaning Channel.
Thanks for Autodesk for this opportunity. If you want to see more of these, comment on the video and ask for it!
I delivered 5 tutorials for Autodesk;s 3dsMax Leaning Channel.
Thanks for Autodesk for this opportunity. If you want to see more of these, comment on the video and ask for it!
#3dsMax 2025.2 features Scientific color OSL map by Fabio Cramel.
It is 32 color gradient map with sRGB based interpolation under the hood. But, what’s important is the presets. The map comes with the full sets of 39 Scientific colour maps by Fabio Crameri.
You can see the preview image here.
The color was resampled to 32 color from the original dataset with matplotlib. It is sRGB values.
If you don’t know what the perceptually uniform color maps for scientific visualization is. Please check this page.
https://www.kennethmoreland.com/color-advice/
That being said I gathered even more color maps and made another preset.
It has 371 additional maps from the following sources.
Smooth Cool Warm by Kenneth Moreland.
Viridis by Eric Firing
Plasma, Inferno by Stéfan van der Walt and Nathaniel Smith
Kindlmann, Extended Kindlmann by Kindlmann, Reinhard, and Creem.
Color specifications and designs developed by Cynthia Brewer
http://colorbrewer.org/
ColorCet by HoloViz
https://github.com/holoviz/colorcet/
cmocean by Kristen Thyng
https://github.com/matplotlib/cmocean
To use this, download the attached ScientificColorMaps.csv file and replace this file.
C:\Program Files\Autodesk\3ds Max 2025\OSL\ScientificColorMaps.csv
As of now, the csv file has to be in the same folder as maps.
I hope there could be a way to use a different folder to add preset in the future.
This will be a long tutorial. Be prepared!
I’m sure many of you already have used some form of pipeline or at least heard about it. Having a good pipeline could make your job easier, faster. It would reduce the burden of non-artistic tasks, and let you concentrate on making art.
If your studio is big enough to have dedicated TDs and engineers, you probably already have something. But, if you are a small team, the chances of having an automated pipeline would be low since it requires resources and effort. Or, simply you may not even know where to start.
I have had a chance to build a few pipelines from scratch and also have used a few existing pipelines, big and small. From those experiences, I want to share how I would build a new pipeline for a small team if I start again a small team.
Before we start, I just want to make sure that there is no “right” way for a pipeline. The best one is always the one that artists want/like to use, and every studio and every artist has their own taste. So, use this post as just a guide.
Let’s ask the first question. Does your studio have a rule for saving a max file and render outputs? If the answer is Yes. Then, you kinda already have a pipeline. You may not have an automated one. But, you certainly have a pipeline for sure. But, if it is not automated by code, a lot of benefits of having a pipeline will be lost. Humans simply can’t remember all those rules and execute the rules consistently all the time.
Consistency is the key for automation.
The first step for an automated pipeline can start from establishing a naming convention for project files and render output and making a tool for it.
Why? Because using a naming convention requires a minimum amount of coding. Sure, you can use custom DB or off-the-shelf solutions like ShotGun(Flow) or even xml/json. But, all these methods need to be coded and maintained by someone. If you don’t even have or can’t afford a TD, you probably can’t have a developer for this. Also, even when you could use these kinds of more advanced methods, it is good to have a solid naming convention.
This workflow assumes everybody shares a central storage. In my 20+ years career, I never used project folders and have always used centralized storage. Considering a pipeline exists for multiple artists to work together, I’m not sure how the isolated project folder would work. So, this post assumes everybody has access to the same drive, either it is physically the same drive or synced.
Our goal is having a path and filename that would be unique per task.Then, we can add versions to the name. To get this, we need to collect what kinds of information is needed for a unique task. In this post, I’ll assume my studio is mostly working for episodic shows as an example.
To define a vfx task for episodic shows, you would need to know
You can add more entries like artist name(I usually don’t recommend) or 2 level task name, But, I would have it as simple as possible.
This also can work for a feature film or commercial, you can use the episode entry for sequence. If it is a simple commercial or music video. You can just leave the episode as “000” or something.
Again, Keep it simple and unified. Don’t try to have exceptions and conditions. Yes, in the end, code can deal with all kinds of exceptions and conditions. But, the more parts you have, the more chance you have problems.
OK. The theory itself is simple. But, actually establishing a rule is not that simple. There are a lot to consider. Let’s get into the details.
The first rule of a naming for codes – Never ever use space in the name nor path. NEVER! Trust me just don’t do it. Life is easier without space.
That being said, we can start by simply assembling each entry with “_” for the filename. Something like this. Then, we can say that… “To get the information from the file name, split filename with _. Then, the first one is the show name. The second is the episode number, and on and on”.
HOUSE_201_24x56_FX_Explosion_v001.max
Assembling filename by a naming convention is easy. But, the name also need to be pare-sable by code. Basically, we should be able to extract back the information that assembles the file name. In that sense, adding “_” between each item is not enough. What if your client wants to use “_” in a shot name? Like “24_56”? Then, the filename becomes like this.
HOUSE_201_24_56_FX_Explosion_v001.max
Now filename parsing logic doesn’t work anymore because the 4th element from split would be “56”, not a task type. So, we need to have more complicated rules than just adding “_”. Good thing is that any code is very good at handling those complicated rules as long as the rule is clear and machine friendly. FYI, if you google “regex”, you can see what codes can do for parsing strings.
Let’s try a simpler logic. One of the common tool for establishing a naming convention is using special characters as separators to divide the filename into sections. Usually “_” and “-” are used for the separator because a lot of other special characters are an illegal character for a filename and path.
Now let’s think about which items we have more control over.
With this requirement, this is what I did.
I used “-” as a main separator between task related items and others. So, I added “-” in front of the task type and decided not to use “-” in the task name. Then, we can say that “Separate filename divided at the last -”. Since the last “-” is the divider between task and else. You can use “-” in the shot name if you need. Something like this.
HOUSE_201_24-56–FX_Explosion_v001.max
Then, split the front part with “_” and take the first item as a show and the second item as an episode.
HOUSE_201_24-56 – FX_Explosion_v001.max
Show_episode_shot –
Task part is even easier, split the green part with “_”. Then, the first item is a task type, and the last is a version, and the anything inbetween is task name. You can use any alphabet, number and underscore fore task name.
HOUSE_201_24-56 – FX_This_is_Your_Explosion_v001.max
Show_episode_shot –tasktype_taskname_version.max
A file path convention is easier than a filename convention since we just need to put each item at each level. But, there are a few extra things to consider compare to the filename convention.
Let’s see my sample file path first.
Z:\Project\HOUSE\201\work\24-56\FX\This_is_Your_Explosion\max\HOUSE_201_24-56 – FX_This_is_Your_Explosion_v001.max
First, you will need a root folder. That’s “Z:\Project”. Don’t make it too long or deep. Even tho we are making folders with code. The shorter, the better. Then, the show folder, “HOUSE”. Then, the episode folder, “201”. So far so Good. Easy.
But, what the heck is the “work” folder?
Currently we only have been talking about the project file, like max file and maya file, naming convention. But, you actually need a few different naming conventions for different things. For example, you can’t really use your max file naming convention for your render output. You will likely need more than one outputs, such as render element, from a max file. How about a published assets? If you build an asset publishing system, they will require a slightly different naming convention, “work” here means your working project files such as max and maya files, and we will put all project files under this sub folder.
Now you may wonder why under each episode? Why not under the show folder? Good question.
Your storage is expensive. You can’t store everything forever. At some point, you need to delete files. Even tho I do many things with scripts, I don’t really delete folders with scripts. You may think you made a perfect script for delete folders. But, imagine somehow your logic had a hole and all the project files for tomorrow delivery got deleted!
By having all your projects under the “work” folder under episode folder, you can clean up a project folder per episode easily. If you add this under show, you have to keep all projects for the show until the show ends or manually visit each episode and clean up. If you add it under the shot folder, you have to visit every shot to clean up projects files. Putting under episodes would be a happy medium.
We will talk later again. But, using the same logic, if we have “image” or “output” folder at the same level for render outputs and comps, you can clean up those folder first, and then clear projects later.
After “work”, continue just like file name, and the last folder would be DCC type or the project file format, and all versions for the DCC will be in the same folder.
Some might wonder why not have a folder for each version and have a DCC folder under there like this.
Z:\Project\HOUSE\201\work\24-56\FX\This_is_Your_Explosion\v001\max\HOUSE_201_24-56 – FX_This_is_Your_Explosion_v001.max
That kind of folder structure is usually for published assets which would have different formats for the same version all the time. For example, when you publish a model asset, you would publish an alembic file, a usd or a fbx along with your .max file. In that case, having the folder under the version folder would make sense.
But, usually you wouldn’t switch program between versions. If you ever need to switch to other program, you can just restart from v001.
OK, let’s see what we have again. This is the full path that I’m using.
Z:\Project\HOUSE\201\work\24-56\FX\This_is_Your_Explosion\max\HOUSE_201_24-56 – FX_This_is_Your_Explosion_v001.max
Now we have a rule. Next, we need a tool. Because the consistency of the data is key for pipeline automation. As I said in the beginning, No human can remember these rules and execute correctly all the time. Only way to make this work is having a tool. Something like this.
These list is just a start. Since you have a way to browse set the context of task. You can add more and more features to this tools. For example…
Thanks to the fact that most programs are now supporting Python. You can build the interface once and reuse it for many programs. You can see my example tool is working in Maya, Houdini, Nuke even for Photoshop.
After the project file name convention and tool are sorted out, the next stop would be the render output file name.
For render output, we need to extend upon the project file naming convention so we can automatically track where the renders are coming from.
This is an example of render output file path and name convention.
Z:\Project\HOUSE\201\render3d\24-56\FX\This_is_Your_Explosion\ExplosionHero\v001\HOUSE_201_24-56-FX_This_is_Your_Explosion-ExplosionHero_v001.0000.exr
This is what I did.
NOW here is a little bit controversial part, render elements(AOV). If you are using the multi-channel exr workflow. You wouldn’t need a render element sub folder. I personally am not a big fan of putting all channels in a gigantic exr file.
If you are using the split file workflow, you also need to add a render elements folder. As I mentioned once, it is always better to be consistent. So, I would have the RGB element in its own folder. But, some may opt to leave RGB in the version folder and only have other elements in their own folder.
Then, your file could be something like this.
Z:\Project\HOUSE\201\render3d\24-56\FX\This_is_Your_Explosion\ExplosionHero\v001\Bty\HOUSE_201_24-56-FX_This_is_Your_Explosion-ExplosionHero-Bty_v001.0000.exr
If you decide to have AOV folders, here is one more thing you might think about. You can swap the position of the AOV folder and the version folder like this.
Z:\Project\HOUSE\201\render3d\24-56\FX\This_is_Your_Explosion\ExplosionHero\Bty\v001
This makes deleting unnecessary AOVs easier since all versions for a pass are under a folder and. it is easier for a code to pull all the versions list. But, this also makes it harder to know what is the highest version of all to determine the next version, and deleting certain version becomes more difficult.
OK, now one last thing I need to talk about render output is how to decide the version number. Obviously the simplest method would be to keep versioning up for every render submission.
Another way of versioning is syncing the output version number to the scene file version number. For example, , If your scene version is v008, your render output also becomes v008. It is possible because the render output naming convention has all the items of the project file naming convention. There is no chance that different max files could generate the same render output.
If you do this, you have to version up your scene file to get a new version of renders. This also means you will have skipped versions. That sounds bad. Why would you do this then? Because it allows you to easily track where your renders come from without any extra system. If you automate max file version up after submitting render, you can always go back to the version of max file when you need and get exactly the same render again.
Now you need a tool to set the render output path automatically. Yes, right. This is the moment that you need renderStacks. 🙂
In the following picture, you can see I just made a global function and feed it as maxscript token for rednerStacks. Now you never need to type render output path ever. renderStacks will automatically set the render output path every time when you submit or render.
Of course, you can use any other script/tool, too. The point is that you must have a tool to set it.
Now you have a naming convention for project file and render output and have a tool to handle those path. Then, we can say you have a MVP(Minimum Viable Product) pipeline. But, if your workflow requires comps most of the time. Then, you would like to have naming conventions for comp and precomp as a next step.
This was the project file naming convention for max.
Z:\Project\HOUSE\201\work\24-56\FX\This_is_Your_Explosion\max\HOUSE_201_24-56 – FX_This_is_Your_Explosion_v001.max
For 3d projects, it made sense to have lookdev, fx, and animation task types. But, for comp, do you need them? Do you have a comp for fx and a comp for lookdev? Probably not…
Then, what should we do with the task type? We can remove the item from file and path name convention. That means you would need a separate naming convention for comps which means it will cost more to develop and maintain while having more chances to have a bug. As I mentioned a few times, it is always better to be simple and consistent.
Therefore, I would keep the task type. But, I would change the items. We can at least have a “comp” task type. How about the task name? Usually you would have 1 comp per shot. But, you never know if you would need more than 1 comp in the future. What if the director wants to have 3 options! Since we already have it in the naming convention, it is better to keep it consistent and flexible. But, we can have a soft convention to agree to use “main” as a default task name.
Z:\Project\HOUSE\201\work\24-56\comp\main\nk\HOUSE_201_24-56-comp_main_v001.nk
Now here is something to think about. How about other support task like precomp or roto? If it is for precomp for the same nuke file. It could be just another “pass” like 3d render. But, if it needs its own nuke file, you have 2 choices. 1) having its own task type 2) using a task name.
If you decide to have its own task type such as “precomp” or “roto”, you will have one more level of flexibility( task name + pass name). It also means precomp or roto will have their own sub folders which means it will be easier to clean up. But, you will have a lot of empty or folders with only one sub folder.
Or, you can just utilize the task name. Just make sure artists use “precomp_” or “roto_” prefix or build a tool that can force it.
Lastly, I would separate the comps from the 3d renders. Something like under “image2d”. Our final comp/precomp file naming convention will be like this.
Z:\Project\HOUSE\201\image2d\24-56\comp\main\main\v001\HOUSE_201_24-56-comp –main–main_v001.0000.exr
Of course, you should never generate this path manually. For local rendering, you would make own render dialog with automatic path update. For network render, you would a code to update Write nodes version to latest before open network render submission dialog.
After you implement a good naming convention and tools, you can start to take an advantage of the consistent and predictable structure of files. For example, this is the image loader for my project manager. It build the list of all image assets(render3d, comp, precomp)
This is a Nuke Read node updater.
If you want to go further, you can start to explore a pipeline for asset publishing. I wish continue this tutorial to cover asset publishing. But, unfortunately, everybody works differently, and it is hard to make a universal solution without bloat.
But, I have a few cents that I can share from my experience.
OK! That’s it. Now you know where to start to build your awesome pipeline. I think I put enough information in this post. But, if you think you need help or just want to use what I have built. Contact me through LinkedIn message. I’m available for consulting. 🙂
One of the new 3dsMax 2025 features is the completely rewritten new menu system for menus and quad menu. This is a part of the initiative called Upgrade-Safe UI which was introduced in 3dsMax 2020 for the hotkeys first.
For users, the most important and beneficial change is how the customization is stored and loaded.
The legacy UI customization system was the “Save and Load” system. When users customize menu items and save them, the entire menu status is saved in a .mnux file. Then, when users load the .mnux file, the entire menu items will be replaced by the content of the file. This causes the following issues.
To address these problems, the new menu/hotkey system uses a transformation approach. Basically instead of save/load the explicit configuration of the menu, the new system stores only the delta(change) from the default menu/hotkey and applies back the changes and overrides the default status.
This will allow users to keep the changes they made while still receiving updates from the global changes. This also means the menu customization will be portable between versions and machines.
This also means it is very easy to go back to the default menus if you need to by simply choosing the locked “3dsMax Default Menus” configuration. This is the same for hotkeys since they are using the same system. Everybody probably had an experience where you had to jump on other’s max and realized that all the hotkeys and quad menu are heavily customized. Now you can easily revert to Default and back to the custom.
The menu file(.mnx) are saved in the “User Settings” folder by default. This folder is in the “Autodesk” folder in the user folder, not the hidden AppData folder. C:\Users\[username]\Autodesk\3ds Max 2025\User Settings
You can also set a custom location using ADSK_3DSMAX_USERSETTINGS_DIR env var.
This means that all these settings will survive when you nuke ENU folder to fix issues. Also, you can just copy everything in this folder to another version or machine to get all the settings in this folder.
Currently the following settings are stored in this folder. Any files in this folder is portable and upgrade safe. When you move version to version. Just copy them to the new version folder.
The old menu system is gone now. So, Maxscript Menu Manager interface(MenuMan) is gone. If your plugin/script/pipeline has been using MenuMan for adding custom menus. You need to update to the new system.
A good news is that now you don’t necessarily need to code to add menus. The application package now support “menu parts” component. I updated my scMakePreview to demonstrate how you can use this for any scripts.
You can download and check the package. But, in short, I modified the menu and saved .mnx with the new Menu Editor. Then, add the .mnx file in the package and added this line.
<ComponentEntry ModuleName=”./Contents/cui/csMakePreview.mnx”/>
The plugin package will replace the built-in Make Preview viewport menu with csMakePreview like this.
To assist this, The “Developer Mode”.has been added to the new Menu Editor. When you switch to this mode, only the base and either the selected preset or an empty preset is loaded(no plug-in and user defined menus)to provide a clean configuration to work with.
There are 5 UI items you can customize. Mouse, Toolbar, Menu/QuadMenu, Hotkey, Color.
But! Which file is THE file you need to use? Isn’t there a million places that have ui files? Well… Yes and No. First, the answer to the question is \en-US\UI\MaxStartUI.* files under ENU folder.
C:\Users\[username]\AppData\Local\Autodesk\3dsMax\2024 – 64bit\ENU\en-US\UI\MaxStartUI.*
This is the ui files that gets updated when you close 3dsMax when you turn on “Save UI Configuration on Exit” in the Preference, and they are loaded when 3dsMax starts.
Browse to the 3ds Max ENU folder you want to load UI from and load them. MaxStartUI.cuix is for the toolbar, and MaxStartUI.clrx is for the color. For mouse, MaxStartUI.musx is not automatically generated. So, you can save anywhere and load it.
AGAIN, NOW YOU JUST NEED TO COPY .HSK .MNU BETWEEN VERSION(OR MACHINE) AND LOAD IT TO UPGRADE OR TRANSFER CUSTOMIZATION TO .OTHER MAX
A Friendly Reminder!
Before you transfer any of this UI customization. You need to make sure to install all your plugin/scripts first. For that matter, I already have 3 parts for this. I highly recommend you to read this and try. Since I have implemented this setup, I never ever needed to touch any plugin/scripts install/setup ever again.
/how-to-manage-tools-part-1-scripts-featuring-new-pipeline-integration/
/how-to-manage-tools-part-2-plugins-featuring-new-pipeline-integration/
/3dsmax-2023-pipeline-integration-v2/
!!! Updated to 1.1 If you have downloaded 1.0, please download again !!!
This is a simple script that syncs a camera with an active perspective view. If you want to control a camera view just like perspective view navigation, this is the script for you.
How to use is simple. Select a camera to sync from drop down and turn on Sync. If you turn off the button or close the dialog, the sync will stop.
A few things to remember!
Substitute modifier is one of the most underrated modifiers in 3dsMax and one of my favorite modifiers. As the name suggests, this modifier replaces the object’s mesh/poly. How to use is very simple. Just apply the modifier, turn on “Pick Scene Object” button and pick an object in the scene to substitute.
You can choose to use the substitute mesh only for viewport or render.
You can also choose to use an object from another max file.
We can think about a few useful situations such as…
BUT! That’s not all. Substitute modifier has more super powers.
It makes sense since the Substitute modifier provides a mesh from the stack point. Whatever at the below of the stack doesn’t do anything in any way. The best part is that you don’t have to set anything manually. This modifier just does it. Combined with the feature that allow to use Substitute modifier only for viewport display, this provide a great work around to improve the scene performance when you have a lot of hires animated meshes.
For example…
This is a really really powerful feature. After you pick an object from the scene, you can delete the object. Then, the modifier will hold the mesh information in itself which essentially act as a cache modifier.
This means that you can collapse the stack while keeping all the history. l Some of you probably have been duplicating objects and collapse in the scene and save a copy in another max file for future use. You don’t need to do that any more. Everything can be just stored in the same scene
one of the benefit of caching a big stack is to improve max file loading time. I want to cover this topic in depth some day. In short, 3dsMax file doesn’t save the result of stack in the .max file. If you make a Box and apply Bend modifier. 3dsMax just stores the class(Box, Bend and its parameters. Then, when the file is loaded, it evaluates all the classes and generates a mesh. This means if you have very big stack or very calculation intensive modifiers. The file opening can take a long time. That’s why some modifiers like Boolean, Conform or Retopology have own caching mechanism. With Substitute modifier, you can cache any objects with modifier in the scene if you want. Obviously, it has a trade off. It will increase the max file size. You gotta pick your poison.
Another benefit is that it can be used as a countermeasure for possible mesh corruption. As a procedural evaluation system, if anything goes wrong in the middle of the stack, the above of the stack would produce an unwanted result. For example, Edit Poly is an awesome and powerful modifier. But, it can be fragile with certain operations. In fact, Edit Poly never stored the result of change in the modifier. It is actually a mini stack in a stack. It stores every operation you did and re-execute then you open the file. So, even tho it is slim, there is a chance that one of hundreds of operations, especially one that removes or adds sub-objects, could go wrong. For that case, you can use Substitute modifier to lock/freeze the status of stack.
So, I made a small script called csStackCache to take advantage of Substitute modifier’s super power. You can find from csTools > csStackCach in the Customize UI dialog.
How to use is simple.
BUT! I want really want to set a built-in “Cache” button in this modifier. That will be much faster than my scripted solution. So, please visit here and vote for me!
https://forums.autodesk.com/t5/3ds-max-ideas/add-quot-cache-quot-button-in-the-substitute-modifier/idi-p/12470220
All Thinkbox plugins has been open-sourced. But, it still requires a good amount of effort to update for new SDK changes. I have been try to find a way to recompile this and was fortunate enough to find awesome volunteers.
The effort is still going on. I’ll keep adding as we get more. All the relase from me will be an application package format. You just need to unzip in C:\ProgramData\Autodesk\ApplicationPlugins folder or your own application package folder.
The first one is FrostMX with VRay6 and TP support. Big thanks for Vlado for recompiling! Also, big thanks for Marc Auvigne for testing.
Thinkbox_FrostMX_2024
Big thanks for David Baker from maxplugins.de for recompiling! Also, big thanks for Marc Auvigne for testing.
Thinkbox_XMeshLoaderMX_2024
Ben Lipman also compiled Krakatoa(without TP support). You can find the download link here.
https://www.facebook.com/groups/stackthis/posts/2064066623939823/
Here is some of max file you saw in the Conform Sizzle Reel including the tire and track scene.
Download 3dsMax 2024.2 Conform Sample Pack
Credit
Greg Glezakos – conform_clock, conform_Tire
Paul Erdtmann – conform_tracks
Logan Foster – conform_zipper
Michael Spaw – conform_scanner
Changsoo Eun – conform_array_rope,conform_Fake_Collision conform_noiseball_animated, conform_proxymity_shader, conform_shrinkwrap_band, conform_missed_verts, conform_volume
There has been many requests for providing a way to adjust clipping plane by numbers.
Your voice was heard. 3dsMax 2024.2 bring MXS exposure for the clipping plane.
vpSetting = NitrousGraphicsManager.GetActiveViewportSetting() vpSetting.ViewportClippingEnabled = true vpSetting.ViewportClipNear = 0.05 vpSetting.ViewportClipFar = 0.8 vpSetting.ResetViewportClipNearFar() Note: Same as UI, the allowed range of near/far is [- 0.1, 1.1], and the specified value should obey the rule: near < far
Of course, I know there are many who don’t/can’t script. So, I made a script for you which you saw in my video.
3dsMax 2024.1 has been released. I made a YouTube playlist for the highlights.
For the detailed list, please visit the unofficial 3dsMax what’s new