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
