Maxwell Render | Official public forum

I'm sorry if this problem has been discussed, but I couldn't find a previous thread that helped me.

I'm no computer genius and apologize if I'm missing some basic thing that's causing my problems.

Sketchup crashes every time I try to export to Maxwell. Whether it's to Studio, Render, MXS, it crashes.

The Bugsplat detail says:

SketchUppQDCT45L5.dmp
DPNL6HP6.xml
SketcUpUndo0.log

I'm running Windows 7 professional on a Dell T5400 Intel Xeon E5410 @2.33GHz ( I think 4 processors) and 4 GB ram.


I don't know what to do. Any help is greatly appreciated.

First, a few questions:

1. What is the plugin version? (see main menu > Plugins > Maxwell > About)
2. You say it crashes every time; is this the case with every model, or just with one?
3. Do you know how to monitor memory usage in Windows Task Manager?

Thanks JDHill for helping.

1. I've tried every version of plugin. Today I just loaded 2.5.15
2. Every model. Actually, almost randomly it worked for a simple model once, but then didn't work again for that same model.
3. Do you mean, change the priority to "high" under processes?

You can monitor how much memory is being used by an application (i.e. SketchUp.exe) in Task Manager by going to View > Select Columns, and checking the boxes for Memory - Working Set, Peak Working Set, Private Working Set, etc.

Don't worry about that for now though, as you indicate that you experience crashes with simple models. So let's keep going.

4. Which version of SketchUp you are using? (see main menu > Help > About SketchUp)
5. Does it crash just the same if you use File > Export > 3D Model and select the MXS format?

4. I'm running SketchUp Pro Version 8.0.4811
5. Yes. But, this time the bugsplat info is slightly different.
SketchUpM1D15SR4.dmp
JE914RN0.xml
SketchUpUndo0.log

Thanks, some more questions:

7. Does the behavior change if you do/don't run SketchUp as administrator?
8. Does it change when you use different MXS output locations (i.e. Desktop, etc.)?
9. Is Skp2Mxs.dll the only Maxwell-related file in [SketchUp 8 installation]/Exporters?
10. Have you tried uninstalling the plugin, deleting any plugin-related files, and reinstalling?

Plugin-related files, if present, will be found in [SketchUp 8 installation]/Exporters and [SketchUp 8 installation]/Plugins. In Exporters, there will be Skp2Mxs.dll, while in Plugins, there will be maxwell.rb and a maxwell folder. It is not likely that these will be present after uninstalling, but check anyway, and also make sure there are no other Maxwell-related files in those locations, possibly left from pre-Maxwell 2.x plugins.

Lastly, can you generate a crash, navigate to [system root drive]:\Users\[user name]\AppData\Local\Temp, and locate the three files listed in the bug splat dialog box? If they are not too large, can you zip them up and send them to me at jeremy at nextlimit dotcom?

7. I will try that
8. No
9. No, there's MaxwellExport.dll, Skp2Xsi.dll, Skp23ds.dll
10. I did try this several times as I upgrade my plugins

I will take the time to try making some of those changes and let you know what happens.

9. Please delete MaxwellExport.dll from Exporters, this is left over from a very old plugin. The current exporter is named Skp2Mxs.dll.

#9! That did it.

Thanks so much for your help JDHill. I would never have deleted that file without your suggestion.

Now off to render!

I am currently working on a model that exports/fire great from home SU8, 2.5.15 plugin,
but at work (SU7), it got to a point where it runs out of memory and crashes every time.

I was also having problems because of the old exporter, but I have already fixed that...

JD: could you expand on what I need to look for regarding memory use
Which of the columns should I monitor?

PS: after reading you post, I tried to run as admin > this time I got a C++ runtime error during the "voxelization" process

I am running out of ideas....

PS2: Could it be that is trying to write a MXI for the fire (does fire write a temp mxi?) in User Docs and the space isn't available?
Thinking this could be the problem, I wrote a post about it earlier: http://www.maxwellrender.com/forum/view ... 07&t=37435

Theoretically, SketchUp 8 can use more memory than SketchUp 7, due to a minor change Google made in how they compile it. So it's entirely possible to be able to work with a model in SketchUp 8 which will cause out-of-memory in SketchUp 7.

Now when you say it is running out of memory, how are you determining that? Is the plugin telling you so? If so, then that's simply the case. If not, then I'd ask why you think it is out of memory.

And no, Maxwell Fire does not write any MXI file.

