Windows 7 x64
Blender 2.65 official release.
I was trying to do a fairly simple Cinema4D task in Blender. This motion task is to reveal a shape over time along a curve.
The recipe I am using is...
1.) Make a mesh shape.
2.) Add array modifier and up the count.
3.) Create a BezierCircle object.
4.) Add a curve modifier to the mesh shape and pick the BezierCicle as the curve.
At this point I can animate the array count and coarsely reveal the shape over time, simulating an extrusion along a curve.
My next thought was to create several of these revealing rings and offset them in Z-Space. So I duplicated the first one and moved it up a bit. At this point the two rings were 'synchornized'. I wanted to rotate the second copy so I could offset the gap in the revealing rings.
That is when I realized that the rotation I was applying to the object was being relayed to the array copies and thus offsetting them in space based upon the Z-Rotation I applied.
Ok, so that does not work and I reset the rotation back to zero. But not to be defeated I thought, Aha! I'll just add that array/curve object to a group then use an Empty to deploy the group into the scene. So I moved the array/curve object to an unused layer and added it to a group. I went back to layer #1 and added an Empty and turned on dupligroup for that group name.
>>It seems like the rotation of the Empty is being relayed to the underlying array modifier, and it shouldn't. The rotation of the Empty should be applied to the resulting mesh from the group.
Give it a try, download the BLEND file and rotate the green object along the Z-Axis. You will see that it works fine in the viewport and even OpenGL render, but when you press F12, Blender Internal and Cycles get this wrong and render it incorrectly. (Mitsuba Gets It Right)
It seems like a bug (order of operation), but does anyone else have any insights on how to resolve this render error?
Related: BlenderArtists thread:
- To Do
The workaround is to add circle_race_track-1 to the soft_square group, then it renders the same as viewport. This is more a depsgraph / dupli issue than a modifier issue.
I guess this is a limitation of the system, don't think there is a quick fix. The modifier for the dupli object gets evaluated while it has the dupli transform applied, while the object that it depends on, circle_race_track-1 is left in its original location. If you want a dupli object that is a perfect copy of the original, then it should be evaluated in its original location. If you want it to be affected by other objects in its new location (e.g. collision for a character group with proxy), then it should be evaluated in the dupli location.
Added this to the depsgraph todo list now, it's a known limitation of the system that we need to tackle as part of the depsgraph project: