search

PixarAnimationStudios / OpenUSD-proposals

Share and collaborate on proposals for the advancement of USD
92 stars 25 forks source link

Text Proposal should include facilities for 3D text #40

Open dgovil opened 2 months ago

dgovil commented 2 months ago

The Text schema proposal as listed here https://github.com/PixarAnimationStudios/OpenUSD-proposals/tree/main/proposals/text states NOTE: in this design, the text primitive should be within a plane, or in general it is a 2D text. Deformable 3D text is not included in this design.

For the purposes of Apple use cases, we'd want to allow for 3D text. Our prior preliminary text schema is based around 3D text https://developer.apple.com/documentation/arkit/arkit_in_ios/usdz_schemas_for_ar/preliminary_text?language=objc

I think that even if the first iteration of an official schema focuses on 2D, we should have affordances for 3D text that is diegetic as well.

meshula commented 1 month ago

Unless I am misunderstanding something, the text element in the proposal would have a 3d transform so it can be positioned, scaled, and oriented in space; although the text itself would be laid out with respect to the plane so defined. Is it a matter of clarifying the language of the proposal?

dgovil commented 1 month ago

Sorry I should have clarified. Apple's schema allows for 3D text as in text that has depth and is part of the scene. The current proposal specifically says that isn't covered.

I just want to make sure that even if it's not covered, we don't elide it completely from the future.

meshula commented 1 month ago

Ah! My personal opinion is that a separate proposal would be in order for that. @nvmkuruc has started referring to "diegetic" and "non-diegetic" render elements, where diegetic elements are those that must be sampled for a scene and non-diegetic are those elements that are not sampled, but can be displayed, like UI elements or text callouts. "diegetic" text rendered in scene would have a whole orthogonal set of controls; extrusion depth, tessellation factors, bevel thresholds, and so on, and would not include things of interest in this proposal (such as layout). So I'd propose not that it's incorporated to this proposal in the future, but that it be considered as a separate concept with unique considerations.

dgovil commented 1 month ago

I guess part of that is that they share a lot of the same base. E.g the majority of the proposal would be shared.

I think it's valid for them to be different schema types. Something like UsdText2D and UsdText3D with a shared UsdTextBase. My point was more that since they share enough commonalities, that it would make sense to structure it in such a way that a text schema doesn't prevent a 3D text schema in the future.

Taking my example of TextBase, Text2D and Text3D. if we think something is only for 2D text, we should put it in Text2D instead of TextBase

Also on the topic of diegetic, it is possible to have diegetic 2D text planes as well. So I'm not sure text should inherently be considered non-diegetic.

So stuff like billboarding to face the user view might apply to non-diegetic text but not to diegetic ones. But both might be 2D or 3D.

meshula commented 1 month ago

I see the principled point. The practical point makes me want to treat 3d as a follow on proposal in order to be able to conclude work on this proposal in a timely manner. How about submitting a PR to the existing proposal with a note in the introduction along the lines of "Diegetic text shares much in common with this proposal and is a matter for a future proposal." ?

dgovil commented 1 month ago

Yep I don't think 3D should be included from the get go. It's more just about making sure it's not excluded in the future by choices made early on.

I'll work on the wording and put up a PR.

dgovil commented 1 month ago

Hey @meshula , for whenever you're back. I've been giving it some thought and I think the core issue is that I think the Text proposal as is, is that it is fairly large and encompassing which makes it difficult to provide adequate feedback/changes to without unravelling it too much.

This is made a little more difficult because it does diverge from the Apple preliminary schema (which I had raised in review) quite a bit. I think that's fine, but again just makes it harder to consolidate into a simple PR over the existing proposal.

I guess what I'm looking for is some guidance on how invasive a PR to an existing merged proposal can be?

meshula commented 1 month ago

It's merged in draft mode; draft proposals are meant to be discussed and debated.

It would be useful, I believe, to do a gap analysis between this proposal and Apple's (and any other proposals that authors would like to have considered), in order to have a concrete and systematic understanding of differences; that would provide a framework for reconciliation.