Ramdisk

[john]

Following is based on my programming observations not facts about specific script so I might be wrong somewhere.

Obj is a text file. Text operations are much, much slower in general comparing to numerical or direct memory processing. The fact that these operations are carried through script multiplies the slowdown. The bottleneck is huge volume of processor-ram operations before the thing gets to actual saving. Being hard-coded as library or part of program a minute export could be done in seconds on single core, but should also require noticeably more time in programming.
Personally I'd like to see area lights and many other things first
Again, I'm not familiar with blender architecture so there might be something else.

My post above was meant less as a gripe and more to dissuade anyone from investing time or money in researching and setting up the ramdisk. The lights, MLT, material presets and everything else should definitely come first. Thanks for the info.

[radiance]

hi,

the whole ramdisk conversation is a forum-user thing, we don't have any plans to include that (and how could we?!) with octane.

Radiance

[john]

hi,

the whole ramdisk conversation is a forum-user thing, we don't have any plans to include that (and how could we?!) with octane.

Radiance

Of course -understood. I meant that the features you're planning on introducing with 2.3 should be implemented before the slow mesh export is addressed. Obviously, a ramdisk program is a different product altogether. In any case, setting up a ramdisk didn't accelerate mesh export/import on my system.