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

Proposal: Support translucent color #290

Closed
jasollien opened this issue Sep 13, 2021 · 8 comments · Fixed by #326
Closed

Proposal: Support translucent color #290

jasollien opened this issue Sep 13, 2021 · 8 comments · Fixed by #326

Comments

@jasollien
Copy link
Contributor

Currently there is no way to make an element translucent, while still keeping the original color.

I suggest that we all agree on a color value that should be treated translucent, example "000000", or similar.

Also, it should be possible to transluce (or color) all elements except some.

@GeorgDangl
Copy link
Member

Just a thought, I think right now we can either have three blocks for red, blue, green or four blocks to include transparency. What if just a single block would indicate just a transparency value?

But we should maybe look around a bit more, how such data is expressed in other systems - maybe there's a clever solution that we just don't know😀

@GeorgDangl
Copy link
Member

GeorgDangl commented Apr 17, 2023

From the docs:
image

So, we can provide transparency IF we also provide colors, but we can't just add a transparency without also specifying the color.

@ykulbak
Copy link
Collaborator

ykulbak commented Apr 24, 2023

I propose that transparency should be defined directly under the compomenets because it willl be used in a similar fashion to visibility. Clash detection tools, for example, will colour the clashing objects and would apply transparency or a wireframe view to the surrounding objects to retain context (see image).
I propose we create a transparency object which would follow the same pattern as visibility. It would have a default_transparency directive and a set of exceptions to support making "everything transparent" and then highlight a small number of objects.
Transparency will be subject to visibility - a hidden/invisible object will not become visible by having a transparency assignment.

image

@pasi-paasiala
Copy link
Contributor

@ykulbak I like this idea. This way we wouldn't need to specify the transparency for each component. It'd be just a rendering hint how to show rest of the model.

@GeorgDangl
Copy link
Member

We've discussed it in the call, we'll go with that approach😀

@ykulbak
Copy link
Collaborator

ykulbak commented Jul 4, 2023

Discussion summary:
We discussed the BCF-XML pull request on the fortnightly call.

  • General agreement with the approach
  • The proposal allows categorising components as translucent or opaque but it doesn't allow specifying how translucent the components should be. Should we allow specifying the translucency of components?
    -- Agreed that if translucency level should be specified then it would be specified as a [0-1] xs:decimal where 0 indicates complete transparency and 1 indicates full opacity
    -- Proposed approach - leave the rendering of translucent components to the vendors who will ensure that the translucency level provides the best experience for their users.
    -- Alternative approach - specify translucency for each component.
    -- Alternative approach - specify translucency for each component type.
    -- Alternative approach - specify a single "global" translucency number for the viewpoint.
  • Concern: the XSD definition for translucency is a duplication of the visibility XSD with minor adjustments. Should we generalise and reuse a single XML schema definition for both?

It was decided to pause and defer the discussion to a future meeting with a greater number of participants.

@GeorgDangl
Copy link
Member

We just discussed it in a larger group in the call. The linked PR in the BCF XML repo looks good, and we'll do it that way😀

ykulbak added a commit that referenced this issue Nov 30, 2023
@ykulbak ykulbak linked a pull request Nov 30, 2023 that will close this issue
@GeorgDangl
Copy link
Member

Closed with #326

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants