The do-version handling for Userdef is outside file reading, which makes
it needed to store the file version in UserDef, so it gets the correct
version to handle.
Thanks Antonis R. for pointing at the omission!
Also removed the mindboggling define. If you do such, then make it
like "MAIN_VERSION_OLDER_THAN() or so.
In general version hacking could be limited much better... ask me
before even thinking to add one, most optimal is to do it in a way
it's not depending on a version ever - forward/backward compatible.
there were 2 bugs here.
- int buttons scaling values on input but not on display.
- pixel distances were using PROP_DISTANCE subtype - which isn't correct.
added assert incase PROP_INT values have PROP_DISTANCE subtype applied in future.
* Color picker cursor was too small, and color cirle was not smooth enough.
* Border select gesture cross before first click did not reach to the border
of the window.
* Buttons were not drawing emboss properly (also for non-retina actually).
Note it doesn't draw entirely right for aligned buttons, but this was also
the case before it got broken.
As per discussion and analysis of all trackpad usage, we now
follow this convention:
- Blender follows system setting for trackpad direction preference.
- If you set your system to "natural" scroll, we need to invert a couple
of cases in Blender we do "natural" already. Like:
- view rotate (the inversed option just never feels ok)
- scroll active items in list or pulldown menu (up/down is absolute)
- ALT+scroll values in buttons (up/down is absolute)
The new User Preference setting "Trackpad Natural" handles this.
For 2.66 we only have trackpad handling for OS X... so this isn't
affecting trackpad usage in Windows and Linux, which stick to be mapped
to Scroll Wheel still.
(Note: viewrotate now is "natural" always, changing how it worked in the
past weeks).
This was caused from using theme shadow setting to clip the popups and a hard-coded value to translate the popup within screen bounds - these values should be the same.
from regular diffuse to more shiny, stone, wax, eflective, glass and two non-realistic ones.
The menu now shows it in 3 rows. I made the previews a bit smaller, 96 pixels,
like the brushes for painting.
Thanks everyone for submitting pics! I updated the credit file too, but name
from one person is missing still, will be added next.
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
if you moved your mouse fast over a button the event would get converted to a wheel, even if the input event wasnt a MOUSEPAN event.
When Alt was held this was noticable because Alt+Wheel changes button values.
added an assert to avoid this happening again.
53132 which changed the RNA index to -1 for these. Also made it so that these
buttons no longer display "Insert Single Keyframe" and only "Insert Keyframe"
as you can't edit individual components here so it's only confusing.
without NPOT support. Was wrong stride used for memcpy leading
to wrong memory writes in def_internal_icon.
It's a regression since matcap commit.
Should fix the following reports:
- #33993: Crash on Blender startup (Vista x32)
- #33996: Latest build crashes on win xp
Headerless panels are not supposed to be closed ever. But if user saves a blend with a stardard panel closed, then dev decides to make this panel headerless, when user open again its blend, the panel is closed and has no more header, so it becomes invisible!
This commit simply checks, at draw time, that a headerless panel is never closed (and repoen it if necessary)!
Oops! So there was an Unpack button, hidden in the Nkey properties of Image window.
This was drawn next to greyed-out buttons, didn't notice it well.
I also now found the unpack() menu in editors/util, and there's an Image unpack op.
Also the RNA api has an unpack!
Will remove the generic unpack op, and add a sound and vfont unpack instead.
- The "ID" buttons (for browse images, for example) now show a Pack icon, for packed
Images. Using this button allows unpack.
- Pack and unpack operations now give a Info report on what happened.
- Not restored yet: option to set "AutoPack".
previous commit (54102) actually reintroduces an old bug where Blender sigfaults when
the sensor and controllers are not from the active object.
The real fix for report #33746 is to clear the "object" property after the operator ran.
I'm not sure why when I call the operator from command line the property is cleared, but not
when I called it from C. Either way all should be working now.
Full log is here:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport
Implementation notes:
- Matcaps are an extension of Solid draw mode, and don't show in other drawmodes.
(It's mostly intended to aid modeling/sculpt)
- By design, Matcaps are a UI feature, and only stored locally for the UI itself, and
won't affect rendering or materials.
- Currently a set of 16 (GPL licensed) Matcaps have been compiled into Blender.
It doesn't take memory or cpu time, until you use it.
- Brush Icons and Matcaps use same code now, and only get generated/allocated on
actually using it (instead of on startup).
- The current set might get new or different images still, based on user feedback.
- Matcap images are 512x512 pixels, so each image takes 1 Mb memory. Unused matcaps get
freed immediately. The Matcap icon previews (128x128 pixels) stay in memory.
- Loading own matcap image files will be added later. That needs design and code work
to get it stable and memory-friendly.
- The GLSL code uses the ID PreviewImage for matcaps. I tested it using the existing
Material previews, which has its limits... especially for textured previews the
normal-mapped matcap won't look good.
