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

Sat Feb 17 14:57:47 EST 2007

As an addition to this; the ones who would be interresting in knowing
how the displacement for the bumpmapping is done and precalculated;
have a look at Joa Ebert's ImageProcessing library
(http://blog.je2050.de/imageprocessing-library/) which has an
excellent implementation of a QuickNormalMap and a QuickBumpMap, which
Joa has implemented .based on an earlier demo I did on 3D bumpmapping
: http://www.unitzeroone.com/blog/flash_examples/flash_8_example_3d_bumpmapping_using_filters_source_included.html

This concises of partly precalculating the bumpmap to normals using
the convolution filter, and then processing that in the displacement
map filter, displacing the lightlayer, which is the multiplied with
the texture layer.

Ralph.

On 2/17/07, Ralph Hauwert <r.hauwert at gmail.com> wrote:
> 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
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>

-- 
Ralph Hauwert
FlashCoder