Fix T39136: DupliFaces: Inconsistent handling of group member types
authorSergey Sharybin <sergey.vfx@gmail.com>
Tue, 18 Mar 2014 12:05:59 +0000 (18:05 +0600)
committerSergey Sharybin <sergey.vfx@gmail.com>
Tue, 18 Mar 2014 12:15:02 +0000 (18:15 +0600)
commita6e347177bb61ce3d6e5657c1dfbd6ffa7663c55
tree3592708ccf1885b9a3a24490aed10615e3417133
parent5ff0500593021f42ef9e9945f6168321b340ba9b
Fix T39136: DupliFaces: Inconsistent handling of group member types

The issue was caused by assumption object matricies can be modified
by DupliObject->obmat outside of the duplilist iteration cycle.

This isn't really true. The thing is, old code used to modify object
matrix based on the duplicated matrix to make it so modifier evaluation
kind of works (it'll use proper matrix in most cases, but think there
might be some cases when this assumption also breaks).

Even when matrix is copied from dupliobject to object in advance
(to mimic old behavior or dupli system) you're still to use matrix
from dupliobject inside a cycle body. This is because the same object
might be modified multiple times by different dupliobject. For example,
in case of duplifaces loads of faces will modify object's matrix and
before this change matrix from the last face would have been used.

The fix is simple one-liner which makes it so render instance will
use proper matrix from dupliobject.

All the rest bits here (pre-loading matrices and restoring them in
the reverse order) totally matches old behavior of duplilist.

This is a regression and to be ported to 2.70 tag!
source/blender/render/intern/source/convertblender.c