Text mesh in ground plane

[mwpowellhtx]

No. Uncomment the draw text lines; I don't care about the z-fighting, per se. I do care that there is a textures bug preventing the draw of a simple text.

[jerome]

you are missing the parameter scene in your creation call : http://www.babylonjs-playground.com/#1TP1KF#5

[mwpowellhtx]

15 minutes ago, jerome said:

you are missing the parameter scene in your creation call : http://www.babylonjs-playground.com/#1TP1KF#5

Good catch.

Check it out, however, then it doesn't work. I get a "black", not a "red" plane, and no text whatsoever.

I could be missing something, but this is about as minimalistic an example as I can think of taking into consideration some of the example work I have reviewed.

[JCPalmer]

Would not making an off-line texture in a graphics program be a better option.  You then know things are going happen in 1 draw.  How many draws do you currently do just to display the field with all those lines? (turn on debug using scene.debug = true)

True, there would be waste, since the texture file is square, but field rectangular?  Might be a little blurry on very big screens, but think resorting to dynamic construction, and fonts on different systems is not worth it.

[mwpowellhtx]

Off topic @JCPalmer. Don't care about that right now; non sequitur given the application scope.

[mwpowellhtx]

Added colors to the playground, now the inner plane is appearing black; nothing is rendering for the text at all. This is consistent with the application scope.

[jerome]

http://www.babylonjs-playground.com/#1TP1KF#7

[mwpowellhtx]

Got it. Man alive, a lot of moving parts, but I have a better understanding of it now. Thanks a bunch ALL.

After working with it a little more "in situ", I will consider what changes might be relevant and submit the corresponding PRs as they make sense to do so.

[adam]

I'm glad this was resolved.  I'm hoping future issues go a little more smoothly for you.

[mwpowellhtx]

@adam Thanks, this one was kind of brutal, but there are a lot of moving parts. Anyhow, I've at least got a sense of what I'm dealing with, which is half the battle.

[mwpowellhtx]

And now for the results (for now).

Figuring the fonts, height, width, and positions, are a bit tricky; plus there is coordinating the plane with the fixture dimensions, to name a couple of things. But that's (somewhat) beyond the scope of BABYLON (and/or WebGL), unless it isn't.

Center doesn't seem to be quite center, but I think there are also some options issues in the DynamicFixture that need to be sorted out.

Yes, still with the z-order thing, I know. In a way, though, I kind of like the effect, it's like the lines are faded or have seen some weather. Anyway, neither here nor there.

 

[mwpowellhtx]

A little better angle. And tweaked font, font size, and orientation.

[GameMonetize]

If you want to get rid of the z-index issue just set material.zOffset = 1

[mwpowellhtx]

@Deltakosh Just tried that, and the numbers vanished. For which material(s)? And to which zOffset? Bear in mind all of the dashes are themselves Ground as well. So, to a value such as what, 276? Sarcastic, but you get the idea.

[mwpowellhtx]

Ah! m.zOffset = -1

[GameMonetize]

here you are

[mwpowellhtx]

Although, that works for the numbering, but apparently not for the lines or hash marks (grounds/planes). It's okay, minor issue, not concerned about that. See other post re: DynamicTexture changes.

[jerome]

just a naive question : if your texts are known in advandce and fixed forever, why using some text based dynamic textures instead of a single baked texture ...say, a single image with all the text values you need (10, 20, 30, etc) that could be easily done with any text soft ?

[mwpowellhtx]

@jerome Yes, it is naive. Because the field may not always be 100 yards; may be 50, or even 110. Or some other custom number.

[jerome]

ah ok .. I  thought it never changed