Well, "needed" is a bit too much because it's not something i'm making money with. Not even something that will evolve into a real game. It's just a fun project that i'm working on from time to time to learn things about 3d. The idea is this: There are birds hidden in a tree (with around 1000-2000 leafs) and you have to hit them using a fireball  
I started this little project using the mentioned jpct engine and i wanted the leafs to burn down when hit by the fireball. In the earlier version of the engine, i had to create an object for every leaf too. Just like i would have to in xith . That's because the engine was able to detect the collision itself but it couldn't tell me which leafs were affected when i stored them all in one big object. That was quite slow. According to my profiling, most of the time was spent in the collision detection between my fireball and all the leafs. A newer version introduced the possibility to get the list of affected polygons (i.e. the leafs) from a collision. With this, i can easily maintain my own list of burning leafs, let them burn some time by changing the texture to an animated fire and finally i change the texture to a "burned leaf" one. (You can spot the birds better through the burned leafs   )
That's what i'm doing and that's what i'm using this feature for. I don't really need xith to implement it, because i don't plan to use xith ATM. I was just wondering why something so obviously needed (to me at least) isn't possible with this engine.
And finally, albeit i'm not writing one, i think it's very usefull for texturing work in an editor. But i already mentioned that.

Sorry, but i really don't get what you are trying to tell me here. That changing the texture state requires 300 lines of code?  For sure not.

I'm calling a shape whatever xith is calling a shape and i couldn't care less about what the programmer of the API is doing with this shape/model/whatever internally. I'm just interested in a feature that makes sense to me (and not just me). Maybe it's hard to implement and doesn't fit nicely into the current code but should i really care about this as the "user" of the API?  Back to my example: If your loader loads a level with a single texture, it would make it either one shape containing all the polys or it would make one shape for every poly because i somehow told it to do so. The later solution is totally out of question for me. That's far away from the optimized state you are talking about.  The former solution explodes when i'm trying to change a texture of a single polygon. I would have to reorganize the whole shape and split it into two seperate ones and so on and so on.
So i think you are basically telling me, that i can use xith for writing a game where almost everything is static (texture wise) but not for writing the tools for creating it!?
In my opinion, an engine's task is to abstract from the underlying rendering layer and its requirements. If it forces me to build wierd workarounds to get what i want (if its reasonable, which it is in this case), it has failed in this part IMHO.

