Re: [Algorithms] BSP tree, or what?

[Pierre T. <pie...@gr...>]

In other words, "optimize the worst case".

- Pierre

> That's just the problem, though, it doesn't get you 4x the framerate.
> It gets you 4x the framerate when you're looking over there at this
> particular clump of trees (from this particular angle), and normal FPS
> when you look anywhere else.  If you build the scene to that 4x
> figure, most of it will run like crap, and if you build the scene to
> the normal figure, you'll be getting (whatever FPS you designed for)
> everywhere and a spike to obscene framerates for a half second of a
> camera rotation in this particular spot - which isn't particularly
> nice.  If the FPS was already what you wanted elsewhere, the spike
> doesn't get you anything appreciable aside from throwing off the
> consistency of your movement and player feedback.
>
> It only gets you 4x framerate if your scene happens to be built up of
> uniformly distributed homogenous occluders, and for the instances
> where dPVS-esque tech is often suggested (free roaming RPGs, sandbox
> environments, some similar inconsistent and hard to manually occlude
> region) you absolutely never have that.  There are absolutely scenes
> where it makes sense (let's say you have a cityscape made up of clumps
> of distinct buildings, but where those buildings uniformly cover a
> city block), but those same scenes tend to be the sort of thing you'd
> optimize out (those distinct buildings should become a single large
> facade per block, lending themselves nicely to a standard large fixed
> occluder).
>
> ... but I admit, I am crusty about this particular tech, and my
> arguments have a distinct "darn kids playing your nintendoo video
> machines!" flavour.  I'm more than willing to be disproven by a
> practical example of their implementation, but I'm unconvinced by the
> dPVS tech demos.
>
> On Wed, Jun 4, 2008 at 9:50 AM, Stefan Sandberg
> <kef...@gm...> wrote:
>> I find that reasoning pretty silly..
>> Wherever you gain performance(or rather, reduce cost), it's a win..
>> Naturally you cap your framerate at something, usually 30-60 fps, that
>> doesn't mean that you wont benefit from a solution that
>> is capable of 4 times that framerate if you let it loose. Just spend
>> that time doing something else..
>> Most graphics artists & designers would massage you daily if you told
>> them you figured out a way for them to
>> have twice the amount of <something> in the game...
>>
>> Megan Fox wrote:
>>> While this is true, do keep in mind that occluder fusion isn't
>>> necessarily going to win you anything you actually want.  Consider the
>>> case where a collection of trees, viewed just so, occludes 80% of the
>>> scene, netting you a significant performance boost.  This is a bad
>>> thing, not a good thing - because players respond better to a
>>> consistently mediocre framerate than they do to a framerate that
>>> spikes massively and inconsistently.
>>>
>>> I'm all for occlusion where it makes sense (big city buildings, big
>>> houses, large walls), but most of the places where occluders make
>>> sense are probably also places where individual objects are big enough
>>> to just be modelled with occluders built in - no need for fusion.  The
>>> usual example of "and we can take this group of people / cars and
>>> occlude everything behind it!" tends to be a plain bad idea, unless
>>> you're in the unlikely situation of having a game in which you're
>>> absolutely always surrounded by a mass of (something indistinct).
>>>
>>>
>>>> All of those mechanisms can be improved, from a rasterization point of
>>>> view, by adding dynamic occluders (ideally with occluder fusion). I 
>>>> know
>>>> that the IHVs say that their cards are efficient enough that you
>>>> shouldn't bother, but that's only true for the "GTX" versions -- the
>>>> 64-bit versions that end up in the laptops that most of the buying
>>>> public are buying, are still very fill rate sensitive.
>>>>
>>>> Sincerely,
>>>>
>>>> jw
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> 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
>>
>
>
>
> -- 
> Megan Fox
> Idyllon, LLC
> http://www.shalinor.com/
> http://www.idyllon.com/
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> 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
>