Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

KaiClavier

742
Posts
10
Topics
639
Followers
66
Following
A member registered Jul 23, 2014 · View creator page →

Creator of

Recent community posts

Hello,


First I need to ask, did you update to the latest version? (v1.14.17) The fix I made should be in there, as well as a few more on top of that related to materials changing mid-string. (like for fonts)

Second, when changing the font, are you calling Rebuild() on the text meshes that need to update? In-editor changing that value will trigger an automatic rebuild just because of OnValidate calls in the inspector, but in-game, changing the font won't trigger a rebuild. If you're setting "_text" when you try changing the text for the language, either call Rebuild() after, or set "text" instead, which calls Rebuild() automatically.


That's my best guesses from this! Please let me know if that helps.

Wait, everything? Including the custom fonts with the Ultra shader dropshadow resizing strangely? (Or if you're not using that for dropshadows anymore that's fine! Can just write this down as something to look into later)

Got the email! Something came up, so I should be able to look at this on Friday, hopefully. But for now, please try using the new version of STM, and see if the MaskableGraphic shadow works properly for you!

(1 edit)


A) For the font size outline issue, please email me the fonts you're using just so I can rule that out as a factor.


B) Shadow disappearing upon complete... These shadows will *only* work when STMMaskableGraphic is on the STM object, so that part is expected. I just fixed the other issue you reported, which could have effected this as well. (Even if it didn't return an error, it could get the wrong index of text used for a font upon rebuilding)


That said, yes I'm seeing shadows disappearing when text is done reading! I managed to track down the issue, STMMaskableGraphic wasn't applying effect data when a mesh was done reading, only while int he middle of reading. I've got this updated and optimized now.


C) That error trace seems to be coming directly from your TestActorVoice script, so I'm not sure how related it is at a glance? What is the list that the out of range exception is happening on, and what is the index it's trying to get?

I think I'll publish what I've got here so far as an update, this is a good chunk of fixes! (Look for v1.14.17!)

Ok yes, I'm able to reproduce this!

I think I've got it fixed, the problem was I was storing "sampleInfoIndex" in sharedMaterialData (per-game data), when it's really something that should be in submesh data. (per-mesh data) Seems to work now that that's moved over! Will try to publish this asap.

Huh, yeah both of those fonts are proper imported fonts, right? Like .ttf/.otf? If so, yeah that looks about right... 

Only idea that comes to mind, which I need to check, is since you're changing from LegacyRuntime to this font by using the <f> tag, I'm wondering if it's *that* fact causing this to mess up. Like some setting is set for LegacyRuntime, and it's carrying over to the other font. I'll be able to give it a closer look this next week!

Ok, good to know!


For now, yeah just try returning if the value is out of range, and let me know if anything appears wrong! I'll be able to dig into this on tuesday

Ok, it's probably due to some sync error with infoCount and  the array of submeshes and I'll look into that tuesday, but uhh... please check the other error you seem to have on STM there!

It looks like this is a UI STM object, but you have a mesh filter and a mesh renderer attached?

(1 edit)

I'm curious to see these custom fonts! I'm saying "bitmap font" but I mean... I just want to see the font's import settings in Unity! 

Basically, fonts that don't inherit from .ttf or .otf behave differently with the Ultra shader, and the way it's determined is in-shader is that they have a certain value (I'm forgetting which, specifically) that's negative instead of positive, s STM/the shader is checking for that. Perhaps you set up your font correctly (afaik, the way Unity does it is *incorrect* according to their own docs...) and this value is flipped so it's acting like the other font type. Or it could be some other metadata value causing it to be interpreted the wrong way, I don't know.


But yes, the STMMaskableGraphic component allows STM to work together with Unity's "Shadow" and "Outline" components (as well as LeTai Asset's "True Shadow" or any other custom Unity UI effect) so... that should be a good option!

Huhhh is this due to custom code editing the materials, or just as behaviour for STM? Just checking to be sure.

I made an update to UpdateMaskingOnAllSubmeshes last month, so was wondering if something like this would happen... still not sure why sampleInfoIndex would get out of sync with info.Count (use infoCount by the way, *that* value should be synced) but yeah I think making sure Submesh_infoIndex is greater than -1 and less than infoCount and returning otherwise would be fine. I'd really just expect this to happen when loading or something like that and correct itself, but if you can figure out the exact timing it happens, please let me know!

