[2022.28040 MacM1 - 12.3] TextCOMP - alpha not working with Specification DAT / CHOP

When in ‘Text Mode’ it’s possible to set the TextCOMP alpha with the Font Alpha parameter.
When in Specification DAT/CHOP mode:

DAT columns:
fontcolorr, fontcolorg, fontcolorb → working
fontcolora → not working

CHOP channels:
fontcolorr, fontcolorg, fontcolorb → working
fontcolora → not working

PS
The TextCOMP is absolutely awesome! :star_struck:

That parameter is named “fontalpha”.

Ah thanks! it’s marked as fontcolora in the wiki.

All working for specification DAT and specification CHOP.

Apologies, fixed fontalpha in wiki.

1 Like

Building on this topic, I am unable to affect alpha via Formatting Code color(r,g,b,a):

I’ve also tried with a normalized range (although that wouldn’t make much sense given the syntax), it does something but not what I would expect, either:

FYI I am on Windows 10 instead of @tmisk 's M1. Same build, 2022.28040.

Hey Dylan,

The problem is actually similar to what I emailed you about with the sRGB color range where the font library that handles the formatting codes is doing things a little differently than the main TouchDesigner systems. In this case, the text shader is expecting a premultiplied alpha, but the font library is just passing the color through directly.

I think we’ll need to update the library to automatically premultiply the alpha, but in the meantime you should be able to do it manually if you want. For reference, the alpha value is still linear while the r, g, b values are currently supposed to be in sRGB space.

Thanks for the report.

1 Like

Hi Rob, any update on this? I’m actually using Text COMP with multi-line setting and I’d like to control the alpha of the lines individually but I guess the problem is still there.
Using 33910 build on Windows 11 btw.

Sorry we didn’t update this thread, but I believe the pre-multiply fix was included with our 2022.31030 release last December ( Release Notes - Derivative )

When I try it in the current release with this content ‘{#color(255,255,255,128)}Derivative\n{#color(255,255,255,64)}another line here’ in appears to be blending correctly.

Let me know if you’re still having problems.

Hey Rob, sorry for the late reply.
Actually my problem is slightly different: alpha is fine, but it is the multiline that is not working since the \n is not parsed. I guess it is because within a specification DAT it is possible to control lines individually. Is this meant to be like this?
I attach a simple example.
TextCOMP_multiline.toe (6.7 KB)

Unfortunately, that is a known limitation in the Text COMP at the moment. Escape sequences can be parsed in a python expression directly in the Text parameter as you were doing in the first example, but that is not currently supported when using the Specification DAT.

We did add a special option called ‘Parse Escape Sequences’ to the Geo Text COMP to handle that scenario, but it hasn’t been implemented in the Text COMP yet. I’ll see if I can get that ported over before our next update. Thanks for point that out.

1 Like

Thank you so much for the info. I’m sure we’ll find a workaround waiting for the update :slight_smile:
Have a good day!

I’ve added the new feature for the next update of our 2023 release. In that version you can enable ‘Parse Escape Sequences’ and it will convert ‘\n’ or ‘\t’ characters to the appropriate line breaks and tabs.

2 Likes