A render-to-texture problem?

It sounds like some machines might have problems with the render-to-texture code that I’ve written for lesson 16, which is a pain! I’d be really grateful if more people could let me know what they’re seeing when they load up the demo page; you should see a slowly-rotating laptop, on the screen of which there is a different WebGL scene, showing the moon and a crate spinning slowly around the point between them.

Any feedback at all, positive or negative, would be much appreciated — what you see, your OS, browser, and graphics card.

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

37 Responses to “A render-to-texture problem?”

  1. Denny says:

    Hi Giles,
    i am seeing the moving Laptop model. It seems correctly lid, but i get only a black screen. Tested with latest Minefield and WebKit on Snow Leopard.

    P.S.: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100308 Minefield/3.7a3pre (.NET CLR 3.5.30729) shows the Laptop and two white moving shapes on the screen of it.

  2. Hi Giles,

    I tested it with a recent Chrome nightly build, same result as Danny’s one.
    One thing I noticed is that you are not setting the viewport when you bind the framebuffer object to its correct size (and then set it again when rendering to main screen).
    In general, whenever you set a target surface to render to, you must explicitly specify it’s viewport, in this case gl.viewport(0, 0, 512, 512) when doing rtt, and then gl.viewport(0, 0, canvas.width, canvas.height) (thich is a 500×500) when rendering to screen.
    Of course it does not matter if the sizes are the same, but it’s a good practice to set the whole transformation chain data when rendering (this includes the viewport). Even when you do not rtt, it is good to re-specify the viewport in the rendering function, although it doesn’t change, so you have all transformation operations easy spottable in the code.
    This is how I am used to do, so please do not take this advice as a must :)

  3. blinblin says:

    Hi Giles,
    The scene just shows the laptop with a white or black screen (depending on the angle), no WebGL scene on it. Previous lessons work fine.
    Chromium 5.0.363.0 (42644), GeForce 7900GT, Windows XP sp3

    p.s.Thanks for the so great lessons !

  4. nameless says:

    I see the laptop rotating,but nothing is on the screen of it.
    I’m using Mozilla Firefox Developer Preview 3.7 Alpha 3.
    My graphics card is nvidia 9800GT, the graphics driver is rather new, supporting OpenGL 3.2
    My Internet connection is rather slow, that could have something to do with it, but after all these bug reportings before I don’t think so.

  5. I’m seeing the moon and crate on the laptop but nothing is textured. Minefield and Chromium, Windows 7, ATI Mobility Radeon HD4530.

    In Chromium there’s also some black round thing occluding the moon/crate some of the time.

  6. Pyro Technick says:

    No moon/crate in Chromium/Minefield on Snow Leopard :(

  7. steve says:

    Would it be possible to specify if you have NVidia or ATI graphics displays? I’m also looking into this problem and haven’t been able to find anything so far. I’m about to probe through other render-to-texture code to see if I can find a working example and what the difference is.

  8. Sticking a gl.enable(gl.TEXTURE_2D) in the init function fixes the missing textures for me. Both latest Minefield and Chromium, still Win7 with a HD 4530.

  9. steve says:

    @Jacob; that fixes the white moon/crate problem for other people? Still no rendering in the laptop screen for me.

  10. ewgl says:


    Isn’t it becuase you don’t have a colour renderbuffer in your Framebuffer object?? Becuase i think you still need that too for textures used in the framebuffer

    many greetz

  11. ewgl says:

    sorry stupid mistake I made there

    I will look further into it once I get home.

    I found a nice tut for framebuffers


  12. Peter says:

    rotating white/gray laptop, nothing on the laptop screen except black.

    safari Version 4.0.4 (6531.21.10, r56207)
    GeForce 8600M GT
    Mac OS X 10.6.2 (10C540)

  13. giles says:

    Thanks to everyone for so much feedback!

    @Marco — good point; I think that the viewport calls are optional with the canvas, but I should definitely be putting them in for the FBO. Sounds advice!

    @Jacob — it’s interesting that the gl.enable(gl.TEXTURE_2D) helped; I know there is a problem with some graphics drivers that means that they require it, though. Do you put that line into your own demos?

  14. Denny says:

    Hi Giles,

    i just implemented render-to-texture to EnergizeGL.

    First i had the same problems, just seeing a white texture. I implemented gl.enable(gl.TEXTURE_2D) and the viewport calls. Thx a lot Marco and Jacob, but what actually does the trick for me was to switch from gl.DEPTH_ATTACHMENT to gl.COLOR_ATTACHMENT0 in my gl.framebufferTexture2D call, and i don’t use a renderbuffer!

    So maybe this:
    gl.framebufferRenderbuffer(gl.FRAMEBUFFER, gl.DEPTH_ATTACHMENT, gl.RENDERBUFFER, renderbuffer);
    is the problem!?
    Does any of the GL pros can image why?

  15. giles says:

    OK, I’ve uploaded two new versions:

    * If you go here, you’ll get the page with viewports set properly, as recommended by Marco: http://learningwebgl.com/lessons/lesson16/

    * If you go here, you’ll get the same thing, but with gl.enable(gl.TEXTURE_2D) in the render functions too, which Jacob found helped: http://learningwebgl.com/lessons/lesson16/index-enable.html

    Any feedback would be much appreciated!

  16. Springer says:

    still a blank screen instead of the RTT

    Minefield 3.7a2pre, WinXP sp2 , NV 96000GT
    force ware6.14.11-9562.

  17. steve says:

    No difference, still the same problem as before.

    I do notice that when I comment out the re-binding to rttFramebuffer, the moon and crate are properly drawn into the same view as the laptop. This confirms that absolutely everything is OK except for the rttFramebuffer setup.

    Here’s a demo that appears to work OK, so I’m going through this line by line… http://spidergl.org/example.php?id=4

  18. Hi,

    I think I spotted out the problem.

    - Short answer:
    after creating the rttTexture add one of these two lines:
    gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR);

    - Long answer:
    in OepnGL, textures and framebuffers has a “completeness” state associated to them. Among other factors, the most important is that the texture must have all its mipmap levels specified before any mipmap filter is used.
    I don’t want to go deeply into mipmap description, anyway, by calling
    gl.texImage2D(gl.TEXTURE_2D, 0, …etc)
    you are telling the GL to use that image data for mip level 0 (or base level). Given that the default texture minification filter is gl.NEAREST_MIPMAP_LINEAR, the texture won’t never be used by the GL in read mode, e.g. sampling from them inside shaders, because it is expected that you have specified all of its mip levels via texImage2D.
    The right way is thus one of the following:

    1) specify all mip levels with gl.texImage2D(gl.TEXTURE_2D, 0..N-1, …);

    2) do not use a mipmap filter: use gl.NEAREST or gl.LINEAR if it fits your needs;

    3) have the GL generate the whome mip pyramid for you by calling gl.generateMipmap(gl.TEXTURE_2D); This will generate all the required mip levels for the currently bound texture object in the current texture unit.

    Regarding the workaround with gl.enable(gl.TEXTURE_2D) i am very upset that it worked, because it addresses OpenGL fixed function pipeline, this means a serious bug in how GL context are prepared before being boxed by javascript interfaces.

    @steve – In fact if you go through SpiderGL code you’ll see that by default I initialize both minification and magnification filters to gl.LINEAR (although you can of course change default behaviour via “options” parameters).

    I hope my explaination was clear :)


  19. steve says:

    Yep, verified – all working with Marco’s suggestion applied. A further factor to consider is that core OpenGL ES 2.0 will revert to software rendering if using textures with mipmaps, so the LINEAR option is the best for keeping it in hardware.

    Marco; the TEXTURE_2D thing was spotted and fixed about a month ago, so it should not be necessary for any recent builds. Jacob should upgrade and try again, or check that he’s not using an older version of the browser?

    Thanks Marco, you fixed it! Giles; all good to go now. :)

  20. EWGL says:

    indeed fixed it on all my computers on both minefield and chromium. Thanks Marco

  21. @steve: Using freshly downloaded builds, Chromium 5.0.365.0 (42904) and Minefield 3.7a4pre 20100326. I get no textures without enabling TEXTURE_2D.

    The RTT part seemed to be working all along, though. Just with a white moon and crate.

    @giles: And yes, I do put it in my own projects – but my understanding was also that it wasn’t necessary and that it’s not part of the spec.

  22. steve says:

    @Jacob; now that the texture mipmap has been fixed, do you still need TEXTURE_2D enabled? I remember discussion on the WebGL mailing list about that, and it was deemed a bug that would be fixed.

  23. @steve: Yes, still need it.

    Something else: even with TEXTURE_2D enabled, it’s pretty shaky. Sometimes it works, sometimes the textures are missing. This doesn’t happen when running it from localhost, though. Maybe a timing issue due to latency or something..

  24. Christof says:

    Windows 7 pro
    ATI Radeon 4850
    chromium / minefield
    everything looks great :D

  25. giles says:

    @Marco — thank you so much! Your explanation is very clear — I’ll have to think a bit about which solution to use in this example, though. gl.generateMipmap(gl.TEXTURE_2D) sounds very tempting for the sake of the appearance of the demo, but perhaps using a non-mipmap filter would make sense from the perspective of ease of explanation. I’ll sleep on that.

    @steve — many many thanks for reporting the problem, investigating it so carefully, and for checking out Marco’s fix!

    @EWGL — thanks also for checking it out, looks like we’ve definitely got the solution here.

    @Jacob — here’s the last discussion about the gl.enable(gl.TEXTURE_2D) problem that there seems to have been here: http://learningwebgl.com/blog/?p=1569 — might be that you can get rid of the problem by updating graphics drivers.

    @Christof — I guess you and I just have very forgiving graphics drivers :-)

  26. @giles: Thanks, maybe I’ll do that. My laptop is also a HP like those in the other comment thread and like they say, getting up to date drivers working means hacking, which I haven’t done after a recent OS upgrade.
    Anyway, I’m keeping my TEXTURE_2D enabled until it’s fixed somewhere else. Can’t count on regular users doing what I haven’t bothered with myself.

  27. giles says:

    Perhaps we should lobby the browser implementors to put the workaround code for the driver bug into the browsers themselves, just so that it doesn’t wind up in every WebGL example (and thus wind up spreading like a plague when WebGL really takes off)?

  28. ewgl says:

    That is an excellent idea.

    Becuase, sorry to say, but that should be their job. We need an implementation that can work crossbrowser if we follow the draft. And gl.enable(gl.texture) isn’t in there.

  29. giles says:

    OK, I’ve added lines to set the minification and maximisation filters to the same values as I’ve used with other textures in the other tutorials, and also added code to generate the mip levels after the render-to-texture. Thanks once again to Marco for showing the way!

    I’ve also re-introduced the gl.enable(gl.TEXTURE_2D). It’s a pity to have that there, but I’d rather put in compatibility code than have people getting frustrated and giving up because they can’t get textures to work in WebGL. Thanks to Jacob for re-raising that issue.

    Any further comments would be much appreciated!


  30. Thormme says:

    It now works for me using Minefield and Chromium!
    I’m using an Nvidia 9600 GT if it’s of any significance.

  31. giles says:

    Excellent, thanks Thormme!

    I reckon that some cards — perhaps certain ATIs — are forgiving about textures with insufficient mip levels and just use whatever they have, while others are less forgiving. TBH I think I prefer the latter, it’s good if vendors are strict about their standards.

  32. Cid says:

    It works for me on both Minefield and WebKit, with one caveat: On WebKit, the sort-order for the rendered texture is reversed (displaying furthest depth, not closest).

    Snow Leopard
    ATI Radeon HD2600 Pro

  33. giles says:

    That sounds odd! Do you have any kind of screen-capture software? It would be interesting to see exactly what it looks like.

  34. Lars says:

    Works here:

    Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100405 Minefield/3.7a4pre

    Machine: DELL XT2 (GMA 4500MHD)

  35. Cid says:

    I’ve sent two images to: [email protected]

    It was the only address I saw on your site.

  36. giles says:

    @Cid — thanks! Unfortunately for some reason they never arrived, so I’ll drop you a line directly.

    @Lars — thanks for letting me know! This one’s proving tricky to get right, but positive feedback (“works for me”) is just as useful as negative.

  37. Scott Lininger says:

    Reviving an only thread…

    I just see a black screen in the nightly build of Chromium on XP from July 1st, 2010. Other framebuffer demos around the web (including the spiderGL one linked above) seem to crash consistently. Other folks seeing this trouble?

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter