Cracks between textures

OpenGL Development JOGL Development
#1

I’ve been working on getting textures into my brute-force terrain, and the odd cracking problem has arisen.

My video card is Radeon 9500 pro/9700, and the following details concern when the cracks appear:

Texture size Result
32x32 *no texture drawn at all
64x64 *texture looks fine
128x128 *cracks between textures
256x256 *texture looks fine
512x512 *cracks between textures
1024x1024 *texture looks fine
2048x2048 *computer locks up, even though
OpenGL reports that this size texture is
supported.

If more info is needed, I will happily supply it.

Thanks alot.

#2

would a quick screenshot be possible?

#3

Ary you sure the problem is caused by the size of the texture? Sounds like it could be a t-junction problem.

#4

I’m not seeing how to post a screen shot here…I’ve got the IMG tags, but don’t see how to specify the location, which is C:\cracks.png.

Anyway…the cracks are appearing in a brute-force-regular-grid, so I suppose where two or more square sections of the grid are in the same plane there would be T-junctions, although I admit I never thought about it.

How much variation is needed to avoid the T-junctions?

#5

This board doesn’t support attachments, therefore you’ve to upload the file somewere else. The webspace needs to support so called hot linking, which most “free” thingies just doesn’t allow. And even if… there are still alot of annoying settings and restrictions, which can be quite annoying. The best thing you can do is buying some space together with a decent domain. Something like 2$/month for some space and some traffic and for about 5$ you can get something usable (php, mysql, 500mb, 50gb traffic incl, fast connection etc).

#6

Thanks for the info on the screen shot posting.

As far as the T-Junctions go, I looked in the Red Book, and I was wrong…it looks like a Brute-Force Grid would never have a T-Junction, so I don’t know what the deal is.

Sometimes if I recompile the exact same scene the cracks go away, only to return on the next compile.

#7

Zahl: Quick note: check your private messages.

Cheers,

ribot

#8

On behalf of zahl:

All of the white or gray lines you see should NOT be there!

http://www.liquidmatrix.co.uk/images/cracks.png

#9

Thanks very much, ribot.

Now…all I need is an answer to the mystery of my crap texturing job :slight_smile:

#10

An added note: when I added the following two lines of code, the gaps between the textures became totally transparent, even though no transparency was specified in the textures themselves.

gl.glEnable(GL.GL_ALPHA_TEST);
gl.glAlphaFunc(GL.GL_GREATER, 0.5f);

I certainly hope one of you folks has an idea on this :slight_smile:

zahl

#11

I’d have a good look at your texture loading routines, what are you using to create the textures? You might just be loading too little data into OpenGL and you get some default white pixels.

Try making a simple solid black texture, with a one-pixel border of various colours on different edges. Then you can see if you’re missing some of your texture or if you’re getting some extra pixels from somewhere else.

#12

OK, OrangyTang, I made a solid black texture with a bright pink, one pixel wide border, and the pink stripe does not make it into the final texture on the top side.

But…somthing else I have noticed is that the ‘white stripe’ that is showing up as the error isn’t always white…sometimes it has what looks like fragments of other images in it, and they aren’t always the same.

While I wait for further advice, I will begin going through the texture loading routine and see if I can find anything.

Zahl

#13

If you’re seeing random images in your rouge stripe that probably means you’re getting whatever happened to be in video memory at that particular point, and you’re not uploading enough actual data to fill over it.

If you hunt though past topics in this forum you’ll find Kev’s texture loader classes which I’ve used before and works nicely. Failing that, have a look at your glTexImage2D use and make sure all your parameters are correct.

#14

http://cislab2.cbpa.louisville.edu/k0myer01/cracks.png

After getting the fancy texture code from the forums, my PREVIOUS cracking problem went away, and has revealed what I believe to be a seperate problem.

As you can see, there are tiny cracks now, and I think it might be due to some sort of round-off error since my vertex values are calculated, and I most likely don’t have it done right :slight_smile:

