Votes
11
Product:
iClone 6
Version:
6.42
Status:
Active
Issue 462
Make Indigo multi-frame export more efficient by using a single copy of things that don't change
INTRODUCTION:
This is relevant when doing multi-frame Indigo exports for animation. It does not impact single-frame exports.
I have written about this numerous times in the forum, such as in this thread:
http://forum.reallusion.com/282542/Indigo-plugin-future#bm282554

WHAT IS WRONG:
iClone writes out the *full* scene for each and *every frame*. ALL the meshes and ALL the textures. Everything, for each and every frame.

WHY THAT IS WRONG:
Indigo files can easily accommodate a "shared" folder for things that don't change. So something like the terrain or a building should only be exported once. That would greatly increase the export speed and greatly reduce the disk space requirements.

Even if something changed once every second, you could easily write the mesh and textures once (for that second), and reference them for 30 frames, instead of exporting 30 copies of the same thing. Then write out (and reference) a new set of files only when you need to.

It should be easy to know if an asset is unchanged between frames, and the Indigo file could just point to the mesh and/or texture files that have already been written. That check should be much faster than the exporting process (no "conversion" and it avoids the file write times), and it doesn't fill your disk drive with dozens and dozens of copies of the same, large files.

IMPACT:
Today we have the triple-penalty of:
a) Ridiculously long export times
b) Filling your disk with gigabytes of unnecessary files
c) Long rendering times (not Reallsion's fault)

This change has the potential to drastically improve on two of the three issues when exporting an Indigo animation sequence.

GOING A STEP FURTHER:
For maximum improvement, static meshes that move (but don't deformed) could also use the same mesh file. For example, a moving prop like a door that opens. The "transform" can be written into the Indigo file, and you could still use a single copy of the mesh.

Also keep in mind that changes to the mesh and changes to the texture are independent. An constant-shaped object with an animated texture needs only one mesh file, while a deforming mesh with static textures (like an avatar or clothing) would need only one set of texture files.

CLOSING:
I've hand-edited Indigo files and proven this to be true, so this is not theory, it works.
OS: Windows 7
  •  2
  •  3589
SuggestionPlug-inGeneral
Submitted byjustaviking
1
COMMENTS (2)
pmaina 
This approach is needed no matter what render plugin is used.

Even if this is sorted, the problems inherent in Indigo technology will prevail.

Unbiased renderers are great for stills and architecture work but when it come to animation it's better and smarter to use a biased renderer. Hoping RL will give us best of both worlds.
animagic 
The inefficiency of this approach has actually been pointed out very early on and since then discussed by various users on the forum. Sharing data as Viking suggests would at least assist in making the plugin more useable.

Render times are the nature of this kind of rendering approach, so we can only hope for further improvements on the part of Indigo. 

I will see if I can free up a vote...
1