Cool. Given that it is there to minimize refactoring, is Number3D to be viewed as deprecated and something to move away from for best performance and results?
Cheers, BW On Tue, Sep 14, 2010 at 8:00 AM, Rob Bateman <[email protected]> wrote: > no, Matrix3D and Vector3D essentially replace MatrixAway3D and Number3D for > all functionality, although the Number3D class still exists as an extension > of Vector3D to minimise the code refactoring required. > > > > On Tue, Sep 14, 2010 at 3:18 PM, Michael Iv <[email protected]> wrote: >> >> Hey Rob , greetings for the last update. However I need some explanation >> on Matrix3D. From your example below should I conclude that from now on all >> the matrix calculations are to be made via native Matrix3D API or it is just >> an alternative way and all the AwayMatrix3d stuff is still intact ?The same >> question is directed in relation to Number3D. >> >> Thanks for your great work guys :) >> >> On Tue, Sep 14, 2010 at 3:47 PM, 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 >>> >>> >>> >>> -- >>> Rob Bateman >>> Flash Development & Consultancy >>> >>> [email protected] >>> www.infiniteturtles.co.uk >>> www.away3d.com >> >> >> >> -- >> Michael Ivanov ,Programmer >> Neurotech Solutions Ltd. >> Flex|Air |3D|Unity| >> www.neurotechresearch.com >> http://blog.alladvanced.net >> http://www.meetup.com/GO3D-Games-Opensource-3D/ >> Tel:054-4962254 >> [email protected] >> [email protected] >> > > > > -- > Rob Bateman > Flash Development & Consultancy > > [email protected] > www.infiniteturtles.co.uk > www.away3d.com >