For a while it was failing to export and I would get the: "Export failed: Out of Memory"
I have been messing with this for several hours, and now I am getting it to go all the way to the "Voxelization" process.
Then I get the C++ Runtime Error and SU closes.
IMPORTANT: the Render-in-Maxwell is now working again. Fire is what is crashing.

As test, I hid the about 75% of the model: fire worked.
My latest test was too use a plugin to remove ALL textures from the model: fire Worked too!

Two possibilities I can think of:
1-either the textures are over-loading SU/plugin.
2-there is a corrupted/problematic texture/path that is making it crash.
(the mxm utility you gave me shows that paths are all ok. Output Path is ok, and path to default material is ok > these are some of the path related issues I have had in the past.)


If it helps, here are the last two export reports...
http://db.tt/ydsWwrC7
http://db.tt/ghjEnO7w

Looking at those logs, it doesn't appear that the model is extremely large. Textures might be, though. So, I guess, open Task Manager, go to View > Select Columns, and enable Memory (Working Set) and Memory (Peak Working Set). Then keep an eye on those as you are working and see how much is being used. In SketchUp 7, I don't figure you should count on getting much higher than 1.5 GB and remaining stable.

The fact that you actually got notification from the plugin about running out of memory strongly suggests that to be the case, as does the C++ runtime error (does it say something similar to "the application has requested that the runtime terminate it in an unusual way"?), which is happening outside of the plugin's ability to protect from out-of-memory.

As an aside, do make sure you are using components as much as possible, since the plugin is extremely aggressive about exporting them as instances. If you have structures like this:

• [component]
  - [group a]
  - [group b]
  - [group c]
  - [group d]

Where each group is a copy of the same thing, you rather want to make that original geometry a component such that you have:

• [component]
  - [component a]
  -- [group x]
  - [component b]
  -- [group x]
  - [component c]
  -- [group x]
  - [component d]
  -- [group x]

In this case, [group x] will only appear in the MXS one time, with components a/b/c/d appearing as instances of it.

the application has requested that the runtime terminate it in an unusual way"

: yes

Back @ home things are smooth
I guess I should just not go to work anymore
I guess I will just have to lobby the IT guys into getting SU 8 (but I also hesitant, because 9 might come out soon!)

Regarding components and hierarchy, I am not 100% sure I understand:
Is there a difference/benefit from one of the 3 cases above?

Case 1: (ie: A patch of trees group together)
[Model]
- [group a]
-- [component A]
-- [component A]
-- [component A]
-- [component A]

Case 2: (ie: tree components ungrouped)
[Model]
- [component A]
- [component A]
- [component A]
- [component A]

Case 3: (ie: 2 groups of tree components with a different arrangement)
[Model]
-[group a]
-- [component A]
-- [component A]
-[group b]
-- [component A]
-- [component A]

Those examples look fine -- in each case, you should find the faces contained in the definition of [component A] being written only once in the MXS. My only point in mentioning it was that since a group behaves so much like a component (internally, that's what it is), it is pretty easy to write models which are heavier than necessary.

I've written about this a bit in the past, and it is probably best illustrated using the example of rendering grass using instances. Your options are basically these:

1. make one thousand blades of grass.
2. make one blade, put that in a component, and copy the component one thousand times.
3. make one hundred blades, put them in a component, and copy the component ten times.

In (a) you will obviously not be making use of instances. While (b) may be intuitively correct, it may not actually be the best choice, due to the size relationship between the one blade, and an instance of it; given simple enough geometry, it may be the the case an instance is hardly any smaller, data-wise (an instance is not zero-size; it still has a name, position, material, etc.), than the mesh data. The main downside of this method is degraded export speed: writing a thousand instances can take much longer than option (c), which on the other hand, is likely to take somewhat more memory than (b).

Something like grass is clearly an extreme case, and usually you are just fine to put whatever faces you have into a component without thinking about it too much, but it is still something to keep in mind.

In the case that it is actually your textures which are causing you memory problems, the next version of the plugin may be able to help; in the right-click UV menu, there will be an option to 'Ignore Distortion'. This was prompted by a tree sent to me by a user, which had subtle distortion on each and every leaf. This caused SketchUp to consider each one as unique and to write a separate texture -- something like 40,000 textures, if I recall correctly -- for each at export. By enabling 'Ignore Distortion' on the tree component, only one texture is exported, which is really no problem, since the distortion (apparently he had worked on the tree in Blender, and then exported it for use in SketchUp) is insignificant.

I think that's pretty rare though, so it might not be something which would help in your particular case.