-
Notifications
You must be signed in to change notification settings - Fork 0
build: add appropriate compile flags to cmake presets #34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5 files reviewed, 2 comments
| alignas(16) glm::vec4 diffuseColor; // RGB + alpha | ||
| alignas(16) glm::vec4 emissiveColor; // RGB + intensity | ||
| alignas(16) glm::vec4 specularColor; // RGB + shininess | ||
| alignas(16) glm::vec3 hoverTint; // RGB tint for hover highlighting (1,1,1 = no tint) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potential shader layout mismatch: vec3 in std140 layout takes 12 bytes but following fields may not align correctly. In GLSL push constants, after a vec3 at offset 48, the next field starts at offset 60. The C++ alignas(4) on flags may not match this layout, potentially causing the shader to read wrong values.
Consider using vec4 instead of vec3 for hoverTint, or verify the struct size matches expected shader layout (should be 76 bytes total).
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/core/pipeline.hpp
Line: 71:71
Comment:
Potential shader layout mismatch: `vec3` in std140 layout takes 12 bytes but following fields may not align correctly. In GLSL push constants, after a `vec3` at offset 48, the next field starts at offset 60. The C++ `alignas(4)` on `flags` may not match this layout, potentially causing the shader to read wrong values.
Consider using `vec4` instead of `vec3` for `hoverTint`, or verify the struct size matches expected shader layout (should be 76 bytes total).
How can I resolve this? If you propose a fix, please make it concise.| // Store CPU copies for ray-triangle intersection | ||
| gpu.cpuVertices = subMesh.vertices; | ||
| gpu.cpuIndices = subMesh.indices; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Storing full CPU-side copies doubles mesh memory usage. Consider building a simplified collision mesh (e.g., just positions, no normals/UVs) if memory becomes a concern for large models.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/render/renderable_mesh.cpp
Line: 43:45
Comment:
Storing full CPU-side copies doubles mesh memory usage. Consider building a simplified collision mesh (e.g., just positions, no normals/UVs) if memory becomes a concern for large models.
<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>
How can I resolve this? If you propose a fix, please make it concise.|
Closed in favor of #36 |
Greptile Overview
Greptile Summary
This PR fixes Windows shader compilation issues and adds a complete mouse hover detection system for meshes and skeleton bones.
Windows Shader Fix:
CMakeLists.txtandEmbedShaders.cmaketo avoid Windows command-line length limits[[maybe_unused]]attribute to suppress warnings when no shaders are presentHover Detection Feature:
raycast.cpp/hpp) with triangle, sphere, and line segment intersection algorithmsHoverDetectorclass to manage hover state and test against scene geometryraycast_test.cpp) with 100% coverage of intersection algorithmsBuild Improvements:
-O0 -gfor debug,-O3for release on GCC/Clang)/O2 /GLfor release with/LTCGlink-time optimization)Notes:
Confidence Score: 4/5
Important Files Changed