#378202
Hi,

Trying to render instanced mxs references causes Maxwell to crash right at the end of voxelization. Using 3dsmax instances.

I tried with a couple of references and both crashed.

Instancing of proxys of those references causes no trouble.

Edit: well it does cause some trouble, but I don't know yet the pattern...

Re-edit: for some reason if I make 8 copies or more it crashes (when using 3dsmax instances) :?:
#378292
It's kind of confusing; maybe this doesn't have to do just with mxs references or proxies but just with instances.
Anyway I cannot get a pattern. I get the crashing scene; start deleting things until it doesn't crash anymore, then I isolate the objects that made the difference and save them into a different scene and those alone don't crash. :?:
#380918
I actually just had a similar issue using 3ds Max Design 2014 x64, Maxwell 3.0.1.3 and 3ds Max Plugin 3.0.30. I had a scene that I exported as an MXS and then loaded it as a Maxwell Reference. I reexported 400 frames for an animation. Maxwell would crash almost immediately upon rendering. This happened on 4 separate machines. My only solution was to disable the "Use 3dsMax Instancing" option in the render setup dialog.

The log file wasn't too helpful in this situation though. I was hoping it would have had a more verbose level of reporting (even though I had it set to deep debug). All it said was:

..........
[04/June/2014 12:22:54] [04/June/2014 12:22:54] [INFO]: Dependency found: <PATH>
Installing error mode handler
[04/June/2014 12:22:54] [04/June/2014 12:22:54] [INFO]: Message to render node: render_info preprocessing data...
[04/June/2014 12:22:54] [04/June/2014 12:22:54] [INFO]: Checking Data
[04/June/2014 12:22:54] [04/June/2014 12:22:54] [INFO]: Loading Bitmaps & Preprocessing Data
[04/June/2014 12:22:54] [04/June/2014 12:22:54] [INFO]: Loading MXS references...
[04/June/2014 12:22:54] [04/June/2014 12:22:54] [INFO]: MXS references loaded successfully

[04/June/2014 12:22:54] The remote host closed the connection . Code: 1
[04/June/2014 12:22:54] ERROR: Error in rendering process. The process crashed some time after starting successfully.
[04/June/2014 12:22:54] ERROR: Render process crashed!

[04/June/2014 12:22:54] Connecting to render process: Binding to port: 45463

It must have been something in my scene, because I tried a quick example from scratch but couldn't replicate the crash. Unfortunately, my exact scene this crashed on is quite large with all of it's assets. Quite a few of the assets are 3rd party content that I can't distribute.
#382732
I wanted to revisit this as I am having MXS Reference issues again. I thought about posting this in the Maxwell V3 section, but I figured it's actually related to the plugin and not Maxwell itself.

I tried enabling / disabling "Use 3dsMax Instancing" but it didn't seem to fix the issue this time.

Are there general guidlines for what you can and can't do with MXS References? I know that Maxwell doesn't let you put an MXS ref. inside an MXS ref. What about using MXM material references and embedding them into the scene? Do things like that have any significant impact MXS References or Maxwell's stability?

Are there variations of object types and properties that I should avoid in 3ds Max when exporting to Maxwell? What about 3ds Max groups and links? Does the plugin have to do some special interpretations for those types of objects? I always assumed that since Maxwell dealt with individual, static scene files that rigging, wiring, and everything else animation related in 3ds Max was ignored by the plugin and it exports objects as 3ds Max has manipulated them based on key frames.

The Maxwell documentation just defines what references are and why they're useful. I didn't see anything specific to best practices though, or even defined limitations.

http://support.nextlimit.com/display/mx ... +MXS+files

What I'm doing specifically is along the same lines as the "fly-through sequence" mentioned in the doc's help tip. I went one step further and animated the positions of the references, which theoretically shouldn't have any effect on each individual MXS scene file that gets exported.

