Integrating TurboBadger to Urho3D-master shows some weird graphical artifacts, e.g. lines above fonts, lines inside boxes and radial buttons, shown below.
Same code and data in 1.4 didn’t show any of this.
Where should I look to debug this problem? I’m thinking batch process or shader routine.
Both code base can be found here:
Using the same code and data in 1.4 didn’t show this, a pic from 1.4 below. It’s a screenshot that I took of my implementation and not a pic from Turbo Badger’s github.
I haven’t started digging into this yet, as I have no idea where to look, but I can start with diff’ing the UIBatch render process.
Looks like texture bleeding to me too.
Notice how it mostly happen above upper case letters and special characters.
Maybe texture filtering changed somewhere? I’d try to test with no filtering.
Maybe adding 1 pixel padding around glyphs if nothing else works.
I got those kinds of artifacts from enabling multisampling a while ago.
Thanks for your input.
I looked at the graphics settings for 1.4 and 1.5 and they both have multisample set to 1. I diff’d the UI code and didn’t see anything different that would caused this problem. Still no resolution.
[quote=“Lumak”]Thanks for your input.
I looked at the graphics settings for 1.4 and 1.5 and they both have multisample set to 1. I diff’d the UI code and didn’t see anything different that would caused this problem. Still no resolution.[/quote]
Try to disable filtering (completely) regardless of changes.
Setting multisample = 0 had no effect - still see the same artifacts.
I built OpenGL version of 1.5 and there is no graphical artifacts. It’s clean as what’s seen in 1.4.
Just don’t use DirectX, ha.
But seriously, I diff’d DirectX9Texture and Graphics files and didn’t see changes that would cause this. There’s something else I’m not seeing.
Ok, I’ll look into that next.
Here’s the recap:
[li] 1.4 OpenGL - no issue[/li]
[li] 1.4 DirectX9 - no issue[/li]
[li] 1.5 OpenGL - no issue[/li]
[li][color=#FF0000]1.5 DirectX9 - artifacts[/color][/li][/ul]
If you mean engine MSAA than that’s not what I meant.
I meant texture filtering, disabling it by using FILTER_NEAREST.
Though just sticking with OpenGL is a valid solution.
In the RenderBatch() func, all incoming batch are padded to the end of the vertexbuffer:
unsigned begin = batch.vertexData_->Size();
batch.vertexData_->Resize(begin + _pb->vertex_count * UI_VERTEX_SIZE);
float* dest = &(batch.vertexData_->At(begin));
It’s similar to how UIBatch class constructs the batch data. Here is a sniplet from UIBatch::AddQuad() func:
unsigned begin = vertexData_->Size();
vertexData_->Resize(begin + 6 * UI_VERTEX_SIZE);
float* dest = &(vertexData_->At(begin));
vertexEnd_ = vertexData_->Size();
dest = left;
dest = top;
dest = 0.0f;
((unsigned&)dest) = topLeftColor;
dest = leftUV;
dest = topUV;
Except my code is in a for loop. If I wasn’t accounting for offset then I imagine I would not get anything to render except for garbage.
edit: added uibatch::addquad() code sniplet.
again, below is a pic from 1.4 DX9
I thought you could’ve meant that, so also did that test but forgot to mentioned it. Using the FILTER_NEAREST filter initially showed like it would work. The very 1st window in the TB demo looked like there were no artifacts but the remaining windows had it.
I don’t know the implementation details, but maybe each window uses it’s own texture and you only disabled filtering on a single window?
All TBTextures are created by a overriden Texture ctor and where the filter was set. So, every TB demo window and textures went through the same ctor.
Sounds like a “should”. Did you confirm that the windows with the artifacts have unfiltered texture?
Maybe something changes it later?
Maybe only the first window uses that constructor?
Now I understand what you mean. And I stand corrected in regards to my claim that the pic was from DX9, I looked at my build again and it was OpenGL.
All fixed! Thanks for your help!
Re: graphical artifacts help
PostPosted by Sinoid ? 08 Nov 2015, 21:09
I did your work for you.
I said this:
I'd look at texture coordinates and check 'border' colors and texture border modes. Looking at the lines around the colored text portion it appears that the lines are areas of "off glyph" texture that's bleeding through.
If you can get a dump of the rasterized font I'd look at that and compare it to the offending characters to see if there's any stand out indicators (ie. maybe the font rasterize only writes alpha where it thinks it needs to instead of everywhere).
Then I'd look at whoever/where-ever the font is rendered into an image (as in turning a TTF into a bitmap).
And then you said this:
I haven't started digging into this yet, as I have no idea where to look, but I can start with diff'ing the UIBatch render process.
What is that: “I have no idea where to look” … I gave you a detailed list of exactly where I’d look. You’re implementing a third party library but incapable of looking into that library? You’re implementing a third party library without even thoroughly reading the documentation available?
I can tell you exactly how to adjust Recast/Detour/DetourCrowd to account for multiple agent sizes in exchange for speed - because I implemented that stuff and understood the library I was working with before I picked up the work before me.
You’ve expressed nothing but “terror” at the thought of investigating TurboBadger.
The 0.5,0.5 offset IS IN THE DOCUMENTATION! RTFM! There is no good reason for anyone to believe that your implementation of TurboBadger is worth using. You’re clearly afraid of TurboBadger, and you very clearly are lacking in ability.
So tubobadger isn’t filling my view horizontally, what’s wrong?
Find an answer.[/quote]
LOL, I don’t know what to make of this, but AWESOME JOB in doing all the work! You are the best!
And maybe you should get back on your meds! LOL
Since the OP issue is already resolved, I lock this thread for now so it does not go off topic.