Issue was caused by size influence affecting on object's matrix, which
is nice by it's own. But mball code was using ob->size to check whether
it's zero-sized object or not, but then was using ob->obmat to scale
the meta elements.
This lead to situation when zero-sized elements were trying to tessellate,
which is for sure a really bad idea.
This mistake happens over and over, it's just not clear what the index arguments in these relink functions mean ... We really need to clean up that interface.
- puff was interpolating hair that made longer strands cirl up.
- also fixed problem with puff-volume option, it was over-accumulating so unselected parts of the hair would have too much offset applied.
draw mode. This happens because it uses node data structures in threads, now
it does same as preview render, which is to immediately stop the render thread
when e.g. deleting nodes.
Clipping start is negative when the viewport preview is used with the orthographic view,
while Freestyle assumes that imported mesh data are in the camera coordinate system
with the view point located at origin. The present solution is to adjust the clipping
start/end and introduce a Z-axis offset for mesh vertices so as to satisfy the assumption.
There's one thing we didn't foresee from the beginning,
which is apparently TLS is only available in OSX starting
from version 10.7, and we still do support of 10.6.
After recent Brecht's changes about locked viewport
while initializing BI render this TLS is not needed
in trunk anymore. So reverting this chunk of base
iteration to use static variable. But leaving all the
other static variables warped into context still, it
should help a bit in the future refactor.
Real fix would be to have some kind of graph context
evaluation structure which would be passing to update
routines (which will solve threaded mballs update) and
making depsgraph responsible for getting a motherball.
But this is all for GSoC project.
This time issue was caused by static variables used in
BKE_scene_base_iter_next function.
Change is not so much ultimate actually, but didn't
find more clear solution for now. So the changes are:
- Wrap almost all the static variables into own context-
like structure, which is owned by the callee function
and getting passed to the iteration function.
- Recursion detection wasn't possible with such approach,
so recursion detection still uses static in_next_object
variable, but which is now stored in thread local
storage (TLS, or thread variable if this names are more
clear for you).
This makes code thread-safe, but for sure final solution
shall be completely different. Ideally, dependency graph
shall be possible to answer on question "which object is
a motherball for this metaball". This will avoid iterating
via all the bases, objects and duplis just to get needed
motherball.
Further, metaball evaluation ideally will use the same
kind of depsgraph filtering, which will get result for
question like "which objects belongs to this group of
metaballs".
But this ideal things are to be solved in Joshua's and
mind GSoC projects.
Tested on linux (gcc and clang) and windows (msvc2008),
hopefully no compilation error will happen.
Thanks to Brecht for reviewing the change and getting
feedback for other possible ways we've dicussed!
the way Curve.len is used at the moment is really stupid, calculate string size on save for now, but should really store the length in bytes and total number of characters.
- calc normals only check flag when needed.
- keymap, dont get name unless its needed.
- keymap, avoid property lookup.
- idprop debug print, include pointer, helpful for troubleshooting.
RGB color components gave non-grey results when you might no expect it.
What happens is that some of the color channels are zero in the direct light
pass because their channel is zero in the color pass. The direct light pass is
defined as lighting divided by the color pass, and we can't divide by zero. We
do a division after all samples are added together to ensure that multiplication
in the compositor gives the exact combined pass even with antialiasing, DoF, ..
Found a simple tweak here, instead of setting such channels to zero it will set
it to the average of other non-zero color channels, which makes the results look
like the expected grey.
internal viewport rendering. Lots of tweaks here, mainly:
* Stop 3D viewport render and free database before undo.
* Accumulate update flags rather than replace them each time it rerenders, to
avoid previous updates getting lost.
* Don't check against Render struct view parameters for changes, those are set
in the job thread which might not run before the next update call.
Now the viewport rendering thread will lock the main thread while it is exporting
objects to render data. This is not ideal if you have big scenes that might block
the UI, but Cycles does the same, and it's fairly quick because the same evaluated
mesh can be used as for viewport drawing. It's the only way to get things stable
until the thread safe dependency graph is here.
This adds a mechanism to the job system for jobs to lock the main thread, using a
new 'ticket mutex lock' which is a mutex lock that gives priority to the first
thread that tries to lock the mutex.
Still to solve: undo/redo crashes.
becomes too small. Typically this would happen if the number of buckets
is clipped to the maximum value. This avoids thread overhead.
A better fix might be to do bucket-brush intersection on main thread and
dispatch threads to process bucket hits as they become available. This
way only one thread at most would end up being used in such cases
anyway. A better task scheduler is needed for that though, leaving for
after GSOC.
- normals depended on the meshes rotation, so you could rotate Suzzane and in some cases one of the eye normals would be flipped.
- normals depended on the meshes placement in relation to the meshes center, now find the outer most face by each face-island center.
The bugs were about not respecting edge smoothness and
not respecting edge crease. This change copies the
edge attributes from a beveled edge to the two outside
edges of the bevel.
custom pynodes tree edited directly as library data would get a 0 user count on reload and subsequently not be saved. Now the node space follows the same pattern as the image space: the node tree(s) user
count gets incremented on file load and opening in the editor ensures a real user. This leads to 1 "unreal" user for the editor (dropped on reload), but seems to be the only viable solution atm.
Issue goes back to 2.4x days at least (but very much likely the
issue is even older). It's caused by subdivision code was starting
to iterate points from previous one, which shifted all the points
by one.
Reshuffled code so now iteration starts from first spline point.
Thanks to Campbell for review and tests! :)
