- pick the closest unit that matches the existing step size.
- set the distance subtype on some camera flags.
- commented mesh flag 'ME_ISDONE' its nolonger used.
- Also made it so sys.stdin isnt overwritten anymore, instead the interactive consoel overwrites while it executes and restores after.
- removed hope folder from sphinx patch path
Now, rather than the bit-too-alarming stop sign, threaded wmJobs
display a progress indicator in the header. This is an optional feature
for each job type and still uses the same hardcoded ui template
(could use further work here...).
Currently implemented for:
Render - parts completed, then nodes comped
Compositor - nodes comped
Fluid Sim - frames simulated
Texture Bake - faces baked
Example: http://mke3.net/blender/devel/2.5/progress.mov
[#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders
Blenfont was not thread safe, that is why one thread can change
the font properties (size, dpi, color, etc) at the same time
that the stamp draw on the image, and then the problem.
To make blenfont thread safe I have to change two important things:
1) Every BLF_* function take one argument, the font id.
2) We have two new function to make font "thread safe":
BLF_load_unique
BLF_load_mem_unique
This two function are for case like stamp, that need and own font
that don't share the glyph cache, so can draw without problem
in a different thread.
Why the BLF_*_unique function ?
Because blenfont keep only one copy of a font and keep a list of
"glyph cache". Every glyph cache have size and dpi, so if two
different thread access the same font at the same time, they can
change value and finish with something like the stamp problem.
Why don't remove the glyph cache ?
Because if we do that, we finish with a font object for every size
and dpi, and the stamp is really a special case that happen in
the rendering process, so I really thing is better keep the
glyph cache and make this two new function to handle this
special case.
(When I say "font object" I mean have the same freetype font multiple
times just to have differents size and dpi)
As Matt point we still can have one case that two thread access
the BLF_*_unique function at the same time, but I am looking to
fix this with some class of thread lock.
For now I test and work fine, so if some one found problem, please
let me know.
Campbell I have to change the python api (python/generic/blf_api.c)
to the new syntax, so maybe you can take a look at this.
* Some cases of struct name being set where it shouldnt have been.
* Spelling: wich --> which
* Copy and initialize uv modifier scale, remove unneeded enum.
* Ability to pin any object into the context.
* Update uv window while transforming (useful when used with UVProject modifier)
* Patch by Wahooney, so new template's are internal text and dont get saved over
by mistake.
* Fix for https://bugzilla.redhat.com/show_bug.cgi?id=572186
Bug 572186 - [abrt] crash in blender-2.49b-5.fc12: Process
/usr/bin/blender.bin was killed by signal 6 (SIGABRT). Original fix submitted
by Jochen Schmitt.
* [#21816] bpy.data.add_image has stopped working on Windows. moved to
bpy.data.images.load(), missed this call.
(commits 27726,27825,27828,27831,27832,27833,27834,27836,27837,27838,27839,27858 by Campbell from render25 branch)
Theme colours were getting overwritten on startup with defaults (as in 2.4
system). Changed this to allow changing the default theme, and added a
'Reset to defaults' operator in user prefs. Perhaps next step to look into the
py presets system for themes too (nice and easy to share).
If you're using a custom B.blend you may get some strange theme colours on
startup if they weren't saved properly before. 'Reset to default' button in theme
preferences should fix it back to defaults.
Only source/blender/editors/ dir, should not give errors on different platforms
Only removing: UI_*.h, ED_*.h, WM_*.h, DNA_*.h, IMB_*.h, RNA_*.h, PIL_*.h
The problem was that wmPushMatrix/wmOrtho/.. and similar functions did not
work well for offscreen rendering. It would have been possible to make a
fake subwindow for this, but I decided to just remove this extra layer as
it does not seem to have much purpose and has been quite confusing when
trying to fix other bugs. The relevant matrices are already stored in
RegionView3D so there will be no increase in calls to glGetFloat, which may
have been a performance reason to use this system in the past.
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
Rotations are now stored internally as radians, while exposing degrees in the UI -
in the graph editor and UI controls. This is done in two areas:
1) Using the unit system to convert RNA data to display as degrees in the UI controls
2) FCurves now use degrees for rotation, so you can edit in the graph editor what
you see in the UI.
All rotation data is consistently accessible in DNA and RNA as radians, degrees are only
used for the UI controls and graph editor.
This commit includes conversions will convert old files (stored data and also fcurve data)
to the new units, hopefully everything should go smoothly!
Part of this also changes a few properties that were hard-coded as degrees before (such
as IK pole angle and brush texture rotation) to also use the same consistent system of
radians (dna/rna) and degrees (ui).
Thanks to Joshua for hints and review here too.
similar to sequence editor.
--> http://mke3.net/blender/devel/2.5/color_balance_node.jpg
Also added 0 key (zero key) shortcut when mouse is over a button, to reset it to its default value.
Same as the RMB menu ->Reset to Default, except for color wheels, it only resets the hue/sat/value
components that that widget affects.
Peter/Xavier: The existing color balance code can generate NaNs (fractional power of a negative),
which causes havoc along the image pipeline. I added a check in the node code to prevent this.
Still plenty of potential for lots of better colour correction tools in the compositor, just needs time...
Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator,
working nicely using rna properties (fixes#19475 and some todo items)
This ended up being a bit more work than expected, it involved converting the
colour picker to use RNA properties directly, rather than temporary values. This has
several advantages, including being able to type in RGB values greater than 1,
however there are still some redraw issues with sliders.
Also removed the alternate color pickers after this time spent testing, the current one
should be sufficient, or alternatives to the wheel can possibly become preferences
in the current design.
Converting the picker to RNA also made it very trivial to make a cool new
ColorWheel template, which can be embedded in UI layouts. I've enabled it already
in texture/vertex paint brush properties and the sequence editor color correction:
http://mke3.net/blender/devel/2.5/colorwheels.jpg
This changes how textures are accessed from Brushes, with the intention of simplifying
the workflow, and reducing the amount of clicking. Rather than the previous texture slots
(which didn't work as a stack anyway), brushes now have a single texture linked. Rather
than taking time having to set up your slots in advance, you can now select and change
textures directly as you sculpt/paint on the fly. For complex brushes, node textures can
be used, or for fast access, it's easy to make a duplicate of your brush with the texture
you like and assign a hotkey.
Brush textures can now be chosen from a new Textures panel in the brush tool
properties - click on the thumbnail to open a texture selector. This is done using a new
variation on the ID template - the number of rows and columns to display in the popup
can be customised in the UI scripts.
* Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries.
* Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language.
This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
After testing and feedback, I've decided to slightly modify the way color
management works internally. While the previous method worked well for
rendering, was a smaller transition and had some advantages over this
new method, it was a bit more ambiguous, and was making things difficult
for other areas such as compositing.
This implementation now considers all color data (with only a couple of
exceptions such as brush colors) to be stored in linear RGB color space,
rather than sRGB as previously. This brings it in line with Nuke, which also
operates this way, quite successfully. Color swatches, pickers, color ramp
display are now gamma corrected to display gamma so you can see what
you're doing, but the numbers themselves are considered linear. This
makes understanding blending modes more clear (a 0.5 value on overlay
will not change the result now) as well as making color swatches act more
predictably in the compositor, however bringing over color values from
applications like photoshop or gimp, that operate in a gamma space,
will give identical results.
This commit will convert over existing files saved by earlier 2.5 versions to
work generally the same, though there may be some slight differences with
things like textures. Now that we're set on changing other areas of shading,
this won't be too disruptive overall.
I've made a diagram explaining the pipeline here:
http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png
and some docs here:
http://www.blender.org/development/release-logs/blender-250/color-management/
* Now has documentation links and recent files.
* Click on image or outside splash to make it go away.
* Still has old image, new one will be committed later.
only implimented min/max precision & step.
at the moment there is no way to edit these other then via python
example of setting UI limits...
>>> C.object['foo'] = 0.5
>>> C.object['_RNA_UI'] = {'foo': {'step': 0.5, 'soft_max': 10.0, 'soft_min': 0.0, 'precision': 2, 'description': 'Some setting'}}
Also fixed typo's: precission -> precision
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
* Fix problem with curve mapping / color ramps not updating
things like previews propertly. Now it uses the RNA update
of the pointer from the material/texture/.. so each of those
can define their own update, but still share the RNA struct.
* Code for these templates is now in interface_templates.c
* Fix exception for "axis" property, now it always shows normal
widget with the PROP_DIRECTION subtype.
* Remove context from uiBlockLayoutResolve, no longer needed.
#19302: the spin operator did not redo correct when changing properties.
Actually the problem was somewhere else, the search menu always did an
unnecessary undo push, which conflicted with an operator undo push with
the same name. Only in the case of "Spin" was this noticed, because it's
name is so short and you actually type it completely.
#19328: swapping areas could crash when dragging mouse outside the window.
Attempted fix for #19331, #19335 as well, where backspace and some other
keys give square characters instead of working as expected. Couldn't
reproducable here, so please test.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
