Having recently discovered jME, I think it is great - but I am banging my head against a wall in frustration.
Why? Well, whilst the game engine is superb, there’s no middleware.
What do I mean? As an example, for my application I’m going to need a profiler, network client/ server, an octal-tree based LOD manager to create dynamic scene graphs , game scripting language, etc. All of these items sit in the middle between the engine and the game - hence the term middleware.
Now I know I’m not the first person to need these, and I bet there are loads of people in the same position. Whilst I am quite capable of implementing them for jME, I’d rather be working on the app itself rather than spending the next 6 months on the middleware. I’m guessing there are others who feel the same.
Assuming this is the case, can I suggest adding a new forum & CVS section where people can share their middleware for the benefit of all? (Maybe start a poll to see whether others agree?)
Matt
[donning heat resistant clothing and getting prepared to be flamed !]
I also have the AISystem (which I renamed GameSystem because its not really an AISystem). And I also have the physics system based on ODE.
So those are done.
Also, for the scripting, Groovy and BeanShell can be integrated into the GameSystem pretty well.
DP
Some of the things you mention are slated for future releases of jME (Octal trees for example,) and others we have decided are too game specific to really concern jME (networking, to name one).
I like your idea of a code share section. There’s been a relatively good deal of that, informally spread throughout the various forum topics. Having one forum section devoted to it might be a good idea.
PS: You rarely find flamers here. 
knock on wood
jME supports outdoor levels with the classes from the terrain package. Currently, there is no adequate functionality for indoor levels. As I understand, BSP trees, octrees, portals are technologies to reduce the amount of faces to be drawn indoors, but there is even more to this than that like indoor terrain following etc.
Some other (commercial) game engines contain code to support this, think of the q3 engine, the ut engine or the new hl2 source engine. They offer customization in the form of modding the engine. I don’t know whether it would be a good idea to follow this in jme, as it binds jme to a specific technology (by eg. supporting q3 maps, which is done in several other open source game engines).
On the other hand, for ppl who need to create indoor levels it would be a major ease if they find the functionality to do so and simply paint their maps with an existing map editor. It prevents them from reinventing the wheel each on their own.
What do you think?
I personally feel that having some way to render indoor levels and allowing mods is better then having no indoor levels and rewiring mods. I also think that we should fined a way to encode map data into the .jme file. This way we just have to write converters to that map file formats we want to support. If a user wants to use a existing map editor then they could convert the file to .jme.
Some words from a 2d/3d artist.
Id software BSP (the format is free, Id’s tools aren’t for comercial projects) has some serious limits .Mainly geometry which only can be convex. But some other limits also.
I wouldn’t put too much effort on that one, as I say is too old and limited.
I’d rather prefer a way to make portals for indoors, but tied to BSP format and restrictions.
main advantage I see in those editors (the only usables free for comercial are Quark ( planetquake.com/quark ) and getic3d (which includes editor and bsp(maybe a non standard bsp. I think source code is available, not usre if gpl, bsd or gnu ) compiler )) is that all is easier for zero 3d knowledge people, Quark has even a tool to “build stairs” , but mainly, that it generates lightmaps from the lights setting and position that u build in the editor. The actual lightmap (is a greys 24bit bitmap with lighting and shadows info) is generated really in the BSP file, that is, in the BSP compiler, which is apart from the editor (except the Getic3d) , and sadly, no way to compile a quake3 bsp for comercial projects. Is sad not to have the freedom of make a comercial tiny project from time to time , my tools are all this way as I don’t like the restriction.
Half life bsps are worse fro curved surfaces, i think I have read. yet though, there’s a free Halflife 1 bsp compiler, the ZHLT tools , which is quite good, and can perfectly be combined with the free editor (works for any game) , Quark,just configure the paths to use that compiler.
Another possible thing is…forget the lightmaps generation, and just parse a map file before it goes to the bsp compiler. A queak3 one surely is more powerful. That is, a *.map. So u could convert that to jME map format.
But imho, the best, and more powerful and unlimited way, would be using Blender or a similar 3d full blown modeller (is just that Blender is BSD open source, there’s loads of extremely good doc available online, a very good manual free, etc.) as in Blender, u have access to all in python (can do in c++, too) , and can lots of advanced stuff. Could for example build boxes with an special name so that the engine recognize them as portals, other as collision boxes, etc.
There’s your full blown editor, already done and bsd open sourced.
U could even build ur own blender (it’s done so often, indeed…the builds)
Only thing, is it does not generate the lightmaps. there I’d recomend the modified version of fsrad, a tool to generate radiosity lightmaps for free.
Third possibility is…one of my favourites. give support to x format (I also asked for it for bones and weights characters, u see it can serve for both maps and characters 
) specially the 2 uv channels support, so to be able to import an x file which has a typical texture in channel 1, and the lightmap tga (generated wherever) asigned to its uv channel 2.
This open the door to practically any package, as all have a free x export plugin, some is a cheap one.
Max, Maya, LW, etc, have free ones.
Still, no portals, collisions, or automatically generated lightmaps (an all packed in a bsp) are not ported in an x.
But also, not possible to do greater than 65.000 triangles terrains with x files. Is a format limit, like md3 is 8.192, or 3ds is also 65.000
For huge tris numbers, only that I know, is OBJ, probably ASE.
Among those, OBJ is wildly supported every where. ASE, that I know, only in Max, Blender recently -and not sure till what extent- , and Ultimate Unwrap, even supporting the 2 uv channels, so could be a great format for lightmaps.
The key is imho, to any engine, have more standard formats import, and then convert to internal optimized and engine friendly format.
So, bsp can look like the best option, but, problems to find a totally free compiler, very limited geometry stuff, lightmaps are never radiosity ones (fsrad does much better lightmaps) , editors, while easy for the noobs, are very limited in modelling features compared even to very basic freeby modellers… Metasequoia, for example.
Perhaps the most powerful way is go via Blender direct export, making a python plugin, but I’m afraid there’s not much interest here on making blender support…
Metasequoia output, mqo, is ascii…it’s a much easier package to handle, and an excellent modeller.
Gmax. It’s probably the best of this all for what is making level (snap functions, etc) but while it’s free (and if not hacked/cracked, contraire to what people think, is free for comercial use of what u make with it) , it needs online registration, every time u install it!
That’s why I don’t usually recommend it.
I’v seen recently gmax users say they love Blender, reason why, Blender may deserve some deeper glances…I know, as I have learnt to use it, and was one those to say ugly things of its UI
You can customize every bit of it, as an user, but also in the python script u make to export to ur engine, it’s already been done.
Hmmm…perhaps, after all what I’m proposing is 3 simultaneous ways(I mean, you can implement the 3, 2 or one…(or none, of course )) :
-
- Halflife BSP support. Directly. Sorry, not a parser. Now that we do things, let’s do it complete (yep, now changed my mind) So, free for comercial-easy-to-make levels, together packed collisions, portals visibility, and lightmaps, all at easy handling for 3d newbies. (this or some coder have a glance at Getic and see what can be done with that custom made maybe non standard BSP format he made)
- Halflife BSP support. Directly. Sorry, not a parser. Now that we do things, let’s do it complete
-
- Blender direct plug, and say to the user the names or setting to the boxes so that those, build around geometries, are detected by engine as: collisions, portals, etc. This options will mean no lightmaps. So it’d need Trancos’s fsRad modified version to generate them, and some jme coder would have to make a loader for trancos format or something.
- Blender direct plug, and say to the user the names or setting to the boxes so that those, build around geometries, are detected by engine as: collisions, portals, etc. This options will mean no lightmaps. So it’d need Trancos’s fsRad modified version to generate them, and some jme coder would have to make a loader for trancos format or something.
-
- load of x files with 2 uv channels. It yet would need some other modeller or a jme editor, to be used as a scene editor where you could import the x file, add the special boxes there (collision, portals, etc) and from that editor/modeller, export to jme.Many highend packages, free tools like -soon- deled editor, can export x files with lightmaps asigned in the second uv channel. So the engine just import the x file, the tga texture, and the tga lightmap. Both linked in its path inside the ascii x file.
This open the door to very pro tools.(like in character animations, x opens the door to many high end packages at a time)
Just BSP would be way too limited, while also easier and complete solution in one. I’d say at least BSP and one of the 2 others(complex geometry, more complex lightmaps)…
Does it have sense ?
- load of x files with 2 uv channels. It yet would need some other modeller or a jme editor, to be used as a scene editor where you could import the x file, add the special boxes there (collision, portals, etc) and from that editor/modeller, export to jme.Many highend packages, free tools like -soon- deled editor, can export x files with lightmaps asigned in the second uv channel. So the engine just import the x file, the tga texture, and the tga lightmap. Both linked in its path inside the ascii x file.
Sounds to me like a decision between complex and capable on the one hand and easy but simple on the other hand.
From a personal point of view, I am currently standing in front of the decision whether to invent my own indoor map format and -handler or search for something existing - and port it to jME, as jME itself currently does not have such a feature. I would judge Q3 currently, simply for the one reason that there are some open source implementations out there and it would be enough for my personal requirements. I can benefit from existing editors, but I will lose several weeks/months doing the port.
If I invent something on my own, I don’t have editors for it from the beginning, it will only be limited to my current requirements and it will probably be missing some nice features - but I could do it much quicker. So, if anybody out there is already doing such a thing, get in touch with us!
I personally feel that you should fined a way to put the map files in the .jme format.
bsp is such an old thing…
“If I invent something on my own, I don’t have editors for it from the beginning, it”
Why not? I mean, you can do your own format. And then program in Python(is very easy) an script to export the levels from blender to your format.
It’s been done.
Blender is way more powerful than those ready-made bsp editors, and not limited. Of course, is not as easy.
what is more, a python script blender—>jme. Cool, powerful way
BTW, there are already two scene editors, aren’t there?
what they have in advanatge sure is better adequacy of things like particles, collisions, and portals or other engine specific…but i suspect u can just make boxes or other meshes with special names, be read by th eengine as those special things, so the engine will now in that place there’s a collision of that size , a vis portal of that size, etc. I have seen done it with Max in a comercial environment (game job, via c++ plugin direct to the engine, with the sdk, surely pretty near to what python does with blender. )
What u’ll have then would be a fantastic mesh/level modeller, practically unlimited, and surely possibility to add all the pawns and game specific stuff. And totatlly free (bsd license)
There’s snap to grid, reference image loading, extrude face, edge, point to point modelling…True that is easier to push a button that says “stairs” (Quark, for example) but…it’s about you want to stick to premade prefabs, very simple in geometry or not.
Besides, you can already perfectly import OBJ files into blender, and export OBJs. Indeed, the idea would be good as surely more and more stuff of blender would become available, and that idea of special names/properties of boxes to add the game engine stuff. because through obj,essential geometry can already be ported. (through x, md5 or cal3d, skeletal animation)
as game scripting language you could use BeanShell,
for client server networking you could use JMS or JXTA
JMS for client/server communication for games ? I hope you are joking. You can as well send game packets by mail. If you don't want to use RMI-like method and want to do your own packet encoding/handling, then it is a lot better to stick to plain TCP/IP. JMS is not designed to be even near real time.
I believe Cep is working on Portals. Unless I’m mistaken.
BSP trees are going in before portals. Portals will be based off them. Trying to keep it like Elberly’s design. If anyone wants to work on BSP with me, just send me a PM.
When do you think BSPs will be ready?