Troika: الميزة: أضف سمات فهرس الأحرف / الكلمة / الخط إلى هندسة النص

ربما أيضًا: wordIndex ، lineIndex ...؟

سيتم تمكين الكلمة والخط للرسوم المتحركة لكل سطر وكلمة ، تمامًا مثل https://greensock.com/splittext/ (والذي يمكننا اعتباره مثالًا جيدًا لما سيمكنه هذا التغيير)

هل أنا محق في افتراض أن هذا سيسمح أيضًا بالتغييرات لكل رمز (حرف ، كلمة ، سطر) في تظليل الأجزاء؟

هل أنا محق في افتراض أن هذا سيسمح أيضًا بالتغييرات لكل رمز (حرف ، كلمة ، سطر) في تظليل الأجزاء؟

يجب عليك تمريرها من قمة إلى جزء متغير ، لكن نعم. :)

أسفل حفرة الأرنب نذهب ...

يمكنني التفكير في استخدامات جميع المؤشرات التالية ، بالإضافة إلى العدد الإجمالي لكل منها:

• charIndex ، totalChars
• wordIndex ، totalword
• lineIndex ، totalLines
• charInWordIndex ، totalCharsInWord
• charInLineIndex ، totalCharsInLine
• wordInLineIndex، total WordsInLine

نود أن نجعل كل هذه العناصر قابلة للاشتراك ونقوم ببعض التعبئة الذكية لتقليل عدد سمات glsl الجديدة التي نقدمها. سأفكر أكثر حول API لهذا الغرض.

يمكننا السماح للمستخدمين باختيار كل منهم بالعلامات ، لذلك

{
انقسام: {Words: true، character: true، lines: true}
}

القيام ببعض التعبئة الذكية

العقل يتوسع في هذا؟ أنا فضولي 👐

تعجبني فكرة السماح للمستخدمين باختيار التقسيم (التقسيمات).

أعني بالتعبئة أننا لا نريد إضافة 12 إعلانًا جديدًا attribute float foo أو سنصل إلى الحد الأقصى (أعتقد أنه إجمالي 16 سمة في webgl) ، ولكن يمكننا حزمها في 3 إعلانات جديدة كحد أقصى attribute vec4 foo الإعلانات ، ثم قم بفك حزمها إلى متغيرات float ذات مظهر أجمل داخل التظليل.

أوه نعم ، له معنى كبير ، شكرا لك!

هل يجب أن يتضمن charIndex مسافات بيضاء في الزيادة؟ أو مجرد زيادة للصور الرمزية المرئية؟ أنا أميل نحو الصور الرمزية المرئية فقط.

قد يؤدي حساب المسافات البيضاء إلى إنشاء تداعيات غريبة عند التحريك بواسطة الفهرس ، لذلك سأميل أيضًا نحو المرئي

لدي الكثير من التنظيف لأقوم به ، لكن لديّ نقطة حماية أولية من التهم المذكورة أعلاه. فيما يلي أمثلة لاستخدام أزواج الفهرس / الإجمالي المختلفة لتغيير اللون في تظليل جزء:

charIndex / totalChars:

charInWordIndex / totalCharsInWord:

charInLineIndex / totalCharsInLine:

wordIndex / totalWords: (تبدو مشابهة جدًا لـ charIndex / totalChars في هذا المثال ولكن هناك فرق بسيط)

wordInLineIndex / total

lineIndex / totalLines:

تمكنت من الحصول على جميع البيانات في 3 زي موحد + 2 سمات كحد أقصى ، وهو أمر جيد جدًا. ما زلت أريد أن أجعلها اختيارية.

مدهش! اسمحوا لي أن أعرف عندما يكون لديك نسخة تجريبية جاهزة 😄

كنت أبحث عن عمل ميزة يمكن أن يعالجها هذا. لدي مجموعة من 3 تسميات أحرف لأضعها حول كرة. أنا أجعلهم دائمًا يواجهون العارض وأجري تعديلات بحيث يكونون دائمًا بنفس الحجم على الشاشة ، بغض النظر عن القياس المطبق في مصفوفة العرض أو مصفوفة النمذجة.
في الوقت الحالي ، أقوم بإنشاء كائن Text لكل تسمية وقمت بتطبيق التحويل.
كنت أفكر في أنه يمكنني الحصول على أداء أفضل بكثير من خلال تعبئة جميع الملصقات في نص واحد ولديها سمة للحصول على موضع على كرة كل تسمية للقيام بالتحولات الصحيحة في تظليل قمة الرأس.
lojjic هل يمكنك توثيق كيفية إنشاء تظليلات مخصصة؟ أعتقد أن إضافة السمة يجب ألا تكون صعبة كما يجب أن تفعل الطريقة الحالية setAttribute من BufferGeometry .

