BennyQBD / 3DEngineCpp

It's like the 3D Game Engine, except in C++
Apache License 2.0
301 stars 84 forks source link

Render to texture not working #6

Closed EvilSocket1 closed 10 years ago

EvilSocket1 commented 10 years ago

Visual Studio is not capable of compiling your project anymore. This is, because you used GLenum drawBuffers[m_numTextures]; and Visual Studio doesn't want you to create dynamic arrays this way. The easy fix GLenum* drawBuffers = new GLenum[m_numTextures]; does not work either (but at least it compiles). It gives you this: effect effect2

Colt-Zero commented 10 years ago

For the sake of reinforcing that this is a rather big issue, I can say that I am having the exact same problem.

BennyQBD commented 10 years ago

I've updated the array so it builds in visual studio, and it now runs as intended for me on both Windows and Linux. Try getting the latest commit and seeing if it works for you.

EvilSocket1 commented 10 years ago

At least for me that is not solving the issue (but hey, at least it compiles). I'm running a windows 7 computer with opengl 3.3 (Which should be working just fine, shouldn't it?)

Colt-Zero commented 10 years ago

Same as EvilSocket. While this does fix compiling issues, it does not fix the problem it's having with drawing. All I get is a grey square that shifts through various tones as you interact with the camera rather than the actual scene. Are you using visual studio to compile on Windows or some other IDE?

alan-jak commented 10 years ago

Same here, Still getting the gray square issue, although moving forward changes it to brown. Running the latest GeForce drivers from NVidia.

BennyQBD commented 10 years ago

I am using visual studio to compile, and I'm having no issue. Something you can try is replacing everywhere that I used "GL_DRAW_FRAMEBUFFER" with simply "GL_FRAMEBUFFER" (I believe there's 3 places you'll need to replace in texture.cpp, and 1 in window.cpp) Your graphics drivers might be having issues with the draw framebuffer for some reason.

Otherwise, I'd appreciate it if you gave a detailed step-by-step of what you're doing to produce the issue. That way I can see if I'm doing anything different than you are.

Colt-Zero commented 10 years ago

That's just the thing Benny. I encounter the problem with YOUR repository. Both with and without the "GL_DRAW_FRAMEBUFFER" to "GL_FRAMEBUFFER" change you just recommended. Could this be an Nvidia graphics card problem? Kiwuser said he has Nvidia and so do I. Also note that I actually haven't updated my graphics drivers lately and I suppose I could try updating them. Though, considering how Kiwuser said he has updated drivers, I don't think it will fix the problem if I did.

alan-jak commented 10 years ago

(https://www.opengl.org/wiki/Common_Mistakes#Render_To_Texture)According to OpenGL, this is a common issue with NVidia cards, I'm working on finding a fix for this, it says it has something to do with incomplete textures and missing mip map levels EDIT: I don't think there is a fix for this, as, like the page says, the framebuffer would be considered incomplete or unsupported if the texture error happened.

alan-jak commented 10 years ago

Benny, what GPU does your computer have? This issue seems to affect only people with nVidia drivers on their PCs, I just tried running with integrated graphics (the right click option), and nothing changed.

Colt-Zero commented 10 years ago

Sigh... This is quite frustrating. The only "solutions" I've found thus far seem to require the use of glut. I'm actually not entirely sure quite yet on whether or not its absolutely necessary, but every working example I've spotted thus far definitely uses glut.

I wouldn't really consider it that frustrating if it wasn't for the fact that Benny hasn't used glut for this project at all.

One thing I have noticed is that the solutions I've spotted keep pointing to a "PBuffer"

EvilSocket1 commented 10 years ago

Actually it seems to me, that the problem is hardware independent (I don't have a Nvidia graphic card). I found a few tutorials on this topic and I'm currently trying to spot the difference.

alan-jak commented 10 years ago

@EvilSocket1 Do you have an AMD/ATI card then? Depending on Benny's computer, this may be an issue with dedicated cards overall.

EvilSocket1 commented 10 years ago

I have an "Intel HD Graphics 4000"

alan-jak commented 10 years ago

@EvilSocket1 Then it isn't just a dedicated-gpu issue like I thought, if it affects you on integrated graphics, then it won't work for basically 90% of people - Benny must be lucky!

BennyQBD commented 10 years ago

I do have an AMD/ATI card, and I suspect that's why I'm not encountering the issue.

From what Kiwuser has posted and a little digging through the OpenGL wiki, the issue seems to be with texture completeness. For some reason, some graphics drivers won't create framebuffers with "incomplete" textures (textures without mipmap settings specified). This is a bug in the drivers and shouldn't happen according to the OpenGL spec, but clearly it does or we wouldn't be having this discussion.

The simplest way to create a texture with complete mipmap settings seems to be doing something like this during texture creation:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);

I've updated the repository with that code, and hopefully that will solve this issue.

pythoneer commented 10 years ago

Still having the grey screen :/

GeForce GTX 750 Ti nvidia_blob: 337.12

alan-jak commented 10 years ago

Doesn't seem to fix it for my nVidia card, and I don't think it was to do with texture completeness because like what I posted said, the buffer would be GL_FRAMEBUFFER_UNSUPPORTED or GL_FRAMEBUFFER_ATTACHMENT_INCOMPLETE not GL_FRAMEBUFFER_COMPLETE

EvilSocket1 commented 10 years ago

I shouldn't have to do anything with the nVidia Bug, because it also happens for me, without a nVidia card.

alan-jak commented 10 years ago

@EvilSocket1 Does the latest update fix it for you?

EvilSocket1 commented 10 years ago

The latest update only changes GL_DRAW_FRAMEBUFFER to GL_FRAMEBUFFER. And the fix for nVidia he explained doesn't fix the issue.

alan-jak commented 10 years ago

That update wasn't meant to be just for nVidia, the OpenGL wiki page I posted said that the issue commonly means there's an incomplete texture, I'm going to try that texture code he posted

alan-jak commented 10 years ago

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0); Tried it under the texture parameters in texture.cpp, didn't change a thing. So it's an issue only AMD/ATI cards can handle, which means Benny can't help us as he has AMD

