GL.glMaterialfv

Hello, ;D

while converting the Lession 36 from Nehe Tutorials.
I ran in a Exception using the GL.glMaterialfv Method.

There the Code :


   private void ProcessHelix()                                                                        // Draws A Helix
  {
        float x;                                                                              // Helix x Coordinate
        float y;                                                                              // Helix y Coordinate
        float z;                                                                              // Helix z Coordinate
        float phi;                                                                        // Angle
        float theta;                                                                        // Angle
        float v,u;                                                                        // Angles
        float r;                                                                              // Radius Of Twist
        int twists = 5;                                                                        // 5 Twists


        float [] glfMaterialColor = new float [] {0.4f,0.2f,0.8f,1.0f};                  // Set The Material Color
        float [] specular = new float[] {1.0f,1.0f,1.0f,1.0f};                              // Sets Up Specular Lighting

        FloatBuffer glfMaterialColorBuffer = FloatBuffer.allocate(4);
        FloatBuffer specularBuffer = FloatBuffer.allocate(4);

        glfMaterialColorBuffer = glfMaterialColorBuffer.wrap(glfMaterialColor);
        specularBuffer = specularBuffer.wrap(specular);


        GL.glLoadIdentity();                                                                  // Reset The Modelview Matrix
        GLU.gluLookAt(0, 5, 50, 0, 0, 0, 0, 1, 0);                                    // Eye Position (0,5,50) Center Of Scene (0,0,0), Up On Y Axis

        GL.glPushMatrix();                                                                        // Push The Modelview Matrix

        GL.glTranslatef(0,0,-50);                                                            // Translate 50 Units Into The Screen
        GL.glRotatef(angle/2.0f,1,0,0);                                                // Rotate By angle/2 On The X-Axis
        GL.glRotatef(angle/3.0f,0,1,0);                                                // Rotate By angle/3 On The Y-Axis

        GL.glMaterialfv(GL.GL_FRONT_AND_BACK,GL.GL_AMBIENT_AND_DIFFUSE,glfMaterialColorBuffer);
        GL.glMaterialfv(GL.GL_FRONT_AND_BACK,GL.GL_SPECULAR,specularBuffer);

JBuilder said :

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x69649BC2
Function=[Unknown.]
Library=C:\WINNT\System32\nvoglnt.dll

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.


Current Java thread:
      at org.lwjgl.opengl.CoreGL11.glMaterialfv(Native Method)
      at rendertotexture.Lesson36.ProcessHelix(Lesson36.java:288)
      at rendertotexture.Lesson36.RenderToTexture(Lesson36.java:381)
      at rendertotexture.Lesson36.Draw(Lesson36.java:525)
      at rendertotexture.Lesson36.renderLoop(Lesson36.java:65)
      at rendertotexture.Lesson36.<init>(Lesson36.java:58)
      at rendertotexture.Lesson36.main(Lesson36.java:535)

Is it really the Native Code,or my Code producing the error ?

Bye the Way im using 0.7 of LWJGL
and the NVidia Drivers Version is: 6.14.10.4403
on GeForce 2 MX 400 under Win2k.

Thx,

  • Jens

Easily fixed: you cannot use indirect buffers for LWJGL operations, you must use direct ones instead:


FloatBuffer glfMaterialColorBuffer = ByteBuffer.allocateDirect(16).order(ByteOrder.nativeOrder()).asFloatBuffer();

   glfMaterialColorBuffer.put(glfMaterialColor).flip();

The flip() is now required too because we use the buffer’s current position() and limit() to determine what is actually being passed in to GL. (Limit is not always used but in those functions where you were expecting to type a size parameter and there isn’t one – that’s where we use limits)

Cas :slight_smile:

[quote] The flip() is now required too because we use the buffer’s current position() and limit() to determine what is actually being passed in to GL.
[/quote]
if you use the buffer with the .get(index) a flip isn’t required - is it ?

What flip() does is set the limit to the position and the position back to 0.

In LWJGL we are now passing buffers to all functions offset by their position. In some OpenGL commands a size is also specified, ie. the number of elements expected in the buffer. We no longer allow this to be specified arbitrarily; you have to specify the buffer’s limit to give the size to GL.

Example:
Old way:
gl.genLists(1, Sys.getDirectBufferAddress(buf));

New way:
buf.position(0).limit(1);
GL.glGenLists(buf);

For most GL functions the limit is not used, for example, in glVertexPointer, where all we are interested in is the position at the time the function is called.

But for those functions where we do use the limit, flip’s what you want generally. In the OP’s problem above he could just have easily used position(0) or rewind() though.

Cas :slight_smile:

Thx,

i will try that. :slight_smile:

Bye the Way , i there somthing in OpenGL you havent Ported or missing right now ?

  • Jens

Yes, in 0.7 we’ve started removing methods that are either pointless, pointless in Java, or pointlessly slow.

These means goodbye to most of the methods which take pointers to small arrays, goodbye to most methods taking doubles, goodbye to texture priorities, and goodbye to a bunch of GLU stuff that’s just not needed by pro games programmers.

Amongst other things.

Cas :slight_smile:

Yeah ;D ;D ;D

I was able to port the “Render To Texture” Code, based on the cpp Code avaible at Nehe in Lesson 36.

I will put it on my Website asap - and post the Link for everbody.

  • Jens

Why is texture priorities removed?

  • elias

Texture priorities is an anachronism from when they first thought about implementing textures. The reality of how texturing works turns out to be very different from how the original designers assumed it was going to work.

The short answer is: when you draw a scene, either a texture is in the scene, or it isn’t. They don’t jostle for priority over who gets to be on the graphics card; they’re all required. Any that aren’t required are overwritten as new textures are required when the RAM fills up. If you don’t have enough texture RAM to fit all the textures in the scene into RAM - you have to upload the difference over the top of something. As the next frame is likely to have the same textures in too, you’ll have to replace the bit you’ve overwritten in the next frame, and then once more upload the difference. The driver is the best at figuring out what texture memory to overwrite; generally it will try to overwrite an existing patch of memory the same size, rather than clobber a big texture.

So I removed the methods because they’re a) a waste of space b) don’t improve performance one iota and c) confusing

