I finally made my updates...I was stuck for a couple of days on loading models/textures from jar files or from a directory and I think I put in a stop gap measure for now that seems to work pretty well. Once I clean it up in my own code I'll have to put that update in this main one as well...either way, right now you can load directly from a jar file or from a directory on your computer.

I made updates to most of the files and I tried to keep the old code in place (commented out) and put the new code near it.

This code still doesn't work for EVERY 3DS model, but it works on significantly more...I think some of the failures are not because of the loader per se but how the read in data is handled. Right now the data is handled very naively...meaning, the code assumes a required texture exists and if one is missing then it will fail to display the model and possibly have a null pointer exception. Things like that will be fixed with time.

I updated the test3ds package as well to include a viewer that fits the model to the view, and adds a mouse handler to rotate the view and adds a simple light, etc.

I uploaded the changed files with the PATCH I made, but for those without access to those files that would like to try out my fixes you can get them from here:

Now I need to go figure out how to preserve the models/textures in the context so that I don't have to reload them when resizing the screen....using GLJPanel for my own project and this is a big issue.

Z - I am the developer who originally put the 3ds loader code in the joglutils library. Myself and Brian Wood, has since made lots of changes to it. I would like to go through your code and merge it with the changes we have made. One big change with the loader is that the model has been abstracted from a specific model type implementation (whether it is a 3ds, obj, etc. implementation). The loader does support the obj format now and has the ability to support many more. There are still several areas that need work.

Z - I am the developer who originally put the 3ds loader code in the joglutils library. Myself and Brian Wood, has since made lots of changes to it. I would like to go through your code and merge it with the changes we have made. One big change with the loader is that the model has been abstracted from a specific model type implementation (whether it is a 3ds, obj, etc. implementation). The loader does support the obj format now and has the ability to support many more. There are still several areas that need work.