BennyQBD commented 10 years ago

Sorry, I updated the wrong repository last time, so you didn't get the corrected code. Try now.

Colt-Zero commented 10 years ago

It's still broken for me. So whatever you did probably didn't work Benny. Oh well... When I get around to it, I'll really take a crack at fixing it on my own.

BennyQBD commented 10 years ago

Actually, try again. I literally just made another commit.

Colt-Zero commented 10 years ago

Nope... Still not working for me.

alan-jak commented 10 years ago

Still not working for me either

BennyQBD commented 10 years ago

I've updated the repo with my final guess as to what's wrong.

However, I'm afraid after this I'm going to have stop working on this issue. I really want to help you guys, but the code simply doesn't cause an issue on my computer. There's no way for me to reproduce the issue, or test things that might cause an issue, or really do anything other than make random guesses as to what might be causing it. I'd like to say I can keep guessing and asking you guys to check, but I've found there's few things in life more frustrating than debugging code by making semi-random changes and asking other people if it changes anything. That isn't your fault of course; it's just the nature of debugging like this. Despite that, I don't think this extreme frustration is good for my health, and seeing how it's ultimately not solving anything, I think it's best that I stop.

If you want this issue solved, then I'll need your help. If you're having issues with my code, then I suggest looking at other tutorials involving render to texture, and test if their code works for you. If it does, see what's different and try doing render to texture more like they are. If nothing else, that should give you a good idea as to what might be wrong. Here's some links to a few tutorials that use render to texture in some form to get you started:

If you figure it out, then please let me know. This issue is really bothering me.

Cheers, Benny

Colt-Zero commented 10 years ago

Benny, reporting once again that your repository update did not work for me.

I've been looking around and unfortunately, the closest thing I've found is more along the lines of an alternative for the frame buffer rather than a fix for the frame buffer.

What I'm looking at is something called the PBuffer and erm... Well, I haven't looked through all of it yet, but I'm having my doubts on this. From what I've seen, it seems to require the use of OpenGL headers that you have not implemented into your engine along with the possibility that it might require the use of glut. And besides that, the PBuffer class itself has this big heap of OS dependent code. From what I can tell, all the OSs seem to be handled, but I'd rather ask your opinion on it still.

On the plus side, the PBuffer's implementation into the actual drawing methods seems simple enough. Although, it makes use of the glReadPixels method, but I think there might be alternatives to that.

The example I'm looking at right now is found here. http://developer.download.nvidia.com/SDK/9.5/Samples/samples.html#simple_pbuffer

Edit: And take note that on the same page I linked you, there are other examples covering the usage pbuffers for rendering to texture. But I'm starting with that one as it is probably the most basic example.

Edit2: And if it isn't obvious enough, the PBuffer method for rendering to texture does work for me as proven by the little demo that came with that example, I wouldn't be posting this if it didn't work for me.

noah4477 commented 10 years ago

Colt-Zero are you saying that you have found a fix to this problem? Or will I have to use GLUT

Colt-Zero commented 10 years ago

What I'm saying is that, for reasons, I haven't actually tried to crack down on the PBuffer example yet. I will be attempting that tomorrow. The reason I'm unsure on whether or not GLUT needs to be used is because the example itself uses GLUT, and I haven't determined if it's actually needed to implement a PBuffer.

So yeah... More on that later. And if your wondering why I bothered posting about it even when I haven't done it myself. Let's just say I wanted others opinions on what I had found and if it was a suitable route to take. In particularly, I want to know Benny's opinion on whether or not this "solution" will work out for the engine.

noah4477 commented 10 years ago

