There were two issues:
- Line visibility computations are very slow in the case of the provided .blend file, which gave
an impression that the rendering process got stuck. The slowness can be explained by the present
data structures used for the line visibility computations, together with the specific mesh distribution
of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system
to divide tris/quads into small groups in order to accelerate the line visibility computations.
On the other hand, the test scene is populated a big plane (made of one quad) and a moderately
detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to
about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the
tris concentrate in one grid cell, so essentially there is no performance gain from the grid data
structure optimized for speed. It looks like a better grid data structure (possibly based on
adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now
the progress bar of Blender is employed to better inform users of the amount of work done in the line
visibility computations.
- A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid
data structure are determined based on the average area of mesh faces in the given scene. When the big
plane in the test scene is excluded from the rendering, the average area is almost zero (on the order
of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very
large number, causing a fatal memory allocation error. The present revision has introduced a hard
upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
- creating faces was unnecessarily checking if they already existed.
- deleting a face did edge-lookups, when the edges are already available from the face-loops.
with mouse crashes blender.
Issue here is that paint operator invocation, immediately calls modal,
which checks if event is the same as initialization event plus keyup.
Since using the mouse on amenu calls the operator on mouse button up,
the operator ended immediately and that cause immediate cleanup and
crash,
Worked around this by forbidding the operator to finish on first modal
call (which is expected by all the asserts on invoke anyway). This
prevents the crash but requires an extra up event to end.
Also, ported part of Jason Wilkins' patch to stroke code to allow for
stroke sampling to be done before a dab is first performed and as soon
as the stroke begins
Such mapping only worked foe compositor output node
(with some issues btw) and failed dramatically for
nodes like previews and viewers.
For now let's behave the same way as border+crop
worked in 2.66 for until proper feature support
is ready (which could take some time).
Fixes#35313: object and ID anti-aliased masks get messed up
when using border render + crop
* Also do pressure interpolation for brush size and spacing.
* Do smoothing of pressure when smooth stroke and sample average is enabled.
* Revert the OS X specific pressure change to pressure ^ 2.5, for low pressure
values like 0.05 it makes the pressure 100x lower, which is problematic. If
we need to adjust the pressure curve it should be done for all platforms.
Still weak:
* Pressure of first touch on tablet is difficult to control, usually it's low
which makes the stroke start out small or soft, but other times not. Finer
event capturing at ghost level would help, along with pressure changes without
mouse movement, but this may also need different paint stroke logic.
* Brush radius is rounded to integers, this gives noticeable stepping.
* Brush falloff is not antialiased, gives noticeable aliasing for small brush
sizes which was always a problem, but is more common with size pressure control.
On file save the mesh gets loads from the editmesh but the derived mesh caches
wer not cleared. This usually happens through the depsgraph but it needs to be
done manually here. Most changes are some refactoring to deduplicate derived
mesh freeing code.
* Fix crash on 2d painting when no active object is present (NULL
pointer dereference in cursor drawing)
* Skip conditional on space_stroke function, since this is already
checked for on higher level.
* Interpolate pressure on spaced strokes.
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.
