Clueless texture distortion :/

Hi!

.

I am looking for tips on what can be causing this and what tests I should perform.

I have this problem with the texture, and I dont understand what is causing it.

http://imgur.com/L2CD8.png

.

It seems to be related to the UV texture normals?

.

I tried to compute that in several ways and none worked:

[patch]

Vector3f a = tri.get2().subtract(tri.get1());

Vector3f b = tri.get3().subtract(tri.get1());

tri.setNormal(a.cross(b));



mesh.getBuffer(Type.Normal).updateData(

BufferUtils.createFloatBuffer(fb));



(below here I got really random tries…)

mesh.createCollisionData();

solid.setTextureCoordinates(textures);

mesh.updateBound();

mesh.updateCounts();

TangentBinormalGenerator.generate(mesh,true);

TangentBinormalGenerator.genNormalLines(mesh, 1);



[/patch]

.

The point is, may be the very root of the code should be changed to let textures work?

.

PS.: this is related to the BoolMesh, after applying a boolean operation the texture gets distorted :frowning:

Looks to me like the texture coordinates get messed up. Maybe the boolean operation stuff is not calculating them correctly when adding the new vertexes?

Thats what I thought.



I dont really understand how that UV calculation works, I tried to sometime ago but the info I found was confusing (I mean I tried to reproduce what I read, but the results were completely diferent so I gave up), I need noob info and noob examples to understand that :slight_smile:



So my current approach is to try to fix the resulting mesh after it is created, fixing the UV in some way.

Or do you think it is not possible, and should be worked during the bool operation?

I did so many (random) tries… I am beginning to think the only way is to understand how bool worked.

I just thought, the UV had a certain value; and that value was kept after the triangles/faces were changed; but that would made me think the texture would be shrinked (as the new triangles are smaller) and not stretched as it seems… mmm… could be that anyway?

Each vertex for a face has a texture coordinate, usually between 0 and 1. It looks like the existing vertexes have their original texture coordinate and that any of the newly created ones get some incorrect value… maybe even a constant value.



You’d have to know how the original edges were split in order to even hope of calculating new texture coordinates.



The larger question… what are you trying to do with booleans? What set of shapes are being subtracted and added in that picture?

I create a box, rotate it a bit; I add a cone (mixing both); and finally I subtract a sphere.

.

Here is the sample code:

http://hub.jmonkeyengine.org/groups/contribution-depot-jme3/forum/topic/boolmesh-java-boolean-operations-on-mesh

it requires installation of external libraries.

.

Btw, I played with the texture coordinates on that code, and things changed (to a lot worse), but finally something happened, so that is the point to fix indeed. I just need to know how to recalculate them fixed!

.

I was looking for a way to fix the textcoords for a face automatically and I found this thread

http://hub.jmonkeyengine.org/groups/free-announcements/forum/topic/normal-generator-solids-of-revolution-for-jme/#post-130260

but it is too old and not updated to jme3, anyway I am not sure it could help…

The best place is in the code that is splitting the edges and faces. It is the best place to know what the texture coordinates should be. Anything after the fact will be prone to error, I think. Too much information is lost at that point.

1 Like

great!

.

I found where to change!

.

I am using an specific (another) test case: add two boxes without rotation.

I used this code:

[patch]

// there is 3 face vertexes and each has UV coordinates (x and y from color)

Vertex[] faceVerts = {face.v1, face.v2, face.v3};



Color3f color = faceVerts[j].getColor();

switch(face.getStatus()){

case Face.OUTSIDE:{ //face status if it is outside a solid

float bkp = color.x;

color.x = color.y;

color.y = bkp;

}break;

case Face.SAME:{ //face status if it is coincident with a solid face

float bkp = color.x;

color.x = color.y;

color.y = bkp;

}break;

… (other cases dont happen when adding meshes…)

[/patch]

.

in truth, color.x and color.y are the texture coordinates (I reused the variable, but I think you can have only color or texture, not both, so it wouldnt cause trouble?)

.

what i did was invert the values.

And that fixed a few triangles textures!!

.

many thx for the clues! :smiley:

.

But… I continued researching, and looked how the textures coordinates are calculated for jme Box, and imagined something could be done.

But… I looked more, now at Sphere… and… imagined o.m.g. :open_mouth:

.

To make things worse, I looked at the final mesh that I put the screenshot above, and thought that it is a completely irregular, unpredictable mesh; there is no simple, even if coded way to apply a texture to that, that would look good :O.

I think such a mesh would have to be specifically painted, each group of triangles, to look good… I think we can do that in blender (that I still cant use well…). As we usually see a texture being applied to a sphere that gets distorted, is another clue thats not a simple task.

.

So the best thing to do with such a mesh is to apply some simple granular low contrast texture, or even better, only plain colors, or may be an equivalent to wired mesh, but opaque and with low contrasting delimiters (I will take a look at the wired material!).

.

Am I right, or is there still hope? :slight_smile:

.

EDIT: I think I found some more info (with drawings) here:

senocular.com

still studding :), I know I am almost there… :smiley:

There is code somewhere in the boolean stuff that splits an edge and/or derives new vertexes from some other set of vertexes. This is where new normals and texture coordinates should be calculated as it’s relatively trivial. Splitting one triangle into many and distributing normals and texture coordinates is pretty straight forward. Linearly interpolate the texture coordinates, Do the same for the normals and renormalize.



Anything else is hard in the easy cases and really really really hard in the not so easy cases (as you’ve discovered).



If the boolean code is where the problem is then I don’t see how it could be fixed outside of that. I have no familiarity with that code, though… maybe it tries to do the right thing with the right options? Maybe this was something never implemented?