Re: [Algorithms] Texture mip streaming prioritization
Brought to you by:
vexxed72
From: Sebastian S. <seb...@gm...> - 2013-07-23 02:35:06
|
On Mon, Jul 22, 2013 at 7:24 PM, Sebastian Sylvan < seb...@gm...> wrote: > > > On Mon, Jul 22, 2013 at 5:21 PM, Josh Green <in...@gm...> wrote: > >> >> Unfortunately the above algorithm looks like it'd be very serial, and >> involve a bunch of sorts... But I think it might acheive good results? >> > > Seems reasonable. You should of course try to keep your texture requests > in a priority queue instead of re-sorting in each iteration, and use > "adjust key"/"decrease key" whenever you decide to drop a MIP level for a > key. There are heap implementation where this operation is O(1) (e.g. > Fibonacci heap), so it's at least possible to be efficient (in practice, > depending on the number of textures, a straight binary heap a la STL may be > faster due to being less complicated). > > Also, it's worth considering your expectation here. If you intend to keep enough memory for textures that you'll "almost never" have to turn down a MIP-loading request, you don't really have to over-think this too much. Simply loading the lowest-resolution MIP always (taking object visibility into account) will do a decent job - it's sort of like having a global resolution clamp and just lowering it until stuff fits in memory, which won't be optimal, but tends to behave consistently and predictably. > -- > Sebastian Sylvan > |