Sometime along the development of the application I came across the need to convert 3D coordinates into 2D screen coordinates and also the opposite. It's nothing new and it's already implemented in papervision, but since it took me a little while to find it, I decided to share it.

Getting the 2D Screen coordinates from a DisplayObject3D

Since papervision 2.0 that every DisplayObject3D has a property called "screen", that will return the coordinate of the object on screen. Whenever I tried to access the screen property the number3D I got back was always (0,0,0). Probably because it's an expensive operation and it's something you only need sporadically, papervision will not calculate this automatically. You need to ask papervision yourself to calculate this coordinates. To do so, just use the "calculateScreenCoords" of the do3d

myDisplayObject3D.calculateScreenCoords(camera)

Now when you try to access the "screen" property you will get the number3D with the screen coordinates for your DisplayObject3D.

Getting the 3D coordinates from a 2D point (x,y)

For this one I found a great post by zupko that tells you exactly what you need to do.
In a nutshell, you need to take your 2D coordinates (x,y) and convert them into a direction vector. Having the vector and the camera position you can create a ray (line) that will go from the camera into infinity. Next you need to specify the Z, or in another words, where do you want to stop on that line. Zupko uses a 3D plane to do that using the "getIntersectionLineNumbers"

Just remember papervision's 3D Zero (0,0,0) is at the center of the screen and not on the upper left corner like the 2D Zero (0,0)

pv3d_gallery_as3project

Dreaming in Flash interviewed Rob Bateman, The Chief architect and co-founder of the Away3D engine, on his views about the upcoming release of Flash Player 10 and how it will affect Away3D.

Dreaming in Flash: Can you tell us a little bit on your role on Away3d team?

Rob Bateman: I'm Chief architect and co-founder of the framework. Around March last year, myself and Alexander Zadorozhny created a branch of Papervision that fulfilled some specific needs of 3d projects we were both working on at the time (the needs were perspective correction and corrective z-sorting. Lighting also came soon after). To accomplish these extensions we ended up re-writing a lot of the core classes of the papervision engine, however the outward facing structure appears very similar - the reason why a lot of people still refer to Away3d as a "papervision branch".

Since then our development team has increased to 8, with a core group of 4 who commit code regularly. I write a lot of code but also help steer our development schedule in directions we feel will most benefit the engine and the community. For example, we are currently on the verge of releasing a new update that contains a lot more documentation and source code demos - something that has been requested by the community on our site and mailing list.

DIF: Did Adobe approach you for the 3D features, and if so what features did you ask for, and which ones made it?

Rob: Adobe have really been very distant from us and our needs. I think Papervision had more of a dialogue with them over the last few months, and some of the new features in the player clearly are included with 3d in mind, so we're not really complaining! I would have liked to have seen a pixel z-buffer in there along with the perspective bitmap transformations (which whould have completely banished any z-sorting problems of the past) but i guess you can't have everything. What's there is still very useful, and will certainly be put to good use in upcoming releases of Away3d.

DIF: What is for you personally the coolest new feature?

Rob: Pixel bender is by far the coolest feature, not only in the creation of custom filters for 3d shader objects, but also in terms of the hacking potential! We'll certainly be exploring a few avenues of possible uses over the next month or so...

DIF: What's the most relevant feature for Away3D

Rob:drawTriangles is going to help with render speed no end, because the drawing operations of flash were always the bottleneck in the past. The drawTriangles extension to the graphics api allows you to push a single array of drawing commands to the rasteriser, rather than having to call thousands of drawing methods. So your draw loop is reduced to simply manipulating an array of vector data, which is infinitely more preferable.

DIF: What can we expect,in terms of performance and improvements, of the next Away3D version?

Rob: Well, the next version of Away3d (2.1.0) be realeased by the end of this week. This will have fully documented classes, more demos, better management of primitives, better management of events, and a few other useful enhancements. It's a dot release in the truest sense because there are few new features, but a recent poll on our website showed that "new features" is currently at the bottom of what people actually want! Demos, tutorials and docs were all at the top, so that's what we'll be delivering this time round. We'll also be looking for a lot more user involvement over the next month or so in the development of the flash 10 version of Away3d (3.0), which will be developed in a public branch that anyone can hack and provide patches for as the upgrade develops.

Preliminary tests for speed improvements are good, but i wouldn't like to put a figure on what they will be exactly at this point as it's still early days. It's fairly clear that the biggest savings will be in the area of shading though - pixel bender does give phenomenal power to the graphics of the flash player and we expect to be taking full advantage of that new feature.

DIF: Do you have a planned schedule for start working on Away3d 3.0 as soon as FP10 releases?

