YASS - Yet Another Space Shooter

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
Ronin
Posts: 116
Joined: Wed Mar 03, 2004 6:23 pm
Location: Germany

Post by Ronin »

@Phenix: Yes, we're using a 24 bit z buffer. But a far plane of more than 1.000.000 leads to a black screen. We talked about that issue in another thread some time ago, there you meant that you pushed your far plane that far and that you can watch nearly infinite or something like that. It would be quite interesting, if that is the same on all computers or maybe dependant of the grafics card. Did you test it on other cards?

I know that page, it is really quite interesting, but I would guess, a z buffer is not the right tool to simulate such distances with that scale. I may be wrong, but I would bet on the w buffer. (Although I never used one till now...)
YASS - Yet Another Space Shooter - www.yass-engine.de
Phenix
Posts: 51
Joined: Sat Nov 15, 2003 3:15 pm
Location: Earth
Contact:

Post by Phenix »

I think w-buffer has uniform error everywhere,while zbuffer has greater precision near the camera,much less far from the observer.
So if you want to have a far plane at,for example,100000 kilometers,and you have a 24bit wbuffer,your wbuffer precision would be 100000000/2^24 meters everywhere,something like 6 meters.Of course I am not sure about what I wrote :(
I tried my game on 3 other computer,seems to work well.
Ronin
Posts: 116
Joined: Wed Mar 03, 2004 6:23 pm
Location: Germany

Post by Ronin »

What value are you using for far plane? I remember something about flying from sun to neptune with 1 meter = 1 unit in your app, is that true?

We would need a far plane of about 1.000.000.000 to 5.000.000.000 for simulating just a planet with surrounding moons. For a whole solar system you need MUCH more. Currently we use just 1.000.000 units...
YASS - Yet Another Space Shooter - www.yass-engine.de
Phenix
Posts: 51
Joined: Sat Nov 15, 2003 3:15 pm
Location: Earth
Contact:

Post by Phenix »

I'm using 10000000 as far value.
1 meter=1 unit.
I've tried my game on 4 configurations,one with geforce 4 mx 420,another with geforce mx 440 (quite the same),another with an ATI 9700 mobile,and with integrated Intel Extreme Graphic,it works well.
What graphic card have you got?
I have sent you a PM with a link where to download a work-in-progress version of my game,but if your screen is black if you set a far plane more far than 1000000,it probably won't run.
I tried to disable planes clipping in directX9 renderer but nothing changes:if I set a too near far plane,the planets disappear.
If my game don't run,I've uploaded two screenshots:
www.infinito.it/utenti/phenix84/shot1.jpg
www.infinito.it/utenti/phenix84/shot2.jpg
The first shows Jupiter at a distance of 230000Km,the second shows one of jupiter's moon at 87Km that is correctly drawn in front of Jupiter.
Ronin
Posts: 116
Joined: Wed Mar 03, 2004 6:23 pm
Location: Germany

Post by Ronin »

So you are able to look beyond your far plane? When your far plane is 10.000.000 it is equal to 10.000 km, but your screenshots shows jupiter in a distance of 230.000 km. I would really like to know how you did that...

I tested your app on two different computers, one with geforce ti 4200 and another with radeon 9600xt. On geforce the planets are not "really" visible, just some flickering polygons let you guess where that planet should be. On radeon not even that flickering polygons are noticeable, just plain void. Besides that your game ran very well and I like it a lot! Especially that docking to stations and your "virtual cockpit" is greatly impressive.

How is that database tool involved in your development process? Are you able to create stars and such for your game with it?
YASS - Yet Another Space Shooter - www.yass-engine.de
Phenix
Posts: 51
Joined: Sat Nov 15, 2003 3:15 pm
Location: Earth
Contact:

Post by Phenix »

quite bad,I hoped that it was more compatible.I tried on 3 pc with no problems...
So I guess I was simply lucky,my geforce mx worked too much well,and I took a wrong developing direction.
I'm not sure I've understood exactly your question.
I've got a database of about 8000 stars,that should be in real positions,with correct infos about name,mass,spectra,and costellation (quite useless).
The stars drawn in the game are these from database and should be at real position(no skybox).
The problem is that I've imported the stars database from a free stars viewer program,so maybe there can be copyright problems.
I pseudo randomly generate stars distant from Sol,as you can notice if you move quite much the stars map.
I'm using no tools,just code made by me.
The docking to station is still incomplete,I would like to add some animations.
The cockpit developing took me some time,I needed to code a procedure to draw bitmaps to texture with mipmap levels,and a little proc to find the texture coordinates of a clicked point on the cockpit'polygons.
I made a 3d cockpit instead of 2d because I would like to make possible to wake up and walk in ship,stations and planets,but before that I need to implement collisions,and it is quite a nightmare,specially with procedural planets.
But I can trow everything in trash if I cannot find a solution for the far plane problem.
You said that a far plane of more than 1000000 leads to black screen;
On the release of my game you've downloaded the far plane was at least 3000000,if not 10000000, I'm not sure.The near plane is 1.0.
So why you don't see a black screen?maybe because I don't have skybox?
I really don't know how to fix it,if I cannot disable plane clipping.
I think the problem is that projection matrix have two elements that are not set correctly if zFar and zNear are very different(zfar 10.000.000 times than zNear or more),and this destroys the view frustrum.
If it's really impossible to turn off clipping,I see only one solution:to render planets nearer and smaller so that they can fit the view frustrum,but of course this is the LAST AND LEAST solution.
If you like, I've uploaded a replacement executable for the old release that have a more extreme far plane,because maybe the old version has it at 3.000.000 and it's not extreme enough :)
The link is almost the same as the old version,just instead of /techdemo.zip the file is /Techexe.zip
But don't hope it work :(
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