Cas :slight_smile:

Well, I have to say I like the trimming that’s going on - it’s focusing the API nicely to the intended topic. Users should be a little better isolated from the cruft that’s built up in OpenGL over the years, and hopefully their applications will perform better because of it. I’m just hoping you don’t get over-zealous and discontinue support for things that people really do want… ;D

Q1: Is there any intended release date for 0.7 yet?

Q2: And is the reason for not providing a OpenGL10 interface because you don’t see any need for it - don’t see any cards out there still running 1.0?

We still have some goodies left for 0.7, so there will probably be another pre one of these days. The final will be delayed, which is good, considering our massive API changes (especially the position() and remaining() stuff is sure to break many apps out there).

I don’t think 1.0 would be useful at all - IIRC, 1.0 doesn’t even have proper support for texture objects and display lists.

  • elias

[quote]and goodbye to a bunch of GLU stuff that’s just not needed by pro games programmers.
[/quote]
Does that include quadrics, spheres and cylinders and stuff? Those might not needed by pro’s maybe but I found them handy. The newbie idiot that I am.

Yes, please don’t remove quadrics as I use them extensively for visualizing debug info (bounding volumes, etc).

Yes it includes all GLU quadric shapes.

  • elias

Dang, I’m sorry to hear that. I guess it’s time for me to think seriously about the transfer to JOGL. :-[

edit:
Just saw the thread regarding Quadrics being implemented in pure java at puppygames.

Yes, if anyone wants to help vrm port GLU to Java that’d be very kind :wink:

Cas :slight_smile: