Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (552)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 8
1  Java Game APIs & Engines / JOGL Development / Re: opengl.util.BufferUtil and VBO on: 2011-10-13 16:26:07
Ah, you're using JOGL. BufferUtil is part of LWJGL, which is an alternative to JOGL. Personally I prefer LWJGL, but you can just make your own utility class for buffer creation. To create other buffers (FloatBuffer for example) just create a ByteBuffer (with the code I posted) with 4 times the size (as you'll need 4 bytes per float) and use asFloatBuffer().

wait, what?!?  BufferUtil is part of JOGL... it is in: com.sun.opengl.util.BufferUtil

So this is what I usually do:
1  
vertices = ByteBuffer.allocateDirect(totalBuffer * BufferUtil.SIZEOF_FLOAT).order(ByteOrder.nativeOrder()).asFloatBuffer();


You also need to remember to 'rewind' the buffer, I think:

1  
vertices.rewind();
2  Java Game APIs & Engines / JOGL Development / Re: Search for a good jogl book on: 2011-10-11 17:32:37
JOGL is really no different than OpenGL. I would just get the Redbook for OpenGL or read it online and be done with it. After that I would just use example code to get your base template created and go from there.
3  Java Game APIs & Engines / JOGL Development / Re: ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 17:35:05
Another thing I noticed with GLCanvas has to do with resizing it. I have it part of a top component of a JSplitPane. When I resize the bottom component by moving the divider down the GLCanvas grows bigger but then it prevents me from shrinking it back. The bigger it gets the bigger it stays and won't let me make it smaller? Any idea why?

Edit: Seems like others have had the same issue and this is due to the heavyweight of GLCanvas
  http://forums.techarena.in/software-development/1267145.htm

Sigh...now you see why I chose GLJPanel.   Grin

Edit 2: It seems I need to do more searching...hehe. Here is the solution http://www.java-gaming.org/index.php/topic,18457..

Basically I added this setMinimumSize() on the panel that contained my GLCanvas:
1  
2  
3  
4  
// We need to create a Dimension object for the JPanel (containing the GLCanvas) minimum 
// size to fix a GLCanvas resize bug. The GLCanvas normally won't recieve resize events
// that shrink a JPanel controled by a JSplitPane.
setMinimumSize(new Dimension());    


Thank God for JOGL developers that came before me. Smiley
4  Java Game APIs & Engines / JOGL Development / Re: ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 15:28:11
So far, the main break I have after fixing the flicker (see above) is that my JMenus appear beneath the GLCanvas - basically a lightweight/heavyweight issue.

I saw that this kind of issue seemed to be fixed with JDK 6.0 update 12 and above...but I have update 23 and I still see it. This is the quote I found http://java.sun.com/developer/technicalArticles/GUI/mixing_components/. Maybe I need to try JDK 7

Quote
As of the JDK 6 Update 12 and JDK 7 build 19 releases, it is now possible to seamlessly mix heavyweight and lightweight components within the same container. The following screen captures show the same three examples, run under the JDK 7 release, with no changes to the code. In each case, it just works.

Edit: GLCanvas is still causing my popup panels (JWindows) to get partially hidden. Too bad this wasn't truly fixed as they say.
5  Java Game APIs & Engines / JOGL Development / Re: ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 15:02:47
I noticed one thing strange in my GLCanvas version that has me additionally focused on the GLJPanel and that was some horrible flickering. I need to test it again but it was the flickering of the canvas itself that just made it too frustrating to use.

Edit: yeah, still have it. When I move my frame the GLCanvas section just flickers until I stop and sometimes it just goes blank (disappears) and I have to click inside the GLCanvas section to get it to come back. It is frustrating as hell.

Edit 2: I saw a post by 'cgull' at http://stackoverflow.com/questions/414915/jmenus-caused-jogl-glcanvas-canvas-to-flicker that said the following in the quote below...and it seems to be working. I just need to make sure it doesn't break something else.

Quote
This is caused by AWT erasing the GLCanvas every time before JOGL repaints it and can be worked around by inserting the following line into your main() method:

System.setProperty("sun.awt.noerasebackground", "true");

While this solves the given problem, side effects are possible in other areas of the application such as visible artifacts when resizing the window. I use this in all my JOGL apps though without any problems.

