A Python API for the collision group / mask has been added:
```
KX_GameObject.collisionGroup
KX_GameObject.collisionMask
```
The maximum number of collision groups and masked has been increased from eight to sixteen.
This means that the max value of collisionGroup/Mask is (2 ** 16) - 1
EndObject will now activate objects that were sleeping and colliding with the removed object.
This means that, unlike now, if a rigid body starts sleeping on top of another object, when the latter is removed the rigid body will activate and fall, rather than float midair as before.
Collision groups that do not intersect used to collide on the first frame. Now this has been fixed so that they collide appropriately.
Thanks to agoose77 for his help.
Reviewers: scorpion81, hg1, agoose77, sergof
Reviewed By: agoose77, sergof
Subscribers: sergof, moguri
Projects: #game_physics, #game_engine
Differential Revision: https://developer.blender.org/D1243
This approach gets rid of iuser->pass for good.
Also, I'm commenting out the pass increase/decrease. This was broken
since multiview. I will fix it later (before 2.75), but I didn't want to
get this patch mangled with that fix.
Thanks Sergey Sharybin for the review and feedbacks.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1232
While investigating T44412, I noticed some weirdness going on when trying to
draw on frame 0 (i.e. strokes were getting added to frame 1 instead). Clearly,
this seemed like an off-by-one error related to clamping to prevent negative
frames which was also excluding frame 0.
This commit reverts the fixes made for T36831 in:
rBf18f2fbb33d90ecc91e6f3d063cb9f97f217e808
After thinking this over, I think these checks against drawing on negative
frames aren't needed. Even if the current userpref setting doesn't allow
navigating to negative frames, this may not be true for other users that
may work on the same file (in a team environment). Also, negative frame
values can get set via the dopesheet.
Tessellation data isn't used for drawing or sculpting.
This frees up some memory ~approx 10% in own tests.
Also slight spee-up since it avoids calculating it in the first place.
Use tagging to avoid re-evaluating the same edges while sculpting.
While gives only minor speedup,
it allows for changes to the queue without additional redundant checks.
There should be no functional changes visible from this change, but this commit
should make it easier to code tools which need to check on tweeakmode status,
by making it easier to figure out which NLA Track contains the strip which
owned the action being edited. (The strip is already saved, so this commit just
adds the track alongside it).
For now there is no version patch for this. The worst that happens is that an
extra refresh is needed in the NLA editor to get these to show up.
To help make it more convenient to edit stashed actions, Shift-Tab
(i.e. holding down the Shift key, which "tabbing" into tweakmode as
usual to edit the action referenced by the active NLA strip) now flags
the NLA Track that the strip occupies as being "solo" too.
This allows you to use the NLA to select a stashed action, then Shift-Tab
to start editing it without any other actions in the NLA stack interfering.
Like the "Next/Previous Layer" tools in the Action Editor, this is designed
to help with checking on stashed actions.
Dyntopo can currently create skinny faces,
especially when the faces are much larger then the resolution.
To get the old behavior, set debug value to 1234
Allocate statistics array dynamically, so increasing max number of threads does
not increase sloppyness of the memory usage.
For the further cleanups: we can try alloca-ing this array, but it's also not
really safe because we can have quite huge number of threads in the future.
Plus statistics will allocate memory for each individual entry, so using alloca
is not going to give anything beneficial here.
The issue was caused by phase being limited from 0 to 1, which gave only
0..M_PI distribution which is not good enough for good randomness.
Now the phase is being randomized across full 0..2*M_PI range.
Issue here is simple and has been fixed in other places such as
texpainting: Basically if face has different winding, do not calculate
it as adjucent to the other face, even if UV is identical.
This allows us to stack islands of symmetrical closed meshes on top of
one another and still be able to select the two identical island halfs
(provided the normals are correct of course).
The issue was introduced in rB4b685e1 and it appears some crazy area still
accesses particles for render after deleting it's render data, which broke
viewport/render behavior.
This commit restores previous G.is_rendering logic and adds corresponding
checks to cache construction, so counting is all consistent.
Goes to the TODO list to either replace G.is_rendering with eval_ctx or to
make it so psys->renderdata always exists during render sync.
