Yep.
I also just noticed (unfortunately!) that once the object I'm dragging
gets rotated, the new Drag3D gets upset. In fact, from that point on, even
if I return the object to its original rotation, it never drags correctly
:(
On Tue, 14 Sep 2010 14:46:02 -0700, Fabrice3D <[email protected]> wrote:
i'll look at it, but before I do, do you updatedrag on enterframe from
the moment the user starts to drag?
the vector need constant update.
Fabrice
On Sep 14, 2010, at 11:39 PM, Joshua Granick wrote:
Hi again :)
Here's one more thing that broke with this release. Not sure if its
related.
If I select an instance, it uses Drag3D to begin dragging. If I change
the camera angle while it is still selected, the dragging gets weird.
As a workaround, I need to deselect the object before changing the
camera. Then the user will have to click to select the object again,
and dragging will work correctly.
This also used to work without a workaround before the latest release.
Cause ... not sure either, unfortunately
On Tue, 14 Sep 2010 14:03:14 -0700, Joshua Granick
<[email protected]> wrote:
I'm having a trouble with MouseEvent3D.MOUSE_DOWN events not being
dispatched. I can't quite put a finger on what causes it, though.
In my project, if you click an item, it pushes it into a different
scene for dragging. There are often too many objects to render
everything fast enough, so I use a separate View and Scene to render
only the dragging object. When you stop dragging, it stops rendering,
but its still in that scene. If you click it again it should resume
dragging. If you click off of it it should return it to the original
Scene and View.
This has been working fine, but with this latest release, the
MouseEvent3D.MOUSE_DOWN event doesn't dispatch when the object is in
the dragging scene. As a result, you can click, drag, but once you
release, you cannot start dragging the object again.
As a hack to workaround this issue, I've added a MouseEvent.MOUSE_DOWN
handler for that View, to start dragging the currently selected object
when its clicked. It would be nice if this wasn't necessary, but
there's enough variables in play, here, that it's hard for me to
pinpoint the exact problem.
I can't share code publicly but I can send it privately if you're
interested
Thanks!
On Tue, 14 Sep 2010 13:36:17 -0700, Joshua Granick
<[email protected]> wrote:
Hi Rob,
I don't think this is correct. When you add or subtract, it reduces
the result to a Vector3D instance, and not a Number3D instance. This
seems to be the new parallel:
var difference:Number3D = new Number3D ();
difference = difference.subtract (firstPoint, secondPoint);
vs.
var differenceTemp:Vector3D = firstPoint.subtract (secondPoint);
var difference:Number3D = new Number3D (differenceTemp.x,
differenceTemp.y, differenceTemp.z);
In some ways this new method is more comfortable, but having to
re-instantiate the result as a Number3D is kind of a pain. Do you
think it might be possible to at least add a new method to make this
easier ... maybe something like this?
var difference:Number3D = Number3D.fromVector (firstPoint.subtract
(secondPoint));
On Tue, 14 Sep 2010 06:47:25 -0700, Rob Bateman
<[email protected]> wrote:
Hey guys
today an update has been made to the main fp10 trunk that
incorporates a few
major refactors. The impact of these on code compatibility should be
minimal, but there are a few necessary changes that have had to be
made as
we move forward.
First of all, we have (finally) replaced all MatrixAway3D references
with
fp10's native Matrix3D class. This has allowed us to switch to faster
projection techniques for vertices, which should for the majority of
Away3D
apps be seen as a slight speed increase. There have also been some
other
optimising measures brought in from Lite, such as radix sorting of
faces,
etc
In the interest of improved memory handling, there have also been a
huge
amount of updates carried out to improve memory consumption, and
provide a
more stable memory base. This is not yet perfected, but the majority
of
applications should see improvements here as well
Following on from memory optimisations, both screenvertex and
number3d now
inherit from vector3d. These changes mean a slight alteration will be
required for any apps that use these classes. Primarily, the
differences lie
in the way these objects are added, subtracted etc. Where previously
you
would add two number3d objects by doing:
new number3DResult:Number3D - new Number3D();
number3DResult.add(number3D1, number3D2);
you will now need to do:
new number3DResult:Number3D = number3D1.add(number3D2);
The old player 9 memory problems of generating extra number3d
instances are
no longer an issue in 10.1, and the above way of working is generally
considered a standard when dealing with 3D vectors, hence the
change. The
same thing follows for the native Matrix3D class - where before you
would
transform a number3d with the following:
new number3DResult:Number3D - new Number3D();
number3DResult.transform(oldNumber3D, transformMatrix);
you can now do the same using native objects:
new vector3DResult:Vector3D =
transformMatrix.transformVector(oldVector3D);
aside from these slight syntactic changes, the engine should operate
as
normal. If anyone experiences any bugs, please report them in this
thread!
Enjoy the new release!
Rob
