Multi-geometry Blender models imported into 3.0Stable

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:

arcade-new.png

When I load a single block, I don’t see any strobe/kaleidoscope effects.

I hope that’s clear. Any advice on how to proceed? Should I upload sample .blend and .j3o files?

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.

Do you have normal maps and/or bump maps?

No, I don’t use any normal maps or bump maps, only diffuse.

Then my only other guess would be that it has no UVs at all, or something. Maybe poke at the meshes to see what they actually have in them.

1 Like

summon oooo mighty @Kaelthas cometh and shed thy wisdom upon us.

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.
:wink:

1 Like

@Kaelthas go here and click on “View raw file”

@sgold I have just commited the fix.
The UV’s were loaded when the textures were linked to the material or when the model had no materials at all.

Looks like I missed the case when the model had materials but no textures :wink:

Please chack it out and let me know if everything is fine.
If not I will look further.

3 Likes

I tried it (checked out the latest SDK and built it from scratch) and it seems to work. Thank you, @Kaelthas!

1 Like

he’s the one.

I’m gradually learning the names of all the jME gods/saints and which one(s) to invoke for each sort of issue. :slight_smile:

Looks like the fix didn’t make the 3.0.2 update. Is there any chance of getting it in 3.0.3?

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. :slight_smile:

I should think the fix for this bug would be worth back-porting into 3.0.x, but I realize it’s not my call.

@sgold said: I should think the fix for this bug would be worth back-porting into 3.0.x, but I realize it's not my call.

Not mine either, really since I have no way to test the code myself, etc…