PROJECT PROPOSAL: jme-contrib

And DP, how would you organize things. Maybe for Xith it’s better to change. That’d be interesting to have your advice.

That cat never stops firing…lol. :wink:

DP, I think kman has done very valuable work.

We (one of the guys posting here, (but I’ll keep the identity ;)) and me) ,are strongly in the middle of a comercial (small but realy cool :wink: ) game, and certain part of his work is essential for us.

Allow me to say one of the hugest problems I as an artist (3d, 2d, all) have allways found with open source engines is the status of the art pipelines(point me to one I can say is complete). This is not a single very old guy’s(me) opinion, is something I keep hearing in the many comunities of this kind I am solidly connected to(not allways as “Snaga”).

Even so, I have found way many engines with less and worse formats support than jme. The loaders like OBJ are solid and well done, better than in other places. But when you do a game, even a basic one, you really need more. Scene formats,(but of the kind that have a plugin from available 3d softwares! ) and bones and weights formats.

In scenery, you need to port reflection maps, vertex colors, lightmaps(not only smoothing, uvmaps, base textures). And do it solidly(main needed features), and double checked at least to work in a real example with one(or 2) main popular freeware/open source tool, and one popular comercial tool. Imho.

Well, till the arrival of Kman’s md5 (i know, there was a very nice one from chaos , but project stopped long ago) I had no other option than stick with md3. This meant: our downloadable game would grow into tons of megs as I will be doing many animations(and hi res meshes would be also a big cost in performance). The UV island borders in md3 cause smoothing normals creases in unwanted areas->solution is only uvmap in a very restricted way. Litlle good support of md3 format by softwares, and the exporters often output a not very accurate result, sadly. It uses a sort of interpolation(between keyframes) not as good as desired…and the solution of exporting a key mesh per frame, is even worse for download size. Md3 is a very good format…at the times it was created :wink:

Well, he went and made an md5 plugin. Now the size per animation (as md5 does not include whole mesh info with every animation, like other bone and weights formats do, and md3 (vertex anim format) even worse, as adds whole mesh every keyframe! ) has gone to some ridiculous kbs of memory per animation-action! This is an absolute success for downloadable games which also are into animation smoothness and overall quality = md5 format.

Not to mention md5 has a load of features (which we don’t need for our project. I don’t need normal maps, nor camera or lights porting,probably would be handy the animation blending(betweendifferent animations, ie walk->run.I can do it by hand, just cuts a lot of work) but not essential. I only needed a lightweighted md5 loader, that took well the interpolation, bones and weights, smoothing normals, base texture with its uvmap. Achieved in his very first version…)

heck, you don’t know how much important for an artist to use an engine is to have simply a way to get his stuff in the engine! if jme-contrib would speed up the fast additions of this contribution code,(full priority with md5, scene can be dealed for us wel fo rnow, but next anyone could add could be collada ;)) am all for it! We’re dedicating our time to this game project in a very strong manner, so I’d really like to see art pipelines a bit better. OBj is really nice; collada(dunno if x3d, should study these formats a bit more(in the matter of test well the exports of latest plugins (blender collada’s uncomplete, for example))) would be better, but we’ve managed however to deal well with the stuff with obj for now. We’re now a bit stuck as we need to know how much performance load will add the md5 character in whole thing, to determine final polygon count, textures, etc. As we’re targeting really low machines(a kind of very safe way).

About other comunities “contrib versions” …yup…seen many others do so. I know of, indeed, several others. Wont mention here, though. (or I’ll see a cat firing there too :wink: (…BTW, to keep it clear, I always liked the avatar :wink: ) But in fact, both of the contribs of that non java based engine -IMHO- are more advanced, and one of them has many of the bugs fixed(seems also the guys have plenty more free time :wink: ). Still, most people prefer to go with the standard. the majority even. But when one wants larger scene meshes, or certain formats, or certain effects goes with the other. the 3 coexist well…though one actually has no activity now, the other is really strong and used by many advanced users. is indeed allowing to generate amazing projects.

So, I think is a great thing. I know my main point, a bit about art pipelines, is a bit OT, but as you seen, in the end all is connected. And trust me, is key for any engine actually output games.

JME has the attractive(among many others: solid, being java and open source, capabilities, design (coders say), incredible performance in low machines (we’re realizing it ), comunity, etc, etc, etc ) point it has a bunch of formats, and overall things are quite solid(way more than seen in other engines). Just that there are certain features that are a royal need to put working game artwork into the engine. The nature of the thing is…you don’t know this well till an artist starts to work seriously with a coder to get real case 3d artwork, of certain complexity, into the engine, but for making a game, not an fx example demo :wink:

pd: oh, btw, we’re two “pros” which work (and worked) at game companies. About the professionalism matter :wink:

I don’t wanna enter into the debate of modules vs separate repos but I definitely need Cal3D import support for Xith3D (I finally decided to bring it to the upper level). So I need theKman’s code.