Re: [away3d] Away3D update to 3.5.3

[Joshua Granick]

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  
<bulkm...@joshuagranick.com> 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  
<bulkm...@joshuagranick.com> 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 <rob.bate...@gmail.com>  
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