I had a little too much time on my hands yesterday and I started thinking about texture handling in OpenSG.
How does OpenGL and thus OpenSG determine which textures to unload from memory and how does that interact with the "sorted" order in which OpenSG 2.0 renders textures? For example, imagine that I am on a machine with 256MB of texture memory and I have a scene with 9 32MB textures (288MB). When OpenSG renders them (assuming only 9 geometries each with a separate texture), it would come out something like this: - render geom 1: tex 1 - render geom 2: tex 2 - render geom 3: tex 3 - render geom 4: tex 4 - render geom 5: tex 5 - render geom 6: tex 6 - render geom 7: tex 7 - render geom 8: tex 8 - render geom 9: tex 9 Now assuming that the sort is non-stochastic, it will rendering in the same order the next frame. But that last render (geom 9) may have pushed texture 1 out of texture memory (if OpenGL uses a FIFO or LRU replacement stategy). But the really bad part is that means when it loads tex 1 it will push out tex 2 and when it renders tex2 it will push out tex3 and so on. So in a worst case, as soon as we exceed the texture limits by a single texture, every texture has to be uploaded every frame instead of a single texture per frame. So my question is, is this how OpenSG/OpenGL are currently working or is there some way that we are avoiding this performance trap? -Allen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
