Imperio - Galaxy-wide strategy

[meinfilter]

Hi,

I'm evaluating jPCT to decide if I will use it in my project: a strategy multiplayer game called "Imperio", which shows portions of a galaxy as planets connected by worm-holes (slim cylinders).

I have been using IDX3D to show those planets and cylinders, and move and rotate the camera around in every direction. But I have realized that it lacks some features I need, and I wondered if jPCT has them.

The features I'm interested in:
- Drawing distant stars as points (maybe on some huge sphere that contains the whole scene) that must rotate as the scene does.
- 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).

Any quick guidance to know if it would be not too difficult to achieve these? I'm a newbie in 3D, and might spend a lot of time trying something wrong...

Thanks in advance.

[EgonOlsen]

- 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?

- 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.

[meinfilter]

First of all, thank you very much for such a quick reply and for your help.

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.

About drawing planets' names: the grow/shrink behaviour would be OK, as it doesn't matter if distant planets' names are not readable. Would be difficult to draw characters on that billboarded quad? 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?

[Raven]

Would be difficult to draw characters on that billboarded quad? 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?

Hi meinfilter.

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?

[EgonOlsen]

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?

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).

[EgonOlsen]

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.

[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?

I'm planning to use mainly software rendering, because the 3D scene is showed in an applet, and I don't want to rely on the users to have the hardware library installed (that's the reason I discarded Java3D on the first stage). 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?

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).

OK, once generated, the planets' name won't change, so I think I would generate an image with the characters and then use it as a texture.

Thank you indeed, EgonOlsen and Raven.

[EgonOlsen]

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.

[meinfilter]

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.

Very well, thank you again for your help. With it, now I see things less dark ;)

Right now I'm busy with other pressing tasks of my project. When I resume the 3D displaying task and have something to be shown, I will post here again to show you. It may be more than a month from now, but I'll be back :)

[raft]

hello meinfilter,

you can almost forget about texture based strings, they arent readable. have a look at the screenshots at karga thread

for skybox, instead of using a huge sphere i store a small sphere in a seperate world where the camera is always located at origin. than i simply render both of my worlds (the skybox one and the regular one) to same frame buffer one after another

Code Select Expand

r a f t

[rolz]

Raft, What i NICE IDEA !!!!!!!!!!!!!!!!

[meinfilter]

you can almost forget about texture based strings, they arent readable. have a look at the screenshots at karga thread

for skybox, instead of using a huge sphere i store a small sphere in a seperate world where the camera is always located at origin. than i simply render both of my worlds (the skybox one and the regular one) to same frame buffer one after another

OK, I've seen those screenshots. The second balloons you use, the blitted ones, do they hide behind objects? How did you do it if they do? I can't figure how to do it if they are not 3D objects in the scene.

About the skybox, thanks for the idea, I will try it.

PD: I'm still working in other tasks and haven't yet resumed 3D graphics work.

[raft]

Raft, What i NICE IDEA !!!!!!!!!!!!!!!!

:lol:  

The second balloons you use, the blitted ones, do they hide behind objects? How did you do it if they do? I can't figure how to do it if they are not 3D objects in the scene.

i simply decide to blit or not, by checking object's visibility and casting rays and see if they reach target.  blitting always done after rendering, so they never hide behind any objects. to interfere with rendering, i once thought of a object or polygonRendered method to add to paintListener interface but Egon said it wont do the trick since rendering is done from front to back for optimization purposes (Egon please correct me if i remember it wrong)

not a perfect solution but handles most cases. if you find a better one i would like to hear..

Code Select Expand

r a f t

[EgonOlsen]

i once thought of a object or polygonRendered method to add to paintListener interface but Egon said it wont do the trick since rendering is done from front to back for optimization purposes (Egon please correct me if i remember it wrong)

No, you are remembering that correctly. That's one reason why it doesn't work, but there are others too. The one and correct way to do it, would be to write into the zBuffer when  doing 2d blitting in these cases but that's not a good idea for other reasons.

[meinfilter]

Sorry I didn't post before.

At last, I have finished my project. Finally I haven't used jPCT as the API for 3D graphics, primarily because of lack of time. I sticked with IDX3D, and concentrated in other non-3D aspects of the project. In fact, I believe jPCT would have been a better choice than IDX3D, and I would recommend it.

To solve the problem of displaying the names of the planets, I tried the brute force solution, and it worked fine with little impact on performance. I make a postprocess: check every pixel of every rendered 2D frame, looking for 3D objects. I do this thanks to a function that IDX3D offers: scene.identifyObjectAt(x,y). When every pixel has been checked, I blit the name of every planet that has a minimum number of pixels displayed.

I don't know if this is such a horrible solution as I thought at first, but it works fine for my application.

Thanks for the tips you provided, it was significant to help me with the project.

Here is an image of the result:
[img=http://img71.imageshack.us/img71/2421/vtacticaphpconnombres5ws.th.png]

Edit: I forgot to say that finally I didn't draw distant stars. It wasn't a compulsory requirement, and I thought that leaving the background black would improve readability.