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

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!

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!

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 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.

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

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.

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.

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

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.

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.

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:

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

maybe the spikes you're talking about are some broken or incorrectly imported normals? what 3ds models do you use? are you exporting them from 3ds max? what version?

11it could be, but I know there are errors in how the bytes are read...I don't recall the exact routine because it has been a month since I fixed it, but I know it was incorrectly reading the bytes for the floats (or was it the ints). Either way, I fixed the code (as far as I can tell) and I even added one line for the handling of the colors which was surprisingly missing. I know the author didn't want to impose a specific solution but not including at least a simple one seems odd.

I don't know which version of the 3DS files I was using specifically and no I did not export directly from 3DS MAX. Although I'm quite confident that the models were valid 3DS MAX models simply because it wasn't just one model but several (11 models tested)...the only one that worked was the 'globe.3ds' model that is referenced in the example code. {start of rant} Why the heck wasn't the globe.3ds model included in the JOGLUTILS package?!?! I had to search the net for this damn file. {end of rant}

Log into java.net, go to the above page (you may need to register as an Observer of the joglutils project first) and then click "Patch" to file a new patch.

I haven't seen any issue / patch filed by Z-Knight.

Sorry, I'm new to this forum so I don't know the process that I need to follow so I would greatly appreciate any step by step instructions of what I would need to do...I don't know how to create patches/etc...I could document what changes I made and give you my updated code.

In addition, I have just started cleaning up the code that I modified (removing debugging statements, etc) and I hope to have this done by the end of the coming week since I have to submit my code in at work and it needs to be in a clean shape. The modifications I did to the code can be rolled into the joglutils work if needed or I can simply document what fixes need to occur to the base code...I'm not sure which is preferred. For example, I changed the code to be able to read 3DS files (and any corresponding texture files) from a JAR instead of just a path...it is more convenient this way.

I think the following are some general updates I made: - fixed reading of 3DS models (specifically corrected how the bytes were being processed ... there was an issue between ints and floats) - Previously, when a model had textures the code would incorrectly assume the textures were in the same path as where the program was being started, and I changed it so that it assumes that the textures are in the path relative to the model file path. - The normals are calculated incorrectly and I fixed this - Material id was incorrectly being associated with 'faces' and not 'objects'... I changed this to follow the 3DS spec more correctly. - added simple code to generate bounding boxes around each object of the 3DS model and an overall bounding box ... this also lets me center the model if I wish (helps because sometimes people put the model center away from the model and so rotations of a model act screwed up) - added some code to the Model3DS to use colors/materials if no textures are present...previously the original author left this blank saying that was to be filled in by the user (so I did)

I know there were other fixes but I've been busy with my project that I was not able to work on the loader stuff lately. I will also make a quick model loader viewer so that you can play around better with 3ds models you have...I can't guarantee all models will now be read in successfully but many more have been for me.

Again, if you could tell me what steps I should take when I'm ready with my changes, either - submit all code for your review or - submit what changes are required to make the current joglutils correct

If you aren't already an Observer of the joglutils project, go here, click "request a role", and request the Observer role. I or we will grant it immediately.

Once you're an Observer, go here, click "Patch" to file a patch, click the joglutils Subcomponent, enter a reasonable summary and description, and click "Submit issue". Then go back to the issue and attach your patch (for example, the revised file or files) to the bug.

I think the following are some general updates I made: - fixed reading of 3DS models (specifically corrected how the bytes were being processed ... there was an issue between ints and floats) - Previously, when a model had textures the code would incorrectly assume the textures were in the same path as where the program was being started, and I changed it so that it assumes that the textures are in the path relative to the model file path. - The normals are calculated incorrectly and I fixed this - Material id was incorrectly being associated with 'faces' and not 'objects'... I changed this to follow the 3DS spec more correctly. - added simple code to generate bounding boxes around each object of the 3DS model and an overall bounding box ... this also lets me center the model if I wish (helps because sometimes people put the model center away from the model and so rotations of a model act screwed up) - added some code to the Model3DS to use colors/materials if no textures are present...previously the original author left this blank saying that was to be filled in by the user (so I did)

That's a healthy list of fixes! I'd be quite appreciative if you could submit them to the project.

That's a healthy list of fixes! I'd be quite appreciative if you could submit them to the project.

It's coming...I'm trying to fix one bug that I'm having for some 3DS files which causes a nullpointer exception because of a missing texture file...I though I had this squashed but apparently not. Plus I had the flu for a couple of days so I'm shooting for end of this weekend to get those changes in.

One major thing I need to do is apply the changes I made in my code onto the jogutils version of the 3DS loader. I combined the MyModel.java code from the test section into the Model3DS.java code of the actual loader since it seemed to make sense to load it together with the model but that's not how it is setup in joglutils so I need to do a small bit of revert...hopefully that doesn't cost me too much time to do...I'm still shooting for the end of this weekend.

DOH...I lost track this weekend, I really feel like an idiot...I'm sorry, I beg for an extension. I totally zoned out this weekend after a horrible week....I've not even done my taxes yet.

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.

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