that's fine...definitely go review it. I guess I don't understand what you are trying to say right now though...I've not changed the abstraction of the code update I gave you (though I could be wrong). Mainly I fixed a lot of bugs that didn't allow me to load most 3DS models I had...heck even the globe.3ds model was incorrectly textured because the texture was being placed upside down on it (needed to do an AffineTransform on the texture). The other fixes included some incorrect manipulation of bytes, incorrect calculation of normals, and there was something wrong with textures or materials (I can't recall which right now) being associated with objects when the 3DS spec says that they are associated with faces.

As a comparison of the updates, I would recommend trying to load any of the 3DS models that I included and you'll notice that many won't be able to be read by the original code but are now possible with the updates. I know I still have some things wrong but I hope I made enough improvements (hopefully didn't break anything) that this could be useful for you.

Thanks for putting this code out there in the first place...holy cow this saved me a lot of time. I'd also be very interested in what other loaders are being added...VRML would be a nice one since I have some models in that format.

Mainly I fixed a lot of bugs that didn't allow me to load most 3DS models I had...heck even the globe.3ds model was incorrectly textured because the texture was being placed upside down on it (needed to do an AffineTransform on the texture). The other fixes included some incorrect manipulation of bytes, incorrect calculation of normals, and there was something wrong with textures or materials (I can't recall which right now) being associated with objects when the 3DS spec says that they are associated with faces.

As far as the upside down texture, I use opengl to flip the texture (part of my updates) as compared to java's AffineTransorm (not sure which one is more efficient ). It looks like you were flipping it without checking to see if it needs it. "com.sun.opengl.util.texture.Texture" provides a method "getMustFlipVertically()" to see if it actually needs flipping.

As a comparison of the updates, I would recommend trying to load any of the 3DS models that I included and you'll notice that many won't be able to be read by the original code but are now possible with the updates. I know I still have some things wrong but I hope I made enough improvements (hopefully didn't break anything) that this could be useful for you.

Thanks for putting this code out there in the first place...holy cow this saved me a lot of time. I'd also be very interested in what other loaders are being added...VRML would be a nice one since I have some models in that format.

I hope I've addressed most of the issues that prevent any models from loading, but I will check the ones you mention. Hopefully with both our changes we can illuminate these cases.

gotcha...maybe you caught some of the bugs I found, so that's good. Also good info on the upsidedown texture issue, I'd be interested in seeing that fixed correctly so I can update my code.

Btw, I did add two new classes that probably need some work...one was the ResourceRetriever that helps you load from either a jar or directory path, and the other was the Bounds class into the Three3D package to track the bounding box of the model....I hope that one still makes it into the package or maybe that could be abstracted higher for use with other loaders.

I can't wait for your corrections, it'll definitely be nice to have this loader fully functional. I hope you also use some of the test3ds code I provided to allow the users to view the models better...or maybe improve on it because I'm relatively new to JOGL. Have fun looking through my updates and if you have questions then let me know. Thanks.

I would also appreciate anyone using the 3DS loader to contribute any suggestions as to how to improve frame rates with 3DS models. I happen to have a 3DS model of the International Space Station which has probably 100,000 polygons/faces and when loading it in a 320x240 GLJPanel (I can't use GLCanvas) I get frame rates down in the teens (15 fps, etc) but when I remove the model I get frame rates of 40 fps or more. I know this has to do with the large number of polygons in the model and I'm going to try to reduce those but I was also wondering if maybe the way I'm generating the call list or how I'm drawing the model itself is possibly causing the poor rates. I'm not sure if there are any simple things I could try right of the bat or not? In particular, the current way the model is being called is by generating the various OpenGL calls within a Call list and simply calling the list during the render process...is there something else more specific that I should also be doing...I believe this was the default behavior of the loader and test code...if not, then take a look at the code I attached a couple of posts above.

Did you render your model with display lists ?For my little experience rendering 3ds models, the highest frame rate I get is not with display list.For 3ds models made of lot of different meshes and with high number of vertices, I generally got better results with vertex array (and even more with vbo).

Here is a result that may (or may not) be usefull for you : Direct Mode : ~3 fps; Display List : 4,5 fps; Vertex Array : 14 fps; Vertex Buffered Object (VBO) : 36 fpsI've made it with a 3ds model made of 500,000 vertices (ie 166,600 triangles), having 40 different materials in 560 meshes and displayed on a 1200x800 frame.

You can also optimize the model by : - sorting the meshes inside the model with the same material (ie same texture ...) and render them at the same time (ie in the same 'packet' of data) - pre-transform the meshes at loading time to save some possible glMultMatrix and a push/pop (sometimes there is a different transform for each meshes inside a model or a mesh hierarchy with multiple levels). - don't send unecessary datas (ie normal if no lighting is used ...). - ...

Did you render your model with display lists ?For my little experience rendering 3ds models, the highest frame rate I get is not with display list.For 3ds models made of lot of different meshes and with high number of vertices, I generally got better results with vertex array (and even more with vbo).

Here is a result that may (or may not) be usefull for you : Direct Mode : ~3 fps; Display List : 4,5 fps; Vertex Array : 14 fps; Vertex Buffered Object (VBO) : 36 fpsI've made it with a 3ds model made of 500,000 vertices (ie 166,600 triangles), having 40 different materials in 560 meshes and displayed on a 1200x800 frame.

You can also optimize the model by : - sorting the meshes inside the model with the same material (ie same texture ...) and render them at the same time (ie in the same 'packet' of data) - pre-transform the meshes at loading time to save some possible glMultMatrix and a push/pop (sometimes there is a different transform for each meshes inside a model or a mesh hierarchy with multiple levels). - don't send unecessary datas (ie normal if no lighting is used ...). - ...

Tell me if that's usefull for you

Thanks Jerome for the response and the suggestions. I do use display lists because that is all I know of OpenGL at the moment and so I will have to investigate your suggestions. The FPS for the example model you note are spectacular. The main thing that I'm currently loading is a model of the International Space Station (ISS) that was based on CAD drawings and originally in VRML format which I converted to 3DS. As such, the model contains many polygons even though it is only a low fidelity model of the ISS...it contains 38381 faces, 10112 meshes and 74557 vertices with 256 materials (based on your Model Viewer info). In your Model Viewer I get a frame rate of about 30 FPS but in my display (320x240) when I simply display a textured Earth, moon, stars and sun I get an rate of 38 fps, when I make visible the model that I loaded I get 11 fps...that is a horrible drop - though I believe I must be doing something else poorly given that I have such a poor frame rate (38 fps) with just the 2 planets and stars and sun for that small of a window. (running on a Pentium 4 3.20 GHz, 2 GB of RAM, ATI Radeon X1650 XT crappy video card (256mb))

I'd like to add one more thing...Jerome has been quite helpful in answering many of my questions on the 3DS loader topic in the past and I used his exceptional 3DS loader to help diagnose the issue with the joglutils loader. In particular the ability of his loader to display all of the nodes, faces, normals, etc from within the viewer he has helped me figure out what the joglutils loader was reading incorrectly and where. Thank you very much....for those interested, here is a link to Jerome's site: http://jerome.jouvie.free.fr/index.php If you go to his OpenGL Projects (Project 3) you can also use his model loader/viewer.

Initially I thought it was having to do with Main.java accidentally having 'frame.add(canvas)' twice (I didn't do that...it was there to begin with) but removing one of those lines has not helped....does anyone know the issue here? It must have to do with GLCanvas because I use GLJPanel in my own code with JOGL rc8 adn rc7 and it works perfectly fine.

The code compiles fine but this happens at runtime...I'm pretty sure I have my classpath and library paths setup correctly because, as I said, it runs fine for my other codes that use GLJPanel and even use the joglutils code and it runs perfectly fine in rc6. Sorry I didn't check this sooner with rc7 when I submitted my update to joglutils.

I'd like to add one more thing...Jerome has been quite helpful in answering many of my questions on the 3DS loader topic in the past and I used his exceptional 3DS loader to help diagnose the issue with the joglutils loader. In particular the ability of his loader to display all of the nodes, faces, normals, etc from within the viewer he has helped me figure out what the joglutils loader was reading incorrectly and where. Thank you very much....for those interested, here is a link to Jerome's site: http://jerome.jouvie.free.fr/index.php If you go to his OpenGL Projects (Project 3) you can also use his model loader/viewer.

Thanks Also, just in case that someone could be interested, there is also a (new) utility for map edition : Map/World Editor (Project 5). I've starten this tool just few times ago, but it grows a little day-by-day. For more informations, just visit my pages.

My best guess is that you're throwing an exception out of your display callback and JOGL isn't releasing the OpenGL context. Can you check to see if that's the problem?

Sorry I haven't had time to integrate your changes to the joglutils project yet. I'm swamped with work on the new Java Plug-In.

Nope, I don't have any exceptions that are being thrown from my display callback...though wouldn't I see this same issue if I was in JOGL rc6 if I was having an exception?I'm seeing this issue in any code that uses GLCanvas (as in the test3ds.Main) code...and I'm not even talking about the updated code that I submitted because this happens on the original joglutils test code that has none of my updates.

This is only happening on rc7 and rc8 of JOGL and I'm definitely not smart enough to figure out what the issue is...it even happens if I turn off all of the joglutils calls.Here is some sample code where I've completely stripped everything out...I mean everything is gone and i'm basically creating a GLCanvas() and starting the Animator and that is it....note that if I replace the GLCanvas() with a GLJPanel() it runs fine in rc6 and rc8. GLCanvas() runs fine in rc6 but throws the exception below in rc8.

Be aware that I have not messed with GLCanvas() recently so I don't know if any of this code is correct....though this is the stripped down joglutils test code (Main.java)...I probably should start a separate thread because it appears not to be a joglutils issue which I thought it was at first.

Nope, I don't have any exceptions that are being thrown from my display callback...though wouldn't I see this same issue if I was in JOGL rc6 if I was having an exception?I'm seeing this issue in any code that uses GLCanvas (as in the test3ds.Main) code...and I'm not even talking about the updated code that I submitted because this happens on the original joglutils test code that has none of my updates.

This is only happening on rc7 and rc8 of JOGL and I'm definitely not smart enough to figure out what the issue is...it even happens if I turn off all of the joglutils calls.Here is some sample code where I've completely stripped everything out...I mean everything is gone and i'm basically creating a GLCanvas() and starting the Animator and that is it....note that if I replace the GLCanvas() with a GLJPanel() it runs fine in rc6 and rc8. GLCanvas() runs fine in rc6 but throws the exception below in rc8.

Be aware that I have not messed with GLCanvas() recently so I don't know if any of this code is correct....though this is the stripped down joglutils test code (Main.java)...I probably should start a separate thread because it appears not to be a joglutils issue which I thought it was at first.

As one of the joglutils project owners I'm sorry I haven't helped push this through...but I note that rodgersgb is a Developer on the 3ds portion and intended to put it in earlier. rodgersgb, can you take care of this?

Otherwise, Z-Knight, please apply for a Developer role (assuming you're comfortable using Subversion) and I'll approve it so you can check in your changes directly.

Finally, which loaders will JOGLUtils contain? I see it already contains a 3DS loader. Is it planned to provide a OBJ loader and a MD3 loader? What about adding a minimal scenegraph, something lighter than in Java 3D?

Finally, which loaders will JOGLUtils contain? I see it already contains a 3DS loader. Is it planned to provide a OBJ loader and a MD3 loader? What about adding a minimal scenegraph, something lighter than in Java 3D?

Right now it supports 3DS and OBJ. The OBJ loader is not fully implemented yet because I ran into some problems with the way the Object mesh is defined. The OBJ format is much more bloated than 3DS. I think that coming up with a good scenegraph would fix these issues. It would also allow a way to handle LOD.

I don't know how permissions to write to sub-portions of the repository work so I've added both you and Z-Knight as Developers. Let me know if you need anything else, and please be careful to not break anything in the repository.

I don't know how permissions to write to sub-portions of the repository work so I've added both you and Z-Knight as Developers. Let me know if you need anything else, and please be careful to not break anything in the repository.

Thanks Ken, I have no intentions of going outside of the model package you added for me.

I have put all my code in the net.java.joglutils.model package. The loader supports 3ds and obj (not fully implemented yet).

Z-Knight, if you're not happy with the citations I put in there for you, by all means change it. I appreciate the work you did on the 3DS portion.

Citations are not important to me as long as the loader/viewers work for me and everyone else. Glad to have helped. I've not tested the new version since I'm still working with the old layout in my own code but I will as soon as I get some time. Thanks for the updates and the new obj loader start.

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