1. 15 10月, 2021 2 次提交
    • I
      docs: fix redirect condition for *BufferGeometry (#22680) · e9ee6672
      inokawa 提交于
      e9ee6672
    • S
      WebGPU and NodeMaterial: WGSL Support (#22688) · ceb6a137
      sunag 提交于
      * WebGPURenderPipeline: Use attributes location defined by NodeMaterial
      
      * cleanup
      
      * update to unique flow
      
      * WebGPU: Rewrite GLSL to WGSL and remove GLSL support and libs
      
      * Delete unneeded nodes
      
      * Delete ShaderLib.js
      
      * NodeBuilder: Entire flow approach to generate code without ShaderLib
      
      * NormalMapNode: Move workaround Adreno to JIT approach in ShaderNode
      
      * Remove getContextValue and setContextValue
      
      * ExpressionNode: void support
      
      * NodeKeywords: Is now dynamic, use ShaderNode if possible
      
      * ShaderNode: more swizzle support and keywords
      
      * Nodes: Revision
      
      * update examples
      
      * WebGLRenderer: add .isWebGLRenderer property
      ceb6a137
  2. 14 10月, 2021 2 次提交
  3. 13 10月, 2021 4 次提交
  4. 12 10月, 2021 3 次提交
  5. 11 10月, 2021 2 次提交
  6. 10 10月, 2021 1 次提交
  7. 08 10月, 2021 9 次提交
    • M
      812647f6
    • M
      Updated examples builds · 38d0b96b
      Mr.doob 提交于
      38d0b96b
    • M
      Updated builds. · 9ce2215b
      Mr.doob 提交于
      9ce2215b
    • S
      NodeMaterial: NodeParser and GLSLNodeParser (#22641) · ac3ce471
      sunag 提交于
      * GLSLNodeParser
      
      * NodeFunctionInput: add .isConst property and remove .isCount
      
      * NodeFunctionInput: change signature
      ac3ce471
    • T
      TDSLoader: remove readString maxLength (#22651) · 14250fa7
      Thomas Zeugner 提交于
      * TDSLoader: remove readString maxLength
      
      * removed readString maxLength that is not defined by 3ds spec
      * clean up code
      
      * Update TDSLoader.js
      
      fix syntax error
      
      * Update TDSLoader.js
      
      fix let -> const
      14250fa7
    • R
      Fix clipping in webgl2_materials_texture3d (#22649) · be3e3d20
      Rodrigo Schuller 提交于
      * Fix clipping in webgl2_materials_texture3d
      
      The camera position was too close to the 3D texture, causing clipping
      from certain angles.
      
      * Adjust frustrum and camera position
      
      Move the object to the middle of the frustrum and make the depth of the
      frustrum bigger.
      
      * Disable pan and adjust camera
      
      Disable pan, move camera to -64, -64, 128 and restore original frustum.
      be3e3d20
    • D
      lighter getProgramCacheKey when using RawShaderMaterials (#22650) · 20e2e54f
      Dave Buchhofer 提交于
      * lighter getProgramCacheKey when using RawShaderMaterials
      
      The gist of the problem: each new material instance gets run through this getProgramCacheKey function to see if three needs to build a program for that, or to connect a reference to an existing program.
      
      The getProgramCacheKey function is ‘ok’ for built in shaders, but it has a pretty huge allocation for custom shaders, by way of making the key out of concatenating the full strings of the fragment/vertex shaders.
      
      This wasn’t too much of an issue as long as the materials can be set up front, as it was a one time cost during load, but I'm noticing that with 3d-tiles based streaming, our current method of creating unique ShaderMaterial per tile, each new tile shown is a pretty large memory allocation, and for larger tilesets, where it’s possible to view thousands of tiles over time, this adds up to a healthy amount of GC pressure.
      
      * lighter getProgramCacheKey when using RawShaderMaterials
      
      The gist of the problem: each new material instance gets run through this getProgramCacheKey function to see if three needs to build a program for that, or to connect a reference to an existing program.
      
      The getProgramCacheKey function is ‘ok’ for built in shaders, but it has a pretty huge allocation for custom shaders, by way of making the key out of concatenating the full strings of the fragment/vertex shaders.
      
      This wasn’t too much of an issue as long as the materials can be set up front, as it was a one time cost during load, but I'm noticing that with 3d-tiles based streaming, our current method of creating unique ShaderMaterial per tile, each new tile shown is a pretty large memory allocation, and for larger tilesets, where it’s possible to view thousands of tiles over time, this adds up to a healthy amount of GC pressure.
      
      * lighter getProgramCacheKey when using RawShaderMaterials
      
      The gist of the problem: each new material instance gets run through this getProgramCacheKey function to see if three needs to build a program for that, or to connect a reference to an existing program.
      
      The getProgramCacheKey function is ‘ok’ for built in shaders, but it has a pretty huge allocation for custom shaders, by way of making the key out of concatenating the full strings of the fragment/vertex shaders.
      
      This wasn’t too much of an issue as long as the materials can be set up front, as it was a one time cost during load, but I'm noticing that with 3d-tiles based streaming, our current method of creating unique ShaderMaterial per tile, each new tile shown is a pretty large memory allocation, and for larger tilesets, where it’s possible to view thousands of tiles over time, this adds up to a healthy amount of GC pressure.
      Co-authored-by: NDave Buchhofer <buchhofer@matterport.com>
      20e2e54f
    • M
      3abe68b7
    • M
      Removed DeviceOrientationControls. (#22654) · 1642cdf7
      Michael Herzog 提交于
      1642cdf7
  8. 07 10月, 2021 3 次提交
  9. 06 10月, 2021 6 次提交
  10. 05 10月, 2021 8 次提交