Does the error with distorted text happen with other fonts? I'm curious about the import settings for Retron2000Regular. The fact the letters are changing proportions makes me think that it's a bitmap font and that the system I wrote for making things scale differently with bitmap fonts hit yet another edge-case... but that's just a guess! Would it be possible to send me this font with either a link to where you got it or by email?

If you need an immediate quick fix, does it work when you click "Enable support for RectMash2D & UI Effects" and add a dropshadow effect with that? (On the basic Universal shader)



The error where only the shadow renders is just how the non-Ultra shaders will render in URP, so... not really a bug, just what the Ultra shader and STMMaskableGraphic was made to correct. (More efficiently than those shaders!)

Right, this could come up with STM alone in a UI prefab, huh... oh, got it fixed, will push in the next update!

Ah, good catch!! I'll add this for the next update, should hopefully get that this week. I think I was so excited by STMMaskableGraphic *actually working* that I forgot to check GC... oops.


Should hopefully be fine since it's just OnEnable/OnDisable, but I remember it was very specific about how the worker meshes needs to be used, other techniques just wouldn't work.

I made a note about this in the docs! Will push that to the online docs soon. I really wish there was more info about the internals of what exactly is going on here, but ultimately... it's reproducible, it's fixable, and the fix is probably a good practice to follow anyway with how canvases rebuild and the nature of STM updating its mesh constantly.

I'm thinking it's because STM Quads use submeshes. After 1024 objects on a canvas, some optimization or whatever code is modifying verts on a Unity canvas must be running, but doesn't include submeshes. This falls in-line with what I saw with Unity's VertexHelper class when I was writing STMMaskableGraphic - I needed to create a vertex stream for every submesh used on STM, then use the data from those to fuse everything back into one mesh. I got the sense that Unity itself prefers to use a single vertex stream and ignore submeshes from this. Whenever a material change is used in STM, submeshes are used to display multiple materials with a single mesh, so you should see this with font changes, too.

Some resources I found:


https://www.reddit.com/r/unity/comments/18uwwz9/is_there_a_limit_of_only_like_10...

https://medium.com/my-games-company/how-to-optimize-uis-in-unity-slow-performanc...


In my reproduction, if I give HexContainer a canvas, STM's quad renders again. So I think it might just be a Unity limitation on how canvases with many elements are set up. (Maybe once it reaches 1024 elements, it gives up on rendering submeshes? I know Canvases do *some* type of mesh optimization since UI shaders receive verts in World Space rather than Object Space, and default Unity behaviour tends to not like submeshes as a concept (quads use submeshes to render in STM), so I wouldn't be surprised by this.)


So... I think it might be best to split up the hexes and STM on different Canvases! Seems to be a better way to structure a large scene.

OK I've been able to reproduce it!


In Unity 6, I've got a canvas with two children in descending order: HexContainer, QuadText.


HexContainer contains 1000 gameobjects which have a rectTransform and Image component each.

QuadText has a SuperTextMesh object with some text and the default clap quad on it.


The moment HexContainer has 1024 children, the quad vanishes from STM. I need just a bit more time to think about this, but I have a repro scene now so this is great.

Like it's pretty strange... it's *not* a material count issue like I suspected, the moment this condition is met, the actual geometry of the mesh changes! Trying to figure out if this is linked to submeshes... I wonder if this could *somehow* be related to a bug Unity 2019 had I was never able to solve where quads just wouldn't render on canvases in some versions? The end result is similar... Submesh Materials are still being generated, but not rendering at all so it might be something with submeshes...


Still thinking on this, just wanted to post to give an update!! 

(1 edit)

Hmmmm right, nothing looks particularly out-of-place here... Would it be possible to see the hierarchy and inspectors for the hexes so I can better replicate this on my end?

What do the settings for your quad look like? Including import settings for the texture being used?

This feels pretty bespoke, I might have to look at a sample scene to solve this... So quads disappear if there are 80 hexes, regardless of position relevant to eachother...? Hm, I wonder if it could be related to masking depth... but in that situation STM *should* print a warning to the console. iirc Unity can only handle a mask depth of 7.