Edit 3: I need to give up...I really do. Now the noerasebackground is essentially preventing any updates to my scene unless I move my mouse in the view. This is so damn frustrating - have I said that yet?!
6  Java Game APIs & Engines / JOGL Development / Re: ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 14:16:13
I have to use the GLJPanel because I'm inside a Swing component/frame so the GLCanvas won't help me. I'm not doing anything as taxing as a game, simply I'm drawing a 3D scene with the International Space Station vehicle (loaded from a 3DS file) and other approaching vehicles to show their relative position/attitude. I don't think it has to be on par with game performance, as long as I can get sub-second updates of the scene because my telemetry updates would come down at least at 1sec rate and I can't be waiting for the graphics to still update.

How do you go about the context sharing - I understand the concept in principle but have no idea how to even start that. As for the HashTable approach, I'm not sure how do I use it to use it to deal with more complicated things besides display lists - like the textures or buffers? In either case, at minimum I need to make sure that once I load my textures and buffers that I store them away and only during init() do I bind them - right? There is nothing else like having to recreate buffers (I just can't recall)?

I guess what I'm asking is for some direction on how to do the context sharing and/or hash table approach - is there some good reference I can look at or do you have some sample I can check out? The main reason I need this ability is because the graphics card I use on my development machine is poor and display list updates (and vertex buffer/array updates) for my 3DS models seem to take a long time, and if the user does too much resizing then they will really start to get annoyed at the delay.

thanks.
7  Java Game APIs & Engines / JOGL Development / Re: ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 00:07:41
Sorry for my constant posts...here is what rogersgb had suggested...I may need to look at this:

Quote
I have the same problem with textures and display lists on a GLJPanel. I store them in hash tables when they are created. If they need re-initialized due to context destruction I just grab them back out of the hash table. That implementation works for a heavyweight canvas as well.
8  Java Game APIs & Engines / JOGL Development / Re: ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 00:05:40
I had posed this question a while back in:  http://www.java-gaming.org/topics/gljpanel-and-the-init-method/18054/msg/141666/view.html#msg141666

The answer at the time involved "It was suggested that I essentially build a separate GLContext at the start where I load my textures and models (make it current initially and then release it), then follow this with building the normal GLContext for my scene and then share the initial context data with it in the init() function (i.e. following resizes, etc)." ... has anyone done this?
9  Java Game APIs & Engines / JOGL Development / ? What is best way to keep context after reinit/reshape ? on: 2011-10-06 00:02:17
When you reinitialize/reshape a JOGL display I believe the context get destroyed and the init() method has to be called again to restore things. This is bad because I lose things like my display lists or my VBOs or Vertex Arrays and I have to recreate/rebind them, etc.

What is the best way to prevent this...how can I maintain reference to, say a display list, so a reshape doesn't require me to remake it? If I'm resizing my window or revalidating the panel that my GLJPanel resides in then I lose my context and I have to wait and rebuild things - this can be annoying for users.

I read a while ago about "sharing contexts" but I don't know how that works. Any suggestions on what to do?
10  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-05 14:35:19
I could do that, but my problem would still exist. The issue is not so much the command that I use there, but rather that certain OpenGL commands are placed there.

Instead of having a glColor3D() I can put a glEnable(GL_TEXTURE_2D) or glDisable(GL_MATERIAL_COLOR) and it will have the same effect. But not all OpenGL commands cause problems...I can put a glIsEnabled(...) and it works just fine.

At first I thought the glEnable()/glDisable() were bad because they query a state variable from OpenGL which is done internally via a massive SWITCH() statement. But glIsEnabled() is also using a large SWITCH() statement so that can't be the cause.

I can't see what I'm doing wrong, so it is quite easy to point at the video card or the driver and say that this is a result of some error in their Display List handling. It could be that my Quadro video card is at fault - quite disappointing if that is true. I'm going to have to test this on other computers to truly convince myself of this fact. I just can't imagine that some video card that was created by very smart engineers would not support display lists correctly - it just has to be something that I'm doing wrong since I'm the one with much less knowledge (at least that's what I'm feeling in the back of my mind right now).

thanks.
11  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-04 20:18:44
It might be that my NVidia Quadro NVS 140M Laptop based video card is a problem here - or the video drivers.