الخيار الآخر الذي كنت أفكر فيه هو التقديم ، نظرًا لأن جميع ملصقاتي تحتوي على 3 أحرف. لكن هذا سيتطلب WebGL 2 بالتأكيد وقد يكون معقدًا للغاية بحيث لا يستحق ذلك ، على الأقل في البداية.

FunMiles أعتقد أنك على حق ، هذا قد يسهل هذا النوع من الأشياء. إذا فهمت ذلك بشكل صحيح ، فقد يشمل التحسين جزأين:

1. نقل منطق الدوران / التحجيم من JS من جانب وحدة المعالجة المركزية إلى منطق تظليل الرأس على جانب وحدة معالجة الرسومات
2. هذا _plus_ يجمع عدة أجزاء من النص في مكالمة سحب واحدة

بالنسبة إلى 1 ، ألق نظرة على هذا التعليق ، فقد يكون هذا كافياً بالفعل لاحتياجاتك بالفعل. يعد هذا أيضًا عرضًا جيدًا لكيفية تطبيق تظليل مخصص ، بشكل أساسي فقط تعيينه كـ material . لقد استخدمت الأداة المساعدة createDerivedMaterial الخاصة بـ Troika من أجلها هناك ، ولكن يمكنك بالمثل تمرير أي ShaderMaterial أو مادة مع تعديلاتها onBeforeCompile .

بالنسبة إلى 2 ، أعتقد أنك محق في أنه يمكنك عرض نص واحد ثم استخدام سمة _some_ لإزاحة الأحرف الفردية حول المجال الخاص بك. قد تكون سمات فهرس الأحرف / الكلمات الجديدة الموضحة في هذه المشكلة مفيدة بعض الشيء ، لكنني لست متأكدًا من أنها ضرورية. ربما يمكنك فقط ترميز هذه الإزاحات إلى سمة InstancedBufferAttribute جديدة ، حيث يحتفظ كل متجه لها بالإزاحة لحرف واحد (هندسة النص عبارة عن رباعي بسيط يتم تثبيته لكل حرف رسومي ، لذلك سيتم تخطي سمات InstancedBufferAttribute الإضافية لكل حرف رسومي.)

أنا مهتم بمعرفة ما إذا كان لديك أي حظ في القيام بذلك!

lojjic لقد فهمت بشكل صحيح. والكود الذي قمت بربطه يفعل 90٪ مما أحتاج إليه (1). العرض التوضيحي الخاص بك يتطابق بشكل مخيف مع حالة الاستخدام الخاصة بي.
إذا كان لي أن أطلب منك تصحيح فهمي ، فإليك كيف أرى ما تفعله:

• تمت تهيئة mvPosition بموضع النقطة المرجعية في مساحة عرض النموذج. أفترض أن هذه النقطة المرجعية هي نقطة الارتكاز. هل هذا صحيح؟
• position هو الإزاحة من تلك النقطة المرجعية وأفترض أنه يحتوي فقط على إحداثيات x و y غير صفرية. (مما يجعلني أعتقد أنه يمكنك تخطي حساب المكون z للمقياس؟) (ملاحظة: بالنظر إلى رمز تظليل قمة الرأس ، يبدو أنه يمكن للمرء تدوير النص ، وفي هذه الحالة لن يكون المكون z صفرًا)
• يتم استرداد المقياس في كل اتجاه على افتراض أن الكتلة 3x3 تحتوي فقط على تركيبة القياس والدوران.
• تمت إضافة position المقياس ، وإذا كان المكون z يساوي صفرًا ، فإن هذه المساهمة تحافظ على الموضع في مستوى موازٍ لمستوى الإسقاط.

التغييرات التي أجريها على هذا الرمز لفعل (1) ستكون في الغالب في المقياس وتغيير بسيط في إحداثيات بحيث يظل النص خارج المجال الذي أملكه.

لقد فهمت 2 أيضًا. ومع ذلك أنا في حيرة من أمري عند قراءة الكود. لم أكن أدرك أن تقديم النص هو بالفعل تقديم مثيل. ما يحيرني هو أن لديك GlyphsGeometry مشتق من InstancedBufferAttribute ومع ذلك Text هي فئة فرعية من Mesh وليس من InstancedMesh . أعتقد أنني يجب أن أتعمق أكثر في Three.js.
خلافًا لذلك ، نظرًا لأن كل حرف مثبت ، سأحتاج فقط إلى سمة ذات متجه لتعويض position لكل مثيل حرف رسومي. هل هذا صحيح؟

