i wonder if anybody had this problem in a project before:
we have a dual screen setup with primary head to a 1024x768 projector and the second head to a 1920x1200 TFT screen. on both sides we load about 50 pictures, 512x384 on primary and 1920x1200 on the second screen.
the problem is, that we get some errors in the big pictures, it looks like horizontal lines. the error only appears in the upper half of the picture, and only on some of the pictures. one of it has the error almost every time (its the one that is visible right after startup), while others have the error only occasionally.
strange thing is, when connecting a writer to the renderer and making a screenshot, the error is not visible on the saved picture…
the computer is 2,4 Ghz dualcore 2GB ram, nvidia 8800 GS with 512mb vram.
have seen those horizontal lines pop up randomly before. our setup was not dualview, but two graphiccards and only one output of one of the cards was fullscreen. as you describe the error was mostly happening with the same pictures but was definitely not reproducible and really rarely happening. my best bet was that it had something to do with mipmapping.
see if you can disable mipmapping alltogether. don’t forget, if you preload the textures to also disable mipmapping in the preloading FileTexture. in case you’re loading .dds files note that they can have mipmaps already saved in the file. and there is the mipmapping filterstates to play around with…
and let us hear your results on this spooky topic.
do you convert the pics with the filetexture node? what happens, if you wait a bit until the patch is loaded completely and then (manually) load the textures?
are you sure the errors occur in the texture and not in some later stage? what happens if you rotate/scale the texture? or reboot your monitor? does changing the output resolution solves the problem? does underclocking the gpu changes something?
but due to a lack of time, we couldn’t persue the issue much further. but we tried everything we could think of. like reloading the files after some frames, load in background, loading first the textures of the one head and then of the other, delaying the switch to fullscren, different formats and settings of the filetexture…
the only setting that worked, was to load the files with a samller size. as it still looked quite good, we kept it like that.
so its most likely a memory issue. the big textures all together have ~ 405 mb, plus the small ones could be a total thats slightly more than the 512 mb vram. but in that case some of the textures should be loaded into the ram. so i think its because its just a little more than 512 mb and somehow the memory management went wrong.
so its most likely a memory issue. the big textures all together
have ~ 405 mb, plus the small ones could be a total thats slightly
more than the 512 mb vram. but in that case some of the textures
should be loaded into the ram. so i think its because its just a
little more than 512 mb and somehow the memory management went
wrong.
Maybe you can load some more Textures (you don´t really need) so you have definitely more than 512 MB.
good idea, but we left the construction site yesterday… maybe kathi or so can test it with the backups at meso or so, if we have a similar computer there…
we had a similar problem within a setup of two graphic cards using 2 graphic outputs on the primary and only one on the secondary card. each of the 3 screens rendered 1920 x 1080. Dualscreen mode.
We have loaded and rendered about 20 texture a 1360 x 1024 pixels on two of the outputs.
No matter how we changed the graphic heads, alywas one of them had problems rendering the textures correctly. we tried mip map settings and filter states. no changes.
the only thing we can definetly say: the less pixels per texture the better works. it seems to be like a render frame drop on the graphic heads.
when i remember it correctly textures are beeing processed from left to right starting in the upper left corner… this would explain the horizontal lines…
