I’ve formed a new project (with Ken’s blessing) as the centralized repository for community-developed utilities for jogl. It’s been seeded with a package encapsulating OpenGL lighting into a Java Class, a basic GLJFrame containing a GLCanvas (i.e. you just attach a GLEventListener, setVisible(true), and it works), and a 3DS modelling file format reader (by Greg Rodgers). Anyone who’s interested is welcome to become an observer, and if you have a utility package to provide (or would like to begin work on a utility requested in the issue tracker), you will be granted access to that part of the source code. I hope plenty of people are interested in this - it’s always easiest if all the utilities you need are in one place. The project can be found at joglutils.dev.java.net
Do you have a website for the project yet?
Hej hej!
I would like to test the 3DSLoader already and so downloaded the joglutils.jar. Unfortunately I could not find any documentation anywhere. Is it not uploaded or written yet, or was I just too dumb to find it? 
Anyway, good luck with this project, I will be one of the first users! 
Eric
It was in the subversion repository, but it didn’t occur to me to put it in the files&documents with the .jar build. There should now be a .zip file with the documentation. It isn’t properly linking to the java.sun.com javadocs (as It didn’t work by default in netbeans, and I haven’t yet worked out how to make it link), but all the docs should be there… Good luck!
I already searched through the repository and found only the same docs that I found now in the zip file. But it seems that all the docs for the 3DSLoader are located in a directory named “ThreeDS” which is missing.
Or am I missing something?
I updated the zip file in the files&documents section of the project to include the 3ds documents. I’m not sure why you can’t see the documentation in the repository… its certainly there…
can you manupulate different parts of a loded object eg load a character and rotate its limbs with my own interpolation code
It looks like it, yes - the loader just loads the file into a bunch of object verticies and materials, and you’re free to modify what actually gets sent to JOGL.
I am writing some shader handling classes for OpenGL 2.0. But stuff like ShaderProgram.add(gl, new VertexShader(gl, resource))) it does some simple shader source preprocessing for, for example, dynamically making scene-specific shaders. The preprocessor can add information about the original source and line numbers to compiler errors/warnings.
This has been a project I’ve had in mind for a while, although someone may have beaten you to it… see the pm I sent. Thanks!
yes, 3ds loader is indeed very useful tool. i’ve tested it already, and it works just fine 
thanks a lot!
but (maybe it’s a n00b question) how is it possible to modify sigle vertices of imported model? what methods need to be used?
i assume using MyModel is not a good idea am i right?
update:
i switched to ASE format, and written a simple parser myself. it’s not as compact as 3DS, but at least it’s easy to parse
Do you need a MD3 loader?
md3? what format is that?
basically, i need some loader to load a model (exported from 3ds max) into opengl, into displaylist for start. i need only basic data about the model: vertices, and possibly edges and colours. i don’t need any texture or animation stuff. i have used vrml before, but ASE seems to be simplier to read.
MD3 is used for Quake 3. I thought you were interested in this, sorry to make you waste your time.
np thanks anyway. eventually, i think i’ll stick with ASE format. maybe with zip compression
I was curious how you were able to get the 3ds loader to work “just fine” … as you say. The reason I ask is because I tried this loader as well and found that it does indeed work on the example 3ds file (if you are able to find it on the net - not sure why it wasn’t included with the zip). But when I tried using the loader on other 3ds files (freely available ones) it had a significant amount of errors and problems. In some cases it did display the object but it would then have what appeared to be vertical spires coming out at almost every vertex…sort of looked like a spiked ball. Other times the loader just crashed because the loader did not properly read the bytes.
I have corrected all of the major problems and even added the handling of the colors/materials so that the loader actually works now and once I correct some problems in my other code I’ll get back to cleaning up the joglutils loader source I have an submit some corrections here…or if someone could point out the best way to submit corrections then I’d greatly appreciate it.
Thanks for improving this code. Please file a bug with the joglutils Issue Tracker and we’ll likely make you a Developer on the project so you can check in your changes directly.
[quote]I was curious how you were able to get the 3ds loader to work “just fine” … as you say.
[/quote]
well, i didn’t test it thoroughly, but i used it to import some models exported from 3ds max, and it worked without errors.
That is really surprising because I’ve tested it with several models and most of them failed quite severely. The resulting model would look like it had spikes growing out of it over the entire model in some case. In another case, when I had more that 65535 nodes the reader failed to read them because of how it was processing the byte stream incorrectly and it crashed. When I had models without textures and instead just lighting then they would fail when I enabled the normals because the normal vector calculations are completely wrong…and I’m not saying just a little wrong, but absolutely incorrect. For example the code has the following in the Loader3DS.java for the calculation:
normals[i].x = normals[i].y*vVector1.z - normals[i].z*vVector1.y;
normals[i].y = normals[i].z*vVector1.x - normals[i].x*vVector1.z;
normals[i].z = normals[i].x*vVector1.y - normals[i].y*vVector1.x;
The code first calculates the .x component based on the .y and .z components and then uses this value to calculate the .y component and hence changes the ,y component but then it uses that .y component and the changed .x component to calculate the .z component…ouch, long sentence.
That normal calculation makes zero sense…and as a result the colors and materials don’t show up correctly at all and the lighting is basically wrong as a result. In the above case, temporary copies should have been made of the variables and then those copies used to make the calculation since they don’t change…but it doesn’t matter because there is actually errors in the little code just above it when the vVector1 is calculated.
I fixed all of this in my hacked code and I need to clean it up before I can submit it. btw, I used this guy’s (http://jerome.jouvie.free.fr/OpenGl/Projects.php) model viewer (project 03) to compare the output of the vertices, textures, normals, etc and hence I was able to track down many of the issues. It will take me a week or more to get to the point where I can submit this as a bug because I had to hack up the code in several places…and no I did not break the code in the process