![]() |
|
#1
|
|||
|
|||
How were you able to accomplish the asynchronous texture upload in your previous program? From my understanding, an OpenGL context can only be active to one thread at a time.
|
#2
|
|||
|
|||
![]()
Hello,
That is a good question. I am no expert in that area, and I just fiddled on until it worked. After a bit of investigating the original code I found out how it worked. What I did was resizing the image in a separate thread. For this I needed a OpenGL context, because gluScaleImage is used by OpenSceneGraph. So in this thread I create a new OpenGL context for the gluScaleImage. So the texture is never uploaded to the graphic card for display in this process. I never really looked at what OpenSceneGraph did I my thread, but it worked. I now also found out the problem. My image is normally not a power of two. So I would read it in, remember the original size and then rescale the image in another thread and display it using the original size to determine the size of the texturequad to display it on. An image with the power of two dimensions loads up fast enough, with (almost) no stuttering. Using the the option resizeNPOS=False still gives a delay when uploading the texture to the graphic card. That is what my example program did and what confused me. So this more or less solves my problem. Except that I now need to make something to automatically scale those images. It would be nice if the scaling could be done when loading the texture, because then the director solution would work. So something like viz.addTexture('test.png', instantScale=True). Thanx for all the help. Sometimes it is just a matter of asking me the right questions. |
#3
|
|||
|
|||
Ok, that makes sense now. I still don't understand why a NPOT texture would take longer to upload to the card. Are you sure your driver supports NPOT textures? I just tried it here and a 1023x1023 texture took just as long as a 1024x1024 texture. When you resized your texture was it resizing down to the nearest power of two? That would explain why it would take less time, since there would be less data to upload.
Either way, we will consider adding manual scaling support to texture objects in a future release. In the meantime you can use the PIL library to scale images. I've actually used this library to do exactly what you are talking about, load and scale images in a background thread, then upload to the card in the main thread. This article describes how to install and use the PIL library with Vizard. |
#4
|
|||
|
|||
Also, you should disable mipmaps on your texture if you don't need them. In most cases this will increase texture upload time.
Code:
#Use non-mipmapped linear filtering texture = viz.addTexture(imagelist.next(), resizeNPOT=False, filter=viz.LINEAR) |
#5
|
|||
|
|||
![]()
Hello,
Hey, it was the mipmapping that gave the problem. Turned off, the NPOD textures load up very fast. Turned on, I get the delay again. So probably generating mipmaps for textures with a power of 2 is much faster. (I can imagine why) With this knowledge I now can make what I want. I won't need the texturescaling because I do not need the mipmaps. But if I would need the mipmaps, then I think the texture scaling still would be needed. Greetings, Joran. |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
trouble loading vrml files generated by ProE | tavaksai | Vizard | 12 | 12-09-2008 11:11 AM |
How to edit the skin tones of the complete characters' cfg files? | vEsotu | Vizard | 3 | 09-23-2008 12:07 PM |
optimizing the loading of .wrl files | dan12345 | Vizard | 2 | 06-10-2008 11:36 PM |
loading large wav files in vizard | tommahhh | Vizard | 1 | 05-16-2005 03:23 PM |
Including Files that Include Other Files | vjosh | Vizard | 1 | 09-21-2004 04:44 PM |