Gerrit Voss wrote: > Hi, > > On Sun, 2008-10-26 at 23:13 -0500, Allen Bierbaum wrote: >> Dirk Reiners wrote: >>> Hi Allen, >>> > >>>> In any case, I suspect that the delay between uploading the image and using >>>> it is there the system performance is suffering. >>>> >>>> Now this may be more of an OpenGL question then anything, but is it >>>> possible >>>> to put a few frames delay between uploading the texture into the texture >>>> object, and the first time the texture is used? Said another way, is there >>>> a way for the system to upload the texture into the graphics hardware in >>>> the >>>> background before the data is actually needed for rendering? >>>> >>> Rumor has it that the drivers can do that, but I haven't spent a lot of >>> time confirming it. You could do it by validating the TextureChunk >>> before putting it into a Material. You'd need access to the GLId, which >>> is internal right now. It might make sense to add an externally callable >>> validate() call to the TC to allow that. >> I have a temporary work around where I just load one geom and texture >> per frame. That makes things better, but still not as good as I would like. >> >> I thought about doing something like you mention above (actually thought >> about modifying the texture chunk to support it) but then I ran into an >> issue. Basically we wouldn't want to use the texture until it was in >> memory, but this also means we wouldn't want to use the geometry either. >> But once the geometry core is create and the material is set, OpenSG >> is going to render the geometry the next frame no matter if the texture >> is ready or not. So what I would need is a way to delay the geometry >> rendering until the material (ie. the texture) says it is ready. >> >> I must admit, I don't have a clue how to do this in OpenSG. > > Hmm, not having look into it, how would you reliable query OpenGL for > the texture state. I'm not sure if the resident queries are good enough.
I had thought of two ideas. 1) Try to see if the resident tests work well enough or look for another OpenGL extension that may provide similar functionality. 2) Adjustable heuristic based on time. For example when setting the texture set a parameter like "delayBindTime" or something to the number of milliseconds you think it may take to upload the texture. This parameter could be tweeked by the application or have reasonable defaults based upon texture size or something similar. Neither of these would be perfect, but it would be a start. -Allen > >>> But in general .5-1 sec sounds very long for uploading a texture. Are >>> you using compressed texture formats like a DXT by chance? Unless you >>> store compressed data in the image, that data will have to be compressed >>> on upload, and that can take quite a bit of time. >> Agreed. I actually tried that once before and ran into issues, but the >> texture compression is turned off now. Although I would like to get it >> back if there was any way to have OpenSG do the compression in memory >> (and better yet allow saving the compressed version out to .osb). > > I have a version of squish in my tree, I can try to move it over to svn > and add the basic stuff to the image class. > > > kind regards, > gerrit > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
