Re: [Algorithms] BSP tree, or what?

[Megan F. <sha...@gm...>]

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/