| Age | Commit message (Collapse) | Author |
|---|
|
Goal is to make them more modular, to allow more variants (variable
single-color, thickness, ...) to be added without having to
copy-and-change-one-line of whole chain of shaders.
|
|
Use consistent prefix for gawain API names as well as
some abbreviations to avoid over-long names, see: D2678
|
|
This commit moves the list of transform orientations from scenes to workspaces.
Main reasons for this are:
* Transform orientations are UI data and should not be stored in the scene.
* Introducion of workspaces caused some (expected) glitches with transform orientations. Mainly when removing one.
* Improves code.
More technically speaking, this commit does:
* Move list of custom transform orientations from Scene to WorkSpace struct.
* Store active transform orientation index separate from View3D.twmode (twmode can only be set to preprocessor defined values now).
* Display custom transform orientation name in header when transforming in it (used to show "global" which isn't really correct).
|
|
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
|
|
Note that I also made 'dash anchor point' consistent (the static one,
not the mouse one), in previous code somtimes dashed were anchored to
the static center point, in others, to the moving mouse position, the
later was rather disturbing imho...
|
|
Getting ready for a Gawain API change...
Part of T49043
|
|
Original code from @Severin with changes from @dfelinto & @hypersomniac.
This doesn't cause many functional changes
besides using new transform manipulators.
Submitted as D2604
|
|
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
|
|
Part of T49450, fixes a Push/Pop mismatch from part yesterday's 3.
|
|
Some `UI_ThemeColor` calls were left in converted files, in some cases
because they were just overlooked, and in the case of text drawing,
because the new BLF color functions were not yet implemented at the
time of conversion.
Also converted one `drawcircball` call that was left in
transform_constraints.c
Part of T49043
|
|
Differential Revision: https://developer.blender.org/D2483
Part of T49043
|
|
|
|
|
|
|
|
When constraining on 2 axis, it was possible the plane was view-aligned causing odd glitches.
|
|
|
|
- LINE_STRIP to LINES when only drawing one
- group state changes for easier reading
- general cleanup
|
|
't->value' no longer has constraint matrix applied for translate,
fix for T46003 is no longer needed.
|
|
|
|
|
|
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
|
|
|
|
D910 by @donfabio with edits
New icon for menu is still TODO
|
|
store global center in transform struct,
some code was calculating all the time, this is useful to keep available.
|
|
Transform code had duplicate aspect checking,
now store aspect in TransInfo.aspect for reuse.
|
|
There are a few things here which are not so nice:
* Position of proportional edit circle is not centered on data
(difficult to predict positions here since those are completely custom,
will probably be positioned at center of area later instead)
* Result is flushed to curve handles only at the end of the transform,
so if people have the graph editor open they will see handles lagging behind.
|
|
This works by using the distance in the x axis only (usually artists want to influence nearby
keyframes based on timing, not value). Tweaking handles is the same as tweaking
the central handle. It's a bit ambiguous if proportional editing is really meaningful
for handles but will leave that for artists to decide.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Some more float precision issue...
|
|
results in 0.5828 increments
Interesting one, took me hours to understand the issue - a stupid typo checking the wrong value against the wrong flag (present since 2008!).
|
|
Ways how it was resetting its values (backspace) was far from satisfaying. Now, e.g. when scaling, it will reset at 1 (or whatever mouse-value it was before entering numinput), instead of some ugly 0.0 value.
Implementation details:
* Values passed to applyNumInput() are stored as default ones (val_org), if it is not EDITED.
* applyNumInput() returns a boolean saying whether it actually set values or not.
* When backspace hits its ultimate step (where it clears all EDITED flags and reset all default values),
it sets a temp FAKE_EDITED flag that will be used to apply one last time values of numinput
(so that default values actually get applied!).
There are important things to note here for code using numinput:
* Values passed to applyNumInput() should be valid and are stored as default ones (val_org), if it is not EDITED.
* bool returned by applyNumInput should be used to decide whether to apply numinput-specific post-process to data.
* *Once applyNumInput has been called*, hasNumInput returns a valid value to decide whether to use numinput as drawstr source or not.
Those two steps have to be separated (so do not use a common call to hasNumInput() to do both in the same time!).
|
|
|
|
|
|
Was caused by int rounding when an axis was < 1.0.
|
|
instead of using incremental offset (which is not useful for nodes). Increment snapping has been disabled for nodes to avoid
confusion, grid snap is now the default as it seems to be the most wanted and easy to use mode.
Absolute grid snapping happens in a somewhat generic function 'applyGridAbsolute', which could also be used for objects and other transforms later on. It is conceptually similar to the 'project' snapping
option, in that it calculates a delta vector for each element on top of the overall transform, which places each node on the grid.
Node transform now uses the top-left node corner for TransformData->loc. The transform center is still the average of node centers, so that scaling and rotation works nicely.
snapGrid*** functions have been renamed to snapGridIncrement*** to distinguish better between incremental and absolute grid snapping.
|
|
redraw flag were mixing up types - int/char/bool, add enum type to use instead.
|
|
individual origins and normal transform orientation are set
thanks to psy-fi for the initial patch.
|
|
now it always draws in front to ensure the circle is visible.
|
|
indent.
also indent case's within the switch (we already did both of these almost everywhere)
|
|
the per-element axis-matrix.
|
|
non-unit matrix. (own error when adding support for axismtx in editmode)
|
|
working if the object was rotated.
|
|
old behavior for editmodes where the axis-matrix isnt set (curve, surface, lattice)
|
|
individual-origin wasn't working.
|
|
|
|
Individual transformation now works in editmode mesh faces/edge, armature bones and metaballs.
|