It could be related to generated materials, but it could also be how STM grabs it's parent canvas for rendering - maybe something is getting mixed up there I can look into on monday. Not totally sure about that since it should be using the same info for text and quads, here.

Does this still happen if you add "STMMaskableGraphic" to the gameObject? If it's already there, does it still happen if you remove it?


Is this happening with The Universal or Ultra shader? Is there a difference between the two?


Also, please try toggling "ZWrite" off if you're using the Ultra shader!


So is this not happening with, for example, a default Image component in place of your map hexes? Are you doing anything with the zBuffer or rendering order with your map hexes...? Or are they *only* composed of masks and polygon collider 2Ds...? If it's just happening with that object, it's got to be some conflicting interaction between them...

(1 edit)

Ok, I think I know what this is... I had to change the behaviour of the <d> tag to insert a zero-width space afterwards since using <d><e=myEvent><d> just compounded on the last character. So the character spacing being set to -0.1 is basically causing double character spacing by moving those zero-width spaces.


Looks like I was accounting for that in a few places, but forgot some... should be fixed, will publish this asap!


EDIT: Update should be out, look out for v1.14.11!

Lovely! Will make sure to get this updated in a build asap!

Hm, I wonder if it could be...

Please try opening SuperTextMesh.cs, and replace every instance of "t.gameObject.activeInHierarchy" with "isActiveAndEnabled". It could be an inconsistency between active and enabled states, where I really should be requiring both at all times. There's a check for this related to the materials system too, but I'm not sure if it's the cause immediately.


And OK that's great to confirm it's the materials system. When the font or material is different, it's fine... Hm I did do some changes a few months back to code there that determines if two materials can be shared, I wonder if there's a value that's not being considered yet that could be causing the old material to be overridden by the new one, breaking the old text. Do you have a material that's being used on both UI and non-UI text? (This technically should be fine, but I could have messed up some values related to stencils, here:) 


Try uncommenting this code that's around line 7475:

//does masking value match
//if(MaterialExists_material.uiStencilDepth != Submesh_stencilDepth)
//{
//  continue;
//}


I removed this check for stencil depth since stencil ID *should* be enough to determine the materials  are different, but perhaps I over-optimized and it's actually required.


If it's neither of these, I'll keep poking around. I feel it's got to be code *like* the commented code above, some value I should be checking that I'm not.

Right, a few updates ago I remember changing the behaviour for enabling STM while a parent gameobject is inactive... 


Are you enabling the STM component, or the entire GameObject it's on in this scenario? Or does it not make a difference between the two? Confirming this will help narrow down the issue greatly - I see some points in the code where I'm only checking for one of these. This and the fact it's happening to all STM objects makes me think it's some type of desync with the internal materials system. 

Do all the effected meshes have the same font and material? Or do they have different settings? If it's only happening to a specific font, that would mean it's related the materials system for sure, which automatically makes text meshes with the same settings share internal materials.


The materials system is basically... Upon rebuilding, STM objects will create and use a cache of materials to render, not the actual material assigned in the inspector. I think toying with these created materials could also cause problems, but I'm not sure how they'd be getting edited externally here. Could there be code in your project that's somehow effecting created materials...?


For the animation event you're talking about, does this refer to a Unity animation event, or STM's drawAnims and event tags? Another guess is... if it's not forceAnimation not being enabled, it could be another variable that's being set automatically. Are you only enabling/disabling the STM object? What is being called in the animation event exactly? With autoRead disabled, I believe it would still call Rebuild() and if the mesh has a readDelay above 0, it would idle on frame 1. (I still don't think it's this but more detail is good!)


Also, what version of Unity are you using? I just remembered that Unity 2019 specifically had some issues with rendering multiple materials on a canvas which I was forced to eventually give up on after seeing it worked fine in 2018 and 2020.


Thank you so much for your patience by the way, I understand how it is to have an issue you can't really show off, so I hope this is at least making a bit of progress!

Hello!


Yeah, that shouldn't be happening... Hm a few things that come to mind from this scenario are...


