hi
We have a quite serious Text2D quality problem. On some backgrounds the characters look really ugly. I first thought, this could be solved by not drawing them transparently ind setting the color through the Coloring Attributes of the Shape3D, but drawing them in the desired color. But it didn’t do the trick.
Does anyone have an idea or know the solution? Matthias and Goliat, you’re famiiar with Textures and Text2D. Do you know anything about that?
Marvin
The glitches only happen when you resize the textures. When they are displayed 1:1 they look absolutely perfect. That’s why we should make new textures when the HUD is resized, and not resize the existing textures. That’s also why one image for button theme is not enough. 9 is what we need (topleft, top, topright, right, bottomright, bottom, bottomleft, left, center).
[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:28047"]
The glitches only happen when you resize the textures. When they are displayed 1:1 they look absolutely perfect. That’s why we should make new textures when the HUD is resized, and not resize the existing textures.
[/quote]
Do you mean, the fonts look ugly when the underlying texture is resized? Sounds strange.
[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:28047"]
That’s also why one image for button theme is not enough. 9 is what we need (topleft, top, topright, right, bottomright, bottom, bottomleft, left, center).
[/quote]
Yes. That’s true.
can you specify ‘ugly’ ? … i had no problems in scaling the Char2D’s … (which is why i created no scaling method)
Do you mean, the fonts look ugly when the underlying texture is resized? Sounds strange.
[/quote]
Huh no that not what I mean. When a texture sized 512x512 appears 520x520 on the screen, it looks strange cause it’s resized by the graphic card. The only way to avoid that is to make it display truly 512x512, or to create a new texture with the appropriate size.
Please have a look at HUD3DTest and you’ll see the effect. And the effect is only well visible on small fonts (font-size 15 or below or shinked ones).
[quote="<MagicSpark.org [ BlueSky ]>,post:5,topic:28047"]
Huh no that not what I mean. When a texture sized 512x512 appears 520x520 on the screen, it looks strange cause it’s resized by the graphic card. The only way to avoid that is to make it display truly 512x512, or to create a new texture with the appropriate size.
[/quote]
Well, the fonts aren’t scaled on the HUD. They’re displayed in the exact texture size.
magnification and minifications filters are handled via texture paramters in OGL, if the textures become ugly when you get closer to them, its probably because your using the ugliest (but fastest) method to obtain the pixel from lower resolution texels, and thats GL_NEAREST.
Read up on GL_MIN_FILTER and GL_MAG_FILTER
DP
Hi!
Just my 5 cents. I had a look at HUD3DTest and what I see, to my opinion has nothing to do neither with scaling neither with filtering. BTW, base_lever_linear is applied as “mag” and “min” filters in Character2D, so filtering is definetely not the problem here. Scaling, even if it does - still will not create that kind of picture…
There is something different. Those “things” we see around charatcers - they are artifacts, this is not what was actually drawn as character - it seems to be just improper result of blending! You can see that it is not distortion, the color “corona” oround characters exists and that color is not the color of character…
So, I think transparency have to be considered, blending and whatever things migth be regarded to it.
Bohdan.
EDIT: @Marvin: Try to remove backgrounds for your “panel1” & “panel2” (totaly remove, no default) in HUD3DTest and you will see that those corrupted labels suddenly looks just fine!!
Yes, I know. But this is not an option. There must be the possibility to display a characater over a background.
btw. Thanks for your troubles.
ah … i guess i know what you mean … i had the same problem in the text2d demo … i guess it is due to the way java2d renders the characters on the image …
i guess they are antialiased somehow which results in a conora …
greets … Golly
No-no, there is no problems to display the character over the background. Do the folowing change to your HUD3DTest and you will see that:
instead of panel1.addWidget(infoText, new Point2f(10, 82));
just add that label to the top “container”: this.addWidget(infoText, new Point2f(10, 82));
(and regulate location a bit so the label is over your panel1)
and you will see it is just perfectly displayed!!! and over all the underlying images/backgrounds.
So if that label is in panlel1 OrderedGroup - you have artifacts, if it is simply out of it (but the screen looking same way) - perfect. So, I still think there is something to do with maybe blending order or sorting etc… - well I don’t know.
You will probably will be laughing but once when I have that problem I switch off the DepthTest on ceratin things - and everything become perfect. So there is nothing to do with your HUD, there is more general problem, and if you want I will prepare for you test-case, where the problem showing up and the way to fix it - but it will be up to you to figure out why it helps ;), because I have no clue 
Hopefully today if I will have time.
Yes, you have antialiasing ON in you character2d, but it is good thing. At some stage I used a lot of java2d drawing things and never have a problem with that. Try to switch antialiasing off and you will see that the problem still persist. It is more a guess, but as I mentioned above, simply putting that characters to different node in the scenegraph - resolves the problem totaly… And now the question is - why ??? ??? ??? What makes suddenly a difference… :-\ Something to do with Xith transparency/sorting/orders/blending etc… don’t know…
Thanks for your huge reply.
I worked half the day on this problem. But I can’t solve it. It seems to have something to do with a background image in the “wrong” group. When I don’t give the Panel a background image but add an Image Widget to it which has a lower z-index than the Label, it just looks great. But I can’t see the difference for xith. ???
I tried to directly add a Quad and a Text2D node to a TransformGroup and even then the shit started to happen.
You are welcome
Yes, that’s what I was surprised with too… Shouldn’t do any difference… or maybe we just don’t understand something…
Just want to point on another, I think pretty explanatory example (as what is the story about), just to destruct attention from the Labels, because it is more general problem.
In you HUD3DTest change:
Widget william = new Image(40, 40, 3, “HUD/DropshadowPanel.png”, true);
See attachment (well I changed HUD background to WhiteBackground.png…, but just for the sake of better “contrast” )
As you see it is clear that the problem is that that image william or Label or whatever transparent and blended is there, no matter what is in some reason blended not with the underlying backround of the panel widget but with HUD background. If you put Blue background, blending corona would be blue etc…
Exactly same is corrupting and label too… Funny staff… have no idea why, but it is clear - it is blending/transparency etc problem. Something wrong with it in xith… seems like at least… hmmm…
BTW, you are using OrderedGroup… just wonder why?
I realized this blending problem, too. But it doesn’t always occurr (strange). In the case I descripbed in my last posting (not setting the background image of a Panel by calling the setBackground() method but adding an Image Widget) the artifacts didn’t come up. So just as you say: Maybe there’s something, that we don’t understand…
It doesn’t seem to be necessary. I inserted this one to ensure, that the parts of an assembled Widget are rendered in a certain order and to avoid using the z-index mechanism, which is nothing more than translating in z-direction in a minimum (-effective) step, which is 0.0001f. Well, anyway I think, I can leave this group.
OrderedGroup is anyway something I don’t really understand. A normal Group like TransformGroup also has an order. So what is the OrderedGroup for? Somewhere I read, that xith (or JOGL or something) sorts nodes for their blending attribute. So blended nodes are rendered first (or last?). I can’t see what this is good for. There can’t be a preferred order any mechanism knows of from itself. So the only order to be honored should be the insertion order of the group’s children. In that manner the sense of OrderedGroup is no more and this class could be removed/deprecated.
But the bleding problem stays. Could please someone, who knows these internals look at the code?
Marvin
I actually asked for purpose ;). I have seen that you have “zIndexUnit” defined, but I was suspecting as well that you might not everywhere use it since there is OrderedGroup mentioned. To say true, I didn’t clearly understood from you answer, are you still using z-translations togather with OrderedGroup, or because of OrderedGroup you don’t need using that translations?
Bacause if you don’t - it might be (probably) explanation to the problem. I have mentioned above in the post that once I have the problem just the same!, and I have to switch DepthTest… to be specific it was when I had two coinsiding (same z-translations) geometries and I needed blending to work!!! For example if background z-translation (absolute!) would be same as in other transparent Shape3D there would be a problem.
As Yuri Vl. Gushchin explained once, OrderedGroup really works (well, I still not totaly agree with him, anyhow - I believe he know better :)) either for transparent pass, either opaque, but not in combination. In combination you need to make a difference in their absolute z-translations (well, it works for me)…
In general, what about OrderedGroup see this thread:
http://www.java-gaming.org/forums/index.php?topic=12856.0
Just wonder if there is any progress with that issue?
Sorry. I had so much to do. So had left it aside for the moment.
I fixed the problem by accident It seems to have something to do with the order the TransformGroups have in each other. But since I don’t understand the logic behind it (there should be no difference), I guess the problem may occurr again in the future. But for the moment it is fixed.
I do love that kind of accidents.
Great!!! ;D
@Qudus: Could you please briefly disclose some details, coz I’d love to steal your solution! ;D