Texture Coordinate Wrapping (Split from Port Requests)


lunixbochs

Moderator
Staff member
Joined
Sep 18, 2011
Messages
742
Ok, Found it. In fact it was a precision issue with the texture!
That's the same conclusion I came to with IMG support (precision problems with large coordinates).

Does wrapping the coords between 0 - 1 after dividing by 128.0 instead of before the cpu division have the same effect?
 
Last edited by a moderator:
Ok, Found it. In fact it was a precision issue with the texture!
That's the same conclusion I came to with IMG support (precision problems with large coordinates).

Does wrapping the coords between 0 - 1 after dividing by 128.0 instead of before the cpu division have the same effect?
I'll test that (you suspect a "float" limitation and not a driver limitation?)
 
So yes, it works also.

I used this (quick and unoptimized) code (for the road part)


float p, p3=pos/128.0f;
double p2;
p=modf(p3, &p2);
glTexCoord2f(0, -p);
glVertex3f(r_x1, r_y1, r_z);
 
glTexCoord2f(0.75, -p);
glVertex3f(r_x2, r_y2, r_z);
 
glTexCoord2f(0.75, -(p + inc/128.0f));
glVertex3f(r_x2[i + 1], r_y2[i + 1], r_z[i + 1]);
 
glTexCoord2f(0, -(p + inc/128.0f));
glVertex3f(r_x1[i + 1], r_y1[i + 1], r_z[i + 1]);
//glEnd();

And I get the correct picture (the upler midle glitch is just the picture being refresh of course).

 

So I guess you can clamp texture coordinates inside glshim :)

test5.png
 
Won't this break on subsequent coords ending in zero?

(2.0, 2.0), (3.0, 3.0) would become (0.0, 0.0), (0.0, 0.0)

when in reality it should be (0.0, 0.0), (1.0, 1.0)?

So I can detect greater intpart and assign 0x0, 1x1 to the larger. What if this happens 2+ times in a row?

Like 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0

This fix also needs work if the tex coordinates span multiple lengths of the texture (for a repeating texture): (0, 0), (2, 2) would shrink if we put it in the 0, 1 space...

How big is p2?
 
Last edited by a moderator:
p2 goes up to a bit more than 5000 in the demo level. *EDIT* No, 5000 is just pos. but p2=pos/128 is 391...

In that case, you keep the fractionnal part as-is and limit the interger part to -1,0, +1  and rebuild the texture coord with that?
 
Last edited by a moderator:
K, do you also know how big the glDrawArrays vertex counts tend to be?
 
Last edited by a moderator:
Herer are some printf from previous code

pos=-50094.320312, p3=-391.361877, p=-0.361877, p2=0
pos=-50078.375000, p3=-391.237305, p=-0.237305, p2=0
pos=-50062.429688, p3=-391.112732, p=-0.112732, p2=0
pos=-50046.484375, p3=-390.988159, p=-0.988159, p2=0
pos=-50030.539062, p3=-390.863586, p=-0.863586, p2=0
pos=-50014.593750, p3=-390.739014, p=-0.739014, p2=0
pos=-49998.648438, p3=-390.614441, p=-0.614441, p2=0
pos=-49982.703125, p3=-390.489868, p=-0.489868, p2=0
pos=-49966.757812, p3=-390.365295, p=-0.365295, p2=0
pos=-49950.812500, p3=-390.240723, p=-0.240723, p2=0
pos=-49934.867188, p3=-390.116150, p=-0.116150, p2=0
pos=-49918.921875, p3=-389.991577, p=-0.991577, p2=0
pos=-49902.976562, p3=-389.867004, p=-0.867004, p2=0
pos=-49887.031250, p3=-389.742432, p=-0.742432, p2=0
pos=-49871.085938, p3=-389.617859, p=-0.617859, p2=0
pos=-49855.140625, p3=-389.493286, p=-0.493286, p2=0
pos=-49839.195312, p3=-389.368713, p=-0.368713, p2=0
pos=-49823.250000, p3=-389.244141, p=-0.244141, p2=0
pos=-49807.304688, p3=-389.119568, p=-0.119568, p2=0
pos=-49791.359375, p3=-388.994995, p=-0.994995, p2=0
pos=-49775.414062, p3=-388.870422, p=-0.870422, p2=0
(I messed up the printout of the integer part) 

From the screen output, I count 504 vertex.
 
Last edited by a moderator:
Back
Top