Loom_weaver tried it and had no problems and not big delay like I experience - so maybe it is a hardware/driver thing or some kind of funny that I'm unlucky to experience. Coupled with 3DS models that have lots of objects could be a cause here too.  I need to do more investigation because I can load my models relatively fast (no big slowdown) when I use commercial software like Right Hemispheres -> Deep Exploration 6.5 viewer (trial edition).

I want to thank Loom_weaver for taking the time and effort to do some independent testing for me - Thank you!
12  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-04 19:56:16
so with my larger model, having 4700 objects, the rendering is almost instantaneous when I don't have those extra glColor3d, etc calls. But when I have those inside the code, I get about a 10-15 second delay for the first render and then everything is fine.

So I see this output at the very end:

Quote
-display()-----------------------------------------------
[null] Update Display Lists[null] Immediate Mode time: 31
...done. 31
 display() loop time: 31
         start to vehicle render: 0
            vehicle render total: 31
           vehicle render to end: 0
    time between display() calls: 16
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: 0
            vehicle render total: 0
           vehicle render to end: 0
    time between display() calls: 12174
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: 0
            vehicle render total: 0
           vehicle render to end: 0
    time between display() calls: 32
BUILD SUCCESSFUL (total time: 1 minute 13 seconds)

Note the RED line above showing a 12 second delay.
13  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-04 19:44:12
Thanks for checking it out....I guess one problem is that I'm on a Intel Core 2 Duo t9300 @ 2.5GHz with 2GB of RAM and you are on something much faster. And as a result you might not be seeing that significant of a pause as I'm seeing. Maybe my more complicated model would have a bigger effect.

Let me look for a more complicated model - or maybe you can PM me with an email and I can send you the one I have - zipped it should fit in an email. Maybe then the difference would be noticeable.
14  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-04 18:05:10
sheesh...finally found a site where I can upload my source code example - all others were blocked by my lovely work spy-on-your-employees system.

Here is the link to the JOGL version 1.1.1 example:  http://www.nippyzip.com/uploads/111004013618-16435.zip - that should be good for 3 days.

I included a 3DS example file called "Gantry.3ds" and my source code that includes helper classes (JOGUTILS 3DS loader stuff) and my modified Viewer and Renderer. This file is comprised of about 700 objects, 174000 vertices and 177000 faces.

Copy all the files into one project folder and copy the Gantry.3ds file to some directory and note the path. Then edit the 'Dumb3DSViewer.java (line 87) and set the path to this model in that location.

To run the program you run the 'Dumb3DSViewer.java' class. When it starts it will show a blank 3D scene with only the colored 3D axes. You can use the mouse to do some crappy rotation. Since I don't use an FPSAnimator, the updates to the scene occur as a result to changes in the view - so when you move your mouse to rotate the scene then stuff gets updated. So keep that in mind because you will have to do some rotations while the model is loading to see the issue that I am seeing.

Ok, so, when you run the program (Dumb3DSViewer) scene is empty...so hit the 'Z' keyboard key to load the 3DS model in the background. While that is loading make sure that you are rotating the scene (the 3D axes) around so you can see the updates occurring. While you are doing your mouse rotation you will notice a period during which time you will lose control and nothing will update - probably like 3-4 seconds later the update will finish and the model will be displayed and you will be able to continue rotating.

If you go into the 'Dumb3DSRenderer.java' (line 287) there will be the glColor3d(1.0, 1.0, 1.0) call that you can comment out and repeat the process. With this line commented out the 3DS model will load super fast and display almost immediately...I mean you probably have to be moving the mouse around before you hit the 'Z' key to load the model so you can see the effect.

So...you might be wondering if my loader is the cause or the way I load by using a separate thread to spawn the loading in the background. Sure, I thought about that, but if the separate thread was the cause then I should see that same issue irrespective of having the extra glColor3d() call or not. I think this has something to do with the way I'm rendering or creating display lists - I don't know.

I did figure out one thing though - the 3DS model has a lot to do with it and not so much how many vertices or faces it has but rather how many objects it has. The model, Gantry.3ds, only has 700 objects but my work models have about 4700 and if you notice the rendering loop (drawImmediateMode() method on line 278 of Dumb3DSRenderer) I loop over the objects. I used models with more vertices and faces but only like 10-20 objects and the scene was generated super fast....so that kind of confused me as to what is going on.

