| Age | Commit message (Collapse) | Author |
|---|
|
|
|
also use ..._find_name(..., name) rather then ..._find_named(..., name) --- both were used.
|
|
* ID-blocks referenced by Constraints but not being used as the target objects
(such as Actions in the Action Constraint, or Text Blocks in PyConstraints) now
get usercounts for being referenced in this way. This should fix ancient bugs
such as [#19205] and [#8593]. More tests still needed to verify that this
does now play nicely with proxies.
* Changing actions used by NLA strips should now update the usercounts
accordingly
|
|
new image. (not use existing one)
|
|
also stop numpy from being found in /usr/include with cmake.
|
|
|
|
|
|
|
|
a bevelled curve which isn't fully covered with a bevel.
|
|
For sample images see:
http://www.dalaifelinto.com/?p=399 (equisolid)
http://www.dalaifelinto.com/?p=389 (equidistant)
The 'use_panorama' option is now part of a new Camera type: 'Panorama'.
Created two other panorama cameras:
- Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...)
this works as a real lens up to an extent. The final result takes the
sensor dimensions into account also.
.:. to simulate a Nikon DX2S with a 10.5mm lens do:
sensor: 23.7 x 15.7
fisheye lens: 10.5
fisheye fov: 180
render dimensions: 4288 x 2848
- Equidistant: this is not a real lens model. Although the old equidistant lens simulate
this lens. The result is always as a circular fisheye that takes the whole sensor
(in other words, it doesn't take the sensor into consideration).
This is perfect for fulldomes ;)
For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can).
Reference material:
http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdf
http://www.bobatkins.com/photography/technical/field_of_view.html
Note, this is not a real simulation of the light path through the lens.
The ideal solution would be this:
https://graphics.stanford.edu/wikis/cs348b-11/Assignment3
http://www.graphics.stanford.edu/papers/camera/
Thanks Brecht for the fix, suggestions and code review.
Kudos for the dome community for keeping me stimulated on the topic since 2009 ;)
Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
|
|
All operators which changes tracking data now just tags dopsheet as outdated,
actual re-calculaiton of happens only when this information is actually needed
(like on dopesheet draw).
This makes things a bit faster when there's no dopesheet visible in current
screen and also makes it much easier to update dopesheet using dependency
graph.
Also renamed dopesheet_sort_order to dopesheet_sort_method in rna and internal
stuff which makes much more sense and also correlated with naming in
file browser.
|
|
|
|
Supported sorting by name, longest tracked segment and total tracked frames.
Internally tracks are stored in Tracking datablock, but sort order is
a clip editor space property and sorting happens on clip editor draw.
If there's no dopesheet opened with different sort orders it's not
a problem due to re-sorting wouldn't happen.
Also fixed draw issue of tracked segments introduced in previous commit.
|
|
ideally this function should become context free, for now just trick it to
execute in the right context.
|
|
working in blender render rather than blender game mode. Tweaked the flags a
bit to make it compatible more, but for full configuration you need to be in
blender game mode still.
|
|
would crash.
|
|
types and make node code more robust for future nodes with extra socket data.
* Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes.
* Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm.
* File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct).
* Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature.
* Added another operator for reordering custom input slots in the file output node.
|
|
|
|
|
|
|
|
This commit refactors the way that the Motion Paths GUI works. The key problems
this tries to address are:
1) Mode error - Confusion about whether we're dealing with the Object or Pose
level Motion Paths panel
2) Display settings vs Baking Settings
In line with the original design intentions for the 2.5/6 Properties Editor,
I've now split out the actual baking-related settings away from the Properties
Editor:
* Now, when clicking "Calculate Paths" from the toolbar, you'll be prompted with
a dialog to select the start/end frames (and for bones, whether to bake from
heads or tails). This is less confusing than relying on firstly setting the
range via the display range settings (and baking using that), since many people
apparently only used the "around current" mode, and were confused why things
weren't working
* Added a display of the frame ranges of the current baked Motion Path on the
active Object/Bone. This makes it clearer/easier to debug if the path suddenly
starts disappearing after a certain frame.
* Replaced Calculate/Clear Paths in the panels with a single "Update" button if
there's already a baked Motion Path.
Hopefully these changes (in combination with some of the other bugfixes) will
make it more obvious how everything works.
|
|
* Shadow color now usable in the BGE
* Simplified the shadow panel while "Blender Game" renderer is active
* Added variance shadow maps for the BGE
* Buffered shadows on sun lamps in the BGE (orthographic)
* Light textures in the BGE
|
|
http://wiki.blender.org/index.php/Dev:Doc/CodeStyle#Braces_with_Macros
|
|
- Displays dopesheet information for selected tracks, and currently does not
support any kind of editing.
- Changed regions to use the whole main region for such views as curves and dopesheet.
This allows to have own panels with tools/properties in this area.
- Active clip is getting synchronized between different clip editor editors in the
same screen, so updating of curve/dopesheet views happens automatically when one
changes current clip in one of this editors.
- Panels in toolbox and properties panels are now separated to rely on current view
mode, but some operators and poll functions still need to be updated.
- Added new screen called "Movie Tracking" where layout is configured to
display timeline, main clip window, curves and dopesheet.
|
|
|
|
Most of the changes are related to adding support for motion data throughout
the code. There's some code for actual camera/object motion blur raytracing
but it's unfinished (it badly slows down the raytracing kernel even when the
option is turned off), so that code it disabled still.
Motion vector export from Blender tries to avoid computing derived meshes
when the mesh does not have a deforming modifier, and it also won't store
motion vectors for every vertex if only the object or camera is moving.
|
|
|
|
threshold to be limited by the falloff value. These should be independent. Cleaned up how falloff works in keying nodes.
|
|
Patch from Jaggz H, thanks!
[#31096] Weight-painting: Brush-specific weights
http://projects.blender.org/tracker/?func=detail&atid=127&aid=31096&group_id=9
Each brush's weight can now be set individually, can also enable
unified setting (same as size and strength have.)
Added readfile code to the patch: subversion bumped to 1, brushes get
default weight of 0.5, unified weight enabled by default and value
from old vgroup_weight field.
|
|
|
|
|
|
|
|
and dopesheet view into trunk
Mostly related on changes in poll functions for tracking operators and some changes
to how interface is initializing for different view types.
|
|
Sponsored by the Blender Development Fund.
http://www.blender.org/blenderorg/blender-foundation/development-fund/
Remarks:
The original code was not designed to support moving obstacles so I had to introduce some velocity constraints into the code to prevent smoke from exploding. If this causes problems with "fire" emulation, please let me know.
|
|
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
|
|
to BLI_array macros.
|
|
Expose option into interface to use modal solver which currently
supports only tripod motion.
This solver requires two tracks at least to reconstruct motion.
Using more tracks aren't improving solution in general, just adds
instability into solution and slows down things a lot.
Refirement of camera intrinsics was disabled due to it's not only
refines camera intrinsics but also adjusts camera position which
isn't necessary here
To use this solver just activate "Tripod Motion" checkbox in
solver panel.
Merged from tomato: svn merge ^/branches/soc-2011-tomato -r45622:45624 -r46036:46037
P.S. Quite experimental yet, requires more checking and probably
tweaks to prevent camera jumps when tracks apperars/disappears
from the screen.
|
|
=== BVH build time optimizations ===
* BVH building was multithreaded. Not all building is multithreaded, packing
and the initial bounding/splitting is still single threaded, but recursive
splitting is, which was the main bottleneck.
* Object splitting now uses binning rather than sorting of all elements, using
code from the Embree raytracer from Intel.
http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/
* Other small changes to avoid allocations, pack memory more tightly, avoid
some unnecessary operations, ...
These optimizations do not work yet when Spatial Splits are enabled, for that
more work is needed. There's also other optimizations still needed, in
particular for the case of many low poly objects, the packing step and node
memory allocation.
BVH raytracing time should remain about the same, but BVH build time should be
significantly reduced, test here show speedup of about 5x to 10x on a dual core
and 5x to 25x on an 8-core machine, depending on the scene.
=== Threads ===
Centralized task scheduler for multithreading, which is basically the
CPU device threading code wrapped into something reusable.
Basic idea is that there is a single TaskScheduler that keeps a pool of threads,
one for each core. Other places in the code can then create a TaskPool that they
can drop Tasks in to be executed by the scheduler, and wait for them to complete
or cancel them early.
=== Normal ====
Added a Normal output to the texture coordinate node. This currently
gives the object space normal, which is the same under object animation.
In the future this might become a "generated" normal so it's also stable for
deforming objects, but for now it's already useful for non-deforming objects.
=== Render Layers ===
Per render layer Samples control, leaving it to 0 will use the common scene
setting.
Environment pass will now render environment even if film is set to transparent.
Exclude Layers" added. Scene layers (all object that influence the render,
directly or indirectly) are shared between all render layers. However sometimes
it's useful to leave out some object influence for a particular render layer.
That's what this option allows you to do.
=== Filter Glossy ===
When using a value higher than 0.0, this will blur glossy reflections after
blurry bounces, to reduce noise at the cost of accuracy. 1.0 is a good
starting value to tweak.
Some light paths have a low probability of being found while contributing much
light to the pixel. As a result these light paths will be found in some pixels
and not in others, causing fireflies. An example of such a difficult path might
be a small light that is causing a small specular highlight on a sharp glossy
material, which we are seeing through a rough glossy material. With path tracing
it is difficult to find the specular highlight, but if we increase the roughness
on the material the highlight gets bigger and softer, and so easier to find.
Often this blurring will be hardly noticeable, because we are seeing it through
a blurry material anyway, but there are also cases where this will lead to a
loss of detail in lighting.
|
|
* Remove RNA, Operator and UI for Texture and Sequence plugins.
Since 2.5x no effort has been done to bring that back, so there is simply no reason in keeping that code and the UI for that ;-)
* Low Level code still exists and is unchanged.
|
|
|
|
sequencer strip.
|
|
|
|
slight modifications.
Thanks!
|
|
blender - http://www.viva64.com/en/b/0145/
|
|
now stored in the loops.
|
|
|
|
|
|
bpy.data.scenes.tag() was missing.
|
|
- fix for own mistake (Ctrl+T didnt set beauty peroperty).
- remove bad level includes in bmesh.
|
|
add filtering for document generator to support --partial bpy.types.SomeType
|
