Re: [Algorithms] Texture mip streaming prioritization

[Jamie F. <ja...@qu...>]

On 23/07/2013 01:21, Josh Green wrote:

<snip>

> Have any of you seen these implementations executed in a product or game
> before? Was it successful? Tricky? worth the time?

We've seen sorting costs for texture prioritization be surprisingly 
high, without doing anything that complex, particularly as you're often 
moving around, priorities change, and you haven't even finished loading 
the mip / texture you wanted to load in the first place (depending on 
hardware, etc.) by the time it's no longer the most important.

Our experience has been that it's not worth over-thinking it. Prioritize 
higher mips close to your points of interest (usually cameras), but 
don't keep too big a queue for low priority things, unless you like 
doing lots of sorting. Once you've started loading something, finish 
loading it; yes, you might bin it soon, but you need some hysteresis in 
the system. Large mips generally are worth seeking and loading on their 
own; small mips may be worth generating from the smallest mip you think 
is worth loading. For our tech, prioritization is configurable via 
plug-ins, so our users can get in and prioritize whatever they think is 
most important, but it's usually just whatever's near the camera (or is 
expected to be near the camera soon). You can do a bit better job if you 
know something about texture density from a pre-process, but it's not 
necessary, particularly if things are built with a reasonably consistent 
texture density.

So I'd build something simple, and see how well it works. Almost never a 
bad way to go about it :)

Jamie

> Thanks for the comments and suggestions so far,
>
> Josh