The same 4 triangles as before but rendered as if they are different distances from the camera, the brightest one is right up near the camera, the next one is (0.3*scene depth) away, then (0.5*scene depth) away and the last very faint one is (0.8*scene depth) from the camera.
Anything beyond that will be rendered with a grey polygon instead of the texture. Although I have not yet written that decision code yet.
The same 4 triangles as before but rendered as if they are different distances from the camera, the brightest one is right up near the camera, the next one is (0.3*scene depth) away, then (0.5*scene depth) away and the last very faint one is (0.8*scene depth) from the camera.
Anything beyond that will be rendered with a grey polygon instead of the texture. Although I have not yet written that decision code yet.
??? Isn't this just one wall part and one floor part? Made up of 4 triangles? Looks like shadow.....
I'm only using those same polygons because I can't be arsed to hardcode any more coordinates. Just imagine the darkest triangle is hundreds of metres away.
Finished my LDPS algorithm (Long Distance Polygon Substitution). Instead of wasting time rendering far away textuers, just replace it with a polygon of similar brightness with regard to distance
You should ignore the formation of the triangles because its not relevant at the moment, just that from left-to-right they are near-to-far. By altering a threshold we can radically speed up or slowdown the framerate depending on how much detail we want.
Ahha..so it is left to right..ok....goody....yeah, looks good...I havn't had the time to work to much on this today...I can't get my MySQL server to resopond and need to fix it...but I will stay an hour extra at work today since we have a football mach after hours...so I should get some time to start on the BSP tree..
Don't expect my function to calculate from World Space coordinates to Screen Space coordinates to be done any minute... I have at least no way to finnish that up before I go on my vacation in a week..
Need to find my math books then.....I can't remember this by hart at all.....I know I had it in my OpenGL book, but that one is left back in Norway.....W should have had Kedaman on the team, he live for stuff like this..
OK, I just found out that we need a Vector4 class too......grrrr...this is going to take for ever.....
and I got this info out of the master..
// THeory:
// From world to screen: X=x/z+screenwidth/2 and Y=y/z+screenheight/2
// But first from world to camera.
// coordinates = camera matrix * world coordinate
// Then 2D projection
An other thing. If you look at the picture I have attached. Lets say the quad in the middle is the screen. And I tell you to draw a quad where two of the vertices is P7 and P8 on this picture. What will happen then? Can you do that? Or do you have to change the screen coordinates? And if so, will that be a big problem, like getting the right perspective?
Don't read this..I just have to post it here since I am in Windows now, and I need it in Linux tomorrow....
--------------------------
We need to transform from the world coordinates to the eye coordinates
The eye coordinate system is specified by:
View reference point (VRP)
(VRPx, VRPy, VRPz)
Direction of the axes: eye coordinate system
U = (ux, uy, uz)
V = (vx, vy, vz)
N = (nx, ny, nz)
---------------------------------
There are two steps in the transformation (in order)
-Translation
-Rotation
---------------------------------
Translate World Origin to VRP
---------------------------------
Rotate World X, Y, Z to the Eye coordinate system u, v, n, also known as the View Reference Coordinate system
---------------------------------
- Center of camera (x, y, z) : 3 parameters
- Direction of pointing (q,j) : 2 parameters
- Camera tilt (w) : 1 parameter
- Area of film (w, h) : 2 parameters
- Focus (f) : 1 parameter
----------------------------------
- Center of camera (x, y, z) : View Reference Point (VRP)
- Direction of pointing (q,j) : View Plane Normal (VPN)
- Camera tilt (w) : View Up (VUP)
- Area of film (w, h) : Aspect Ratio (w/h), Field of view (fov)
- Focus (f) : Will consider later
----------------------------------
Eye:
- View Reference Point (VRP)
- View Plane Normal (VPN)
- View Up (VUP)
----------------------------------
Translate World Origin to VRP
Rotate World X, Y, Z to the Eye coordinate system, also known as the View Reference Coordinate system, VRC = (VUP ´ VPN, VUP, VPN), respectively:
-----------------------------------
- (VRP) View Reference Point
- (VPN) View Plane Normal
- (VUP) View Up
- (VRC)
- (COP) Center of Projection
- (DOP) Direction of Projection
- (PRP)
I remember trying to transform world coordinates to screencoords once and failing miserably.
Yeah...I have a bit of a problem here too at the moment...I can't understand how to do the first step...the rest should be piece of cake, but been looking for hours to find out how to do the first step...
I have also started to make a Camera class. But I am not sure how to build up the vectors in it yet..and if they should be 3 or 4 long...hmmm.....
But we need some input though.....from keyboard and maybe mouse after a while....mouse can be a bit tricky since we only want to find out how much it has moved since last frame, not couse coordinates. And then for every frame you have to reset it to the middle of the screen, and maybe even hide the mouse pointer?
First things first, leave the input until later, no point having mouse movement until we can draw something.
I'm putting the anticlock method as a member function of the TriangleClass, since a wallpart will be converted to 2 triangles. We need to be able to draw individual trianles too since both WallPart and Triangle both inherit from Primitive (my new name for DrawObject)
Are you allowed to use FTP at work? Do you use Fx? Can you add a plugin to it to use FTP?
Maybe we should have a working directory online, so we can just download the newest versions there all the time, so we don't do changes on the same file, and we no longer know what the new file is?
Not allowed FTP and IE is compulsory. They don't even let us blink without orders signed in triplicate.
It is going to be a problem later on though, we's stil have to agree not to work on the project at the same time with the same version. We should keep our 2 halves separate for as long as possible and then maybe you give me a copy of your half (and vice versa) and we can agree not to alter each-other's code, only work on our own stuff.
I'll need your wallparts to store the corner points in this order...
(its the most efficient sequence for GDI+ to process, as it means only point D needs to be transformed.)
Last edited by wossname; Aug 3rd, 2005 at 09:27 AM.
Do you think we should be making the wallparts and triangles draw themselves? At the moment I'm drawing them from the 'outside' by passing them to a DrawPrimitives(Primitive[]) method within the engine class.
Self-drawing would be the OOP thing to do but it would mean passing lots of information to each triangle and wallpart everytime and it would mean thy have to store more information internally so our memory usage would go up a lot.
What do you think, fast and dirty or slow and OOPy? (I like dirty myself but only because the framerates would be better). It would be a big job to recode the 'primitives' to draw themselves. Probably better to keep our current approach (which is more like DX's anyway) but I would like your opinion.
I can't see how that will be so much slower. You are not passing the infor to the triangle and wallpart every frame. The triangle and wallpaper class HOLDS all the information it needs to draw it self with? What do you mean? It even calculates it's own coordinates from world space to screen coordinates. To get a hold on that you need to take it OUT of the object....I can't see what you mean here....
The 3D primitives will stay put throughout the game but the 2D ones will have to be re-invented for each frame. Then I need to pass in at least 2 objects to each one.
I think the 3D wallpart should be able to create a 2d version of itself and then we can append that new object to this frame's Primitive[] array which will be looped through and drawn.
We have wallparts. They are read in from a 2D array, then I will make a BSP tree out of them. All of them will every frame be translated into Screen coordinates. Then the BSP tree will deside what walls will stay, and what walls have to go. Then call the draw function on the remaining leaves in the BSP tree, because they all ready have the screen coordinates.
Currently getting 10.5fps @ 800x600 drawing 40 triangles at varying distances (equivalent to 20 wallparts). Changing resolution up or down doesnt sem to have a huge impact on fps figures. We could probably run this fullscreen without too much hassle.
Originally Posted by wossname
