[choo-chee]

I have this question since FIRE was introduced:
as it appears (I use v2 but testing v3), some scenes render FASTER with the rs1 while in simple cases only FIRE is faster.
emitters, displacements, complex models - it's better to render rs1 at something like 2000X1500 and wait for 1-2 minuets than take a chance with FIRE
that may crash your host app and will give you poor results at more time.... why is that ?

[JDHill]

Let's consider a job you might do; there will be a design phase, and there will be an execution phase. During design, the project may be altered in any way, and you need to provide images giving a feel for the effect of the changes. During execution, nothing may be changed, and you are basically required to provide different views of the approved model.

It is pretty clear that to be successful, you need to adopt a different strategy for each phase. During the design, you should not waste too much time with being really organized, since it's so likely that work will be thrown away. What you need here is to be as responsive as possible. It is exactly the opposite during execution: time spent up front, making sure things are built in an organized fashion, will have a definite payoff, in the long run.

The point being: efficiency has very different meanings, depending on the context, and it is the same with the two engines.

The most important thing for Maxwell FIRE is that it be able to stop instantly, change various aspects of the scene, and then provide a view of the altered model, as quickly as possible. It cannot afford to waste time organizing things for long-term efficiency, since it is so likely that work would just end up being thrown away a couple of seconds later. And when it renders, it should produce an image with as much useful visual information as possible, as soon as possible.

Maxwell Render, on the other hand, has the luxury of knowing that the design phase is over, that time invested in organizing data is not likely to be wasted, and that it is okay if the first few updates are slower-coming, and less complete, relatively speaking. And unlike Maxwell FIRE, it does not need to constantly check whether you want it to stop, and start over (which is very expensive, in terms of CPU usage). Where, for Maxwell FIRE, performance means instantaneous performance, for Maxwell Render, it means overall performance.

Therefore, to be efficient with Maxwell, you should no more use Maxwell FIRE for final images, than you would use a scratch model after the design phase, and vice versa. It is primarily useful as a design tool, not as a render engine, because it's not designed to be efficient in that capacity -- and if it were, it would be incapable of serving its intended purpose. The problem is that because Maxwell FIRE does provide a relatively complete image so quickly, I think people often assume it to be the faster engine, when in practice, it almost never is.

[choo-chee]

Therefore, to be efficient with Maxwell, you should no more use Maxwell FIRE for final images, than you would use a scratch model after the design phase, and vice versa. It is primarily useful as a design tool, not as a render engine, because it's not designed to be efficient in that capacity -- and if it were, it would be incapable of serving its intended purpose. The problem is that because Maxwell FIRE does provide a relatively complete image so quickly, I think people often assume it to be the faster engine, when in practice, it almost never is.

that's not what I meant.
say I want to test an emitter inside a building. FIRE shows a whole lot of noisy mess and gives no idea about the way it will actually render, even if I wait. however waiting a couple of minutes with rs1 will give me noisy yet articulate impression of the final render... I don't get it. it's like FIRE cannot show things good enough unless they are typical materials and geometry..

[eric nixon]

I think its pretty obvious that FIRE provides the ability to position your lighting or camera angle interactively.

And within MXED it gives the fastest interactive material feedback. So its a really useful thing, no?

[choo-chee]

I think its pretty obvious that FIRE provides the ability to position your lighting or camera angle interactively.

And within MXED it gives the fastest interactive material feedback. So its a really useful thing, no?

very useful. I just want to understand it better... had it crashing so many times that I modified my toolbar "fire" button with a script of "save scene than fire"...

[dariolanza]

Hello choo-chee,

In the example you describe, you are getting more noise in FIRE because actually FIRE doesn't work internally identically to Maxwell.

To gain interactivity and responsibility, FIRE delays certain calculations (in particular the caustics and secondary calculations) to later, as they are harder to solve and usually not the kind of elements the user focus in during the design phase. IOn the other hand, Maxwell doesn't delay anything, calculating those caustics and secondary illumination from the very beginning as the rest of the image.

You can perform this test: find a scene with a patent caustic and launch it with Fire. As it will delay the caustic to later, you will get the caustic as small dots slowly appearing, while in Maxwell it will appear completely from the first seconds.
FIRE will converge to the same solution, but the caustic calculations will come after the rest.
This is a case where FIRE may take longer to clean a caustic than Maxwell itself. On the other hand, this "feature delay" in FIRE will provide you the ability to alter the lighting, materials, camera, etc without extra cost.

I hope this helps you to understand the different functionality of both engines.

Dario Lanza

[choo-chee]

thanx dario now I get it.
btw I think that using your maxwell's avatar can be a very good icon for the program itself