UV map offset in-game but not max/O2 :(

[JDog 11]

Running into a weird issue I can't seem to pin on to anything, hoping someone might have an idea.

With my ship, it's split into 4 sections length-wise, so I need to make sure the deck textures line up properly. For some reason, the bow section of the ship will not line up by normal methods with the one its beside. Here's a pic from in-game:

In max, which I use to do the uv mapping, it lines up fine with the next section. When I preview it in Buldozer, it also seems to be lining up fine. For whatever reason, the textures wont line up in game. Also, the models the textures are on are indeed lined up perfectly also, so it isn't a model offset thats causing the texture offset. Any ideas?

Also, I just found a TON of these when it works on the model in question:

Warning: UV coordinate on point 1509 is too big UV(-283.700714, -43.407444) - the UV compression may produce inaccurate results

never seen it before any idea what I did wrong?

Edited October 14, 2010 by JDog

[mikebart 1]

weird, so it seems to be happening during binarization? could you provide more info like; when you export from max are you exporting as .obj or .3ds?, does the mesh have multiple UV channels?, is the mesh completely in tri's?

if you've imported the model into O2 with quads, try converting it to tri's in max, export as .obj and reimport, this fixed a problem once for me, but it was different to the one you're having, might help though.

[JDog 11]

Export as .3ds, I don't know what "multiple UV channels" mean so I'm guessing it doesn't haha, and the object is in polygons, but of course O2 makes it all into tris.

Never had this problem with the Nimitz and its just this 1 section of this ship. I thought maybe because there were some long angular faces near where it goes off-track but I tidy'd them up and re-UV'd and still nothing. It's really weird :( I can try resetting the uv-map/Xform of the deck object in max and redo that part when I get the chance.

[Synide 0]

Do you have an .rvmat mapped to polygons in the .p3d?

If so, maybe double check them that the 'transforms' within the .rvmat's are 'correct' and not 'pushing' the texture mapping out. But, on thinking this probably isn't the problem as you would'a seen it in Buldozer. But, it's worth a check.

[t_d 47]

With ArmA2, BIS integrated a compression for the UV coordinates into their ODOL p3ds. This compression is not lossless and that's why there is a warning appearing telling you that there might be inaccurate results like the one you are having. I could tell you how the compression works but you probably just want to know how to solve your problem. You should try to bring your UV coordinates within the range from 0 to 1 or at least in a small range. -283.700714 is simply too far away from that.

[JDog 11]

Thanks for the suggestion Synide but I'm too nooby to even know how to make/use rvmats yet lol.

TD, I'm not entirely sure what the uv coordinate "range" is but I'll try to figure it out. Again I'm just not sure why it would be happening for only 1 section of the model when it was all built together and mapped the same way. Thanks for the input.

[rstratton 0]

some of your uv's are either way to big or way to small. in oxygen 2 go to structure> check faces to find the offending polygons

[JDog 11]

After resetting everything that has to do with the deck object/uv mapping in max, I did the Check Faces thing, but it only highlights a few faces which make up the underside of the walkways, which have nothing to do with the deck object. I tried deleting them just for the heck of it but didn't do anything either. It doesn't say there's anything wrong with the deck.

Here's what it looks like in O2:

And in-game still:

This is really weird. Even when I don't binarize and just pack it, it still happens.

[PuFu 4600]

could you please post 2 side by side images of your UV layout in max and O2 please?

[JDog 11]

Well the deck is multiple objects and I can't edit two UVs at once (that I know), so I can't show you via uv-map screenshots that they're lined up, only with images of the objects beside each other. Also, I'm not familiar/comfortable with the uv editor in O2, if I were to screenshot it it would be overlaid with all the other objects' uv mapping too. Later I'm going to see if I can get the other 3 sections to line up with the first, since the other way around isnt working.

[Synide 0]

If you'd like I can have a squizzy at your model at this end if you wanna upload it somewhere. Or, if you don't have this facility then I can send you some ftp details of somewhere to upload.

Alternatetively, I suggest you send it to someone else to see if they have the same issue.

Re. turning off background uv's in uv editor... goto 'View>Background LOD' and uncheck it.

While you're there, do a 'Edit>Select All'. Then hit the 'Fit UV Map' button.

Does the UV viewport zoom out hugely?

[mikebart 1]

I might be wrong, but I think what T_D is talking about is that there is a limit to how much you can tile your UV's over a model, binarization detects that you've over tiled your UVs and attempts to cut them up bringing them into a smaller UV space, but as the .log says results can be unacurate.

so to fix this problem, you might need to re-map your model and split up your UVs more so that it fits into a smaller UV space (still tiling over some space though), this might require a few cuts to be made across your model.

[rstratton 0]

, I did the Check Faces thing, but it only highlights a few faces which make up the underside of the walkways, which have nothing to do with the deck object. I tried deleting them just for the heck of it but didn't do anything either. It doesn't say there's anything wrong with the deck.

.

ive had one small part of a model totally warp the uv's on all of the model before so anything is possible

[JDog 11]

Thanks guys. The deck isn't tiled but the underside of the walkways is so I will try making some cuts in that and seeing if it affects the deck object tomorrow.

[t_d 47]

Maybe I need to explain how UV coordinates work. But I am bad at explaining...Will try it though. Every point of a face needs an U and a V coordinate. Why? Because the engine needs to know which part of a certain texture needs to be mapped on the face. So what does a certain U or V value mean? U is the horizontal and v the vertical position in the texture. And these UV values are usually in an interval from 0 to 1 (the range I was talking about), because every position in a texture can be described with two values within that interval. How is a value out of that interval handled? For example a value of 1.5 or 2.5 or 3.5 etc. is the same as 0.5. For your example a value of -283.700714 is the same as 0.299286. So why does the engine allow values out of that range? If you want to repeat a texture on a face you cant do that within 0 and 1. Most important question: how to solve your problem? If the texture needs to be repeated 283 times on a single face you need to split the face into more faces. But I doubt that is the case here. If you open the UVEditor in O² you will see a grid. Each square of the grid is basically one texture so if all points are in the middle square all UV coords are within [0,1]. If you go 283 squares to the left you will probably find points there. These should be moved to the middle square where most of the points should be.

[JDog 11]

Hah sorry for having you write all that up T_D, I understood what it meant shortly after someone brought up tiling as the issue. I'll end up cutting those up some and remapping them so they arent SO tiled, and see if that fixes the deck. Otherwise I'm remapping the deck anyway.

[JDog 11]

Yea I deleted EVERYTHING except the two deck objects that arent lining up. It's definitely some other object thats messing with the first deck section and making it mess up, cuz it lines up fine. Gonna narrow it down and see what it is. I cut up the walkways so they aren't stretched across the uv map tiling as far as they did, but didn't seem to fix it. At least now I know how to figure out where the problem is. Woulda never guessed it was another object, doesn't make sense to me :P

Update: I am IMMENSELY disappointed/infuriated lol. I figured out what was setting it off. WHY, I have no idea. Its the stupid little beams that hold the netting that wraps around the ski ramp. They aren't even textured/uv-mapped, they're just given a flat color in O2. That's retarded. So I went back into max, did a quick planar map not caring about it at all, imported into O2, and it works in game now. Wtf.

Note to self: ALWAYS unwrap objects, even if you're just giving them a flat color. /sigh

Edited October 17, 2010 by JDog

[PuFu 4600]

yes, everything should be uvmapped for game use

[JDog 11]

Hey guys, don't wanna make a new thread so I'll post it here. I thought maybe this was because I hadn't made a Geometry LOD for the deck/hangar floor yet but I have now and still have the issue so...

What's happening is, if you shoot a gun on the carrier, 75% of the time, you'll see like a hexagonal muzzle flash, and the textures inside of it will disappear for the length of the flash (a couple frames I guess). So like... when you shoot, you can partly see through the deck looking through the muzzle flash. I'll see if I can get a video of it later.

Could this still be because of the uv coordinate issue maybe? Because this doesn't happen on the Nimitz, and they're both put together the exact same as far as LODs go. I'll toy with it later and see if its the same uv coordinate issue, just thought I'd post anyway for now.

[mikebart 1]

could be because you have an alpha channel in one of you're _co.paa's, try converting it to .tga, open it in photoshop or gimp, then save it as 24bit .tga.

Take note of the size of the .tga before you save over it from photoshop or gimp, once saved without the alpha channel it should be about 3/4 the size in KB's.

[JDog 11]

My textures don't even end with _co and all that other jazz. I noticed there's like a "proper texture naming" method but is it required? Seems to work fine without. That might be the issue though, because after checking now, the Nimitz deck has a white background and the QE is transparent. Thanks I'll try that out now.

EDIT: Yup that was def the issue, thanks a ton. I'd be lost without you guys :)

Edited October 20, 2010 by JDog

[mikebart 1]

My textures don't even end with _co and all that other jazz. I noticed there's like a "proper texture naming" method but is it required? Seems to work fine without.

yeah i dont really know if its required for every texture map for things to work properly, but its a good habit to get into, even just for the sake of tidy house keeping inside your 'data' folder.

http://community.bistudio.com/wiki/ArmA:_Texture_Naming_Rules

you'll see here that theres a few different types of normal maps, so the naming convention might be required for these to work accordingly

Edited October 21, 2010 by mikebart

[soul_assassin 1750]

the convention is there for texview and buldozer to recognise the type of texture and apply the appropriate conversion (i.e. waht type of DXT compression, etc.)

[mikebart 1]

ahh, makes sense thanks SA

[Synide 0]

the convention is there for texview and buldozer to recognise the type of texture and apply the appropriate conversion (i.e. waht type of DXT compression, etc.)

yeah, indeed... one should view the 'texture naming convention' as a mandatory requirement. As Soul_Assassin points out... without it you don't get the correct compression & the correct swizzling of the channels.

Both of which are an absolute necessity with the majority of the texture types. Personally, I think it's a bit gay having a suffix driving functionality as opposed to having meta data embedded in a header in the file format. But, I can understand why they've done it that way. Still, irksome though.