Dirk Reiners wrote: > Hi Allen, > > Allen Bierbaum wrote: >> We have an application where we dynamically add geometry and textures at >> runtime. We load the data into memory in a background thread and that seems >> to be working correctly. But when the new data gets added to the scene >> graph, we seem to be suffering a very significant drop in performance (pause >> for .5 - 1.0 seconds).
I performed some more detailed timings and found that it was closer to .25 seconds for around 6-8 textures. I believe the textures are all RGBA 512x512 with no texture compression. There is also a small but noticable delay for creating the display lists for the geometry that have the textures applied. > That sounds very long. How big are your textures? Do you only upload one > at a time or a larger number of them? >> I am still trying to track down the details inside >> OpenSG, but I suspect it is the time spent on texture upload and texture >> object creation before the texture is used. >> >> I am assuming that OpenSG does something like this: >> >> - Once a new material is added to geometry and that new material has a new >> texture >> - The next time the geometry is rendered, the material is activated >> - This causes opensg to: >> - Create a texture object >> - Upload the image into the texture object >> - Activate that object to render the geometry >> > Texture objects are only created if needed, but generally yes. >> This is a very simplistic explaination and I have not looked at the code in >> detail but this seems to be the behavior and would follow the OpenGL >> conventions. >> >> 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. > 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). Thanks, Allen > > Hope it helps > > Dirk > > > ------------------------------------------------------------------------- > 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
