trace(myBitmapdata);

Ok the day started bad, the algorithm i've spend 2 evenings working on is simply to heavy for flash. But i was walking for a few days with a litle idea behind my head.
For the bitmapdata only renderers, i've wrote a very fast (who am i to say so, just see by yourself!) lightning code, very simple code, but very efficient. So i decide to apply it to the bitmapMaterial, the same classes as in Papervision.
After the defeat of the shading, i could balance with a very fast flat shading.
If there is sufficient triangles, you even could get a smooth fx illusion.
According to my tests on my G4 and G5 witch are not speed monsters anymore, i could set up good FPS on every models i was loading, in some cases i couldn't say the lightning was slowing the process of rendering down.

My job will be now to add to all materials this flat light option, a lock light option witch will also assure that normals will be calculated only once, so the light will not be calculated on each iteration. Handy if you want to light that chair with no function behind that table in the back of your scenery... the model will have lighting, but after 1 refresh, the light will be just dead!

Working on new materials, i wanted first to make some research on the algorithm i will need to write before even start playing with it in a 3D environement. To allow smoothing basically you need 3 colors values. You calculate the average normal of each faces and neightbours faces sharing the same vertices, you add then divide by the amount of shared vertices... In this case i use a fourth color: the pixel color of the source bitmapdata.

Here you can see the shading apply to an entire bitmapdata.

Looked nice, so i've push up a bit and wrote a little app to simulate more faces, just to find the bugs and see what's happening...

What's happening if you try to apply a gourauld calculation to a bitmapdata is an easy answer: You get a running snail! So this experiment is now officially terminated! Even without fixing the y interpolation on color and the over range issue...

i have one thing to say: back to the drawingboard!

In this example, i've doubled the light brightness influence and gave an offset of 255. Als a result rgb multipliers are going now from -255 to 255. Giving some contrast to the images i was missing in the first non destructive version.

Just look at the difference
with last posted example. We can now create interresting lightnings within a scene.
Next stop the smooth shading. I'am affraid it will run like a snail. But hey, first write the class and take it from there!

Since i want to add some smoothing to the faces to the material, i need lightning.
This is the second attempt, the first one was working well but was too expensive.
This time it renders about 45% faster than the first version, and i got also an ambient light for the same price.

In this example, the light position is inversed but i'll fixe that later.Its just a work file.. What i do miss in this picture is a bit more contrast. For instance if you want create a dark atmosphere in a room. I want that a 0-1 value of "dark" can be set and would only influence the less exposed faces of the mesh and actually darkens the image material in the shadowed areas. Now in this case the black value is non destructive, the darkest value is the image itself. That because the black is defined with rgb values of 0 red, 0 green and same for blue, if you multiple or add a color with nothing... nothing much happens...

Enough boring techstuff, let there be flat light!
The next stop, dark shading, highlights and smoothing of the surfaces... o boy, it's gonna cook my old G4 cpu's!

If you love cubes that are rotating quietly to display your video's, if you are about to build a 3D slideshow made of planes to display your images, and you want to keep it that way, you should not even read further more...

Some energy is about to be released: Thanks to Rob Bateman.
(i call him secretly 'Betaman', since he made me waiting sooo long to reveal this )

Rob's been working on a physics engine for the away3d source for weeks. He's about a few days from release now, he's busy fine tuning and testing, but just to give you a few hints on next release:
the physics part of Away3D will now include those features:

axisaligned solid body physics,
Constraint-based particle dynamics,
friction, drag, bounce and magnetic coefficients for objects (and materials)
Raycast collision detection for particles,
Container collision 'sweep & prune' detection,

in the process of adding:

Angular solid body physics,
custom surface collision detection for primitives,
Raycast collision detection for surfaces,

The engine uses a Verlet Integrator at the moment, but because of the advantages offered by Alexander's Traverser methodologies to the Away3d engine, this could easily be swapped out for a Euler Integrator or whatever you fancy, on an object by object basis if necessary.

Huuuuuuuu??

Hey! I heard you say that! Ok, let's translate this in Flashers talk, this means you can soon ask the engine to do tons of stuff for you that handles the way models are interracting with each other.
That the car of the game you are writing will have springs, that i will weight 2 tons and travel at a certain speed, and that if you are a stoopid 10 grams cube with videos on it, you beter move out fast before being kicked to the moon!

Rob has have taken a great care to try and integrate the physics model with the away3d code in such a way that (he hopes!) is neither detrimental to those who don't want to use it, nor overly complex to apply for those that do.

Right now there are some demo's on the make they will probably be released before the code will be committed to the Away3d svn trunk for anyone to have a poke at.

As soon as Rob as something ready i will show it here... if he's not pissed at me for the "betaman" thing

It's been a busy week, the whole team is working very hard to deliver high quality features for the engine's next release (Very nice things are coming up i can tell you! Its burning my leaps, but.. i will not say a word here!).
Anyway, first i had to find my way beetween all those containers. It used to be: myMatrix, myBitmapData and I... not anymore.
To start, i couldn't load anything quickly within the engine from the supported format like the .ase or .collada parsers from my 3D apps, so i first wrote a .obj parser in order to start testing and learning the engine structure a bit more. Here you go, before i knew it, was my first class for Away3D a reality!

Hmmm, where do you start to implement a rasterbased renderer in such an engine? Its simply a pain.. nothing is build for it, movieclip all over the place, so after hours of traces and tests, i finally had a visible result! No errors anymore, no missing params, no wrong typing and there it was: Ladies and gentlemen the first pixel based renderer for Away3D was born!

Look at this screendump underneath, isn't it nice? Hours of hard work rewarded by this wonderfull orange collection of pixels! I've mailed the team this result. They surely thought i was crazy!

Sure, if you look at the result on screen, but i saw it this way: i had finally found a place to insert the code, that it was actually receiving data from the main renderer... Within the next few hours when all matrixes were corrected with the right offsets, i finally had it, the first line tracer based on a Bresenham algorithm was working, then the point version (it would have been stupid to not do this one)
and finally la piece de resistance: the bitmaprenderer, witch transforms image information on the faces.

You can see the first beta version of the bmdrenderers here, i've booked today a 10 fps plus increase on the bitmap
but i still have some artifacts to fix. I know i can gain here and there a few fps more on the code, but fact are there, the new Flash player beta 9.0.60 will help on general performance, but not on pixels level, so i'm pretty close to the max i can get right now.

But the nice thing is, and that certainly not the case with the beginmapfill, is that if i add light influence to it, there are no or very small influence on performance.
. Of course there are lots of issues to be solved before this code will be released, so check the away3D svn from time to time.

A balance beetween design and polygon count will have to be found. This new materials will just help you guys building some new breed of fx for flash 3D that would not be possible with the relatively "traditional" movieclip approach. I will soon post some examples that are using this new tools, and not just spheres like this little demo shows.