![]() |
#1
|
|||
|
|||
![]()
Hello,
I understand that when you load models or textures the rendering will stop until the file is completely loaded. But sometimes you don't want that. Is there a way to load files, in particular textures, in the background? I thought that maybe viz.director could do the trick (since the help says it starts a new thread), but that doesn't work. Greetings, Joran. |
#2
|
|||
|
|||
Can you post the code you are using to load the texture?
Loading a texture within a director function will perform the file IO asynchronously from the main graphics loop. However, the texture data must be uploaded to the graphics card in the main graphics loop. If you have a large texture then this might be causing the stuttering. What are the dimensions of the texture? If the texture is large you might consider saving it to a DXT1 compressed DDS file. This will decrease the file IO time and upload time to the graphics card. |
#3
|
|||
|
|||
Hello,
This is the test script I use: Code:
import viz viz.MainView.setMatrix([ 0.995800, -0.029732, 0.086595, 0.000000, -0.000767, 0.943062, 0.332616, 0.000000, -0.091554, -0.331285, 0.939078, 0.000000, 1.961064, 5.105468, -15.360188, 1.000000 ]) viz.go() viz.mouse.setOverride(viz.ON) beam = viz.add('box.wrl', scale=(10,1,1)) beam.addAction(vizact.spin(0, 1, 0, 30)) screen = viz.addTexQuad(scale=(10, 10,1)) screen.alpha(0.8) imagelist = viz.cycle(['info/0100.png', 'info/0300.png', 'info/0400.png']) def asyncTextureLoad(): texture = viz.addTexture(imagelist.next(), resizeNPOT=False) screen.texture(texture) def onKeyDown(key): if key == ' ': viz.director(asyncTextureLoad) viz.callback(viz.KEYDOWN_EVENT,onKeyDown) I am trying to port a C++ OpenSceneGraph program to Vizard. There I solved this problem by uploading the texture to the graphic card in a separate thread. Any ideas how to solve this with Vizard? Greetings, Joran. |
#4
|
|||
|
|||
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.
|
#5
|
|||
|
|||
![]()
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. |
#6
|
|||
|
|||
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. |
#7
|
|||
|
|||
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) |
#8
|
|||
|
|||
![]()
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 12:11 PM |
How to edit the skin tones of the complete characters' cfg files? | vEsotu | Vizard | 3 | 09-23-2008 01:07 PM |
optimizing the loading of .wrl files | dan12345 | Vizard | 2 | 06-11-2008 12:36 AM |
loading large wav files in vizard | tommahhh | Vizard | 1 | 05-16-2005 04:23 PM |
Including Files that Include Other Files | vjosh | Vizard | 1 | 09-21-2004 05:44 PM |