1. Re-enabling the canvas might not be properly telling child STM objects to re-appear/re-make their meshes. Is this behaviour any different when the GameObject the canvas is on is turned on/off instead? Not sure if I already is, but need to check since this can narrow it down! (If this is the case, will look into why STM isn't updating in this scenario, but that's a quick working fix for you) I have a few  ideas on how to fix this if it's the problem.

2. Inside of an animation, please enable the "forceAnimation" variable on the text, at least for the frames where it will appear/disappear. This was intended as an optimization feature for animating text, but if a parent object is being set active/inactive, I can see the text or certain animations refusing to play. You can also try disabling "autoRead" or enabling "rememberReadPosition"... Those variables are true by default so if I had to guess, it's probably trying to read but refusing to automatically animate during the animation triggering it.


So, please give those a shot! setting the canvas's gameobject active/inactive, and enabling "force animation" on STM.

(1 edit)

Does using a unity Grid Layout and multiple STM object complicate positioning too much? That would be fine for text that's spaced evenly, but I think I've seen a modified grid layout component somewhere that can use the size of what's inside for each row/column. (Together with contentsizefitter & STM that might be a solution)

Anyway, simpler second idea I have: indents and carriage returns!


A string like this will work:

"Damage:<indent=5><u=000D>A</indent>

Defense:<indent=5><u=000D>B</indent>

Complexity:<indent=5><u=000D>Moderate</indent>"




...with "5" being the width between columns (will need to be bigger for bigger text, etc), and <u=000D> being equivalent to "/r", the carriage return, which goes back to the start of a line without dropping down. (and setting the indent changes where the start of the line is)


I hope this helps!

Hm, STM has its own system to combine materials, but on the Ultra shader, at least for now, proper batching is disabled due to how it breaks vert indices for outline and dropshadow effects. (Will experiment with replacing this with index data stored on a UV channel at some point, I think there might be one UV channel free *maybe* so that would possibly allow batching if changed) If you're not using the super smooth outlines, you could try the default Universal shader instead? It's more lightweight compared to the Ultra one too, especially since I wasn't able to complete the optimization pass on the Ultra shader I tried earlier this year. (More on how to still get the outline effect with this soon...)


The material combiner system reduces draw calls if two meshes share the same basic text settings. So same font, same material, etc. Effects like basic color tags do not matter, as those are applied with vertex colour, but the"texture" color tag will make a new material. From your last screenshot, this seems to be the case already, though... So I'm not entirely sure why each component is causing a new draw call. A culling script is a great idea though regardless! (You can also try disabling the STM component but leaving the meshrenderer & meshfilter on, that could potentially give a performance boost, but I have not tested this)


STMMaskableGraphic may help, all it does is let STM behave as a "MaskableGraphic" component properly, so that could be the cause of the Z issue here, potentially. I'm not sure what would have made it not work a month ago, so it's worth another shot! That should hopefully enforce some rendering order features. Additionally!!With STMMaskableGraphic, you can use a basic shader like the default Universal one, and then use Unity's "outline" component to render an outline that way. I also did work with LeTai's assets to get their asset "True Shadow" working together with STM, which can produce a batched, smooth outline if configured properly.  https://assetstore.unity.com/packages/tools/gui/true-shadow-ui-soft-shadow-and-g...


Another small thing to try is, is anything different if you nudge the text forwards a bit? There could just be an issue with the Z buffer somewhere, so if the text and background are on the same layer, I could imagine it getting scrambled together with VR rendering, somehow. (The text is *supposed* to push itself forward a bit with effects like this, but I can see VR as being an edge-case I didn't account for. There's a manual "ZDepth" value in the Ultra shader that might give a better result if adjusted, I can send shader variants soon but I think the Universal shader should be tried first)

If you can let STM do most of the work, see if that works for you! The AutoWrap feature sounds like what you're after, with VerticalLimit being its vertical counterpart. (On UI text, these values are controlled by the size of the recttransform, by the way!!! Unless"ui wrap" and "ui limit" are disabled.) 


The STMMatchRect code in my sample scenes really sounds like what you're looking for - it just takes an existing rectTransform which you can change the appearance of, and resizes it based on text size. (With options for which bounds it's copying.) So please check out the sample scene for that.


