BTW: Here's a good posting about the current state of MMORPGs...he has some good points IMHO. Albeit it's quite long, it's worth a read: http://www.gamedev.net/community/forums/topic.asp?topic_id=361091

I've played it for some time today. Here are my thoughts:

- It's quite laggy from time to time. You click to move or attack and the command is executed up to one second later. That's quite annoying but i assume that it's due to my bad pings to the server (ranging from 90 to 700ms). It plays ok when pings are around 100ms, but 200 and above is noticable laggy.

- I got stuck two times. The game was still running, but i couldn't move. One time, it seemed to be related to collision detection. I tried to walk through two tents in the Muton area above the starting point. I failed to pass them but i couldn't go back either. The other time, i somehow screwed up the inventory.  The upper left box was always highlighted when entering the menu and i was able to highlight all others too by clicking into them. But i wasn't able to use the inventory itself and i couldn't move anymore after leaving it.

- Sometimes, my character ran right into a Muton when i was actually trying to attack him...:?

- I think that you should change the background color from black to the same light brown that the fog has.

- You can talk to NPCs and buy things as soon as they come into view. That should be limited to a smaller area around them IMHO.

- At times where the pings were better, i enjoyed playing it. You should make it possible to store the character on the server when leaving and let the NPCs only train you when you've enough experience points. That way, it's possible to concentrate on character development as a starting point to extend the gameplay and explore the world.

- I'm loving the forests. I'm always looking for trees in the sectors and run right to them when i found some. I usually skip sectors without any trees... :wink:

Edit: Maybe changing the sort offset on the shadows of the decorations helps to avoid the flickering between them and the plants. Something like Object3D.setSortOffset(100)...i'm not sure if it's really a good idea but it's worth a try.

Quote from: "Eyleath"
I have a question about the fps demo that we can find on the web site, did you do the 3d? how did you link in your 3d software the texture with the object. Because you just add the folder with the texture but after, jpct knows which texture to take for any object...how..

The textures each have a name in the 3DS file. When loading the file, jPCT is looking for a texture with that name in the TextureManager and assigns this to the polygon in question. If it can't find the name, it creates a new (plain white) one with that name that can be replaced later. When loading the 3DS in jPCT, you should see the textures' names in the log messages.

Quote from: "Melssj5"
I only can Imagine that is due to the 24 bpp instead of the 32bpp.

for example it shows only a color that seems to move when using textures that I took with a diigtal camera.

No, it's for sure not due to that. Sounds more like you are not calling build() or at least recreateTextureCoords() after assigning the texture. Two screen shots for comparision would be helpful.

Quote from: "meinfilter"I supposed there was going to be a performance problem about the distant stars background, but I wonder if it could be mitigated somehow, like drawing them like points instead of using a texture, for example (and perhaps not drawing many many stars). By the way, is there a way to draw points instead of polygons? Would it be faster if there was one? To apply a texture on the sphere would be the wiser approach?

Drawing points would still require a zbuffer read/compare. Maybe the best (or at least a reasonable) solution is to use actual objects placed on a sphere instead of the textured sphere. They can be stars, distant galaxies etc...that way, you are saving fillrate and are getting a higher flexibility. At least until you insist on hundreds of stars in the background, which i think you don't.

Quote from: "Uija"Is there a way to serialize OcTrees?

Octree implements java.io.Serializable, so you should be able to serialize it using Java's standard serialization methods.

Quote from: "Uija"Another thing: My "Map" contains currently 40x40x2 Triangles. when I build a octree with it, I get a stackoverflow. isnt it meant to be used on big objects?

There are situations, where the subdivision of an object fails and the recursion never ends...i can't remember exactly when this happens, but there should be a thread about it IIRC. To prevent this, you may create the octree with a maxDepth (5 or 10 or whatever) by using the corresponding constructor. What's your setting for maxPoly for that tree (shouldn't be lower than 100 IMHO)?

Edit: A little more on this subject: jPCT doesn't split polygons for creating an octree. It just tries to decrease polygon count in a node by subdividing the node if needed. On some objects, this doesn't work, because the polygons already cover the whole node. There is no way to decrease their number by subdividing that node...they will just cover it even more. By limiting the depth, you make jPCT stop at a certain depth.

Try to adjust Config.collideOffset (and, if that fixes the problem, enable Object3D.setCollisionOptimization() afterwards to get some performance back).
Maybe your plane is too large to be covered by the default setting (most likely, especially if you are already 30 units away from it). Whatever you do, try to make sure that everything in your world takes places in almost the scale or you'll run into accuracy problems sooner or later (for example: don't translate your objects by 100 if your polygons are all one unit in size).

