To the author/porter of the milkshape loader for JOGL, can you put up a link for it here? It seems that the old forums ate the code. I’m getting the joy of copying files around machines in order to use it. 
No Problemo.
miklabs.com/wip/nehe31.zip
I have done a Linux test of it and texture doesn’t show.
I need more feedback for my port on Linux…
Im working on a base code for other port and demos. So stay tuned.
I have in my folder a old code to compare speed between J3D and GL4Java, which display Quake3 map. Maybe I will work on that too.
But I don’t have a lot time my Middleware project MEE, take me a lot of time:
- J2ME support for MIDP1 and MIDP2, Nokia, Moto and Siemens API using an interface wrapping.
- J2SE in the same way
- 2D multiscrolling, Isometric, Raycast.
- XML project description
And MM3D a full 3D for J2ME/J2SE thar I completly rewrite to be compatible with JOGL, and JSR184. ;D
Mik
Never understood how one can write a loader for a rendering API without having an engine!?
How does that work?
I don’t understand what you want to say?
But a engine is only some extensions for an API.
To write a 3D loader you need some base classes, like Vector3f, Triangle, Matrix, Joints, ,… to describe infos in the file. This classes are a small engine in fact, specific or not to this loader. 
I guess what Herk is getting at (I was wondering the same thing myself), how you can deal with things like transparency sorting, if you don’t know how the person writing scene tree for engine has dealt with them…
How can you write a generic loader, without a generic “engine/culling method/transparency sorter” in place for you to load the model into?
I mean otherwise, you’re not really providing a loader, more of pointer in the right direction…
Kev
Yes. Of course you can create an object with a render()-method that displays a single object.
But this is not usefull at all.
You need a framework for material sorting, transparency sorting, texture management, object culling, animation trigger, … just to mention basic rendering needs.
Hey!, do you mean like, um… Java 3D has?
Kev
;D
To display a simple cube you don’t need so much stuff ;D
Transparency and culling are not usefull for only drawing a simple model like Milkshape format.
The framework don’t need to be very complex. See my nehe31 port.
Do you use a caterpillar to kill a ant? ;D
I think you missed the point. The framework doesn’t have to complex, but it does need to be common between users…
So, we’d all have to pick up your system and use it across the board…
Not to mention, mostly, when you load of model you want to put it in a world of some sort?
Kev
Ok I see what you want, a common framework. Not a new engine, but something standardized.
Not reinventing the wheel every time is a good thing. It is what I try to do in my current professionnal project MEE, by completly rewriting the 3D engine to be complaint with standard, like JOGL and JSR184 (JavaMobile3D)
If you want I will completly rewrite the nehe31 and the JOGL framework to a more java3D way… like using vecmaths, and other java3D paradigms. In fact I have already done that with my Quake3 map viewer, a cross over between Java3D and GL4Java.
No Problemo
Mik
No, I really don’t want you to anything
But that still wouldn’t solve it, the point Herk was making was that to actually get proper reuse out of your loader you also have to buy into your implementation of the scene tree (as its not part of the platform - JOGL)
I don’t think anyone is saying its complex to write an engine/scenetree to working in JOGL, just that without it being part of the platform, you can’t really write a loader in an generic way.
Kev
Maybe I’m just daft here, but looking at the Nehe code I see no sign of sorting routines. I THINK this is because GL is figuring out the mesh for us. All we do is draw a triangle mesh and GL says “Ok, these triangles are visible, these aren’t bam, done.” Come to think of it, it’s probably because GL doesn’t draw backfaces. Don’t know what would happen with models with multiple meshes tho. In any case, it doesn’t matter. Once you have the meshes loaded, you can perform whatever type of sorting, ordering, HSR, lighting, etc. you want on them. Nothing is tying you to an existing engine.
[quote] I THINK this is because GL is figuring out the mesh for us. All we do is draw a triangle mesh and GL says “Ok, these triangles are visible, these aren’t bam, done.” Come to think of it, it’s probably because GL doesn’t draw backfaces.
[/quote]
Half right - GL will, with proper depth buffer and other settings, remove hidden faces and pixels. It will not however automajically sort transparent polys and other view-dependant effects.
There is a good work-around though - Milkshape allows multiple materials per-mesh, so assuming that the mesh is defined to certain standards/conventions then the transparent and opaque sections could be rendered separatly, thus the app is free to determine its own sorting etc., and call the appropriate rendering methods when appropriate.
Realistically though, this isn’t the difficult bit. The real difficulty is the loading and skelatanal animation routines, which are independant of the rendering order/organisation.
That’s right OpenGL.
For culling:
gl.glCullFace(mode); // where mode could be GL_BACK, GL_FRONT or GL_FRONT_AND_BACK
and etc.
For transparency some methods exists using extensions:
http://developer.nvidia.com/view.asp?IO=Interactive_Order_Transparency
Or as Orangy, by separate opaque and transparent faces
For the skeletal animation, J3D doesn’t do that too…
I think we were getting at group culling as opposed to face culling really.
Yes, you could use extensions, but then you’re loader has to make that assumption.
As to splitting out transparencies into seperate models, well yes, this does it make it easier, but it hardly solves the problem. You still need to sort the transparent faces within that model while integrating them into whatever transparent faces exist in the scene? Or don’t you?
Kev
[quote]I think we were getting at group culling as opposed to face culling really.
[/quote]
Group culling or per-object culling is entirly independant, although it would be nice to build a set of standard geometry intersection routines that could be used everywhere.
[quote]As to splitting out transparencies into seperate models, well yes, this does it make it easier, but it hardly solves the problem. You still need to sort the transparent faces within that model while integrating them into whatever transparent faces exist in the scene? Or don’t you?
[/quote]
Depends 
Most games don’t bother with sorting within a mesh, as a pixel perfect solution involves much work, splitting and rebuilding polys in a view dependant manner - the idea solution involves building a bsp tree every frame with the transparent polys to properly split and sort them. Obviously this is pretty costly so games tends to come up with hacks (certain blending modes are order-independant) or more complex geometry independant methods (google depth peeling for a start, but involves lots of passes and plenty of spare texture memory).
Hey admin
I think this thread should be moved to the JOGL group.
I totally missed in earlier…
Anyone else agree/disagree?
Yes that’s right.