RE: [Algorithms] (New?) method for skinned shadows
Brought to you by:
vexxed72
Menu
▾
▴
RE: [Algorithms] (New?) method for skinned shadows
|
From: Andreas B. <And...@di...> - 2004-02-13 15:23:32
|
Yes, I agree it's quite expensive. For us there are two good reasons for
doing it anyway:
1. We're already heavily CPU-bound.
2. If you do the skinning of the shadows on the CPU you're not guaranteed
that they'll match up perfectly with the skinning of model on the GPU due to
very small inconsistencies in the handling of floating point values (I've
had trouble with this in the past). You could of course skin the model on
the CPU as well if you can afford it though.
There is one more optimization you can do to speed it up a little (lot?),
identify which triangles in the mesh are rigidly skinned (all three vertices
have the same weights and indices) and draw them in a separate pass with a
simpler shader.
/Andreas Brinck - DICE
-----Original Message-----
From: Tom Forsyth [mailto:tom...@ee...]
Sent: den 13 februari 2004 15:42
To: gda...@li...
Subject: RE: [Algorithms] (New?) method for skinned shadows
Cute. If you're lucky, the pre-T&L cache on the card will know that although
they're separate vertices they are still the same chunk of memory, so your
AGP bandwidth doesn't rise as well. I'm pretty sure the nVidia pre-T&L cache
works like this (it's a dumb memory cache - doesn't know about verts and
indices). Don't know about any other bits of hardware though.
Your vertex throughput is still going to be awful though. From your original
model of n vertices, you have about 2n triangles (on average). So by
creating degenerates you now have 6n vertices. So now the memory required is
10n, but the number of vertices that need to be skinned by the VS is still
18n.
I know stencil volumes are traditionally thought to be fill-rate bound, and
they often are in the evil cases. But this is going to raise the bar of how
fast even moderately-sized shadows can go. At 1/18th the speed, doing it all
on the CPU with a bit more smarts seems like a no-brainer.
Or just tessellate the problem areas more until the artefacts go away. Which
is the solution I like best :-)
TomF.
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...] On
> Behalf Of Andreas Brinck
> Sent: 13 February 2004 14:10
> To: 'gda...@li...'
> Subject: [Algorithms] (New?) method for skinned shadows
>
>
> I've come up with a (new?) way to render shadows for skinned
> models with
> correct selfshadowing entirely on the GPU that I thought I'd share.
>
> It's pretty easy to render correct shadows for rigid models.
> All you have to
> do is:
>
> - Make sure the model is two manifold
> - Store the triangle normal in each vertex
> - Stitch all adjacent edges with an extra quad.
> - In your vertex program extract the vertices facing away
> from the light to
> infinity
>
> If we try to do the same thing for skinned models we run into
> trouble; we
> can't store the triangle normal in the vertex since it depends on the
> deformation of the other two vertices in the triangle.
>
> You could of course store the normal from the bindpose and
> deform it the
> same way as the normal you use for lighting. This would
> probably be good
> enough to cast shadows on other objects but would introduce
> notable errors
> in the self shadowing.
>
> How do we solve this then? The obvious solution is that in
> each vertex we
> also store the two other vertices (with blend weights and
> blend indices)
> from the triangle it belongs to. In our vertex program we can
> the deform all
> three vertices and use their positions to calculate the true
> triangle normal
> which we can then use to determine if the vertex should be extruded.
>
> Unfortunately this means we'll triple the memory used by the
> shadow casting
> mesh's vertices.
>
> Now here's the trick: instead of saving three vertices in
> each vertex, we
> create a vertex buffer with the following pattern (v0 means
> vertex 0 from
> an original nonindexed version of the model)
>
> [v0 v1 v2 v0 v1 v3 v4 v5 v3 v4 v6 v7 v8 v6 v7 ... ]
>
> And our index buffer is filled like this
>
> [0 1 2 5 6 7 10 11 12 ... ]
>
> The vertex format we use in the vertex buffer looks something
> like this:
>
> struct Vertex
> {
> float position[3];
> float weights[3];
> int indices[3];
> };
>
> However in the vertex declaration for the vertex program we
> specify that the
> vertex format looks like this:
>
> float position0[3];
> float weights0[3];
> int indices0[3];
>
> float position1[3];
> float weights1[3];
> int indices1[3];
>
> float position2[3];
> float weights2[3];
> int indices2[3];
>
> This means that we can access all three vertices in a
> triangle at once. For
> the first four indices in the index buffer we get:
>
> Vertex buffer: [v0 v1 v2 v0 v1 v3 v4 v5 v3 v4 v6 v7 v8
> v6 v7 ... ]
> Accessed by index 0: [v0 v1 v2]
> Accessed by index 1: [v1 v2 v0]
> Accessed by index 2: [v2 v0 v1]
> Accessed by index 3: [v3 v4 v5]
>
> Instead of 200% more memory we now only use 67% more memory.
>
> Now I don't now about OpenGL but the DirectX documentation
> says that you
> shouldn't specify a stride less than that computed from the vertex
> declaration. This doesn't mean that you _can't_, just that
> they haven't
> figured out a use for it. When I tried it it worked perfectly!
>
> This method could be used for other problems as well where
> you need the
> entire triangle in the vertex program.
>
> I apologize if this is an old well known method but I haven't seen it
> anywhere else. Hopefully it's new to some of you at least ;)
>
> Regards
>
> /Andreas Brinck - DICE
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88
|