So having 4700 objects means I loop a lot and have many calls to glColor3d() - but it is necessary because each object could have a different color/material/texture so I can just have one global color call. Note in this example I am only using one color just for testing purposes but the full code has the specific color/material/texture calls for that object.

I hope that is all clear - I know it is kind of wordy.


P.S. For grins and to blow your mind even more, move the gl.glColor3d(1.0, 1.0, 1.0) from the drawImmediateMode() method in Dumb3DSRenderer.java from outside of the glBegin(GL_TRIANGLES)/glEnd() to inside that loop and notice what happens. Tell me it is not confusing that simply moving that call inside the glBegin/glEnd block speeds it up!?! But at the same time, if I try to add a glEnable(GL_COLOR_MATERIAL) call inside or outside the glBegin/glEnd block the slowdown is the same. Hence my crazy situation - I don't know what is going on. And if anyone does I would be eternally thankful - or for at least a couple of weeks.

15  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-03 22:27:08
I'll post something in the morning tomorrow (Tuesday)...I need to find a 3DS model that I can attach.
16  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-03 21:40:31
yeah, I'm working on a super stripped down version of both my render code and an example that uses it. I'll keep the 3DS loader pretty much intact because that loading part is fine.

I've ripped out all of my VBO and vertex array code and am working on stripping out all extra calls/methods I had for my own benefit that are not needed in the example. I also need to add a new mouse listener to allow you to rotate the scene because I took out my camera code for fear that it was the problem.

After all of the stripping so far, I still have the problem. I hope to have an example code uploaded today - but worst case it will be tomorrow morning. Thanks for your help.
17  Java Game APIs & Engines / JOGL Development / Re: ? DisplayLists with weird rendering problem ? on: 2011-10-03 21:14:23
yeah, but that was just an example....forget that glDisable() call because I get the same issue by simply having a glColor3d(1,1,1) call in its place.

I had a bunch of texture/material calls in my code that are different for each "group" that I have, which is why I made mention of it. But I commented everything out...it is barebones now and I only add that glColor3d() call and it is still causing that delay between update loops.

OH yeah...forgot to mention that I'm still using JOGL version 1.1 (or whatever the last 1.XX release was prior to JOGL 2.0).
18  Java Game APIs & Engines / JOGL Development / ? DisplayLists with weird rendering problem ? on: 2011-10-03 20:57:51
I am about to bash my head into this monitor because I cannot figure out the cause, the source or the solution to a very weird rendering problem. I'm trying to work on a simple version to demonstrate the issue but in the meantime here is my problem.

I am working on rendering a 3DS model. I am able to read in the model quickly enough and then I try to render it and this is where I get the weird results. I have two ways of rendering: Immediate Mode and Display Lists. The Immediate mode rendering has no problems, other than it is a bit slow if I have large models. The Display Lists mode is essentially created using:

Quote
  gl.glNewList(list, GL.GL_COMPILE);
    drawImmediateMode();
  gl.glEndList();

This is essentially my Immediate Mode rendering code (psuedo code):

Quote
  private void drawImmediateMode(GL gl) {

    for (int i = 0; i < objects.size(); i++) {
      Obj tempObj = objects.get(i);
      if (tempObj.groups != null) {
        for (Obj.OffsetAndLength group : tempObj.groups) { 

          // gl.glColor3d(1.0, 1.0, 1.0);                <===== Adding this line, or the one below it causes
          // gl.glDisable(GL.GL_TEXTURE_2D);                   a massive slowdown during first rendering
                                                                             when using DISPLAY LISTS. Taking these out
                                                                             results in no problems at all.


          gl.glBegin(GL.GL_TRIANGLES);
            for (int j = group.offset; j < group.offset + group.length; j++) {
              gl.glNormal3f(normal.getX(), normal.getY(), normal.getZ());             
              for (int k=0; k<3; k++) {
                gl.glVertex3f(verts[k].getX(), verts[k].getY(), verts[k].getZ());
              }
            }                     
          gl.glEnd();
     
        }
      }
    }

  }

When I render I simply do the following:

