Do textures work for you?

Apparently, gl.enable(gl.TEXTURE_2D) is invalid WebGL, and is absolutely not needed (according to the spec) to make textures work.

However, pipy says in the comments that, at least for him, textures don’t appear without it. Both pipy and Kenneth Russell suspect that the cause might be the graphics driver. [UPDATE: sounds like that was it: he's managed to find an updated driver that fixes it for him. See his comment for more.]

If this is a widespread problem then until the drivers are fixed, it needs to be addressed by people building WebGL pages (or maybe even in the browsers). So it would be great to get a sample of how many people are affected: if you have a WebGL-enabled browser, could you have a quick look at this demo, and then post a comment here saying whether or not you see the wooden crate texture on the spinning cube, and what OS/graphics card/browser combination you’re using? Both positive and negative results much appreciated!

You can leave a response, or trackback from your own site.

33 Responses to “Do textures work for you?”

  1. Groovounet says:

    On an OpenGL point of view, gl.enable(gl.TEXTURE_2D) is not required.

    This actually reflex the old fixed pipeline of OpenGL 1.x. With shader, it doesn’t make sense.

    If you want gl.enable(gl.TEXTURE_2D) says “process the texture” which is actually an order you do with instruction in the shader.

  2. giles says:

    Groovounet — thanks for the explanation, that clarifies why so many demos have it — like my own code, they must have inherited it from old non-shader-based demos. That in turn would explain why the bug in pipy’s graphics card (and perhaps in others’) has been masked. Still, the more we can find out about the prevalence of the graphics driver bug, the better!

  3. Coolcat says:

    Works for me.

    Minefield 3.7a1pre (updated today)
    Fedora 11 Linux (x86_64)
    Nvidia Geforce 9800 GT

  4. murphy says:

    Works for me (Minefield and WebKit on Mac OS X). I don’t know about drivers ;) but my hardwar supports OpenGL 2.1.

  5. Groovounet says:

    I guess, there is no driver issue involve here.
    I guess as well that WebGL is implemented using OpenGL 2 in navigators.
    It’s probably a implementation issue due to the specification mistake.

    ATI drivers used to have this bug with their OpenGL drivers but it’s a long gone bug now.

  6. Andrea says:

    Works for me!

    Chromium on Ubuntu Linux 9.10 (32bit), NVidia FX 1400 (173.14.20)

  7. titan says:

    Works for me.

    Minefield 3.7a1pre (Hardwarerender mode – updated today 20th.01.2010)
    Win7 x64
    INTEL 4500MHD (or so, notebook)
    Intel Driver

  8. Paul Brunt says:

    Chromium & Minefield 3.7a1pre on Ubuntu Linux here

    Although, I used to have an issue with texture on my old ATI(sorry, can’t remember what it was) a couple of months back but that was a mipmap issue I think.

  9. Skofo says:

    No prob here; Chromium on Win 7 x64 w/ GTS 250.

  10. Works for me:
    OS X 10.6.2
    Intel Macbook Pro

  11. giles says:

    Thanks, everyone. Looks like it’s a not a widespread problem, then. Either a driver issue, or as Groovounet says, perhaps it could be something in the OpenGL implementation itself? The fact that pipy has now reported that the problem is there in Minefield as well as Chromium makes it pretty certain that the problem’s not in the browsers, at least:

  12. Roman says:

    Sorry for being a little late…

    No textures.

    Minefield3.7a1pre (just updated)
    WindowsXP Pro SP3
    ATI Radeon 9550/X1050

  13. giles says:

    That’s interesting, thanks Roman. It’s probably a silly question, but have you updated your graphics drivers recently?

  14. pipy says:

    I was finally be able to update mobility fireGL drivers(ATI don’t provide them any more so we are depending on HP to update it) with the catalyst 09.12(modified with Mobility Modder.NET). and every things now WORKS!!!!! Hire are the info for driver versions from HP and modified ati catalyst 09.12:

    FireGL From HP
    Driver Packeging version 8.632.1.3.090915a-089023C
    2d Driver version 8.01.921
    Direct 3D version
    OpenGL Version
    Catalyst Control Center Version 2009.0915.2144.37147
    HP Date 30.10.2009

    Catalyst 09.12 modified with Mobility Modder.NET
    Driver Packing Version 8.681-091124a-092499C-ATI
    Catalyst Version 09.12
    2D Driver Version
    Direct 3D Version
    OpenGL Version
    Catalyst Control Center Version 2009.1124.2132.38610

    Both of them are for Windows 7 x64.

  15. giles says:

    That’s great news — thanks for posting it!

  16. Ecu says:

    No textures here.

    Chrome 5.0.317.2 unknown
    ATI Mobility Radeon HD 4650
    Driver version: 8.563.1.3000

    I just downloaded and installed the newest driver from HP, but its rather old. As this is a common issue for users, I can expect that there would be others with this problem.

  17. giles says:

    Thanks, Ecu — it’s interesting that you’re looking at HP drivers, as was pipy. I wonder if it’s something in the HP version of the drivers rather than ATI’s?

    Do you think you might be able to find a driver provided directly by ATI?

  18. Ecu says:

    I was able to use modtool to hack the ATI driver and make it work with my HP. However, I think this is a rather nasty issue as the average laptop user wouldn’t be savy enough to work through all that.

  19. giles says:

    Glad to hear you could make it work — I agree, that it’s well short of an ideal solution, though. How old is the computer?

  20. Ecu says:

    Not old at all. Its under a year old. Rather top end machine as well.

  21. giles says:

    That’s very odd, then! I’d heard that the problem existed in “old” ATI drivers, but it would be weird if a new machine came with those. So presumably it’s in some of the newer drivers too.

    The problem is, it’s very hard to work out what to do here.

    The problem is in the graphics drivers, so in an ideal world it would be fixed there. This would mean that there would be one fix per bug, which is what we would want. But the driver writers aren’t fixing the bug because it doesn’t affect enough of their customers, who are (I suspect) mostly using software that does have workaround for the bugs; I get the impression that a lot of the time games developers spend writing their software is coding stuff to take account of the different quirks of different cards and drivers.

    The next alternative would be for the browser writers to put in a workaround; they could put calls to gl.enable(gl.TEXTURE_2D) in their own code, which would not be correct strictly speaking but would ensure that WebGL coders saw correct behaviour. (I’m assuming here that there would be no subtle side-effects from doing that.) This would mean that there would be bit of code in each browser to fix the problem; for three browsers, that means three times as much code as fixing the problem in the driver, which is worse but not that much worse. However, I get the impression that the browser writers are not keen on putting in a workaround for a bug in the drivers’ code. To be honest, I can sympathise with this. Doing it just for one bug might not be such a problem, but I can see it could open the floodgates to many others. At the end of the day they’d rather be able to say “the browsers are all fine, only badly-implemented graphics cards won’t work” and hope that customer pressure on the graphics card makers will make them fix their drivers.

    The problem is that until that happens, people who, through no fault of their own, have graphics drivers that exhibit these bugs, will see that WebGL pages don’t work for them, and may simply conclude that (a) WebGL is broken and not worth bothering with or (b) the specific WebGL pages that they’re seeing problems with are broken. In case (a) this will slow adoption of WebGL, and to a lesser extend the same goes for case (b).

    But case (b) also has an even more dangerous effect; as a WebGL page creator, I really would rather that people don’t think my pages are broken. So the temptation to put the workaround into all of my WebGL pages is very strong; but this is the worst of both worlds, as it means that one bug now turns into a line of code to work around it in *every WebGL page on the Internet*. The problem that the browser implementors seem to worry about is still there, too — so if there are multiple graphics card problems, each of which needs its own workaround, then every WebGL page will be full of extra code to make sure it runs everywhere. Learning it will be like learning DHTML back in 1999, except that instead of having to handle IE versus Netscape differences, there will be tens of different kinds of graphics cards, each with their own bugs.

    The problem is that the people who should fix the problem, the graphics card vendors, are probably the ones with the weakest incentive to do so. The people with the strongest incentive are those who are building WebGL pages. It feels like the dynamics of the situation are pushing everyone in the worst-possible direction…

  22. Ecu says:

    See, the sad thing is…the graphic card company itself fixed the bug. Unfortunately, for HP laptops you have to hack the driver to make it work. The average user will not know how to do that at all.

  23. giles says:

    That’s a very good point. OTOH, that means that if WebGL does take off, HP will have a good incentive to fix the problem. Doesn’t help their customers much right now, though, I guess.

  24. Ecu says:

    At least the people that want to use WebGL right now are developers. The types that actually know how to modtool. So, just hopefully HP steps it up this year as WebGL becomes more and more popular.

  25. giles says:

    Let’s hope so.

  26. Crwth says:

    No textures for me either; I’m running XPSP3 on an iMac, so have the Mobility Radeon drivers that come from Apple. They don’t seem to have updates for them, and I’m remiss to try anything else, as my wife uses this machine. *:^)

    I have other machines that I can use, so it’s not a game-ender, but just thought I’d add my two cents.

  27. giles says:

    Thanks for letting me know — that’s the first Mac I’ve heard of that demonstrates the problem — but by XPSP3, do you mean you’re running Windows on it?

    Understood re: upgrading one’s wife’s machine, definitely much too risky to try ;-)

  28. pran says:

    Intel graphics card.

    Used mozilla developer preview 3.7. No textures. Is there a way out to be implemented in the browser that could resolve this?

    Tried the work around gl.enable(gl.TEXTURE_2D); Does not work.

  29. giles says:

    Hi pran — thanks for mentioning that! As I’m sure you know, Intel graphics cards only work with software rendering via OSMesa, and the OSMesa library that most people are using is only compatible with the 3.7 developer preview. I think the problem you’re seeing is that the WebGL API for textures has just changed, and I’ve updated the tutorials to reflect the change — but, of course, this made them incompatible with 3.7.

    However, there’s some potentially good news. Vladimir Vukicevic has made a new build of OSMesa available, and it may well work with the current nightly builds, which have the latest API. I don’t have access to an Intel graphics machine right now, so if you could try the following and let me know what happens, I’d be very grateful:

    I think that should work.

  30. pran says:

    Hello Giles,

    That’s great. It is working :)


  31. giles says:

    Hi Pranamya — thanks for letting me know, that’s great news!

  32. pianom4n says:

    I have a Radeon 4200 HD (integrated graphics) with Windows 7 x64, and textures were working, but not mipmaps (they faces were all white). My driver verision was 8.632.1 (what Windows 7 auto installs).

    Downloading the latest drivers from ATI (8.573.0, Catalyst 10.7) fixed the problem. Hope this helps someone.

  33. giles says:

    Thanks, pianom4n! I’ve left a pointer to this on a different thread where someone else was having a problem that sounded similar.

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter