Troika: 텍스트 개요

색상을 지정할 수만 있다면 내가 원하는 것은 debugSDF 플래그로 수행될 수 있을 것 같습니다.

sdf를 표시하면 기본적으로 색상을 지정하고 크기를 조정하고 잠재적으로 약간 더 선명하게 만들 수 있는 아웃라인이 제공됩니다.

이 작업은 너무 어렵지 않아야 합니다. 나는 얼마 전에 textOutline을 기능으로 사용하기 시작했지만 끝내지 못했습니다.

이론적으로 글리프 가장자리는 가장자리에 해당하는 부호 있는 거리 필드의 값을 변경하여 간단히 확장할 수 있습니다. 이것은 현재 셰이더 코드 에서 0.5 이지만, 유니폼으로 전달하여 구성할 수 있습니다.

이상적으로 셰이더는 단일 그리기 호출에서 일반 글리프와 그 주위의 윤곽선을 모두 그리는 것을 처리할 수 있으므로 윤곽선 너비(단위가 무엇인지 확실하지 않음) 및 색상 윤곽 영역.

나는 얼마 전에 textOutline을 기능으로 사용하기 시작했지만 끝내지 못했습니다.

기본적으로 지원된다면 매우 기쁠 것입니다 :)
그러나 저는 셰이더를 처음 접하기 때문에 얼마나 도움이 될 수 있을지 잘 모르겠습니다. 이 문제를 유심히 지켜보겠다.

나는 이것을 조금 다시 시작했고 내가 원래 왜 그것을 끝내지 않았는지 빨리 깨달았다. SDF는 개요에 _사용할 수_ 있지만 몇 가지 주의 사항이 있습니다.

• 아웃라인의 잠재적인 최대 너비는 디스턴스 필드 자체의 범위에 의해 제한됩니다(64x64 SDF 텍스처에서 ~8 텍셀).
• SDF 텍스처가 각 글리프의 경계에 맞게 크기가 조정되기 때문에 이는 모든 글리프에서 일관된 시각적 크기에 해당하지 않습니다.

따라서 "W"와 같은 큰 글리프는 상당히 두꺼운 윤곽선을 얻을 수 있지만 마침표와 같은 작은 글리프는 매우 얇은 윤곽선만 얻을 수 있습니다. 그리고 각 글리프는 윤곽선을 시각적으로 일관성 있게 만들기 위해 다른 SDF 컷오프 지점을 사용해야 합니다.

나는 이것이 아직 극복할 수 없다고 생각하지만 처음에 생각했던 것만큼 간단하지 않습니다.

@lojjic , 이 라이브러리 🥇를 사랑하지만 텍스트 개요는 우리 프로젝트의 요구 사항입니다...

나는 이것을 조금 다시 시작했고 내가 원래 왜 그것을 끝내지 않았는지 빨리 깨달았다. SDF는 개요에 _사용할 수_ 있지만 몇 가지 주의 사항이 있습니다.

• 아웃라인의 잠재적인 최대 너비는 디스턴스 필드 자체의 범위에 의해 제한됩니다(64x64 SDF 텍스처에서 ~8 텍셀).
• SDF 텍스처가 각 글리프의 경계에 맞게 크기가 조정되기 때문에 이는 모든 글리프에서 일관된 시각적 크기에 해당하지 않습니다.

따라서 "W"와 같은 큰 글리프는 상당히 두꺼운 윤곽선을 얻을 수 있지만 마침표와 같은 작은 글리프는 매우 얇은 윤곽선만 얻을 수 있습니다. 그리고 각 글리프는 윤곽선을 시각적으로 일관성 있게 만들기 위해 다른 SDF 컷오프 지점을 사용해야 합니다.

나는 이것이 아직 극복할 수 없다고 생각하지만 처음에 생각했던 것만큼 간단하지 않습니다.

궁금합니다. 윤곽선 및/또는 그림자 효과를 얻기 위해 셰이더를 사용하여 일종의 후처리를 수행할 수 있습니까? 미리 감사드립니다!
달성하려는 효과는 다음과 같습니다.

편집 : 이것은 mapbox gl에서 가져온 것입니다. SDF도 사용하고 있다고 생각합니다 https://blog.mapbox.com/drawing-text-with-signed-distance-fields-in-mapbox-gl-b0933af6f817 , 아마도 우리는 할 수 있습니다 코드를 분석하여 그들이 한 일을 확인하십시오. https://github.com/mapbox/mapbox-gl-js

Mapbox에 대한 정보를 제공해 주셔서 감사합니다. @anzorb. 나는 그들의 구현을 더 자세히 확인하겠지만, 그 블로그 게시물(그들은 아웃라인을 "후광"이라고 부름)에서 이전에 언급한 것처럼 SDF 알파 임계값 접근 방식을 사용하는 것처럼 들립니다. 그러나 그들의 SDF 생성 및 아틀라스 패킹 전략은 내 것과 다르며 글리프당 비균일 디스턴스 필드 크기와 동일한 문제가 없습니다. 그러나 동일한 최대 윤곽선 너비 제한이 있을 것입니다.

나는 실제로 표준 파생 상품을 사용하여 _화면 공간_ 윤곽선에 대해 약간의 진전을 이루었습니다. 윤곽선을 의미하는 화면 공간은 예를 들어 텍스트의 크기/축척 또는 기울기에 관계없이 너비가 1 화면 픽셀이 됩니다. 목표가 배경과의 대비를 추가하는 것이라면 텍스트 크기에 따라 크기가 조정되는 윤곽선만큼 좋을 수 있습니다. 그것에 대한 의견이 있습니까?

표준화된 너비는 스케일링 너비보다 훨씬 더 선호됩니다. 이런 식으로 CSS처럼 더 많이 작동합니다.
CSS를 통해 적용되는 모든 text-shadow 는 font-size 와 독립적으로 구성됩니다.
제안한 솔루션 @lojjic 이 동일한 방식으로 수행된다면 그것은 🎉 🎉 🎉가 될 것입니다.

@lojjic의 신속한 응답에 감사드립니다!

목표 는 대비를 추가하는 것이며 제안이 멋지게 보입니다. 윤곽선이 고정된다는 것을 의미합니까? 즉, 그것을 제어할 방법이 없습니다( @stephencorwin이 설명했듯이 text-shadow-ish 접근 방식을 사용하여).

솔직히 말하면, 초고밀도 디스플레이에서 1픽셀이 보이는 한 문제로 보지 않습니다(현재 밀도에 관계없이 "동일한" 비율을 달성하기 위해 글꼴 크기에 장치 픽셀 비율을 곱하기 때문) , 당신의 제안은 더 높은 DPI 장치에서 윤곽선이 눈에 띄게 더 얇아진다는 것을 의미한다고 생각합니다.

미리 감사드립니다!

나는 당신의 제안이 더 높은 DPI 장치에서 윤곽선이 눈에 띄게 더 얇을 것이라는 것을 의미한다고 생각합니다. 그렇죠?

예, 그것은 화면 공간 접근 방식의 한 가지 단점입니다. 그것은 많은 시나리오에서 괜찮을 수 있지만 디자이너로서 장치에서 다른 모양을 갖는 것은 귀찮게 할 것입니다.

다른 큰 단점은 (내 생각에) 후광 두께를 늘리면 더 많은 텍스처 읽기가 필요하기 때문에 성능에 영향을 줄 수 있다는 것입니다. 그래도 이건 계속 연구해야 해요.

저에게도 이 기능이 필요합니다. 나는 오래전에 개발한 Android 앱에서 이러한 기능을 구현했으며 나 자신과 친구들만을 위해 사용했습니다. 나는 이 앱을 React로 다시 구현하기 시작했고 당신의 프로젝트를 찾기 위해 왔습니다.
다른 사람들과 마찬가지로 이 도서관에 감사드립니다. 나는 그것에 놀랐다.

더 많은 질감 읽기에 대한 귀하의 의견에 대해, 나는 당신이 그렇게 많이 걱정할 필요가 없다고 생각합니다. 필요한 추가 텍셀은 인접 프래그먼트에 필요한 텍셀이므로 어쨌든 GPU 캐시에 있을 것이며 비용은 거의 들지 않을 것입니다.

@FunMiles를 입력해 주셔서 감사합니다. (콜로라도 대표! 😄)

나는 당신이 1, 아마도 2 조각 두께의 윤곽선에 대해 옳다고 생각합니다. 내 우려는 두께가 증가함에 따라 텍스처 읽기의 수(두께 4 = 56 읽기?)와 해당 읽기가 더 비쌀 가능성이 폭발적으로 증가한다는 것입니다. 그러나 나는 몇 가지를 읽고 추측했을 뿐이며 GPU 전문가는 아닙니다. 나는 아마 그것을 시도해야 할 것입니다.

@lojjic (북쪽 😄 ) 프래그먼트 셰이더의 코드를 찾으려고 했습니다. 셰이더를 완전히 작성하는 대신 수정하는 것처럼 보이는(그리고 어딘가에서 읽은 것 같습니다) 상황을 파악하는 데 어려움을 겪고 있음을 인정합니다.
그러나 전체 셰이더가 무엇인지, 실제로 어떻게 연결하는지 알 수는 없지만 핵심 루틴은 어느 정도 알 수 있을 것 같습니다...

지금 texture2D(uTroikaSDFTexture, vTroikaSDFTextureUV).r; 픽셀의 스칼라 거리를 읽습니다. 당신이 전에 쓴 것을 이해한다면, 한 가지 문제는 글리프 주변의 공간과 관련이 있습니다. 더 자세히 설명해 주시겠습니까?
'W' 및 ','의 예로 돌아가서 텍스처의 vTroikaSDFTextureUV 범위가 글리프 주위에 정확히 꼭 맞습니까? 아니면 추가 공간이 있습니까? 조각 셰이더는 현재 글리프의 UV 경계를 알고 있습니까? 그렇다면 외부에 있는 조각의 경우 현재 UV를 경계에 투영하고 내부 데이터를 읽을 수 있습니다.

최대 5개의 텍셀 읽기 또는 파생 상품을 사용하여 필요한 것이 무엇인지 알아내는 것이 가능하다고 생각합니다(사용 가능한지 확인하세요).

'W' 및 ','의 예로 돌아가서 텍스처의 vTroikaSDFTextureUV 범위가 글리프 주위에 정확히 꼭 맞습니까? 아니면 추가 공간이 있습니까?

각 글리프의 실제 경로 경계 주위에는 거리 필드의 외부 부분을 수용하기에 충분한 약간의 추가 공간이 있습니다. 그것은 SDF에서 8 텍셀이지만, 각 SDF는 다양한 크기의 글리프 쿼드로 크기가 조정된 균일한 64x64이기 때문에 보이는 여백은 글리프마다 다릅니다.

조각 셰이더는 현재 글리프의 UV 경계를 알고 있습니까? 그렇다면 외부에 있는 조각의 경우 현재 UV를 경계에 투영하고 내부 데이터를 읽을 수 있습니다.

해당 정보를 사용할 수 있어야 합니다. 나는 "현재 UV를 경계에 투영하고 내부 데이터를 바로 읽으러 가십시오"에 대해 당신을 따르지 않습니다.

적은 수의 텍셀 읽기로 더 두꺼운 윤곽선을 얻는 방법을 알고 계시다면 감사하겠습니다! 나는 그것을 다음과 같이 개념화했습니다. 글리프 경로 안에 있지 않은 조각에 대해 방사형 검색을 수행하여 r= 내에 조각이 있는지 확인하십시오.글리프 경로 내에 떨어질 것입니다. 그것은 그것에 대해 생각하는 잘못된 방법일 수 있습니다.

한 가지 문제는 글리프가 나란히 놓일 때 발생하는 일입니다. 지금은 제쳐두고 꽤 두꺼운 윤곽선 t 으로 그려진 단일 문자의 경우를 가정해 보겠습니다. 윤곽선을 수용할 수 있을 만큼 충분히 큰 사각형으로 캐릭터가 그려지고 있습니다.
프래그먼트 셰이더에는 vTroikaSDFTextureUV 및 vTroikaGlyphUV 의 두 가지 주요 정보가 있습니다.

내 이해는 vTroikaGlyphUV 글리프 내부에서 0과 1 사이에서 고정된 값을 갖는다는 것입니다. 내가 투영에 대해 이야기할 때 의미한 것은 vTroikaGlyphUV 가 해당 경계를 벗어나면 글리프 경계에 "투영된" 점의 거리를 검색할 수 있다는 것입니다. 즉, uv = (1.05, 0.7)인 경우 투영된 점은 (1.0, 0.7)입니다. (1.0, 0.7+epsilon) 및 (1.0, 0.7-epsilon)의 값을 사용하여 거리에 대한 기울기를 검색할 수 있으며 이를 사용하여 (1.05, 0.7)에서 근사 거리를 계산할 수 있습니다.
내가 이것을 위해 내 자신의 작업을 수행했을 때 텍스처의 그라디언트를 사용하여 SDF를 수행하는 누군가의 기사를 읽은 기억이 있습니다. 이 접근 방식은 3개의 텍셀을 읽을 필요가 없지만 텍스처를 3개의 구성 요소 텍스처로 만들고 텍스처를 빌드하는 데 복잡성을 추가합니다.

이것이 귀하의 질문에 대한 답변입니까?

이제 여러 캐릭터가 나란히 있을 때 각각은 이웃을 인식해야 하므로 이를 조금 더 복잡하게 만듭니다. 현재 캐릭터뿐만 아니라 이웃에 대해서도 GlyphUV 및 TextureUV를 전달해야 합니다. 각 문자를 두 개의 직사각형으로 잘라야 이웃이 첫 번째 직사각형의 경우 이전 항목이 되고 두 번째 직사각형의 경우 이후 항목이 될 수 있습니다. 여러 줄을 처리하는 방법을 잘 모르겠습니다.... 내 응용 프로그램에서 해당 경우를 처리할 필요가 없었습니다. 내 응용 프로그램은 지도였고 각 레이블은 한 줄이었습니다.

추신: "각 글리프의 실제 경로 경계 주변의 추가 공간"을 잘못 이해했을 수 있습니다. 예를 들어 X의 경우 직사각형으로 둘러싸여 있고 유효한 값이 없는 4개의 삼각형이 있다는 말씀이신가요?

@FunMiles 나는 _생각__ 당신이 어디로 가는지 알 것 같습니다. 깊이 생각할 시간이 필요하지만 현재 집중해야 하는 다른 마감 작업이 있습니다.

추신: 약간의 재미있는 수학 메모:
누군가가 2개 또는 3개의 정렬된 점에서 어떻게 기울기를 얻을 수 있는지 궁금해하는 경우를 대비하여 거리의 기울기에는 고정된 표준이 있다는 점을 기억해야 합니다(선택한 축척에 따라 다름). 그리고 그라데이션은 확실히 글리프 상자의 바깥쪽을 가리킵니다. 따라서 예를 들어 예(1.0, 0.7), (1.0, 0.7+epsilon) 및 (1.0, 0.7-epsilon)의 3개 점 모두가 동일한 거리에 있는 경우 기울기는 (scale, 0)입니다.

확실히 성능이 좋지는 않지만 오프셋을 사용하는 것은 가능합니다. drei 패키지와 함께 troika-text를 활용하는 react-three-fiber 를 사용하고 있지만 라이브러리가 기본적으로 스트로크를 지원할 때까지 다른 사람들이 임시방편으로 솔루션을 찾는 경우를 대비하여 공유할 것이라고 생각했습니다.

import React from 'react';
import {Text} from 'drei';

const StrokedText: React.FC<
  {
    strokeWidth?: number;
    strokeColor?: string;
    strokeResolution?: number;
    bold?: boolean;
  } & any
> = ({
  strokeWidth = 1,
  strokeColor: color = '#000000',
  strokeResolution = 100,
  position,
  bold,
  ...props
}) => {
  const font = bold ? FONTS.BOLD : undefined;
  const sharedProps = {
    ...props,
    font,
    color,
    sdfGlyphSize: 12,
    debugSDF: true,
  };

  let zOffset = 0;
  const offset = () => (zOffset += 0.001);

  return (
    <group name="Stroked Text" position={position}>
      {Array(strokeWidth)
        .fill({})
        .map((_, i) => {
          const s= i / strokeResolution;
          return (
            <React.Fragment key={i}>
              {/* <Text {...sharedProps} position={[-s, 0, offset()]} />*/}
              {/* <Text {...sharedProps} position={[s, 0, offset()]} />*/}
              <Text {...sharedProps} position={[0, -s, offset()]} />
              <Text {...sharedProps} position={[0, s, offset()]} />
              <Text {...sharedProps} position={[-s, -s, offset()]} />
              <Text {...sharedProps} position={[s, s, offset()]} />
              {/* <Text {...sharedProps} position={[-s, s, offset()]} /> */}
              {/* <Text {...sharedProps} position={[s, -s, offset()]} /> */}
            </React.Fragment>
          );
        })}
      <Text name="Text" {...props} position={[0, 0, strokeWidth ? offset() : 0]} />
    </group>
  );
};

export default StrokedText;

그런 다음 다른 곳에서는 일반적으로 <Text /> <StrokedText /> 로 호출할 수 있습니다.

<StrokedText
  color="#ffffff"
  fontSize={fontSize}
  clipRect={[-0.5, -0.15, 0.5, 0.15]}
  textAlign="center"
  position={[0, 0, 0.01]}
>
  {text}
</StrokedText>

@FunMiles 마침내 귀하의 제안을 구문 분석할 시간이 생겼습니다. 글리프의 SDF 사각형 전체에 유용한(> 0.0) 거리 값이 포함되어 있다고 가정하는 것이 합리적이라고 생각합니다. 현재는 그렇지 않습니다. 나는 당신이 "x"에 대한 후속 조치에서 그것을 깨닫고 있다고 생각합니다. 여기서 SDF는 쿼드의 경계 내에서 0으로 잘 떨어지므로 외삽할 유용한 거리 기울기가 없는 중요한 영역이 있습니다.

