Export speed

[livuxman]

What I have implemented is simple, and we must bear in mind that the plugin in blender 2.5 is called for each frame of animation.
Initially exported normally, once exported, is called octane and begins to export the next frame and adding the frame number to the filename. When octane has finished rendering, the image is collected and added to the animation.
The process is repeated again with the next frame, but as it was exported in the previous step, instead of exporting it again, when detected that the file already exists with the frame number on the filename, this is renamed to the usual name and call octane. The process is repeated, exporting the next frame while rendering.

Cheers

[ROUBAL]

Exporting one frame while rendering the previous one only makes sense if rendering time is superior or equal to the exporting time, but in the animations I tried to render so far, the rendering time was around 1 minute and the exporting time whas around 2 to 3 minutes, so it wouldn't be functionnal, as Octane couldn't be rendering frame 10 when only exporting frame 3 !

And of course, increasing uselessly the rendering time to keep it longer than the rendering time would be a big waste of time ! It would be worse than the curren system.

[livuxman]

Yourself

In the event that the render time is less than the export, the result is the same, use the cpu time to export while doing the rendering on gpu, which would otherwise be wasted. If the export time is 3 minutes and the rendering is 1, would be as if time to export was 2 minutes (3 minutes CPU currently used at least 1 minute of unused cpu while rendering).

[radiance]

There really is'nt much we can do about this right now, the OBJ exporter in blender is python code, which is interpreted, not compiled, so it's slow,
especially when running large datasets through it.

I'm hoping the new blender 2.5 API will make things easier for us in the near future to add a C or C++ based mesh export kernel or other integration without files.
Either that, or, if you just want to render walkthroughs, a simple keyframing system and time bar in octane will appear not too long in the near future.

Radiance

[kivig]

There really is'nt much we can do about this right now, the OBJ exporter in blender is python code, which is interpreted, not compiled, so it's slow,
especially when running large datasets through it.

I'm hoping the new blender 2.5 API will make things easier for us in the near future to add a C or C++ based mesh export kernel or other integration without files.
Either that, or, if you just want to render walkthroughs, a simple keyframing system and time bar in octane will appear not too long in the near future.

Radiance

I guess someone from blender developer forums could give a good advice on this.

So far seen solutions (for v-ray for instance) include a custom blender build/patch with integrated needed functions.
Maybe later that patch could be included in blender by default.

[enricocerica]

See that post
http://www.refractivesoftware.com/forum ... 469#p32469

[ROUBAL]

A big thank you for this link !

I have done some trials on my current heavy scene, and I have divided my exporting time by 3 !

From 3 minutes to 58 seconds !

As Blender works better with quads, and as most other 3D softwares use triangles, I thought that tringulation was necessary. And as I wanted to get the best possible quality for my images, I never thought of disabling these features !

Even if an exporter built in Blender would probably be faster than a Python script,

It is a great improvement, and a happy day !

Thanks again !