Jump to content
  • Advertisement
Sign in to follow this  
GenuineXP

(2D) Texturing Problem

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was going to upload a simple image to help in my explanation of the problem, but I can't from work, so please forgive any confusion! I'm storing (2D) geometry as a quad-tree. Regardless of the size of any given subdivision (be it 1024x1024 or 32x32 pixels), there is a base width of 64 pixels. This means several things, including that every 64 pixels, texture coordinates range from 0 to 1 (i.e., a texture is repeated every 64 blocks, forming a tiled-like appearance). My problem is, each subdivision can be transformed. This basically means that each vertex in the quad that forms the subdivision can be "pushed in" and "pulled back out" to form arbitrary (but convex) shapes (that are confined within the square region of the subdivision). However, when I do this, my texture coordinates get messed up, and the nice tiled appearance goes out the window. Instead, the texture repeats, but is distorted and "bent". As an example, lets say I have a very simple and small quad-tree. There is only one node, the root, and it is 256x256 pixels in size. This means the texture should form a 4x4 tiled appearance. Now, if we transform this one and only node by pushing the top-left vertex towards the right (positive x axis) 128 pixels... how can I possibly form texture coordinates that maintain the tiled appearance of the texture? Note there are still only four vertices. Is this possible without introducing more vertices? The transformed edge should simply "cut into" the texture... no wrapping or distortions, as if a triangular (in this case) section has simply been "erased". Any ideas? Thanks! EDIT: One thought I've had is that transformed subdivisions may need to be further subdivided until leaf nodes reach at least the base width of 64 pixels. At this point, each subdivision can precisely control the texture coordinates and there's no problem. However, I want to avoid subdividing at all costs, which is why I'm curious if there's a way to get these coordinates right.

Share this post


Link to post
Share on other sites
Advertisement
You can just convert the vertex coord into texture coords directly with an appropriate scale factor. Eg. if your original quad size was 64x64 and your texture coords go from 0 to 1 then the original coords of (64,64) should map to (1,1) and (0,0) should map to (0,0). So dividing the vertex coords by the size of the quad (in this case 64) should get you suitable texture coords.

(that's a really bad explaination, but I hope you can see what I mean).

Share this post


Link to post
Share on other sites
If I understand you correctly, this should be very easy to achieve.

Just set the texture coordinates to the position of the vertices divided by 64.

For example, your original 256x256 quad had the following vertex positions and tex coord pairs:
(0, 0) - (0, 0)
(0, 256) - (0, 4)
(256, 256) - (4, 4)
(255, 0) - (4, 0)

If you move one of the vertices, let's say the last one, to (192, 0), then its texture coordinates should change from (4, 0) to (3, 0).

Is that what you're looking for? Or am I missing something.

[Edited by - shurcool on June 26, 2008 11:46:28 AM]

Share this post


Link to post
Share on other sites
Wow, that was easier than I thought.

I haven't yet solved this in my code, but I hard coded the texture coordinates to test out what has been posted and it worked like a charm. Starting in the lower-left corner and rotating counter-clockwise, the coordinates (0,0), (4,0), (4,4), and (2,4) work as expected.

The problem is in the calculation of these coordinates, so I'll have to revisit my code. I actually store relativistic transformations for each vertex, so I have to first calculate the transformation distance (which is based on the width of the subdivision) and then apply that to the "normal" coordinate of the square region the subdivision occupies.

In any case, thanks for the help. It figures that my code is spitting out whacky texture coordinates. :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!