Render to texture not working about 3denginecpp HOT 89 CLOSED

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

from 3denginecpp.

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.

from 3denginecpp.

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?)

from 3denginecpp.

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?

from 3denginecpp.

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

from 3denginecpp.

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.

from 3denginecpp.

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.

from 3denginecpp.

(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.

from 3denginecpp.

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.

from 3denginecpp.

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"

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

I have an "Intel HD Graphics 4000"

from 3denginecpp.

@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!

from 3denginecpp.

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.

from 3denginecpp.

Still having the grey screen :/

GeForce GTX 750 Ti nvidia_blob: 337.12

from 3denginecpp.

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

from 3denginecpp.

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

from 3denginecpp.

@EvilSocket1 Does the latest update fix it for you?

from 3denginecpp.

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

from 3denginecpp.

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

from 3denginecpp.

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

from 3denginecpp.

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

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

Nope... Still not working for me.

from 3denginecpp.

Still not working for me either

from 3denginecpp.

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:

• http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/
• http://ogldev.atspace.co.uk/www/tutorial23/tutorial23.html
• http://ogldev.atspace.co.uk/www/tutorial35/tutorial35.html

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

Cheers,
Benny

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

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.

from 3denginecpp.

@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?

from 3denginecpp.

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

from 3denginecpp.

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.

from 3denginecpp.

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.

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

@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

from 3denginecpp.

@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.

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

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?

from 3denginecpp.

"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...

from 3denginecpp.

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

from 3denginecpp.

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

from 3denginecpp.

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.

from 3denginecpp.

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.

from 3denginecpp.

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

from 3denginecpp.

@KIWUser
you are posting the "header" of the email you are replying to and this reveals your email address, maybe this is not what you intended! Maybe you visit the github page and edit your post.

from 3denginecpp.

I honestly don't care, I barely use this email anymore, and since my school blocks GitHub, this is my only way to send messages, I actually don't know what it looks like, can you possibly take a screenshot so I can see what you mean?

from 3denginecpp.

It's fine. But that is an interesting theory, is there any way to prove it?

from 3denginecpp.

@KIWUser http://s1.directupload.net/images/140508/quxbc3t9.png

from 3denginecpp.

My phone won't let me fix it, wait an hour until I have lunch, I'll use hotspot and fix it

from 3denginecpp.

All done thanks to sneakily turning on hotspot in the middle of class :)

from 3denginecpp.

This is interesting.

I decided to test this out by putting in some code to test the width and height of the texture that is bound at the moment before you draw the rectangle mesh.

Its reporting that the texture is only 16 x 16 pixels, to spite the fact that it should be bigger.

This is the code that I'm using to test the width and height

GLint width[1];
GLint height[1];
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, width);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_HEIGHT, height);
printf("Width: %d Height: %d \n", width[0], height[0]);

from 3denginecpp.

I'm reading 800 and 600

from 3denginecpp.

So when you have your code like this, your getting 800 by 600?

m_defaultShader->Bind();
m_defaultShader->UpdateUniforms(g_transform, *g_material, this);
GLint width[1];
GLint height[1];
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, width);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_HEIGHT, height);
printf("Width: %d Height: %d \n", width[0], height[0]);
g_mesh->Draw();

from 3denginecpp.

I do read 16 there but inside the TextureData::initrender function I get 800 and 600. But even if it was reading just 16 by 16 pixels we would see more than just one color on the screen.
Update: I set the color of the directionalLight to be green and set the intensity really high. The result was the render to texture area being all green. This proves that the render to texture functionality is working, but it seems like the Framebuffer is a very small resolution or something? I don't really know. Someone with more knowledge of OpenGL should look into this issue more.
Look at https://github.com/BKcore/JungleIN/blob/master/trunk/src/render/framebuffer.cpp
It seems like it's very similar to what Benny has and it may solve some things. I'll look into it tomorrow when I get a chance.

from 3denginecpp.

Oooh... Your right, that does look like it could prove to be helpful. But much like you, I can't do it tonight either.

Sigh... I wanna get back to working on my other project, but this problem has had me going and circles and keeps leaving me rather exhausted. And my seemingly chronic sinus headaches aren't exactly helping on that front.

from 3denginecpp.

Okay, I tested on an AMD 6370M and it works just fine. So it probably is something that only works on AMD.

from 3denginecpp.

Interesting update. I think its sort of working now. Its just drawing something very weird. I used http://www.songho.ca/opengl/gl_fbo.html to experiment with it. Also someone please tell me how to properly write githut code this is driving me crazy.

