Blender Git Statistics -> Branches -> cycles_memory

"Cycles_memory" branch

Total commits : 4
Total committers : 2
First Commit : February 26, 2015
Latest Commit : February 27, 2015

Commits by Date

DateNumber of Commits
February 27, 20152
February 26, 20152


AuthorNumber of Commits
Sergey Sharybin3
Antonis Ryakiotakis1

Popular Files

FilenameTotal Edits

Latest commits Feed

February 27, 2015, 14:06 (GMT)
Fix blenderplayer
February 27, 2015, 11:27 (GMT)
Add argument to DM_to_mesh() function to take ownership over the DM

The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the

This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion

Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.

Reviewers: campbellbarton

Differential Revision:
February 26, 2015, 20:07 (GMT)
Add an option to mesh.calc_tessface() to get rid of polygons and loops

The purpose of this change is to add extra possibility to render engines and
export scripts to reduce peak memory footprint during their operation.

This new argument should be used with care since it'll leave mesh in not really
compatible with blender format, but it's ok to be used on temp meshes.

Unfortunately, it's hard to get scene where it'll show huge benefit because
in my tests with cycles peak memory is reached in MEM_printmemlist_stats().

However, in the file with sintel dragon it gives around 1gig of memory benefit
after removing the polys which would allow other heavy to compute stuff such as
hair (or even pointiness calculation) to not be a peak memory usage.

In any case, this change is nice to have IMO, and only means more parts of
scene export code should be optimized memory-wise.

Reviewers: campbellbarton

Differential Revision:
February 26, 2015, 20:01 (GMT)
Cycles: Free caches used by the synchronized objects

Issue this commit is addressed to is that particle system and particle modifier
will contain caches once derived mesh was requested and this cached data will
never be freed.

This could easily lead to unwanted memory peaks during synchronization stage
of rendering.

The idea is to have RNA function in object which would free caches which can't
be freed otherwise. This function is not intended to deal with derived final
since it might be used by other objects (for example by object with boolean

This cache freeing is only happening in the background rendering and locked
interface rendering.

From quick tests with victor file this change reduces peak memory usage by
command line rendering by around 6% (1780MB vs. 1883MB). For rendering from
the interface it's about 12% (1763MB vs. 1998MB).

Reviewers: campbellbarton, lukastoenne

Differential Revision:

MiikaHweb - Blender Git Statistics v1.06
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021