Re: [Algorithms] why not geometry?

[Jeff R. <je...@gm...>]

Have a link, by any chance? Were they just discussing instancing of a
single large mesh (1 full tree), or duplicating several small
branches?

Jeff

On Wed, May 28, 2008 at 3:02 PM, Paul at Home <pa...@ru...> wrote:
> At a recent XFest in Reading (UK), MS presented exactly this tree scenario
> as a way to use DX10 instancing to draw trees exactly like that. There were
> actually stacks of them on screen too, allegedly from just 4 draw calls.
>
> My problem with this is that it's a pipe dream imo. Until some distant time
> in the future when everyone has an SM4.0 card and the *next* set of consoles
> is out, you can't put this stuff in commercial games, as it's like
> developing two different titles at the same time. There are simply no
> convenient fallbacks for this stuff which means you need two codepaths and
> two sets of art.
>
> The final nail for me is that (apart from a very narrow space where it's the
> best target,) PC games are rarely the lead version. A big budget title is
> going to be for 360 and/or PS3 with sometimes a PC version thrown in and
> powerful though they are, neither console can approximate this technique
> well. So what's the point?
>
> Bloody impressive demos though. Hope I'm not starting a flamewar here.
> Regards,
> Paul Johnson
> www.rubicondev.com
>
>
>
> ----- Original Message -----
> From: Jeff Russell
> To: Game Development Algorithms
> Sent: Wednesday, May 28, 2008 7:30 PM
> Subject: [Algorithms] why not geometry?
> So, say hypothetically that a person wanted to render a tree trunk. The
> typical approach is to use solid triangles for the trunk and a few major
> branches and use alpha-tested or blended geometry for the smaller branches
> and twigs, the goal being of course to reduce the triangle count to get good
> performance. One then ends up rendering for example something like 1-2k
> triangles instead of the 50k or more that might be required to render the
> 'full' tree. Seems logical.
>
> But my question is - is this still wise? And if so, why?
>
> Consider:
>
> - A typical vertex shader often compiles into about as many instructions as
> a fragment shader nowadays (for us in the 50-100 range). I would expect then
> that from a pure computation standpoint computing a single vertex would be
> roughly as fast as a single pixel on a modern GPU, since vertices and
> fragments now share ALU in most cases.
>
> - Geometry in this case saves fill rate. Even if the tradeoff for vertices
> to fragments isnt 1:1, drawing your tree branches with geometry will avoid
> the massive overdraw that large alpha-tested triangles can incur. Even
> proper sorting won't save all those fragments that get discarded by the
> alpha test.
>
> - Geometry looks better! You get antialiasing, proper depth buffer
> interaction, parallax, etc. all of which are trickier to attain in full for
> impostor geometry.
>
> - The advent of the 'geometry shader' makes replicating parts of your data
> stream more feasible. I could see a situation of local geometry instancing
> where a large branch has the same 'twig' present in several different
> positions/orientations/scales along its length. This means you allow maybe
> 100 tris in your vertex buffer for a given twig, and the geometry shader
> replicates it at draw time using a constant table to maybe 16 instances or
> so to fill out your tree. Then you'd get a very large number of triangles
> generated by a single draw call that only passes in a fraction of the data.
>
> I suppose maybe the memory problems alone could be what hurt vertex
> processing so much, given there's so much data flying around. Plus I've
> heard that geometry shaders aren't even very fast yet.
> Any thoughts? Has anyone gone down this road - using lots of triangles in
> place of flat textures?
>
> Jeff Russell
>
> ________________________________
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
> ________________________________
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>