The static environment for my game is composed of modular “building block” models which I created in Blender. These models typically consist of one or more geometries, each with its own UV map, but no armatures or animations. I apply textures after loading each model, so the import process needn’t handle textures correctly, only UV coordinates. I don’t create a texture atlas or do any baking. All this worked fine with Blender 2.66a and 2.68a importing into jME3 RC2.
After I switched from RC2 to 3.0 Stable the other day, models I’d previously imported still worked. And when I re-import single-geometry models, they look fine. But when I re-import a multi-geometry model, the textures get distorted, apparently because the UV maps are garbled.
Is anyone seeing similar issues?
My development environment is 64-bit Windows 7. I’ll be happy to provide other details which might help me resolve this issue.
Are you sure it isn’t that the textures are flipped? Try setting y flipped to true (or false if it’s already true)… this is almost always the problem in cases like this.
I’m quite sure that the distortion is nothing a simple as inverting a single coordinate. The textures in question are seamless, so flipping a coordinate would not change the model’s appearance much.
I’m wondering whether this contribution might have something to do with my issue.
@sgold said:
I'm quite sure that the distortion is nothing a simple as inverting a single coordinate. The textures in question are seamless, so flipping a coordinate would not change the model's appearance much.
I’m wondering whether this contribution might have something to do with my issue.
??? Completely turning a texture upside down with complex UVs will almost always look like the uv coordinates are distorted.
I guess we will need pictures because it’s tough for me to understand how it could be so obvious that something is wrong and yet “no way” it could be the image being upside down.
I generated screenshots from my game to illustrate the issues I’m seeing.
Here’s a typical game scene as it looked with the previously-imported models: scene-old.png
Here’s how the scene looks with two of the block models (arcade and towerEntry) re-imported using 3.0Stable: scene-new.png
Here’s the arcade block model as previously-imported: arcade-old.png
The scene with the reimported models includes five visible instances of the arcade block, and they don’t all look the same. In two instances, the square wood top (which consists of two triangles) appears correct. In two it appears untextured brown – perhaps all four vertices got identical UV values. In one instance, the textures of the two triangles don’t match – as if the texture got rotated by 45 degrees on one triangle. There are similar problems with the stone texture, which appears untextured or stretched or rotated on a many of triangles.
One detail not captured by these screenshots: as I move the camera around, some of the faulty textures shift, creating a strobe or kaleidoscope effect.
When I load the arcade block by itself, most its polygons render as untextured solid colors. In those that appear to be textured, the texture seems to be rotated and/or scaled:
Some of it (like the changing as you move around, uvs looking stretched, etc) sounds like tangent vector issues if you are using normal or bump mapping.
I think pspeed’s final guess (that there are no UVs at all) is on-target.
I set a breakpoint just after the towerEntry block model gets loaded and examined the Geometry in the debugger. With the old towerEntry.j3o file, each mesh had four buffers: Position, Index, Normal, and TexCoord. With the new file, each mesh only has three buffers – there’s no TexCoord.
@nehon said:
~~summon~~ oooo mighty @Kaelthas cometh and shed thy wisdom upon us.
Why thou had summoned me oooh @nehon ?
I have cometh to thee to see what problems thou foe - The Dark Lord Bug - has done.
For He shalt not live long to causeth more troubles.
=D
OK and now seriously. @sgold please upload your model and send me a link. I will take a look at it today why the coords are not loaded.
3.0.x is a bug fix branch so things don’t automatically make it over there unless someone specifically ports it. We try to maintain backwards compatibility and stuff… so we’re a little stingy about what makes it over.
I don’t think anyone merged them into the branch so the only way to get the changes is by using HEAD. I don’t know if we have a nightly for trunk or not… or how that is intended to work going forward. I always build from source so I’m spoiled.
