- This topic has 3 replies, 2 voices, and was last updated 1 month, 2 weeks ago by
.
-
Hi,
1) There might be some inconsistencies in the code that detect WebGL extensions, because we have not blacklisted any of those. Moreover, these are used extensively to implement HDR rendering and image-based lighting in Verge3D.
2) Unfortunately, Verge3D and Three.js code bases diverged a lot since r122 when the last sync was performed. API differences are not so significant, but still might require refactoring of the apps being ported from Three.js to Verge.
2) Unfortunately, Verge3D and Three.js code bases diverged a lot since r122 when the last sync was performed. API differences are not so significant, but still might require refactoring of the apps being ported from Three.js to Verge.
Additionally, I used AI to analyze the required Three.js version or any hard requirements.
1. Hard Requirement: Three.js r126+ (Critical for Async Readback)
Issue: Missing renderer.readRenderTargetPixelsAsync
Technical Detail: Spark and most modern Gaussian Splatting (3DGS) renderers rely on GPU-based sorting. This process requires reading sorted index data from the GPU back to the CPU (or handling it via Transform Feedback). To maintain high FPS without freezing the main thread, an asynchronous readback API is mandatory.
The Gap: This specific API (readRenderTargetPixelsAsync) was introduced in Three.js r126.
Current Status: Verge3D 4.1.1 is based on r122, which completely lacks this API. Consequently, Spark crashes immediately unless a heavy (and slow) synchronous polyfill is manually injected.
2. LOD Feature Requirements: Three.js r152+ (Highly Recommended)
Issue: Inefficient Buffer Updates & Legacy Loader Logic
Context: The module @sparkjsdev/spark (LOD version) relies on advanced geometry handling, likely utilizing logic similar to dynamic InstancedMesh updates or the newer BatchedMesh paradigms found in recent Three.js versions.
Buffer Handling: Efficient LOD switching requires frequent updates to InstancedBufferAttribute. While addUpdateRange exists in r122, the underlying WebGL 2.0 bufferSubData optimization is significantly more mature in r126+.
Texture Compression: Spark LOD often utilizes .spz or .sogs file formats. The KTX2Loader and TextureUtils required to handle the textures for these formats are much more stable and efficient in r140+. Using r122 risks performance bottlenecks or decoding errors.
3. WebGL 2.0 Core Support Issues
Issue: “False Negatives” on Extension Checks
Requirement: Spark explicitly requires a WebGL 2.0 environment.
The Gap: Older versions of Three.js (like r122) treat WebGL 2.0 features inconsistently. Specifically, features that were promoted to Core in WebGL 2.0 (such as OES_standard_derivatives or EXT_shader_texture_lod) are often still checked as “Extensions” by the engine.
Consequence: Since these are Core features in WebGL 2, gl.getExtension() returns null, leading the engine to falsely report that the feature is missing.
Comparison: Modern Three.js (r160+) automatically detects the WebGL 2 context and skips these redundant extension checks, ensuring native features are correctly utilized.“The above diagnosis and assumptions may not be entirely accurate. The Verge3D team has made significant efforts in supporting newer 3D software versions, and we also look forward to their continued progress in keeping up with newer Three.js releases, which is crucial for the development of the entire ecosystem.”
- You must be logged in to reply to this topic.