[kami]

I get this message

I can click on anything I like but the window always comes back.

This usually means I have to kill rhino manually and lose my not saved file.
Is there any way to avoid this? To just close Fire? Or that Fire will automatically close if it hangs for some time.

cheers,
christoph

[JDHill]

If you see that, it can mean one of two things:

1. the engine is taking a long time to do something.
2. the engine has locked up, due to an internal problem.

In the first case, when you stop the render, or change a material, or similar, the plugin has to ask the engine to stop, wait for that to happen, then if necessary, apply the update and tell it to start up again (we can't change the data it's rendering, while it is rendering). If the scene is complex, or if you are at a high SL, it can take some time for the engine to stop, and Windows might think we're stuck, and show you that dialog.

In the second case, you have made a change in the scene which has triggered some bug in the engine, where one part of the code is waiting for another part, while the second part is also waiting for the first -- this sort of scenario is known as a deadlock, and has no end, so you will see this dialog forever, until the application is shut down.

The plugin has no way of knowing which is the case, or even that either situation is happening, and if it did, it would have no way of coping, since the engine is in a state where it is not able to accept commands. So if you have a scenario where this is repeatable, it will be good to know that, because if it falls in the second class, there is an internal problem that we need to address, but to address it, we need to know what is triggering it.

[polynurb]

i get this a lot , too.
most times in combination with displacement.

sometimes, and depending on the system, it can take 1-2 min until rhino responds again.
so clicking anything in the dialog has no effect for that time and once fire recovered "retry" works and rhino doen't crash.

once in a while there is no hope though, and rhino will be stuck, so generally this "recovery" period seems to be a sensitive process.

[JDHill]

Exactly -- sometimes, the engine is just taking a long time to do something, while other times, it is truly locked up and will never resume. Unfortunately, I have no way of determining which is the case. Regarding displacement, you may be aware that there is an issue in 2.6.0 with the new pretesselated displacement: the engine actually replaces the original geometry, in memory, with the pretesselated geometry. When you then change a value in the displacement parameters, the engine tries to tesselate the pretesselated geometry again, so you go 2 tris > 2000 tris > 2000000 tris > and so on. To overcome this, you have to unload Fire data from memory (in the material editor, this is done when the preview scene is switched). So, while you can use it (pretesselated disp), I would personally avoid it for the time being.

[polynurb]

thanks for the info!
i am seeing that behaviour since 2.5 though.

also it feels a bit as if fire takes longer to stop a displacement render than external maxwellrender?

eg. i render a complex scene with higher displacement settings, but small resolution (no big mxi written) it still takes very long to stop in fire.

i will try to do some testing later this week.

[JDHill]

They are two different engines, which have to work in very different ways, so it's possible -- I haven't specifically noticed or measured this, though.