I see...your plane is quite huge. ATI's per pixel fog implementation is actually per vertex, which can produce strange results when polygons are quite huge. I've already noticed that but never investigated it further. I suggest to split the plane into smaller ones. The lighter/darker effect you are experiencing has the same source. It's linear interpolated across the polygon. Depending on where the actual vertex of a polygon is located, the result may change.
In a real world application, you shouldn't use planes that large anyway, because it will cause lighting to show similar problems.

Quote from: "Uija"
funny thing is: this only happens on my notebook (ATI) and not on my MainPC (NVidia)

Driver problem? Which card/driver version are you using? Can you provide me with a test case for that?

If it's the same model (or maybe just with different textures), you can load it once and use cloneObject() in Object3D on it to create your additional instances. That will reuse the mesh and animation data. If the current state of the animation is different for all models, it's additionally required to clone the Mesh because otherwise a call to animate() on Object 1 will influence Object 2. So the idea is basically:


Object3D newAnimObj=oldAnimObj.cloneObject();
newAnimObj.setMesh(newAnimObj.getMesh().cloneMesh(true));


In addition, you may set Config.saveMemory=true.
For reference: Paradroidz runs with -Xmx256m and uses around 128m of this . It uses around 3100 Object3Ds which it holds in that memory all the time.
Keyframe animation, however, is expensive in terms of memory usage.

Edit: The current WIP of 1.09 already includes a change suggested by raft that strips some unused information from meshes that are used for animation only. I may add this change to Animation itself somehow. It should help too...

Quote from: "Raven"Actually, I've been wondering about the same thing. I've pondered as far as using char ASCII values and having a texture with characters at corresponding 'cutout' points similar to the jPCT FPS demo's frames-per-second blitting. Seems tedious, however.

Can anyone point out a better, general way of blitting Strings?

It depends on your needs. If the text doesn't change much, you can render it into a texture and use that. If it changes often, you are better off with the method the fps-example is using. That's because creating a new texture every frame may still be possible when using the software renderer, because there is not much overhead involved when creating a new texture (or modifying an existing one via the ITextureEffect interface), but when using the hardware renderer, performance will suffer very much if you are doing that.
Or you can use standard swing/awt to blit directly onto the canvas when using the software- or the AWTGLRenderer.

Quote from: "meinfilter"
About drawing distant stars: they are just for decoration; the camera can move around, but I would set a limited volume in which it can do it, so these distant stars would remain always distant.

Then a skybox or -sphere should be sufficient. But that eats up your fill rate for the software renderer. Are you planning to use soft- or hardware rendering?

Quote from: "meinfilter"
Something like using the Java API to draw the characters on an image and then applying the image as a texture on the billboarded quad would be the right approach?

I guess that you'll generate them once and use them from there on? Then you are fine to draw an image using standard Java2d stuff and upload that as a texture. If the text changes a lot, you should compose your texts from various texture parts instead (see below).

Have a look here: http://www.3dcenter.de/downloads/treiber-geforce-w2k.php
It's a german site but driver numbers should be international... :wink:

Quote from: "meinfilter"
- Drawing distant stars as points (maybe on some huge sphere that contains the whole scene) that must rotate as the scene does.

Possible IMO, but the way i'm thinking of requires some work to do it. Are these stars actually reachable or just for decoration?

Quote from: "meinfilter"
- Drawing each planet's name under it (so I need a way to draw characters that are always looking at the camera, whatever its position).

Possible . You could use a billboarded quad (will grow/shrink depending on the distance, text may be hard to read if too small) or blitted text (will always have the same size, always be readable but doesn't take overlapping into account). It depends on your needs which way is better.

Hope this helps.