Quote
public void display() {
   gl.glCallList(list);
 }


So here is where it gets weird. I put timing statements all over the place to measure how long something takes to complete. The loading of the model is tiny. The rendering in immediate mode is tiny. The creating of the display lists is tiny. Calling glCallList() on the list is tiny.

BUT....upon the first rendering my updates get blocked for a period of time that is proportional to the size of the 3DS model only if I include the RED section above....for some reason calling any of those methods, and others as well causes a massive slow down that takes control of my update and does not return it for a few seconds. Effectively the time between the end of the first display() call and the start of the next display() call is delayed by the few seconds.

I have NO IDEA why this is happening...I can take out those glColor3d() or glDisable() calls and it is fine. I can put in a glIsEnabled() call and it is fine too but certain gl calls cause my slowdown. I can't understand what is happening here at all. I realize the first time you send something to the graphics card via a display list invocation that things can be slow....but in my case the display list is only bad/slow when those extra commands are sent and those can be in a display list - as far as I'm aware.

I don't know if this is an OpenGL question or a JOGL question...btw, I control my display updates using the display() call on my GLJPanel, but somehow this issue is preventing from making any updates...I essentially lose all listener control, the long pause occurs and then I get them all back and the scene continues to render without any problems...only that first one is an issue.
19  Java Game APIs & Engines / JOGL Development / Re: ? Texturing many triangles - 3DS loader question ? on: 2011-09-15 19:30:53
Very good info, thank you.  FYI, currently I was summing the normals from all coincident faces for the vertices. Then normalizing all normals.

It seems like the correct way is as you say and as other suggest so I might have to look into it.

Thanks again.
20  Java Game APIs & Engines / JOGL Development / Re: ? Texturing many triangles - 3DS loader question ? on: 2011-09-14 20:32:59
I have a follow-up question, lhkbob....it relates to the colors.

I have a cross post of this question at the Opengl Forums: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=302948#Post302948

In the case of 3DS files you can read in all of the vertices in a list but to get the colors for each vertex you have to loop through the faces and get the face material/color id and then apply it to the vertices of the face. In doing so you will get cases where a neighboring face will have a different material and so two of the vertices that you previously set to have a particular color will now be overwritten with the color of the second face. As a result you can end up having face #1 have only one vertex set to the original color and the other two vertices correspond to the color of face #2. When you draw them using those colors, the phong modeling (I believe) will then cause the colors to blend across the triangle and so for triangles along edges between two different materials/colors you will not have a crisp line but can get "bleed" through.

This is the picture showing the bleeding:



So, I was wondering what I could do to avoid this issue when using the vertex arrays and having a colors buffer that is a one-to-one correspondence with the original vertex buffer. And the original vertex buffer only contains unique vertices and hence no duplicates.

The suggestion I got from the opengl people is to duplicate vertices when I loop through the faces so that I can have multiple coincident vertices that have different materials/colors but they will be correctly aligned with the faces/triangles when they are rendered. I'm not convinced this is the optimal solution but I'm not exactly sure what else to do. I tried to instead get rid of my current glPointerCall and instead explicitly set the colors via glColor3d() inside the group-loop - it still had some bleed through, though it was in a black color and so I'm not sure if I have something else that could be the cause or not.
21  Java Game APIs & Engines / JOGL Development / Re: ? Texturing many triangles - 3DS loader question ? on: 2011-09-07 21:32:22
So far the Immediate mode rendering seems to work correctly. I need to make sure it renders as fast as the naive case ran before (ie when I only had one material) - it will tell me if I need more optimization or not.

Also, I found out that some 3DS files also have bump maps for materials!!! LOL...yet another thing to try to figure out - but that will have to come much later.

Thanks.
22  Java Game APIs & Engines / JOGL Development / Re: ? Texturing many triangles - 3DS loader question ? on: 2011-09-07 18:28:32
Thank you very much, I'll try to see what I can do. Thanks for the pseudocode.

I'd really like to get this 3DS loader to a good level so I can finally return it to the wild (i.e. to JOGLUTILS). I've improved my version of it for the past couple of years until I realized this issue recently. It would be nice for everyone to use it.
23  Java Game APIs & Engines / JOGL Development / ? Texturing many triangles - 3DS loader question ? on: 2011-09-06 20:24:17
This is probably a question for Jerome J. regarding 3DS rendering since he has lots of experience - and anyone else is welcome to chime in too.

