[Bf-usd] Support for Preliminary_Text

[John Harrison]

Hi Sybren and others~

Implementing an importer as part of the same effort makes sense to me (more work of course) because it balances the feature set and will help with testing (import->export & compare).

Regarding how to implement an importer and exporter, I will need some direction to get started, but would be surprised if it didn’t involve coding.

Regarding font point size, I would use Reality Composer as “ground truth” and see how it maps font point sizes to designer units (meters usually), then document my findings and follow suite.

Regarding width/height, I’ll lean on others here. It makes sense IFF the runtime renders exactly the same as the designer (Blender), but what if the runtime doesn’t have the font family, or the font style (bold, italic)? I cannot vouch for a different runtime honoring the text attributes 100%, which is why I am hesitant about these two fields. Regarding their value, it is nice to know up front how much space the text will use.

Best,
John

> On Apr 21, 2022, at 5:53 AM, Sybren A. Stüvel <sybren at blender.org> wrote:
> 
> Hi John & fellow USD list members,
> 
> On Tue, 19 Apr 2022 at 13:51, John Harrison via Bf-usd <bf-usd at blender.org <mailto:bf-usd at blender.org>> wrote:
> Hi, I’m a software developer (never contributed to blender) motivated (possibly?) to implement USD export support for one of Apple’s schema additions, namely Preliminary_Text: https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text <https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text>
> 
> That looks like a nice addition to me. Would you also be able to implement the importer side of this?
> 
> Personally I don't have any experience with extending the standard USD schema. How would this work on a technical level? Would it require Blender to bundle any additional schema files? Would the mere existence of such schema files be enough, or would Blender's USD handling code also have to change?
>  
> On Tue, 19 Apr 2022 at 19:26, John Harrison via Bf-usd <bf-usd at blender.org <mailto:bf-usd at blender.org>> wrote:
> Great questions Charles, here are my thoughts in the same order as your questions (learning as I go here):
> 
> - Apple specifies a default point size of 144 in their docs (https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text/pointsize <https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text/pointsize>). My guess is Apple assumes the traditional 1/72” point unit, which multiplies nicely to 144 and would result in Apple choosing a default size of 2”. Now Blender has no such notion of point size for fonts, leading to your question about how blender would specify this. One suggestion is to have Blender convert on export, such that it measures the height in designer units, converts to inches, then divides by 72.
> 
> It would be good to get a definitive answer about this.
>  
> - No idea. The docs refer to USD’s notion of a “stage unit”, but honestly having wdith/height makes no sense to me - seems like the runtime should figure this out. The doc also states, "The runtime ignores this value if `wrapMode` is singleLine.” I would (without understanding more) not export width/height at all and see what issues it causes
> 
> From what I can tell, the width/height/depth properties are expressed in the "stage unit" indeed, which means for Blender simply Blender units (the exporter should ensure the USD scene is correctly set up to map it to meters on loading).
>  
> Sybren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-usd/attachments/20220421/c205a78d/attachment.htm>