<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Great questions Charles, here are my thoughts in the same order as your questions (learning as I go here):<div class=""><br class=""></div><div class="">- Apple specifies a default point size of 144 in their docs (<a href="https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text/pointsize" class="">https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text/pointsize</a>). 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.</div><div class="">- Resolution-independent would be great, but not sure how that would work. I think this is a separate issue from exporting though, seems like a rendering engine effort?</div><div class="">- I suppose the designer would leave that up to the rendering engine as well, but maybe you are considering use-cases I am not thinking of?</div><div class="">- Right. It seems like this isn’t called out at all in the Apple docs. Maybe they expect a separate `def` for heterogenous characters?</div><div class="">- 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</div><div class=""><br class=""></div><div class="">- John</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 19, 2022, at 8:35 AM, Charles Wardlaw <<a href="mailto:cwardlaw@imageworks.com" class="">cwardlaw@imageworks.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi John,<div class=""><br class=""></div><div class="">That sounds like a neat addition. Reading over their description, a few questions come to mind:</div><div class=""><br class=""></div><div class="">- How large is a "point" in DCC units? Can this be specified somehow?</div><div class="">- Is the text intended to be converted to polygons for rendering, or is it intended to be displayed in a resolution-independent way like an SDF font?</div><div class="">- If the text is intended to be converted to polygons, how does the author specify subdivision or font spline to polygon conversion?</div><div class="">- How do I specify or override properties on a per-character level?</div><div class="">- Are width and height in scene units, as is depth?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">~ Charles</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 19, 2022 at 7:51 AM John Harrison via Bf-usd <<a href="mailto:bf-usd@blender.org" class="">bf-usd@blender.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">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: <a href="https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text" target="_blank" class="">https://developer.apple.com/documentation/arkit/usdz_schemas_for_ar/preliminary_text</a><div class=""><br class=""></div><div class="">My motivation is to allow a designer to create a USD file with text that contains the text <i class="">attributes</i>, not the final mesh (though I supposed it could do both). This would allow software to pull the attributes from the USD file at runtime, including xForm, material, font-family, etc., and use these attributes to render dynamic text at runtime with the same text <i class="">attributes</i> the designer intended. Think 3D user interface where text may change based on a view model.</div><div class=""><br class=""></div><div class="">Apple is thinking along these lines but, after diving into their tools, there seems to be more concept than implementation. They are pushing Reality Composer but I find it more a broken toy than a tool, so I am turning to blender.</div><div class=""><br class=""></div><div class="">Thoughts? Questions?</div><div class=""><br class=""></div><div class="">Best,</div><div class="">John Harrison</div></div>_______________________________________________<br class="">
Bf-usd mailing list<br class="">
<a href="mailto:Bf-usd@blender.org" target="_blank" class="">Bf-usd@blender.org</a><br class="">
List details, subscription details or unsubscribe:<br class="">
<a href="https://lists.blender.org/mailman/listinfo/bf-usd" rel="noreferrer" target="_blank" class="">https://lists.blender.org/mailman/listinfo/bf-usd</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>