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?
11
it 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}
Ken, how does one go about filing a bug report? I think I’ve found and fixed a bug in MyModel dealing with loading textures.
Also, what is the status of Z-Knight’s fixes being included into the utility?
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
Sorry for the long delay.
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.
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.
[quote=“Z-Knight,post:28,topic:28082”]
Don’t worry about it too much, after all you are donating your time and skills. Obviously the sooner the better, but I’m in no big rush. ;D
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:
http://www.zaczek.com/joglutils/ThreeDS.zip - Updated 3DS loader code.
http://www.zaczek.com/joglutils/test3ds.zip - Updated viewer
http://www.zaczek.com/joglutils/models.zip - some free/sample 3DS models (including the original globe.3ds)
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.
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.
I’m saying that I’m going to merge your changes with the ones I have made, then update the source in the repository.
[quote=“Z-Knight,post:32,topic:28082”]
I’ve made it a bit more abstract and easier to use.
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.
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.
Thank you for your work on this.
-greg rodgers
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.
Would you mind posting an update on here when you’ve updated the repository?
And thank you everyone for the work you’ve done, I look forward to seeing the results.
You might want to use Wavefront OBJ format (it can be exported from almost all 3D modeling tools including 3dsmax and maya). OBJ format is the simplest format to read and write to!
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.
Thanks.
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 fps
I’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.
I have encountered a problem with JOGL rc7 and rc8…I cannot run the net.java.joglutils.test3ds.Main under anything but rc6 because with rc7 and rc8 I get an exception:
Exception in thread "Thread-2" javax.media.opengl.GLException: java.lang.RuntimeException: java.lang.IllegalArgumentException: argument type mismatch
at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
at com.sun.opengl.util.Animator.display(Animator.java:144)
at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: argument type mismatch
at com.sun.opengl.impl.JAWT_DrawingSurfaceInfo.newPlatformInfo(JAWT_DrawingSurfaceInfo.java:86)
at com.sun.opengl.impl.JAWT_DrawingSurfaceInfo.platformInfo(JAWT_DrawingSurfaceInfo.java:52)
at com.sun.opengl.impl.windows.WindowsOnscreenGLDrawable.lockSurface(WindowsOnscreenGLDrawable.java:189)
at com.sun.opengl.impl.windows.WindowsOnscreenGLContext.makeCurrentImpl(WindowsOnscreenGLContext.java:57)
at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.opengl.impl.JAWT_DrawingSurfaceInfo.newPlatformInfo(JAWT_DrawingSurfaceInfo.java:83)
... 14 more
Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Attempt to make the same context current twice on thread Thread[AWT-EventQueue-0,6,main]
...
...
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.
public static void main(String[] args)
{
Frame frame = new Frame();
GLCanvas canvas = new GLCanvas();
Renderer renderer = new Renderer();
MouseHandler inputMouseHandler = new MouseHandler(renderer);
canvas.addMouseListener(inputMouseHandler);
canvas.addMouseMotionListener(inputMouseHandler);
canvas.addGLEventListener(renderer);
[b]// frame.add(canvas);[/b]
frame.add(canvas);
frame.setSize(600, 600);
final Animator animator = new Animator(canvas);
frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
// Run this on another thread than the AWT event queue to
// make sure the call to Animator.stop() completes before
// exiting
new Thread(new Runnable() {
public void run() {
animator.stop();
System.exit(0);
}
}).start();
}
});
frame.setVisible(true);
animator.start();
}
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.