Maxwell Render

I am adding an MXS Cache Policy setting to Options, whereby you will be able to choose your preferred behavior: to use caches, to invalidate them, or to prompt when necessary.

_________________
Next Limit Team

Yes, I'm aware of the 'refresh' button, but that won't fix the issue i'm describing.
Sometimes FIRE won't render. A little yellow exclamation mark pops up in the lower right corner and reports something like 'no material assigned to mesh in component 'Name[number]'. Pressing render (and thereby sending the FIRE-data to Maxwell) ends in an error in the Maxwell Console.
Closing FIRE and hitting render again makes everything work. Except for FIRE in SketchUp, which keeps reporting the missing material in a specific component. Editing and coloring all faces in any component with that name seems to solve the problem. Later, in the same or another model, it may reoccur with another component... I can't reproduce the issue, but I'll post a model when I see it again.


Sounds great
/Stefan

Well it sounds like you have a bug there, but I don't understand it, since the code doesn't change from one case to the other. So, it must come down to some subtle difference between how Fire processes the data and how Maxwell does -- if you find a model which reproduces this reliably, I'll sure take a look and try to see what's going on.

_________________
Next Limit Team

Just to add that I am experiencing exactly the same issue as Stefan. If I get a model that has reproducible behavior I will let you know.
This minor quirk aside, many many thanks and congratulations to you on this release of the plugin - it has dramatically increased the quality of my life!

Best J

Here's a screenshot of the strange error:



This case is regarding an emitter, but it could be any material.
Now I've encountered the error in both the Windows and the OSX-version.

If the file is saved, closed and re-opened, the error disappears...
I can't reproduce the error on demand, it just pops up from time to time.

/Stefan

Thanks Stefan, could you confirm that the following is true:

1. open SketchUp and draw a plane
2. draw a diagonal across the plane to produce triangles 1 and 2
3. assign non-emitter material A to triangle 1
4. select the entire plane and make it a component
5. assign non-emitter material B to the component
6. render in Maxwell Fire

Here, everything should be okay, with triangle 1 showing material A and triangle 2 showing material B. Next:

7. switch material B to use the Emitter Character

Here, you should see the same error you show above. Next:

8. click the Re-export Scene button in the Fire toolbar

The error should go away, and Fire should start rendering, with triangle 1 using material A and triangle 2 using (emitter) material B.

What is happening is that if possible, the plugin will export the plane as one mesh, assigning the two materials using triangle groups. Emitters are not legal on triangle groups though, so if necessary, it will export each face separately. In the above example, the assignment only becomes illegal after the fact -- the mesh has already been exported using triangle groups, with one of the materials assigned to one of those groups being changed into an emitter later on, causing the error. Re-exporting, the plugin's logic finds the emitter material assigned, and splits up the mesh into separate sub meshes to make the emitter assignment legal.

_________________
Next Limit Team

Hi JD.
Yes - it is true, that by following your steps the error is produced, and that re-exporting the scene fixes the problem. So far so good

Unfortunately this error, which I described in the screenshot, is regarding an emitter and is not the error I initially wanted to report...
The initial error-report said something like 'object <component#21> has triangles with no material - render cannot continue'.
Re-exporting the scene (or even closing and re-opening the FIRE-window) did not solve this.
The scene could not be rendered with FIRE but worked fine if send to Maxwell.
As I recall, shutting down SketchUp, re-starting the application and loading the model would 'cure' the matter, but I'm not sure...

I've saved a screenshot of this in my office, but since I'm away on holidays I won't be able to send it the next couple of weeks.

Another issue, that I also have nailed in a screenshot in my office:
Sometimes, when opening Maxwell Scene Manager, activating the Materials-tab and choosing a non-Automatic material in use, eg. an Emitter, only the Type and Roughness-settings would be shown. In Type, it would say Emitter...
If I then wanted to change the Watts or Efficacy on this emitter, I would have to choose another material-type and then re-choose the Emitter-type again, resulting in my Emitter being reset.
It is important to note, that this could happen with any non-Automatic material, not just emitters.
Unfortunately I can't send you a screenshot yet - but I will as soon as possible.

I hope you get some days off to enjoy the hot summerdays!

/Stefan

That's curious, since the plugin is not capable of performing material assignments on the running Maxwell Fire scene. So if it's not doing any of those, but you're getting a message saying that an object lacks material (nevermind that this should be handled by the default material mechanism, were it to happen), then I'd have to say that either (a) the error message is incorrect, or (b) there is a bug in the engine which allows a material to become unassigned through some unknown sequence of events.

_________________
Next Limit Team

JD, can you explain the difference between the various new Auto focusing options (Spot, Average, and Average + DOF)?

-Brodie

Spot samples a single point in the center of the image. Average samples the image center, plus two ellipses, 1/5 and 1/2 the viewport width/height (I use 6 and 8 sample points around these ellipses -- ray testing the model can be pretty expensive); it then sets the focal point at the average of the distances found. Average + DOF does the same as Average, but it also adjusts your fStop (and shutter, to maintain your chosen EV) such that all objects within the sampled range are brought into focus.

_________________
Next Limit Team

Wow, pretty amazing. I really like the Average + DOF option

-Brodie

Here's a screen dump of the FIRE-error (which I can't reproduce):


And the strange behavior in the Materials-tab where a material can loose it's settings.
Here's an example of an emitter that looks a bit strange (I can't reproduce this either):


Finally a small issue concerning the Save Image dialog in the Fire-window where no file formats are listed in the drop-down menu:


/Stefan

Thanks Stefan, I have not yet found the sequence of steps to reproduce your first two issues. On the last, that is a limitation of the SketchUp Ruby save file dialog; you will have to type in the extension, which I will check for validity afterward. Perhaps in the future I'll also write custom save file dialogs, as with the open file dialogs when using the Custom file browsers option, but I haven't done so yet.

_________________
Next Limit Team

Stefan, on the first issue (triangles with no material), what are the chances that the problem could be related to one of the following:

1. an invalid MXM file is specified in Output > Materials.
2. no valid default.mxm is able to be found in the Maxwell mxm files directory.

I believe the engine is supposed to substitute its own in-memory default material if the default mxm is not found, but it doesn't appear to be doing so in my testing here. I don't know how likely it is that your issue would be related to this; probably not very.

_________________
Next Limit Team

Not long time ago I asked you how to control the "default" material. I followed the description in your reply, and might have played a little with these settings in the file that brings up the error message. If the issue will appear because of a broken link or invalid MXM, you might actually have found the needle in the hay stack
If I encounter the error again, I'll check the "default" material settings and let you know!
/Stefan