I posted this question on the OpenGL forums at: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=302424#Post302424

Basically my issue is that I recently realized that a 3DS model can have multiple textures assigned to one "object" and the way it tells the object which textures to use is by listing the texture id for each triangle. I was using the JOGLUTILS code for rendering 3DS models and that code assumed you only had a single texture per object...meaning that when I was rendering things, the triangles were all getting the same texture and that was wrong.

I'm trying to modify the code to work correctly but I'm having trouble rendering. I initially tried to brute force render each triangle with a bind call to the appropriate texture but this was really slow and I was told that I should not have a BIND call within a glBegin/glEnd block (ie I used the glBegin(GL_TRIANGLES)). Also it was suggested that I sort the triangles to group the ones that share a texture (or material) together and hence only have as many bind calls as I have actual textures - rather than having as many bind calls as I have triangles. This will probably speed things up.

I was wondering if that was reasonable and is this what you'd recommend...this is for Immediate mode rendering.

My next question has to do with Vertex Arrays and VBOs. Because of the assumption of one texture per object, I had written VBO rendering code which renders all of the VBO buffer with the one texture. I guess I will now have to create separate VBO buffers for the textures, correct? Much like using the separate buckets for the Immediate mode?
24  Java Game APIs & Engines / JOGL Development / Re: Make a triangle rotate on: 2011-08-01 16:54:37
Simple answer is that you need to use the FPSAnimator to make it constantly redraw like it does in C based OpenGL.

Option 3 that lhkbob suggested is what I use and I don't think it is a big deal - I just don't want to have my display constantly repainting the same scene that doesn't change. So I force a display update only on keyboard/mouse inputs or various event updates
25  Java Game APIs & Engines / JOGL Development / Re: Trying to load textures on seperate thread, cannot bind context. on: 2011-05-16 14:55:32
IMHO it's much, much easier to keep all of your opengl calls on one thread and ignore the makeCurrent stuff, as it's horrendously error prone and tends to uncover bugs and quirks in drivers.

You can still do all the heavy lifting (like reading the image off disk and decoding it into RGBA bytes) in a seperate thread, and just keep the texture upload in the gl thread. That's pretty quick anyway, and if you have really big textures you can split them over multiple frames if you need to. This is what I do for texture loading and it doesn't impact the framerate at all.

+1, I do 3D model loading and texture loading on a separate thread and update a variable flag that tracks when they are done. I then force a canvas display update and it checks if that flag is set to then take appropriate action - such as creating 3D objects, binding the textures, etc.
26  Java Game APIs & Engines / JOGL Development / Re: Should I move to VBOs? [Resuelto] on: 2011-05-13 16:01:29
It depends on the implementation of display lists in the drivers. When static VBOs are well implemented, you get the same performance than a smart use of display lists.

ahh, good info.

I suspect the same applies to the implementation of the VBOs in the drivers because I'm having heap memory issues and crashes when switching from immediate mode/display lists mode to using vertex arrays/vbos. I run out of memory on the first rendering call and the application crashes on a computer using an onboard Intel Graphics card....sigh, kind of disappointing but nothing I can do about it.
27  Java Game APIs & Engines / JOGL Development / Re: Should I move to VBOs? [Resuelto] on: 2011-05-12 20:24:56
As simple as it may sound you may look into DisplayLists.

I have a program that reads in 3DS graphics files and I implemented 4 rendering modes: Immediate, Display Lists, Vertex Arrays and VBOs. I found the following speed relationships/rankings between these modes:

ModeSetupRendering
Immediate1 (best)4 (worst)
Display Lists31 (best)
Vertex Arrays23
VBOs4 (worst)2

The display lists had the cost of setup that was generally minor but it had the fastest rendering...for one model I had rendering times of 0-15 milliseconds, while in Vertex Arrays and VBOs it was 45-60 milliseconds, and in Immediate mode it was 120 milliseconds.

The downside is that displaylists are locked in to displaying their content, so if it changes (or your window reinitializes) then you need to recreate the list. The same applies to VBOs...you have to rebind and that has a little cost to it. Vertex Arrays and Immediate mode have no cost to reinitialize.

