| Re: Nape new alpha [message #1291 is a reply to message #670] |
Wed, 07 September 2011 23:57   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Milestone 6.0
Start of geometric utilities.
# Monotone and Convex decompositions should be very stable and robust given a sensible input. Simple decomposition is not quite as stable or robust yet.
GeomPoly encompasses the geometric utilities as a Geometric Polygon. Interface is to an internal circular linked list.
current() is a reference to the current 'head' of the polygon, the only difference between pop() and shift() is the position of the 'head' after the removal.
+ Winding
+ Clockwise
+ AntiClockwise
+ Undefined
+ GeomPoly
+ new ({Array<Vec2>,Vector<Vec2>,Vec2List,GeomPoly}=null)
+ push(Vec2) : Vec2
+ unshift(Vec2) : Vec2
+ pop() : Void
+ shift() : Void
+ erase(Int) : Void //can be negative
+ skip_forward(Int) : Void
+ skip_backwards(Int) : Void
+ current() : Vec2
+ isSimple() : Bool //O(n.log(n))
+ isMonotone() : Bool //y-monotone, O(n)
+ isConvex() : Bool //O(n)
+ isDegenerate() : Bool //O(n)
// when polygon is not simple, result is not well-defined
+ winding() : Winding //O(n)
+ isClockwise() : Bool //O(n), same properties of winding()
+ area() : Float //O(n)
+ empty() : Bool //O(1)
+ size() : Int //O(n)
+ copy() : GeomPoly //O(n)... obviously
// postcondition: empty()
+ clear() //O(n)
// precondition: !isDegenerate()
// postcondition: for each(output) output.isSimple()
+ simple_decomposition() : GeomPolyList // O((n+k).log(n)) where k is the number of self intersections
// precondition: isSimple(), !isDegenerate()
// postcondition: for each(output) output.isMonotone()
+ monotone_decomposition() : GeomPolyList // O(n.log(n))
// precondition: isSimple(), !isDegenerate()
// postcondition: for each(output) output.isConvex()
+ convex_decomposition() : GeomPolyList // O(n.log(n))
+ toArray() : Array<Vec2> //not important anymore.
To the debug drawers:
~Debug
+ drawPolygon({Array<Vec2>,Vector<Vec2>,Vec2List,GeomPoly}, colour:Int)
+ drawFilledPolygon({Array<Vec2>,Vector<Vec2>,Vec2List,GeomPoly},colour:Int)
where drawFilledPolygon when using BitmapDebug performs a simple+convex decomposition on the polygon first and uses drawFilledTriangle internally.
Polygon constructor has also been modified to accept a GeomPoly as input.
I created nape!
|
|
|
| Re: Nape new alpha [message #1294 is a reply to message #1291] |
Fri, 09 September 2011 23:19   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r3"
Simple decomposition is more robust now.
isSimple and simple_decomposition have diverged now, the resulting polygons from a simple_decompositino are not guaranteed to be simple as defined by isSimple(), but will always work (given that simple_decomposition performs properly) in a convex/monotone decomposition.
I created nape!
|
|
|
| Re: Nape new alpha [message #1295 is a reply to message #1294] |
Sun, 11 September 2011 12:23   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r11/r15"
Changes made to both nape and part of my tool chain to reduce .swc sizes down from 410kb for r3, to 277kb for r15 on release_nape.swc.
These changes (on the tool chain side) have the potential to break the .swc, but it seems to be fine in testing so far.
I created nape!
|
|
|
| Re: Nape new alpha [message #1296 is a reply to message #1295] |
Tue, 13 September 2011 17:15   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r19"
Fixed a bug in GeomPoly::copy (previously didn't actually return a value)
and added:
GeomPoly::simplify(epsilon:Float) -> GeomPoly
which performs a simplification of the polygon (whether simple or self intersecting) so that the maximum distance from the original polygon to the return polygon at any vertex is less than epsilon where the returned polygon is formed via taking a subset of the original polygon's vertices.
This (like all the other geometric utils) is an O(n.log(n)) algorithm.
----------------------------------
Important non-geometric change.
I realised that the recent changes to help with memory management which meant that things like Material only track the 'live' shapes resulted in the behaviour of 'sharing' materials breaking.
The exact behaviour broken being that previously if you had 4 shapes sharing a material, and you then set material.shared = false the 4 shapes would be given a copy so that none of them shared the material any longer.
Now since the material will not track all of the shapes using it, this is no longer the case. And so with no reasonable way of getting around this without introducing the original memory problems for which these changes were made, the 'shared' property of Material/InteractionFilter/FluidProperties has been removed and all of these are now by default shareable.
[Updated on: Tue, 13 September 2011 17:18] I created nape!
|
|
|
| Re: Nape new alpha [message #1299 is a reply to message #1296] |
Wed, 14 September 2011 00:51   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r20"
Small changes made to the probably yet to be used by anyone Callback type so that arbiter/body/constraint are always well defined and are null when not applicable to the callback.
AND!!! more importantly.
Unless i've missed something out the api documentation should be fully up to date now! (took a rather long time... :S)
I created nape!
|
|
|
| Re: Nape new alpha [message #1310 is a reply to message #1299] |
Tue, 20 September 2011 00:21   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r28" : Milestone 6.1
Small additions of:
GeomPoly :: contains(position:Vec2) : Bool
GeomPoly :: iterator/forward_iterator/backwards_iterator : Iterator<Vec2>
Large addition in marching squares.
MarchingSquares :: static run (iso:Float->Float->Float, bounds:AABB, cellsize:Vec2, ?quality:Int=2, ?subgrid:Vec2=null, ?combine:Bool=true) : GeomPolyList.
Given a function 'iso', we generate polygons corresponding to the regions of space bounded by the 'bounds' AABB such that iso(x,y) <= 0.0. cellsize : Vec2 determines the granularity of the sampling grid from which the initial polygons are generated, using 'quality' number of iterations when interpolating along cell edges.
When combine is true (by default). The large number of polygons generated (bounded by number of cells) are combined into larger weakly-simple polygons which are guaranteed to be decomposable by the convex and monotone decomposition algorithms. It is not necessary (and in general may not work) to perform a simple decomposition of the output when combining polygons.
The subgrid : Vec2 is to provide the equivalent to old nape Geom::marchingMesh where the bounds : AABB is split first under a grid defined by subgrid, and each cell is then operated on seperately as though multiple calls were made to MarchingSquares :: run on each grid cell.
------------
Other big changes, are to do with simplification which are not at this point directly accessible to the user.
Vertices of the GeomPoly's may be marked internally so as that a call to the simplify() function will be guaranteed to include these vertices no matter what.
This is used in the simple_decomposition, marking vertices corresponding to intersections.
In monotone and convex decompositions for vertices on either side of internal diagonals used in partioning the polygon.
And in MarchingSquares for vertices on either side of any internal 'cuts' made to allow holes when combining polygons, and also on the boundary of the grid and any subgrid if applicable. When combine is false this is extended to the cell level so that in fact every vertex in this case would be marked.
This is done so that any simplification routine will not 'open up' gaps inside of a logical polygon which has been decomposed.
It would be recommened to call simplify() on the output of marching squares so that you can retain high fidelity in the surface extraction, but without having too many vertices in the final polygons. We must be careful here however as the current simplify() algorithm does 'not' guarantee that a non self-intersecting polygon will still be non self-intersecting after we simplify it so we should not use too large an epsilon in the simplify routine.
MarchingSquares here in new nape is significantely faster than old nape marching squares when combining polygons, and should be 100% robust given a sensible input (Aka iso function meets requirements).
Docs will be updated shortly.
I created nape!
|
|
|
|
| Re: Nape new alpha [message #1312 is a reply to message #1311] |
Wed, 21 September 2011 01:47   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Should make a point of mentioning that I have now discovered some corner cases to do with degeneracies which marching squares does not handle and will cause issues.
(Though it is still more robust than old-nape marching squares).
These corner cases should hopefully not prove too troublesome and i'll be looking into classifying them properly tomorrow.
--edit: Note that the bug isn't actually in the marching squares per-se... marching squares is perfect. The issue is more work needs to be done to deal with degeneracies to ensure it's output is suitable for use in the convex/monotone decompositions in all cases.
[Updated on: Wed, 21 September 2011 11:53] I created nape!
|
|
|
| Re: Nape new alpha [message #1325 is a reply to message #1312] |
Thu, 22 September 2011 18:57   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r29"
Marching Squares should now handle all possible degenerate cases which previously prevented it's output being 100% compatible with monotone and convex decompositions.
I created nape!
|
|
|
| Re: Nape new alpha [message #1454 is a reply to message #1325] |
Mon, 14 November 2011 16:57   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r65"
Apart from lots of bug fixes since my lost post here, today there's been a couple changes/additions:
Space::shapesInShape and Space::bodiesInShape no longer take an optional InteractionFilter, instead the InteractionFilter of the input shape is used.
There is now also Space::shapesInBody and Space::bodiesInBody which performs a merger of the above functions over each shape, which has an optional interaction filter argument which will override those of the bodies' shapes.
There is now also in the nape lists, a merge method: List<T> :: merge : List<T> -> Void, which will merge the given list into the 'this' list as though the two lists are infact sets.
----
Documentation for these has been added, and since my last post here there has also been lots of missing tidbits of documentation inserted.
[Updated on: Mon, 14 November 2011 16:58] I created nape!
|
|
|
| Re: Nape new alpha [message #1466 is a reply to message #1454] |
Tue, 15 November 2011 12:18   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r66"
Added 'weak' Vec2's to aid anyone that wants to try and have Vec2's reused as much as possible. (Still like Vec2.get(..) is 100% optional).
Many methods now have an additional optional parametere 'weak' to ask for a 'weak' Vec2 to be returned instead of a normal one, as well as the new static functino Vec2.weak(x,y) == Vec2.get(x,y,true).
Weak vec2's are such that when supplied to a nape function, they will be automaticly disposed of at the end of the function, for example:
new Body(BodyType.DYNAMIC, Vec2.weak(x,y));
rather than
var v = Vec2.get(x,y);
new Body(BodyType.DYNAMIC, v);
v.dispose();
The behaviour with lists of Vec2 is slightly different in that pushing a weak Vec2 to a list will simply... push it to the list, but when that list is supplied to a nape function, any weak Vec2's contained will be disposed of automaticaly and removed, for instance:
new Polygon(Polygon.box(w,h,true));
instead of
var vs = Polygon.box(w,h);
new Polygon(vs);
for(v in vs) v.dispose();
----
I iterate, this is all 100% optional
I created nape!
|
|
|
| Re: Nape new alpha [message #1469 is a reply to message #1466] |
Tue, 15 November 2011 13:36   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r67"
small change, userData field is copied by reference in all copy methods.
I created nape!
|
|
|
| Re: Nape new alpha [message #1475 is a reply to message #1469] |
Fri, 18 November 2011 15:38   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r68"
Small addition.
FluidProperties now has a field 'gravity' of type Vec2. Initially set to null (and can be reset to null); when non-null this value overrides space.gravity in buoyancy calculations.
I created nape!
|
|
|
| Re: Nape new alpha [message #1478 is a reply to message #1475] |
Sat, 19 November 2011 02:14   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r70"
More bug fixes (one was very annoying to track >.> but got there in the end). Couple new features:
Geom :: intersects : Shape -> Shape -> Bool to test if two shapes belonging to some body so that they are well defined intersect (Body need not belong to a space).
Geom :: contains : Shape -> Shape -> Bool to test if the first shape contains the second shape with the same rules as above.
These complement the existing Geom :: distance function, and will at some point in very near future be expanded once more with Geom :: intersection : Shape -> Shape -> ??? to perform the buoyancy intersections on two generic shapes, at the vert least the exposed information will be the centroid of the intersection and the intersectino area, at most I guess I could possibly expose a representation of the actual intersection (A list of line segments and circular arcs in the general case) If that could be of any use to people I don't know, this level of detail in the intersection is not currently exposed through the FluidArbiter of two interacting shapes.
I'll also expand the space query methods at some point soon to allow 'strict' inclusion in the query, so that for instance space.shapesInCircle(..., true) will return only those shapes entirely contained within the circle, rather than those only partially contained by intersection
[Updated on: Sat, 19 November 2011 02:15] I created nape!
|
|
|
| Re: Nape new alpha [message #1487 is a reply to message #1478] |
Sun, 20 November 2011 23:09   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"r72"
Add 'containment' parameter to most space query methods to query shapes/bodies entirely contained within the given shape. The shapesInBody bodiesInBody methods do not have this parameter as including a containment option would be very complex.
I created nape!
|
|
|
| Re: Nape new alpha [message #1491 is a reply to message #1487] |
Tue, 22 November 2011 16:20   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
"rsomething"
regressed api for shapes/bodiesInShape/Body w.r.t. to interaction filter so that the input shape/body act purely in a geometric sense with any optional filtering provided by filter argument alla shapes/bodiesInCircle/AABB
I created nape!
|
|
|
| Re: Nape new alpha [message #1600 is a reply to message #670] |
Tue, 27 December 2011 21:24   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Milestone 7.1 - Interaction callbacks.
I can only apologise for the delay in getting these ready (Due to heavy workload at university)
.........
NOTE: A break in past functionality:
The default cbType for all types is now 'null' not CbType.DEFAULT so this may break any code already using the Body/Constraint callbacks [noting that the listener cannot listen on null cbTypes]
.........
The callbacks are roughly equivalent to old-nape callbacks (just more reliable with less overhead).
In the next few days I'll put together some samples to fully show how they work, for now a quick summary:
Interaction/Pre callbacks occur between mixes of Shapes and Bodies depending on the shape/body cbType's (Which is now 'null' by default with no CbType.DEFAULT to add noise)
new InteractionListener(CbEvent.BEGIN, cb1,cb2, ?handler)
Event occurs when two 'interactors' with cbType's cb1/cb2 begin to overlap interacting either as sensors, fluids, or collidables.
The optional handler (which should be used by default for ease of use) should be a function of type:
Interactor->Interactor->Void
which takes the two interacting objects (ordered the same as the supplied cbType's when un-ambiguous) which have two properties 'shape : Shape' and 'body : Body' with one obviously being null depending on what exactly it corresponds to.
new InteractionListener(CbEvent.END, cb1,cb2, ?handler)
As above, but occurs when the two shapes/bodies stop overlapping/interacting as sensors/fluids/collidables.
Finally (the most powerful as the above have to this point been supplied (without stability and effeciency) by the Collides class)
new PreListener(cb1,cb2, handler)
this event (only one applies, so no argument for the CbEvent) occurs right in the middle of a space.step() as soon as it is determined that the two objects 'should' interact in some manner and information like contacts/fluid centroids have been computed.
The (non-optional) handler is of type which supplies the first arbiter to be handled by nape for the two interactors (whether Shape's or Body's).
The return type 'PreFlag' has 4 values, ACCEPT, IGNORE, ACCEPT_ONCE, IGNORE_ONCE which informs nape what you want to do.
if you return ACCEPT, then the interaction will proceed as normal until the interactors seperate.
if you return IGNORE, then the interaction will be ignored as though it were filtered out by the InteractionFilters (with the difference that you can still get BEGIN/END events which will not be given when the interactino is filtered out).
if you return #_ONCE, then for that step alone the behaviour will be as above, then in the next step if the two interactors are still overlapping, you will get another call to the handler with the first arbiter nape handles (might not be the same one) and you will once more be asked what you want to be done.
As the PRE event occurs 'during' a space.step() call (rather than at the end) there are certain things you can modify to hack about internally in nape (There are safety nets in place in debug builds to make sure you aren't doing things that are invalid) but doing this will be quite rare.
I created nape!
|
|
|
| Re: Nape new alpha [message #1601 is a reply to message #1600] |
Tue, 27 December 2011 21:25   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Note: There is no 'milestone 7' help thread here in features/development like previous versions. Please direct any help related questions to the Help forum from now on.
I created nape!
|
|
|
|
| Re: Nape updates [message #1631 is a reply to message #670] |
Tue, 10 January 2012 19:59   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Milestone 7.2
Introducing InteractionGroup trees, and Compound trees.
InteractionGroup's are a slightly less powerful, but more general way of approaching filtering out unwanted interactions.
Compound's being groupings of Bodies, Constraints and other Compounds into trees that act like single physical entities when it comes to Interaction and Pre callbacks + more fun.
---------------------------------------
New demo Filtering displaying both InteractionGroup's and InteractionFilters
And changes to the Callbacks demo to display Compounds.
---------------------------------------
API Changes (loss of backwards compatability)
//basic name change.
Shape::circle => Shape::castCircle
Shape::polygon => Shape::castPolygon
//removal
Space::kinematics, Space::dynamics, Space::statics
[Updated on: Tue, 10 January 2012 20:01] I created nape!
|
|
|
| Re: Nape updates [message #1637 is a reply to message #1631] |
Sat, 14 January 2012 14:43   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r2
Added a few compound helpers and related.
Vec2::rotate(angle:Float):Vec2 rotating vector in place and returning 'this'
Body::rotate(centre:Vec2, angle:Float):Void rotating body about given point in world space
Compound::translate(translation:Vec2):Void, translate every body inside
Compound::rotate(centre:Vec2, angle:Float):Void, rotate every body inside about given point
Compound::visitBodies(lambda:Body->Void):Void, apply given function to all bodies contained at some level of the compound tree
Compound::visitConstraints(...)
Compound::visitCompounds(...)
I created nape!
|
|
|
| Re: Nape updates [message #1645 is a reply to message #1637] |
Mon, 16 January 2012 21:29   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r3
StressPyramid demo + a few small improvements to library physical size and an optimisation made with recent callback additions.
r4
Optional sorting of dynamic contacts (default enabled) which can improve stability in large complex piles/stacks especcially when working with dyn-aabb broadphase (default) due to no inherent ordering being present.
This is not enough to make sweep/dyn-aabb respond exactly the same (as other arbiter types are not sorted and will exist in different orders still).
Improvement made to the performance of the dyn-aabb (default) broadphase, significant in some cases.
+Space::sortContacts = true
+Space::userData : Dynamic
+Space::id : Int
I created nape!
|
|
|
| Re: Nape updates [message #1646 is a reply to message #1645] |
Tue, 17 January 2012 01:00   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r5
Body::graphic is now typed Dynamic (* in AS3)
and addition:
Body::graphicUpdate : Body->Void
as a method of customising how the graphic is represented (graphic need not actually exist).
for instance, the way nape normally renders graphic would be emulated with:
body.graphic = ...;
body.graphicUpdate = function(b:Body) {
b.graphic.x = b.position.x;
b.graphic.y = b.position.y;
b.graphic.rotation = (b.rotation*180/Math.PI)%360;
}
and the graphic isn't actually needed, you could do:
body.graphic = null; <-- doesn't matter, graphicUpdate takes precedence
body.graphicUpdate = function(b:Body) {
//do some custom rendering without any display object or similar at all.
}
Technically speaking, using the graphicUpdate handler is actually more performant than iterating the list of bodies and drawing them like that (Not only since graphicUpdate will only be called on bodies that actually 'need' to be updated; aka have had their position/rotation change) but because either way you will have the same number of function calls (N calls to graphicUpdate, or N calls to list.at(...) or 2N calls via haxe iterator with hasNext()/next()) <-- not that any of this would ever be a bottleneck compared to the actual rendering itself
I created nape!
|
|
|
| Re: Nape updates [message #1651 is a reply to message #1646] |
Wed, 18 January 2012 22:11   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r8
Extension to Interaction/PreListeners.
eg:
new InteractionListener(CbEvent.BEGIN, InteractionType.COLLISION, cb1, cb2, handler);
new PreListener(InteractionType.ANY, cb1, cb2, handler);
Noting that InteractionType.ANY is the equivalent to pre-r8 behaviour.
What the InteractionType argument means is that the begin/end/pre callback will occur when the two interactors start to 'actually' collide or 'actually' stop colliding etc.
When using InteractionType.ANY in comparison (as was default pre-r8) the begin/end/pre callbacks occur when the two interactors start to interact in 'any' way, whether they actually have started colliding, or simply started sensing.
I created nape!
|
|
|
| Re: Nape updates [message #1657 is a reply to message #1651] |
Sun, 22 January 2012 01:08   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Milestone 7.3
User-defined constraints added 
Checkout the .pdf tutorial describing deriviations and how such constraints should be constructed to fit into the nape API as a normal constraint type. UserConstraint API entry
the .pdf demonstrated a reimplementation of the PivotJoint, whilst the new demo demonstrated a reimplementation of the WeldJoint as a user constraint.
[Updated on: Sun, 22 January 2012 01:08] I created nape!
|
|
|
|
| Re: Nape updates [message #1711 is a reply to message #1658] |
Sun, 29 January 2012 23:29   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r6
I cannot remember with but r4/r5 introduced Body::crushFactor : Float which computes an estimate of how much a body is being crushed by opposing forces acting on it.
r6 introduces full debug drawing for constraints very pretty now. (Check the constraints demo to see the new debug draw in action)
[Updated on: Sun, 29 January 2012 23:29] I created nape!
|
|
|
| Re: Nape updates [message #1764 is a reply to message #1711] |
Tue, 31 January 2012 18:56   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r8
r7 fixed a small bug in Body::rotate/Compound::rotate cannot remember which to do with using a Weak Vec2.
r8 fixes a bug to do with InteractionGroup assignments and changes a lot of internal structures regarding shared Interactor behaviours and properties.
very slight break with backwards compatability.
CbType::shapes/bodies no longer exist
and there is now CbType::interactors (which also tracks the previously ignored Compounds using the CbType actively)
I created nape!
|
|
|
| Re: Nape updates [message #1769 is a reply to message #1764] |
Wed, 01 February 2012 22:55   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r9
Another very slight break in backwards compatability.
InteractionListener function handlers must now take an additional argument: an ArbiterList for the arbiters that exist at that moment in time between the two Interactors (noting that 'in general' it will be empty on an END callback (but not always since you might listen for the end of a collision, but at that point there may still be fluid/sensor arbiters).
Noting also that the ArbiterList does not discriminate against 'type' of arbiter, so even if it's an event listening for InteractionType.COLLISION, the arbiter list may contain sensor/fluid arbiters that exist between the interactors also.
In recap:
instead of:
function(int1:Interactor,int2:Interactor):void { }
you now have:
function(int1:Interactor,int2:Interactor,arbs:ArbiterList):void { }
I created nape!
|
|
|
| Re: Nape updates [message #1814 is a reply to message #1769] |
Tue, 07 February 2012 01:02   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r12
Bug fixes in between.
Addition in r12 is the ONGOING event type.
The ONGOING event type occurs whenever two interactors are in the process of interacting (and overlaps with the BEGIN event).
In the case of both a BEGIN and ONGOING listener being registers, it is guaranteed that the BEGIN event will always occur first (both in the callback queue and in term of handler's being called).
I created nape!
|
|
|
|
| Re: Nape updates [message #1853 is a reply to message #1823] |
Tue, 07 February 2012 22:39   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r14
Fixed bug with InteractionListener's handler's ArbiterList arguments.
I created nape!
|
|
|
| Re: Nape updates [message #1885 is a reply to message #1853] |
Wed, 08 February 2012 19:36   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r15
Hopefully fixed a bug to do with changing CbType/Listener's at runtime.
Also introduced Space::visitBodies,visitConstraints,visitCompounds to mirror the methods that exist in Compound already.
I created nape!
|
|
|
|
|
| Re: Nape updates [message #1906 is a reply to message #1902] |
Fri, 10 February 2012 01:52   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r18
More bug-fixes regarding run-time changes to interaction types, cb types and listeners w.r.t. callbacks, in testing seems to be stable now with whatever crazyness I throw at it.
I created nape!
|
|
|
| Re: Nape updates [message #1907 is a reply to message #1906] |
Fri, 10 February 2012 01:54   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
Clearly should have just gone to bed....
r19
Left a trace statement again... perhaps I should add a check in my release script to ensure there aren't any before releasing hahaha.
I created nape!
|
|
|
| Re: Nape updates [message #1936 is a reply to message #1907] |
Sun, 12 February 2012 21:18   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r20
Add missing breaking of constraint to LineJoint (Thanks Antriel for pointing that out)
Add missing doc-entry for Constraints (Constraint::removeOnBreak : Bool)
I created nape!
|
|
|
| Re: Nape updates [message #1971 is a reply to message #1936] |
Wed, 15 February 2012 11:51   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
r21
Bug fix regarding lset!=null assertion failure to do with adding/removing listeners at runtime.
Bug fix regarding listeners not being inserted/removed from the space.listeners list when using expressions 'listener.space = ###'
I created nape!
|
|
|
| Re: Nape updates [message #1975 is a reply to message #1971] |
Thu, 16 February 2012 09:43   |
dELtaluca Messages: 1299 Registered: July 2010 Location: Surbiton, London |
Senior Member Administrator |
|
|
m7.4
Fix regarding contacts not being released to object pool when removed during a pre-event handler.
Changes to callbacks: (After poll)
Handlers for non-pre event types are no longer optional, with removal of space.callbacks queue
Handler arguments change from the actual objects involved to a more complete Callback object open for additional properties to be added without having to change API in an annoying way again, remembering that Callback object already has properties 'event' and 'listener' to reference the CbEvent type for the callback object, and the Listener responsible for generating the handler call and Callback object generation.
PreCallback having more substantial additions being the interactors on which the callback was generated for, rather than simply the arbiter and it's two shapes/bodies (since callback can occur between any compound trees), together with a 'swapped' property to denote that the arbiter's body1/shape1 belongs to the second interactor, and not the first based on cbTypes.
- CallbackQueue
~ Space {
- callbacks : CallbackQueue
}
+ BodyCallback extends Callback {
+ body : Body
}
+ ConstraintCallback extends Callback {
+ constraint : Constraint
}
+ InteractionCallback extends Callback {
+ int1 : Interactor
+ int2 : Interactor
+ arbiters : ArbiterList
}
+ PreCallback extends Callback {
+ int1 : Interactor
+ int2 : Interactor
+ arbiter : Arbiter
+ swapped : Bool
}
~ BodyListener {
- ?handler:Body->Void
+ handler:BodyCallback->Void //no longer optional, same change for constructor
}
~ ConstraintListener {
- ?handler:Constraint->Void
+ handler:ConstraintCallback->Void //no longer optional, same change for constructor
}
~ InteractionListener {
- ?handler:Interactor->Interactor->ArbiterList->Void
+ handler:InteractionCallback->Void //no longer optional, same change for constructor
}
~ PreListener {
- handler:Arbiter->PreFlag
+ handler:PreCallback->PreFlag
}
Demos and documentation updated to reflect changes.
I created nape!
|
|
|