Big improvement over the previous mess anyway.

And…I can host my own pics now, so thanks for the advice on that point.

Zahl

[edit] I forgot to add that I am quite open to suggestions if the answer is apparant to anyone…

#15

If anyone is still interested, I have found the reasons for my previous problems.

  1. The small cracks in the second screen shot: setting the wrap mode to repeat fixed this.

  2. The large white bands in the first screen shot: turns out they weren’t really fixed when I thought they were. The first time the app was run the bands would not appear, then, every time after that they WOULD. Restarting the machine would reset the process, so the bands would NOT appear the first time.

My program’s display method calls a function to draw the HUD, and whether or not this method is accessed is controlled by a boolean which is linked to a key press. If the program is set to draw the HUD during initialization, the bands appear. If the program is NOT set to draw the HUD during initialization, the bands do NOT appear. Turning the HUD on after the program is running causes no errors.

I admit that the ‘why’ of it is beyond me. If anyone wants to take a crack at figuring out why, I’ll put some code up, but I’m not asking anyone to. I think I’ve asked enough questions on this particular topic, and will have to figure it out myself and live with it until I do.

Zahl

#16

The problem is not quite what you believe it is. In OpenGL textures have a border area, which is typically one pixel wide. What the WRAP boundary mode does is just use pixels from the other side of the texture to fill in that border space. This is fine if you have a texture that is designed to tile, but if you don’t (eg skybox textures), then you’ll get some very odd looking artifacts in the rendering.

Instead, what you want to do is set the wrap mode to CLAMP_TO_EDGE so that the border is removed completely. Your code should look something like this:

`
int[] tex_id_tmp = new int[1];
gl.glGenTextures(1, tex_id_tmp);
textureIdMap[side].put(gl, new Integer(tex_id_tmp[0]));

        gl.glBindTexture(GL.GL_TEXTURE_2D, tex_id_tmp[0]);

        gl.glPixelStorei(GL.GL_UNPACK_ALIGNMENT, 1);
        gl.glTexParameteri(GL.GL_TEXTURE_2D,
                           GL.GL_TEXTURE_WRAP_S,
                           GL.GL_CLAMP_TO_EDGE);

        gl.glTexParameteri(GL.GL_TEXTURE_2D,
                           GL.GL_TEXTURE_WRAP_T,
                           GL.GL_CLAMP_TO_EDGE);

`

#17

I’m very grateful for that post :slight_smile:

I was looking at the CLAMP_TO_EDGE argument in the BlueBook last night, and wondering what it was all about.

Zahl

#18

OK, the correct uses of GL_CLAMP_TO_EDGE, and GL_REPEAT have been made clear, so what situation calls for GL_CLAMP? It seems like the first 2 cover all the bases: tiling and not tiling…

Thanks,

Zahl

#19

Haha ;D

Well, ok the correct implemention of GL_CLAMP can’t be used for anything (I thought about it for awhile and even asked others - no one knows for what you can use such a thing). The correct implementation of GL_CLAMP is like GL_CLAMP_TO_EDGE but it’s interpolated to the color of the vertex at the edges (usually black).

I have really no clue for what you might need such a thing. Well, back in the old days there wasn’t GL_CLAMP_TO_EDGE, but everyone needed something like that. “Fortunately” GL_CLAMP usually was just “broken” and worked exactly like GL_CLAMP_TO_EDGE. But… oh well… you can’t rely on a broken GL_CLAMP - therefore you should use GL_CLAMP_TO_EDGE (1.2+).

Q3 for example used GL_CLAMP (instead of GL_CLAMP_TO_EDGE) for the skyboxes, therefore you can see it’s edges on newer systems.

So… just use *_TO_EDGE if you can and everything is fine.

#20

Well I have learned quite a bit from this thread, and that last post was very interesting indeed :slight_smile:

Thanks!

Zahl