Strange Sphere Problem

I create 10 spheres by the following codes.
but these 10 spheres are very strange. please see the attached image.

public class HelloJME3 extends SimpleApplication {
public static void main(String[] args) {
HelloJME3 app = new HelloJME3();
app.start();
}
@Override
public void simpleInitApp() {
float radius = 5.0f;
int numPoints =10;

    for(int k=0; k<numPoints;k++){       
        
        float r = FastMath.PI*FastMath.nextRandomFloat() ; //0~pi
          float d = FastMath.TWO_PI *FastMath.nextRandomFloat() ;//0~2pi
         Vector3f translation = Vector3f.ZERO;
          float z = radius *  FastMath.cos(r);
          translation.z =z;
          float x =  radius *  FastMath.sin(r)*FastMath.cos(d);
          translation.x =x;
          float y =  radius *  FastMath.sin(r)*FastMath.sin(d);
          translation.y =y;           
         Sphere b = new Sphere( 16, 32, 0.2f);            

        Geometry geom = new Geometry("Sphere"+k, b);
        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
      
        ColorRGBA color = ColorRGBA.randomColor();
        mat.setColor("Color", color);         
        geom.setMaterial(mat);    
                      
      geom.setLocalTranslation(translation);          
       rootNode.attachChild(geom);
    }        
}

Well, you are directly modifying the fields of Vector3f.ZERO so you will be messing up all of JME at some level.

Do not modify the fields of the “constants”.

1 Like

Thanks pspeed. It works.

They should be final then …

Humm, I just saw they are final, and I just remember that its an java problem actually.
Java dosent support constant objects and allow peaple to change it, I remember I read somewhere this would be fixed by oracle some day…
That would prevent this kind of mistake when coding.

Except it’s kind of impossible with the way Java works. There is no indication in a pointer that “this object is constant” and it would basically bloat everything just to provide that.

…all to prevent a programming mistake that is made rarely and usually only once per dev.

Actually there is : “const”
But its not working, there is a lot of requests to finish this implementation in the java language.
The lazy sun gives some excuses some time ago saying its too hard to finish it, and Oracle said some time a go that they will implement…
I know this is pure java discussion, but its interesting and its on topic.
The follow cmd was planned to be implemented :

final const Object fco = new Object();

Yes, but if you really understand what it would take to make that work for real then you understand why it’s too hard to implement. It’s basically a similar reason as to why we only have a half-way implementation of generics.

Because what happens when you pass that to a method? (And remember, Java is not statically linked like C/C++.) What happens when you return it from a method? What happens when you have to support const casting to work with older libraries? (Oops… all benefits of const gone but with all of the new pain.)

Edit: and actually the const casting thing is probably a red herring because you just plain wouldn’t be able to work with old libraries most likely. The class formats would probably have to change in a very broken way (with respect to current formats).

I agree with every word you said…
But, its my opinion, its this kind of stuff that make the language better, and worth the effort and break of some compatibility …

break of ALL compatibility. That’s the thing.

IMO, not worth it. Would have been nice if they’d added it from the beginning but kind of too late now. Type erasure in generics is bad enough but at least we get some every day use out of that.