2023-05-31 16:19:06 +02:00
|
|
|
/* SPDX-FileCopyrightText: Blender Foundation
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2012-02-17 19:59:41 +01:00
|
|
|
#pragma once
|
2008-01-29 22:01:12 +01:00
|
|
|
|
2019-02-17 22:08:12 +01:00
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
2011-02-18 14:05:18 +01:00
|
|
|
*/
|
|
|
|
|
2020-03-02 15:07:49 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2020-12-16 06:26:23 +01:00
|
|
|
struct BVHTree;
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
struct Collection;
|
2019-01-28 11:08:24 +01:00
|
|
|
struct CollisionModifierData;
|
|
|
|
struct Depsgraph;
|
|
|
|
struct MVertTri;
|
2010-03-26 11:52:55 +01:00
|
|
|
struct Object;
|
2008-01-29 22:01:12 +01:00
|
|
|
|
|
|
|
////////////////////////////////////////
|
2023-03-01 17:32:12 +01:00
|
|
|
// used for collisions in collision.cc
|
2008-01-29 22:01:12 +01:00
|
|
|
////////////////////////////////////////
|
|
|
|
|
2008-05-07 22:42:16 +02:00
|
|
|
/* COLLISION FLAGS */
|
2012-06-07 00:38:39 +02:00
|
|
|
typedef enum {
|
2012-05-12 22:39:39 +02:00
|
|
|
COLLISION_IN_FUTURE = (1 << 1),
|
2011-05-02 05:44:02 +02:00
|
|
|
#ifdef WITH_ELTOPO
|
2012-05-12 22:39:39 +02:00
|
|
|
COLLISION_USE_COLLFACE = (1 << 2),
|
|
|
|
COLLISION_IS_EDGES = (1 << 3),
|
2011-05-01 23:39:13 +02:00
|
|
|
#endif
|
2018-09-26 17:18:16 +02:00
|
|
|
COLLISION_INACTIVE = (1 << 4),
|
2008-05-07 22:42:16 +02:00
|
|
|
} COLLISION_FLAGS;
|
2008-01-29 22:01:12 +01:00
|
|
|
|
2008-02-11 14:30:52 +01:00
|
|
|
////////////////////////////////////////
|
2023-03-01 17:32:12 +01:00
|
|
|
// used for collisions in collision.cc
|
2008-01-29 22:01:12 +01:00
|
|
|
////////////////////////////////////////
|
2023-03-01 17:32:12 +01:00
|
|
|
/* used for collisions in collision.cc */
|
2012-05-12 22:39:39 +02:00
|
|
|
typedef struct CollPair {
|
2008-01-29 22:01:12 +01:00
|
|
|
unsigned int face1; /* cloth face */
|
|
|
|
unsigned int face2; /* object face */
|
2018-09-26 17:18:16 +02:00
|
|
|
float distance;
|
2008-01-29 22:01:12 +01:00
|
|
|
float normal[3];
|
|
|
|
float vector[3]; /* unnormalized collision vector: p2-p1 */
|
|
|
|
float pa[3], pb[3]; /* collision point p1 on face1, p2 on face2 */
|
2008-05-07 22:42:16 +02:00
|
|
|
int flag;
|
2008-01-29 22:01:12 +01:00
|
|
|
float time; /* collision time, from 0 up to 1 */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-30 15:23:40 +02:00
|
|
|
/* mesh-mesh collision */
|
2021-06-26 13:35:18 +02:00
|
|
|
#ifdef WITH_ELTOPO /* Either ap* or bp* can be set, but not both. */
|
2011-05-01 23:39:13 +02:00
|
|
|
float bary[3];
|
|
|
|
int ap1, ap2, ap3, collp, bp1, bp2, bp3;
|
|
|
|
int collface;
|
|
|
|
#else
|
2008-05-07 22:42:16 +02:00
|
|
|
int ap1, ap2, ap3, bp1, bp2, bp3;
|
2011-05-01 23:39:13 +02:00
|
|
|
#endif
|
2023-01-06 12:48:36 +01:00
|
|
|
/* Barycentric weights of the collision point. */
|
|
|
|
float aw1, aw2, aw3, bw1, bw2, bw3;
|
2008-05-07 22:42:16 +02:00
|
|
|
int pointsb[4];
|
2008-01-29 22:01:12 +01:00
|
|
|
} CollPair;
|
|
|
|
|
2023-03-01 17:32:12 +01:00
|
|
|
/* used for collisions in collision.cc */
|
2012-05-12 22:39:39 +02:00
|
|
|
typedef struct EdgeCollPair {
|
2008-01-29 22:01:12 +01:00
|
|
|
unsigned int p11, p12, p21, p22;
|
|
|
|
float normal[3];
|
|
|
|
float vector[3];
|
|
|
|
float time;
|
|
|
|
int lastsign;
|
|
|
|
float pa[3], pb[3]; /* collision point p1 on face1, p2 on face2 */
|
|
|
|
} EdgeCollPair;
|
|
|
|
|
2023-03-01 17:32:12 +01:00
|
|
|
/* used for collisions in collision.cc */
|
2012-05-12 22:39:39 +02:00
|
|
|
typedef struct FaceCollPair {
|
2008-01-29 22:01:12 +01:00
|
|
|
unsigned int p11, p12, p13, p21;
|
|
|
|
float normal[3];
|
|
|
|
float vector[3];
|
|
|
|
float time;
|
|
|
|
int lastsign;
|
|
|
|
float pa[3], pb[3]; /* collision point p1 on face1, p2 on face2 */
|
|
|
|
} FaceCollPair;
|
2011-05-01 23:39:13 +02:00
|
|
|
|
2008-01-29 22:01:12 +01:00
|
|
|
////////////////////////////////////////
|
|
|
|
|
|
|
|
/////////////////////////////////////////////////
|
|
|
|
// forward declarations
|
|
|
|
/////////////////////////////////////////////////
|
|
|
|
|
2008-06-03 21:06:54 +02:00
|
|
|
/////////////////////////////////////////////////
|
2023-03-01 17:32:12 +01:00
|
|
|
// used in modifier.cc from collision.cc
|
2008-06-03 21:06:54 +02:00
|
|
|
/////////////////////////////////////////////////
|
2008-08-18 16:41:24 +02:00
|
|
|
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 06:10:43 +01:00
|
|
|
struct BVHTree *bvhtree_build_from_mvert(const float (*positions)[3],
|
2020-12-15 00:47:58 +01:00
|
|
|
const struct MVertTri *tri,
|
|
|
|
int tri_num,
|
|
|
|
float epsilon);
|
|
|
|
void bvhtree_update_from_mvert(struct BVHTree *bvhtree,
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 06:10:43 +01:00
|
|
|
const float (*positions)[3],
|
|
|
|
const float (*positions_moving)[3],
|
2015-07-31 06:00:07 +02:00
|
|
|
const struct MVertTri *tri,
|
|
|
|
int tri_num,
|
|
|
|
bool moving);
|
2008-08-18 16:41:24 +02:00
|
|
|
|
2008-06-03 21:06:54 +02:00
|
|
|
/////////////////////////////////////////////////
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Move Collision modifier object inter-frame with step = [0,1]
|
|
|
|
*
|
|
|
|
* \param step: is limited from 0 (frame start position) to 1 (frame end position).
|
|
|
|
*/
|
2020-01-12 17:08:01 +01:00
|
|
|
void collision_move_object(struct CollisionModifierData *collmd,
|
2022-01-07 01:38:08 +01:00
|
|
|
float step,
|
|
|
|
float prevstep,
|
|
|
|
bool moving_bvh);
|
2008-01-29 22:01:12 +01:00
|
|
|
|
2014-09-12 14:34:14 +02:00
|
|
|
void collision_get_collider_velocity(float vel_old[3],
|
|
|
|
float vel_new[3],
|
|
|
|
struct CollisionModifierData *collmd,
|
|
|
|
struct CollPair *collpair);
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 17:23:29 +02:00
|
|
|
|
2018-06-22 14:42:03 +02:00
|
|
|
/* Collision relations for dependency graph build. */
|
|
|
|
|
|
|
|
typedef struct CollisionRelation {
|
|
|
|
struct CollisionRelation *next, *prev;
|
|
|
|
struct Object *ob;
|
|
|
|
} CollisionRelation;
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create list of collision relations in the collection or entire scene.
|
|
|
|
* This is used by the depsgraph to build relations, as well as faster
|
|
|
|
* lookup of colliders during evaluation.
|
|
|
|
*/
|
2018-06-22 14:42:03 +02:00
|
|
|
struct ListBase *BKE_collision_relations_create(struct Depsgraph *depsgraph,
|
|
|
|
struct Collection *collection,
|
|
|
|
unsigned int modifier_type);
|
|
|
|
void BKE_collision_relations_free(struct ListBase *relations);
|
|
|
|
|
|
|
|
/* Collision object lists for physics simulation evaluation. */
|
Fix depsgraph to compute more accurate links for collision & force.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
2016-08-12 17:23:29 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create effective list of colliders from relations built beforehand.
|
|
|
|
* Self will be excluded.
|
|
|
|
*/
|
2018-06-22 14:42:03 +02:00
|
|
|
struct Object **BKE_collision_objects_create(struct Depsgraph *depsgraph,
|
|
|
|
struct Object *self,
|
|
|
|
struct Collection *collection,
|
|
|
|
unsigned int *numcollobj,
|
|
|
|
unsigned int modifier_type);
|
|
|
|
void BKE_collision_objects_free(struct Object **objects);
|
2008-08-18 16:41:24 +02:00
|
|
|
|
Unified effector functionality for particles, cloth and softbody
* Unified scene wide gravity (currently in scene buttons)
instead of each simulation having it's own gravity.
* Weight parameters for all effectors and an effector group
setting.
* Every effector can use noise.
* Most effectors have "shapes" point, plane, surface, every point.
- "Point" is most like the old effectors and uses the
effector location as the effector point.
- "Plane" uses the closest point on effectors local xy-plane
as the effector point.
- "Surface" uses the closest point on an effector object's
surface as the effector point.
- "Every Point" uses every point in a mesh effector object
as an effector point.
- The falloff is calculated from this point, so for example
with "surface" shape and "use only negative z axis" it's
possible to apply force only "inside" the effector object.
* Spherical effector is now renamed as "force" as it's no longer
just spherical.
* New effector parameter "flow", which makes the effector act as
surrounding air velocity, so the resulting force is
proportional to the velocity difference of the point and "air
velocity". For example a wind field with flow=1.0 results in
proper non-accelerating wind.
* New effector fields "turbulence", which creates nice random
flow paths, and "drag", which slows the points down.
* Much improved vortex field.
* Effectors can now effect particle rotation as well as location.
* Use full, or only positive/negative z-axis to apply force
(note. the z-axis is the surface normal in the case of
effector shape "surface")
* New "force field" submenu in add menu, which adds an empty
with the chosen effector (curve object for corve guides).
* Other dynamics should be quite easy to add to the effector
system too if wanted.
* "Unified" doesn't mean that force fields give the exact same results for
particles, softbody & cloth, since their final effect depends on many external
factors, like for example the surface area of the effected faces.
Code changes
* Subversion bump for correct handling of global gravity.
* Separate ui py file for common dynamics stuff.
* Particle settings updating is flushed with it's id through
DAG_id_flush_update(..).
Known issues
* Curve guides don't yet have all ui buttons in place, but they
should work none the less.
* Hair dynamics don't yet respect force fields.
Other changes
* Particle emission defaults now to frames 1-200 with life of 50
frames to fill the whole default timeline.
* Many particles drawing related crashes fixed.
* Sometimes particles didn't update on first frame properly.
* Hair with object/group visualization didn't work properly.
* Memory leaks with PointCacheID lists (Genscher, remember to
free pidlists after use :).
2009-10-01 00:10:14 +02:00
|
|
|
typedef struct ColliderCache {
|
|
|
|
struct ColliderCache *next, *prev;
|
|
|
|
struct Object *ob;
|
|
|
|
struct CollisionModifierData *collmd;
|
|
|
|
} ColliderCache;
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create effective list of colliders from relations built beforehand.
|
|
|
|
* Self will be excluded.
|
|
|
|
*/
|
2020-09-04 20:59:13 +02:00
|
|
|
struct ListBase *BKE_collider_cache_create(struct Depsgraph *depsgraph,
|
2018-06-22 14:42:03 +02:00
|
|
|
struct Object *self,
|
|
|
|
struct Collection *collection);
|
|
|
|
void BKE_collider_cache_free(struct ListBase **colliders);
|
Unified effector functionality for particles, cloth and softbody
* Unified scene wide gravity (currently in scene buttons)
instead of each simulation having it's own gravity.
* Weight parameters for all effectors and an effector group
setting.
* Every effector can use noise.
* Most effectors have "shapes" point, plane, surface, every point.
- "Point" is most like the old effectors and uses the
effector location as the effector point.
- "Plane" uses the closest point on effectors local xy-plane
as the effector point.
- "Surface" uses the closest point on an effector object's
surface as the effector point.
- "Every Point" uses every point in a mesh effector object
as an effector point.
- The falloff is calculated from this point, so for example
with "surface" shape and "use only negative z axis" it's
possible to apply force only "inside" the effector object.
* Spherical effector is now renamed as "force" as it's no longer
just spherical.
* New effector parameter "flow", which makes the effector act as
surrounding air velocity, so the resulting force is
proportional to the velocity difference of the point and "air
velocity". For example a wind field with flow=1.0 results in
proper non-accelerating wind.
* New effector fields "turbulence", which creates nice random
flow paths, and "drag", which slows the points down.
* Much improved vortex field.
* Effectors can now effect particle rotation as well as location.
* Use full, or only positive/negative z-axis to apply force
(note. the z-axis is the surface normal in the case of
effector shape "surface")
* New "force field" submenu in add menu, which adds an empty
with the chosen effector (curve object for corve guides).
* Other dynamics should be quite easy to add to the effector
system too if wanted.
* "Unified" doesn't mean that force fields give the exact same results for
particles, softbody & cloth, since their final effect depends on many external
factors, like for example the surface area of the effected faces.
Code changes
* Subversion bump for correct handling of global gravity.
* Separate ui py file for common dynamics stuff.
* Particle settings updating is flushed with it's id through
DAG_id_flush_update(..).
Known issues
* Curve guides don't yet have all ui buttons in place, but they
should work none the less.
* Hair dynamics don't yet respect force fields.
Other changes
* Particle emission defaults now to frames 1-200 with life of 50
frames to fill the whole default timeline.
* Many particles drawing related crashes fixed.
* Sometimes particles didn't update on first frame properly.
* Hair with object/group visualization didn't work properly.
* Memory leaks with PointCacheID lists (Genscher, remember to
free pidlists after use :).
2009-10-01 00:10:14 +02:00
|
|
|
|
2008-08-18 16:41:24 +02:00
|
|
|
/////////////////////////////////////////////////
|
|
|
|
|
2008-01-29 22:01:12 +01:00
|
|
|
/////////////////////////////////////////////////
|
|
|
|
|
2020-03-02 15:07:49 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|