The rendering surprised me that using display lists was much faster than VBOs or Vertex Arrays. I guess I might be able to combine displaylists and vertex arrays/VBOs but I'm not sure...that possibly would be the optimal solution.

Anyway, look into display lists as they may be more useful than you initially thought - I did and it improved my performance significantly.

One MAJOR CAUTION I have with VBOs is that they are apparently not well implemented on Mac OS and as a result you will have a huge slowdown in their initial creation. For the example model I used it took about 1 second to create/bind the VBOs on a PC but 120 seconds (2 minutes!!!) to create/bind on a Mac.
28  Java Game APIs & Engines / JOGL Development / Re: ? Vertex Arrays - Index Out of Bounds issue ? on: 2011-05-10 20:03:43
One of your direct NIO buffers is empty. What is strange is that it is supported with VBO but not with vertex arrays.

I see...so I'll need to put some kind of check to skip empty buffers, I guess. Do you have a suggestion, am I correct? What's the best way to do it.

edit:  I did the following quick check before proceeding with rendering and it might be a good solution.
1  
2  
3  
if (normals[i].hasRemaining()) {
 // render
}
29  Java Game APIs & Engines / JOGL Development / Re: ? Vertex Arrays - Index Out of Bounds issue ? on: 2011-05-10 20:02:46
A previous thread suggestions didn't work either.

Ken Russel suggested in http://www.java-gaming.org/index.php?;topic=12412.0 to perform a buffer rewind(). I already had a vertices.rewind() in the array creation method, and I even tried to add it to the render method but it had no benefit.

Further I even did:
1  
gl.glVertexPointer(3, GL.GL_FLOAT, 0, vertices[i].position(0));


without success. I'm doing this on Windows XP...it works fine for most of my 3DS models, but not for one. I can read that "bad" model just fine and can render it both in immediate mode and in VBO mode without any problems...but in this Vertex Array issue it failed.
30  Java Game APIs & Engines / JOGL Development / Re: ? Vertex Arrays - Index Out of Bounds issue ? on: 2011-05-10 18:19:49
Let me add one more thing...

I use the same 'createVertexArray()' to create the vertices FloatBuffer which I then use in rendering in VBO mode (as opposed to Vertex Array mode). And I have NO PROBLEMS rendering the VBOs. So it is weird that the buffers were created the same way and they work for VBOs but only sometimes for the Vertex Array....using the exact same 3D model.

I render it this way:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
private void createVBO(GL gl) {
    vbo = new int[objects.size()];

    // Generate the vertex buffer objects for the model
   gl.glGenBuffers(objects.size(), vbo, 0);

    // Bind the vertex buffers
   for (int i = 0; i < objects.size(); i++) {
      gl.glBindBuffer(GL.GL_ARRAY_BUFFER, vbo[i]);
      Obj tempObj = objects.get(i);
      int totalBuffer = tempObj.numOfFaces * 3 * 3;
      gl.glBufferData(GL.GL_ARRAY_BUFFER, totalBuffer * 4, vertices[i], GL.GL_STATIC_DRAW);
      gl.glBindBuffer(GL.GL_ARRAY_BUFFER, 0);
    }
}

private void renderVBO(GL gl) {
  gl.glEnableClientState(GL.GL_VERTEX_ARRAY);
  for (int i = 0; i < objects.size(); i++) {
    Obj tempObj = objects.get(i);
    int numFaceIndices = tempObj.numOfFaces * 3;
    gl.glBindBuffer(GL.GL_ARRAY_BUFFER, vbo[i]);                // <=== Bind the buffer
   gl.glVertexPointer(3, GL.GL_FLOAT, 0, 0);                      // <=== VertexPointer offset is 0 (zero)
   gl.glBindBuffer(GL.GL_ARRAY_BUFFER, 0);                      // <=== Unbind the buffer
   gl.glDrawArrays(GL.GL_TRIANGLES, 0, numFaceIndices);
  }
  gl.glDisableClientState(GL.GL_VERTEX_ARRAY);
}


The VBO rendering method is not much different from the Vertex Array rendering method in the previous post...only the binding is required and the VertexPointer has a zero offset.
Pages: [1] 2 3 ... 8
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (41 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!