From 29ebb2f6ac0628b323ad48a452c39bbb48075823 Mon Sep 17 00:00:00 2001 From: Jamie Robertson Date: Fri, 13 Dec 2024 11:19:16 +0000 Subject: [PATCH 1/4] Update PolytopeIntersector.cpp In the PolytopeInterctor constructor with screen coordinates, the eyespace polytope should have been placed in the polytope stack before the worldspace polytope (as per LineSegmentIntersector constructor). The omission meant that intersections were not calculated properly for nodes under transforms. --- src/vsg/utils/PolytopeIntersector.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/vsg/utils/PolytopeIntersector.cpp b/src/vsg/utils/PolytopeIntersector.cpp index 644896d98..c5dd48fef 100644 --- a/src/vsg/utils/PolytopeIntersector.cpp +++ b/src/vsg/utils/PolytopeIntersector.cpp @@ -229,6 +229,8 @@ PolytopeIntersector::PolytopeIntersector(const Camera& camera, double xMin, doub eyespace.push_back(pl * projectionMatrix); } + _polytopeStack.push_back(eyespace); + vsg::Polytope worldspace; for (auto& pl : eyespace) { From 8c4662876c80a9076d1263814582d220fe40acd8 Mon Sep 17 00:00:00 2001 From: AnyOldName3 Date: Thu, 14 Nov 2024 19:12:02 +0000 Subject: [PATCH 2/4] Ensure glslang include directories are specified before Vulkan SDK ones Otherwise some compilation units may use the definitions of inline glslang functions from the Vulkan SDK's copy of glslang instead of the glslang we're using, and if the necessary linker warnings aren't enabled and set as errors (they're not), this can cause ABI issues. I noticed this after encountering stack corruption in glslang::GlslangToSpv as the Vulkan SDK version 1.3.296 provides glslang 15.0.0, where glslang::SpvOptions is ten bytes, whereas I was using glslang 14.3.0, where it's only nine bytes, so initialising defaultOptions would spill one byte past the object's end. Fixing the include order ensures all TUs use the right function implementation and the linker won't randomly pick the wrong one. --- src/vsg/CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vsg/CMakeLists.txt b/src/vsg/CMakeLists.txt index 263122d5a..229faee43 100644 --- a/src/vsg/CMakeLists.txt +++ b/src/vsg/CMakeLists.txt @@ -268,7 +268,7 @@ set(LIBRARIES PUBLIC ) if (${VSG_SUPPORTS_ShaderCompiler}) - list(APPEND LIBRARIES PRIVATE glslang::glslang glslang::glslang-default-resource-limits glslang::SPIRV) + list(INSERT LIBRARIES 0 PRIVATE glslang::glslang glslang::glslang-default-resource-limits glslang::SPIRV) endif() # Check for std::atomic From 13bb7b1c1d59a3c0e86cac07e16364e08833628c Mon Sep 17 00:00:00 2001 From: AnyOldName3 Date: Thu, 7 Nov 2024 19:16:52 +0000 Subject: [PATCH 3/4] Use binary mode when writing .vsgt files We unconditionally use binary mode when reading them as we use the header to differentiate between a .vsgt and a .vsgb, and can't read the header without opening the stream first. If the stream mode is mismatched, then this can cause problems. On Unix, there are no symptoms as the only difference is whether a trailing line feed will be inserted if the file is closed and doesn't end with one - some Unices treat all files that don't end in a line feed as binary - and `AsciiOutput::write` adds one after the closing `}` anyway. On Windows, it causes a bigger problem as automatic line ending conversion only happens in text mode - binary streams read and write carriage returns and line feeds as-is, but text streams convert a CRLF sequence to just the line feed when reading and convert a lone line feed to a CRLF sequence when writing. Because of this, when reading a multiline string in a .vsgt file, like a shader listing, on Windows, the CRLF in the file would be read into memory as-is, but if the same object was written back, then the CR would be written, and then the LF would be written as CRLF, leaving CRCRLF in the file. As well as being generally gross, most software for Windows attempts to accommodate files with weird line endings, so will interpret this as a 90s Mac line ending followed by a Windows line ending, and display it as two line breaks. The alternative would be to conditionally enable binary mode after reading the header, but that would mean the stream would need to be closed and reopened, then the header skipped, which would be a nuisance. Developers writing software for Windows are generally ready to deal with explicit carriage returns in strings, so it's fine to load them. Also, this approach is consistent with the text and glsl loaders. --- src/vsg/io/VSG.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vsg/io/VSG.cpp b/src/vsg/io/VSG.cpp index 0096498fc..d03935cde 100644 --- a/src/vsg/io/VSG.cpp +++ b/src/vsg/io/VSG.cpp @@ -184,7 +184,7 @@ bool VSG::write(const vsg::Object* object, const vsg::Path& filename, ref_ptr Date: Wed, 4 Dec 2024 15:09:52 +0000 Subject: [PATCH 4/4] Don't append SPIR-V onto existing SPIR-V when recompiling shaders --- src/vsg/utils/ShaderCompiler.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/vsg/utils/ShaderCompiler.cpp b/src/vsg/utils/ShaderCompiler.cpp index 5db11cad7..717bc0a90 100644 --- a/src/vsg/utils/ShaderCompiler.cpp +++ b/src/vsg/utils/ShaderCompiler.cpp @@ -282,6 +282,7 @@ bool ShaderCompiler::compile(ShaderStages& shaders, const std::vectormodule->code.clear(); glslang::GlslangToSpv(*(program->getIntermediate((EShLanguage)eshl_stage)), vsg_shader->module->code, &logger, &spvOptions); } }