www.tombraiderforums.com  

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

Reply
 
Thread Tools
Old 23-10-14, 10:12   #921
Nicklander
Historian
 
Nicklander's Avatar
 
Join Date: Oct 2014
Location: Lausanne
Posts: 255
Default

Haha the shiva looks so funny.
Great job keep on developing this !
Nicklander is offline   Reply With Quote
Old 23-10-14, 14:30   #922
Caesum
Tomb Raider
 
Caesum's Avatar
 
Join Date: Aug 2008
Location: Poland, Warsaw Gender: Male
Posts: 11,564
Default

May I ask a silly question, when are you going to make the camera work like in classics? I mean so it moves and rotates with Lara. In all of the videos it seems to be independent from Lara's moves.
Caesum is offline   Reply With Quote
Old 23-10-14, 14:42   #923
pmatulka
Hobbyist
 
Join Date: Jun 2013
Location: Poland
Posts: 40
Default

Quote:
Originally Posted by Lwmte
Sure, we need classic auto camera in OpenTomb; actually, there is already working implementation by Kurlyak, but it was written for Direct3D - only thing we need is to adapt it to OpenGL. I'm not good at math, so I still hope someone else might do this! As for mouse inversion, I'll look into it, shouldn't be hard to implement.
Demo for this is already done.

Just in config.lua change mlook(1); to mlook(0);
pmatulka is offline   Reply With Quote
Old 24-10-14, 13:28   #924
Lwmte
Archaeologist
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 1,074
Default

Ok, so now we decided to finally change collision model back to floordata! I had brief conversation with TeslaRus and it seems the best solution, as recreating all the doors and portals in existing levels is a pure hell. The problem is, TR1-5 collision system was designed back in 1996, when resources for mesh-based collision were too scarce, and whole concept was new, so Core have gone with discrete "slant-based" sector collision. There is no such option in contemporary physics engines, so what must be done is converting existing floordata and sector heights to collisional polygons (which are then fed into Bullet). Essentially, we parse through adjacent sectors in a room and build unified geometry collisional mesh.

I'm asking for help because I can't fully get the concept of sector-based collision, and it seems that people like Turbo Pascal and meta2tr got it right, since both Dxtre3d and meta2tr software can operate with it (especially the second one, as latest meta2tr version "decodes" existing collision and allows to modify it in Metasequoia).

What I've learned so far:

1. Absolute "flat" floor/ceiling height is taken from sector info's floor/ceiling parameters (world coordinates).
2. In TR1-2, corner heights (so called "slants") are derived from floordata word operand, which is divided into two signed byte values (for X and Z oriented slants), where value's sign specifies slant direction (e.g., positive number gives right-to-left slant descendance for X-oriented slant, while negative number gives left-to-right descendance).

Things are getting really complicated with TR3. There are TWELVE additional functions, and while I understand that some of them are responsible for "north-west" and some for "north-east" diagonal orientation, it's not clear is how TR1-2 legacy slants are interfering with TR3-5 triangle slants. I mean, is it possible to combine them in the same sector, i.e. is there a chance to stumble upon sector which contains both 0x02 floordata function and, for example, 0x08 function? Thanks!

Last edited by Lwmte; 24-10-14 at 13:37.
Lwmte is offline   Reply With Quote
Old 24-10-14, 13:46   #925
Gh0stBlade
Archaeologist
 
Gh0stBlade's Avatar
 
Join Date: Dec 2010
Posts: 2,284
Default

Quote:
Originally Posted by pmatulka View Post
Demo for this is already done.

Just in config.lua change mlook(1); to mlook(0);
Yes, that's just a temporary feature I added long back. It automatically rotates the camera based on Lara's current angle. See Game.cpp "cam_angles[0] = (ent->angles[0] * (M_PI/180));" Kurlyak's camera code was much more like the original. I never got round to attempting to implement it into OpenTomb. I don't think it would be that difficult since the code is pretty much there. Just needs adapting to OpenTomb.

Quote:
Originally Posted by Lwmte View Post
Ok, so now we decided to finally change collision model back to floordata! I had brief conversation with TeslaRus and it seems the best solution, as recreating all the doors and portals in existing levels is a pure hell. The problem is, TR1-5 collision system was designed back in 1996, when resources for mesh-based collision were too scarce, and whole concept was new, so Core have gone with discrete "slant-based" sector collision. There is no such option in contemporary physics engines, so what must be done is converting existing floordata and sector heights to collisional polygons (which are then fed into Bullet). Essentially, we parse through adjacent sectors in a room and build unified geometry collisional mesh.