اضطررت إلى الابتعاد عن هذا قليلاً ، ولكن إليك تحديثًا سريعًا للحالة:

يشعر PR # 109 بأنه قوي جدًا من حيث جمع وفضح التهم المختلفة. أريد أن أجعلهم يختارون الاشتراك ولكن بخلاف ذلك فأنا سعيد بمكانه.

ومع ذلك ، لدي حدس قوي بأن الرسوم المتحركة القائمة على التظليل لن تتطلب هذه الأعداد الجديدة فحسب ، بل ربما أيضًا الوصول إلى بعض البيانات الأخرى مثل:

• الحدود الرباعية للصورة الرمزية الحالية
• حدود الكتلة الإجمالية
• معلومات قياس الخط مثل الخط الأساسي / الصاعد / النازل والتي لا يمكن استنتاجها من الرباعية
• آخر؟

بعض هذه العناصر موجودة بالفعل من الناحية الفنية في التظليل ، ولكن إذا كان المستخدمون سيعتمدون عليها ، فسيحتاجون إلى الكشف عنها بأسماء مألوفة وتوثيقها كعقد موثوق.

إذا كان لدى أي شخص الوقت للعب مع فرع العلاقات العامة هذا ومحاولة تنفيذ بعض الرسوم المتحركة للتظليل ، وأخبرني ما هي أجزاء المعلومات المفقودة ، فستكون هذه مساعدة كبيرة.

lojjic أريد فقط التعبير عن اهتمامي بهذه الميزة 😺

لقد قمت بحل بعض تعارضات الدمج مع أحدث سيد هنا: https://github.com/canadaduane/troika/tree/char-indices

لم تسنح لي الفرصة لاختباره بعد ، لكنني أنوي ذلك في الأيام القليلة المقبلة.

لقد كنت بعيدًا عن هذا النقاش لفترة طويلة. ومع ذلك ، تم تذكيرني للتو أنني أريد العودة إلى النظر في الأمر.
في نهاية هذا المنشور هو مثال على شيء قمت به باستخدام createDerivedMaterial .
ومع ذلك ، في الوقت الحالي ، هناك شبكة واحدة لكل ملصق وعندما يصبح عدد الملصقات كبيرًا جدًا ، يصبح العرض متشنجًا بشكل كبير في الهواتف المنخفضة الجودة. أفترض أن ذلك يرجع إلى مكالمات وحدة المعالجة المركزية لكل تسمية. لمعالجة ذلك ، أود استبدال الشبكات المتعددة بشبكة واحدة بكل الملصقات واستخدام تظليل قمة محسّن للقيام بالباقي.

أعتقد أنه ، كما ذكر lojjic ، سأحتاج إلى بعض القيود على الكلمات. أو على الأقل ، من وجهة نظري ، مركز كل كلمة.
أي اقتراح آخر حول كيفية القيام بذلك بطريقة أخرى أو حول كيفية الحصول على هذا المركز؟

https://flightlog-beta.vercel.app/circles؟route=BRU-HER-ATH-IST-AMM-CAI-TUN-CMN-RAK-MAD-LIS-ZRH-GVA-NCE-CDG-DUS-FRA- MUC-LHR-LCY-LGW-DUB-HBA-SYD-MEL-CNS-KTM-DEL-BLR-COK-MAA-CMB-MLE-HKG-HND-NRT-KIX-ICN-GMP-MNL-DPS-JOG- CGK-SIN-KUL-PEN-LGK-BKK-SGN-HAN-LPQ-CNX-DOH-AUH-DXB-JNB-CPT-LVI-ZNZ-JRO-DAR-SSH-BUD-OTP-IPC-SCL-PMC- GRU-EZE-GIG-BSB-LIM-LPB-BOG-PTY-SJO-SJU-CUN-ACA-MEX-MTY-JFK-BOS-PHL-DCA-IAD-BWI-CLT-ATL-MSP-MIA-DFW- DTW-ORD-IAH-COS-DEN-PHX-SAN-LAX-SJC-SFO-SEA-PDX-YVR-YYZ-YUL-LGA-EWR-ASP-BNE-AKL-CHC-ZQN-VIE-SJJ-VCE- MXP-FCO-BCN-PEK-PVG-HNL-OGG-KOA-HIJ-RGN-PBH-TIP-AMS-CPH-SLC-CVG-GSP-TPE-ULN-PNH-VTE-ABQ-BUF-MCO-HKT- MDL-