@Colt-Zero wouldn't it be better to just use an FBO? I'm failing to understand why you want to use old ways of doing this when there is a better solution (according to Wikipedia FBOs are better than Pixel Buffers) so as far as I know they are better. Shouldn't we be working in trying to just revamp the code to try to make it work? But if pbuffers work then it's probably just a better idea to use it for now. Also have you looked into how the performance differences and limitations of Pbuffers?

Colt-Zero commented 10 years ago

Well, in terms of that. The only response I have is that I'm a half-assed researcher. I went with PBuffers because it was the only solution I could seem to find, not to mention I had spotted a multitude of sources guiding me in that direction. I know I also saw some stuff pointing out that there are a couple of ways to optimize PBuffers. Mostly just the recommendation to use glCopyTexSubImage2D

EvilSocket1 commented 10 years ago

It can't be an issue with framebuffers, at least not one, that makes using them impossible. The Demo from http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/ worked perfectly fine for me. I just didn't have any time to look closely and debug both programs.

BennyQBD commented 10 years ago

I'd strongly advise against using pbuffers for render to texture. They have some system dependencies, as you've noted, and furthermore they require an OpenGL context switch to be used, which is terrible for performance. There's a reason that OpenGL tried to entirely replace pbuffers with framebuffers, so I'd suggest sticking to FBOs. Besides, as EvilSocket1 has noted, it's not framebuffers themselves causing the issue; if it was, then a large number of your applications, especially games, would be displaying garbage.

alan-jak commented 10 years ago

I just got around to testing the newest update, and still no luck :( But what makes me very interested, is what does AMD's driver do differently to make it work? It would be useful if someone else tested this on an AMD card so we can establish for sure that this works on AMD only.

EvilSocket1 commented 10 years ago

Maybe the opengl version is important. I use opengl 3.3 with an "Intel HD Graphics 4000" and it's not working for me.

alan-jak commented 10 years ago

@EvilSocket1 I don't believe the OpenGL version matters, it's only the one you support. My card supports 4.2 like Benny's probably does aswell

noah4477 commented 10 years ago

@Kiwuser I'm running it on a GTX 770 which supports all versions and windows 8.1. I don't think it's a problem with the opengl version you support. Maybe it's the graphics driver. Someone should try to downgrade theirs and see if it works? But then again it's not working on that guys integrated graphics. So it's unlikely it's a driver problem. Maybe there's something wrong in the code we're missing that AMD cards can handle. Which means that someone has to try it on an AMD card.

alan-jak commented 10 years ago

Benny has AMD which is why it works for him, 4.2 is the latest OpenGL, which my GT555M supports, someone earlier was using an old driver and it didn't work, I tested it on a 5 month old driver and the latest one with no luck. Basically no one has any idea why it only works on AMD.

alan-jak commented 10 years ago

Correction: 4.4 is the latest version and nVidia's website confirms that 500 series plus supports it

spaarmann commented 10 years ago

I have an AMD card in my laptop, I can probably try tomorrow if it works or not for me. I'll leave another comment then.

alan-jak commented 10 years ago

That would be great. And @BennyQBD would you be willing to change the source if I created a texture class using FBOs?

Colt-Zero commented 10 years ago

Yeah... I'm still stuck on this.

I've tried making numerous tweaks in an attempt to figure out the problem. But nothing I've tried works.

Over the course of my researching I've tried messing with a number of texture parameters, but that didn't work. I tried glGenerateMipmap because I saw something suggesting to not depend on auto generated mipmaps, but that didn't work.

I've tried the other glFrameBufferTexture method, but that didn't work. I tried messing with the framebuffer parameters and of course, it didn't work.

I also saw something suggesting the use of glPushAttrib(GL_VIEWPORT_BIT), but that made no difference either.

Also, I couldn't help but notice that if I were to just simply not call the glDrawBuffers method, it would make no difference visually on what I was seeing in the window. Does that mean the glDrawBuffers method isn't working at all or something else entirely?

EvilSocket1 commented 10 years ago

"Also, I couldn't help but notice that if I were to just simply not call the glDrawBuffers method, it would make no difference visually on what I was seeing in the window. Does that mean the glDrawBuffers method isn't working at all or something else entirely?" Interesting, especially because glGetError() doesn't return an error value...

BennyQBD commented 10 years ago

You know, do you think it might be an issue with my example rather than an issue with the render to texture code itself?

alan-jak commented 10 years ago

What do you mean exactly, like something wrong with a makefile or project file? Maybe try uploading it as a zip, if you think it could be GutHub breaking it

Colt-Zero commented 10 years ago

I've got a question then. Is it possible that the texture coordinates are somehow not working right?

The result I've been getting is something akin to it picking just one pixel from the whole texture and drawing the entire rectangle with just that one pixel.

Or perhaps the framebuffer is only picking up one pixel despite everything that has been written to it.

alan-jak commented 10 years ago

That's an interesting theory - I never thought of that being a possible issue; but you're right, it does in fact look like that.

alan-jak commented 10 years ago

I do realise this - it could be that the render to texture initialises as 1 pixel square or something, instead of 200x300 or whatever it's supposed to be