neo-mashiro / sketchpad

A simple rendering library to experiment with CG techniques in OpenGL.

Howdy! This is neo-mashiro ₍ᐢ •⌄• ᐢ₎ A C++ enthusiast with a passion for 3D Graphics and Game Dev ✨

🍃  I have lived in Shanghai, China, Texas, USA and Saitama, Japan. I currently live in Vancouver, Canada.

🍀  I speak English (fluent), Japanese (proficient), Mandarin (native) and Machine-Code (sometimes at night).

💗 About me:

• Self-educator in Computer Science, lifelong learner & ACG lover
• M.Sc in Financial Econometrics, Texas A&M University, College Station (2014)
• B.Ec in Mathematical Economics, Shanghai University of Finance & Economics (2012)

🍏 I know about:

• C/C++, Python, C#, Go, Lua, RStudio, SAS, Oracle PL/SQL, MongoDB
• Unity3D, OpenGL, GLSL, Linux, Git, Unix Shell, LaTeX, OpenCV...

🌴 I'm currently working on:

• (primary focus) Vulkan API, C++ Concurrency in Action
• (in parallel) USD Pipeline, DCC Software and Workflows
• (if time allows) Graphics Optimization, Design Patterns

🌱 To-Do list:

• Intrinsics and x86 assembly, In-depth C++, Unreal Engine 5
• Monte Carlo Path Tracing, Real-time RTX, Multi-bounce Dynamic GI
• TAA, SDF, PRT, MIS, SSS, Water & Hair Simulation, Caustics
• Particle System, Realistic Fire, Bezier Area Light ...

🍵 How to reach me:

sketchpad's Issues

OpenGL error 1282 `GL_INVALID_OPERATION`

sketchpad/src/core/app.cpp

Lines 187 to 194 in 340aa22

	void Application::PassiveMotion(int x, int y) {
	if (Window::layer == Layer::Scene) {
	Input::SetMouseMove(x, y);
	}
	else if (Window::layer == Layer::ImGui) {
	ImGui_ImplGLUT_MotionFunc(x, y);
	}
	}

sketchpad/src/core/app.cpp

Line 305 in 340aa22

glutPassiveMotionFunc(PassiveMotion);

I recently found out that this passive motion callback always gives me an GL_INVALID_OPERATION error. Every time I move my mouse, this callback is triggered as expected, but as soon as execution enters the function body, the above mentioned error occurs, even before it has time to run the first line of code. In other words, it's not my code that triggers this error, but somewhere inside the freeglut code. I don't have source code for freeglut available at the moment, nor do I know anything about how it schedules callback events under the hood.

Fortunately, this issue hasn't caused any problems so far. I'm able to render everything correctly even without awareness of this error. I highly suspect that it's a bug in freeglut or on the driver side, but for now it seems OK to just leave it unattended, I will probably upgrade and migrate to use GLFW soon...

`glDebugMessageCallback()` is not always triggered as expected

the glDebugMessageCallback() is sometimes not triggered when OpenGL error occurs, but it does work some other times...... I've researched on this issue but still sort of clueless, however there is a thread saying that the GLEW library may not be supporting it well, I'll try to use GLAD instead at a later time and see if the issue would persist.

[Memo] List of functions/features not working as expected

Tested on Windows 10 in debug mode with 2021 latest drivers for

• GeForce GTX 1080 Ti
• Intel® UHD Graphics 620
• Radeon™ RX 540

Release build is run on Radeon™ RX 580 and is not tested. (because it's not my graphics card)

glNamedFramebufferTextureLayer

On AMD card this works fine with cubemap textures (setting one face to be the framebuffer render target), but my Intel UHD 620 generates a error on this call, probably a driver issue. There seems to be another function called glNamedFramebufferTextureFace, what does that do? Similar post:
https://community.intel.com/t5/Graphics/glNamedFramebufferTextureLayer-rejects-cubemaps-of-any-kind/m-p/1337935#M103221

glBlitNamedFramebuffer

This one works correctly on AMD and Nvidia card, but on Intel it only works well with simple framebuffers. The result of resolving multisampled framebuffers on Intel card gives super weird result. Similar post:
https://stackoverflow.com/questions/14469569/opengl-fbo-blitting-inconsistent-between-intel-and-nvidia

glClientWaitSync

As per OpenGL 4.5 spec, this function takes in a parameter GLuint64 timeout which is measured in nanoseconds though it might not have nanosecond accuracy. While the blocking behavior is correctly observed, it seems that the timeout on my AMD card is really measured in microseconds instead. I've measured the time in my console log, for example, when this call reports a total of 3ms timeout (incremented in a loop), the real physical time elapsed is 3 seconds, the timeout is always 1000 times smaller. On Intel and Nvidia GTX card, timeout is in nanoseconds as expected.

Compute shaders

When I have a slightly heavy-duty compute shader, the program hangs on the AMD card but works fine on Intel 620 and GTX 1080t card. The problem can be solved by simply reducing the amount of computation (e.g. iterations) in the compute shader. Sometimes the hang also happens to the fragment shader, sometime the app crashes and the Radeon manager will detect a driver timeout. AMD driver timeout and crashes is a known issue reported by many people, especially after the 2021 windows 10 updates. Some references:
https://www.reddit.com/r/Amd/comments/mj0vhb/driver_timeout_issues_on_2132/
https://www.reddit.com/r/Amd/comments/mym8xb/possible_solution_if_you_are_experiencing_driver/
https://www.reddit.com/r/AMDHelp/comments/o93kro/amd_driver_timeout_ongoing_for_the_last_six/