#include "renderingEngine.h"
#include "window.h"
#include "gameObject.h"
#include "shader.h"
#include <GL/glew.h>
#define TEXTURE_WIDTH 512
#define TEXTURE_HEIGHT 512
#define screenWidth 800
#define screenHeight 600
GLuint textureId;
RenderingEngine::RenderingEngine()
{
m_samplerMap.insert(std::pair<std::string, unsigned int>("diffuse", 0));
m_samplerMap.insert(std::pair<std::string, unsigned int>("normalMap", 1));
m_samplerMap.insert(std::pair<std::string, unsigned int>("dispMap", 2));
AddVector3f("ambient", Vector3f(0.1f, 0.1f, 0.1f));
m_defaultShader = new Shader("forward-ambient");
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);

glFrontFace(GL_CW);
glCullFace(GL_BACK);
glEnable(GL_CULL_FACE);
glEnable(GL_DEPTH_TEST);
glEnable(GL_DEPTH_CLAMP);
 // create a texture object
glGenTextures(1, &textureId);
glBindTexture(GL_TEXTURE_2D, textureId);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
//glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
//glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
//glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE); // automatic mipmap generation included in OpenGL v1.4
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, TEXTURE_WIDTH, TEXTURE_HEIGHT, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
glBindTexture(GL_TEXTURE_2D, 0);
glGenFramebuffers(1, &fboId);
glBindFramebuffer(GL_FRAMEBUFFER, fboId);

    // create a renderbuffer object to store depth info
    // NOTE: A depth renderable image should be attached the FBO for depth test.
    // If we don't attach a depth renderable image to the FBO, then
    // the rendering output will be corrupted because of missing depth test.
    // If you also need stencil test for your rendering, then you must
    // attach additional image to the stencil attachement point, too.
    glGenRenderbuffers(1, &rboId);
    glBindRenderbuffer(GL_RENDERBUFFER, rboId);
    glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, TEXTURE_WIDTH, TEXTURE_HEIGHT);
    glBindRenderbuffer(GL_RENDERBUFFER, 0);

    // attach a texture to FBO color attachement point
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, textureId, 0);

    // attach a renderbuffer to depth attachment point
    glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, rboId);
    glBindFramebuffer(GL_FRAMEBUFFER, 0);

}

