Re: [Algorithms] why not geometry?
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] why not geometry?
|
From: Paul at H. <pa...@ru...> - 2008-05-28 21:40:17
|
No links, didn't even remember to pick up the conf materials at the time. :( They built the whole thing from geom. One instance of a trunk did all the branches, another instance of this lost made all the trees, etc. Regards, Paul Johnson www.rubicondev.com ----- Original Message ----- From: "Jeff Russell" <je...@gm...> To: "Game Development Algorithms" <gda...@li...> Sent: Wednesday, May 28, 2008 10:13 PM Subject: Re: [Algorithms] why not geometry? > 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 >> > > ------------------------------------------------------------------------- > 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 > > |
