In addition to D319, this patch updates the parameter editor, the UI of Freestyle.
Using new API functionality and experience gained in making D319, this patch
provides a quite noticable speedup for commonly-used Freestyle linestyle modifiers.
As this patch touches a lot of code (and mainly the foundations) it is likely that
mistakes are made. The patch has been tested with a regression suite for Freestyle
(https://github.com/folkertdev/freestyle-regression-tests/tree/master), but testing
with scenes used in production is very much appreciated.
Differential revision: https://developer.blender.org/D623
Author: flokkievids (Folkert de Vries)
Reviewed by: kjym3 (Tamito Kajiyama)
If the active image node contributes to the final material shader
(meaning it's either directly or indirectly connected to an Output Node)
the user will receive an alert about circular dependency.
Similar to what we do for Blender internal the baking will still happen,
but the user will receive the alert which should prevent the image
saving to happen if the result was not intentional.
Core function to check for node output written by Lukas Toenne.
Reviewers: lukastoenne, campbellbarton
Differential Revision: https://developer.blender.org/D673
This patch creates an interface for selection mechanisms in opengl. This
makes it possible to switch between occlusion query based or select
rendermode based selection transparently.
This is really useful on graphics drivers that do not accelerate the
select rendermode path (some ATI cards are notorious for this, and the
new path is used by default there), since occlusion queries are always
hardware accelerated due to their use in games.
The option can be found under system - selection. Auto just enables
occlusion queries for ATI users while the rest of the options enforce
one of the two methods always.
There is just one known change, previous code enforced nearest bone to
always get selected, even when mouse selecting near the same position, I
couldn't replicate the behaviour though.
patch by me with edits and review by Campbell.
Thanks!
We do have odd behaviors with name and expanded enums, but in this case it did
not made any sense at all! :)
Note the error was not in RNA, but in C UILayout api itself...
Rename UI_init_userdef_factory to BLO_update_defaults_userpref_blend
This closely matches BLO_update_defaults_startup_blend so makes sense for them to be together.
Previously the imported mesh data were transformed by a local-to-world projection matrix
through NodeTransform. Now that the file loader assumes the imported mesh data already
in the camera coordinate system, an indentity matrix was supplied to NodeTransform.
The present commit avoids this redundant matrix operation by using NodeGroup instead of
NodeTransform, recalling the latter is a subclass of the former with extra matrix computations.
The issue is actually that creating a new image in texture paint mode
will set it always as a stencil image. Internally, the code checks if
the painted image is the same as the stencil and if it is, no painting
is done.
Solution is to expose a boolena to the operator for setting the image as
a stencil (could be an enum in th future for more uses)
Stencil UI is a bit weird here, will definitely redesign.
We were copying everything from the old sequence into each new ones... including the stripdata,
which for image sequences is an array with one item per image!
So bug was an exponential one, separating strips of a few tens of images was insensible, while
separating a strip of 1000 images would add above 250MB to file size (and RAM usage too)!
The issue was caused by the wrong objects order for
convertblender.c. Dependency graph totally missed
handling of this situation.
Fixed now, but it's not that pretty, don't try this
at home obviously. But consider this to be good enough
for the current dependency graph.
Details are in the build_dag_object().
Commented out the 'no zero' protection of scaling transforms for numinput.
Issue is, once an axis has null scale, you can't regrow it from transform code
(you have to directly edit the scale property). This is not ideal, but getting
good behavior in this case is hairy...
Yet, when using numinput, you type precise values, so if you want to set it to zero,
set it to zero. User is assumed responsible, we should avoid too much 'invisible magic'
when handling precise inputs. ;)
Note: an idea for possible future feature would be to have an 'absolute' mode for numinput
(allowing to type in real value, not factors).
Calling `glLoadName()` was possible with '-1' value (65535 actually), in `draw_pose_bones()`...
Note I think bug exists since ages (at least, seems to be already present in 2008
when drawarmature.c was added in repo)!
Odd behavior reported (issue only affected objects once parented to the armature) was
due to ordering stuff, since only objects drawn *after* the armature were affected.
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
That's really annoying that multiplication order is flipped
comparing mat3 and mat4 cases, but for the purposes of not
breaking all the branches which might use this stuff we'd
better keep order consistent with old version for now.
Suggestion here would be to make order consistent but rename
this functions to mult_* to make compilation fail instead
of failing and using wrong order silently.
The "Show All" and "Show Selected" operators in the Graph Editor was taking into
account all handles on keyframes, even when some of those would be invalid and/or
set to nonsense values (e.g. for any interpolation mode other than "Bezier")
There were several small issues/inconsistencies if how particles' org face index was checked,
leading in some cases to invalid indices and hence mem access, in RNA UV/VCol compute for particles.
Note org code RNA one was copied from (in BI's convertblender.s) is much more complicated,
and seems to never reach those breaking conditions.
Also deduplicated most code in those UV/VCol particles funcs, they were doing mostly the same thing!
Finally, also got rid of annoying `NO CD_ORIGSPACE, error out of range` error message in console,
was another case of not checking whether we did have any faces in final mesh!
Currently this gaussian blur implementation accumulates values in the
square kernel rather that doing X direction and then Y direction because
of the lack of using multiple-staged filters.
Once we can we'll implement a way to apply filter as multiple stages we
can optimize hell of a lot in here.
Another thing we can do is to use SSE2 instructions here.
Manifold was defined as any edges not using 2 faces,
however its useful to have some options here.
You can now select between Wire/Boundary/Multi-Face/Non-Contiguous/Verts
Note the Non-Contiguous option is new,
it selects edges between faces pointing in different directions.
- name primary comparison var 'v'
- names remain same when expanded
- no odd mixing of macros, use prev ELEM + extra arg
- use 16, even if not used yet, saves adding more in future
BKE_scene_base_iter_next() was completely messing poor dupli objects' matrices...
Note this func should be reworked, but as stated in comments, it should not exist at all,
DAG should be used here, so until we have new shinny one we can live with this.
Also, mballs do not behave correctly when used as duplis (org object remains visible/rendered,
unlike any other object type). This will be fixed in a separate patch/commit,
since it proved to be rather tricky to handle.
BKE_mball_basis_find() was making a bunch of string manipulations for all MBall objects
(including duplis), and then making a (broken!) check to do nothing in case of duplis mball!
Now it makes correct check in early stage.
