28-06-13, 10:22 | #201 | |
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
You can modify the vertices in bulk on the CPU before sending them to OpenGL, and in the brief time after the existence of GPUs with hardware transform & lighting but before the existence of shaders, that was the recommended way (and still is for crappy Android phones), but I wouldn't use it anymore. TR's approach is a very different one. I've done some analysis on the Mac version of TR2, and it seems that this does not use the standard OpenGL modelview matrix at all (the projection matrix is used, but only to scale everything to offset the viewport transformation, since TR uses a different screen-space coordinate system from OpenGL. It is effectively useless). Instead it calculates the necessary transformations completely on the CPU, and presumably, it applies the wobble there, too. Since it has the screen space coordinates, it does not even need the camera coordinate system. In general, Tomb Raider is best understood as a software renderer that has been very slightly adapted to use very early 3D accelerators. You can copy that approach today, but it's not at all useful for modern GPUs, and especially not if you want to render levels that are more complex than those that the TR engine (even if patched) can. Today, you want the transformations on the GPU, and if you want to modify the vertex transformations in this way, then a shader is really the only useful solution I see. Last edited by Cochrane; 28-06-13 at 10:25. |
|
28-06-13, 10:28 | #202 | |
Member
Joined: Feb 2012
Posts: 56
|
Quote:
Actually that explains a lot - TR1-TR3 does the transform in software (I guess they were emulating the PSX GTE fixed point stuff), TR4 uses Hardware T&L. The underwater effect in TR4 is poor compared to the effect in TRLA - Sleeping with fishes - that first underwater window just looks stunning :P I'll try and find the TR4 wobble code see how they've done it - it terrible compared to the previous versions! Last edited by shabtronic; 28-06-13 at 10:47. |
|
29-06-13, 09:16 | #203 |
Member
Joined: Jan 2013
Posts: 195
|
swimming
Hallo! I fix crashes in gold levels case: I did not check room_sprite == NULL in renderer.
About swimming: underwater swimming is easiest to implement and I did it. But this time I need water surface detection... I see way to do it with polygon transparency / normale check (horizontal and transparency flag >= 1) + polygon plane == portal plane and room_up.water xor room_down.water != 0. But, is more correct way as a some vertex flags checking? |
29-06-13, 11:58 | #204 | |
Member
Joined: Apr 2008
Posts: 368
|
Quote:
Values: 0x2000 or 0x6000 = up and down movement 0x4000 = caustics effect One problem is that in meta2tr levels this flag is sometimes used as an effect in a dry room (like branches on trees). It may also be removed from water surfaces (cave in the demo level v7) Another possible test: see if the texinfo on the surface is double-sided and in an animated range. Another possible test: see if there's no collision in the floor data if (Level->Rooms[rn].Sectors[xszs].RoomBelow != 0xFF) // no collision |
|
29-06-13, 12:34 | #205 |
Member
Joined: Jan 2013
Posts: 195
|
water test
Thanks for information. I was trying to detect water polygons by portals information - there is wrong results in WALL.TR2. I decided to use texture coordinates check - fast, easy and absolutely correct. But the first I need to get information about water texture position. That information may be added manually to the levelscript.lua. But, can I get this information from original level structure?
|
29-06-13, 15:34 | #206 |
Member
Joined: Apr 2008
Posts: 368
|
I haven't seen any flag or variable in the level structure that indicates that a texture is a water texture.
Last edited by meta2tr; 29-06-13 at 15:52. |
30-06-13, 09:28 | #207 |
Member
Joined: Aug 2010
Posts: 1,810
|
I think that easiest way is to check up water flag of a current Lara's room, I suppose it's the way Core used in their engines (since you can change room flag to water on the fly, and Lara will immediately change her state to swimming). Moreover, it's necessary to make sure Lara changes her state in case of alternate room switching (you can't make it with simple "water" polygon collision test, because when room switches to alternate, no water surface pass happens and Lara stays in the same room bounds).
Also, additional coordinates checking should be performed to assure that room above is not water room, so state can be changed from underwater to surfacing. I think that Core checked specific meshes position, not whole Lara model (maybe they used only hips mesh as a reference point in older games, that's the reason why she often remained in underwater swim state, even if she sticked out of water almost the half). Eventually, we can check if head, hips and feet meshes are in a room with water flag set, and create if...then statement with these conditions: 1. Head+hips+feet in water room: fully underwater 2. Hips+feet in water room: if no floor collision and already underwater state, switch to surfacing, else switch to underwater (if no floor collision, else switch to shallow water animations in TR2 and above). 3. Only feet in water room: make steps audio FX with splashing sound, also if switching from shallow water, set normal run/walk animation state. 4. Head+hips in water room: if no floor collision, set state to underwater, else... I can't imagine such situation, but in custom levels... I remember that in Armageddon's Temple 2 there was a flat water room through which you should fall in a deep pit, Lara simply fell through it. 5. Unusual situations, like only head in water room, feet+head in water room, can be ignored or simply make Lara wet, like in TR4-TR5. Last edited by Lwmte; 30-06-13 at 09:30. |
30-06-13, 13:01 | #208 |
Member
Joined: Apr 2008
Posts: 368
|
Detecting how much of Lara is underwater is probably not too difficult since any portal between a water room and a dry room can be considered the water surface (even if there are no visual faces there). This would work for alternate rooms too.
In OpenTomb all visual faces have collision on by default. This is a good thing, it allows the level designer more flexibility and is also more realistic for the player. But it creates some problems to be solved. For example - water surfaces, cobwebs, curtains - although they are faces, they would generally not have collision. Often, these faces that shouldn't have collision are transparent, double-sided, and are aligned with portals. However, these properties aren't sufficient for detecting if collision should be turned off, like for example windows or bars - these are transparent and double-sided, and often near to a portal, yet collision should be turned on. Curtains are not always transparent, they would need collision turned off. Alternatively, if we want a way to determine if collision should be set or not that never fails, then either we need a flag on the faces, or the vertices, or the texture. Out of these three it seems that the most intuitive is the texture coordinates because these are easy to locate visually. Also, this is easy to code. |
30-06-13, 14:26 | #209 |
Member
Joined: Jan 2013
Posts: 195
|
water test, physics
I wrote function that find current water level correctly (sector / sector above / sector below tests). To adjust collisions I add script property to textures (I.E. tile with № and rect (x0, y0, x1, y1) has no collision). Polygons with water textures has no collisions.
About collision system: really it is not always good that visible model == collision model for models with a big numbers of polygons (slow + incorrect edge calculation in climbing). This time polygons with transparency >= 2 has no collision, but it is not correct in all cases. How much of Lara is underwater can be founded by water level, Lara's position and Lara's X angle (she has static length and height in swimming) |
30-06-13, 17:57 | #210 |
Member
Joined: Aug 2010
Posts: 1,810
|
But there are cases in TR which rule out this solution. For example, in TR3's Aldwych level you need to obtain ornate star behind opaque curtain, which in other cases should be solid. On contrary, in TR4 you have room with "frozen" water texture in Temple of Karnak. So in any case, you need more information than simple texture coordinates or opacity flags.
|
Thread Tools | |
|
|