쿼드 전체에 걸쳐 0이 아닌 기울기를 보장하기 위해 SDF 생성기를 변경하는 방법을 살펴볼 수 있습니다...? 소리내어 생각하면 거리 정밀도에 대한 의미가 있을 수 있고 아틀라스 텍스처 내에서 캐릭터 사이에 아티팩트가 발생할 수 있습니다... 🤔

쿼드 전체에 걸쳐 0이 아닌 기울기를 보장하기 위해 SDF 생성기를 변경하는 방법을 살펴볼 수 있습니다.

나는 그것을 시도했고 네, 그것은 거리 필드가 쿼드 경계를 넘어 외삽되도록 허용하지만 내가 두려워하는 것처럼 글리프 자체의 품질을 크게 떨어뜨립니다. 이는 8비트 그라디언트로만 예상됩니다. 더 먼 거리에 퍼뜨리면 각 텍셀에서 정밀도가 낮아집니다. :(

아마도 두 번째 텍스처 채널로 인코딩된 윤곽선에 대해 별도의 SDF를 생성할 수 있습니다. 텍스처 크기를 두 배로 늘리지만 크게 느려서는 안 됩니다. 🤔

두 번째 텍스처 채널로 인코딩됩니다.

@lojjic 그것은 매우 합리적으로 들리고 기본적으로 지금 당장의 해결 방법을 모방합니다. 또한 옵트인이 가능하므로 사용자가 개요를 요청하지 않으면 성능이 저하되지 않습니다.

@lojjic @stephencorwin 이 제안한 옵트인 접근 방식은 아무도 지불할 준비가 된 것보다 더 많이 지불하지 않도록 합니다.

기술적인 측면으로 돌아갑니다. 응답에서 X 이미지를 사용하겠습니다. 모든 글리프에 대해 64x64 픽셀이라는 것을 올바르게 이해하고 있습니까? 8비트를 사용하여 전체 거리 공간을 인코딩해야 하는 경우 2 _fractional_ 비트의 정확도를 의미합니다. 이 정확도가 충분하지 않다고 말씀하신 것 같습니다.

아주 적은 비용으로 정확도를 높이는 데 사용되는 트릭이 있을 수 있습니다. 8비트의 64x64 그리드를 수행하는 대신 2x2 블록의 데이터를 32비트 데이터로 압축합니다. 두 픽셀 사이의 부호 있는 거리의 한 가지 분명한 특징은 대각선으로 항상 [-1,1] 오른쪽과 왼쪽, 위쪽과 아래쪽 및 [-sqrt(2), sqrt(2)] 내에 있다는 것입니다. 따라서 2x2 블록 중심의 SD에 12비트를 사용한다고 가정하고 픽셀의 각 중심에 5비트를 사용하여 중심과 2x2 중심 간의 차이를 인코딩하게 됩니다. 이 5비트는 최대 sqrt(2)/2 거리를 나타냅니다. 효과적으로 5.5비트 정확도를 갖습니다.
중심점 12비트는 최대 64의 거리에서 최소 6비트의 정확도를 인코딩합니다. 기술적으로 상자의 모서리에 한 지점만 있는 경우 12비트는 최대 sqrt(2)*64까지 인코딩할 수 있어야 하지만 상자가 모든 글리프 주위에 합리적으로 중앙에 위치할 것으로 추정되기 때문에 그것이 실제로 가능하다고 생각하지 않습니다. 사실, 글리프 에지에서 멀수록 델타가 인코딩해야 하는 정보가 적습니다(글리프 에지에서 멀리 떨어져 있을 때 그라디언트 필드는 이웃에서 거의 균일해짐). 따라서 정보 이론의 관점에서 볼 때 짝수입니다. 인코딩 개선 가능
더 많은 실제 정보를 얻으려면 .... 그러나 나는 그러한 추가 최적화로 시작하지 않을 것입니다.

이 접근 방식의 흥미로운 결과 중 하나는 텍스처링 하드웨어가 보간을 수행하도록 하지 않는다는 것입니다. 그러나 반대로 무료로 그라디언트를 얻을 수 있습니다.

도움이 필요하면 이 모든 것의 인코딩/디코딩을 구현할 수 있습니다.

추신: README.md 중 하나에서 보다 정교한 SDF에 대한 토론을 본 기억이 있습니다. 내가 꿈을 꾸었습니까? 😛 다른 시스템이 여기에서 도움이 될 수 있는지 알아보기 위해 누군가 나를 다시 안내해 줄 수 있습니까?

@FunMiles 아주 영리한 압축 아이디어입니다. 다른 옵션이 실패할 경우 이를 염두에 두겠습니다. 하드웨어에 의한 선형 보간을 잃는 것은 내가 하지 않아도 되는 절충안입니다. 😉

비트가 충분하지 않은 문제가 0.5를 "0" 거리로 사용하면 악화되므로 알파 값의 절반만 상형 문자를 인코딩하는 데 사용할 수 있습니다. 외부 거리에는 더 많은 값을 사용하고 내부 거리에는 더 적은 값을 사용하도록 잠재적으로 전환하여 주변에서 어느 정도 정밀도를 얻을 수 있습니다.

답장. "더 정교한 SDF"는 여러 색상 채널이 사용되는 "MSDF"를 의미할 수 있습니까?

@FunMiles 아주 영리한 압축 아이디어입니다. 다른 옵션이 실패할 경우 이를 염두에 두겠습니다. 하드웨어에 의한 선형 보간을 잃는 것은 내가 하지 않아도 되는 절충안입니다. 😉

보간을 잃어버릴까 걱정할 필요는 없다고 생각합니다. 비용은 매우 낮지만 하드웨어 지원이 없을 때 항상 기울기(및 약간의 곡률)를 갖는 이점이 더 중요하다고 생각합니다. 실제로 샘플 점을 반올림하고 반올림된 샘플 점에 대한 새 오프셋 값을 얻습니다. 앤티 앨리어싱을 위한 조각의 부분 커버링을 계산하는 것은 일반적으로 사용 가능한 그래디언트에서 하는 것처럼 진행됩니다.
비트가 충분하지 않은 문제가 0.5를 "0" 거리로 사용하면 악화되므로 알파 값의 절반만 상형 문자를 인코딩하는 데 사용할 수 있습니다. 외부 거리에는 더 많은 값을 사용하고 내부 거리에는 더 적은 값을 사용하도록 잠재적으로 전환하여 주변에서 어느 정도 정밀도를 얻을 수 있습니다.

그러면 최대 1비트의 정확도를 얻을 수 있습니다. 재채기하지는 않지만 여전히 그렇게 중요하지 않습니다.

답장. "더 정교한 SDF"는 여러 색상 채널이 사용되는 "MSDF"를 의미할 수 있습니까?
그게 내가 의미한거야. C++에서 이에 대한 GitHub 프로젝트를 찾았습니다. 쓸만한게 있었나요?? 아니면 제가 2주전에 찾아본 여러가지를 섞어서 헷갈린건가요?

그건 그렇고, MSDF가 도움이 될 것이라고 생각하지 않습니다.
JavaScript에서 SDF를 빌드하는 방법을 설명하는 작은 .md 파일이 있는지 여쭤봐도 될까요? 이를 통해 압축 아이디어를 구현하는 코드를 만들 수 있다고 생각합니다.

SDF는 https://github.com/protectwise/troika/blob/master/packages/troika-three-text/src/worker/SDFGenerator.js#L134 에 구축되어 있습니다. 텍셀을 글꼴 단위로 매핑하고 측정된 거리를 텍셀 값에 기록합니다. 각 2x2 블록의 중심점에 대해 추가 거리 측정값을 추가해야 합니다.

내 두뇌를 이것으로 완전히 감싸려고 하는 중... GLSL에서 쌍선형 보간을 복제하는 것은 가장 가까운 4개의 값이 있으면 간단하고/저렴해 보입니다. 압축 체계로 인코딩될 때 해당 값을 얻으려면 다음이 필요하다고 생각합니다.

• 정확히 텍셀의 중앙에 있는 경우: 2개 또는 3개의 텍스처 샘플
• 2x2 블록의 4개의 텍셀 사이인 경우: 4개의 텍스처 샘플
• 두 인접 블록 사이에 있는 경우: ~9 텍스처 샘플~ 7 또는 8 텍스처 샘플
• 4개의 인접 블록 사이인 경우: ~11 텍스처 샘플~13 텍스처 샘플

내가 그것을 올바르게 grokking하고 있습니까?

아 잠깐만, 나는 여전히 단일 채널 텍스처를 생각하고 있었습니다. 4개의 rgba 채널을 사용하여 각 데이터 블록은 단일 읽기입니다. 따라서 최대 4개의 텍스처 샘플이 있습니다.

나는 SDFGenerator.js를 읽기 시작했습니다. 더 살펴보겠습니다.

모든 면에서 글리프 가장자리로 둘러싸인 지점에 있을 수 있는 모서리 경우에 대해 알파 블렌딩을 특별히 개선하려는 경우가 아니면 조각당 단일 텍셀을 읽는 것 이상은 필요하지 않다고 생각합니다. 조각의 중심이 있는 2x2 블록의 가장 가까운 중심만 있으면 됩니다.
그러나 내가 예상하지 못한 어려움이 있을 수 있음을 깨달았습니다... WebGL 1.0은 여기에서 사용할 수 있는 기능이 매우 제한적입니다. 부호 없는 정수 유형 없음 uint 32비트 정수도 아닙니다! 🤯 그리고 비트 연산이 없습니다... 그래서 제가 제안하는 압축은 16비트 정수를 사용하여 작성하기가 조금 더 까다롭습니다.

이 모든 것이 WebGL 2.0에서 사용 가능하지만 여기에서 WebGL 1.0을 대상으로 하고 싶다고 가정합니까?

이 모든 것이 WebGL 2.0에서 사용 가능하지만 여기에서 WebGL 1.0을 대상으로 하고 싶다고 가정합니까?

텍스트 개요를 webgl 2로 제한하고 사용자가 해당 브라우저 호환성을 가지고 있는지 감지하는 것이 합리적일 수 있다고 생각합니다. 그러나 webgl 1 폴백으로 webgl 2 최적 버전을 모두 수행하는 것을 이해할 수 있습니다. 우리는 webgl 2로 시작하여 커뮤니티에 스며들게 하고 즉시 두 가지를 모두 지원하려고 시도할 수 있습니다.

나는 정밀도 문제를 해결하기 위한 대체 접근 방식이 있다고 생각하므로 @FunMiles 는 지금 압축 문제에 대해 걱정하지 않아도 됩니다.

안녕하세요 @lojjic , 방금 확인했습니다. 진행 상황이나 도움이 필요한 사항이 있습니까?

참고 사항: Safari는 마침내 WebGL2를 지원하게 되므로 이 기능에 대해 WebGL1을 지원하지 않을 수 있습니다.

WebGL2 구현은 더 광범위한 테스트를 위해 기본적으로 활성화해야 할 만큼 충분히 좋은 상태입니다.
https://trac.webkit.org/changeset/267027/webkit

WebGL 2.0이 없을 iPhone 6이 있습니다 😒

흥미롭게도 WebGL 1.0은 내가 생각했던 것보다 훨씬 더 나쁜 요구 사항을 지정합니다. 정수는 실제로 존재하지 않습니다.

4.1.3 정수
정수는 주로 프로그래밍 지원으로 지원됩니다. 하드웨어 수준에서 실수 정수가 도움이 될 것입니다.
루프 및 배열 인덱스의 효율적인 구현 및 텍스처 단위 참조. 그러나 없음
언어의 정수가 하드웨어의 정수 유형에 매핑되어야 한다는 요구 사항입니다. 라고 예상되지 않는다.
기본 하드웨어는 광범위한 정수 연산을 완벽하게 지원합니다. OpenGL ES 셰이딩
언어 구현은 정수를 부동 소수점으로 변환하여 작동할 수 있습니다. 그래서 휴대용이 없다.
래핑 동작.

그러나 나는 희망을 잃지 않았습니다. 조금 다시 생각해봐야겠네요...
한편, @lojjic , ​​어떤 대안을 생각해 냈는지 알려주시겠습니까?

@FunMiles 물론입니다. 비선형 스케일을 사용하여 거리 값을 인코딩하여 글리프 모양에 대한 충분한 정밀도를 유지하면서 거리 필드를 텍스처의 가장자리까지 확장할 수 있습니다. 따라서 글리프 경로(1-2 텍셀 이내)에 매우 가까운 거리에는 작업할 값이 많은 반면 멀리 떨어져 있는 거리에는 더 적은 값이 있습니다. 셰이더는 원래 선형 거리로 다시 변환하는 방법만 알면 됩니다. 글리프의 적절한 모양은 멋지게 보이고 돌출된 윤곽선의 낮은 정밀도는 어쨌든 반올림되기 때문에 거의 눈에 띄지 않습니다.

저는 2계층 선형 척도와 지수 척도를 모두 사용하여 이것을 증명했습니다. 둘 다 장단점이 있습니다.

저는 이제 쿼드 외부의 그라디언트를 근사화하기 위해 인접 가장자리 값을 사용하는 (매우 똑똑한) 접근 방식을 구현하는 중입니다. 지금까지는 이해가 되지만 모서리 바깥쪽 영역에 대해 무엇을 해야 할지 잘 모르겠습니다. 좀 더 들어가보면 뻔할 수도 있겠지만, 쉬운 답변을 해주시면 감사하겠습니다 :)

