User avatar
By greengreen
#389800
Fire in Rhino gets stuck if I try to stop Fire or close the Fire window. It gets stuck with this "Server Busy" pop-up, and if I click "Switch To..." or "Retry", it will go back to the same pop-up for a long time. I finally was able to hit the 'retry' button after several minutes.

Image
By JDHill
#389801
When this occurs, it means we are waiting for the render engine to finish doing whatever it is doing, so its appearance will usually be related to the use of very large amounts of memory (pretesselated displacement, etc), extremely-high numbers of instances (e.g. MXS references referencing MXS files with instances), and so forth -- anything that causes the render engine to do a lot of bookkeeping during startup & shutdown of rendering.
User avatar
By greengreen
#389814
Should I be clicking the "retry" button? Is it still stopping the render when the "server busy" pop-up is up? Currently I have been waiting for fire to stop for about 25 minutes and I don't know if it is still working in the background with the pop-up. If I click 'Retry', the pop-up immediately appears again.

Instead of stopping my work for a very long time, it would be nice to be able to force stop fire faster. Currently it is a faster workflow to save before using Fire, and if I have this issue, which I do often, I force quit Rhino and re-open to where I was before I tried Fire.

Currently, I don't know how much longer it will take and I didn't save before using Fire, so I might lose work
By JDHill
#389815
It is not possible to forcibly stop the rendering process without compromising the integrity of the entire process (meaning, Rhino.exe). Doing so would be worse than killing Rhino without saving, since if you were to save with memory corrupted, you could end up with a corrupt file, rather than just one that was missing the latest changes.

If I was routinely running into this, I'd try to find the reason why; as I wrote above, I'd probably look at the use of displacement first, by disabling Scene Manager > Output > Export > Displacement before starting FIRE. Other things I might look at would be the use of extremely large textures (e.g. HDRs used in IBL), and/or the use of render-time subdivision (i.e. Rhino Obj Props > Maxwell > Modification > Subdivision).

If you send me a file that shows this behavior, I can give you more precise direction.
User avatar
By greengreen
#389816
Ok, thanks, I just force quit. If I render the scene fully, I don't get any issues. It's just Fire.

I do have a large texture and a large surface with scatter on it. I just will turn these off when I use FIRE
By kami
#389953
I'm also having these problems with fire that you get stuck with the "Switch to ... " or "Retry" window with large or complex scenes. But in 90% of the case, after a few minutes, hitting the retry-button helps. Sometimes you have to kill the process.
Unfortunately you sometimes also have to wait, if you just hit stop on the fire window to wait until it stops. I'm used to save every time before I launch fire because of that.
User avatar
By greengreen
#390893
Fire in Rhino is not respecting objects that are hidden.

Makes it difficult to use Fire if I can't hide the problematic objects
By JDHill
#390894
Please provide a more detailed description of the scenario, because FIRE in the plugin definitely does respect the hiding of objects. Just for example, draw plane and a cube, start FIRE, select the cube and type Hide in the command line; the cube will disappear. Then, type Undo, and it will re-appear. Alternatively, you could select the cube, go to Object Properties > Maxwell, and check the Hide box; the cube will disappear, and re-appear if you then un-check it. It will work similarly, if you go to the Layers window and hide/unhide the cube's layer (you'll get an error if both the plane and the cube are on that layer, and there are no other objects in the scene).

So please let me know exactly what you are doing, in order to allow me to observe it here.
Will there be a Maxwell Render 6 ?

Let's be realistic. What's left of NL is only milk[…]