I am able to set FarValue of my camera as far as 16 000 000 units away and see objects up to 10 000 000 units away (with NearValue default 1).

If I set FarValue more than 16 000 000 (say 17 000 000) I get black screen and nothing is displayed.

If I set NearValue more than default 1, than I can see objects more than 10 000 000 units away and set FarValue more than 16 000 000 but objects are strangely displayed in uncorect sizes (larger) like if cameraFOW was changed.

If I lower NearValue I can set maximum FarWalue even les than 16 000 000 and see objects les than 10 000 000.

Anyway 10 000 000 is quit unsatisfied since if I would make 1 unit = 1 kilometer real than anything closer than 1 unit to my camera would not be displayed. That means I can not see objects closer than 1 km from my ship, which is unnacceptable.
Lowering NearValue will solve nothing since it will also lower farest distance objects are displayed + there is that strange thing with FOW.

If I make 1unit = 1meter real than farest I can see is poor 10 000 km which is nothing in space of course...

BTW: I was also thinking of the same solution as you (with scaling planets and placing them in wiev) but that would leave space for lot of future problems like colision detection and possibly pathfinding.
Ronin
Posts: 116
Joined: Wed Mar 03, 2004 6:23 pm
Location: Germany

Post by Ronin »

Yeah, with your new exe I see those planets! And looking real good...

Probably my max far value is the same than yours, it was some time ago when I tested it and all I remember for sure is that my desired far value of several billions lead to black screen. As arras said 10.000.000 units are 10.000 km which is nothing in space...

So this is a problem with todays hardware, right? Because isn't the z buffer located on the grafics card? So you cannot take a z buffer for granted with more than 24 bit. If that is true, the w buffer would be the only (maybe not perfect looking, but hopefully passable) option to keep that scale of 1 unit = 1 meter.
Btw, are there cards out already with a 32 bit z buffer and what precision could one achieve with them?

Or am I wrong, and the z buffer is "just" a software issue? Then maybe there would be other solutions also...

@phenix: Those stars are no skybox? Thats impressive! But why can I see them, if they are at real position, several lightyears away?
YASS - Yet Another Space Shooter - www.yass-engine.de
Phenix
Posts: 51
Joined: Sat Nov 15, 2003 3:15 pm
Location: Earth
Contact:

Post by Phenix »