저는 이제 쿼드 외부의 그라디언트를 근사화하기 위해 인접 가장자리 값을 사용하는 (매우 똑똑한) 접근 방식을 구현하는 중입니다. 지금까지는 이해가 되지만 모서리 바깥쪽 영역에 대해 무엇을 해야 할지 잘 모르겠습니다. 좀 더 들어가보면 뻔할 수도 있겠지만, 쉬운 답변을 해주시면 감사하겠습니다 :)

_모서리 밖_이 무슨 말인지 잘 모르겠습니다. 가장 가까운 투영이 모서리 자체인 각 모서리에 뿌리를 둔 1/4 평면을 의미합니까? 수직 및 수평 가장자리 모두의 가장자리에 대한 규칙을 사용하고 각각에 대한 거리를 기반으로 가중 평균을 수행할 수 있다고 생각합니다.

추신: 오늘 일찍 WebGL 정수형 넌센스를 읽은 후 정확도를 멀리 낮추는 아이디어가 떠올랐습니다... 😛 WebGL 1.0에서 압축 기술을 구현하여 11비트의 정확도를 저렴하게 얻을 수 있기를 여전히 희망합니다. 더 많은 테스트로 더 많은 비트. 예를 들어 rgba 를 사용하면 a 는 평균의 8비트를 보유할 수 있으며 rgb 각각에 대해 서명되고 부호는 1비트의 정확도를 나타냅니다. 평균, 그리고 마지막으로 0-127 범위에 있는 나머지는 필요한 4개 값 중 3개에 대해 7비트를 나타내기 위해 값 64를 뺍니다. 실제 값은 center(0 ~ 2^11-1 범위) + dist_i입니다. 네 번째 값은 합계가 평균이어야 하므로 합계를 빼서 복구됩니다. 하나는 11비트만 얻을 수 있지만 아마도 충분할 것입니다. 더 많은 비트를 얻으려면 값 또는 r , g 및 b 이 -64보다 작은지, 양수인지 음수인지, 64보다 큰지 테스트해야 합니다. 기본적으로 중앙에는 14비트를 제공하고 차이에는 6비트만 제공합니다. 아마도 좋은 타협? 나는 WebGL 1.0이 정확성을 가짐으로써 이러한 생각을 방해하지 않는다는 것을 매우 느슨하게 보장하는지 테스트해야 할 것입니다....

