• 14
• 12
• 9
• 10
• 13

# cube texture with ray tracer

This topic is 4205 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I added a cube texture to my ray tracer but there are seams along the borders: http://img50.imageshack.us/img50/6954/seamds7.jpg You can see the left seam going up clearly. There is also a subtle seam at the top going from left to right. Anyone know what might be causing this? I checked my six images in photoshop and they are seamless. I determine the face the lookup vector hits by looking at the coordinate with the largest magnitude. Then I use the other two coordinates as 2D texture coordinates on that face, transforming them to [0, 1]. For example, the code to handle the case where the x-coord has the greatest magnitude (mag) and is positive: case POS_X: { u = 1.0f - 0.5f*(texC.z/mag + 1.0f); v = 0.5f*(texC.y/mag + 1.0f); j = (int)(u*(width-1) ); i = (int)(v*(height-1) ); return image[POS_X][i*width+j]; } Obviously some filtering could hide the seams a bit better, but should it be seamless without it when working per pixel?

##### Share on other sites
You need to be careful when rounding your coordinates obviously, because they could end up the wrong side (outside) of your texture.

If you cannot ensure that your calculation will end on the right side, you can always clamp (saturate) before doing the texture read :

    i = min(max(i, 0), width - 1);    j = min(max(j, 0), height - 1);

LeGreg

##### Share on other sites
You also made a mistake when scaling your texcoord.

When going from normalized to unnormalized texture coordinate, the scaling ratio is not (width -1) but (width), because you're expanding the range from [0..1[ to [0..width[.
Of course then you increase your risk of overreading (reading outside your texture), but it should be okay if you're clamping your coordinates correctly.

LeGreg

##### Share on other sites
I am going to assume that all of your observed error points fall at a place where one of your earliest definitions is ambiguous:

"I determine the face the lookup vector hits by looking at the coordinate
with the largest magnitude."

The errors crop up when you have MULTIPLE scalers with equal magnitude (or close enough to be considered equal given the expected error margin due to FPU rounding issues)

Given this, you should be able to devise some test cases where you feed the texture lookup both possibilities at your observed error points.

Tracking the lookup calculations by hand will show you WHERE in the calculation they diverge... and that should lead to WHY they diverge.. and then hopefully HOW to solve it.

In addition to potentialy solving your problem, you are garanteed to learn a thing or two about your calculation pipeline and its rounding issues which is always a good thing.