So now it's possible to copy-paste splines between layers.
Implementation is pretty much straightforward and duplicates
some logic which we've got in sequencer/tracking clipboards.
Will work on a common routine for clipboards later, for now
it's not so much crucial to have.
Updated CMakeLists.txt to account for boost hardcoded locations for VS 2013.
Reviewers: juicyfruit
Differential Revision: https://developer.blender.org/D261
Changed curve active point from pointer to index. Allows curve active point to be saved to file and retained between modes for free. Also some small optimisations by removing pointer look up code.
- Made active point access functions into BKE API calls.
- Fixes operators where curve de-selection resulted in unsel-active point.
- Split curve delete into 2 functions
* Very simple implementation, only allows for 1 output socket. As we haven't decided yet whether we keep the XML API, rather not spend more time on this now.
* To use an external osl shader, put the .osl file next to the xml file.
* Parameters: "output" is the output socket name, "output_type" the variable type (float, color and closure color are supported).
Example:
<osl_shader name="tex" src="ramp_closure.osl" output="Phong" output_type="closure color" />
<connect from="tex Phong" to="output surface" />
Factorized a bit the code here, think it's more readable now... No performance enhancement though.
Reviewed by: campbellbarton
Differential Revision: https://developer.blender.org/D259
* Change Info in header, put more important info to the left
* API: Move Camera width/height to camera, add some film properties
* Add ESC key to help menu
* EXR layers with names like 'Z' without any pass name were not loaded at all
and would break the Combined pass as well.
* EXR pass names longer than 16 characters where writing past the end of the
array and getting invalid names.
Until now, the "vertex group" limit method in the modifier
only worked for "vertex only" bevels. With this change,
edges with both ends in a vertex group will be beveled
in the non-"vertex only" case.
Also changed the test for being in a vertex group from
"any nonzero weight" to "weight >= 0.5". This is because
cascaded bevels on disjoint vertex groups did not give
disjoint bevels, because weight interpolation would give
non-zero weights to newly created vertices in earlier bevels.
Chose 0.5 because that won't result from interpolation, but
still allows some dilution (e.g., cascaded bevels on the
same vertex group).
libraries view not working.
This was disabled in the operator, there may have been a reason for this at
some point, but I can't see any reason to disallow it in the current code or
find a good reason why it was done in the commit logs.
The method for calculating points on the profile for non-circles
and non-lines meant that the segments making up an edge had
uneven widths.
Use a numeric search technique to find superellipse evaluation
points that lead to equal-sized chords across the profile.
Also calculate the actual profile points sooner, so that they
don't have to be recalculated again and again.
This also sets up for a possible later feature of arbitrary
profile shapes, set by user.
This is very basic for now, but can be extended with more info (available devices for example) later.
Thanks to Bastien and Sergey for some help with the glRect coordinates stuff.
Previously the divider was using the region background and the region text, leading to bad outlines with custom themes. This makes the outline behave more expectedly and allows better control.
This is rather a workaround which only works because curve evaluation is only called
for a temporary object. Not a big deal if we'll skip path creation for such objects.
Still would need to think of general solution.
For example for vector displacement, you may have an EXR texture that has
negative colors values. Blender clamps these by default, now the Colors panel
for textures has a Clamp option to disable this clamping.
This option affects all texture types and is enabled by default, you need
to disable it if you want negative values to have an influence.
Patch by Fredrik Hansson with modifications by me.
it is possible that different windows shares scene but displays different
layers. And it's also possible that different areas in the same window will
show different layers.
First case was violated in `dag_current_scene_layers()` which only checked
scene layers only once and if multiple windows shares the same scene only
one window was handled. Now made it so layers from all windows will be
squashed together into a single `DagSceneLayer`. This mainly solves issue
with `DAG_on_visible_update()` which didn't work reliable with multiple
open windows.
Second case required call of `DAG_on_visible_update()` when changing space
are type.
This commit slows things a bit actually because `dag_current_scene_layers()`
is actually called on every main WM loop iteration. It is possible to speed
some logic up perhaps. Not sure it's so much critical to do now because there
are unlikely to be more than few windows open anyway.
Will rather think of skipping all that flushing things if no objects are
tagged for update actually.
- Made them receive number of channels rather than number of planes.
This matches to how ImBuf structure stored planes and channels.
- IMB_premultiply_rect_float() was called with channels passed instead
of planes already :S.
Issue is caused by the race condition between getting custom data layers
from target's derived mesh (for vertices and faces) and releasing this
derived mesh from other threads.
When one releases the derived mesh it'll free temporary data from it,
and it'll also update data layers mapping.
General rule for threading is that no one is ever allowed to modify
data he doesn't own. This means that no temp layers are to be allocated
in derived mesh and making it so `CustomData_free_temporary()` doesn't
update mapping if nothing was freed will solve the race condition.
It is still possible to do other improvements, namely detect which
additional data/layers are to be present in derived mesh and create
it as a part of `object_handle_update()`, but this is to be solved
separately.
This was storing the original object matrix, which builds on the
assumption that obmat is modified during dupli construction, which is a
bad hack.
Now the obmats are still modified, but this only happens outside of the
dupli system itself and the original ("omat") is stored as local
variables in the same place where the obmat manipulation takes place.
This is easier to follow and avoids hidden hacks as much as possible.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D254
