Whoops… I just noticed a serious bug regarding worldBound and modelBound. This is causing major issues with collisions/picking/culling, etc. It’s also causing a major pain for setting them up. It should be much easier than it is, and was supposed to be easier. I’ll be fixing this ASAP.
Secondly, Eric, any idea what’s going on with the Milkshape loader and JNLP?
Ok, I think I tracked down the problem and fixed it. Geometry objects weren’t correctly setting their world bounds based on the model bounds, due to a transform problem. This is now in. So, you should not have to EVER set world bounds, just model bounds. These bounds should then propogate through the scene graph automatically.
The loader is being fixed, I hope. 
I finally have a few hours to sit down and take a close look at the problem. More info when I have it.
Aha! I’ve nailed the bug. It’s not fixed yet, but at least I know what’s going wrong. Heh. My “Crazy Test Version of Extreme Debug Statement Spammage” led to find that the real reason the texture wasn’t loading was because it was dying within the .bmp loader function. I’ll fix everything up and commit.
You got the newest version of everything before you fixed it right? With me changing the constructor for Spatial, pretty much everything changed.
Yep, I did. I was hoping that your changes would fix everything, but alas, no luck. Well, at least now I know how to fix the darn thing!
edit:
Well, perhaps I don’t. I tracked down the problem to the loader code incorrectly determining the extension on the file and hence attempting to load it as a format Java supports. After making the necessary corrections, everything works excellently. But here’s the problem: determing what file to load in the loadTexture() method. As far as I can tell, we need to use the proper relative path (e.g. “test/data/a.png”) and not an absolute path to get things to work. I’m unsure how to extract that information from the URL. Ideas?
Ok, I’m a little confused as to what the problem is…
We seem to load textures for other things just fine, why exactly is this one different?
A quick update on the situation:
The Milkshape ASCII loading is now mostly fixed. The textures will now load, and the test will [finally!] run in Webstart. One problem , however, is that the textures do not load properly. They are either missing parts or are distorted. Can others confirm this behaviour? Try me!
I’m sure we’ll get everything sorted out quickly.
Maybe it’s a bmp problem? Try setting a bmp texture to a box and try it through webstart (maybe two boxes, one with a bmp texture and one with the normal jme texture). If those render fine, then we know it’s still in the milkshape loader.
It’s definitely a .bmp problem. I did as you suggested and created a test with two textured boxes: one bitmap and another jpeg. The .bmp was corrupted/missing bits while our favourite jME texture loaded just fine. So, now I’m thinking that it’s perhaps some weirdness with the input stream?
Ok, I’ll see if I can find anything in the bmp loader.
ok, its time to get serious, no one will use bmp’s in their game, simply because they are too easily modified and are over bloated, the same image saved in .png format will more than likely be 1/8th of the size of a .bmp.
So if this is a serious issue, my vote will be to ditch .bmp format. Or is it an ability question?
Ok, in BitmapHeader… we have the old read instead of readFully. Unfortunately, it’s not a quick fix like MD2 was. I am working on it. DarkProphet has a point, but casual users tend to use BMP cause it’s there. So I’d still like to support it.
Eric, can you convert the bitmaps to png and try loading that way (you’ll have to change the model text to reference png), but that might improve our current situation while I try to fix BitmapHeader.
EDIT: Ok, I think I got read fully working. Let’s see if that solves the webstart issue…
Ok, new bitmap loader is in. Update and give it a shot. crosses fingers
It’s good! Everything works without issue now. I took a quick look at your solution: very elegant and compact. I believe that this is the last barrier to releasing jME 0.5. If so, excellent! I’ll echo Mark’s sentiments; great job everyone, this is a huge leap from 0.4.
fwiw, the link to the demo you provide above seems not to be missing any textures… I see the man run towards the camera, run backwards, then sorta skip upwards and repeat.
That’s good: it means everything is fixed now! Excellent.
Thank God.
BTW, in regards to the original topic of this thread. Bounding Volumes are working again. To use, the ONLY thing you are required to do is set the model bound for any geometry, you don’t have to do anything for nodes, they are calculated in the update geometric state. To set the model bounds just do:
myMesh.setModelBounds(bounds);
bounds can be precalculated OR you can say:
myMesh.setModelBounds(new BoundingSphere());
myMesh.updateModelBounds();
the update model bounds will calculate the sphere based on the vertices that make up the geometry.
Ok, 0.5 is ready. Let’s just clean up and document what we can this week. March will start 0.6.