Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text Proposal should include facilities for 3D text #40

Open
dgovil opened this issue Mar 19, 2024 · 8 comments
Open

Text Proposal should include facilities for 3D text #40

dgovil opened this issue Mar 19, 2024 · 8 comments
Labels
text Supporting text primitives

Comments

@dgovil
Copy link
Contributor

dgovil commented Mar 19, 2024

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
Copy link
Member

meshula commented Mar 24, 2024

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
Copy link
Contributor Author

dgovil commented Mar 24, 2024

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
Copy link
Member

meshula commented Mar 27, 2024

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
Copy link
Contributor Author

dgovil commented Mar 27, 2024

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
Copy link
Member

meshula commented Mar 27, 2024

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
Copy link
Contributor Author

dgovil commented Mar 27, 2024

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.

@dsyu-pixar dsyu-pixar added the text Supporting text primitives label Mar 27, 2024
@dgovil
Copy link
Contributor Author

dgovil commented Apr 5, 2024

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
Copy link
Member

meshula commented Apr 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
text Supporting text primitives
Projects
Status: Update
Development

No branches or pull requests

3 participants