3D Model/View Problem

Yes, essentially you have two options ahead of you:

  1. create a minimal test case (one class preferably) that illustrates the problem so that others might test it on their GPU setups and comment appropriately (or maybe we’ll just spot the problem)
  2. or build JME from source starting with the 3.2.0 tag and walking forward a commit at a time until it breaks. I’ve done this before… it’s not ‘fun’ but it can be satisfying to find the specific commit.

…in the end it could still turn out to be system-specific, though. So a test-case is not a bad idea.

Also, in your testing I hope you were able to repeat the results several times in a row… else you might fall into the “backwards clock” trap. Short version of the story:
My dad tells a story about a broken electric wall clock that they took apart to try and fix. When they put it back together it ran backwards. So they unplugged it to look again… when they plugged it back in it ran fine. Turns out unplugging it and plugging it back in caused it to switch directions. Forward, unplug, plug back in, backward, unplug, plug back in, forward…
In the U.S., a standard ungrounded wall plug can be flipped and work just fine. My dad and his co-workers had their boss thinking he was crazy as they tried to convince him that flipping the “polarity” caused the clock to run in a different direction.
Plugged in: clock runs forward
Unplug, flip the plug over, plug it back in: clock runs backwards
…repeat process.
Had their boss questioning everything he knew about alternating current.
Lesson: be careful your variables and assumptions. Something is only failing if it fails three or four times in a row under the same conditions.

Unfortunately, the problem is really sporadic; running exactly the same program, it sometimes won’t happen, or it will only be the odd polygon that gets stretched to infinity (see pic), or everything goes bananas (like the first video). I’m trying to find some kind of pattern.

.

It certainly seems like you are modifying one of the JME constants somewhere.

Check to make sure things like Vector3f.UNIT_X, etc. are all still the values they are supposed to be.

I’ve whittled the code down pretty much as far as I can to recreate the problem:-

https://bitbucket.org/SteveSmith16384/recreatecorruptmodel

The strange thing is that, just like earlier in the thread where commenting out a single unrelated line fixed the problem, if I comment out a single unrelated line, it fixes the problem! This time, the line is ControllerManager.initSDLGamepad() which calls a method in the Jamepad library ( Jamepad/ControllerManager.java at master · williamahartman/Jamepad · GitHub ).

I just had the bright idea of adding 2 lines of the Jamepad library to the standard JME test game to see what happens. Give me a sec…

That didn’t recreate the problem, but I have whittled it down to this code, which uses a jar and a model from the above repository.

public class ModelViewer extends SimpleApplication {

public static void main(String[] args) {
	ModelViewer app = new ModelViewer();
	app.showSettings = false;
	app.start();
}


@Override
public void simpleInitApp() {
	// This code causes the model to be corrupted
	ControllerManager controllerManager = new ControllerManager(1);
	controllerManager.initSDLGamepad();

	cam.setFrustumPerspective(60, settings.getWidth() / settings.getHeight(), .1f, 100);

	super.getViewPort().setBackgroundColor(ColorRGBA.Black);
	
	Spatial model =  assetManager.loadModel("Models/beholder/beholder.blend");
	rootNode.attachChild(model);

	this.flyCam.setMoveSpeed(12f);

	setupLight();
}


private void setupLight() {
	// Remove existing lights
	this.rootNode.getWorldLightList().clear();
	LightList list = this.rootNode.getWorldLightList();
	for (Light it : list) {
		this.rootNode.removeLight(it);
	}

	// We add light so we see the scene
	AmbientLight al = new AmbientLight();
	al.setColor(ColorRGBA.White.mult(1));
	rootNode.addLight(al);

	DirectionalLight dirlight = new DirectionalLight();
	dirlight.setColor(ColorRGBA.White.mult(1f));
	rootNode.addLight(dirlight);

}


@Override
public void simpleUpdate(float tpf) {
}

}

You shouldn’t be messing directly with the world light list.

I don’t know if it’s your problem but generally in JME if you have to get something like that to clear it then you shouldn’t be clearing it in the first place.

If you want to remove local lights from some model then traverse the model and remove the local lights. (Or load it into the scene composer and remove them… or remove them before you export, etc…)

1 Like

I assumed it was the quickest way to remove all lights from the whole world, so I could add my own lights and be sure there was no existing lights. It wasn’t intended to specifically remove them from models or anything.

I’ve removed that whole method though, and the model problem still remains (though slightly darker :slight_smile: ) .

Convert your .blend model to a game-ready model and try that.

The blend loader is a horrible way to go in general but especially at runtime for a game.

In JME, the “World” stuff is usually a rollup of other things. By pooping all over it your screwing up half-a-dozen things that calculated that for you from the “ground truth” of your scene graph. So then later you confuse the engine where parts of it are looking at ground truth and parts of it are looking at the rollup.

If a method has “world” in the name, don’t modify its results.

If you have to call a getter to mess with a value then don’t mess with it.

…if you were supposed to set it then there would be a setter for it.

Done that, and the problem doesn’t occur.

Problem solved?

Imagine a high speed train zooming down a track. On the hill is a highly trained, well paid, sniper ready to shoot anything that gets in the way of that train.

That’s the way we wish developing a blender loader was like.

But it’s actually a rocket powered dune buggy driven by a pack of drunk clowns, turns may be sharp, paths me be circuitous… meanwhile, we have a part time, works only every other Sunday for five minutes in the afternoon when the weather is nice… highly trained, not at all paid, sniper.

It’s going to be a buggy mess… essentially forever. .blend is not an interchange format. We were foolish to ever consider treating it as such. (And I was an original proponent of the .blend loader before I realized what an impossible task such a thing really is.)

2 Likes

so now we have .gltf still little buggy for exporters but i hope will be all fixed soon :slight_smile:

gltf has the benefit of actually being an interchange format. It is DESIGNED to transfer data between tools. And it does it the right way: export it in one tool, import it in another.

.blend is not an interchange format. It could have been a raw dump of working memory for all Blender cares. (And I guess the truth is not that far off.)

1 Like

The problem doesn’t occur, but still very strange why it happened so intermittently and was affected by unrelated code. I’m also surprised no-one else seems to have come across it?

You are using things that 99% of JME users don’t use. Any of those things could be involve in memory corruption, I guess.

It’s quite likely that switching away from .blend has only moved the problem in your case but it was still a good idea.