Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Dec 2005
Offline Last Active Aug 30 2012 04:05 AM

Posts I've Made

In Topic: GLSL-PingPong-Rendering - strange performance issue

30 August 2012 - 03:39 AM

Thank you, calling glFinish() after rendering the quad made it run fast so that I don't need the glReadPixels-hack anymore! Seems like glReadPixels does something like glFinish internally.

(btw. Putting glGetError at locations behind context creation also removed any gl-errors Posted Image )

I'm also wondering what you mean by "submitting the results to GPU", if you never read back the texture data to CPU won't you just keep working on the same data? The piece of code you commented as submitting the results just binds another texture.

I'm not deep into that but I think it's like this:
The texture data doesn't need to be transferred to the CPU, since after rendering the quad the data is inside the texture memory on GPU - binding the texture and sending the texture unit via glUniform to the shader allows accessing the texture memory on GPU where the texture data still is.
(Is that right?)

In Topic: GLSL-PingPong-Rendering - strange performance issue

29 August 2012 - 01:03 PM

Oh sorry, I didnt... I was just checking for glsl errors...
What could it mean that i got an invalid operation error (0x502) at the very beginning of my Program?

[source lang="cpp"]int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd){ checkErr(); // GL_INVALID_OPERATION !!!!!!!! MSG msg = {0}; WNDCLASSEX wcl = {0}; wcl.cbSize = sizeof(wcl); wcl.style = CS_OWNDC | CS_HREDRAW | CS_VREDRAW; wcl.lpfnWndProc = WindowProc; wcl.cbClsExtra = 0; wcl.cbWndExtra = 0; wcl.hInstance = g_hInstance = hInstance; wcl.hIcon = LoadIcon(0, IDI_APPLICATION); wcl.hCursor = LoadCursor(0, IDC_ARROW); wcl.hbrBackground = 0; wcl.lpszMenuName = MAKEINTRESOURCE(MENU_FIXED_FUNC); wcl.lpszClassName = "GLWindowClass"; wcl.hIconSm = 0; if (!RegisterClassEx(&wcl)) return 0;......[/source]

In Topic: Photon Mapping : multiple Lights / one global map

15 December 2005 - 11:59 PM

I just found the bug... Something really stupid... I assumed that max_phot in the constructor of the Photon_map class would be the same number of emitted photon, what results in loosing information of one light source, if more than max_phot would be saved. That's why the error ocured only when I used indirect Lighting.
Thanks anyway for reading, I really thought it would be something more complicated.