Hi,
Text Entity’s Text Settings become null when de-serializing in Hops
Version 8 SR29
(8.29.26041.10001, 2026-02-10)
This is an example definition of creating a Text Entity
And this is the Script where I am using it as a Hops component
Please fix this bug, I need to revert back to 8.28 as of now.
This is a known issue. Essentially, Model Objects aren’t yet supported on Rhino.Compute. Model Objects are more complex data types than just geometry. A Text Entity can be serialized as “raw” geometry and that’s why you are getting a result out of the Hops component with a valid text entity that says “text”. However, a Model Object contains the raw geometry (i.e. the text entity) but all of the other references needed to make up that object in Rhino. Things like it’s layer, it’s display color, it’s line weight… etc… but most importantly for text entities is it’s referenced annotation style. Right now, Rhino.Compute doesn’t know how to serialize all of the additional data needed to be sent over for a Model Object… and so what you get back is the valid geometry of a text entity… but it didn’t serialize the annotation style and so things like the text height for the annotation style settings is null. FWIW, we are working towards a new release which would be able to handle Model Objects (and other 3rd party data types) so that this wouldn’t be a problem moving forward… but I don’t have a timeline as to when that will get released.
But this is not the behavior on 8.28. Text Entities do have Text Settings retained.
If this is how its going to be from 8.29 then it will cause some major problems for me. Can you please look into what changed between the two versions?
I think there has been some change in the way that Annotation Style Overrides are working with Text Entity under the hood. I don’t work with Annotation Styles, I just apply a Text Settings directly to the Text Entity component.
I should have added a screenshot, but essentially right now there is no way to get a text entity output from hops since the Text Settings are Null. This was not the case up till 8.28
(I will add a screenshot when I get access to my system again)
Hmm. You are correct. This is repeatable on 8.28. Let me dig in deeper.
Morning Andy
Here is how the Hops component has been working up till 8.28
And this is as of 8.29. There’s clearly a regression here, I think something about Annotation Style Overrides was changed in 8.29 which has caused some issue. The text entity isn’t null, rather it assumes a Text Height of 1 which is the default Text Settings when nothing is supplied
Hope this is sufficient to explain the issue.
@AndyPayne could you give me head up for how this will affect 8.29 and beyond?
I am currently affected by this bug in 8.28 and unable to get a fix for it. If this is how Text Entities are going to be treated then I will go about changing by Hops scripts and getting the text height as a string output which I can use in my Main Grasshopper Canvas.
If you guys are going to revert back to the same text entity handling then I wont put in this effort. Please let me know as soon as you can. Thanks
Thank you @kike
When can I expect 8.30 to be launched? A Service Release Candidate of 8.29 was released today…
Hi Kyuubimode -
Public releases of a final Service Release are always on the second Tuesday of a month.
Unless something goes wrong, the final 8.29 SR will be released on March 10th. At that time, the first public Service Release Candidate for 8.30 will also be released.
-wim
Hi @kike,
Has this been solved in the 8.30 release candidate released today?
I don’t think this is currently fixed. There was a change made to the Annotation Base class back in January and this is likely the cause of the issue. We did make some changes to the code base recently, but I just tested this in 8.30 and the problem still seems to be showing up. We’ll continue to look into this. Sorry for the delay.
Hi Andy. Would you advise that I change my scripts to reflect this behavior and output text height, font, etc as a string output from the Hops and re-make the text entities in the main canvas to bypass this? Will this be a more fool-proof way moving forward? Or should I continue waiting on 8.28 hoping that the behavior will revert back at some point?
Since I can no longer update Rhino, stuff like the import content component is causing hindrances and if any other bugs even show up and get fixed, I have been unable to update since a month.
Bumping this topic. Would be grateful to hear back from you guys as to how I should proceed. I’m still on 8.28
Bumping again, would really appreciate some guidance.
Any update on this?
