FrameBuffer throwing ArrayIndexOutOfBoundsException on renderScene

Started by AGP, April 15, 2014, 03:43:26 AM

Previous topic - Next topic

AGP

I'm writing a simple particle system, but World.renderScene(FB) is crashing with an ArrayIndexOutOfBoundsException. The following is my console.

Quote
C:\MyPrograms\3D\Algorithms\ParticleSystems\Flames>java -classpath jpct.jar;. MyFrame
Java version is: 1.7.0_51
-> support for BufferedImage
Version helper for 1.5+ initialized!
-> using BufferedImage
Software renderer (OpenGL mode) initialized
Loading Texture...Flames.jpg
New WorldProcessor created using 1 thread(s) and granularity of 1!
Creating new world processor buffer for thread main
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
        at com.threed.jpct.Object3D.render(Object3D.java:9315)
        at com.threed.jpct.WorldProcessor.processInternal(WorldProcessor.java:21
6)
        at com.threed.jpct.WorldProcessor.process(WorldProcessor.java:110)
        at com.threed.jpct.World.renderScene(World.java:1569)
        at MyFrame.loop(MyFrame.java:35)
        at MyFrame.<init>(MyFrame.java:27)
        at MyFrame.main(MyFrame.java:56)
Terminate batch job (Y/N)?
^C
C:\MyPrograms\3D\Algorithms\ParticleSystems\Flames>

By the way, if I don't call    camera.moveCamera(Camera.CAMERA_MOVEOUT, 2f), it doesn't crash (but I still don't see anything).

AGP

I figured out that if I made the camera a global variable the problem wouldn't occur. But that seems like it should be unnecessary, doesn't it?

If I set Config.glTransparencyOffset = 0.00f and Config.glTransparencyMul = .01f, can I expect transparency to work the same way on both software and hardware renderers?

AGP

By the way, in util.Light's documentation, you have such useful comments as "boolean yes...or no?", but you don't mention the scale of the setIntensity methods. I assume it's between 0-1, since they're floats, but I think this should be mentioned in the docs...

EgonOlsen

Quote
I figured out that if I made the camera a global variable the problem wouldn't occur. But that seems like it should be unnecessary, doesn't it?
That's an indication of something being wrong in your code. The engine doesn't care about where you are storing an instance or not. If that makes a difference, it can only be because the result of some operation is different. If the error goes away if you don't move the camera, that's because the cause isn't visible then and hence won't be rendered.
99.9% of these problems happens, because people are using multiple threads in a way in which they shouldn't. jPCT isn't thread safe. You must not fiddle around with jPCT related instances some anything but the rendering thread, unless you are properly synchronizing things.
If that's not the problem, check your texture assignments.

Quote
If I set Config.glTransparencyOffset = 0.00f and Config.glTransparencyMul = .01f, can I expect transparency to work the same way on both software and hardware renderers?
No. That's because the docs say that "This setting is ignored by the software renderer.". The default setting makes the OpenGL renderer try to mimic the software renderer. If you are changing these values, the OpenGL renderer's output will change but the software renderer will render the same thing.

Quote
...but you don't mention the scale of the setIntensity methods. I assume it's between 0-1, since they're floats, but I think this should be mentioned in the docs...
No, they are in the range of [0..255..]. I should really add this information.

AGP

Quote
That's an indication of something being wrong in your code. The engine doesn't care about where you are storing an instance or not. If that makes a difference, it can only be because the result of some operation is different. If the error goes away if you don't move the camera, that's because the cause isn't visible then and hence won't be rendered.
99.9% of these problems happens, because people are using multiple threads in a way in which they shouldn't. jPCT isn't thread safe. You must not fiddle around with jPCT related instances some anything but the rendering thread, unless you are properly synchronizing things.
If that's not the problem, check your texture assignments.

The ONLY thing I changed was making the camera a global variable. When it's a global variable, I can even move it out. And everything happens in the main/rendering loop. Other weird things are that World.setAmbientLight(0, 0, 0) isn't rendering a black image (it isn't, in fact, making any difference whatsoever), and changing the intensity of my only light in the loop isn't making making it flicker.

EgonOlsen

Again, if changing the way in which you are storing a variable in your own code affects the outcome, then it's something on your side. Think about it: In which possible way should a local storage of some instance affect the result of some other class that works with that instance? Hint: There is none...
Given the others problem that you mention, i would think that something is fundamentally flawed...if it helps, you can send me a test case but i would prefer an Eclipse project...




AGP

I don't know if my last e-mail got lost in the shuffle. I do know that its timestamp looks an hour behind the one before it (e-mail timestamps should just come straight from a server with Grenwhich mean time to avoid this kind of bs). Check it out, please.