www.tombraiderforums.com

Go Back   www.tombraiderforums.com > Tomb Raider Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 28-06-13, 10:22   #201
Cochrane
Gold Contributor
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,049
Default

Quote:
Originally Posted by shabtronic View Post
Hi Conchrane - I myself am no Graphics expert, I ment to ask you is there an easy way to do the underwater effect without using a shader? - i.e. the screen space vertex wobble when the room is underwater? I know how to do it using the camera's up and sideways vectors - but that just seems really ugly - esp for my loader since I use the verts directly and they are ints. I'm wonderng is there a trick to this?

thanks
In short: No, shaders are the easiest way. Unless you have a very, very good reason to avoid them (e.g. you absolutely need it to work on Android phones that only have OpenGL ES 1.1 or something), use shaders. If you need help with shaders, I'd be happy to assist.

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.
__________________
GŁter auf die Bahn!

Last edited by Cochrane; 28-06-13 at 10:25.
Cochrane is offline   Reply With Quote
Old 28-06-13, 10:28   #202
shabtronic
Hobbyist
 
Join Date: Feb 2012
Posts: 56
Default

Quote:
Originally Posted by Cochrane View Post
In short: No, shaders are the easiest way. Unless you have a very, very good reason to avoid them (e.g. you absolutely need it to work on Android phones that only have OpenGL ES 1.1 or something), use shaders. If you need help with shaders, I'd be happy to assist.

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.
Wow - that is interesting - so on the MAC they are using the Vid card as a rasterizer only and doing all the transform stuff them selfs :P ahh the good old days. I'll have a look at the code in Tomb4.exe and try and find the transform code. I suppose they could get away with this because of the portal system. Yeah I want to avoid shaders for this version - for various reasons :P Hmmm need some right brain thinking to do the wobble without shaders.


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.
shabtronic is offline   Reply With Quote
Old 29-06-13, 09:16   #203
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
Default 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?
TeslaRus is offline   Reply With Quote
Old 29-06-13, 11:58   #204
meta2tr
Historian
 
Join Date: Apr 2008
Posts: 368
Default

Quote:
Originally Posted by TeslaRus View Post
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?
In tr4 files, there is a vertex flag associated with wave movement. The flag is the 5th word in the room vertex structure.
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
meta2tr is offline   Reply With Quote
Old 29-06-13, 12:34   #205
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
Default 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?
TeslaRus is offline   Reply With Quote
Old 29-06-13, 15:34   #206
meta2tr
Historian
 
Join Date: Apr 2008
Posts: 368
Default

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.
meta2tr is offline   Reply With Quote
Old 30-06-13, 09:28   #207
Lwmte
Explorer
 
Join Date: Aug 2010
Posts: 939
Default

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.
Lwmte is offline   Reply With Quote
Old 30-06-13, 13:01   #208
meta2tr
Historian
 
Join Date: Apr 2008
Posts: 368
Default

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.
meta2tr is offline   Reply With Quote
Old 30-06-13, 14:26   #209
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
Default 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)
TeslaRus is offline   Reply With Quote
Old 30-06-13, 17:57   #210
Lwmte
Explorer
 
Join Date: Aug 2010
Posts: 939
Default

Quote:
Originally Posted by meta2tr View Post
it seems that the most intuitive is the texture coordinates because these are easy to locate visually. Also, this is easy to code.
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.
Lwmte is offline   Reply With Quote
Reply

Bookmarks

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 14:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.