deathshadow
03-02-2007, 09:40 PM
Wasn't sure whether to put this in mathematics or graphics, since I think it draws heavily from both... should be an interesting 'first post'
For some time (hell, approaching a decade now) I've been playing with implementing a 3d engine that displays all 360 degrees around the user in a single 'strip' at the top of the screen... As described in the older Battletech fiction to create a "MechWarrior" style game (that perhaps actually has something to do with the parent product instead of just ripping off a few names and unit appearances). In the battletech universe it's one of the 'big features' of the BattleMech (and the helments of certain elite foot soldiers) that has been strangely missing from every attempt at a computer game of it.
Of course, the reason for it to be missing is simple - no 'popular' 3d perspective math is set up to do this well, if at all. You cannot tell OpenGL or DirectX to have a FoV of more than 90 degrees without horrible fish-eye effects... sure you can try splitting it into multiple views, but even with 16 of them across the top of the screen you STILL get wierd 'points' dropping down from the fish-eye effect, and if you compensate for the fish-eye the edges of the polys don't line up... much less how agonizingly slow it can get when you are rendering the same thing 17 times per FRAME.
So my question is, how would you guys implement this? I've asked in the past and the answer I've gotten most often is the 'multiple windows' that got rejected for the reasons above.
I was able to write a working demo in Delphi six years ago using glide that showed the concept in action, and I ported it to OpenGL and FPC a few years back... The .exe and needed files of that port are here:
http://battletech.hopto.org/circle/
I'm still looking for my old source... I'll post it when I find it
...but at the time I deemed it to be too slow to be practical on the hardware (of that era) for anything more than a very small map and one unit, with no textures and little more than simple (non shadow) shading. Now that the hardware has jumped forward I'm wondering if it might be practical for me to revisit again.
The technique I'm currently using is to use ATAN2 (actually, a workalike I wrote which is WAY faster but only works with 32 bit dwords and has 'screen' granularity) to convert the x and z coordinates of a point to a 'heading', which becomes my screen X coordinate - then I use pythag's theorem to get the distance on that axis, then use that distance and the y to get a 'pitch' value, which I project as screen y. One more sqrt(A^2+B^2) gets me the actual distance for z-buffering... I then project this one triangle at a time in orthogonal view in openGL (much as I did in glide). You have issues that have to be checked for like at the edges of the screen needing to render any triangles that have pixels on opposite sides of the screen are 'handled' down to be rendered twice on each side (+360 for the first, -360 for the second) but nothing insurmountable... just more if statements to slow things down :(
Basically the math boils down to:
ra_2_screen:=pi/(screen_width/2);
dxa:=sqrt(x*x+z*z);
screen_x:=atan2(x,z)*ra_2_screen;
screen_y:=atan2(y,dxa)*ra_2_screen;
distance:=sqrt(y*y+dxa*dxa);
The method itself has some advangages - like rotating the world around the 'camera', at least on two axis (yaw and pitch) becomes simple addition... (though roll is basically going back to sin/cos) but there are also some disadvantages - because I'm not using openGL's matrixis applying lighting and shadows is going to be a 'from scratch' affair... textures when applied may not 'wrap' to depth properly, etc, etc. (I never really got that far though)... It's a technique I pretty much had to come up with on my own, since I really could find no real texts on handling this sort of thing as everything is either matrixes or flat multiplies, with full rotations for the final camera and then a simple z divide to do the perspective.
That reminds me - can anyone explain to me the raging chodo for matrixes? I still have trouble wrapping my brain around the concept of a 16 variables (meaning more memory access AND less likely to fit the L2 cache, much less the L1) and 64 multiplies being FASTER than the classic 6 and 6, or this technique... hell, it's so grossly inefficient they ended up having to make an entire register set and series of opcodes (disabling the mathco in the process) to make it USABLE... Doesn't seem right to me.
Anywho, if someone can come up with other ways of implementing this, I'd love to hear them. It's been, well... almost a decade since I put any serious thought this direction, but now that I'm recently semi-successfully retired AND it looks like people are taking my favorite language seriously again, I'm thinking on dusting off the hat and taking a serious stab at it.
Oh, I've also been (the past year) playing on and off with the math from above to do simple 3d in javascript and SVG - it's got a LOT more possibilites in that environment since Matmults and world rotations are agonizing in a interpreted language run atop a web browser.
For some time (hell, approaching a decade now) I've been playing with implementing a 3d engine that displays all 360 degrees around the user in a single 'strip' at the top of the screen... As described in the older Battletech fiction to create a "MechWarrior" style game (that perhaps actually has something to do with the parent product instead of just ripping off a few names and unit appearances). In the battletech universe it's one of the 'big features' of the BattleMech (and the helments of certain elite foot soldiers) that has been strangely missing from every attempt at a computer game of it.
Of course, the reason for it to be missing is simple - no 'popular' 3d perspective math is set up to do this well, if at all. You cannot tell OpenGL or DirectX to have a FoV of more than 90 degrees without horrible fish-eye effects... sure you can try splitting it into multiple views, but even with 16 of them across the top of the screen you STILL get wierd 'points' dropping down from the fish-eye effect, and if you compensate for the fish-eye the edges of the polys don't line up... much less how agonizingly slow it can get when you are rendering the same thing 17 times per FRAME.
So my question is, how would you guys implement this? I've asked in the past and the answer I've gotten most often is the 'multiple windows' that got rejected for the reasons above.
I was able to write a working demo in Delphi six years ago using glide that showed the concept in action, and I ported it to OpenGL and FPC a few years back... The .exe and needed files of that port are here:
http://battletech.hopto.org/circle/
I'm still looking for my old source... I'll post it when I find it
...but at the time I deemed it to be too slow to be practical on the hardware (of that era) for anything more than a very small map and one unit, with no textures and little more than simple (non shadow) shading. Now that the hardware has jumped forward I'm wondering if it might be practical for me to revisit again.
The technique I'm currently using is to use ATAN2 (actually, a workalike I wrote which is WAY faster but only works with 32 bit dwords and has 'screen' granularity) to convert the x and z coordinates of a point to a 'heading', which becomes my screen X coordinate - then I use pythag's theorem to get the distance on that axis, then use that distance and the y to get a 'pitch' value, which I project as screen y. One more sqrt(A^2+B^2) gets me the actual distance for z-buffering... I then project this one triangle at a time in orthogonal view in openGL (much as I did in glide). You have issues that have to be checked for like at the edges of the screen needing to render any triangles that have pixels on opposite sides of the screen are 'handled' down to be rendered twice on each side (+360 for the first, -360 for the second) but nothing insurmountable... just more if statements to slow things down :(
Basically the math boils down to:
ra_2_screen:=pi/(screen_width/2);
dxa:=sqrt(x*x+z*z);
screen_x:=atan2(x,z)*ra_2_screen;
screen_y:=atan2(y,dxa)*ra_2_screen;
distance:=sqrt(y*y+dxa*dxa);
The method itself has some advangages - like rotating the world around the 'camera', at least on two axis (yaw and pitch) becomes simple addition... (though roll is basically going back to sin/cos) but there are also some disadvantages - because I'm not using openGL's matrixis applying lighting and shadows is going to be a 'from scratch' affair... textures when applied may not 'wrap' to depth properly, etc, etc. (I never really got that far though)... It's a technique I pretty much had to come up with on my own, since I really could find no real texts on handling this sort of thing as everything is either matrixes or flat multiplies, with full rotations for the final camera and then a simple z divide to do the perspective.
That reminds me - can anyone explain to me the raging chodo for matrixes? I still have trouble wrapping my brain around the concept of a 16 variables (meaning more memory access AND less likely to fit the L2 cache, much less the L1) and 64 multiplies being FASTER than the classic 6 and 6, or this technique... hell, it's so grossly inefficient they ended up having to make an entire register set and series of opcodes (disabling the mathco in the process) to make it USABLE... Doesn't seem right to me.
Anywho, if someone can come up with other ways of implementing this, I'd love to hear them. It's been, well... almost a decade since I put any serious thought this direction, but now that I'm recently semi-successfully retired AND it looks like people are taking my favorite language seriously again, I'm thinking on dusting off the hat and taking a serious stab at it.
Oh, I've also been (the past year) playing on and off with the math from above to do simple 3d in javascript and SVG - it's got a LOT more possibilites in that environment since Matmults and world rotations are agonizing in a interpreted language run atop a web browser.