What is your monitor's refresh rate? If it's higher than 60, that means the issue shouldn't be something delta-related, so that helps narrow it down at least. (Thinking it's happening on a per-frame basis, rather than a per-time basis) 


Got your zip, will check it out shortly!

Layout issues like that can even stump experts, so it's a bit tough to debug this all without doing it myself... sorry for that!


For the MatchRect script, to be a bit more clear about how it works... Place it on the object you want to resize to match the text's bounds (so in your case, the background) and then in the inspector, you need to drag in the gameObject that has SuperTextMesh on it from the hierarchy into the "stm" field. (Ideally the objects are siblings in this case). 


But it sounds like Adventure creator may be trying to resize the box itself, so this might be the wrong approach... (Sorry it's been a very long time since I've had AC's code in front of me, so I need to guess... If AC is trying to set the box size itself, you need to remove the ContentSizeFitter from STM, and set the anchor presets on its recttransform to stretch. (So it'll match whatever AC is actually resizing) So in this instance, instead of the text controlling the box size, the text is fitting in the box size. Not entirely sure this is the case here though.



I'm actually not too sure what to make of that maybe useful info immediately... does it *only* happen when recording? Could the STM object have anything else on it causing an issue in this instance?


For the script I sent, forget about it for now because it was incomplete and I wanted to expand on it, I don't think it would have changed much in its current state. I also think the MatchRect script might be a more direct fix for this issue. But yes, it has public fields, one for an STM component, and one for a LayoutElement... it's meant to send values generated by STM straight to the LayoutElement, which could be a parent object in your case. It's C# code, by the way!


If I'm not able to solve it like this, I might ask you to sent over a scene for me to edit, I feel like it might just be one thing out of place, and the fastest way to know is by just pushing all the buttons, haha. I'd really like to isolate the issue because it's still not completely clear if it's an issue with STM, AC, or Unity Layouts!

Yeah, I think the problem may be that it's two content size fitters immediately inside of one another (but I'd expect this to effect size, not position... so might be the wrong path to look down?) ...without a layout group or layoutelement to help decide what controls what.


The way the code I sent works is... you reference an STM component, then you reference a LayoutElement component, and the height value from STM is sent directly to the layoutElement's "preferredHeight" field. (Make sure preferred height is enabled on the layoutelement or this does nothing) The LayoutElement is intended to be the parent object of the one STM is on, in this example. I'm catching this before bed, could add the other fields besides height for you tomorrow.


Hm, you said before that TextBoxContainer also has a vertical layout group already, but it *might* work here with using a layoutelement and setting values directly from the child STM object. I'm still not completely convinced this is the error though since it's *always* just returning to the same point before being corrected what I can assume is a layout refresh... so even if we fix the layout refresh, something could still be responsible for the move.

It might also be worth seeing if reducing nesting would help - could txtSubtitles be made a sibling of Panel_TextBG instead of a child? If you go into STM's sample scenes, there's a "MatchRect" script that will let one rectTransform fit to STM with various settings, regardless of parenting. I forgot to mention this before, this is probably a more direct and thorough fix than piggybacking off LayoutElement... probably!


So please give that last one a shot! That might be better since you're trying to size a box based on text size, anyway!

Here's the code, it's quite basic and only copies over one value to the LayoutElement, but could be modified to nab other values, too: https://pastebin.com/XbvqHeCC (I don't want to do it myself because it's the long weekend - maybe tuesday!)

Can the TMP object be moved elsewhere? Curious if it's controlling position at all.


Will think more on this over the weekend, but I'd really just like to figure out... what is trying to make this move back to the origin anyway? Could it be a setting for subtitle location in AC or something...?

Perfect! I'm glad it works, I'll just link to your post on the Helper Scripts page!

Hi! I saw your post with John, let's see what's changed in the last 9 years... (A lot has changed with how Unity UI handles layouts as well)

Immediately seeing, the fading animation starts and then continues as the position corrects itself...

Assuming this is Unity UI... 

1) Try replacing "supertext.Text" with "supertext._text", this is something that I think might have changed in the last 9 years, but I'm not completely sure if it's the issue here. ("Text" I believe used to update text WITHOUT calling Rebuild(), while "text" would, but now "_text" has this function, so the issue could be that Rebuild() is being called twice here and some layout code is getting confused)

2) Try replacing "supertext.RegularRead()" with "supertext.Rebuild(true)", which I think should have the same effect, guaranteeing STM will both rebuild and read at the same time.

3) Try adding supertext.rt.ForceUpdateRectTransforms() after the "RegularRead()" line is called. (Assuming this is on Unity UI) That might force the layout to rebuild if it's a layout issue. You can also try "LayoutRebuilder.ForceRebuildLayoutImmediate()".

4) I'm also guessing at this but... does your STM object have a ContentSizeFitter on it? I've been running into some problems with nested layouts and contentsizefitter in just the last few days actually and wrote myself a rudimentary script to make sure the effects of ContentSizeFitter happen frame 1 with STM, rather than waiting for the layout update. (It just forwards information to a LayoutElement component) So I could try sending over a cleaned up version of the script with this, but with any luck it's one of the first 3 issues.


These are my initial guesses! There's nothing in that code that should be effecting text position besides those 3 things there, so there's a chance it's how AC works now... I can take some guesses at how *that* might work, but I don't use it myself! (I could ask the dev, but I'll try guessing first...)


5) What is the parent object of your STM object? Is it also moving when the text moves? What is making it move? (Thinking maybe AC is trying to use the position of the hidden text object to decide where STM should go, but not sure how it would play initially then decide to move after a few frames...)


Let me know if any of these help!

Ok those screenshots and description help a lot! Here's some things to try:


In the inspector try disabling ZWrite. This is basically there just to make it so Ultra shader outlines don't go over the previous letter, but if your outlines are thin enough you may as well disable it, it can *sometimes* cause something like this to happen if text is is a 3D space like this, rather than being on a UI. I feel like this shouldn't be happening with ZWrite on though, so if this solves it I'll look into how to prevent it from being a problem in the first place.


I'd also check out the rendering order of those objects in the background, is their render queue above 3000? You can try changing the render queue value on STM's material settings to something higher!


Do you get a result similar to what you want when using the Universal shader (plain version with out outline) then adding an outline through STMMaskableGraphic? That's also an option for rendering outline effects now, too!

Ah got it, so yes for the Universal shader there, that is just what it does and why I made the Ultra shader. (But apparently it works fine in builds?)

Do you have any screenshots of the weird artifacts in the Ultra shader? It sounds like... hm, the material/font is changing, but the UVs don't update to match immediately which they really should. Saving *should* usually correct that, but that's odd... if an error showed up that got cleared (an error I would like to fix btw), STM might have entered a stalled state. If you select the object in the hierarchy and press ctrl+d to duplicate it, does anything change on the new object created?

Hey!

Are you sure this is the Ultra shader? Normally the UI on the inspector there should change when it's been applied, and in your screenshot it's showing the configuration for the Universal shaders. (Additionally, the rendering going on here is what I would expect the Universal shader to do in this circumstance, where it's only rendering the final pass of the outline and ignoring the text pass) So please try clicking the "Ultra" button next to the shadier field on the inspector to apply that shader to your material. Please let me know if that makes a difference.


If nothing changes when pressing that button and you don't get any errors in the console, try saving your scene as that will force STM to rebuild the material settings.

The board sizes impacting the usefulness of different blocks day-by-day was a consideration in design for sure! There was such a focus on mobile and mouse controls, I had completely forgotten about arrow keys existing until just this moment. I'll see if they can be added in!

Unclosed tags will not lead to any issues with how STM currently works, and if I were to add this tag stacking change I would also not require tag closing! As it stands, when text parses, it just goes forwards, not backwards.


(There's some benefits to the current system by the way... color tags of a different type can stack (color, gradient, texture) but now that I've got the combo color tag (<c=myColor,MyGradient,myTexture) and customizable color-mixing rules for color data, adding an alternate tag parsing system could be interesting...)

Well, with the current way it works, the closing tag means that *any* closing tag (not just fonts) will return to the default setting for that tag, which has its own uses! (But there is the <clear> tag already for clearing everything to default I suppose...) I guess I think of them more like programming the text as it's read out, rather than formatting existing text? I think I wrote a bit about this system int he docs, but I could make it a bit clearer. Anyway, should all still be workable!