Hi,

I render a sequence for nothing(empty scene). But it is still slow(5-6 seconds per frame). The render is for a sequence. Mantra should not need to cold initialize for every frame. The CPU's usage is always below 10%.
What's the reason? Is it because of the windows 10 system?

Well mantra doesn't know that it should deliver a black image.
Whenn there is a camera and light in the scene it will try hard to create a masterpeace of a image. Even when it is a black image

mandrake0
Well mantra doesn't know that it should deliver a black image.
Whenn there is a camera and light in the scene it will try hard to create a masterpeace of a image. Even when it is a black image

But…. how much calculation is needed for the simple scene. It seemed that mantra is always waiting for something.

Mantra is a pretty old render compair to newer renderer.
Mantra is EOL in terms of development this problem will be solved with karma but currently in beta.

When you know there won't be anything to render you can use attributes, frame range….

You also can use HQueue and send the render job to your computers.

jerry7
Hi,

I render a sequence for nothing(empty scene). But it is still slow(5-6 seconds per frame). The render is for a sequence. Mantra should not need to cold initialize for every frame. The CPU's usage is always below 10%.
What's the reason? Is it because of the windows 10 system?

Mantra cannot be used to render a sequence, that's why it has to start cold for each frame. Most of the time when mantra is used it only renders a single frame, with each frame spread out over the many computers of a renderfarm, so the start time doesn't matter that much. The overhead of starting is also very small compared to typical render times which are usually more than a few minutes.

The next generation lighting and lookdev engine solaris is more suited to rendering sequences, as the command for translating usd to the renderer, husk, is capable of accepting sequences of frames to batch eliminating much of the overhead. Some renderers will still obviously have overhead for starting and stopping, but it should be less than a cold starting executable.

Checking that there's no renderable geometry and outputting a black frame as an optimization is not hard. First there needs to be no render-time displacement or subdivision, and then you'd check that no geometry falls within the camera frustum. However this is so rarely useful that rendering engines simply don't do it to avoid the overhead. Instead the renderer immediately spins up a few threads, tiles up the image and feeds each thread a tile to chew on until all the tiles are done. If there's nothing to render, the overhead of dispatching and gathering ends up being the bulk of the work done. On my setup, Karma spins for a few seconds whenever I change the camera angle, even for a completely empty scene.

I have tested karma with a static empty scene. It still needs 70 seconds for 10 frames.
Because karma can second render in viewport, I guess it is husk or some other translation process that eats the time.

jerry7
I have tested karma with a static empty scene. It still needs 70 seconds for 10 frames.
Because karma can second render in viewport, I guess it is husk or some other translation process that eats the time.

Rendering from the usdrender rop still starts a separate process for each frame. Running husk from the command line should allow batching all of the frames in one process.

Even when running a separate process for each frame, it only take 30 seconds to render out 10 empty frames for me.

Edit:
There's a checkbox on the usdrender node to render all the frames in one husk process. When enabling it, 10 blank frames render in 4 seconds for me.