Previously it was nearly impossible to have fast moving objects emitting smoke or they would just leave behind a row of smoke poofs instead of continious stream of smoke. Now it's possible to set number of subframes for each smoke flow.
Another new thing is ability to set size of smoke flow particles instead of using closest smoke cell. This also works with my earlier "full sample" commit, so no more blocky particles either. :)
For more info check my blog post: http://www.miikahweb.com/en/blog/2013/05/17/blender-smoke-subframes
This commit also includes couple of fixes I spotted while testing:
* Fix: dissolve was applied at different time for low res and high res simulations.
* Fix: full sample setting didn't get copied with domain.
- reverted fix for bug 32537 (error report drawing after thread job didn't show)
This solves very bad 3d view render updates while using transform, it was
getting into an eternal feedback loop for dependencies. (jobs sending mousemoves
causing jobs to end, causing mousemoves, causing etc).
- The render-update code was not going over all windows, but over every screen to
send signals (also the invisble ones)
Shapekey drivers were executed for every call to derivedmesh, which shouldn't happen.
It now only runs on the object_update() function, once for every depsgraph change.
Error was found while testing preview render in viewport. On each render, the
animsys sent a 'changed data' because of the shapekey drivers being called,
causing eternal re-render loops (without showing anything).
Issue was caused by file output node actually,
The thing here is, compositor output does have fixed
resolution and we could predict how to map coordinates
for border and cropping in that case.
But viewers and file output nodes are currently totally
depending on an input resolution. Could not see how
border could be applied reliably in this cases.
Disabling border option for file output node, so
now it shall behave the same way as it was before.
Discovered issues when using cropping to render border,
namely there's an offset in viewer nodes and previews,
but this is separate issue i guess (file output seems
to work fine). Will revisit this issue in next days.
Added incremental re-render on view changes. That means all data preprocessing
only needs to be done once on view changes, quite faster that way.
Also fixed a bug in raytracing strands with soft shadows, was wrongly changing
coordinates in a static array.
Note: proper signals for re-renders is still on the todo. Many button options
don't signal a re-render yet. Work around: press G+ESC for quick full renders.
So now, in the new "other" tex context, you can (depending on active data) have direct access to modifiers', force's or brushes' textures...
I also refactored a bit how texture contexts are handled (once again, we had some quite similar code in both space_buttons and RNA sources). This should also solve some harmless glitches like "no texture context selected in UI" sometimes when you remove data related to current texture (see e.g. after removing the material from default cube, in startup scene).
This usage of two different systems for textures, and the handling of switches between them, has been a bit tricky to get working right, but it is OK now I think. I also had to add a bool flag to buttons space, SB_TEX_USER_LIMITED (use_limited_texture_context in RNA), which indicates "new shading" texture code whether it has to ignore materials, lamps etc. (BI) or not (Cycles).
Btw, pinned textures from modifiers/force/etc. were also broken (showing nothing), now it should work too.
Thanks to Brecht for reviewing.
Suitable for inclusion in 2.67a.
Logical AND, OR and XOR operations on freestyle.Nature instances gave an error in some cases.
The updated C implementation of these bitwise operations is intended to reproduce the following Python implementation:
class Nature(int):
def __and__(self, other):
return Nature(int(self) & int(other))
def __or__(self, other):
return Nature(int(self) | int(other))
def __xor__(self, other):
return Nature(int(self) ^ int(other))
The problem report was by plasmasolutions on IRC, thanks a lot!
The issue here was that the "active" material node depends on the editor context. Previously (< 2.67) there was only 1 edited node group possible globally throughout Blender, so the active material in the context could be resolved more easily. The solution now involves the active_viewer_key variable (first introduced for compositor viewer nodes in r56271, naming is a bit awkward but hard to change in DNA). This key defines the "last modified" node tree to resolve ambiguity of active context items. For single editors the result is the same as in 2.66, if multiple editors are used with different node groups the last modified tree is used.
SpatialNoiseShader, as well as SmoothingShader were not updating stroke length after
geometry modification, causing an infinite loop in Stroke::Resample(int iNPoints) due to
incorrect length-based resampling of stroke vertices.
* Editing number of segments for particle hair did not update the viewport.
* Hidden particles were confusing, the paths were drawn but without the points.
Now it draws the path faded to indicate that they are hidden/locked.
* Select tips/roots operators now have options to select/deselect/toggle/invert.
take up a lot of memory.
The operator was recording an array with all stroke points. However this was not
particularly useful, only sculpt mode had exec() implemented to redo the stroke,
but it was not registering the operator anyway so there was no way to access the
data after the operator was done. So no one was using this anyway.
I did now implement exec for the paint modes so you can call the operator with
stroke points from a script.
Partial redraw doesn't work so well with these, now I've changed the action
zones to just draw as part of regions instead of as a special overdraw done
at the end, which fits better with partial redraw by avoiding any special
exceptions.
* Particles did not render at viewport resolution like meshes.
* Properties editor preview render of hair was crashing, solution is to have
two separate flags for this preview render and viewport preview render.
After the paint refactoring for 2.67, the OpenGL texture was getting updated for
every stroke point, rather than once for every redraw. With a small brush radius
and low spacing the number of stroke points can be quite large, which might have
a big performance impact depending on the graphics card / drivers.
Also for 2D image paint, avoid redrawing the button panels and properties editor
during painting.
There is another possible cause for slowdowns with 3D texture painting which was
not fixed. Projection painting is creating and destroying threads for every stroke
point. Depending on the CPU/OS there might be a lot of overhead in doing that if
the brush size is small.
down, this time by the operator properties getting converted to a string for
display in the info window.
With 1000+ stroke points this can get slow, and takes up too much space anyway,
so now it's (somewhat arbitrarily) limited to printing only 10 points.
Textured dyntopo draw was leaving 2d textures enabled when it shouldn't.
Root of the issue was figured out by Campbell, actual place where
2D textures left enabled found by self.
Also, simplified fix is suggested by Campbell (mine was 2 lines longer! :)
Switching to tool will cycle via all brushes with given type
only in case current brush tool matches requested one.
This means, when user requests brush with different type,
first brush of that tool will be activated. But further
toggling to the same tool will cycle via all acceptable
brushes.
This functios are declared in BKE_paint.h header and using
SculptSession structure which is also declared there.
Anyway, does not make sense such a splitting of header and
implementation files, better be consistent here.
Made it so dynamic topology will flush changes from
SculptSession->bm to Object->me.
Used the same approach as sculptsession_bm_to_me does,
but instead of using DAG_id_tag_update used in-place
DerivedMesh release. Otherwise this lead to some
update issues resulting in missed object after render.
Also fixed multires modifier not being applied for
render when rendering from dyntopo sculpt mode.
P.S. Apparently sculpsession_bm_to_me was declared
in BKE_paint.h but implemented in object.c.
Rather confusing and better make it so this
functions are declared and implemented in
consistent files. But will solve this in a
separate commit.
* Removing KX_Scene::RemoveAnimatedObject() since KX_Scene::NewRemoveObject() is already handling this.
* Don't create a new BL_ActionManager when replicating an object. Just set m_actionManager to NULL and let KX_GameObject::GetActionManager() allocate a new BL_ActionManager when one is needed.
* Use KX_GameObject::GetScene() instead of KX_GetActiveScene() in KX_GameObject::GetActionManager() to make sure we're using the object's scene instead of one where Python might currently be running from. This could avoid potential issues with playing actions for objects in other scenes.