네, U와 V가 모두 0-1 밖에 있는 영역을 의미했습니다. 감사합니다. 한 번 시도해 보겠습니다.

@lojjic 다른 질문으로 이전 게시물에서 메모리 때문에 SDF 텍셀당 두 개의 텍스처 값을 갖는 것에 대해 걱정하는 것처럼 보였습니다. 나 자신은 메모리를 줄이는 것을 선호하지만 64x64 그리드의 256개 글리프는 1/4MB의 텍스처 메모리만 사용합니다. 일부 언어에는 더 많은 글리프가 필요할 수 있지만 BBC는 신문을 읽으려면 2000/3000자만 필요하다고 말합니다. 따라서 4000자는 텍셀 SDF당 1바이트로 4MB를 만듭니다. 걱정할 가치가 있습니까?

@FunMiles 공정한 지적, 그리고 나는 사실 그 tbh에 대해별로 걱정하지 않았습니다.

몇 가지 해결해야 할 작업이 남아 있지만 b19cd3aff4b0876253d76b3fc66b7e2a1f16a7e5가 이 문제를 해결합니다. react-three-fiber를 사용하는 사람들을 위해 이것은 drei v2.2.0에서 릴리스되었습니다.
https://github.com/pmndrs/drei/pull/156

이것이 닫혀 있다는 것을 알고 있지만 작업에 대해 감사하다는 말을 전하고 싶습니다. 내 앱에서 작동하도록 했습니다. 속성이 윤곽선 크기에 대해 숫자만 허용하지 않는다는 것을 이해하는 데 약간의 시간이 걸렸습니다. 그러나 결과는 내가 필요로 한 것입니다.

@FunMiles 멋져요! outlineWidth 에 숫자 값을 사용할 수 _ 있어야_ 합니다. 어떤 이유로든 이것이 작동하지 않는 경우 알려주세요.

그리고 그 과정에서 의견을 보내주셔서 감사합니다. 나는 여전히 당신이 언급한 종류의 기술을 사용하여 쿼드 바운드 외부의 거리를 부드럽게 외삽할 수 없었습니다. 그래서 두꺼운 윤곽선은 현재 특히 모서리에 울퉁불퉁한 비트가 있지만 대부분의 경우에 충분합니다(최대 ~ 10% 글꼴 크기). 나는 여전히 그것을 개선하기 위해 노력하고 있습니다.