Ok, i now understand the reason for Shape3d to behave the way it does for compatibility reasons with Java3d. However, a  class that allows different textures for polygons would be a very valuable addition IMO.
JPCT (http://www.jpct.net/forum/viewtopic.php?t=88) is something i'm using from time to time and that offers support for both ways. By default, you assign textures for the whole object but the 3ds loader can handle multiple textures/object and the API lets you obtain a PolygonManager from each object which offers this option too. That's very convenient for coloring picked polygons for example. You just need about two lines of code to highlicht the polygon under the mouse pointer by simply changing its texture.

@abies: I don't think that it's a very good argument to say that something is against definition and therefor not possible for a reason. Maybe not the feature but the definition is questionable in that case?!
Anyway, i agree that there are workarounds. As you mentioned, i could write my own loader to split my level into separate shapes and i can also use different geometry and spatial subdivision for my collision detection than i do for the rendering. But i don't think that that's the point when using a 3d engine like xith. It should offer such things and not force myself to reinvent the wheel here.
Another example: Imagine a 3d editor, where the user can load textures and assign them to every polygon he wants (i.e. he's texturing an untextured level). If i understand the current definition correctly, this is almost impossible with xith, because it would require every polygon to be a single shape (or to split and create shapes everytime he changes a texture, which sounds even worse). For a level with 20000 polygons (which is not much), this would require up to 20000 shapes. Am i right?
I'm sorry, but if i am (even to a degree), i don't think that the current approach is a very good one. Other engines i know are doing it differently and IMHO better. I think that this is something that should be rethought.

That's not exactly what i was talking about. Storing all the level geometry in one shape doesn't mean that you can't use spatial subdivision on it. It's even easier IMO. If you split your level into a lot of texture separated objects, you either have to store the corresponding object of each polygon in your octree (for example) or (even worse) calculate an octree for each one.
Allowing just one texture per shape really is a bad decision IMHO. Imagine a Doom3 level that would have been build that way. How many shapes would that require? Gazillions? And what for? Just to minimize texture state changes?

True to a certain degree for models but for sure not for the level geometry. And to split an indoor level or even a terrain into a bunch of shapes by their textures is a really bad approach imho, because it makes a lot of tasks (like collision detection and response) unnecessarily difficult. Why won't xith let the programmer decide how many textures a shape should use!?

Thank you for insulting me this way. I'll answer the rest of your post when hell freezes over.

So going bankrupt with 1.4 (because the Average Joe won't install it) is a smarter decision than using 1.1 and making money with it? That would explain the state Java gaming is in at least.

Well, i really don't understand your problem then.  You know the dimensions of your grid, so you simply have to move the camera by that amount and rotate it 90 degrees for turning. There must be something in your post, that simply don't get... Anyway, you got it working already.  

A 3d engine without a built in camera class that does basic things like moving and turning? You are kidding, aren't you? Or is there a good reason for it?

Downloading a jar and doubleclicking on it or even unzipping a zip isn't that difficult either. Why do some people go crazy about webstart lately? I like it too, but i still prefer to download the stuff and store it where i want it to store.

That's much too simple. It's like saying that South Park can't compete with Sinbad or that your girlfriend can't compete with Miss World.

There's a similar thread on java.sun.com.
I doubt that it adds much new to this discussion, but anyway. Maybe it's worth a look though.

http://forum.java.sun.com/thread.jsp?forum=21&thread=437870&tstart=0&trange=15

Well, no offense but 70fps for 160 textured quads is not damn fast, it's rather damn slow. Maybe you try it with VSync disabled. 70 and 35fps sound very much like a VSync limit to me.

IF it is this file with 3.7MB that i've found after reading your post (was really easy... )..THEN it doesn't work on a Radeon9700 using the newest driver (3.2 i believe) under Win XP. It tells me to get a new graphics card (and i hate it for that). It does run on a GF3 under XP. IF this is not the version you are teasing us with...then ignore this post....

For some people around here, threads seem to be the Saddam Hussein of programming. Stop this discussion and save your time...it's fruitless here on threadhaters.org.

Tried it on an Athlon XP 1600 running WindowsXP and using a Kyro-I based graphics card. It worked and looked fine. Around 90fps. Overclocking the card helped to increase performance, so my guess is thatit's fillrate limited on that card (what can you expect from a card clocked at 115 Mhz though?).

Yes, that's what i'm talking about. LWJGL is no such thing. And scenegraph-oriented APIs like Java3d are not very well suited to make games with them IMO. It may be possible, but what i was talking about was a kind of Quake2/3-engine on top of something like LWJGL (i really hate this name btw... )
In "native world" there are Quake level viewers like there's no tomorrow and for Java...?...nada! I don't have the experience (3d wise) to write one but i would like to see such thing in Java. That's why i asked!

Doesn't that mean that you would reinvent the wheel (i.e. Java3D)?? I'm looking for a 3d engine optimized for games, not a scenegraph API.  I mean the native world has Unreal 2 and Doom III-type graphics and Java has..what???

As nice as it looks, it technically dated. It's a raycaster. As i mentioned in another thread, i would like to see something like the quake (even quake1 would be fine) engine to be implemented in Java.
The closest thing i could find was this:
http://www.jpct.net/download/jpctdemo.zip

...but that's not using hardware acceleration.

Are there any others? Javaisdoomed seems to look nice but there's nothing to download.
I mean there must be something at least on the same level as the quake engine. What comes closest to it was this jPCT-demo-application and IMHO it's kinda sad (as impressive as it is) that with Java3D and GL4Java out there, nothing like that should be possible that makes use of hardware acceleration...??