reset xform bites again

sir-knight

Something interesting was happening to my craptacular low poly meshes with equally craptacular low res textures I'm trying to tile on them.

I have a very simple rock outcropping mesh, and I exported it with a planar uvw mapping tiled x amount of times.

The model was brought from .x into our inhouse 3d format and displays the tiled texture just fine. But when we loaded the model into the game engine on device, the textures don't display properly anymore... in fact... we're not even sure what part of the texture it's displaying, but it looks extremely zoomed in on like a square of 10x10 pixels.

One of the developers opened up the .x file and mentioned the texture coordinates were not unit vectors (and perhaps the vertex coordinates as well) of numbers less than or equal to 1.

So if that's the case, is this one of those crazy things reset xforms fixes?

I created a box, edit poly, and attached the mesh in question, deleted the box (reseting xforms essentially) and rexported... and compared the numbers myself and looks like the numbers have magically become the delicious unit vectors that the devs are seeking.



edit... okay that didn't seem to work either, I'm at a loss to what could be effecting this, if it is at all a mesh problem or if it's an engine problem. I've tried both planar and box uvw mapping and neither seemed to work, and dev wants to tile a texture on the mesh, rather than having an unwrap... they want to scale the meshes and not have pixelation issues with the textures.


the textures display fine in max and our python editing tools. The game engine is java, and the only one of the 3 having issues with these objects.

Eric Chadwick

Simplify it down to just a single triangle with UVs, and do some export tests on that. You should be able to narrow down the problems to one of your four bottlenecks: creation process in max, or .x exporter, or .x to inhouse converter, or inhouse engine.

If you use a single triangle, it's much easier to look at the coordinate data on those three verts and compare it between the four stages. Where does the data break?

sir-knight

well we're trying to see if it's related to the process of attempting to tile a texture or not, all the objects in question are attempting to do this, rather than having a specific UV unwrap and custom texture, but in trying to save space, they want to reuse mesh and just drop different textures on them.

Reseting xform seemed to not do anything, though it did seem to clean up some of the coordinates, the effect remains the same. But I'll try sending them a triangle like you suggested and see where it leads, some of these meshes aren't even more than 20 triangles. It's been labeled a low priority task though since they're trying to touch up the AI and physics so they can start playtesting.

Which means I get to sit around and do nothing

Eric Chadwick

Is .x a text format? Try opening it in a text editor.

sir-knight

yeah .x is a text format, we've been looking at it and comparing it to working files, that's how the dev saw that the normals weren't being converted to unit vectors, but resetting xform fixed that but not our texture problems.

beyond .x, it's being converted to the inhouse format, but we're we know the info is intact because our python level editor shows the models properly.

At that point that is where my knowledge ends, if max is telling me it's right, and our editor is telling us it's right, there must be something on the java side that either doesn't like what we're doing (not supported or being picky) or max and python are lying to us. :P

I'm using kx xport to do the .x files if that helps at all.

Eric Chadwick

IIRC, Jon Watte is the dev for that exporter, real helpful guy.

Reset Xform doesn't affect the UVs at all, it only helps reset the transform data for the model, which can get screwy if you do non-uniform scaling or if you mirror the model (which is basically just a negative scale).

If your devs are saying texture coordinates have to be between 0 and 1 only, then that means you can't tile. You will have to create all the UVs in the 0-1 box. If you want tiling, you'll basically have to tile the mesh instead of the texture, subdividing the mesh.

sir-knight

subdividing the mesh is out of the question for our application, if this is an issue in the method in which the dev team has implimented texture mapping, then we have a problem... a big one. In any case, they've handed that issue back to the engineering team to look at, but if that's the case, then it's definitely not my fault :P

But could you explain why if the UVs aren't tileable if the unit vector coordinates can't exceed 0-1? Is that a representation of where the texture coordinates are mapped to the actual texture file? So in going over 1 that means that the coordinates exist outside of the texture space?



edit: and that's exactly what it is... thanks for the help Eric... looks like J2ME does not support tiling textures... (lame) looks we'll have to figure out some other way... and by we I mean ME. :P