Concerning joglutils, I was now able to import one of my .3ds models into JOGL. But some issues are left:
I had to use MyModel instead of Model3DS, which is only part of the test system, not the “official” class, right? But otherwise the render() method lacks, without which it is not possible to display the model? Also I could not find any use for Loader3DS…
All I actually see is the dark grey outline of my model, without any color or light or whatsoever. I guess this has to do with the Material, but the docs dont really say how to use it.
Apart from that: Good start, keep up the good work! Maybe some comments for the docs would be great, in the long term…
Model3DS was not really intended to be instantiated. If you do instantiate it, it will only load the 3DS model and not draw it. The intention was to keep the actual rendering separate from the loading. In the example, MyModel is used to demonstrate how to extend Model3DS for JOGL rendering. It is up to the programmer to add all the bells and whistles.
Loader3DS does the actual reading and loading of the 3DS file. Without it nothing works. But, you don’t have to worry yourself with it because it is called/used in Model3DS which you should be extending.
Look at the MyModel class in the example and see how the JOGL code is rendering the model. You can easily add the color in there. It’s only a simple example of how to use it. There is no way to anticipate what everyone wants/needs when they render thier model.
Maybe I got something terribly wrong here, but with Model3DS and Loader3DS, the rendering is already separated from the loading. So why not insert the drawing into Model3DS? ???
Isnt that one of the most basic functions of such a class, to draw it onto the screen? Without that, all the remaining functionality is quite useless, isnt it?
Thanks, I found it. But again, I wonder why it is not possible to anticipate what people want to do with their model. I would deem it quite mainstream to load all the info (materials, textures, attributes) into the model class and render it as it is described in the .3ds file (I have to admit, though, that I do not know which kind of information is stored in the .3ds file and which is missing). If someone really wants to change something about it, it seems quite natural to me to change the model (the .3ds file) instead of writing new import code. Still it would be possible to extend Model3DS and overwrite the methods if necessary.
I would really like to write everything by my own, but I am really quite a newbie to JOGL and 3D models. Otherwise I would not discuss but code instead.
BTW, is it in general possible to store animations in 3DS files? Otherwise I will have to look for other solutions anyway…
It was written that way because someone suggested it be more adaptable, (i.e. do not tie it down to only one renderer). I guess it would make more sense if Model3DS was strictly abstract with a concrete JOGL implementation.
Yes, 3ds does support key frames, but the joglutils loader does not yet support loading the key frames. Animation is not trivial, there needs to be a better framework (Mesh to create objects that store the polygon data as well as key frames) established before animation is supported. If someone wants to start up an object framework, I would be glad to help.