2004-06-26 18:18:11 +00:00
|
|
|
/* ipo.c
|
2002-10-12 11:37:38 +00:00
|
|
|
*
|
|
|
|
|
* $Id$
|
|
|
|
|
*
|
2008-04-16 22:40:48 +00:00
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
2002-10-12 11:37:38 +00:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
2008-04-16 22:40:48 +00:00
|
|
|
* of the License, or (at your option) any later version.
|
2002-10-12 11:37:38 +00:00
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
|
*
|
|
|
|
|
* Contributor(s): none yet.
|
|
|
|
|
*
|
2008-04-16 22:40:48 +00:00
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <math.h>
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <string.h>
|
2002-11-25 12:02:15 +00:00
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
|
#include <config.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "DNA_action_types.h"
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
#include "DNA_armature_types.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "DNA_curve_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_camera_types.h"
|
|
|
|
|
#include "DNA_lamp_types.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "DNA_ipo_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_key_types.h"
|
|
|
|
|
#include "DNA_material_types.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "DNA_mesh_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_object_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_object_force.h"
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
#include "DNA_particle_types.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "DNA_sequence_types.h"
|
|
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
|
#include "DNA_sound_types.h"
|
|
|
|
|
#include "DNA_texture_types.h"
|
|
|
|
|
#include "DNA_view3d_types.h"
|
Giant commit!
A full detailed description of this will be done later... is several days
of work. Here's a summary:
Render:
- Full cleanup of render code, removing *all* globals and bad level calls
all over blender. Render module is now not called abusive anymore
- API-fied calls to rendering
- Full recode of internal render pipeline. Is now rendering tiles by
default, prepared for much smarter 'bucket' render later.
- Each thread now can render a full part
- Renders were tested with 4 threads, goes fine, apart from some lookup
tables in softshadow and AO still
- Rendering is prepared to do multiple layers and passes
- No single 32 bits trick in render code anymore, all 100% floats now.
Writing images/movies
- moved writing images to blender kernel (bye bye 'schrijfplaatje'!)
- made a new Movie handle system, also in kernel. This will enable much
easier use of movies in Blender
PreviewRender:
- Using new render API, previewrender (in buttons) now uses regular render
code to generate images.
- new datafile 'preview.blend.c' has the preview scenes in it
- previews get rendered in exact displayed size (1 pixel = 1 pixel)
3D Preview render
- new; press Pkey in 3d window, for a panel that continuously renders
(pkey is for games, i know... but we dont do that in orange now!)
- this render works nearly identical to buttons-preview render, so it stops
rendering on any event (mouse, keyboard, etc)
- on moving/scaling the panel, the render code doesn't recreate all geometry
- same for shifting/panning view
- all other operations (now) regenerate the full render database still.
- this is WIP... but big fun, especially for simple scenes!
Compositor
- Using same node system as now in use for shaders, you can composit images
- works pretty straightforward... needs much more options/tools and integration
with rendering still
- is not threaded yet, nor is so smart to only recalculate changes... will be
done soon!
- the "Render Result" node will get all layers/passes as output sockets
- The "Output" node renders to a builtin image, which you can view in the Image
window. (yes, output nodes to render-result, and to files, is on the list!)
The Bad News
- "Unified Render" is removed. It might come back in some stage, but this
system should be built from scratch. I can't really understand this code...
I expect it is not much needed, especially with advanced layer/passes
control
- Panorama render, Field render, Motion blur, is not coded yet... (I had to
recode every single feature in render, so...!)
- Lens Flare is also not back... needs total revision, might become composit
effect though (using zbuffer for visibility)
- Part render is gone! (well, thats obvious, its default now).
- The render window is only restored with limited functionality... I am going
to check first the option to render to a Image window, so Blender can become
a true single-window application. :)
For example, the 'Spare render buffer' (jkey) doesnt work.
- Render with border, now default creates a smaller image
- No zbuffers are written yet... on the todo!
- Scons files and MSVC will need work to get compiling again
OK... thats what I can quickly recall. Now go compiling!
2006-01-23 22:05:47 +00:00
|
|
|
#include "DNA_world_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BLI_blenlib.h"
|
|
|
|
|
#include "BLI_arithb.h"
|
|
|
|
|
|
|
|
|
|
#include "BKE_bad_level_calls.h"
|
|
|
|
|
#include "BKE_utildefines.h"
|
|
|
|
|
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "BKE_action.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BKE_blender.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "BKE_curve.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BKE_constraint.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "BKE_global.h"
|
|
|
|
|
#include "BKE_ipo.h"
|
|
|
|
|
#include "BKE_library.h"
|
|
|
|
|
#include "BKE_main.h"
|
2004-06-26 18:18:11 +00:00
|
|
|
#include "BKE_mesh.h"
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
#include "BKE_object.h"
|
2006-04-30 16:22:31 +00:00
|
|
|
#include "BPY_extern.h" /* for BPY_pydriver_eval() */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
#define SMALL -1.0e-10
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* This array concept was meant to make sure that defines such as OB_LOC_X
|
|
|
|
|
don't have to be enumerated, also for backward compatibility, future changes,
|
|
|
|
|
and to enable it all can be accessed with a for-next loop.
|
|
|
|
|
*/
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
int co_ar[CO_TOTIPO]= {
|
Patch #7767: Constraint Subtargets can now target anywhere on a bone, not just the head or tail
Patch by: Roland Hess (harkyman)
For example, a constraint can be sub-targeted at the 50% (or 31.2% or 85% etc.) point of its target bone, giving you enormous rigging flexibility and removing the need for complex contraptions to do such things as:
- A bone whose base slides only between to points on a rig (CopyLoc with a variable, animated subtarget point)
- Bones that attach to multiple points along another bone (CopyLocs, each with a different head/tail percentage)
- Bones that need to stretch to a point midway between specific spots on two other bones (old way: too crazy to mention; new way: stretch bone between points on end bones, then another stretch to the midpoint of the first stretch)
It is only used for the constraint types for which it is relevant: CopyLoc, TrackTo, StretchTo and MinMax, TrackTo, and Floor.
Notes:
- This is accessed by the Head/Tail number-slider.
- This value can be animated per constraint
- The old "Copy Bone Tail" option for the CopyLoc constraint has been automatically converted to 1.0 Head/Bone values for the affected constraints
- In the code, this value is in the bConstraint struct, so it is available for all constraints, even though only a few implement it.
2007-11-12 04:17:03 +00:00
|
|
|
CO_ENFORCE, CO_HEADTAIL
|
2002-10-12 11:37:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int ob_ar[OB_TOTIPO]= {
|
|
|
|
|
OB_LOC_X, OB_LOC_Y, OB_LOC_Z, OB_DLOC_X, OB_DLOC_Y, OB_DLOC_Z,
|
|
|
|
|
OB_ROT_X, OB_ROT_Y, OB_ROT_Z, OB_DROT_X, OB_DROT_Y, OB_DROT_Z,
|
|
|
|
|
OB_SIZE_X, OB_SIZE_Y, OB_SIZE_Z, OB_DSIZE_X, OB_DSIZE_Y, OB_DSIZE_Z,
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
OB_LAY, OB_TIME, OB_COL_R, OB_COL_G, OB_COL_B, OB_COL_A,
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
OB_PD_FSTR, OB_PD_FFALL, OB_PD_SDAMP, OB_PD_RDAMP, OB_PD_PERM, OB_PD_FMAXD
|
2002-10-12 11:37:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int ac_ar[AC_TOTIPO]= {
|
|
|
|
|
AC_LOC_X, AC_LOC_Y, AC_LOC_Z,
|
|
|
|
|
AC_QUAT_W, AC_QUAT_X, AC_QUAT_Y, AC_QUAT_Z,
|
|
|
|
|
AC_SIZE_X, AC_SIZE_Y, AC_SIZE_Z
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int ma_ar[MA_TOTIPO]= {
|
|
|
|
|
MA_COL_R, MA_COL_G, MA_COL_B,
|
|
|
|
|
MA_SPEC_R, MA_SPEC_G, MA_SPEC_B,
|
2004-06-26 18:18:11 +00:00
|
|
|
MA_MIR_R, MA_MIR_G, MA_MIR_B,
|
2002-10-12 11:37:38 +00:00
|
|
|
MA_REF, MA_ALPHA, MA_EMIT, MA_AMB,
|
2004-07-05 09:15:02 +00:00
|
|
|
MA_SPEC, MA_HARD, MA_SPTR, MA_IOR,
|
|
|
|
|
MA_MODE, MA_HASIZE, MA_TRANSLU, MA_RAYM,
|
2004-07-07 08:49:33 +00:00
|
|
|
MA_FRESMIR, MA_FRESMIRI, MA_FRESTRA, MA_FRESTRAI, MA_ADD,
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
MA_MAP1+MAP_OFS_X, MA_MAP1+MAP_OFS_Y, MA_MAP1+MAP_OFS_Z,
|
|
|
|
|
MA_MAP1+MAP_SIZE_X, MA_MAP1+MAP_SIZE_Y, MA_MAP1+MAP_SIZE_Z,
|
|
|
|
|
MA_MAP1+MAP_R, MA_MAP1+MAP_G, MA_MAP1+MAP_B,
|
2004-07-05 09:15:02 +00:00
|
|
|
MA_MAP1+MAP_DVAR, MA_MAP1+MAP_COLF, MA_MAP1+MAP_NORF, MA_MAP1+MAP_VARF, MA_MAP1+MAP_DISP
|
2002-10-12 11:37:38 +00:00
|
|
|
};
|
|
|
|
|
|
2004-07-26 21:44:55 +00:00
|
|
|
int te_ar[TE_TOTIPO] ={
|
|
|
|
|
|
|
|
|
|
TE_NSIZE, TE_NDEPTH, TE_NTYPE, TE_TURB,
|
|
|
|
|
|
|
|
|
|
TE_VNW1, TE_VNW2, TE_VNW3, TE_VNW4,
|
|
|
|
|
TE_VNMEXP, TE_VN_COLT, TE_VN_DISTM,
|
|
|
|
|
|
|
|
|
|
TE_ISCA, TE_DISTA,
|
|
|
|
|
|
|
|
|
|
TE_MG_TYP, TE_MGH, TE_MG_LAC, TE_MG_OCT, TE_MG_OFF, TE_MG_GAIN,
|
|
|
|
|
|
2006-01-06 13:33:20 +00:00
|
|
|
TE_N_BAS1, TE_N_BAS2,
|
|
|
|
|
|
|
|
|
|
TE_COL_R, TE_COL_G, TE_COL_B, TE_BRIGHT, TE_CONTRA
|
2004-07-26 21:44:55 +00:00
|
|
|
};
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
int seq_ar[SEQ_TOTIPO]= {
|
|
|
|
|
SEQ_FAC1
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int cu_ar[CU_TOTIPO]= {
|
|
|
|
|
CU_SPEED
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int wo_ar[WO_TOTIPO]= {
|
|
|
|
|
WO_HOR_R, WO_HOR_G, WO_HOR_B, WO_ZEN_R, WO_ZEN_G, WO_ZEN_B,
|
|
|
|
|
WO_EXPOS, WO_MISI, WO_MISTDI, WO_MISTSTA, WO_MISTHI,
|
|
|
|
|
WO_STAR_R, WO_STAR_G, WO_STAR_B, WO_STARDIST, WO_STARSIZE,
|
|
|
|
|
|
|
|
|
|
MA_MAP1+MAP_OFS_X, MA_MAP1+MAP_OFS_Y, MA_MAP1+MAP_OFS_Z,
|
|
|
|
|
MA_MAP1+MAP_SIZE_X, MA_MAP1+MAP_SIZE_Y, MA_MAP1+MAP_SIZE_Z,
|
|
|
|
|
MA_MAP1+MAP_R, MA_MAP1+MAP_G, MA_MAP1+MAP_B,
|
|
|
|
|
MA_MAP1+MAP_DVAR, MA_MAP1+MAP_COLF, MA_MAP1+MAP_NORF, MA_MAP1+MAP_VARF
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int la_ar[LA_TOTIPO]= {
|
|
|
|
|
LA_ENERGY, LA_COL_R, LA_COL_G, LA_COL_B,
|
|
|
|
|
LA_DIST, LA_SPOTSI, LA_SPOTBL,
|
|
|
|
|
LA_QUAD1, LA_QUAD2, LA_HALOINT,
|
|
|
|
|
|
|
|
|
|
MA_MAP1+MAP_OFS_X, MA_MAP1+MAP_OFS_Y, MA_MAP1+MAP_OFS_Z,
|
|
|
|
|
MA_MAP1+MAP_SIZE_X, MA_MAP1+MAP_SIZE_Y, MA_MAP1+MAP_SIZE_Z,
|
|
|
|
|
MA_MAP1+MAP_R, MA_MAP1+MAP_G, MA_MAP1+MAP_B,
|
2004-12-04 21:49:02 +00:00
|
|
|
MA_MAP1+MAP_DVAR, MA_MAP1+MAP_COLF
|
2002-10-12 11:37:38 +00:00
|
|
|
};
|
|
|
|
|
|
Fixed:
Texture matrix bug in plugin code reported by Mel_Q.
Vertex colors, this was basically the same as the previous uv coord
splitting bug, for xml export, uv coord splitting was actually not quite
complete either (reported by richie).
Added:
Camera Ipo curves for DoF aperture and focal distance.
Aspect ratio set with AspX & AspY are now taken into account as well.
(needs yafray from cvs)
Bokeh parameters for DoF (also needs yafray from cvs).
'Bokeh' controls the shape of out of focus points when rendering
with depth of field enabled.
This is mostly visible on very out of focus highlights in the image.
There are currently seven types to choose from.:
'Disk1' is the default, the same as was used before.
'Disk2' is similar, but allows you to modify the shape further with the 'bias'
parameter, see below.
Triangle/Square/Pentagon/Hexagon, in addition to the bias control, you can
offset the rotation with the 'Rotation' parameter (in degrees).
'Ring', a weird ring shaped lens, no additional controls.
The 'bias' menu controls accentuation of the shape.
Three types available, uniform, center or edge, with uniform the default.
Although based on an actual phenomenon of real camera's, the current
code is bit of a hack and not physically based, and doesn't work all that
well yet (in yafray anyway). Since this is also mostly visible in the very
out of focus parts of the image, it usually also means that you need lots
of samples to get a reasonably smooth result.
2004-11-08 03:55:44 +00:00
|
|
|
/* yafray: aperture & focal distance curves added */
|
2006-12-21 18:11:07 +00:00
|
|
|
/* qdn: FDIST now available to Blender as well for defocus node */
|
2002-10-12 11:37:38 +00:00
|
|
|
int cam_ar[CAM_TOTIPO]= {
|
2007-01-15 12:44:45 +00:00
|
|
|
CAM_LENS, CAM_STA, CAM_END, CAM_YF_APERT, CAM_YF_FDIST, CAM_SHIFT_X, CAM_SHIFT_Y
|
2002-10-12 11:37:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int snd_ar[SND_TOTIPO]= {
|
|
|
|
|
SND_VOLUME, SND_PITCH, SND_PANNING, SND_ATTEN
|
|
|
|
|
};
|
|
|
|
|
|
Sorry for the big commit, but I've been fixing many of these
issues in parallel... So this commit contains: an update of
the solver (e.g. moving objects), integration of blender IPOs,
improved rendering (motion blur, smoothed normals) and a first particle
test. In more detail:
Solver update:
- Moving objects using a relatively simple model, and not yet fully optimized - ok
for box falling into water, water in a moving glass might cause trouble. Simulation
times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot
might also cause slowdowns.
- Additional obstacle settings: noslip (as before), free slip (move along wall freely)
and part slip (mix of both).
- Obstacle settings also added for domain boundaries now, the six walls of the domain are
obstacles after all as well
- Got rid of templates, should make compiling for e.g. macs more convenient,
for linux there's not much difference. Finally got rid of parser (and some other code
parts), the simulation now uses the internal API to transfer data.
- Some unnecessary file were removed, the GUI now needs 3 settings buttons...
This should still be changed (maybe by adding a new panel for domain objects).
IPOs:
- Animated params: viscosity, time and gravity for domains. In contrast
to normal time IPO for Blender objects, the fluidsim one scales the time
step size - so a constant 1 has no effect, values towards 0 slow it down,
larger ones speed the simulation up (-> longer time steps, more compuations).
The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect).
- For objects that are enabled for fluidsim, a new IPO type shows up. Inflow
objects can use the velocity channels to animate the inflow. Obstacles, in/outflow
objects can be switched on (Active IPO>0) and off (<0) during the simulation.
- Movement, rotation and scaling of those 3 types is exported from the normal
Blender channels (Loc,dLoc,etc.).
Particles:
- This is still experimental, so it might be deactivated for a
release... It should at some point be used to model smaller splashes,
depending on the the realworld size and the particle generation
settings particles are generated during simulation (stored in _particles_X.gz
files).
- These are loaded by enabling the particle field for an arbitrary object,
which should be given a halo material. For each frame, similar to the mesh
loading, the particle system them loads the simulated particle positions.
- For rendering, I "abused" the part->rt field - I couldnt find any use
for it in the code and it seems to work fine. The fluidsim particles
store their size there.
Rendering:
- The fluidims particles use scaled sizes and alpha values to give a more varied
appearance. In convertblender.c fluidsim particle systems use the p->rt field
to scale up the size and down the alpha of "smaller particles". Setting the
influence fields in the fluidims settings to 0 gives equally sized particles
with same alpha everywhere. Higher values cause larger differences.
- Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals
computed by the solver are used. This is basically done by switching off the
normal recalculation in convertblender.c (the function calc_fluidsimnormals
handles other mesh inits instead of calc_vertexnormals).
This could also be used to e.g. modify mesh normals in a modifier...
- Another change is that fluidsim meshes load the velocities computed
during the simulation for image based motion blur. This is inited in
load_fluidsimspeedvectors for the vector pass (they're loaded during the
normal load in DerivedMesh readBobjgz). Generation and loading can be switched
off in the settings. Vector pass currently loads the fluidism meshes 3 times,
so this should still be optimized.
Examples:
- smoothed normals versus normals from subdividing once:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png
- fluidsim particles, size/alpha influence 0:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png
size influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png
size & alpha influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png
- the standard drop with motion blur and particles:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg
(here's how it looks without
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg)
- another inflow animation (moving, switched on/off) with a moving obstacle
(and strong mblur :)
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg
Things still to fix:
- rotating & scaling domains causes wrong speed vectors
- get rid of SDL code for threading, use pthreads as well?
- update wiki documentation
- cool effects for rendering would be photon maps for caustics,
and motion blur for particles :)
2006-02-27 11:45:42 +00:00
|
|
|
int fluidsim_ar[FLUIDSIM_TOTIPO]= {
|
|
|
|
|
FLUIDSIM_VISC, FLUIDSIM_TIME,
|
|
|
|
|
FLUIDSIM_GRAV_X , FLUIDSIM_GRAV_Y , FLUIDSIM_GRAV_Z ,
|
|
|
|
|
FLUIDSIM_VEL_X , FLUIDSIM_VEL_Y , FLUIDSIM_VEL_Z ,
|
2008-07-07 14:36:33 +00:00
|
|
|
FLUIDSIM_ACTIVE,
|
|
|
|
|
FLUIDSIM_ATTR_FORCE_STR, FLUIDSIM_ATTR_FORCE_RADIUS,
|
|
|
|
|
FLUIDSIM_VEL_FORCE_STR, FLUIDSIM_VEL_FORCE_RADIUS,
|
Sorry for the big commit, but I've been fixing many of these
issues in parallel... So this commit contains: an update of
the solver (e.g. moving objects), integration of blender IPOs,
improved rendering (motion blur, smoothed normals) and a first particle
test. In more detail:
Solver update:
- Moving objects using a relatively simple model, and not yet fully optimized - ok
for box falling into water, water in a moving glass might cause trouble. Simulation
times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot
might also cause slowdowns.
- Additional obstacle settings: noslip (as before), free slip (move along wall freely)
and part slip (mix of both).
- Obstacle settings also added for domain boundaries now, the six walls of the domain are
obstacles after all as well
- Got rid of templates, should make compiling for e.g. macs more convenient,
for linux there's not much difference. Finally got rid of parser (and some other code
parts), the simulation now uses the internal API to transfer data.
- Some unnecessary file were removed, the GUI now needs 3 settings buttons...
This should still be changed (maybe by adding a new panel for domain objects).
IPOs:
- Animated params: viscosity, time and gravity for domains. In contrast
to normal time IPO for Blender objects, the fluidsim one scales the time
step size - so a constant 1 has no effect, values towards 0 slow it down,
larger ones speed the simulation up (-> longer time steps, more compuations).
The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect).
- For objects that are enabled for fluidsim, a new IPO type shows up. Inflow
objects can use the velocity channels to animate the inflow. Obstacles, in/outflow
objects can be switched on (Active IPO>0) and off (<0) during the simulation.
- Movement, rotation and scaling of those 3 types is exported from the normal
Blender channels (Loc,dLoc,etc.).
Particles:
- This is still experimental, so it might be deactivated for a
release... It should at some point be used to model smaller splashes,
depending on the the realworld size and the particle generation
settings particles are generated during simulation (stored in _particles_X.gz
files).
- These are loaded by enabling the particle field for an arbitrary object,
which should be given a halo material. For each frame, similar to the mesh
loading, the particle system them loads the simulated particle positions.
- For rendering, I "abused" the part->rt field - I couldnt find any use
for it in the code and it seems to work fine. The fluidsim particles
store their size there.
Rendering:
- The fluidims particles use scaled sizes and alpha values to give a more varied
appearance. In convertblender.c fluidsim particle systems use the p->rt field
to scale up the size and down the alpha of "smaller particles". Setting the
influence fields in the fluidims settings to 0 gives equally sized particles
with same alpha everywhere. Higher values cause larger differences.
- Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals
computed by the solver are used. This is basically done by switching off the
normal recalculation in convertblender.c (the function calc_fluidsimnormals
handles other mesh inits instead of calc_vertexnormals).
This could also be used to e.g. modify mesh normals in a modifier...
- Another change is that fluidsim meshes load the velocities computed
during the simulation for image based motion blur. This is inited in
load_fluidsimspeedvectors for the vector pass (they're loaded during the
normal load in DerivedMesh readBobjgz). Generation and loading can be switched
off in the settings. Vector pass currently loads the fluidism meshes 3 times,
so this should still be optimized.
Examples:
- smoothed normals versus normals from subdividing once:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png
- fluidsim particles, size/alpha influence 0:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png
size influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png
size & alpha influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png
- the standard drop with motion blur and particles:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg
(here's how it looks without
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg)
- another inflow animation (moving, switched on/off) with a moving obstacle
(and strong mblur :)
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg
Things still to fix:
- rotating & scaling domains causes wrong speed vectors
- get rid of SDL code for threading, use pthreads as well?
- update wiki documentation
- cool effects for rendering would be photon maps for caustics,
and motion blur for particles :)
2006-02-27 11:45:42 +00:00
|
|
|
};
|
|
|
|
|
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
int part_ar[PART_TOTIPO]= {
|
|
|
|
|
PART_EMIT_FREQ, PART_EMIT_LIFE, PART_EMIT_VEL, PART_EMIT_AVE, PART_EMIT_SIZE,
|
|
|
|
|
PART_AVE, PART_SIZE, PART_DRAG, PART_BROWN, PART_DAMP, PART_LENGTH, PART_CLUMP,
|
|
|
|
|
PART_GRAV_X, PART_GRAV_Y, PART_GRAV_Z, PART_KINK_AMP, PART_KINK_FREQ, PART_KINK_SHAPE,
|
2008-08-21 21:12:27 +00:00
|
|
|
PART_BB_TILT, PART_PD_FSTR, PART_PD_FFALL, PART_PD_FMAXD, PART_PD2_FSTR, PART_PD2_FFALL, PART_PD2_FMAXD
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
};
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
float frame_to_float(int cfra) /* see also bsystem_time in object.c */
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2006-05-27 13:35:03 +00:00
|
|
|
extern float bluroffs; /* bad stuff borrowed from object.c */
|
|
|
|
|
extern float fieldoffs;
|
2002-10-12 11:37:38 +00:00
|
|
|
float ctime;
|
|
|
|
|
|
|
|
|
|
ctime= (float)cfra;
|
2006-05-27 13:35:03 +00:00
|
|
|
ctime+= bluroffs+fieldoffs;
|
2002-10-12 11:37:38 +00:00
|
|
|
ctime*= G.scene->r.framelen;
|
|
|
|
|
|
|
|
|
|
return ctime;
|
|
|
|
|
}
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
/* includes ipo curve itself */
|
|
|
|
|
void free_ipo_curve(IpoCurve *icu)
|
|
|
|
|
{
|
|
|
|
|
if(icu->bezt) MEM_freeN(icu->bezt);
|
|
|
|
|
if(icu->bp) MEM_freeN(icu->bp);
|
|
|
|
|
if(icu->driver) MEM_freeN(icu->driver);
|
|
|
|
|
MEM_freeN(icu);
|
|
|
|
|
}
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* do not free ipo itself */
|
2002-10-12 11:37:38 +00:00
|
|
|
void free_ipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
while( (icu= ipo->curve.first) ) {
|
|
|
|
|
BLI_remlink(&ipo->curve, icu);
|
|
|
|
|
free_ipo_curve(icu);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
/* on adding new ipos, or for empty views */
|
|
|
|
|
void ipo_default_v2d_cur(int blocktype, rctf *cur)
|
|
|
|
|
{
|
|
|
|
|
if(blocktype==ID_CA) {
|
|
|
|
|
cur->xmin= G.scene->r.sfra;
|
|
|
|
|
cur->xmax= G.scene->r.efra;
|
|
|
|
|
cur->ymin= 0.0;
|
|
|
|
|
cur->ymax= 100.0;
|
|
|
|
|
}
|
|
|
|
|
else if ELEM5(blocktype, ID_MA, ID_CU, ID_WO, ID_LA, ID_CO) {
|
|
|
|
|
cur->xmin= (float)G.scene->r.sfra-0.1;
|
|
|
|
|
cur->xmax= G.scene->r.efra;
|
|
|
|
|
cur->ymin= (float)-0.1;
|
|
|
|
|
cur->ymax= (float)+1.1;
|
|
|
|
|
}
|
|
|
|
|
else if(blocktype==ID_TE) {
|
|
|
|
|
cur->xmin= (float)G.scene->r.sfra-0.1;
|
|
|
|
|
cur->xmax= G.scene->r.efra;
|
|
|
|
|
cur->ymin= (float)-0.1;
|
|
|
|
|
cur->ymax= (float)+1.1;
|
|
|
|
|
}
|
|
|
|
|
else if(blocktype==ID_SEQ) {
|
2006-03-26 21:36:42 +00:00
|
|
|
cur->xmin= -5.0;
|
2005-10-10 18:05:30 +00:00
|
|
|
cur->xmax= 105.0;
|
|
|
|
|
cur->ymin= (float)-0.1;
|
|
|
|
|
cur->ymax= (float)+1.1;
|
|
|
|
|
}
|
|
|
|
|
else if(blocktype==ID_KE) {
|
|
|
|
|
cur->xmin= (float)G.scene->r.sfra-0.1;
|
|
|
|
|
cur->xmax= G.scene->r.efra;
|
|
|
|
|
cur->ymin= (float)-0.1;
|
|
|
|
|
cur->ymax= (float)+2.1;
|
|
|
|
|
}
|
|
|
|
|
else { /* ID_OB and everything else */
|
|
|
|
|
cur->xmin= G.scene->r.sfra;
|
|
|
|
|
cur->xmax= G.scene->r.efra;
|
|
|
|
|
cur->ymin= -5.0;
|
|
|
|
|
cur->ymax= +5.0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
Ipo *add_ipo(char *name, int idcode)
|
|
|
|
|
{
|
|
|
|
|
Ipo *ipo;
|
|
|
|
|
|
|
|
|
|
ipo= alloc_libblock(&G.main->ipo, ID_IP, name);
|
|
|
|
|
ipo->blocktype= idcode;
|
2005-10-10 18:05:30 +00:00
|
|
|
ipo_default_v2d_cur(idcode, &ipo->cur);
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return ipo;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Ipo *copy_ipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
Ipo *ipon;
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return 0;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
ipon= copy_libblock(ipo);
|
|
|
|
|
|
|
|
|
|
duplicatelist(&(ipon->curve), &(ipo->curve));
|
2004-06-26 18:18:11 +00:00
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
icu->bezt= MEM_dupallocN(icu->bezt);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(icu->driver) icu->driver= MEM_dupallocN(icu->driver);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ipon;
|
|
|
|
|
}
|
|
|
|
|
|
2007-03-11 12:14:50 +00:00
|
|
|
/* uses id->newid to match pointers with other copied data */
|
|
|
|
|
void ipo_idnew(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
if(ipo) {
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
|
|
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
|
|
|
|
if(icu->driver) {
|
|
|
|
|
ID_NEW(icu->driver->ob);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
void make_local_obipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
Object *ob;
|
|
|
|
|
Ipo *ipon;
|
|
|
|
|
int local=0, lib=0;
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* - only lib users: do nothing
|
|
|
|
|
* - only local users: set flag
|
|
|
|
|
* - mixed: make copy
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
ob= G.main->object.first;
|
|
|
|
|
while(ob) {
|
|
|
|
|
if(ob->ipo==ipo) {
|
|
|
|
|
if(ob->id.lib) lib= 1;
|
|
|
|
|
else local= 1;
|
|
|
|
|
}
|
|
|
|
|
ob= ob->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-09 16:57:49 +00:00
|
|
|
if(local && lib==0) {
|
2002-10-12 11:37:38 +00:00
|
|
|
ipo->id.lib= 0;
|
|
|
|
|
ipo->id.flag= LIB_LOCAL;
|
|
|
|
|
new_id(0, (ID *)ipo, 0);
|
|
|
|
|
}
|
|
|
|
|
else if(local && lib) {
|
|
|
|
|
ipon= copy_ipo(ipo);
|
|
|
|
|
ipon->id.us= 0;
|
|
|
|
|
|
|
|
|
|
ob= G.main->object.first;
|
|
|
|
|
while(ob) {
|
|
|
|
|
if(ob->ipo==ipo) {
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ob->id.lib==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
ob->ipo= ipon;
|
|
|
|
|
ipon->id.us++;
|
|
|
|
|
ipo->id.us--;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ob= ob->id.next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void make_local_matipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
Material *ma;
|
|
|
|
|
Ipo *ipon;
|
|
|
|
|
int local=0, lib=0;
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* - only lib users: do nothing
|
|
|
|
|
* - only local users: set flag
|
|
|
|
|
* - mixed: make copy
|
|
|
|
|
*/
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
ma= G.main->mat.first;
|
|
|
|
|
while(ma) {
|
|
|
|
|
if(ma->ipo==ipo) {
|
|
|
|
|
if(ma->id.lib) lib= 1;
|
|
|
|
|
else local= 1;
|
|
|
|
|
}
|
|
|
|
|
ma= ma->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-09 16:57:49 +00:00
|
|
|
if(local && lib==0) {
|
2002-10-12 11:37:38 +00:00
|
|
|
ipo->id.lib= 0;
|
|
|
|
|
ipo->id.flag= LIB_LOCAL;
|
|
|
|
|
new_id(0, (ID *)ipo, 0);
|
|
|
|
|
}
|
|
|
|
|
else if(local && lib) {
|
|
|
|
|
ipon= copy_ipo(ipo);
|
|
|
|
|
ipon->id.us= 0;
|
|
|
|
|
|
|
|
|
|
ma= G.main->mat.first;
|
|
|
|
|
while(ma) {
|
|
|
|
|
if(ma->ipo==ipo) {
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ma->id.lib==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
ma->ipo= ipon;
|
|
|
|
|
ipon->id.us++;
|
|
|
|
|
ipo->id.us--;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ma= ma->id.next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void make_local_keyipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
Key *key;
|
|
|
|
|
Ipo *ipon;
|
|
|
|
|
int local=0, lib=0;
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* - only lib users: do nothing
|
|
|
|
|
* - only local users: set flag
|
|
|
|
|
* - mixed: make copy
|
|
|
|
|
*/
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
key= G.main->key.first;
|
|
|
|
|
while(key) {
|
|
|
|
|
if(key->ipo==ipo) {
|
|
|
|
|
if(key->id.lib) lib= 1;
|
|
|
|
|
else local= 1;
|
|
|
|
|
}
|
|
|
|
|
key= key->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-09 16:57:49 +00:00
|
|
|
if(local && lib==0) {
|
2002-10-12 11:37:38 +00:00
|
|
|
ipo->id.lib= 0;
|
|
|
|
|
ipo->id.flag= LIB_LOCAL;
|
|
|
|
|
new_id(0, (ID *)ipo, 0);
|
|
|
|
|
}
|
|
|
|
|
else if(local && lib) {
|
|
|
|
|
ipon= copy_ipo(ipo);
|
|
|
|
|
ipon->id.us= 0;
|
|
|
|
|
|
|
|
|
|
key= G.main->key.first;
|
|
|
|
|
while(key) {
|
|
|
|
|
if(key->ipo==ipo) {
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(key->id.lib==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
key->ipo= ipon;
|
|
|
|
|
ipon->id.us++;
|
|
|
|
|
ipo->id.us--;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
key= key->id.next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void make_local_ipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo->id.lib==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
if(ipo->id.us==1) {
|
|
|
|
|
ipo->id.lib= 0;
|
|
|
|
|
ipo->id.flag= LIB_LOCAL;
|
|
|
|
|
new_id(0, (ID *)ipo, 0);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(ipo->blocktype==ID_OB) make_local_obipo(ipo);
|
|
|
|
|
else if(ipo->blocktype==ID_MA) make_local_matipo(ipo);
|
|
|
|
|
else if(ipo->blocktype==ID_KE) make_local_keyipo(ipo);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-26 15:34:21 +00:00
|
|
|
IpoCurve *find_ipocurve(Ipo *ipo, int adrcode)
|
|
|
|
|
{
|
|
|
|
|
if(ipo) {
|
2005-10-10 18:05:30 +00:00
|
|
|
IpoCurve *icu;
|
|
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2005-09-26 15:34:21 +00:00
|
|
|
if(icu->adrcode==adrcode) return icu;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
void calchandles_ipocurve(IpoCurve *icu)
|
|
|
|
|
{
|
|
|
|
|
BezTriple *bezt, *prev, *next;
|
|
|
|
|
int a;
|
|
|
|
|
|
|
|
|
|
a= icu->totvert;
|
2008-09-27 10:08:19 +00:00
|
|
|
|
2006-11-03 14:23:19 +00:00
|
|
|
/* IPO_CONST doesn't have handles */
|
2008-09-27 10:08:19 +00:00
|
|
|
if(a<2 || icu->ipo==IPO_CONST || icu->ipo==IPO_LIN) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
bezt= icu->bezt;
|
|
|
|
|
prev= 0;
|
|
|
|
|
next= bezt+1;
|
|
|
|
|
|
|
|
|
|
while(a--) {
|
|
|
|
|
|
|
|
|
|
if(bezt->vec[0][0]>bezt->vec[1][0]) bezt->vec[0][0]= bezt->vec[1][0];
|
|
|
|
|
if(bezt->vec[2][0]<bezt->vec[1][0]) bezt->vec[2][0]= bezt->vec[1][0];
|
|
|
|
|
|
2005-07-10 12:50:14 +00:00
|
|
|
if(icu->flag & IPO_AUTO_HORIZ)
|
|
|
|
|
calchandleNurb(bezt, prev, next, 2); /* 2==special autohandle && keep extrema horizontal */
|
|
|
|
|
else
|
|
|
|
|
calchandleNurb(bezt, prev, next, 1); /* 1==special autohandle */
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
prev= bezt;
|
|
|
|
|
if(a==1) {
|
|
|
|
|
next= 0;
|
|
|
|
|
}
|
|
|
|
|
else next++;
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* for automatic ease in and out */
|
2002-10-12 11:37:38 +00:00
|
|
|
if(bezt->h1==HD_AUTO && bezt->h2==HD_AUTO) {
|
|
|
|
|
if(a==0 || a==icu->totvert-1) {
|
|
|
|
|
if(icu->extrap==IPO_HORIZ) {
|
|
|
|
|
bezt->vec[0][1]= bezt->vec[2][1]= bezt->vec[1][1];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void testhandles_ipocurve(IpoCurve *icu)
|
|
|
|
|
{
|
2003-04-26 11:56:44 +00:00
|
|
|
/* use when something has changed with handles.
|
|
|
|
|
it treats all BezTriples with the following rules:
|
|
|
|
|
PHASE 1: do types have to be altered?
|
|
|
|
|
Auto handles: become aligned when selection status is NOT(000 || 111)
|
|
|
|
|
Vector handles: become 'nothing' when (one half selected AND other not)
|
|
|
|
|
PHASE 2: recalculate handles
|
|
|
|
|
*/
|
|
|
|
|
BezTriple *bezt;
|
2002-10-12 11:37:38 +00:00
|
|
|
int flag, a;
|
|
|
|
|
|
|
|
|
|
bezt= icu->bezt;
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(bezt==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
a= icu->totvert;
|
|
|
|
|
while(a--) {
|
|
|
|
|
flag= 0;
|
2007-12-01 23:25:00 +00:00
|
|
|
if(bezt->f1 & SELECT) flag++;
|
|
|
|
|
if(bezt->f2 & SELECT) flag += 2;
|
|
|
|
|
if(bezt->f3 & SELECT) flag += 4;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
if( !(flag==0 || flag==7) ) {
|
|
|
|
|
if(bezt->h1==HD_AUTO) { /* auto */
|
|
|
|
|
bezt->h1= HD_ALIGN;
|
|
|
|
|
}
|
|
|
|
|
if(bezt->h2==HD_AUTO) { /* auto */
|
|
|
|
|
bezt->h2= HD_ALIGN;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(bezt->h1==HD_VECT) { /* vector */
|
|
|
|
|
if(flag < 4) bezt->h1= 0;
|
|
|
|
|
}
|
|
|
|
|
if(bezt->h2==HD_VECT) { /* vector */
|
|
|
|
|
if( flag > 3) bezt->h2= 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
calchandles_ipocurve(icu);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void sort_time_ipocurve(IpoCurve *icu)
|
|
|
|
|
{
|
|
|
|
|
BezTriple *bezt;
|
|
|
|
|
int a, ok= 1;
|
|
|
|
|
|
|
|
|
|
while(ok) {
|
|
|
|
|
ok= 0;
|
|
|
|
|
|
|
|
|
|
if(icu->bezt) {
|
|
|
|
|
bezt= icu->bezt;
|
|
|
|
|
a= icu->totvert;
|
|
|
|
|
while(a--) {
|
|
|
|
|
if(a>0) {
|
|
|
|
|
if( bezt->vec[1][0] > (bezt+1)->vec[1][0]) {
|
|
|
|
|
SWAP(BezTriple, *bezt, *(bezt+1));
|
|
|
|
|
ok= 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
2006-12-06 11:17:34 +00:00
|
|
|
if(bezt->vec[0][0]>bezt->vec[1][0] && bezt->vec[2][0]<bezt->vec[1][0]) {
|
2002-10-12 11:37:38 +00:00
|
|
|
SWAP(float, bezt->vec[0][0], bezt->vec[2][0]);
|
|
|
|
|
SWAP(float, bezt->vec[0][1], bezt->vec[2][1]);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
if(bezt->vec[0][0]>bezt->vec[1][0]) bezt->vec[0][0]= bezt->vec[1][0];
|
|
|
|
|
if(bezt->vec[2][0]<bezt->vec[1][0]) bezt->vec[2][0]= bezt->vec[1][0];
|
|
|
|
|
}
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int test_time_ipocurve(IpoCurve *icu)
|
|
|
|
|
{
|
|
|
|
|
BezTriple *bezt;
|
|
|
|
|
int a;
|
|
|
|
|
|
|
|
|
|
if(icu->bezt) {
|
|
|
|
|
bezt= icu->bezt;
|
|
|
|
|
a= icu->totvert-1;
|
|
|
|
|
while(a--) {
|
|
|
|
|
if( bezt->vec[1][0] > (bezt+1)->vec[1][0]) {
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void correct_bezpart(float *v1, float *v2, float *v3, float *v4)
|
|
|
|
|
{
|
2003-04-26 11:56:44 +00:00
|
|
|
/* the total length of the handles is not allowed to be more
|
|
|
|
|
* than the horizontal distance between (v1-v4)
|
|
|
|
|
* this to prevent curve loops
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
float h1[2], h2[2], len1, len2, len, fac;
|
|
|
|
|
|
|
|
|
|
h1[0]= v1[0]-v2[0];
|
|
|
|
|
h1[1]= v1[1]-v2[1];
|
|
|
|
|
h2[0]= v4[0]-v3[0];
|
|
|
|
|
h2[1]= v4[1]-v3[1];
|
|
|
|
|
|
|
|
|
|
len= v4[0]- v1[0];
|
|
|
|
|
len1= (float)fabs(h1[0]);
|
|
|
|
|
len2= (float)fabs(h2[0]);
|
|
|
|
|
|
|
|
|
|
if(len1+len2==0.0) return;
|
|
|
|
|
if(len1+len2 > len) {
|
|
|
|
|
fac= len/(len1+len2);
|
|
|
|
|
|
|
|
|
|
v2[0]= (v1[0]-fac*h1[0]);
|
|
|
|
|
v2[1]= (v1[1]-fac*h1[1]);
|
|
|
|
|
|
|
|
|
|
v3[0]= (v4[0]-fac*h2[0]);
|
|
|
|
|
v3[1]= (v4[1]-fac*h2[1]);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* *********************** ARITH *********************** */
|
|
|
|
|
|
|
|
|
|
int findzero(float x, float q0, float q1, float q2, float q3, float *o)
|
|
|
|
|
{
|
|
|
|
|
double c0, c1, c2, c3, a, b, c, p, q, d, t, phi;
|
|
|
|
|
int nr= 0;
|
|
|
|
|
|
|
|
|
|
c0= q0-x;
|
|
|
|
|
c1= 3*(q1-q0);
|
|
|
|
|
c2= 3*(q0-2*q1+q2);
|
|
|
|
|
c3= q3-q0+3*(q1-q2);
|
|
|
|
|
|
|
|
|
|
if(c3!=0.0) {
|
|
|
|
|
a= c2/c3;
|
|
|
|
|
b= c1/c3;
|
|
|
|
|
c= c0/c3;
|
|
|
|
|
a= a/3;
|
|
|
|
|
|
|
|
|
|
p= b/3-a*a;
|
|
|
|
|
q= (2*a*a*a-a*b+c)/2;
|
|
|
|
|
d= q*q+p*p*p;
|
|
|
|
|
|
|
|
|
|
if(d>0.0) {
|
|
|
|
|
t= sqrt(d);
|
|
|
|
|
o[0]= (float)(Sqrt3d(-q+t)+Sqrt3d(-q-t)-a);
|
|
|
|
|
if(o[0]>= SMALL && o[0]<=1.000001) return 1;
|
|
|
|
|
else return 0;
|
|
|
|
|
}
|
|
|
|
|
else if(d==0.0) {
|
|
|
|
|
t= Sqrt3d(-q);
|
|
|
|
|
o[0]= (float)(2*t-a);
|
|
|
|
|
if(o[0]>=SMALL && o[0]<=1.000001) nr++;
|
|
|
|
|
o[nr]= (float)(-t-a);
|
|
|
|
|
if(o[nr]>=SMALL && o[nr]<=1.000001) return nr+1;
|
|
|
|
|
else return nr;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
phi= acos(-q/sqrt(-(p*p*p)));
|
|
|
|
|
t= sqrt(-p);
|
|
|
|
|
p= cos(phi/3);
|
|
|
|
|
q= sqrt(3-3*p*p);
|
|
|
|
|
o[0]= (float)(2*t*p-a);
|
|
|
|
|
if(o[0]>=SMALL && o[0]<=1.000001) nr++;
|
|
|
|
|
o[nr]= (float)(-t*(p+q)-a);
|
|
|
|
|
if(o[nr]>=SMALL && o[nr]<=1.000001) nr++;
|
|
|
|
|
o[nr]= (float)(-t*(p-q)-a);
|
|
|
|
|
if(o[nr]>=SMALL && o[nr]<=1.000001) return nr+1;
|
|
|
|
|
else return nr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
a=c2;
|
|
|
|
|
b=c1;
|
|
|
|
|
c=c0;
|
|
|
|
|
|
|
|
|
|
if(a!=0.0) {
|
|
|
|
|
p=b*b-4*a*c;
|
|
|
|
|
if(p>0) {
|
|
|
|
|
p= sqrt(p);
|
|
|
|
|
o[0]= (float)((-b-p)/(2*a));
|
|
|
|
|
if(o[0]>=SMALL && o[0]<=1.000001) nr++;
|
|
|
|
|
o[nr]= (float)((-b+p)/(2*a));
|
|
|
|
|
if(o[nr]>=SMALL && o[nr]<=1.000001) return nr+1;
|
|
|
|
|
else return nr;
|
|
|
|
|
}
|
|
|
|
|
else if(p==0) {
|
|
|
|
|
o[0]= (float)(-b/(2*a));
|
|
|
|
|
if(o[0]>=SMALL && o[0]<=1.000001) return 1;
|
|
|
|
|
else return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if(b!=0.0) {
|
|
|
|
|
o[0]= (float)(-c/b);
|
|
|
|
|
if(o[0]>=SMALL && o[0]<=1.000001) return 1;
|
|
|
|
|
else return 0;
|
|
|
|
|
}
|
|
|
|
|
else if(c==0.0) {
|
|
|
|
|
o[0]= 0.0;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void berekeny(float f1, float f2, float f3, float f4, float *o, int b)
|
|
|
|
|
{
|
|
|
|
|
float t, c0, c1, c2, c3;
|
|
|
|
|
int a;
|
|
|
|
|
|
|
|
|
|
c0= f1;
|
|
|
|
|
c1= 3.0f*(f2 - f1);
|
|
|
|
|
c2= 3.0f*(f1 - 2.0f*f2 + f3);
|
|
|
|
|
c3= f4 - f1 + 3.0f*(f2-f3);
|
|
|
|
|
|
|
|
|
|
for(a=0; a<b; a++) {
|
|
|
|
|
t= o[a];
|
|
|
|
|
o[a]= c0+t*c1+t*t*c2+t*t*t*c3;
|
|
|
|
|
}
|
|
|
|
|
}
|
2005-10-30 20:56:19 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
void berekenx(float *f, float *o, int b)
|
|
|
|
|
{
|
|
|
|
|
float t, c0, c1, c2, c3;
|
|
|
|
|
int a;
|
|
|
|
|
|
|
|
|
|
c0= f[0];
|
|
|
|
|
c1= 3*(f[3]-f[0]);
|
|
|
|
|
c2= 3*(f[0]-2*f[3]+f[6]);
|
|
|
|
|
c3= f[9]-f[0]+3*(f[3]-f[6]);
|
|
|
|
|
for(a=0; a<b; a++) {
|
|
|
|
|
t= o[a];
|
|
|
|
|
o[a]= c0+t*c1+t*t*c2+t*t*t*c3;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-01 10:48:33 +00:00
|
|
|
/* we need the local transform = current transform - (parent transform + bone transform) */
|
|
|
|
|
/* (local transform is on action channel level) */
|
|
|
|
|
static void posechannel_get_local_transform(bPoseChannel *pchan, float *loc, float *eul, float *size)
|
2007-11-04 17:14:39 +00:00
|
|
|
{
|
2007-12-01 10:48:33 +00:00
|
|
|
float diff_mat[4][4];
|
|
|
|
|
float parmat[4][4], offs_bone[4][4], imat[4][4];
|
2007-11-04 17:14:39 +00:00
|
|
|
|
|
|
|
|
if (pchan->parent) {
|
2007-12-01 10:48:33 +00:00
|
|
|
/* get first the parent + bone transform in parmat */
|
2007-11-04 17:14:39 +00:00
|
|
|
|
2007-12-01 10:48:33 +00:00
|
|
|
/* bone transform itself */
|
|
|
|
|
Mat4CpyMat3(offs_bone, pchan->bone->bone_mat);
|
|
|
|
|
/* The bone's root offset (is in the parent's coordinate system) */
|
|
|
|
|
VECCOPY(offs_bone[3], pchan->bone->head);
|
|
|
|
|
/* Get the length translation of parent (length along y axis) */
|
|
|
|
|
offs_bone[3][1]+= pchan->parent->bone->length;
|
|
|
|
|
|
|
|
|
|
Mat4MulSerie(parmat, pchan->parent->pose_mat, offs_bone, NULL, NULL, NULL, NULL, NULL, NULL);
|
|
|
|
|
|
|
|
|
|
/* invert it */
|
|
|
|
|
Mat4Invert(imat, parmat);
|
2007-11-04 17:14:39 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2007-12-01 10:48:33 +00:00
|
|
|
Mat4CpyMat3(offs_bone, pchan->bone->bone_mat);
|
|
|
|
|
VECCOPY(offs_bone[3], pchan->bone->head);
|
|
|
|
|
|
|
|
|
|
/* invert it */
|
|
|
|
|
Mat4Invert(imat, offs_bone);
|
|
|
|
|
|
2007-11-04 17:14:39 +00:00
|
|
|
}
|
|
|
|
|
|
2007-12-01 10:48:33 +00:00
|
|
|
/* difference: current transform - (parent transform + bone transform) */
|
|
|
|
|
Mat4MulMat4(diff_mat, pchan->pose_mat, imat);
|
|
|
|
|
|
|
|
|
|
if(loc)
|
|
|
|
|
VECCOPY(loc, diff_mat[3]);
|
2007-11-04 17:14:39 +00:00
|
|
|
if(eul)
|
2007-12-01 10:48:33 +00:00
|
|
|
Mat4ToEul(diff_mat, eul);
|
2007-11-04 17:14:39 +00:00
|
|
|
if(size)
|
2007-12-01 10:48:33 +00:00
|
|
|
Mat4ToSize(diff_mat, size);
|
|
|
|
|
|
2007-11-04 17:14:39 +00:00
|
|
|
}
|
|
|
|
|
|
2005-10-30 20:56:19 +00:00
|
|
|
/* has to return a float value */
|
2006-06-23 12:15:22 +00:00
|
|
|
static float eval_driver(IpoDriver *driver, float ipotime)
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
{
|
2005-10-30 20:56:19 +00:00
|
|
|
|
2006-04-30 16:22:31 +00:00
|
|
|
if(driver->type == IPO_DRIVER_TYPE_PYTHON) {
|
|
|
|
|
/* check for empty or invalid expression */
|
|
|
|
|
if ((driver->name[0] == '\0') ||
|
|
|
|
|
(driver->flag & IPO_DRIVER_FLAG_INVALID))
|
|
|
|
|
return 0.0f;
|
|
|
|
|
/* this evals the expression and returns its result:
|
|
|
|
|
* (on errors it reports, then returns 0.0f) */
|
|
|
|
|
return BPY_pydriver_eval(driver);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
}
|
2005-10-30 20:56:19 +00:00
|
|
|
else {
|
|
|
|
|
Object *ob= driver->ob;
|
2006-04-30 16:22:31 +00:00
|
|
|
|
2005-10-30 20:56:19 +00:00
|
|
|
if(ob==NULL) return 0.0f;
|
2006-11-30 15:54:21 +00:00
|
|
|
if(ob->proxy_from)
|
|
|
|
|
ob= ob->proxy_from;
|
2005-10-30 20:56:19 +00:00
|
|
|
|
|
|
|
|
if(driver->blocktype==ID_OB) {
|
2006-06-26 11:29:33 +00:00
|
|
|
/* depsgraph failure; ob ipos are calculated in where_is_object, this might get called too late */
|
|
|
|
|
if(ob->ipo && ob->ctime!=ipotime) {
|
|
|
|
|
calc_ipo_spec(ob->ipo, driver->adrcode, &ipotime);
|
|
|
|
|
return ipotime;
|
|
|
|
|
}
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
switch(driver->adrcode) {
|
|
|
|
|
case OB_LOC_X:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->loc[0];
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_LOC_Y:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->loc[1];
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_LOC_Z:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->loc[2];
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_ROT_X:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->rot[0]/(M_PI_2/9.0);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_ROT_Y:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->rot[1]/(M_PI_2/9.0);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_ROT_Z:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->rot[2]/(M_PI_2/9.0);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_SIZE_X:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->size[0];
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_SIZE_Y:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->size[1];
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
case OB_SIZE_Z:
|
2005-10-30 20:56:19 +00:00
|
|
|
return ob->size[2];
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
}
|
|
|
|
|
}
|
2005-10-30 20:56:19 +00:00
|
|
|
else { /* ID_AR */
|
|
|
|
|
bPoseChannel *pchan= get_pose_channel(ob->pose, driver->name);
|
|
|
|
|
if(pchan && pchan->bone) {
|
|
|
|
|
|
2007-11-04 17:14:39 +00:00
|
|
|
/* rotation difference is not a simple driver (i.e. value drives value), but the angle between 2 bones is driving stuff... which is useful */
|
|
|
|
|
if(driver->adrcode==OB_ROT_DIFF) {
|
|
|
|
|
bPoseChannel *pchan2= get_pose_channel(ob->pose, driver->name+DRIVER_NAME_OFFS);
|
|
|
|
|
if(pchan2 && pchan2->bone) {
|
|
|
|
|
float q1[4], q2[4], quat[4], angle;
|
|
|
|
|
|
2007-11-04 19:41:21 +00:00
|
|
|
Mat4ToQuat(pchan->pose_mat, q1);
|
|
|
|
|
Mat4ToQuat(pchan2->pose_mat, q2);
|
2007-11-04 17:14:39 +00:00
|
|
|
|
|
|
|
|
QuatInv(q1);
|
|
|
|
|
QuatMul(quat, q1, q2);
|
|
|
|
|
angle = 2.0f * (saacos(quat[0]));
|
|
|
|
|
angle= ABS(angle);
|
|
|
|
|
|
|
|
|
|
return angle>M_PI?2.0f*M_PI-angle:angle;
|
|
|
|
|
}
|
2005-10-30 20:56:19 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2007-12-01 10:48:33 +00:00
|
|
|
float loc[3], eul[3], size[3];
|
2007-11-04 17:14:39 +00:00
|
|
|
|
2007-12-01 10:48:33 +00:00
|
|
|
posechannel_get_local_transform(pchan, loc, eul, size);
|
2007-11-04 17:14:39 +00:00
|
|
|
|
|
|
|
|
switch(driver->adrcode) {
|
|
|
|
|
case OB_LOC_X:
|
2007-12-01 10:48:33 +00:00
|
|
|
return loc[0];
|
2007-11-04 17:14:39 +00:00
|
|
|
case OB_LOC_Y:
|
2007-12-01 10:48:33 +00:00
|
|
|
return loc[1];
|
2007-11-04 17:14:39 +00:00
|
|
|
case OB_LOC_Z:
|
2007-12-01 10:48:33 +00:00
|
|
|
return loc[2];
|
2007-11-04 17:14:39 +00:00
|
|
|
case OB_ROT_X:
|
|
|
|
|
return eul[0]/(M_PI_2/9.0);
|
|
|
|
|
case OB_ROT_Y:
|
|
|
|
|
return eul[1]/(M_PI_2/9.0);
|
|
|
|
|
case OB_ROT_Z:
|
|
|
|
|
return eul[2]/(M_PI_2/9.0);
|
|
|
|
|
case OB_SIZE_X:
|
|
|
|
|
return size[0];
|
|
|
|
|
case OB_SIZE_Y:
|
|
|
|
|
return size[1];
|
|
|
|
|
case OB_SIZE_Z:
|
|
|
|
|
return size[2];
|
|
|
|
|
}
|
2005-10-30 20:56:19 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
return 0.0f;
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
float eval_icu(IpoCurve *icu, float ipotime)
|
|
|
|
|
{
|
|
|
|
|
BezTriple *bezt, *prevbezt;
|
|
|
|
|
float v1[2], v2[2], v3[2], v4[2], opl[32], dx, fac;
|
|
|
|
|
float cycdx, cycdy, ofs, cycyofs, cvalue = 0.0;
|
|
|
|
|
int a, b;
|
|
|
|
|
|
|
|
|
|
cycyofs= 0.0;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(icu->driver) {
|
|
|
|
|
/* ipotime now serves as input for the curve */
|
2006-06-23 12:15:22 +00:00
|
|
|
ipotime= cvalue= eval_driver(icu->driver, ipotime);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
if(icu->bezt) {
|
|
|
|
|
prevbezt= icu->bezt;
|
|
|
|
|
bezt= prevbezt+1;
|
|
|
|
|
a= icu->totvert-1;
|
|
|
|
|
|
|
|
|
|
/* cyclic? */
|
|
|
|
|
if(icu->extrap & IPO_CYCL) {
|
|
|
|
|
ofs= icu->bezt->vec[1][0];
|
|
|
|
|
cycdx= (icu->bezt+icu->totvert-1)->vec[1][0] - ofs;
|
|
|
|
|
cycdy= (icu->bezt+icu->totvert-1)->vec[1][1] - icu->bezt->vec[1][1];
|
|
|
|
|
if(cycdx!=0.0) {
|
|
|
|
|
|
|
|
|
|
if(icu->extrap & IPO_DIR) {
|
|
|
|
|
cycyofs= (float)floor((ipotime-ofs)/cycdx);
|
|
|
|
|
cycyofs*= cycdy;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ipotime= (float)(fmod(ipotime-ofs, cycdx)+ofs);
|
|
|
|
|
if(ipotime<ofs) ipotime+= cycdx;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* endpoints? */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
if(prevbezt->vec[1][0]>=ipotime) {
|
|
|
|
|
if( (icu->extrap & IPO_DIR) && icu->ipo!=IPO_CONST) {
|
2008-09-27 10:08:19 +00:00
|
|
|
if (icu->ipo==IPO_LIN) {
|
|
|
|
|
if (icu->totvert==1) cvalue= prevbezt->vec[1][1];
|
|
|
|
|
else {
|
|
|
|
|
/* use the next center point instead of our own handle for
|
|
|
|
|
* linear interpolated extrapolate */
|
|
|
|
|
bezt = prevbezt+1;
|
|
|
|
|
dx= prevbezt->vec[1][0]-ipotime;
|
|
|
|
|
fac= bezt->vec[1][0]-prevbezt->vec[1][0];
|
|
|
|
|
if(fac!=0.0) {
|
|
|
|
|
fac= (bezt->vec[1][1]-prevbezt->vec[1][1])/fac;
|
|
|
|
|
cvalue= prevbezt->vec[1][1]-fac*dx;
|
|
|
|
|
}
|
|
|
|
|
else cvalue= prevbezt->vec[1][1];
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
dx= prevbezt->vec[1][0]-ipotime;
|
|
|
|
|
fac= prevbezt->vec[1][0]-prevbezt->vec[0][0];
|
|
|
|
|
if(fac!=0.0) {
|
|
|
|
|
fac= (prevbezt->vec[1][1]-prevbezt->vec[0][1])/fac;
|
|
|
|
|
cvalue= prevbezt->vec[1][1]-fac*dx;
|
|
|
|
|
}
|
|
|
|
|
else cvalue= prevbezt->vec[1][1];
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else cvalue= prevbezt->vec[1][1];
|
|
|
|
|
|
|
|
|
|
cvalue+= cycyofs;
|
|
|
|
|
}
|
|
|
|
|
else if( (prevbezt+a)->vec[1][0]<=ipotime) {
|
2008-09-28 15:37:37 +00:00
|
|
|
if( (icu->extrap & IPO_DIR) && icu->ipo!=IPO_CONST) {
|
2002-10-12 11:37:38 +00:00
|
|
|
prevbezt+= a;
|
2008-09-27 10:08:19 +00:00
|
|
|
|
|
|
|
|
if (icu->ipo==IPO_LIN) {
|
|
|
|
|
if (icu->totvert==1) cvalue= prevbezt->vec[1][1];
|
|
|
|
|
else {
|
|
|
|
|
/* use the previous center point instead of our own handle for
|
|
|
|
|
* linear interpolated extrapolate */
|
|
|
|
|
bezt = prevbezt-1;
|
|
|
|
|
dx= ipotime-prevbezt->vec[1][0];
|
|
|
|
|
fac= prevbezt->vec[1][0]-bezt->vec[1][0];
|
|
|
|
|
|
|
|
|
|
if(fac!=0) {
|
|
|
|
|
fac= (prevbezt->vec[1][1]-bezt->vec[1][1])/fac;
|
|
|
|
|
cvalue= prevbezt->vec[1][1]+fac*dx;
|
|
|
|
|
}
|
|
|
|
|
else cvalue= prevbezt->vec[1][1];
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
dx= ipotime-prevbezt->vec[1][0];
|
|
|
|
|
fac= prevbezt->vec[2][0]-prevbezt->vec[1][0];
|
2004-06-26 18:18:11 +00:00
|
|
|
|
2008-09-27 10:08:19 +00:00
|
|
|
if(fac!=0) {
|
|
|
|
|
fac= (prevbezt->vec[2][1]-prevbezt->vec[1][1])/fac;
|
|
|
|
|
cvalue= prevbezt->vec[1][1]+fac*dx;
|
|
|
|
|
}
|
|
|
|
|
else cvalue= prevbezt->vec[1][1];
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else cvalue= (prevbezt+a)->vec[1][1];
|
|
|
|
|
|
|
|
|
|
cvalue+= cycyofs;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
while(a--) {
|
|
|
|
|
if(prevbezt->vec[1][0]<=ipotime && bezt->vec[1][0]>=ipotime) {
|
|
|
|
|
if(icu->ipo==IPO_CONST) {
|
|
|
|
|
cvalue= prevbezt->vec[1][1]+cycyofs;
|
|
|
|
|
}
|
|
|
|
|
else if(icu->ipo==IPO_LIN) {
|
|
|
|
|
fac= bezt->vec[1][0]-prevbezt->vec[1][0];
|
|
|
|
|
if(fac==0) cvalue= cycyofs+prevbezt->vec[1][1];
|
|
|
|
|
else {
|
|
|
|
|
fac= (ipotime-prevbezt->vec[1][0])/fac;
|
|
|
|
|
cvalue= cycyofs+prevbezt->vec[1][1]+ fac*(bezt->vec[1][1]-prevbezt->vec[1][1]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
v1[0]= prevbezt->vec[1][0];
|
|
|
|
|
v1[1]= prevbezt->vec[1][1];
|
|
|
|
|
v2[0]= prevbezt->vec[2][0];
|
|
|
|
|
v2[1]= prevbezt->vec[2][1];
|
|
|
|
|
|
|
|
|
|
v3[0]= bezt->vec[0][0];
|
|
|
|
|
v3[1]= bezt->vec[0][1];
|
|
|
|
|
v4[0]= bezt->vec[1][0];
|
|
|
|
|
v4[1]= bezt->vec[1][1];
|
|
|
|
|
|
|
|
|
|
correct_bezpart(v1, v2, v3, v4);
|
|
|
|
|
|
|
|
|
|
b= findzero(ipotime, v1[0], v2[0], v3[0], v4[0], opl);
|
|
|
|
|
if(b) {
|
|
|
|
|
berekeny(v1[1], v2[1], v3[1], v4[1], opl, 1);
|
|
|
|
|
cvalue= opl[0]+cycyofs;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
prevbezt= bezt;
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(icu->ymin < icu->ymax) {
|
|
|
|
|
if(cvalue < icu->ymin) cvalue= icu->ymin;
|
|
|
|
|
else if(cvalue > icu->ymax) cvalue= icu->ymax;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return cvalue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void calc_icu(IpoCurve *icu, float ctime)
|
|
|
|
|
{
|
|
|
|
|
icu->curval= eval_icu(icu, ctime);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
float calc_ipo_time(Ipo *ipo, float ctime)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if(ipo && ipo->blocktype==ID_OB) {
|
|
|
|
|
IpoCurve *icu= ipo->curve.first;
|
|
|
|
|
|
|
|
|
|
while(icu) {
|
|
|
|
|
if (icu->adrcode==OB_TIME) {
|
|
|
|
|
calc_icu(icu, ctime);
|
|
|
|
|
return 10.0f*icu->curval;
|
|
|
|
|
}
|
|
|
|
|
icu= icu->next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ctime;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void calc_ipo(Ipo *ipo, float ctime)
|
|
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return;
|
2007-06-22 11:09:31 +00:00
|
|
|
if(ipo->muteipo) return;
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2007-06-22 11:09:31 +00:00
|
|
|
if(icu->driver || (icu->flag & IPO_LOCK)==0) {
|
|
|
|
|
if((icu->flag & IPO_MUTE)==0)
|
|
|
|
|
calc_icu(icu, ctime);
|
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ************************************** */
|
|
|
|
|
/* DO THE IPO! */
|
|
|
|
|
/* ************************************** */
|
|
|
|
|
|
|
|
|
|
void write_ipo_poin(void *poin, int type, float val)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
switch(type) {
|
|
|
|
|
case IPO_FLOAT:
|
|
|
|
|
*( (float *)poin)= val;
|
|
|
|
|
break;
|
|
|
|
|
case IPO_FLOAT_DEGR:
|
|
|
|
|
*( (float *)poin)= (float)(val*M_PI_2/9.0);
|
|
|
|
|
break;
|
|
|
|
|
case IPO_INT:
|
|
|
|
|
case IPO_INT_BIT:
|
|
|
|
|
case IPO_LONG:
|
|
|
|
|
*( (int *)poin)= (int)val;
|
|
|
|
|
break;
|
|
|
|
|
case IPO_SHORT:
|
|
|
|
|
case IPO_SHORT_BIT:
|
|
|
|
|
*( (short *)poin)= (short)val;
|
|
|
|
|
break;
|
|
|
|
|
case IPO_CHAR:
|
|
|
|
|
case IPO_CHAR_BIT:
|
|
|
|
|
*( (char *)poin)= (char)val;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
float read_ipo_poin(void *poin, int type)
|
|
|
|
|
{
|
|
|
|
|
float val = 0.0;
|
|
|
|
|
|
|
|
|
|
switch(type) {
|
|
|
|
|
case IPO_FLOAT:
|
|
|
|
|
val= *( (float *)poin);
|
|
|
|
|
break;
|
|
|
|
|
case IPO_FLOAT_DEGR:
|
|
|
|
|
val= *( (float *)poin);
|
|
|
|
|
val = (float)(val/(M_PI_2/9.0));
|
|
|
|
|
break;
|
|
|
|
|
case IPO_INT:
|
|
|
|
|
case IPO_INT_BIT:
|
|
|
|
|
case IPO_LONG:
|
|
|
|
|
val= (float)(*( (int *)poin));
|
|
|
|
|
break;
|
|
|
|
|
case IPO_SHORT:
|
|
|
|
|
case IPO_SHORT_BIT:
|
|
|
|
|
val= *( (short *)poin);
|
|
|
|
|
break;
|
|
|
|
|
case IPO_CHAR:
|
|
|
|
|
case IPO_CHAR_BIT:
|
|
|
|
|
val= *( (char *)poin);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2005-03-09 19:45:59 +00:00
|
|
|
static void *give_tex_poin(Tex *tex, int adrcode, int *type )
|
2004-07-26 21:44:55 +00:00
|
|
|
{
|
|
|
|
|
void *poin=0;
|
|
|
|
|
|
|
|
|
|
switch(adrcode) {
|
|
|
|
|
case TE_NSIZE:
|
|
|
|
|
poin= &(tex->noisesize); break;
|
|
|
|
|
case TE_TURB:
|
|
|
|
|
poin= &(tex->turbul); break;
|
|
|
|
|
case TE_NDEPTH:
|
|
|
|
|
poin= &(tex->noisedepth); *type= IPO_SHORT; break;
|
|
|
|
|
case TE_NTYPE:
|
|
|
|
|
poin= &(tex->noisetype); *type= IPO_SHORT; break;
|
|
|
|
|
case TE_VNW1:
|
|
|
|
|
poin= &(tex->vn_w1); break;
|
|
|
|
|
case TE_VNW2:
|
|
|
|
|
poin= &(tex->vn_w2); break;
|
|
|
|
|
case TE_VNW3:
|
|
|
|
|
poin= &(tex->vn_w3); break;
|
|
|
|
|
case TE_VNW4:
|
|
|
|
|
poin= &(tex->vn_w4); break;
|
|
|
|
|
case TE_VNMEXP:
|
|
|
|
|
poin= &(tex->vn_mexp); break;
|
|
|
|
|
case TE_ISCA:
|
|
|
|
|
poin= &(tex->ns_outscale); break;
|
|
|
|
|
case TE_DISTA:
|
|
|
|
|
poin= &(tex->dist_amount); break;
|
|
|
|
|
case TE_VN_COLT:
|
|
|
|
|
poin= &(tex->vn_coltype); *type= IPO_SHORT; break;
|
|
|
|
|
case TE_VN_DISTM:
|
|
|
|
|
poin= &(tex->vn_distm); *type= IPO_SHORT; break;
|
|
|
|
|
case TE_MG_TYP:
|
|
|
|
|
poin= &(tex->stype); *type= IPO_SHORT; break;
|
|
|
|
|
case TE_MGH:
|
|
|
|
|
poin= &(tex->mg_H); break;
|
|
|
|
|
case TE_MG_LAC:
|
|
|
|
|
poin= &(tex->mg_lacunarity); break;
|
|
|
|
|
case TE_MG_OCT:
|
|
|
|
|
poin= &(tex->mg_octaves); break;
|
|
|
|
|
case TE_MG_OFF:
|
|
|
|
|
poin= &(tex->mg_offset); break;
|
|
|
|
|
case TE_MG_GAIN:
|
|
|
|
|
poin= &(tex->mg_gain); break;
|
|
|
|
|
case TE_N_BAS1:
|
|
|
|
|
poin= &(tex->noisebasis); *type= IPO_SHORT; break;
|
|
|
|
|
case TE_N_BAS2:
|
|
|
|
|
poin= &(tex->noisebasis2); *type= IPO_SHORT; break;
|
2006-01-06 13:33:20 +00:00
|
|
|
case TE_COL_R:
|
|
|
|
|
poin= &(tex->rfac); break;
|
|
|
|
|
case TE_COL_G:
|
|
|
|
|
poin= &(tex->gfac); break;
|
|
|
|
|
case TE_COL_B:
|
|
|
|
|
poin= &(tex->bfac); break;
|
|
|
|
|
case TE_BRIGHT:
|
|
|
|
|
poin= &(tex->bright); break;
|
|
|
|
|
case TE_CONTRA:
|
|
|
|
|
poin= &(tex->contrast); break;
|
|
|
|
|
|
2004-07-26 21:44:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return poin;
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
void *give_mtex_poin(MTex *mtex, int adrcode )
|
|
|
|
|
{
|
|
|
|
|
void *poin=0;
|
|
|
|
|
|
|
|
|
|
switch(adrcode) {
|
|
|
|
|
case MAP_OFS_X:
|
|
|
|
|
poin= &(mtex->ofs[0]); break;
|
|
|
|
|
case MAP_OFS_Y:
|
|
|
|
|
poin= &(mtex->ofs[1]); break;
|
|
|
|
|
case MAP_OFS_Z:
|
|
|
|
|
poin= &(mtex->ofs[2]); break;
|
|
|
|
|
case MAP_SIZE_X:
|
|
|
|
|
poin= &(mtex->size[0]); break;
|
|
|
|
|
case MAP_SIZE_Y:
|
|
|
|
|
poin= &(mtex->size[1]); break;
|
|
|
|
|
case MAP_SIZE_Z:
|
|
|
|
|
poin= &(mtex->size[2]); break;
|
|
|
|
|
case MAP_R:
|
|
|
|
|
poin= &(mtex->r); break;
|
|
|
|
|
case MAP_G:
|
|
|
|
|
poin= &(mtex->g); break;
|
|
|
|
|
case MAP_B:
|
|
|
|
|
poin= &(mtex->b); break;
|
|
|
|
|
case MAP_DVAR:
|
|
|
|
|
poin= &(mtex->def_var); break;
|
|
|
|
|
case MAP_COLF:
|
|
|
|
|
poin= &(mtex->colfac); break;
|
|
|
|
|
case MAP_NORF:
|
|
|
|
|
poin= &(mtex->norfac); break;
|
|
|
|
|
case MAP_VARF:
|
|
|
|
|
poin= &(mtex->varfac); break;
|
2004-07-05 09:15:02 +00:00
|
|
|
case MAP_DISP:
|
|
|
|
|
poin= &(mtex->dispfac); break;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return poin;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* GS reads the memory pointed at in a specific ordering. There are,
|
|
|
|
|
* however two definitions for it. I have jotted them down here, both,
|
|
|
|
|
* but I think the first one is actually used. The thing is that
|
|
|
|
|
* big-endian systems might read this the wrong way round. OTOH, we
|
|
|
|
|
* constructed the IDs that are read out with this macro explicitly as
|
|
|
|
|
* well. I expect we'll sort it out soon... */
|
|
|
|
|
|
|
|
|
|
/* from blendef: */
|
|
|
|
|
#define GS(a) (*((short *)(a)))
|
|
|
|
|
|
|
|
|
|
/* from misc_util: flip the bytes from x */
|
|
|
|
|
/* #define GS(x) (((unsigned char *)(x))[0] << 8 | ((unsigned char *)(x))[1]) */
|
|
|
|
|
|
|
|
|
|
void *get_ipo_poin(ID *id, IpoCurve *icu, int *type)
|
|
|
|
|
{
|
2004-06-26 18:18:11 +00:00
|
|
|
void *poin= NULL;
|
2002-10-12 11:37:38 +00:00
|
|
|
Object *ob;
|
|
|
|
|
Material *ma;
|
|
|
|
|
MTex *mtex;
|
2004-07-26 21:44:55 +00:00
|
|
|
Tex *tex;
|
2002-10-12 11:37:38 +00:00
|
|
|
Lamp *la;
|
|
|
|
|
Sequence *seq;
|
|
|
|
|
World *wo;
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
ParticleSettings *part;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
*type= IPO_FLOAT;
|
|
|
|
|
|
|
|
|
|
if( GS(id->name)==ID_OB) {
|
2005-10-10 18:05:30 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
ob= (Object *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case OB_LOC_X:
|
|
|
|
|
poin= &(ob->loc[0]); break;
|
|
|
|
|
case OB_LOC_Y:
|
|
|
|
|
poin= &(ob->loc[1]); break;
|
|
|
|
|
case OB_LOC_Z:
|
|
|
|
|
poin= &(ob->loc[2]); break;
|
|
|
|
|
case OB_DLOC_X:
|
|
|
|
|
poin= &(ob->dloc[0]); break;
|
|
|
|
|
case OB_DLOC_Y:
|
|
|
|
|
poin= &(ob->dloc[1]); break;
|
|
|
|
|
case OB_DLOC_Z:
|
|
|
|
|
poin= &(ob->dloc[2]); break;
|
|
|
|
|
|
|
|
|
|
case OB_ROT_X:
|
|
|
|
|
poin= &(ob->rot[0]); *type= IPO_FLOAT_DEGR; break;
|
|
|
|
|
case OB_ROT_Y:
|
|
|
|
|
poin= &(ob->rot[1]); *type= IPO_FLOAT_DEGR; break;
|
|
|
|
|
case OB_ROT_Z:
|
|
|
|
|
poin= &(ob->rot[2]); *type= IPO_FLOAT_DEGR; break;
|
|
|
|
|
case OB_DROT_X:
|
|
|
|
|
poin= &(ob->drot[0]); *type= IPO_FLOAT_DEGR; break;
|
|
|
|
|
case OB_DROT_Y:
|
|
|
|
|
poin= &(ob->drot[1]); *type= IPO_FLOAT_DEGR; break;
|
|
|
|
|
case OB_DROT_Z:
|
|
|
|
|
poin= &(ob->drot[2]); *type= IPO_FLOAT_DEGR; break;
|
|
|
|
|
|
|
|
|
|
case OB_SIZE_X:
|
|
|
|
|
poin= &(ob->size[0]); break;
|
|
|
|
|
case OB_SIZE_Y:
|
|
|
|
|
poin= &(ob->size[1]); break;
|
|
|
|
|
case OB_SIZE_Z:
|
|
|
|
|
poin= &(ob->size[2]); break;
|
|
|
|
|
case OB_DSIZE_X:
|
|
|
|
|
poin= &(ob->dsize[0]); break;
|
|
|
|
|
case OB_DSIZE_Y:
|
|
|
|
|
poin= &(ob->dsize[1]); break;
|
|
|
|
|
case OB_DSIZE_Z:
|
|
|
|
|
poin= &(ob->dsize[2]); break;
|
2004-06-26 18:18:11 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
case OB_LAY:
|
|
|
|
|
poin= &(ob->lay); *type= IPO_INT_BIT; break;
|
|
|
|
|
|
2004-06-26 18:18:11 +00:00
|
|
|
case OB_COL_R:
|
|
|
|
|
poin= &(ob->col[0]);
|
2002-10-12 11:37:38 +00:00
|
|
|
break;
|
2004-06-26 18:18:11 +00:00
|
|
|
case OB_COL_G:
|
|
|
|
|
poin= &(ob->col[1]);
|
2002-10-12 11:37:38 +00:00
|
|
|
break;
|
2004-06-26 18:18:11 +00:00
|
|
|
case OB_COL_B:
|
|
|
|
|
poin= &(ob->col[2]);
|
2002-10-12 11:37:38 +00:00
|
|
|
break;
|
|
|
|
|
case OB_COL_A:
|
|
|
|
|
poin= &(ob->col[3]);
|
|
|
|
|
break;
|
2004-06-26 18:18:11 +00:00
|
|
|
case OB_PD_FSTR:
|
|
|
|
|
if(ob->pd) poin= &(ob->pd->f_strength);
|
|
|
|
|
break;
|
|
|
|
|
case OB_PD_FFALL:
|
|
|
|
|
if(ob->pd) poin= &(ob->pd->f_power);
|
|
|
|
|
break;
|
|
|
|
|
case OB_PD_SDAMP:
|
|
|
|
|
if(ob->pd) poin= &(ob->pd->pdef_damp);
|
|
|
|
|
break;
|
|
|
|
|
case OB_PD_RDAMP:
|
|
|
|
|
if(ob->pd) poin= &(ob->pd->pdef_rdamp);
|
|
|
|
|
break;
|
|
|
|
|
case OB_PD_PERM:
|
|
|
|
|
if(ob->pd) poin= &(ob->pd->pdef_perm);
|
|
|
|
|
break;
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
case OB_PD_FMAXD:
|
|
|
|
|
if(ob->pd) poin= &(ob->pd->maxdist);
|
|
|
|
|
break;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if( GS(id->name)==ID_MA) {
|
|
|
|
|
|
|
|
|
|
ma= (Material *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case MA_COL_R:
|
|
|
|
|
poin= &(ma->r); break;
|
|
|
|
|
case MA_COL_G:
|
|
|
|
|
poin= &(ma->g); break;
|
|
|
|
|
case MA_COL_B:
|
|
|
|
|
poin= &(ma->b); break;
|
|
|
|
|
case MA_SPEC_R:
|
|
|
|
|
poin= &(ma->specr); break;
|
|
|
|
|
case MA_SPEC_G:
|
|
|
|
|
poin= &(ma->specg); break;
|
|
|
|
|
case MA_SPEC_B:
|
|
|
|
|
poin= &(ma->specb); break;
|
|
|
|
|
case MA_MIR_R:
|
|
|
|
|
poin= &(ma->mirr); break;
|
|
|
|
|
case MA_MIR_G:
|
|
|
|
|
poin= &(ma->mirg); break;
|
|
|
|
|
case MA_MIR_B:
|
|
|
|
|
poin= &(ma->mirb); break;
|
|
|
|
|
case MA_REF:
|
|
|
|
|
poin= &(ma->ref); break;
|
|
|
|
|
case MA_ALPHA:
|
|
|
|
|
poin= &(ma->alpha); break;
|
|
|
|
|
case MA_EMIT:
|
|
|
|
|
poin= &(ma->emit); break;
|
|
|
|
|
case MA_AMB:
|
|
|
|
|
poin= &(ma->amb); break;
|
|
|
|
|
case MA_SPEC:
|
|
|
|
|
poin= &(ma->spec); break;
|
|
|
|
|
case MA_HARD:
|
|
|
|
|
poin= &(ma->har); *type= IPO_SHORT; break;
|
|
|
|
|
case MA_SPTR:
|
|
|
|
|
poin= &(ma->spectra); break;
|
2004-07-05 09:15:02 +00:00
|
|
|
case MA_IOR:
|
2002-10-12 11:37:38 +00:00
|
|
|
poin= &(ma->ang); break;
|
|
|
|
|
case MA_MODE:
|
|
|
|
|
poin= &(ma->mode); *type= IPO_INT_BIT; break;
|
|
|
|
|
case MA_HASIZE:
|
|
|
|
|
poin= &(ma->hasize); break;
|
2004-07-05 09:15:02 +00:00
|
|
|
case MA_TRANSLU:
|
|
|
|
|
poin= &(ma->translucency); break;
|
|
|
|
|
case MA_RAYM:
|
|
|
|
|
poin= &(ma->ray_mirror); break;
|
2004-07-07 08:49:33 +00:00
|
|
|
case MA_FRESMIR:
|
|
|
|
|
poin= &(ma->fresnel_mir); break;
|
|
|
|
|
case MA_FRESMIRI:
|
|
|
|
|
poin= &(ma->fresnel_mir_i); break;
|
|
|
|
|
case MA_FRESTRA:
|
|
|
|
|
poin= &(ma->fresnel_tra); break;
|
|
|
|
|
case MA_FRESTRAI:
|
|
|
|
|
poin= &(ma->fresnel_tra_i); break;
|
|
|
|
|
case MA_ADD:
|
|
|
|
|
poin= &(ma->add); break;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(poin==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
mtex= 0;
|
|
|
|
|
if(icu->adrcode & MA_MAP1) mtex= ma->mtex[0];
|
|
|
|
|
else if(icu->adrcode & MA_MAP2) mtex= ma->mtex[1];
|
|
|
|
|
else if(icu->adrcode & MA_MAP3) mtex= ma->mtex[2];
|
|
|
|
|
else if(icu->adrcode & MA_MAP4) mtex= ma->mtex[3];
|
|
|
|
|
else if(icu->adrcode & MA_MAP5) mtex= ma->mtex[4];
|
|
|
|
|
else if(icu->adrcode & MA_MAP6) mtex= ma->mtex[5];
|
|
|
|
|
else if(icu->adrcode & MA_MAP7) mtex= ma->mtex[6];
|
|
|
|
|
else if(icu->adrcode & MA_MAP8) mtex= ma->mtex[7];
|
2004-12-04 21:49:02 +00:00
|
|
|
else if(icu->adrcode & MA_MAP9) mtex= ma->mtex[8];
|
|
|
|
|
else if(icu->adrcode & MA_MAP10) mtex= ma->mtex[9];
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 20:51:28 +00:00
|
|
|
else if(icu->adrcode & MA_MAP12) mtex= ma->mtex[11];
|
|
|
|
|
else if(icu->adrcode & MA_MAP11) mtex= ma->mtex[10];
|
|
|
|
|
else if(icu->adrcode & MA_MAP13) mtex= ma->mtex[12];
|
|
|
|
|
else if(icu->adrcode & MA_MAP14) mtex= ma->mtex[13];
|
|
|
|
|
else if(icu->adrcode & MA_MAP15) mtex= ma->mtex[14];
|
|
|
|
|
else if(icu->adrcode & MA_MAP16) mtex= ma->mtex[15];
|
|
|
|
|
else if(icu->adrcode & MA_MAP17) mtex= ma->mtex[16];
|
|
|
|
|
else if(icu->adrcode & MA_MAP18) mtex= ma->mtex[17];
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
if(mtex) {
|
|
|
|
|
poin= give_mtex_poin(mtex, icu->adrcode & (MA_MAP1-1) );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2004-07-26 21:44:55 +00:00
|
|
|
else if( GS(id->name)==ID_TE) {
|
|
|
|
|
tex= (Tex *)id;
|
|
|
|
|
|
|
|
|
|
if(tex) poin= give_tex_poin(tex, icu->adrcode, type);
|
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
else if( GS(id->name)==ID_SEQ) {
|
|
|
|
|
seq= (Sequence *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case SEQ_FAC1:
|
|
|
|
|
poin= &(seq->facf0); break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if( GS(id->name)==ID_CU) {
|
|
|
|
|
|
|
|
|
|
poin= &(icu->curval);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
else if( GS(id->name)==ID_KE) {
|
2005-10-28 08:11:15 +00:00
|
|
|
KeyBlock *kb= ((Key *)id)->block.first;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2005-10-28 08:11:15 +00:00
|
|
|
for(; kb; kb= kb->next)
|
|
|
|
|
if(kb->adrcode==icu->adrcode)
|
|
|
|
|
break;
|
|
|
|
|
if(kb)
|
|
|
|
|
poin= &(kb->curval);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
else if(GS(id->name)==ID_WO) {
|
|
|
|
|
|
|
|
|
|
wo= (World *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case WO_HOR_R:
|
|
|
|
|
poin= &(wo->horr); break;
|
|
|
|
|
case WO_HOR_G:
|
|
|
|
|
poin= &(wo->horg); break;
|
|
|
|
|
case WO_HOR_B:
|
|
|
|
|
poin= &(wo->horb); break;
|
|
|
|
|
case WO_ZEN_R:
|
|
|
|
|
poin= &(wo->zenr); break;
|
|
|
|
|
case WO_ZEN_G:
|
|
|
|
|
poin= &(wo->zeng); break;
|
|
|
|
|
case WO_ZEN_B:
|
|
|
|
|
poin= &(wo->zenb); break;
|
|
|
|
|
|
|
|
|
|
case WO_EXPOS:
|
|
|
|
|
poin= &(wo->exposure); break;
|
|
|
|
|
|
|
|
|
|
case WO_MISI:
|
|
|
|
|
poin= &(wo->misi); break;
|
|
|
|
|
case WO_MISTDI:
|
|
|
|
|
poin= &(wo->mistdist); break;
|
|
|
|
|
case WO_MISTSTA:
|
|
|
|
|
poin= &(wo->miststa); break;
|
|
|
|
|
case WO_MISTHI:
|
|
|
|
|
poin= &(wo->misthi); break;
|
|
|
|
|
|
|
|
|
|
case WO_STAR_R:
|
|
|
|
|
poin= &(wo->starr); break;
|
|
|
|
|
case WO_STAR_G:
|
|
|
|
|
poin= &(wo->starg); break;
|
|
|
|
|
case WO_STAR_B:
|
|
|
|
|
poin= &(wo->starb); break;
|
|
|
|
|
|
|
|
|
|
case WO_STARDIST:
|
|
|
|
|
poin= &(wo->stardist); break;
|
|
|
|
|
case WO_STARSIZE:
|
|
|
|
|
poin= &(wo->starsize); break;
|
|
|
|
|
}
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(poin==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
mtex= 0;
|
|
|
|
|
if(icu->adrcode & MA_MAP1) mtex= wo->mtex[0];
|
|
|
|
|
else if(icu->adrcode & MA_MAP2) mtex= wo->mtex[1];
|
|
|
|
|
else if(icu->adrcode & MA_MAP3) mtex= wo->mtex[2];
|
|
|
|
|
else if(icu->adrcode & MA_MAP4) mtex= wo->mtex[3];
|
|
|
|
|
else if(icu->adrcode & MA_MAP5) mtex= wo->mtex[4];
|
|
|
|
|
else if(icu->adrcode & MA_MAP6) mtex= wo->mtex[5];
|
|
|
|
|
else if(icu->adrcode & MA_MAP7) mtex= wo->mtex[6];
|
|
|
|
|
else if(icu->adrcode & MA_MAP8) mtex= wo->mtex[7];
|
2004-12-04 21:49:02 +00:00
|
|
|
else if(icu->adrcode & MA_MAP9) mtex= wo->mtex[8];
|
|
|
|
|
else if(icu->adrcode & MA_MAP10) mtex= wo->mtex[9];
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 20:51:28 +00:00
|
|
|
else if(icu->adrcode & MA_MAP11) mtex= wo->mtex[10];
|
|
|
|
|
else if(icu->adrcode & MA_MAP12) mtex= wo->mtex[11];
|
|
|
|
|
else if(icu->adrcode & MA_MAP13) mtex= wo->mtex[12];
|
|
|
|
|
else if(icu->adrcode & MA_MAP14) mtex= wo->mtex[13];
|
|
|
|
|
else if(icu->adrcode & MA_MAP15) mtex= wo->mtex[14];
|
|
|
|
|
else if(icu->adrcode & MA_MAP16) mtex= wo->mtex[15];
|
|
|
|
|
else if(icu->adrcode & MA_MAP17) mtex= wo->mtex[16];
|
|
|
|
|
else if(icu->adrcode & MA_MAP18) mtex= wo->mtex[17];
|
2002-10-12 11:37:38 +00:00
|
|
|
if(mtex) {
|
|
|
|
|
poin= give_mtex_poin(mtex, icu->adrcode & (MA_MAP1-1) );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if( GS(id->name)==ID_LA) {
|
|
|
|
|
|
|
|
|
|
la= (Lamp *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case LA_ENERGY:
|
|
|
|
|
poin= &(la->energy); break;
|
|
|
|
|
case LA_COL_R:
|
|
|
|
|
poin= &(la->r); break;
|
|
|
|
|
case LA_COL_G:
|
|
|
|
|
poin= &(la->g); break;
|
|
|
|
|
case LA_COL_B:
|
|
|
|
|
poin= &(la->b); break;
|
|
|
|
|
case LA_DIST:
|
|
|
|
|
poin= &(la->dist); break;
|
|
|
|
|
case LA_SPOTSI:
|
|
|
|
|
poin= &(la->spotsize); break;
|
|
|
|
|
case LA_SPOTBL:
|
|
|
|
|
poin= &(la->spotblend); break;
|
|
|
|
|
case LA_QUAD1:
|
|
|
|
|
poin= &(la->att1); break;
|
|
|
|
|
case LA_QUAD2:
|
|
|
|
|
poin= &(la->att2); break;
|
|
|
|
|
case LA_HALOINT:
|
|
|
|
|
poin= &(la->haint); break;
|
|
|
|
|
}
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(poin==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
mtex= 0;
|
|
|
|
|
if(icu->adrcode & MA_MAP1) mtex= la->mtex[0];
|
|
|
|
|
else if(icu->adrcode & MA_MAP2) mtex= la->mtex[1];
|
|
|
|
|
else if(icu->adrcode & MA_MAP3) mtex= la->mtex[2];
|
|
|
|
|
else if(icu->adrcode & MA_MAP4) mtex= la->mtex[3];
|
|
|
|
|
else if(icu->adrcode & MA_MAP5) mtex= la->mtex[4];
|
|
|
|
|
else if(icu->adrcode & MA_MAP6) mtex= la->mtex[5];
|
|
|
|
|
else if(icu->adrcode & MA_MAP7) mtex= la->mtex[6];
|
|
|
|
|
else if(icu->adrcode & MA_MAP8) mtex= la->mtex[7];
|
2004-12-04 21:49:02 +00:00
|
|
|
else if(icu->adrcode & MA_MAP9) mtex= la->mtex[8];
|
|
|
|
|
else if(icu->adrcode & MA_MAP10) mtex= la->mtex[9];
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 20:51:28 +00:00
|
|
|
else if(icu->adrcode & MA_MAP11) mtex= la->mtex[10];
|
|
|
|
|
else if(icu->adrcode & MA_MAP12) mtex= la->mtex[11];
|
|
|
|
|
else if(icu->adrcode & MA_MAP13) mtex= la->mtex[12];
|
|
|
|
|
else if(icu->adrcode & MA_MAP14) mtex= la->mtex[13];
|
|
|
|
|
else if(icu->adrcode & MA_MAP15) mtex= la->mtex[14];
|
|
|
|
|
else if(icu->adrcode & MA_MAP16) mtex= la->mtex[15];
|
|
|
|
|
else if(icu->adrcode & MA_MAP17) mtex= la->mtex[16];
|
|
|
|
|
else if(icu->adrcode & MA_MAP18) mtex= la->mtex[17];
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
if(mtex) {
|
|
|
|
|
poin= give_mtex_poin(mtex, icu->adrcode & (MA_MAP1-1) );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if(GS(id->name)==ID_CA) {
|
|
|
|
|
Camera *ca= (Camera *)id;
|
|
|
|
|
|
Fixed:
Texture matrix bug in plugin code reported by Mel_Q.
Vertex colors, this was basically the same as the previous uv coord
splitting bug, for xml export, uv coord splitting was actually not quite
complete either (reported by richie).
Added:
Camera Ipo curves for DoF aperture and focal distance.
Aspect ratio set with AspX & AspY are now taken into account as well.
(needs yafray from cvs)
Bokeh parameters for DoF (also needs yafray from cvs).
'Bokeh' controls the shape of out of focus points when rendering
with depth of field enabled.
This is mostly visible on very out of focus highlights in the image.
There are currently seven types to choose from.:
'Disk1' is the default, the same as was used before.
'Disk2' is similar, but allows you to modify the shape further with the 'bias'
parameter, see below.
Triangle/Square/Pentagon/Hexagon, in addition to the bias control, you can
offset the rotation with the 'Rotation' parameter (in degrees).
'Ring', a weird ring shaped lens, no additional controls.
The 'bias' menu controls accentuation of the shape.
Three types available, uniform, center or edge, with uniform the default.
Although based on an actual phenomenon of real camera's, the current
code is bit of a hack and not physically based, and doesn't work all that
well yet (in yafray anyway). Since this is also mostly visible in the very
out of focus parts of the image, it usually also means that you need lots
of samples to get a reasonably smooth result.
2004-11-08 03:55:44 +00:00
|
|
|
/* yafray: aperture & focal distance params */
|
2002-10-12 11:37:38 +00:00
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case CAM_LENS:
|
2007-05-02 16:45:13 +00:00
|
|
|
if(ca->type==CAM_ORTHO)
|
|
|
|
|
poin= &(ca->ortho_scale);
|
|
|
|
|
else
|
|
|
|
|
poin= &(ca->lens);
|
|
|
|
|
break;
|
2002-10-12 11:37:38 +00:00
|
|
|
case CAM_STA:
|
|
|
|
|
poin= &(ca->clipsta); break;
|
|
|
|
|
case CAM_END:
|
|
|
|
|
poin= &(ca->clipend); break;
|
Fixed:
Texture matrix bug in plugin code reported by Mel_Q.
Vertex colors, this was basically the same as the previous uv coord
splitting bug, for xml export, uv coord splitting was actually not quite
complete either (reported by richie).
Added:
Camera Ipo curves for DoF aperture and focal distance.
Aspect ratio set with AspX & AspY are now taken into account as well.
(needs yafray from cvs)
Bokeh parameters for DoF (also needs yafray from cvs).
'Bokeh' controls the shape of out of focus points when rendering
with depth of field enabled.
This is mostly visible on very out of focus highlights in the image.
There are currently seven types to choose from.:
'Disk1' is the default, the same as was used before.
'Disk2' is similar, but allows you to modify the shape further with the 'bias'
parameter, see below.
Triangle/Square/Pentagon/Hexagon, in addition to the bias control, you can
offset the rotation with the 'Rotation' parameter (in degrees).
'Ring', a weird ring shaped lens, no additional controls.
The 'bias' menu controls accentuation of the shape.
Three types available, uniform, center or edge, with uniform the default.
Although based on an actual phenomenon of real camera's, the current
code is bit of a hack and not physically based, and doesn't work all that
well yet (in yafray anyway). Since this is also mostly visible in the very
out of focus parts of the image, it usually also means that you need lots
of samples to get a reasonably smooth result.
2004-11-08 03:55:44 +00:00
|
|
|
case CAM_YF_APERT:
|
|
|
|
|
poin= &(ca->YF_aperture); break;
|
|
|
|
|
case CAM_YF_FDIST:
|
|
|
|
|
poin= &(ca->YF_dofdist); break;
|
2007-01-15 12:44:45 +00:00
|
|
|
case CAM_SHIFT_X:
|
|
|
|
|
poin= &(ca->shiftx); break;
|
|
|
|
|
case CAM_SHIFT_Y:
|
|
|
|
|
poin= &(ca->shifty); break;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if(GS(id->name)==ID_SO) {
|
|
|
|
|
bSound *snd= (bSound *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case SND_VOLUME:
|
|
|
|
|
poin= &(snd->volume); break;
|
|
|
|
|
case SND_PITCH:
|
|
|
|
|
poin= &(snd->pitch); break;
|
|
|
|
|
case SND_PANNING:
|
|
|
|
|
poin= &(snd->panning); break;
|
|
|
|
|
case SND_ATTEN:
|
|
|
|
|
poin= &(snd->attenuation); break;
|
|
|
|
|
}
|
|
|
|
|
}
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
else if( GS(id->name)==ID_PA) {
|
|
|
|
|
|
|
|
|
|
part= (ParticleSettings *)id;
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case PART_EMIT_FREQ:
|
|
|
|
|
case PART_EMIT_LIFE:
|
|
|
|
|
case PART_EMIT_VEL:
|
|
|
|
|
case PART_EMIT_AVE:
|
|
|
|
|
case PART_EMIT_SIZE:
|
|
|
|
|
poin= NULL; break;
|
|
|
|
|
case PART_CLUMP:
|
|
|
|
|
poin= &(part->clumpfac); break;
|
|
|
|
|
case PART_AVE:
|
|
|
|
|
poin= &(part->avefac); break;
|
|
|
|
|
case PART_SIZE:
|
|
|
|
|
poin= &(part->size); break;
|
|
|
|
|
case PART_DRAG:
|
|
|
|
|
poin= &(part->dragfac); break;
|
|
|
|
|
case PART_BROWN:
|
|
|
|
|
poin= &(part->brownfac); break;
|
|
|
|
|
case PART_DAMP:
|
|
|
|
|
poin= &(part->dampfac); break;
|
|
|
|
|
case PART_LENGTH:
|
|
|
|
|
poin= &(part->length); break;
|
|
|
|
|
case PART_GRAV_X:
|
|
|
|
|
poin= &(part->acc[0]); break;
|
|
|
|
|
case PART_GRAV_Y:
|
|
|
|
|
poin= &(part->acc[1]); break;
|
|
|
|
|
case PART_GRAV_Z:
|
|
|
|
|
poin= &(part->acc[2]); break;
|
|
|
|
|
case PART_KINK_AMP:
|
|
|
|
|
poin= &(part->kink_amp); break;
|
|
|
|
|
case PART_KINK_FREQ:
|
|
|
|
|
poin= &(part->kink_freq); break;
|
|
|
|
|
case PART_KINK_SHAPE:
|
|
|
|
|
poin= &(part->kink_shape); break;
|
|
|
|
|
case PART_BB_TILT:
|
|
|
|
|
poin= &(part->bb_tilt); break;
|
2008-08-16 16:21:01 +00:00
|
|
|
case PART_PD_FSTR:
|
|
|
|
|
poin= (part->pd?(&(part->pd->f_strength)):NULL); break;
|
|
|
|
|
case PART_PD_FFALL:
|
|
|
|
|
poin= (part->pd?(&(part->pd->f_power)):NULL); break;
|
|
|
|
|
case PART_PD_FMAXD:
|
|
|
|
|
poin= (part->pd?(&(part->pd->maxdist)):NULL); break;
|
2008-08-21 21:12:27 +00:00
|
|
|
case PART_PD2_FSTR:
|
|
|
|
|
poin= (part->pd2?(&(part->pd2->f_strength)):NULL); break;
|
|
|
|
|
case PART_PD2_FFALL:
|
|
|
|
|
poin= (part->pd2?(&(part->pd2->f_power)):NULL); break;
|
|
|
|
|
case PART_PD2_FMAXD:
|
|
|
|
|
poin= (part->pd2?(&(part->pd2->maxdist)):NULL); break;
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return poin;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void set_icu_vars(IpoCurve *icu)
|
|
|
|
|
{
|
2007-08-15 10:04:45 +00:00
|
|
|
/* defaults. 0.0 for y-extents makes these ignored */
|
2002-10-12 11:37:38 +00:00
|
|
|
icu->ymin= icu->ymax= 0.0;
|
|
|
|
|
icu->ipo= IPO_BEZ;
|
|
|
|
|
|
|
|
|
|
if(icu->blocktype==ID_OB) {
|
|
|
|
|
|
|
|
|
|
if(icu->adrcode==OB_LAY) {
|
|
|
|
|
icu->ipo= IPO_CONST;
|
|
|
|
|
icu->vartype= IPO_BITS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
else if(icu->blocktype==ID_MA) {
|
|
|
|
|
|
|
|
|
|
if(icu->adrcode < MA_MAP1) {
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case MA_HASIZE:
|
|
|
|
|
icu->ymax= 10000.0; break;
|
|
|
|
|
case MA_HARD:
|
2006-06-26 16:57:44 +00:00
|
|
|
icu->ymax= 511.0; break;
|
2002-10-12 11:37:38 +00:00
|
|
|
case MA_SPEC:
|
|
|
|
|
icu->ymax= 2.0; break;
|
|
|
|
|
case MA_MODE:
|
|
|
|
|
icu->ipo= IPO_CONST;
|
2004-07-07 08:49:33 +00:00
|
|
|
icu->vartype= IPO_BITS; break;
|
|
|
|
|
case MA_RAYM:
|
|
|
|
|
icu->ymax= 1.0; break;
|
|
|
|
|
case MA_TRANSLU:
|
|
|
|
|
icu->ymax= 1.0; break;
|
|
|
|
|
case MA_IOR:
|
|
|
|
|
icu->ymin= 1.0;
|
|
|
|
|
icu->ymax= 3.0; break;
|
|
|
|
|
case MA_FRESMIR:
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
case MA_FRESMIRI:
|
|
|
|
|
icu->ymin= 1.0;
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
case MA_FRESTRA:
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
case MA_FRESTRAI:
|
|
|
|
|
icu->ymin= 1.0;
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
case MA_ADD:
|
|
|
|
|
icu->ymax= 1.0; break;
|
2008-08-30 21:41:02 +00:00
|
|
|
case MA_EMIT:
|
2008-08-30 23:12:01 +00:00
|
|
|
icu->ymax= 2.0; break;
|
2002-10-12 11:37:38 +00:00
|
|
|
default:
|
2004-07-07 08:49:33 +00:00
|
|
|
icu->ymax= 1.0; break;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
switch(icu->adrcode & (MA_MAP1-1)) {
|
|
|
|
|
case MAP_OFS_X:
|
|
|
|
|
case MAP_OFS_Y:
|
|
|
|
|
case MAP_OFS_Z:
|
|
|
|
|
case MAP_SIZE_X:
|
|
|
|
|
case MAP_SIZE_Y:
|
|
|
|
|
case MAP_SIZE_Z:
|
|
|
|
|
icu->ymax= 1000.0;
|
|
|
|
|
icu->ymin= -1000.0;
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
case MAP_R:
|
|
|
|
|
case MAP_G:
|
|
|
|
|
case MAP_B:
|
|
|
|
|
case MAP_DVAR:
|
|
|
|
|
case MAP_COLF:
|
|
|
|
|
case MAP_VARF:
|
2004-07-05 09:15:02 +00:00
|
|
|
case MAP_DISP:
|
2002-10-12 11:37:38 +00:00
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
break;
|
|
|
|
|
case MAP_NORF:
|
2005-05-05 20:39:50 +00:00
|
|
|
icu->ymax= 25.0;
|
2002-10-12 11:37:38 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2004-07-26 21:44:55 +00:00
|
|
|
else if(icu->blocktype==ID_TE) {
|
|
|
|
|
switch(icu->adrcode & (MA_MAP1-1)) {
|
|
|
|
|
case TE_NSIZE:
|
|
|
|
|
icu->ymin= 0.0001;
|
|
|
|
|
icu->ymax= 2.0; break;
|
|
|
|
|
case TE_NDEPTH:
|
|
|
|
|
icu->vartype= IPO_SHORT;
|
|
|
|
|
icu->ipo= IPO_CONST;
|
|
|
|
|
icu->ymax= 6.0; break;
|
|
|
|
|
case TE_NTYPE:
|
|
|
|
|
icu->vartype= IPO_SHORT;
|
|
|
|
|
icu->ipo= IPO_CONST;
|
|
|
|
|
icu->ymax= 1.0; break;
|
|
|
|
|
case TE_TURB:
|
|
|
|
|
icu->ymax= 200.0; break;
|
|
|
|
|
case TE_VNW1:
|
|
|
|
|
case TE_VNW2:
|
|
|
|
|
case TE_VNW3:
|
|
|
|
|
case TE_VNW4:
|
|
|
|
|
icu->ymax= 2.0;
|
|
|
|
|
icu->ymin= -2.0; break;
|
|
|
|
|
case TE_VNMEXP:
|
|
|
|
|
icu->ymax= 10.0;
|
|
|
|
|
icu->ymin= 0.01; break;
|
|
|
|
|
case TE_VN_DISTM:
|
|
|
|
|
icu->vartype= IPO_SHORT;
|
|
|
|
|
icu->ipo= IPO_CONST;
|
|
|
|
|
icu->ymax= 6.0; break;
|
|
|
|
|
case TE_VN_COLT:
|
|
|
|
|
icu->vartype= IPO_SHORT;
|
|
|
|
|
icu->ipo= IPO_CONST;
|
|
|
|
|
icu->ymax= 3.0; break;
|
|
|
|
|
case TE_ISCA:
|
|
|
|
|
icu->ymax= 10.0;
|
|
|
|
|
icu->ymin= 0.01; break;
|
|
|
|
|
case TE_DISTA:
|
|
|
|
|
icu->ymax= 10.0; break;
|
|
|
|
|
case TE_MG_TYP:
|
|
|
|
|
icu->vartype= IPO_SHORT;
|
|
|
|
|
icu->ipo= IPO_CONST;
|
2006-01-06 13:33:20 +00:00
|
|
|
icu->ymax= 6.0; break;
|
2004-07-26 21:44:55 +00:00
|
|
|
case TE_MGH:
|
|
|
|
|
icu->ymin= 0.0001;
|
|
|
|
|
icu->ymax= 2.0; break;
|
|
|
|
|
case TE_MG_LAC:
|
|
|
|
|
case TE_MG_OFF:
|
|
|
|
|
case TE_MG_GAIN:
|
|
|
|
|
icu->ymax= 6.0; break;
|
|
|
|
|
case TE_MG_OCT:
|
|
|
|
|
icu->ymax= 8.0; break;
|
|
|
|
|
case TE_N_BAS1:
|
|
|
|
|
case TE_N_BAS2:
|
|
|
|
|
icu->vartype= IPO_SHORT;
|
|
|
|
|
icu->ipo= IPO_CONST;
|
|
|
|
|
icu->ymax= 8.0; break;
|
2006-01-06 13:33:20 +00:00
|
|
|
case TE_COL_R:
|
|
|
|
|
icu->ymax= 0.0; break;
|
|
|
|
|
case TE_COL_G:
|
|
|
|
|
icu->ymax= 2.0; break;
|
|
|
|
|
case TE_COL_B:
|
|
|
|
|
icu->ymax= 2.0; break;
|
|
|
|
|
case TE_BRIGHT:
|
|
|
|
|
icu->ymax= 2.0; break;
|
|
|
|
|
case TE_CONTRA:
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
|
2004-07-26 21:44:55 +00:00
|
|
|
}
|
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
else if(icu->blocktype==ID_SEQ) {
|
|
|
|
|
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
else if(icu->blocktype==ID_CU) {
|
|
|
|
|
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
else if(icu->blocktype==ID_WO) {
|
|
|
|
|
|
|
|
|
|
if(icu->adrcode < MA_MAP1) {
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case WO_EXPOS:
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
case WO_MISTDI:
|
|
|
|
|
case WO_MISTSTA:
|
|
|
|
|
case WO_MISTHI:
|
|
|
|
|
case WO_STARDIST:
|
|
|
|
|
case WO_STARSIZE:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
switch(icu->adrcode & (MA_MAP1-1)) {
|
|
|
|
|
case MAP_OFS_X:
|
|
|
|
|
case MAP_OFS_Y:
|
|
|
|
|
case MAP_OFS_Z:
|
|
|
|
|
case MAP_SIZE_X:
|
|
|
|
|
case MAP_SIZE_Y:
|
|
|
|
|
case MAP_SIZE_Z:
|
|
|
|
|
icu->ymax= 100.0;
|
|
|
|
|
icu->ymin= -100.0;
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
case MAP_R:
|
|
|
|
|
case MAP_G:
|
|
|
|
|
case MAP_B:
|
|
|
|
|
case MAP_DVAR:
|
|
|
|
|
case MAP_COLF:
|
|
|
|
|
case MAP_NORF:
|
|
|
|
|
case MAP_VARF:
|
2004-07-05 09:15:02 +00:00
|
|
|
case MAP_DISP:
|
2002-10-12 11:37:38 +00:00
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if(icu->blocktype==ID_LA) {
|
|
|
|
|
if(icu->adrcode < MA_MAP1) {
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case LA_ENERGY:
|
|
|
|
|
case LA_DIST:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case LA_COL_R:
|
|
|
|
|
case LA_COL_G:
|
|
|
|
|
case LA_COL_B:
|
|
|
|
|
case LA_SPOTBL:
|
|
|
|
|
case LA_QUAD1:
|
|
|
|
|
case LA_QUAD2:
|
|
|
|
|
icu->ymax= 1.0; break;
|
|
|
|
|
case LA_SPOTSI:
|
|
|
|
|
icu->ymax= 180.0; break;
|
|
|
|
|
case LA_HALOINT:
|
|
|
|
|
icu->ymax= 5.0; break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
switch(icu->adrcode & (MA_MAP1-1)) {
|
|
|
|
|
case MAP_OFS_X:
|
|
|
|
|
case MAP_OFS_Y:
|
|
|
|
|
case MAP_OFS_Z:
|
|
|
|
|
case MAP_SIZE_X:
|
|
|
|
|
case MAP_SIZE_Y:
|
|
|
|
|
case MAP_SIZE_Z:
|
|
|
|
|
icu->ymax= 100.0;
|
|
|
|
|
icu->ymin= -100.0;
|
|
|
|
|
break;
|
|
|
|
|
case MAP_R:
|
|
|
|
|
case MAP_G:
|
|
|
|
|
case MAP_B:
|
|
|
|
|
case MAP_DVAR:
|
|
|
|
|
case MAP_COLF:
|
|
|
|
|
case MAP_NORF:
|
|
|
|
|
case MAP_VARF:
|
2004-07-05 09:15:02 +00:00
|
|
|
case MAP_DISP:
|
2002-10-12 11:37:38 +00:00
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if(icu->blocktype==ID_CA) {
|
|
|
|
|
|
Fixed:
Texture matrix bug in plugin code reported by Mel_Q.
Vertex colors, this was basically the same as the previous uv coord
splitting bug, for xml export, uv coord splitting was actually not quite
complete either (reported by richie).
Added:
Camera Ipo curves for DoF aperture and focal distance.
Aspect ratio set with AspX & AspY are now taken into account as well.
(needs yafray from cvs)
Bokeh parameters for DoF (also needs yafray from cvs).
'Bokeh' controls the shape of out of focus points when rendering
with depth of field enabled.
This is mostly visible on very out of focus highlights in the image.
There are currently seven types to choose from.:
'Disk1' is the default, the same as was used before.
'Disk2' is similar, but allows you to modify the shape further with the 'bias'
parameter, see below.
Triangle/Square/Pentagon/Hexagon, in addition to the bias control, you can
offset the rotation with the 'Rotation' parameter (in degrees).
'Ring', a weird ring shaped lens, no additional controls.
The 'bias' menu controls accentuation of the shape.
Three types available, uniform, center or edge, with uniform the default.
Although based on an actual phenomenon of real camera's, the current
code is bit of a hack and not physically based, and doesn't work all that
well yet (in yafray anyway). Since this is also mostly visible in the very
out of focus parts of the image, it usually also means that you need lots
of samples to get a reasonably smooth result.
2004-11-08 03:55:44 +00:00
|
|
|
/* yafray: aperture & focal distance params */
|
2002-10-12 11:37:38 +00:00
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case CAM_LENS:
|
2008-06-29 21:06:18 +00:00
|
|
|
icu->ymin= 1.0;
|
Fixed:
Texture matrix bug in plugin code reported by Mel_Q.
Vertex colors, this was basically the same as the previous uv coord
splitting bug, for xml export, uv coord splitting was actually not quite
complete either (reported by richie).
Added:
Camera Ipo curves for DoF aperture and focal distance.
Aspect ratio set with AspX & AspY are now taken into account as well.
(needs yafray from cvs)
Bokeh parameters for DoF (also needs yafray from cvs).
'Bokeh' controls the shape of out of focus points when rendering
with depth of field enabled.
This is mostly visible on very out of focus highlights in the image.
There are currently seven types to choose from.:
'Disk1' is the default, the same as was used before.
'Disk2' is similar, but allows you to modify the shape further with the 'bias'
parameter, see below.
Triangle/Square/Pentagon/Hexagon, in addition to the bias control, you can
offset the rotation with the 'Rotation' parameter (in degrees).
'Ring', a weird ring shaped lens, no additional controls.
The 'bias' menu controls accentuation of the shape.
Three types available, uniform, center or edge, with uniform the default.
Although based on an actual phenomenon of real camera's, the current
code is bit of a hack and not physically based, and doesn't work all that
well yet (in yafray anyway). Since this is also mostly visible in the very
out of focus parts of the image, it usually also means that you need lots
of samples to get a reasonably smooth result.
2004-11-08 03:55:44 +00:00
|
|
|
icu->ymax= 1000.0;
|
|
|
|
|
break;
|
2002-10-12 11:37:38 +00:00
|
|
|
case CAM_STA:
|
|
|
|
|
icu->ymin= 0.001f;
|
|
|
|
|
break;
|
|
|
|
|
case CAM_END:
|
|
|
|
|
icu->ymin= 0.1f;
|
Fixed:
Texture matrix bug in plugin code reported by Mel_Q.
Vertex colors, this was basically the same as the previous uv coord
splitting bug, for xml export, uv coord splitting was actually not quite
complete either (reported by richie).
Added:
Camera Ipo curves for DoF aperture and focal distance.
Aspect ratio set with AspX & AspY are now taken into account as well.
(needs yafray from cvs)
Bokeh parameters for DoF (also needs yafray from cvs).
'Bokeh' controls the shape of out of focus points when rendering
with depth of field enabled.
This is mostly visible on very out of focus highlights in the image.
There are currently seven types to choose from.:
'Disk1' is the default, the same as was used before.
'Disk2' is similar, but allows you to modify the shape further with the 'bias'
parameter, see below.
Triangle/Square/Pentagon/Hexagon, in addition to the bias control, you can
offset the rotation with the 'Rotation' parameter (in degrees).
'Ring', a weird ring shaped lens, no additional controls.
The 'bias' menu controls accentuation of the shape.
Three types available, uniform, center or edge, with uniform the default.
Although based on an actual phenomenon of real camera's, the current
code is bit of a hack and not physically based, and doesn't work all that
well yet (in yafray anyway). Since this is also mostly visible in the very
out of focus parts of the image, it usually also means that you need lots
of samples to get a reasonably smooth result.
2004-11-08 03:55:44 +00:00
|
|
|
break;
|
|
|
|
|
case CAM_YF_APERT:
|
|
|
|
|
icu->ymin = 0.0;
|
|
|
|
|
icu->ymax = 2.0;
|
|
|
|
|
break;
|
|
|
|
|
case CAM_YF_FDIST:
|
|
|
|
|
icu->ymin = 0.0;
|
|
|
|
|
icu->ymax = 5000.0;
|
2007-01-15 12:44:45 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case CAM_SHIFT_X:
|
|
|
|
|
case CAM_SHIFT_Y:
|
|
|
|
|
icu->ymin= -2.0f;
|
|
|
|
|
icu->ymax= 2.0f;
|
|
|
|
|
break;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if(icu->blocktype==ID_SO) {
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case SND_VOLUME:
|
|
|
|
|
icu->ymin= 0.0;
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
break;
|
|
|
|
|
case SND_PITCH:
|
|
|
|
|
icu->ymin= -12.0;
|
|
|
|
|
icu->ymin= 12.0;
|
|
|
|
|
break;
|
|
|
|
|
case SND_PANNING:
|
|
|
|
|
icu->ymin= 0.0;
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
break;
|
|
|
|
|
case SND_ATTEN:
|
|
|
|
|
icu->ymin= 0.0;
|
|
|
|
|
icu->ymin= 1.0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
else if(icu->blocktype==ID_PA){
|
|
|
|
|
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case PART_EMIT_LIFE:
|
|
|
|
|
case PART_SIZE:
|
|
|
|
|
case PART_KINK_FREQ:
|
|
|
|
|
case PART_EMIT_VEL:
|
|
|
|
|
case PART_EMIT_AVE:
|
|
|
|
|
case PART_EMIT_SIZE:
|
|
|
|
|
icu->ymin= 0.0;
|
|
|
|
|
break;
|
|
|
|
|
case PART_CLUMP:
|
2008-05-08 08:41:56 +00:00
|
|
|
icu->ymin= -1.0;
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
break;
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
case PART_DRAG:
|
|
|
|
|
case PART_DAMP:
|
|
|
|
|
case PART_LENGTH:
|
|
|
|
|
icu->ymin= 0.0;
|
|
|
|
|
icu->ymax= 1.0;
|
|
|
|
|
break;
|
|
|
|
|
case PART_KINK_SHAPE:
|
|
|
|
|
icu->ymin= -0.999;
|
|
|
|
|
icu->ymax= 0.999;
|
2008-05-08 08:41:56 +00:00
|
|
|
break;
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
}
|
|
|
|
|
}
|
2007-08-15 10:04:45 +00:00
|
|
|
else if(icu->blocktype==ID_CO) {
|
|
|
|
|
icu->ymin= 0.0;
|
|
|
|
|
icu->ymax= 1.0f;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* by default, slider limits will be icu->ymin and icu->ymax */
|
|
|
|
|
icu->slide_min= icu->ymin;
|
|
|
|
|
icu->slide_max= icu->ymax;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
/* not for actions or constraints! */
|
2002-10-12 11:37:38 +00:00
|
|
|
void execute_ipo(ID *id, Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
void *poin;
|
|
|
|
|
int type;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
poin= get_ipo_poin(id, icu, &type);
|
|
|
|
|
if(poin) write_ipo_poin(poin, type, icu->curval);
|
2005-10-10 18:05:30 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void *get_pchan_ipo_poin(bPoseChannel *pchan, int adrcode)
|
|
|
|
|
{
|
|
|
|
|
void *poin= NULL;
|
|
|
|
|
|
|
|
|
|
switch (adrcode) {
|
|
|
|
|
case AC_QUAT_W:
|
|
|
|
|
poin= &(pchan->quat[0]);
|
|
|
|
|
pchan->flag |= POSE_ROT;
|
|
|
|
|
break;
|
|
|
|
|
case AC_QUAT_X:
|
|
|
|
|
poin= &(pchan->quat[1]);
|
|
|
|
|
pchan->flag |= POSE_ROT;
|
|
|
|
|
break;
|
|
|
|
|
case AC_QUAT_Y:
|
|
|
|
|
poin= &(pchan->quat[2]);
|
|
|
|
|
pchan->flag |= POSE_ROT;
|
|
|
|
|
break;
|
|
|
|
|
case AC_QUAT_Z:
|
|
|
|
|
poin= &(pchan->quat[3]);
|
|
|
|
|
pchan->flag |= POSE_ROT;
|
|
|
|
|
break;
|
|
|
|
|
case AC_LOC_X:
|
|
|
|
|
poin= &(pchan->loc[0]);
|
|
|
|
|
pchan->flag |= POSE_LOC;
|
|
|
|
|
break;
|
|
|
|
|
case AC_LOC_Y:
|
|
|
|
|
poin= &(pchan->loc[1]);
|
|
|
|
|
pchan->flag |= POSE_LOC;
|
|
|
|
|
break;
|
|
|
|
|
case AC_LOC_Z:
|
|
|
|
|
poin= &(pchan->loc[2]);
|
|
|
|
|
pchan->flag |= POSE_LOC;
|
|
|
|
|
break;
|
|
|
|
|
case AC_SIZE_X:
|
|
|
|
|
poin= &(pchan->size[0]);
|
|
|
|
|
pchan->flag |= POSE_SIZE;
|
|
|
|
|
break;
|
|
|
|
|
case AC_SIZE_Y:
|
|
|
|
|
poin= &(pchan->size[1]);
|
|
|
|
|
pchan->flag |= POSE_SIZE;
|
|
|
|
|
break;
|
|
|
|
|
case AC_SIZE_Z:
|
|
|
|
|
poin= &(pchan->size[2]);
|
|
|
|
|
pchan->flag |= POSE_SIZE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return poin;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void execute_action_ipo(bActionChannel *achan, bPoseChannel *pchan)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if(achan && achan->ipo) {
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
for(icu= achan->ipo->curve.first; icu; icu= icu->next) {
|
|
|
|
|
void *poin= get_pchan_ipo_poin(pchan, icu->adrcode);
|
2005-12-18 20:14:22 +00:00
|
|
|
if(poin) {
|
2006-06-03 11:49:30 +00:00
|
|
|
write_ipo_poin(poin, IPO_FLOAT, icu->curval);
|
|
|
|
|
//printf("execute_action_ipo wrote_ipo_poin: %f\n", icu->curval);
|
|
|
|
|
//printf("%s has poin %p value %f\n", achan->name, poin, icu->curval);
|
2005-12-18 20:14:22 +00:00
|
|
|
}
|
2005-10-10 18:05:30 +00:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* exception: it does calc for objects...
|
|
|
|
|
* now find out why this routine was used anyway!
|
|
|
|
|
*/
|
|
|
|
|
void do_ipo_nocalc(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
Object *ob;
|
|
|
|
|
Material *ma;
|
2004-07-26 21:44:55 +00:00
|
|
|
Tex *tex;
|
2002-10-12 11:37:38 +00:00
|
|
|
World *wo;
|
|
|
|
|
Lamp *la;
|
|
|
|
|
Camera *ca;
|
|
|
|
|
bSound *snd;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
switch(ipo->blocktype) {
|
|
|
|
|
case ID_OB:
|
|
|
|
|
ob= G.main->object.first;
|
|
|
|
|
while(ob) {
|
|
|
|
|
if(ob->ipo==ipo) {
|
|
|
|
|
do_ob_ipo(ob);
|
|
|
|
|
/* execute_ipo((ID *)ob, ipo); */
|
|
|
|
|
}
|
|
|
|
|
ob= ob->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ID_MA:
|
|
|
|
|
ma= G.main->mat.first;
|
|
|
|
|
while(ma) {
|
|
|
|
|
if(ma->ipo==ipo) execute_ipo((ID *)ma, ipo);
|
|
|
|
|
ma= ma->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
2004-07-26 21:44:55 +00:00
|
|
|
case ID_TE:
|
|
|
|
|
tex= G.main->tex.first;
|
|
|
|
|
while(tex) {
|
|
|
|
|
if(tex->ipo==ipo) execute_ipo((ID *)tex, ipo);
|
|
|
|
|
tex=tex->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
2002-10-12 11:37:38 +00:00
|
|
|
case ID_WO:
|
|
|
|
|
wo= G.main->world.first;
|
|
|
|
|
while(wo) {
|
|
|
|
|
if(wo->ipo==ipo) execute_ipo((ID *)wo, ipo);
|
|
|
|
|
wo= wo->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ID_LA:
|
|
|
|
|
la= G.main->lamp.first;
|
|
|
|
|
while(la) {
|
|
|
|
|
if(la->ipo==ipo) execute_ipo((ID *)la, ipo);
|
|
|
|
|
la= la->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ID_CA:
|
|
|
|
|
ca= G.main->camera.first;
|
|
|
|
|
while(ca) {
|
|
|
|
|
if(ca->ipo==ipo) execute_ipo((ID *)ca, ipo);
|
|
|
|
|
ca= ca->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ID_SO:
|
|
|
|
|
snd= G.main->sound.first;
|
|
|
|
|
while(snd) {
|
|
|
|
|
if(snd->ipo==ipo) execute_ipo((ID *)snd, ipo);
|
|
|
|
|
snd= snd->id.next;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void do_ipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
if(ipo) {
|
|
|
|
|
float ctime= frame_to_float(G.scene->r.cfra);
|
|
|
|
|
calc_ipo(ipo, ctime);
|
|
|
|
|
|
|
|
|
|
do_ipo_nocalc(ipo);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void do_mat_ipo(Material *ma)
|
|
|
|
|
{
|
|
|
|
|
float ctime;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ma==NULL || ma->ipo==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
ctime= frame_to_float(G.scene->r.cfra);
|
|
|
|
|
/* if(ob->ipoflag & OB_OFFS_OB) ctime-= ob->sf; */
|
|
|
|
|
|
|
|
|
|
calc_ipo(ma->ipo, ctime);
|
|
|
|
|
|
|
|
|
|
execute_ipo((ID *)ma, ma->ipo);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void do_ob_ipo(Object *ob)
|
|
|
|
|
{
|
|
|
|
|
float ctime;
|
|
|
|
|
unsigned int lay;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ob->ipo==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* do not set ob->ctime here: for example when parent in invisible layer */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2007-08-05 09:21:29 +00:00
|
|
|
ctime= bsystem_time(ob, (float) G.scene->r.cfra, 0.0);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
calc_ipo(ob->ipo, ctime);
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* Patch: remember localview */
|
2002-10-12 11:37:38 +00:00
|
|
|
lay= ob->lay & 0xFF000000;
|
|
|
|
|
|
|
|
|
|
execute_ipo((ID *)ob, ob->ipo);
|
|
|
|
|
|
|
|
|
|
ob->lay |= lay;
|
|
|
|
|
if(ob->id.name[2]=='S' && ob->id.name[3]=='C' && ob->id.name[4]=='E') {
|
|
|
|
|
if(strcmp(G.scene->id.name+2, ob->id.name+6)==0) {
|
|
|
|
|
G.scene->lay= ob->lay;
|
|
|
|
|
copy_view3d_lock(0);
|
2003-04-26 11:56:44 +00:00
|
|
|
/* no redraw here! creates too many calls */
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-04 10:19:26 +00:00
|
|
|
void do_ob_ipodrivers(Object *ob, Ipo *ipo, float ctime)
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
void *poin;
|
|
|
|
|
int type;
|
|
|
|
|
|
|
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
|
|
|
|
if(icu->driver) {
|
2006-07-04 10:19:26 +00:00
|
|
|
icu->curval= eval_icu(icu, ctime);
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
poin= get_ipo_poin((ID *)ob, icu, &type);
|
|
|
|
|
if(poin) write_ipo_poin(poin, type, icu->curval);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-23 21:27:12 +00:00
|
|
|
void do_seq_ipo(Sequence *seq, int cfra)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
|
|
|
|
float ctime, div;
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* seq_ipo has an exception: calc both fields immediately */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
if(seq->ipo) {
|
2006-02-05 19:13:44 +00:00
|
|
|
if((seq->flag & SEQ_IPO_FRAME_LOCKED) != 0) {
|
2007-12-23 21:27:12 +00:00
|
|
|
ctime = frame_to_float(cfra);
|
2006-02-05 19:13:44 +00:00
|
|
|
div = 1.0;
|
|
|
|
|
} else {
|
2007-12-23 21:27:12 +00:00
|
|
|
ctime= frame_to_float(cfra - seq->startdisp);
|
2006-02-05 19:13:44 +00:00
|
|
|
div= (seq->enddisp - seq->startdisp)/100.0f;
|
|
|
|
|
if(div==0.0) return;
|
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* 2nd field */
|
2002-10-12 11:37:38 +00:00
|
|
|
calc_ipo(seq->ipo, (ctime+0.5f)/div);
|
|
|
|
|
execute_ipo((ID *)seq, seq->ipo);
|
|
|
|
|
seq->facf1= seq->facf0;
|
|
|
|
|
|
2003-04-26 11:56:44 +00:00
|
|
|
/* 1st field */
|
2002-10-12 11:37:38 +00:00
|
|
|
calc_ipo(seq->ipo, ctime/div);
|
|
|
|
|
execute_ipo((ID *)seq, seq->ipo);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
else seq->facf1= seq->facf0= 1.0f;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int has_ipo_code(Ipo *ipo, int code)
|
|
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return 0;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
if(icu->adrcode==code) return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
void do_all_data_ipos()
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
|
|
|
|
Material *ma;
|
2004-07-26 21:44:55 +00:00
|
|
|
Tex *tex;
|
2002-10-12 11:37:38 +00:00
|
|
|
World *wo;
|
|
|
|
|
Ipo *ipo;
|
|
|
|
|
Lamp *la;
|
2005-10-28 08:11:15 +00:00
|
|
|
Key *key;
|
2002-10-12 11:37:38 +00:00
|
|
|
Camera *ca;
|
|
|
|
|
bSound *snd;
|
2003-08-05 13:39:27 +00:00
|
|
|
Sequence *seq;
|
|
|
|
|
Editing *ed;
|
2005-07-12 17:46:39 +00:00
|
|
|
Base *base;
|
2002-10-12 11:37:38 +00:00
|
|
|
float ctime;
|
|
|
|
|
|
|
|
|
|
ctime= frame_to_float(G.scene->r.cfra);
|
|
|
|
|
|
2005-07-12 17:46:39 +00:00
|
|
|
/* this exception cannot be depgraphed yet... what todo with objects in other layers?... */
|
|
|
|
|
for(base= G.scene->base.first; base; base= base->next) {
|
|
|
|
|
/* only update layer when an ipo */
|
|
|
|
|
if( has_ipo_code(base->object->ipo, OB_LAY) ) {
|
|
|
|
|
do_ob_ipo(base->object);
|
|
|
|
|
base->lay= base->object->lay;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* layers for the set...*/
|
|
|
|
|
if(G.scene->set) {
|
|
|
|
|
for(base= G.scene->set->base.first; base; base= base->next) {
|
|
|
|
|
if( has_ipo_code(base->object->ipo, OB_LAY) ) {
|
|
|
|
|
do_ob_ipo(base->object);
|
|
|
|
|
base->lay= base->object->lay;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
ipo= G.main->ipo.first;
|
|
|
|
|
while(ipo) {
|
|
|
|
|
if(ipo->id.us && ipo->blocktype!=ID_OB) {
|
|
|
|
|
calc_ipo(ipo, ctime);
|
|
|
|
|
}
|
|
|
|
|
ipo= ipo->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-28 08:11:15 +00:00
|
|
|
for(tex= G.main->tex.first; tex; tex= tex->id.next) {
|
2004-07-26 21:44:55 +00:00
|
|
|
if(tex->ipo) execute_ipo((ID *)tex, tex->ipo);
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-28 08:11:15 +00:00
|
|
|
for(ma= G.main->mat.first; ma; ma= ma->id.next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
if(ma->ipo) execute_ipo((ID *)ma, ma->ipo);
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-28 08:11:15 +00:00
|
|
|
for(wo= G.main->world.first; wo; wo= wo->id.next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
if(wo->ipo) execute_ipo((ID *)wo, wo->ipo);
|
|
|
|
|
}
|
2005-10-28 08:11:15 +00:00
|
|
|
|
|
|
|
|
for(key= G.main->key.first; key; key= key->id.next) {
|
|
|
|
|
if(key->ipo) execute_ipo((ID *)key, key->ipo);
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
la= G.main->lamp.first;
|
|
|
|
|
while(la) {
|
|
|
|
|
if(la->ipo) execute_ipo((ID *)la, la->ipo);
|
|
|
|
|
la= la->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ca= G.main->camera.first;
|
|
|
|
|
while(ca) {
|
|
|
|
|
if(ca->ipo) execute_ipo((ID *)ca, ca->ipo);
|
|
|
|
|
ca= ca->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
snd= G.main->sound.first;
|
|
|
|
|
while(snd) {
|
|
|
|
|
if(snd->ipo) execute_ipo((ID *)snd, snd->ipo);
|
|
|
|
|
snd= snd->id.next;
|
|
|
|
|
}
|
|
|
|
|
|
Result of 2 weeks of quiet coding work in Greece :)
Aim was to get a total refresh of the animation system. This
is needed because;
- we need to upgrade it with 21st century features
- current code is spaghetti/hack combo, and hides good design
- it should become lag-free with using dependency graphs
A full log, with complete code API/structure/design explanation
will follow, that's a load of work... so here below the list with
hot changes;
- The entire object update system (matrices, geometry) is now
centralized. Calls to where_is_object and makeDispList are
forbidden, instead we tag objects 'changed' and let the
depgraph code sort it out
- Removed all old "Ika" code
- Depgraph is aware of all relationships, including meta balls,
constraints, bevelcurve, and so on.
- Made depgraph aware of relation types and layers, to do smart
flushing of 'changed' events. Nothing gets calculated too often!
- Transform uses depgraph to detect changes
- On frame-advance, depgraph flushes animated changes
Armatures;
Almost all armature related code has been fully built from scratch.
It now reveils the original design much better, with a very clean
implementation, lag free without even calculating each Bone more than
once. Result is quite a speedup yes!
Important to note is;
1) Armature is data containing the 'rest position'
2) Pose is the changes of rest position, and always on object level.
That way more Objects can use same Pose. Also constraints are in Pose
3) Actions only contain the Ipos to change values in Poses.
- Bones draw unrotated now
- Drawing bones speedup enormously (10-20 times)
- Bone selecting in EditMode, selection state is saved for PoseMode,
and vice-versa
- Undo in editmode
- Bone renaming does vertexgroups, constraints, posechannels, actions,
for all users of Armature in entire file
- Added Bone renaming in NKey panel
- Nkey PoseMode shows eulers now
- EditMode and PoseMode now have 'active' bone too (last clicked)
- Parenting in EditMode' CTRL+P, ALT+P, with nice options!
- Pose is added in Outliner now, with showing that constraints are in
the Pose, not Armature
- Disconnected IK solving from constraints. It's a separate phase now,
on top of the full Pose calculations
- Pose itself has a dependency graph too, so evaluation order is lag free.
TODO NOW;
- Rotating in Posemode has incorrect inverse transform (Martin will fix)
- Python Bone/Armature/Pose API disabled... needs full recode too
(wait for my doc!)
- Game engine will need upgrade too
- Depgraph code needs revision, cleanup, can be much faster!
(But, compliments for Jean-Luc, it works like a charm!)
- IK changed, it now doesnt use previous position to advance to next
position anymore. That system looks nice (no flips) but is not well
suited for NLA and background render.
TODO LATER;
We now can do loadsa new nifty features as well; like:
- Kill PoseMode (can be option for armatures itself)
- Make B-Bones (Bezier, Bspline, like for spines)
- Move all silly button level edit to 3d window (like CTRL+I = add
IK)
- Much better & informative drawing
- Fix action/nla editors
- Put all ipos in Actions (object, mesh key, lamp color)
- Add hooks
- Null bones
- Much more advanced constraints...
Bugfixes;
- OGL render (view3d header) had wrong first frame on anim render
- Ipo 'recording' mode had wrong playback speed
- Vertex-key mode now sticks to show 'active key', until frame change
-Ton-
2005-07-03 17:35:38 +00:00
|
|
|
/* process FAC Ipos used as volume envelopes */
|
2003-08-05 13:39:27 +00:00
|
|
|
ed= G.scene->ed;
|
|
|
|
|
if (ed) {
|
|
|
|
|
seq= ed->seqbasep->first;
|
|
|
|
|
while(seq) {
|
2006-02-05 19:13:44 +00:00
|
|
|
if ((seq->type == SEQ_RAM_SOUND
|
|
|
|
|
|| seq->type == SEQ_HD_SOUND) && (seq->ipo) &&
|
|
|
|
|
(seq->startdisp<=G.scene->r.cfra+2) &&
|
|
|
|
|
(seq->enddisp>G.scene->r.cfra))
|
2007-12-23 21:27:12 +00:00
|
|
|
do_seq_ipo(seq, G.scene->r.cfra);
|
2003-08-05 13:39:27 +00:00
|
|
|
seq= seq->next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
int calc_ipo_spec(Ipo *ipo, int adrcode, float *ctime)
|
|
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return 0;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
if(icu->adrcode == adrcode) {
|
|
|
|
|
if(icu->flag & IPO_LOCK);
|
|
|
|
|
else calc_icu(icu, *ctime);
|
|
|
|
|
|
|
|
|
|
*ctime= icu->curval;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ************************** */
|
|
|
|
|
|
|
|
|
|
void clear_delta_obipo(Ipo *ipo)
|
|
|
|
|
{
|
|
|
|
|
Object *ob;
|
|
|
|
|
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ipo==NULL) return;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
|
ob= G.main->object.first;
|
|
|
|
|
while(ob) {
|
Version 1.0 of IpoDrivers.
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
2005-10-02 20:51:35 +00:00
|
|
|
if(ob->id.lib==NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
if(ob->ipo==ipo) {
|
|
|
|
|
memset(&ob->dloc, 0, 12);
|
|
|
|
|
memset(&ob->drot, 0, 12);
|
|
|
|
|
memset(&ob->dsize, 0, 12);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ob= ob->id.next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void add_to_cfra_elem(ListBase *lb, BezTriple *bezt)
|
|
|
|
|
{
|
|
|
|
|
CfraElem *ce, *cen;
|
|
|
|
|
|
|
|
|
|
ce= lb->first;
|
|
|
|
|
while(ce) {
|
|
|
|
|
|
|
|
|
|
if( ce->cfra==bezt->vec[1][0] ) {
|
2003-04-26 11:56:44 +00:00
|
|
|
/* do because of double keys */
|
2007-12-01 23:25:00 +00:00
|
|
|
if(bezt->f2 & SELECT) ce->sel= bezt->f2;
|
2002-10-12 11:37:38 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
else if(ce->cfra > bezt->vec[1][0]) break;
|
|
|
|
|
|
|
|
|
|
ce= ce->next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cen= MEM_callocN(sizeof(CfraElem), "add_to_cfra_elem");
|
|
|
|
|
if(ce) BLI_insertlinkbefore(lb, ce, cen);
|
|
|
|
|
else BLI_addtail(lb, cen);
|
|
|
|
|
|
|
|
|
|
cen->cfra= bezt->vec[1][0];
|
|
|
|
|
cen->sel= bezt->f2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void make_cfra_list(Ipo *ipo, ListBase *elems)
|
|
|
|
|
{
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
BezTriple *bezt;
|
|
|
|
|
int a;
|
|
|
|
|
|
|
|
|
|
if(ipo->blocktype==ID_OB) {
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
if(icu->flag & IPO_VISIBLE) {
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case OB_DLOC_X:
|
|
|
|
|
case OB_DLOC_Y:
|
|
|
|
|
case OB_DLOC_Z:
|
|
|
|
|
case OB_DROT_X:
|
|
|
|
|
case OB_DROT_Y:
|
|
|
|
|
case OB_DROT_Z:
|
|
|
|
|
case OB_DSIZE_X:
|
|
|
|
|
case OB_DSIZE_Y:
|
|
|
|
|
case OB_DSIZE_Z:
|
|
|
|
|
|
|
|
|
|
case OB_LOC_X:
|
|
|
|
|
case OB_LOC_Y:
|
|
|
|
|
case OB_LOC_Z:
|
|
|
|
|
case OB_ROT_X:
|
|
|
|
|
case OB_ROT_Y:
|
|
|
|
|
case OB_ROT_Z:
|
|
|
|
|
case OB_SIZE_X:
|
|
|
|
|
case OB_SIZE_Y:
|
|
|
|
|
case OB_SIZE_Z:
|
2004-06-26 18:18:11 +00:00
|
|
|
case OB_PD_FSTR:
|
|
|
|
|
case OB_PD_FFALL:
|
|
|
|
|
case OB_PD_SDAMP:
|
|
|
|
|
case OB_PD_RDAMP:
|
|
|
|
|
case OB_PD_PERM:
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
case OB_PD_FMAXD:
|
2002-10-12 11:37:38 +00:00
|
|
|
bezt= icu->bezt;
|
|
|
|
|
if(bezt) {
|
|
|
|
|
a= icu->totvert;
|
|
|
|
|
while(a--) {
|
|
|
|
|
add_to_cfra_elem(elems, bezt);
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
Added the new Timeline Window, copied from Tuhopuu, coded by Matt Ebb.
Main change is that it's an own Space type now, not part of the Audio
window... the audio window should restrict to own options. This way
functionality is nicely separated.
Since it's the first time I added a new space (since long!) I've made an
extensive tutorial as well. You can find that here:
http://www.blender3d.org/cms/Adding_new_Space_Window.557.0.html
Notes for using timewindow;
- Add time markers with MKey
- CTRL+M gives option to name Marker
- Markers cannot be moved yet...
- Pageup-Pagedown keys moves current frame to next-prev Marker
- Xkey removes Markers
- If an object has Ipos or an Action, it draws key lines
- CTRL+Pageup-Pagedown moves current frame to next-prev Key
- Press S or E to set start/end frame for playback
Notes about the implementation in Tuhopuu:
- Add new Marker now selects new, deselects others
- Selecting Marker didn't work like elsewhere in Blender, on click it
should deselect all, except the indicated Marker. Not when holding SHIFT
of course
- Not exported functions are static now
- Removed unused defines (MARKER_NONE NEXT_AVAIL)
- Drawing order was confusing, doing too many matrix calls
- Removed not needed scrollbar, added new function to draw time values.
(Has advantage the MMB scroll works not confusing on a scrollbar)
- Added proper support for 'frame mapping'
- The string button (name Marker) had a bug (checked str[64] while str
was only 64 long)
- String button itself didn't allow "OK on enter"
- Made frame buttons in header larger, the arrows overlapped
- Removed support for negative frame values, that won't work so simple!
2005-05-05 17:19:21 +00:00
|
|
|
else if(ipo->blocktype==ID_AC) {
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
Added the new Timeline Window, copied from Tuhopuu, coded by Matt Ebb.
Main change is that it's an own Space type now, not part of the Audio
window... the audio window should restrict to own options. This way
functionality is nicely separated.
Since it's the first time I added a new space (since long!) I've made an
extensive tutorial as well. You can find that here:
http://www.blender3d.org/cms/Adding_new_Space_Window.557.0.html
Notes for using timewindow;
- Add time markers with MKey
- CTRL+M gives option to name Marker
- Markers cannot be moved yet...
- Pageup-Pagedown keys moves current frame to next-prev Marker
- Xkey removes Markers
- If an object has Ipos or an Action, it draws key lines
- CTRL+Pageup-Pagedown moves current frame to next-prev Key
- Press S or E to set start/end frame for playback
Notes about the implementation in Tuhopuu:
- Add new Marker now selects new, deselects others
- Selecting Marker didn't work like elsewhere in Blender, on click it
should deselect all, except the indicated Marker. Not when holding SHIFT
of course
- Not exported functions are static now
- Removed unused defines (MARKER_NONE NEXT_AVAIL)
- Drawing order was confusing, doing too many matrix calls
- Removed not needed scrollbar, added new function to draw time values.
(Has advantage the MMB scroll works not confusing on a scrollbar)
- Added proper support for 'frame mapping'
- The string button (name Marker) had a bug (checked str[64] while str
was only 64 long)
- String button itself didn't allow "OK on enter"
- Made frame buttons in header larger, the arrows overlapped
- Removed support for negative frame values, that won't work so simple!
2005-05-05 17:19:21 +00:00
|
|
|
if(icu->flag & IPO_VISIBLE) {
|
|
|
|
|
switch(icu->adrcode) {
|
|
|
|
|
case AC_LOC_X:
|
|
|
|
|
case AC_LOC_Y:
|
|
|
|
|
case AC_LOC_Z:
|
|
|
|
|
case AC_SIZE_X:
|
|
|
|
|
case AC_SIZE_Y:
|
|
|
|
|
case AC_SIZE_Z:
|
|
|
|
|
case AC_QUAT_W:
|
|
|
|
|
case AC_QUAT_X:
|
|
|
|
|
case AC_QUAT_Y:
|
|
|
|
|
case AC_QUAT_Z:
|
|
|
|
|
bezt= icu->bezt;
|
|
|
|
|
if(bezt) {
|
|
|
|
|
a= icu->totvert;
|
|
|
|
|
while(a--) {
|
|
|
|
|
add_to_cfra_elem(elems, bezt);
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2005-05-08 20:10:59 +00:00
|
|
|
else {
|
|
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
|
|
|
|
if(icu->flag & IPO_VISIBLE) {
|
|
|
|
|
bezt= icu->bezt;
|
|
|
|
|
if(bezt) {
|
|
|
|
|
a= icu->totvert;
|
|
|
|
|
while(a--) {
|
|
|
|
|
add_to_cfra_elem(elems, bezt);
|
|
|
|
|
bezt++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2006-12-05 01:11:51 +00:00
|
|
|
|
|
|
|
|
/* what's the point of this little block of code? */
|
|
|
|
|
#if 0
|
2002-10-12 11:37:38 +00:00
|
|
|
if(ipo->showkey==0) {
|
2003-04-26 11:56:44 +00:00
|
|
|
/* deselect all keys */
|
2002-10-12 11:37:38 +00:00
|
|
|
ce= elems->first;
|
|
|
|
|
while(ce) {
|
|
|
|
|
ce->sel= 0;
|
|
|
|
|
ce= ce->next;
|
|
|
|
|
}
|
|
|
|
|
}
|
2006-12-05 01:11:51 +00:00
|
|
|
#endif
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* *********************** INTERFACE FOR KETSJI ********** */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
int IPO_GetChannels(Ipo *ipo, IPO_Channel *channels)
|
|
|
|
|
{
|
|
|
|
|
/* channels is max 32 items, allocated by calling function */
|
|
|
|
|
|
|
|
|
|
IpoCurve *icu;
|
|
|
|
|
int total=0;
|
|
|
|
|
|
|
|
|
|
if(ipo==NULL) return 0;
|
|
|
|
|
|
2005-10-10 18:05:30 +00:00
|
|
|
for(icu= ipo->curve.first; icu; icu= icu->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
channels[total]= icu->adrcode;
|
|
|
|
|
total++;
|
|
|
|
|
if(total>31) break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return total;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Get the float value for channel 'channel' at time 'ctime' */
|
|
|
|
|
|
|
|
|
|
float IPO_GetFloatValue(Ipo *ipo, IPO_Channel channel, float ctime)
|
|
|
|
|
{
|
|
|
|
|
if(ipo==NULL) return 0;
|
|
|
|
|
|
|
|
|
|
calc_ipo_spec(ipo, channel, &ctime);
|
|
|
|
|
|
|
|
|
|
if (OB_ROT_X <= channel && channel <= OB_DROT_Z) {
|
|
|
|
|
ctime *= (float)(M_PI_2/9.0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ctime;
|
|
|
|
|
}
|