Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Galen Helfter

Pages: 1 ... 25 26 [27] 28

The newest version of the plugin has been released and has better renderer support, but doesn't quite work well with VRay RT/Vray GPU yet. We're talking with the developers at Chaos Group about having our plugins work together, but that's still a work in progress.

It's definitely because the output image type only supports 8-bit textures. We're looking at having it able to export .exr files in the next release, which should be out soon.

The 2.1.1 release of the plugin is out now on the webpage. If the problem is still there for you in that version, please let me know.

Testing it on my machine, it returns an empty path as of now.

Code: [Select]

It may be that something has already been changed there for the next release.
I hope that helps.

@Mumm For the next release of the plugin, which should be coming soon, separate cache folders for each Substance node has been implemented. They will save with the scene and be there on load. I hope that will solve your issues.

If this is attempting to load from the Beta version of the newly released plugin, it was noted that the save files would be broken between the Beta and the release.

There were many significant changes that required such a break.

It would definitely be easier from a workflow and interoperability standpoint, but would require an edit to the workflow scripts to either add an entry for VRay Next or to detect what the current renderer is and work off of that.

So it'd simpler from a hookup standpoint, but would require work to make it happen.

@alex_43 Network rendering is currently not supported in the released 2.0.0 version (it will be renumbered from 1.0 to accommodate the old plugin). Work has been added for the next release to make it happen with Autodesk Backburner, which the details of will be fully fleshed out in the release notes when 2.1.0 releases. Currently, it's likely to not work, especially with renderers like VRay that do some odd processing of their own when run in batch mode.

@alexgarmash The workflow script is designed to work with a Metal/Rough workflow, which Arnold now expects as well. If you look at the outputs of the included Substance, which is likely included from the original 1.0 plugin, it doesn't have the outputs (Base Color, Metalness and Roughness) that the script looks for.

This is a mismatch between the old Substances and the newer Arnold workflow. Those Substances included come from the original plugin distributed many years ago, and aren't really accurate to new workflows. You could use them if you manually transformed the outputs into what Arnold expects, but they're not going to be very useful. When the original plugin is fully deprecated, it's likely these Substances won't be included in an install of 3ds Max anymore.

@3d_4 There's a bug with the installer that has been addressed for the next release where it would install both the 2018 and 2019 files into Max 2019. If you check your Program Files folder for the 2018 plugin and delete it if it's there, does it fix the problem?

@Mark042 We've seen a few errors with the menu, and have a ticket in to investigate its behavior. We've got a new release slated soon, but we may look into whether it can be addressed before that. If you can consistently reproduce it or find something that definitively makes it happen, that'd be a great help.

@Colin Senner The attributes in the new plugin are more dynamic, so at that point the filepath hasn't really been initialized as an attribute, as no Substance has actually been loaded into the Substance2 node. It may not be intended per se, but it's more a particularity in difference between the two plugins.

If you're using that to attempt to determine whether a Substance has been loaded, we should look at adding a direct MaxScript call to the Substance to determine that directly, such as a Substance2.isInitialized() method to return true/false.

Although as a whole, our function call should return something default and not throw an error, so that in itself is not intended and should be addressed.

It's part of the architecture right now. We load the engine .dll files, and need to be able to locate them. Max offers functionality to determine the Max install directory, but we can't easily load them from an arbitrary location, as a plugin shares the current directory with the Max program, and not where it itself actually is. Thus, we use the Maya executable location to locate the engine files.

Software like Maya and MODO allow a stronger plugin directory system that is easier to work with there. We should investigate looking if we can get something from the Max SDK on the matter and see if we can edit the program to work with that.

One of the features to look forward to in the future is a silent install, which will make it easier to deploy the plugin on other machines as compared to the current manual approach.

Are you installing the plugin on a network drive or separate location from your 3ds Max install?

The plugin queries 3ds Max's interface for paths, and works relative to the 3ds Max executable for its paths, as the current working directory of the executable is how it determines the locations of files.


That should be enough. I'll have to test with that version and see if I can reproduce it. At first glance, it sounds like the current slate view is getting closed somehow, as that would do the behavior you talked about, since Max will cull unused nodes when a view is closed, but it'll take more investigation and a reproduction to confirm whether that's the case.


Thank you for the information on it. We'll have to investigate later how that works and whether we can make it work.

Pages: 1 ... 25 26 [27] 28