Great! I had no solutions to fix it,if it didn't work.
I think a 32bit zbuffer is 256 times more precise than a 24 bit one.
I don't know how much cards support it,all I can say is that mine doesn't.
Maybe it isn't much common because with a 32bit zbuffer there can't be a stencil buffer,usually there are 32 bits for depth+stencil,24 bits for depth and the remaining 8 for stencil.
There is the floating point 32 bit depth buffer too,that is very rare,I think.
And I don't know how much cards support w-buffer.
Anyway the real problem is the far plane/near plane ratio,if zFar is more than about 3000000 times zNear there can be problems.
That's because the projection matrix uses f32,that's a problem of direct3d and openGL standards.
But if you use this flaw wisely you have good hopes to have a far plane at infinite,if you try to set zNear=1 and zFar=10.000.000 and you try to get the camera's view frustrum,you'll notice that the far plane of view is undefined or something like that.
That's a very rusty and not safe way to disable far plane clipping,but I didn't find nothing better.
@arras:what grafic card have you got?so you cannot have an infinite far plane?Would you like to try my game?I'll send you a PM.Yes the solution of planet scaling is quite terrible. :roll:
24 bits zbuffer seems to work well for me,I had problems with atmosphere of earth,that is a transparent mesh a bit bigger than the planet,but I resolved it drawing the atmosphere before the planets,so that it's always drawn behind avery planet.
If I would see some problems of zbuffer with planets,I would draw the planets before other meshes in order from back (the most far) to front,so that a nearer planet is always drawn in front of a more far planet.
With other objects like stations and ships it's not needed,the zbuffer is more than enough with near objects,when they are far they aren't visible.
What kind of graphical errors can you see in your game with too extreme far plane?
I draw stars in my game with draw2dRectangle,and I find stars'position on screen with getScreenCoordinatesFrom3DPosition.
By the way, the .dat files in \stars are plain text,you can open with notepad,there should be the original stars viewer program in that dir too.
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

Phenix >> I have bit outdated Radeon 7000/VE card.

I was trying your game and it is very interesting and quit far developed. It run fine on my computer I just cant get starmap ...pressing "s" doesnt seem to do anything. Also some planets or moons have theyr polygoons blinking in funy maner ...they apear and disapear in short periods ...not whole planets, just polygoons. At the same moment some are displayed, some are off, letting holes in mesh. Next moment some appear while others disapear.
And last thing ...everything seems to be bit too fast ...with turning ship it's quit anoying since I can turn ship 180 degrees in one second. That make control bit dificult.

"If I would see some problems of zbuffer with planets,I would draw the planets before other meshes in order from back (the most far) to front,so that a nearer planet is always drawn in front of a more far planet."
...howe do you want to do that, I tought that order of rendering is handled internaly by Irrlicht scene manager...

In my project I seems to have problem with shading ...I have ambient light lowered to minimum and one point light set to position of star. I can see ugly zig-zag where light side of planet or moon turn to dark side.

There is also problem with source lighting under OpenGL but that apear only on my computer so it may be case of my graphic card.

Another problem is that I don't seems to be able to set custom point light lighting radius large enough. For example I can't get object 500 000 units away from light source get afected by that source ...no matter what walue I set.

There seems to be also problems with object not displayed in right order on screen but that can be problem of scaling ...I have one sphere mesh 1 unit big in radius which I always scale to get star, planet or moon ...looks like its bounding box is not scaled ..I still have to test it.
Phenix
Posts: 51
Joined: Sat Nov 15, 2003 3:15 pm
Location: Earth
Contact:

Post by Phenix »

The starmap should appear in the ship,to see it you must press "o" to use the external camera that can be controlled by mouse and arrows,and turn back.
I've already noticed that problem with polygons,I have problems with huge planets like stars (in your version stars are not working),on there isn't any problem.
Planet's meshes are runtime generated,and the generation procedure is still under development,I hope to fix it.
I've recently changed ship controls and have not tested much,I like them on my pc,but they depends still on the frame rate.
If you buy a more heavy ship it should be a little slower.
I'm happy that you can see more far than the far plane,that's the important thing.
About the planets ordering,you're right,to do that the engine needs to be changed.I've already modified it to draw the atmosphere of earth before other meshes,I have had zbuffer problems with it.
I set the range of my light scene node to 15000000000.0 (that's a lot :shock: ).I set the value of a yellow star light to video::SColorf(200.0f, 200.0f, 40.0f),and I have an acceptable lighting.
About the shading problem,I would check that goraud shading is enabled for the planet's meshes,but it's enabled by default,so maybe the problem is the planet model,check the vertices of the planet.
The lighting is calculated with S3DVertex::normal,in a triangle the normals should be a little different,if the 3 vertices normals are one equal to another,maybe the model need a fix,because you'll have every triangle uniformly lighted.
I think the bounding box doesn't consider scaling,but if you have,for example, a nearer planet displayed behind another more far,it's a zbuffer problem.
Post Reply