Rob: Our schedules can be a bit haphazard, as a lot depends on what time we have available each month for work on the engine. As a rule of thumb, we try to release a new version on a monthly / month and a half basis, so after our 2.1 release well be expecting to have something ready for our 2.2 release at the end of June. Away3d 3.0 will be a parallel development that will release incremental update to the current codebase in it's own svn branch. While Away3d has no problems with running in Flash 10, obviuosly there are a great deal of new features in the player to be utilised, so i see this as an ongoing conversion rather than a completely new codebase. The framework of Away3d is built to be very adaptable, so there will be little need to change much of the outside appearance of the engine - obviously we want to keep the amount of new user learning to a minimum.

DIF: How will the new features affect the interactivity in Away3D?

Rob: The interactivity of the new 3d api in Flash 10 is great news for designers but slightly less fantastic for us. Essentially the ability extends to flat planes rotated with the rotationX Y and Z of the displayobject, something that we do not use because Away3d (and all the 3 engines for that matter) are based on drawing triangles. Aside from some special case 3d objects where we can taken advantage of these new features (such as flat 2d sprite objects), well be sticking to the current interactivity method on a 3d mesh unless we discover some as yet undisclosed features about interactivity in that area.

DIF: What do you make of the new Pixel Bender, and what will it bring to Away3d?

Rob: Pixel bender will be most useful for creating shaded triangles with phong, normal maps, environmental shading etc. because it removes the need for multiple triangle layering. Previously the only way to get a shaded effect was to render a shader triangle directly over a texture triangle with a blendmode. With this barrier removed, shaded materials become a lot less processor intensive and a lot more useable, so i would say that this is the biggest contribution pixel bender will make!

DIF: Will Away3D support vector based 3d?

Rob: Away3d already supports line based vectors with it's wire primitive objects and the linesegment class. We are aware there are a few developers out there who would like to see more vector classes in the framework, so we are definitely considering the extension of this side of the engine in future to allow for curves (and possibly surface-based rendering) as well as lines.

We'd like to thank Rob for the time he took for this, and we wish him the utmost success with Away3D, we'll be sure to pitch in with some demos.
Reference links:
http://infiniteturtles.co.uk/
http://away3d.com/

So I finally decided to go have a look at Papervision's destroy methods, and surprise surprise they weren't being called, no harm there, it's alpha these things are meant to happen

So here's what you have to do to force those destroy methods to execute, and clean your memory.

In org.papervision3d.core.proto.MaterialObject3D  set the destroy method from protected to public, do the same to all the materials that you use, like org.papervision3d.materials.MovieMaterial . When you're done with these just the destroy method in your class. For me it looks something like this:

Hope this helps.

We've all been waiting for this moment for a very long time, to have physics
and 3D come together, so without further due here's a little demo I've thrown together in an hour or so.

The code will follow shortly, I just need to tidy it up .

demo

Enjoy.

So here's a little demo on the new Phong shader :) As soon as i have the time tonight i'll put on a much nicer one. This is just to show that altough PV3d just got a new whole set of features it's still easy to use

PhongCube

The most important of these branches is the one called Phunky. It is the branch that will soon became the 2.0 version of Papervision3D, which in the SVN trunk is now tagged Beta 1.7 (dated 20.08.07). So, if you're using trunk, you should expect only bug-fixes. It's a bit different from other open-source projects where trunk normally means the latest revision of the project. For Papervision3D, you can think of trunk as a stable version (whatever that means for a software that's in Beta).

Someone said on the list that "switching from trunk to Phunky shouldn't break anything (doesn't impinge on the API) but should net you a performance increase".

MaterialsRestructor was a branch created to test code regarding Materials. Once changes are tested the most likely is that they go into trunk or Phunky.

I don't know much about the 'ascollada' branch besides the fact that it was created by Tim Knip and that he tries to maintain it in sync with ascollada, a actionscript library for parsing COLLADA files. I've tested loading some COLLADA files with Beta 1.7 and it works fine so I don't have the need to use this branch yet but Ivan is using it (the DEA class), so he might have something to add here.

The 'frustum' (definition) branch has a 'BVH mocap importer class' with a beautiful sample here, but I was unable to find the real purpose of this branch. You can check the examples folder for the sample sources.

'timk_frustum' is a branch that appeared when Tim Knip put up for testing a new FrustumCamera3D, in early August 2007. This class is now also at the 'frustum' branch.

And that's it. If you know more about this and want to share please do. Thanks.

Update: John Grden posted a comment explaining a bit more about the branches, thanks!

First be sure you have either flash cs3 or flex2 installed on your machine, then you'll want to download the Papervision3d engine.

Now we can get started
Look in the code for instructions

Download Actionscript source file

And that's it, if you have any questions please post them!! We'd love to hear from you.
Lo.

Code to come soon.