I'm asking for help because I can't fully get the concept of sector-based collision, and it seems that people like Turbo Pascal and meta2tr got it right, since both Dxtre3d and meta2tr software can operate with it (especially the second one, as latest meta2tr version "decodes" existing collision and allows to modify it in Metasequoia).

What I've learned so far:

1. Absolute "flat" floor/ceiling height is taken from sector info's floor/ceiling parameters (world coordinates).
2. In TR1-2, corner heights (so called "slants") are derived from floordata word operand, which is divided into two signed byte values (for X and Z oriented slants), where value's sign specifies slant direction (e.g., positive number gives right-to-left slant descendance for X-oriented slant, while negative number gives left-to-right descendance).

Things are getting really complicated with TR3. There are TWELVE additional functions, and while I understand that some of them are responsible for "north-west" and some for "north-east" diagonal orientation, it's not clear is how TR1-2 legacy slants are interfering with TR3-5 triangle slants. I mean, is it possible to combine them in the same sector, i.e. is there a chance to stumble upon sector which contains both 0x02 floordata function and, for example, 0x08 function? Thanks!
You could try dropping TurboPascal a message or one of the other folks. I'm fairly certain they'd help out with this! It's for the best that the floor data is used directly. As you posted long back, there would be issues with invisible ledges used on Tomb Raider 2 and I think Tomb Raider 3.

I've been having difficulties getting the game to compile again. If someone could point me to the libraries I need to compile OpenTomb again I'd appreciate it.

Excellent work with the new features. Been extremely busy lately.

Regards.
__________________
No longer accepting PMs due to abuse of the system.
Gh0stBlade is offline   Reply With Quote
Old 24-10-14, 14:05   #926
pmatulka
Hobbyist
 
Join Date: Jun 2013
Location: Poland
Posts: 40
Default

Quote:
Originally Posted by Gh0stBlade View Post
If someone could point me to the libraries I need to compile OpenTomb again I'd appreciate it.
For Linux is: libsdl2-dev libsdl2-image-dev libglu1-mesa-dev zlib1g-dev.
For windows also should be something like.
pmatulka is offline   Reply With Quote
Old 24-10-14, 16:29   #927
Dustie
Relic Hunter
 
Dustie's Avatar
 
Join Date: Apr 2005
Location: Poland
Posts: 9,209
Default

Does this mean that there won't be any "real 3D" collision possible in the engine? As in, the kind of collision that's used in modern games, that's not made up from sectors and whatnot, but simly comes from the 3D shape of the level?
Dustie is offline   Reply With Quote
Old 24-10-14, 17:33   #928
Lwmte
Archaeologist
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 1,074
Default

No, it will be used as a legacy workaround for classic levels. This is done because we have faced problems with some specific collision cases, like invisible bridges in TR2-3, curtains, quicksand and trees in TR3, and so on. You still get proper collision for statics and objects, and optionally you'll be able to load custom collision maps externally, like it is done in contemporary games.

By the way, I doubt that any modern game uses ALL visible geometry as a collision geometry, cause it will be too complex and difficult to calculate.
Lwmte is offline   Reply With Quote
Old 25-10-14, 11:16   #929
Lwmte
Archaeologist
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 1,074
Default

First floor data collision test!

Here you can see blue debug lines indicating actual sector collision data. This is a very DRAFT and ROUGH implementation, as I've only constructed flat and "classic" TR1-2 floor slants, yet we don't have proper triangular slants, walls and ceilings - but anyway, this is the first step! As you can see, Lara doesn't stumble into vegetation, quicksand surface and such anymore. There are still some bugs to rule out, however.


Also please note that this impementation doesn't use floordata directly anymore. I hope that eventually we'll get rid of this "parse-through-me-every-time" nonsense completely and use collisional mesh generated on the fly for collisions, plus scripted triggers for anything else.
Lwmte is offline   Reply With Quote
Old 25-10-14, 12:48   #930
Ado Croft
Historian
 
Join Date: Apr 2013
Posts: 272
Default

Wow, collision system works the same like in TR old games. Finally Lara can pass into quicksand terrain and so on. I know it is soon to ask for that but how could we place external collision from custom level created via metasequioa to this engine? Will it be necessary to create some program for that? Anyway, great job

Last edited by Ado Croft; 25-10-14 at 12:49.
Ado Croft is offline   Reply With Quote
Reply

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 04:48.


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