V8: Content Cache bake scaling issue

[Piotr]

You guys are probably fed up with me but I’m not stopping till I get this right:
Here is the Model Object display vs how it is baked:
PREVIEW:

AFTER BAKING:

Layer Name and object’s colour are correct but what’s wrong with the text scale?

I have attached the sample.
sample.gh (37.9 KB)

[Gijs (Gijs de Zwart)]

@Piotr I see the same in preview here:

can you send a 3dm as well?

[wim (Wim Dekeyser)]

Hi Piotr -

@Piotr

Layer Name and object’s colour are correct but what’s wrong with the text scale?

As Gijs says, we’d need the .3dm file to be sure, but judging by the images, it looks like your active annotation style in Rhino has a model space scale larger than 1. The preview uses that style with scaling.

Where does the internalized geometry in the Grasshopper file come from, is that the same document as the one that you are baking into?
-wim

[inno]

this thing of the model space scale is a bit of a dealbreaker

I would indeed expect the baked text to look exactly like in the preview, because when I’m setting up all the different variables it’s the preview itself that drives my choices

for instance, I setup the Annotation Style to be like this, with Model space scale 20:

on screen preview is fine:

after baking, Model space scale gets reverted to 1:

if I manually bring it back to 20, it’s exactly what was previewed, perfect overlapping:

so I guess the point is:

Baking text → performed using the current Annotation Style, but it does not inherit the current Annotation Style Model space scale

while

Preview → is using the current Annotation Style and also its Model space scale

[Piotr]

My apologies for forgetting attaching the 3dm (busy day), but Inno picked up the exact heart of the matter.

[wim (Wim Dekeyser)]

@wim

Where does the internalized geometry in the Grasshopper file come from, is that the same document as the one that you are baking into?

@inno

this thing of the model space scale is a bit of a dealbreaker

I’ve tried recreating this issue from scratch without success so I’m not sure where, exactly, the bug is introduced. I see that the internalized annotations have a font size override (which is respected when baked), but don’t know if it also has a model space scaling override that the override component that fails to identify or if, for some reason, that scale is not respected when baking these annotations. When starting from scratch, the model space scaling is correctly adhered to…

At any rate → RH-85976 Grasshopper: Bake Should Use Model Space Scaling
-wim

[Piotr]

The whole text is created in Grasshopper by reading the Keys and Values from external files. Nothing is internalised in the process.
All my text style have model space set to 20:

Geometry preview shows everything correct:

Model object makes the correct display as well:

Baking using Elefront:

Baking using Rhino panel:

V7 is all way correct. What I see as preview is what I get after baking.

[inno]

@wim

I’ve tried recreating this issue from scratch without success

I’m on Version 8 SR16 (8.16.25034.21001, 2025-02-03)

you can repeat the issue even with this super basic setup:

dimension_test_file.3dm (39.9 KB)
dimension_test_file.gh (7.1 KB)

[kike (Kike Garcia)]

Hi @Piotr,

This will be fixed on next 8.19 RC.

[Piotr]

Oh, thanks!

[brian (Brian Gillespie)]

RH-85976 is fixed in Rhino 8 Service Release 19

[Piotr]

This is still wrong, unfortunately.
The scale is correct, but everything is baked with the same text style.
Example:
This group of text has TEXT table style assigned:

but it assigned different text style when baked:

After assigning another text style:

and baking

It clan clearly be seen that it bakes with one style with messed up internal properties.
Another example with different text style:

when baked: correct font, correct size , wrongly displayed text style

Also, see the order displayed in Rhino vs GH

could this be a culprit?

Anyway. Something that worked 100% error-proof in V7 is broken in V8.
The new method is really pain… when working with multiple text styles.

I have to do some weird extraction and still don’t have an information what text style I have exposed.

[kike (Kike Garcia)]

Hi @Piotr,

Could you please share a simple .gh example file that illustrates the issue you describe?

About the order of the ‘Query Annotation Styles’ it returns the styles in creation order.
If you need the list to be in certain order you can do something like this.

[Piotr]

HI Kike
This issue is difficult to catch on such simple example.
I have made the simple test where the default text is baked in all 16 styles available and it is OK

On a more complex script it is failing, see example:

TEXT table has left alignment (I’m sure it is assigned correctly) and it bakes with wrong text style

The really weird thing is this: text style linked to annotation style failing in a basic example but working above, in more complex script.
1. Data conversion failed from Text Settings to Model Annotation Style

I’m bamboozled.
When I say larger script it means huge, +7000 components. I will try to isolate issue somehow and send it to you as PM.

Few moments later…
Ok, I got you something to look at and it is even more bizarre:

The text above won’t read from text style but when connected directly to text style behaves well.
The texts below will read from the text style but will be all showing central alignment and will bake wrongly.
So you probably asking what is the difference between text entities?
The above is just inserted, the lower ones are isolated from larger script.
They behave differently. I assume I’d have to replace them one-by-one and text style for annotation style, but this is the job I really didn’t want to do as there are so many of them with no visual difference. Can you label them old or anything like that?

[kike (Kike Garcia)]

@Piotr,

Cloud you share this last one as a .gh file?
This would help.

[Piotr]

I sent you PM.