[Papervision3D] About rendering. Was : Status of AS 2.0 Papervision
Carlos Ulloa
c4rl054321 at gmail.com
Sun Feb 18 13:37:04 EST 2007
> 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.
Isn't this guy amazing?
C4RL05
// noventaynueve.com
// papervision3d.org
On 17/02/07, Ralph Hauwert <r.hauwert at gmail.com> wrote:
>
> 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
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/papervision3d_osflash.org/attachments/20070218/ed30cded/attachment-0001.htm
More information about the Papervision3D
mailing list