I noticed this bug while checking some files created with a Python import add-on I'm currently porting to Blender 2.60. I'm atttaching one of the imported files as an example.
If you check the attached .blend file in "Solid" viewport shading:
- in "Object" mode the mesh is properly rendered (see attached screenshot: object_mode.png)
- when switching to "Edit" mode, a few random polygons are rendered as transparent (see attached screenshot: edit_mode.png), even though they share exactly the same properties and material than some other polies which are properly rendered.
- now, select one of this tranparent polygon and assign it another material (eg. the second one): this polygon as well as several other transparent ones will get properly rendered (ie. opaque). If we assign it again the first material, all polygons turn transparent again...
I though it could be an issue with the Python API or the plugin itself, but the same file opened in v2.59 (r39307) shows no issue.
I've also tried to run the import addon both in v2.5 and v2.6: no matter a file is created under v2.5 or v2.6, it always renders properly in v2.5 and badly in v2.6...
For info, the mesh is created using the from_pydata() command and each face has its material assigned through its .material_index attribute.
The materials are using no special setting except the shadeless option. I don't think any other significant Blender setting was modified.
Blender version: v2.60a (r41226)
OS: WinXP
Description
Event Timeline
Can't see any transparent faces in edit mode. Linux 64bit and WIn7 64bit.
Maybe you can also attach system-info.txt generated by Help -> System Info operator?
Ok, I'm attaching system-info.txt.
BTW I noticed it features the mention "platform: Windows:64bit". I don't know whether it's about my platform or about the platform Blender was built on but my OS is actually 32bits.
Don't think it's OpenGL issue. Probably, issue was solved with commit 42158. Would be great if you'll test this revision.
And maybe somebody else can redo this problem?
I just tried with r42161 which at the time of writing was the only 32bits one greater or equal to r42158 available on GraphicAll (this build is named :"Trunk 32bit SSE2").
The issue is still here, exactly the same than with r41226.
Actually, it doesn't really sound like an OpenGL issue, as it would not explain why assigning a different material to one single buggy face can be enough to fix the issue for all other buggy faces, would it?
To try to pin down the emergence of this bug, I have also checked these 2 builds:
r39740 --> no issue
r40372 --> issue is here
Just a guess but I wonder if it could have something to do with the recent DFelinto's port of TexFace to material (commited on r40372).
This does sound like an OpenGL / graphics card related issue to me, especially since we have not been able to redo this. Issues with state changes or driver bugs could give this kind of problem.
Do you by any chance have VBO's enabled in the user preferences, and does enabling/disabling that make a difference? Also useful to test would be to do Load Factory Settings, and then load the .blend file (your current user preferences will not be lost by this, it's just temporary).
Ok, for me it rather sounded like an issue with corrupted material data but maybe it actually has something to do with OpenGL, I would not dare to discuss that point with you Brecht...
About your points:
- VBOs are disabled (and has always been). Enabling VBO doesn't change anything.
- I tried to load the.blend file using Factory Setting but it hasn't fixed anything (I even saved the Factory Setting as default and restarted Blender to be sure no addon was loaded). My profile is usually very close to the Factory Settings anyway...
Too bad you can't redo it. But has anybody tried on a 32 bits platform BTW?
I'm also attaching 2 new files just in case, I don't know if you have a way to examine a .blend content but maybe that could help.
I saved a .blend file with the issue, then I applied another material on one face (which fixes the issue as exposed in 1rst post) and saved the new blend file. To resume: theoretically we have 2 virtually unchanged files except the material of one single face. If I load first file, I see the issue (several transparent faces), if I load the second one, I have not issue (all faces are opaque). Both files are exactly the same size and the binary content is very similar, only a few hundreds bytes differ.
Tested 32bit windows build on my laptop with gt520m videocard and didn't notice artifacts. Also several artists from #blendercoders weren't been able to reproduce your issue. Can see two things you might want to try:
- Check if there are updates for your videocard drivers
- Download graphicall.org/ftp/ideasman42/opengl32.zip and upack dll to the same folder and blender.exe. Then run blender and see if there are still transparent faces for you (this dll will switch blender to fully software opengl, some slowdown can be introduced)
Thanks for test Serguey.
- I'm already using the last driver (ie. GeForce 175.16) as FX 5500 is not supported anymore by newer nvidia drivers.
- Using opengl32.dll actually prevents the issue... It was really slow and it introduced z-fighting but there was no transparent faces anymore.
tested with a GeForce 450 GTS, arch linux, 64 bit, no errors.
since this works in software and on many peoples systems this is almost certainly a driver bug/error.
moving to OpenGL Errors.
A few extra info:
I have temporarily replaced my gfx card with an older and less powerful ATI Radeon 9000 to test in exactly the same conditions, and there was no error anymore.
So it likely confirms there is something wrong with the GeForce FX 5500.
It's still weird that it worked properly in r39740 and not in subsequent releases though...
Don't hesitate if there is any other test / action I could do to help you pin down the issue.