RenderingEngine::~RenderingEngine()
{
if(m_defaultShader) delete m_defaultShader;
}
void draw()
{
glBindTexture(GL_TEXTURE_2D, textureId);

glColor4f(1, 1, 1, 1);
glBegin(GL_TRIANGLES);
    // front faces
    glNormal3f(0,0,1);
    // face v0-v1-v2
    glTexCoord2f(1,1);  glVertex3f(1,1,1);
    glTexCoord2f(0,1);  glVertex3f(-1,1,1);
    glTexCoord2f(0,0);  glVertex3f(-1,-1,1);
    // face v2-v3-v0
    glTexCoord2f(0,0);  glVertex3f(-1,-1,1);
    glTexCoord2f(1,0);  glVertex3f(1,-1,1);
    glTexCoord2f(1,1);  glVertex3f(1,1,1);

    // right faces
    glNormal3f(1,0,0);
    // face v0-v3-v4
    glTexCoord2f(0,1);  glVertex3f(1,1,1);
    glTexCoord2f(0,0);  glVertex3f(1,-1,1);
    glTexCoord2f(1,0);  glVertex3f(1,-1,-1);
    // face v4-v5-v0
    glTexCoord2f(1,0);  glVertex3f(1,-1,-1);
    glTexCoord2f(1,1);  glVertex3f(1,1,-1);
    glTexCoord2f(0,1);  glVertex3f(1,1,1);

    // top faces
    glNormal3f(0,1,0);
    // face v0-v5-v6
    glTexCoord2f(1,0);  glVertex3f(1,1,1);
    glTexCoord2f(1,1);  glVertex3f(1,1,-1);
    glTexCoord2f(0,1);  glVertex3f(-1,1,-1);
    // face v6-v1-v0
    glTexCoord2f(0,1);  glVertex3f(-1,1,-1);
    glTexCoord2f(0,0);  glVertex3f(-1,1,1);
    glTexCoord2f(1,0);  glVertex3f(1,1,1);

    // left faces
    glNormal3f(-1,0,0);
    // face  v1-v6-v7
    glTexCoord2f(1,1);  glVertex3f(-1,1,1);
    glTexCoord2f(0,1);  glVertex3f(-1,1,-1);
    glTexCoord2f(0,0);  glVertex3f(-1,-1,-1);
    // face v7-v2-v1
    glTexCoord2f(0,0);  glVertex3f(-1,-1,-1);
    glTexCoord2f(1,0);  glVertex3f(-1,-1,1);
    glTexCoord2f(1,1);  glVertex3f(-1,1,1);

    // bottom faces
    glNormal3f(0,-1,0);
    // face v7-v4-v3
    glTexCoord2f(0,0);  glVertex3f(-1,-1,-1);
    glTexCoord2f(1,0);  glVertex3f(1,-1,-1);
    glTexCoord2f(1,1);  glVertex3f(1,-1,1);
    // face v3-v2-v7
    glTexCoord2f(1,1);  glVertex3f(1,-1,1);
    glTexCoord2f(0,1);  glVertex3f(-1,-1,1);
    glTexCoord2f(0,0);  glVertex3f(-1,-1,-1);

    // back faces
    glNormal3f(0,0,-1);
    // face v4-v7-v6
    glTexCoord2f(0,0);  glVertex3f(1,-1,-1);
    glTexCoord2f(1,0);  glVertex3f(-1,-1,-1);
    glTexCoord2f(1,1);  glVertex3f(-1,1,-1);

glEnd();

glBindTexture(GL_TEXTURE_2D, 0);

}
void RenderingEngine::Render(GameObject* object)
{
glViewport(0, 0, TEXTURE_WIDTH, TEXTURE_HEIGHT);
glBindFramebuffer(GL_FRAMEBUFFER, fboId);
glClearColor(0,0,0,0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
object->RenderAll(m_defaultShader, this);

glEnable(GL_BLEND);
glBlendFunc(GL_ONE, GL_ONE);
glDepthMask(GL_FALSE);
glDepthFunc(GL_EQUAL);

for(unsigned int i = 0; i < m_lights.size(); i++)
{
    m_activeLight = m_lights[i];
    object->RenderAll(m_activeLight->GetShader(), this);
}

glDepthMask(GL_TRUE);
glDepthFunc(GL_LESS);
glDisable(GL_BLEND);
glBindFramebuffer(GL_FRAMEBUFFER, 0);
glBindTexture(GL_TEXTURE_2D, textureId);
    glGenerateMipmap(GL_TEXTURE_2D);
    glBindTexture(GL_TEXTURE_2D, 0);
glViewport(0, 0, screenWidth, screenHeight);
glClearColor(0, 0, 0, 0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
 draw();

}

from 3denginecpp.

I asked several people knowing OpenGL for a long time and none of them knows why this could possibly happen. I tried to debug the code, but yeah, it just seems to happen...

from 3denginecpp.

I feel the need to apologize, but I haven't been able to work on this for the past several days. I wasn't feeling all that well and I couldn't really focus on any of the work I've been doing.

So yeah.... I haven't been able to solve this issue yet.

Edit: Also um... I'm currently dealing with my pets. My dog is sad because my mom is not here so she's laying on my lap. And one of my cats has taken roost on my desk.

from 3denginecpp.

This issue should probably be closed off as fixed as originally it was a compilation problem around dynamic arrays in Visual Studio. This has since been resolved in the latest commits and the new issue is around rendering to a texture, specifically on nVidia graphics cards.

from 3denginecpp.

The issue is not just nVidia, but also Intel, and this issue is about the grey render to texture as well, as seen in the original issue.

from 3denginecpp.

The texture size of 16x16 is because in the updateUniforms function of the shader textures are bound.

from 3denginecpp.

@KIWUser it should still have been split in to two issues. The first being that it wouldn't compile in Visual Studio (due to the array issue) and the second being the more prominent problem where the texture is not rendering correctly on some cards.

from 3denginecpp.

It could be split into 2 issues, but there's been too much conversation on this issue, so it would be pointless to start a new one.

from 3denginecpp.

We have to solve the issue, not argue where it belongs. Also people might think this issue has been solved if we'd close this.

from 3denginecpp.

At least edit the post then as the title is completely misleading for anyone who hasn't been involved so far.

from 3denginecpp.

That would also be true, so has anyone tried anything new?

from 3denginecpp.

Like I said: "The texture size of 16x16 is because in the updateUniforms function of the shader textures are bound."

from 3denginecpp.

void TextureData::BindAsRenderTarget()
{
    glBindTexture(GL_TEXTURE_2D, 0);
    glBindFramebuffer(GL_FRAMEBUFFER, m_frameBuffer);
    glViewport(0, 0, m_width, m_height);
}

Shouldn't that be:

void TextureData::BindAsRenderTarget()
{
    this->Bind(0);
    glBindFramebuffer(GL_FRAMEBUFFER, m_frameBuffer);
    glViewport(0, 0, m_width, m_height);
}

from 3denginecpp.

I haven't been able to fix it, but I think I'm getting close. Someone else should try to fix it, I won't be able to really and sit down and attempt to fix it for a while. Also we should probably delete the conversations when we finally fix it so people don't have to read all these comments.

from 3denginecpp.

hBdq, that's good thinking, but it is supposed to be as it is. The reason is OpenGL doesn't allow textures to be bound as a texture and as a render target at the same time. Binding texture 0 is supposed to ensure that the texture isn't bound.

Now that you've brought it up however, I realize that it doesn't ensure the texture isn't bound because it doesn't unbind it from every active texture. I don't think that's causing this issue, but if someone reading this is experiencing the issue, it might be worth trying looping through all 32 texture units and binding nothing to them before binding the framebuffer.

from 3denginecpp.

@BennyQBD as suspected that wasn't the cause of the issue unfortunately

from 3denginecpp.

Oh, wow! Whatever Benny changed in the latest update to this repository seems to have made render to texture work for me.

I suggest you all test the latest version of this repository and see if it works for you.

from 3denginecpp.

As default the project now renders the original scene to full window size. This is just using the Window as a render target and not rendering to a texture. When I try to put back in rendering to a texture (at a smaller size and clearing the window to blue to see a background change) it doesn't work.

Perhaps I have the render to texture code wrong now though.

from 3denginecpp.

@Zammalad
This is my proof that the latest repository, when left "as is", does in fact work for me.

from 3denginecpp.

If you mean mentioning them, type @ then it will suggest names of the people in this issue.

from 3denginecpp.

@Colt-Zero You're right. It works.

@Zammalad

#include "renderingEngine.h"
#include "window.h"
#include "gameObject.h"
#include "shader.h"
#include <GL/glew.h>
#include "mesh.h"
#include <cstring>

RenderingEngine::RenderingEngine()
{
    m_samplerMap.insert(std::pair<std::string, unsigned int>("diffuse", 0));
    m_samplerMap.insert(std::pair<std::string, unsigned int>("normalMap", 1));
    m_samplerMap.insert(std::pair<std::string, unsigned int>("dispMap", 2));

    SetVector3f("ambient", Vector3f(0.2f, 0.2f, 0.2f));
    m_defaultShader = new Shader("forward-ambient");

    glClearColor(0.0f, 0.0f, 0.0f, 0.0f);

    glFrontFace(GL_CW);
    glCullFace(GL_BACK);
    glEnable(GL_CULL_FACE);
    glEnable(GL_DEPTH_TEST);
    glEnable(GL_DEPTH_CLAMP);

    m_altCamera = new Camera(Matrix4f().InitIdentity());
    m_altCameraObject = (new GameObject())->AddComponent(m_altCamera);
    m_altCamera->GetTransform().Rotate(Vector3f(0,1,0),ToRadians(180.0f));

    int width = Window::GetWidth();
    int height = Window::GetHeight();

    m_tempTarget = new Texture(width / 5, height / 5, 0, GL_TEXTURE_2D, GL_NEAREST, GL_RGBA, GL_RGBA, false, GL_COLOR_ATTACHMENT0);

    m_planeMaterial = new Material(m_tempTarget, 1, 8);
    m_planeTransform.SetScale(1.0f);
    m_planeTransform.Rotate(Quaternion(Vector3f(1,0,0), ToRadians(90.0f)));
    m_planeTransform.Rotate(Quaternion(Vector3f(0,0,1), ToRadians(180.0f)));
    m_plane = new Mesh("./res/models/plane.obj");
}

RenderingEngine::~RenderingEngine() 
{
    if(m_defaultShader) delete m_defaultShader;
    if(m_altCameraObject) delete m_altCameraObject;
    if(m_planeMaterial) delete m_planeMaterial;
    if(m_plane) delete m_plane;
}

void RenderingEngine::Render(GameObject* object)
{
    m_tempTarget->BindAsRenderTarget();

    glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    object->RenderAll(m_defaultShader, this);

    glEnable(GL_BLEND);
    glBlendFunc(GL_ONE, GL_ONE);
    glDepthMask(GL_FALSE);
    glDepthFunc(GL_EQUAL);

    for (unsigned int i = 0; i < m_lights.size(); i++)
    {
        m_activeLight = m_lights[i];
        object->RenderAll(m_activeLight->GetShader(), this);
    }

    glDepthMask(GL_TRUE);
    glDepthFunc(GL_LESS);
    glDisable(GL_BLEND);

    //Temp Render
    Window::BindAsRenderTarget();

    Camera* temp = m_mainCamera;
    m_mainCamera = m_altCamera;

    glClearColor(0.0f, 0.0f, 0.5f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    m_defaultShader->Bind();
    m_defaultShader->UpdateUniforms(m_planeTransform, *m_planeMaterial, this);
    m_plane->Draw();

    m_mainCamera = temp;
}

This should render the scene in the full window but with very low resolution.

@BennyQBD Your new commits seem to fix the render to text issue.

from 3denginecpp.

@Colt-Zero that code is not left as is, you must have modified something, please be more specific as to what you un-commented or added.

@EvilSocket1 I'd like to see it working as it was in the actual tutorial though to be sure and not just assuming it is working. A low resolution render of the scene at full size isn't the same as rendering to texture.

from 3denginecpp.

@Zammalad It is rendering to small texture and using that texture as a diffuse texture for a mesh. Look at the code, it is definitly rendering to a texture.

from 3denginecpp.

@Zammalad

I only changed a couple of things. Very small stuff really.

I turned the render to texture code in the rendering function back on.I resized the render to texture plane so that it didn't occupy the full window. And I switched one of the plane's in the scene to the monkey head model, so that there could be more distinction between the scene Benny was rendering in the video and the scene I was rendering.

from 3denginecpp.

I'm assuming this problem is solved for everyone.

from 3denginecpp.

So what was the issue and how was it fixed?

//EDIT:
Ok after a while i figured it out. I can not really explain why but i can point to the place in code where it happens. So anybody follow along with the tutorial (and perhaps coding in another language) can solve this issue without doing blind git pull from the cpp git repository and hoping it is somewhat solved. All this issue has to do with creation of the plane primitive in the rendering engine, where we want to draw the texture on. here is the code in question https://github.com/BennyQBD/3DEngineCpp/blob/3643710fe242b8381e5e59ed50e723cba1b44c76/3DEngineCpp/renderingEngine.cpp

line 50-57:

Vertex vertices[] = { Vertex(Vector3f(-1,-1,0),Vector2f(1,0)),
                          Vertex(Vector3f(-1,1,0),Vector2f(1,1)),
                          Vertex(Vector3f(1,1,0),Vector2f(0,1)),
                          Vertex(Vector3f(1,-1,0),Vector2f(0,0)) };

int indices[] = { 2, 1, 0,
                      3, 2, 0 };

and creating a mesh from it on line 60;

g_mesh = new Mesh(vertices, sizeof(vertices)/sizeof(vertices[0]), indices, sizeof(indices)/sizeof(indices[0]), true);

this is causing the strange effect one can see in the original post. Perhaps it has something to do with the texture coordinates.. i really don't know. But the only thing you have to do to make this running is to load a mesh with – i think that's the reason – with proper texture coordinates. If you choose the Monkey or the Box .. or any other object it automagically works. this is what the code in the later commits makes it work e.g.

https://github.com/BennyQBD/3DEngineCpp/blob/4b6ee5dd84fad7a476926a41f34fad6ab542d582/3DEngineCpp/renderingEngine.cpp
line 39:

m_plane = new Mesh("./res/models/plane.obj");

I hope someone find this useful.

from 3denginecpp.

The whole -gray/brown/what have you- plane issue has in my opinion little to do with hardware.
I found out that when you don't use assimp for setting up the mesh where the scene will be rendered to, like Benny does in this tutorial, you just calculate the tangents and adjoin them as a vertex attribute: problem solved! I think the problem is caused by a badly shaped tbn matrix messing up the texture coordinates in the shaders (this matrix will be filled with zero tangent vectors from the default constructor, unless you calculate them). You can find the function which is responsible for doing this tangent calculations on GitHub,...somewhere in the mesh class. Here's some example of the rendering to texture scene, not using assimp (assimp will do this calculuation for you automatically). I rotated the camera a bit as you can see:

Peter

from 3denginecpp.