Hey Justin We already have an errata doc that we need to update - currently its located here:
http://flash3dbook.com/ we'll also be shortly uploading a complete set of refactored class files contained within the book, so that any minor changes can be followed. If you do spot an error that is not included in the errata, the please do let us know! cheers Rob On Wed, Oct 6, 2010 at 9:32 PM, [email protected] <[email protected]>wrote: > Thanks Rob > > Very useful info, noticed the draw primitive change as it effected my > hacking, but since still lots to learn not noticed much else! I know it's a > lot to ask but have you considered if this will have any impact on your book > is there a place where users can add any notes on changes if we find them > while reading, like a wiki page or is there one already? > > Cheers > > ;j > > On 6 Oct 2010, at 21:02, Rob Bateman wrote: > > Hey guys > > so, hopefully this mail will aid comprehension and reduce unnecessary > suffering, always a good thing ;) > > As some of you already know, Away3D 3.6.0 was launched some time last week > with a few unavoidable refactors that will regrettably have an effect on any > projects currently in production. In fact, at present my advice would be to > not upgrade to 3.6.0 for any projects currently in production. If you are > desperate for some of the optimisations but still don't want the hassle of > refactoring (man, you're so lazy!), then we have a nice surprise for you - > many of the upgrades are available in a recently tagged 3.5.2 version that > you can find in the googlecode svn here: > > http://away3d.googlecode.com/svn/tags/3.5.2%20lib/ > > this obviously won't be as fast as the latest version, but should at least > give you some speed and memory enhancements. > > As for the peeps still using Flash 9, this has also recently been upgraded > in a similar style to 2.5.2 - again something you can find tagged here: > > http://away3d.googlecode.com/svn/tags/2.5.2%20lib/ > > > On to the main event, the 3.6.0 release. This has had a few fairly > fundamental changes to its structure, a breakdown of which follows. > > to start with: > > Number3D is replaced by the native Vector3D class. > MatrixAway3D is replaced by the native Matrix3D class. > > while these two changes look fairly innocuous, they have far-reaching > implications to existing project code - basically any 3d number in the > library is now represented by a Vector3D instance, and any 3d transform > matrix is now reprsented by a Matrix3D instance. Another big difference is > the way these classes operate on each other. Previously, Away3D used methods > on Number3D and MatrixAway3D that avoided the creation of new class > instances, to save memory. With the use of native classes this issue is no > longer a problem, but it does mean that something like: > > myDifferenceVector.sub(myObject1.position, myObject2.position); > > now looks like: > > myDifferenceVector = myObject1.position.subtract(myObject2.position); > > Another API change involves the location of session classes - previously > these were lumped together with render classes and called > SpriteRenderSession, BitmapRenderSession. Now these have been moved to their > own package inside away3d.core.session and have been renamed SpriteSession, > BitmapSession. Could we possibly be planning more session types? > > There have already been a few confused posts on the list about sprites - > apologies for having to wait so long for an explaination on this. Basically, > sprites are now defined as an extension of an Element class (the same as > Face and Segment), and have a root class called Sprite3D. This accepts a > material rather than a bitmap, and an instance of Sprite3D is added to the > scene using an addSprite() method. users of the deprecated Sprite2D class an > easily simulate all the previous properties by wrapping a Sprite3D instance > inside an ObjectContainer3D instance. This may seem like more hassle than > its worth, but the main reason for the change has once again been about > speed and unification. > > Similarly to sprites, all light classes now inherit from their own > AbstractLight class rather than Object3D, and as a result are much more self > explanatory to use. They are now added to a scene using the method > addLight(). > > Finally, for those of you poking a bit deeper into the core of the library, > you'll notice that all draw primitives have been removed - this is something > we've wanted to do for a while now but its been quite a task! essentially > any draw information is now stored inside number vectors in the renderer. > Triangle caching all still works as normal, but without hundreds of objects > being passed around every frame, memory and framerates should benefit. > > > I'm sure there are other small alterations i've missed in this initial > post, so please let me know if there is something else you've noticed that > is different to the previous release! > > atb > > Rob > > -- > Rob Bateman > Flash Development & Consultancy > > [email protected] > www.infiniteturtles.co.uk > www.away3d.com > > > -- Rob Bateman Flash Development & Consultancy [email protected] www.infiniteturtles.co.uk www.away3d.com
