[Papervision3D] About rendering. Was : Status of AS 2.0 Papervision

Sat Feb 17 14:51:10 EST 2007

Hi Jake,

Thank you. This is indeed a good idea, transforming the vertex and
face normals through the bitmapdata API. I'm not sure if we can
actually get a good result in a 255 step value though. Currently we
precalculate the vertex and face normals at object instanciation time,
and transforming the face normals on a per frame basis, and vertex
normals on a per frame basis, when there is a material mapped on it
when it's needed. At least it will not be possible to store x and y's
in that 255 value, since we would have to normalize everything down to
that.

What the problem with loss of precision is is that with the materials
we have, we need accurate values for the vertex normals to make them
usable. We are doing fake phong shading on all materials which do
vertex normals (still working on gouraud though, so that wouldn't).
The loss of precision would mean that the edge values would be
innaccurate and would probably not look that good. Also, I'm not sure
what code we would need to get them out again. It would involve 1 slow
getPixel(calculatedPositionX, calculatedPositionY), 3 bitshifts to get
them out, then one normalisation, and then a couple of mults to get
the uv coordinates. As I see it, if we need to do that on a per vertex
basis, we are not that far off from just doing the transform in AS,
where we wouldn't have that loss. But honestly, this is a new idea to
me, so I haven't tested it, and wouldn't know.

In terms of blending, I think it's important to know a couple of base
issues there are. First off all, clearly, per pixel calculations are
out of the question. Next up, there's the issue of having to clear and
access a bitmap for every face. Currently there's no real bitmapdata
calculations in the face renderloop. On a base of that we do about
400-900 visible faces per loop, we have been testing alot. What we
came to is that using the drawing api with a partially precalculated
matrix transform for the skewing and translation/scale this is
basically fastest. What I have tried to do, was having a blend per
face in bitmapdata, so we would end up with drawing 1 tri to the
screen per face. I haven't been able to find 1 way this is fast
enough. Everytime we need to draw to a bitmapdata object, and mask out
a tri while doing it, it ended up slower then just drawing in every
instance. Currently we are doing .graphics layers to seperate the
texture, lighting and displacement. The displacing is done on a per
render() basis, not on a per tri basis. As I have tested, it is
impossible to do this with a reasonable amount of speed.

Currently I am dealing with how to treat these layers correctly, since
we have them per scene, which means objects have no seperation. Since
the current culling relies on a backface culling and simplified
painters algo, we have a problem there when one material overwrites
the other only per layer, and another layer might stay active. I would
opt for having drawing containers for every object/material. Per
triangle sprites seems slower at least, so I am not sure if that is
the way. I think it has to do with how the sprites are composited in
the render engine. And since tri's are exactly what we have most
of...not sure about this yet.

Face normals might prove more then good for the as2 version, they will
help in clipping/culling tri's before there vertices are transformed.
The increase we will get out of this helps especially good on
convex/spherical objects, but become useless as soon as the material
is twosided.

Bumpmapping is half precalculted by pre-processing the bumpmap. The
mapping of this to stage works exactly the same as texture mapping,
the displacement comes afterwards.

The one thing we seem to keep having to avoid is drawing anything, or
using bitmapdata's (which might be needed on a per frame basis, due to
the sizing). In AS3, the bottleneck clearly resides in the render
engine; we need to avoid using it as much as possible. Doing a  Z
Buffer isn't really possible with out it. I have been thinking about
using displacement + drawing api gradients to store some info about
3d, as was ricardo cabello. ARGB would give one more bit precision,
but drawing gradients is not very fast either...ARGB itself having a
considering slowdown over RGB.

Currently all blending is at least done through blendmodes, and the
overhead on that on a 3 layered scene is not that high. It's at least
better then having to use alpha's for having the fall off of light,
since alpha's seem more expensive..What would you propose to use
instead of blendmodes ?

I hope this is at least a half way coherent mail. It's been a tough
nut to crack, and I am still figuring out alot. I have been doing
fulltime flash for 7 years now, and still alot of things keep on
surprising me, leaving me filled with a million ideas which might, or
magically might not work.

