I have also just uploaded a new youtube video showing off the process for converting a Standard Max material into a Cycles-compatible material. The video is intended to be more of an introduction to building Cycles materials within this plugin rather than just demonstrating recently-added features as I have done in the past.
Alpha 3.02 has been released today. This is another minor release in the alpha 3 series that brings some small fixes and user-requested features. A download is posted and the changelog has been updated.
From here on my plan is to do a new minor release approximately monthly until all of the Alpha features below have been added.
This is a list of features I plan on adding to this plugin up to and past the release of version 1.0. If there are any features missing from here that you would to see in the plugin, please leave a comment and I will look at what needs to be done to support your request.
- Physical Camera
- At the least, the plugin will support both motion-blur and depth-of-field through this camera type.
- Physical Sky
- It will be possible to do a render using Max 2017’s new physical sky map. This will likely be achieved by baking out the physical sky to an HDR bitmap.
- ActiveShade Rendering
- Nothing more to say here, ActiveShade will be coming in a future update.
- Revamped Normal Map Support
- Normal maps in the current Slate materials are close to useless as all the parameters are locked.
- Each material will expose full control of all normal map parameters.
- Simple PBR Shader
- This will be a new material type that is a simplified version of an ubershader. It will provide an easy way to render a material based on Substance or Substance-like PBR channels.
- Node Editor Updates
- There are still many cycles node types not available in the editor. Most of these will be added in the alpha phase.
- It will be possible to define environment maps through the node editor. Right now the editor only supports geometry shaders.
- More Slate Nodes
- A number of important cycles nodes are only currently supported through the node graph editor. More of these will become available through Slate during Alpha.
- The beta phase will start when all of the alpha features above are supported. No major features are planned to be added during beta.
- OpenCL Support
- I lack AMD hardware to test this on so I would have trouble providing support or stable builds. I’ll reconsider adding OpenCL support post-launch.
- OSL Support
- OSL is only supported for CPU rendering and for pre-release versions I want to focus on features that will work for both CPU and CUDA renders.
Today is the release of version 3.01 of the plugin. This release focuses on fixing up some usability issues with the Shader Graph material as well as rendering in progressive refine mode. Changelog and downloads have been posted.
I’ve also just recently added a Report Bug page to this website. It isn’t a proper bug tracker but should serve fine for now. If you have any problems with using the plugin please post a comment there with details and I’ll look into it.
Today I have published the first release of the Alpha 3 series. This release includes what I intend to be the last major feature before 1.0: A new node graph editor. This editor allows users to construct Cycles node graphs with much more creative freedom than was possible in previous iterations of this plugin.
I’ve put together a short youtube video showing how the new node graph editor can be used from inside 3ds Max:
As promised a few weeks ago I’m here with another update on how plugin development is progressing, this time focusing on a Cycles shader graph node editor that I’ve been working on recently. Below is a short video demonstrating this node editor being used to create shader graphs for Cycles’ XML frontend.
Now for a bit on my motivation for making this.
An early problem I faced when making the Cycles plugin for 3ds Max was to find a way to allow users to define Cycles shader graphs in Max. The solution I settled on to begin with was to create a Max material plugin for each type of shader node in Cycles. This allows users to author shader graphs and modify/animate all parameters of those graphs using the normal Max user interface.
This approach is great for letting users assemble simple shaders without needing to learn any Cycles-specific knowledge, but comes with some limitations and unintuitive behavior that might confuse a new user. A few examples of such behavior are:
- Some cycles nodes simply can’t work within the Max material API. This API limits outputs to be either Texmaps or Materials and only allows one output slot per node. This means that concepts in Cycles like vector maps and float maps, as distinct types from color maps, are not visible to the user. This also makes it difficult to include things like math nodes.
- All texmaps must be baked out to bitmaps prior to rendering. As it stands, a user must know about this and know that settings for texmap baking can be modified through the use of a ‘Cycles Bitmap Filter’ node. Without this knowledge, texmaps will all bake out at default resolution which will likely produce a render with blurry textures. The plugin should make the user more aware that this baking is happening, and offer a more discoverable way to configure it.
- Some texmaps and materials that are native to Max could be connected to texture and closure inputs on Cycles materials, but most Cycles materials or texmaps could not be used as inputs to native materials. This allows users to easily create invalid materials by accident if they don’t understand how the plugin builds the Cycles shader graph from the Max shader graph. I can’t expect users to know that, particularly new users, so the plugin should do more to not allow such materials to be made in the first place.
Because of these reasons and more, I thought it would be best to simply let the user work directly with Cycles shader graph nodes rather than having the user construct a graph in Max nodes, then translating it (poorly; with the above problems) to Cycles nodes.
To that end, I created this node editor. It is a light library (depending only on NanoVG and GLFW) that creates a window with a drag and drop GUI vaguely resembling the Blender node editor. Users can use this GUI to build a complete Cycles shader graph.
I’m planning to include this new node editor in the Alpha 3 release of this plugin, which should be ready some time in late June. I’ll have more specific details about how it will integrate with Max at that time. I also plan to release the source to this node editor as an Apache- or BSD-licensed library once I have the API figured out. This will likely be around the same time as the Alpha 3 release.
That is all for now. As usual, continue to watch this blog for updates.
This release corrects the issue with environment maps baking out as all-black, but introduces a new environment map problem that prevents HDR data from being recognized.
I’ll be posting another bugfix update for the Alpha 2 series once this issue is resolved.
Here’s just a quick update on the state of things as I’ve been quiet lately about this plugin. There are two main things I’ve been working on recently.
First, I hope to post a 2.01 update sometime in the coming week to address a few issues with environment lighting in the plugin. The largest of these problems is that image-based environment maps will always bake out as an all-black bitmap during a render. This is a new quirk that came up with Max 2017 and is proving a bit trickier to resolve than I expected.
The other bit I’ve spent most of my time working on lately is a node editor that will allow users to more easily define graphs using native cycles node types. Up to now I’ve been creating Max materials and Texmaps that are each roughly analogous to a single cycles node. This approach is fine for simple shaders, but there is no good way within the Max API to create nodes that correspond to some of the cycles internal types such as texture coordinates, fresnel, normal maps, and a few others.
This new node editor will let users author shaders with a node graph interface similar to Blender using all of the nodes built in to Cycles. Here is a quick work in progress screenshot showing off what this looks like.
I’ll have more to say about this in a different blog post later on.
Today I have published the second alpha release of the Cycles plugin for 3ds Max. This release moves to plugin to target 3ds Max 2017 exclusively and brings a number of new features and improvements. An installer is available from the download page and the changelog has been updated.
I’ve posted a new video to youtube as well that goes into some more depth on these additions. It is available here:
I’m sorry to drop support for 2016 so soon after releasing the first alpha, but this was necessary to allow me to move to a more modern version of Visual Studio that can actually build Cycles. Previously I had to make some source changes to Cycles and its dependencies to make them build with the old VS; for the 2017 plugin this is no longer the case.
This combined with the new features in Max 2017 that directly impact renderer development, including the new UnifiedRenderer API and Qt-based GUI support, justified dropping support for the previous version.
That said, Max 2017 will be supported for the forseeable future, including after the release of Max 2018. I do not intend to make a habit of breaking compatibility like this.
I’ve just now put this plugin up for download on this website, get it here.
To any new users, please review the videos in the previous blog post and read the FAQ as they contain important information about how to use textures and environment maps correctly. With this plugin it is a little different from how Max normally works.
Watch this space for future updates.