Any tips regarding MXS References and best practices would be great! Even if it's just a simple "do's and dont's", that would be helpful. If nothing else, it would help me rule out user error. Thanks!
#382762
The only limitation I'm aware of is having a MXS reference inside another MXS reference, which you already mentioned. I think there was a bug with instances inside references at some point, but it should be fixed in the latest "early build" version of Maxwell. Everything else should work in theory, but there are many combinations of factors, and it's possible some of them are buggy. If you ran into a situation where the renderer crashes or doesn't perform as expected, please give us details about how to reproduce the problem, and we should be able to fix it.

Groups and links have no special meaning to the plug-in, it just exports individual objects. Skinning is applied at export time, and the engine just sees a mesh like any other (no skinning or deformation is performed at render time). Therefore, having these kinds of objects inside a reference shouldn't be a problem.
#382848
The procedure to replicate the crash is actually pretty straight forward, but would require the scene that I'm using. I can send you the 4 versions of this scene that would let you compare working versions vs non-functional versions. I'm actually using plugin version 3.0.34 (instead of the older version in the post title). Fair warning, these files are going to be quite large. The zip file containing everything is almost 500MB. I'll place it on one of our secure servers and send login credentials to Next Limit personnel via private message. Due to EULA's, I can really only share them with Next limit support staff for the purposes of trouble shooting. I saw the Maxwell docs said that any content sent to Next Limit is strictly confidential and will ultimately be deleted:

http://support.nextlimit.com/display/mx ... g+Problems

The 4 scene files are as follows:

1.) 3ds Max Working - Maxwell_Forum-41976.max - The packed up 3DS Max scene with some MXS refernces

2.) Maxwell Working - Maxwell_Forum-41976.mxs - The complete MXS file as exported from 3ds Max (based on the above 3ds Max file)

3.) 3ds Max to Maxwell Crashes - Maxwell_Forum-41976-CRASH.max - The packed up 3ds Max scene with as many MXS refernces as possible

4.) Maxwell Crashes - Maxwell_Forum-41976-CRASH.mxs - The complete MXS file as exported from 3ds Max (based on the above 3ds Max file)

The only differences between the working and crashing versions is the amount of MXS Referenced geometry. The working ones ultimately export all of their data into an MXS file anyway, which is why it's so odd the manually created MXS References causes a crash.

I included a basic sysinfo.txt file describing my machine setup, as well as a CPIUD export with very detailed system specifications.

Again, anyone on the Next Limit support staff, please PM me for login credentials to download the files.

Thanks in advance for any help on this!
#382874
The crash is caused by an engine bug related to emitters in MXS references. The good news is that the bug is already fixed in the development branch, and the fix will be included in the next Maxwell update. The bad news is that we cannot work around it from the plug-in side, so I can't make a quick plug-in update which takes care of the issue; you'll have to wait for the next Maxwell patch, which should be soon, but we don't have a definite release date for it yet.

Thanks again for the detailed test scene.
#382876
Thanks for looking into it Mihnea! I'll just omit emitters from MXSRefs until I install the next Maxwell core update. At least it's a predictable error, which I was unable to prove based purely on the logs and observable behavior.
#382881
Hey Mihnea,
As a follow up, I just did this on a different (but similar) scene by only referencing geometry with no emitters attached. The heavily MXSRef'd version crashed. while the native 3ds Max version didn't. I'll pack up the files and send you a link to a new zip file. Since I'll just be using the standard export features of both 3ds Max and Maxwell, you'll need to resolve paths using alternates. I'll PM the path and credentials.

I also took the liberty of removing any plugin based object modifies by collapsing those objects down to Editable Polys. I could take it a step further and collapse everything down, that way we could verify if it's a combination of modifiers that's doing it.

Thanks Minhea!
#382883
I just tested a version locally where I collapsed every possible object down so there were no more modifier stacks (essentially). It still crashed, so I'm thinking you may be correct in that this has nothing to do with the plugin and is more related to the engine.

I'll try one more test where I'm comparing MXM references within the MXSRefs (embedded vs referenced). I'll do this one as a simple scene from scratch, that way it's easier to share and duplicate.
Rhinoceros 6 support

I just installed the new maxwell_rhino_v4.2.6.3_WI[…]

is Maxwell Render abandoned?

"You can expect good news in a few weeks. Be[…]

Good day! We have just released a new version of […]

Hi there, after a texture tag has been assigned to[…]