Ralph.

On 2/17/07, jakelewis <jakelewis at blueyonder.co.uk> wrote:
> Hi Ralph,
>
> Well done on the bumpmapping - an impressively smooth sphere. I'm assuming
> the displacement values are calculated per triangle, but yet there are no
> visible artifacts at the triangle boundaries on what is clearly a very low
> poly sphere - impressive.
>
> Mark Winterhalder made an interesting suggestion a while back:
>  " potential possibility to (ab)use the ColorMatrixFilter for mass
> transforming RGB
> encoded vectors anyway. "
>
> Perhaps this idea would help speed up the vertex normal projections - the
> x,y,z of the normalized normal could be (one time) encoded (with quite some
> loss of accuracy!) into the RGB of a pixel - making up a 1 pixel high bitmap
> of all the normals of the model. This could then be transformed to view in
> one line of ActionScript ( and would thus still be usable in AS2). The
> resultant R and G values would be perfect for us as X and Y coords of a 256
> pixel square lightmap. Face normals could be done the same way. I'm pretty
> sure a dot product could be worked into the input matrix too, so that would
> be essentially free.
>
>
> So how are you proposing to combine the reflection/light/bumpmap with the
> underlying texturemap? Can this be  done in one pass? Flash Players blending
> algorithms cant use MMX so its going to be quite a bit slower.
>
> Regards, Jake Lewis
>
>
>
>
>
>
>
> -----Original Message-----
> From: Papervision3D-bounces at osflash.org
> [mailto:Papervision3D-bounces at osflash.org]On Behalf Of Ralph Hauwert
> Sent: Saturday, February 17, 2007 6:30 AM
> To: Papervision3D at osflash.org
> Subject: Re: [Papervision3D] Status of AS 2.0 Papervision
>
>
> Alot of the RC2 things of PV3D might or might not be wortwhile to copy
> to AS2. I think vertex normals (and thus advanved
> shading)....no....Face normals (for clipping purposes)....yes....then
> the rest of the new things should be ok too.
>
> Ralph.
>
> On 2/17/07, Carlos Ulloa <c4rl054321 at gmail.com> wrote:
> > Our original ideas was to port the current RC1 version to AS2, but since
> > what Ralph is doing will boost performance, I think it's better to port
> RC2,
> > probably losing the fancy effects but getting the better performance.
> >
> > All current features of RC1 should be retained in AS2, including the new
> > API, object hierarchy and scene parsing, but in the future I think we will
> > reach a point in which new features would be AS3 only.
> >
> > C4RL05
> > // noventaynueve.com
> > // papervision3d.org
> >
> >
> >
> > On 17/02/07, John Grden <neoriley at gmail.com> wrote:
> > > I'll let Carlos fill in more details, but from what I remember Carlos
> > saying, the as2 version will be brought up to the same API (as much as
> > possible).  Once it's at that point, I don't know about the other features
> > that are being added and how far he'll continue to support the as2
> version.
> > >
> > >
> > >
> > > On 2/16/07, Austin Kottke < austink at scientology.net> wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > What is the status of the AS2.0 version of papervision. Is there still
> > updates being
> > > > made to it so that it falls in suite with the as3 version - in terms
> of
> > group support
> > > > and new features or is  the as3 version the main one being
> concentrated
> > on?
> > > >
> > > > Best, Austin
> > > >
> > > > _______________________________________________
> > > > Papervision3D mailing list
> > > > Papervision3D at osflash.org
> > > >
> > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > [  JPG  ]
> > > _______________________________________________
> > > Papervision3D mailing list
> > > Papervision3D at osflash.org
> > >
> > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> > >
> > >
> >
> >
> > _______________________________________________
> > Papervision3D mailing list
> > Papervision3D at osflash.org
> > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> >
> >
>
>
> --
> Ralph Hauwert
> FlashCoder
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>
>
>

--
Ralph Hauwert
FlashCoder

-- 
Ralph Hauwert
FlashCoder