www.tombraiderforums.com

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

Reply
 
Thread Tools
Old 13-06-15, 03:46   #1511
Lwmte
Archaeologist
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 1,074
Default

Oh, hi! So nice to see you again!

I constantly think about new level editor, and actually IrisEngine may be a nice basis for it!

The advantage of OpenTomb is that it doesn't directly rely to old TR data formats; TeslaRus made it in a way you can program any loader for any data type - it's just currently it only supports TR file formats via VT loader.

There are, however, some "unparsed" structures, like anim commands or boxes. These need to be converted to something else beforehand.

I also thought about adapting old Dxtre3d code to OpenTomb needs, but since we have no access to Dxtre3d 2.0 code, it may be too tricky. I have old prototype of Dxtre3d 3.0 with reworked UI, but it's relatively useless, as it manipulates with its own (now deprecated) file formats.

Only think I'm afraid of is that we'll spend too much... hmm... human resources if we'll divide between engine and editor development just now; we're kinda in the end of our way programming codebase for entity functions (triggers are basically already done), so if we'll switch to editor right now, engine development will be somewhat halted.

However, it was proven by Gh0stBlade that you can relatively easy attach different level format loaders (he did it for Dreamcast level format), so maybe it worth a shot! But for me, currently I am not ready to switch from engine to editor development, it's just too funny!

And, as example, why!




As you can see, TeslaRus made some really cool optimizations, so now ragdoll bodies are not going through each other, and Lara's movement state is transferred to ragdoll more precisely! I have programmed small task into task manager (something that you folks call "organizer" in TRNG, I suppose?), which checks current animation numbers and frame numbers, and it forcibly sets ragdoll state for some common death animations on specific frame number. So you can have ragdolls implemented for ALL lara's deaths in literally no time!

I will make some additions to the code (in the process, I've changed whole control system layout!) and upload it in a day or two.

EDIT: I have committed code which drastically rearranges debug input - now we can poll keypress events directly from script, which allows to move whole DebugKeys function out of main_SDL.cpp. Along the way, I have made two hotkeys for setting and unsetting ragdoll mode for Lara. To activate ragdoll, just push R button during gameplay. To remove ragdoll, push T button. Make sure you have r_coll activated, or you won't see anything!

Last edited by Lwmte; 13-06-15 at 10:43.
Lwmte is offline   Reply With Quote
Old 13-06-15, 12:43   #1512
godmodder
Explorer
 
godmodder's Avatar
 
Join Date: Feb 2006
Location: Belgium
Posts: 535
Default

I agree, keep up the good work on the engine
But I think for me it would be the easiest way to contribute to this project, as I am already familiar with the IrisEngine code and would just have to export to the right format. We could support so much more new stuff with a custom format

Currently, the editor has full undo/redo functionality and the basic room editing. Of course a lot of work has to be done still to support items, baddies,...
But now that there is an engine to play the levels I will be more motivated

I will try and see if I can get a basic file from the editor to load.
__________________
C++ is the only place where friends get to see your private members.
godmodder is offline   Reply With Quote
Old 13-06-15, 14:48   #1513
Gh0stBlade
Archaeologist
 
Gh0stBlade's Avatar
 
Join Date: Dec 2010
Posts: 2,267
Default

Quote:
Originally Posted by Lwmte View Post
Oh, hi! So nice to see you again!
The advantage of OpenTomb is that it doesn't directly rely to old TR data formats; TeslaRus made it in a way you can program any loader for any data type - it's just currently it only supports TR file formats via VT loader.

There are, however, some "unparsed" structures, like anim commands or boxes. These need to be converted to something else beforehand.

I also thought about adapting old Dxtre3d code to OpenTomb needs, but since we have no access to Dxtre3d 2.0 code, it may be too tricky. I have old prototype of Dxtre3d 3.0 with reworked UI, but it's relatively useless, as it manipulates with its own (now deprecated) file formats.

Only think I'm afraid of is that we'll spend too much... hmm... human resources if we'll divide between engine and editor development just now; we're kinda in the end of our way programming codebase for entity functions (triggers are basically already done), so if we'll switch to editor right now, engine development will be somewhat halted.

However, it was proven by Gh0stBlade that you can relatively easy attach different level format loaders (he did it for Dreamcast level format), so maybe it worth a shot! But for me, currently I am not ready to switch from engine to editor development, it's just too funny!
Great video made me laugh the way the boulder sends Lara flying to the ground

I'd like an editor for OpenTomb. If we can somehow create a clone which runs off the formats of the original Tomb Raider 4/5 Level Editor we could then expand upon that. I'd prefer to have a new editor written from scratch but the resources as you mentioned are so small it will just delay OpenTomb so maybe it's best to work on an editor slowly with the least priority.

It is indeed easy to add support for new level formats as you mentioned with Dreamcast. I also wanted to support every single known Tomb Raider PC format but I think that's a little bizzare and it'll only contribute to more lines of code since VT Loader is a complete mess in my opinion (I absolutely hate it). I wanted to re-write it or possibly even clean some things up...

The only problem with Dreamcast files and others in general is they don't have a "magic" identifier to detect whether the input is from a specific platform or version of the game in some cases. Due to this, it's extremely difficult to check for Dreamcast files which is why it cannot run OpenTomb concurrently with TR5's PC level loading code. The only solution would be to look into a system where it's hardcoded through scripts where the platform and level version is defined. I particularly don't like this approach so maybe it just needs to stay on it's own branch. I am still yet to add support for PS1 files but it's not much of a priority right now so I've left it. It'll only end up like Dreamcast anyway.


----

I've been looking at fixed cameras again and rebuilt the code ontop of the latest commit a few days ago. Still, I've not been successfully able to to get the "target" look at entity working. All we really need is an implementation of gluLookAt which just won't work. I'll still create a pull request today since it "works" only the camera does not look at what it's supposed to.

Regards.
__________________
No longer accepting PMs due to abuse of the system.
Gh0stBlade is offline   Reply With Quote
Old 13-06-15, 14:54   #1514
Cochrane
Gold Contributor
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,138
Default

Quote:
Originally Posted by Gh0stBlade View Post
Great video made me laugh the way the boulder sends Lara flying to the ground

I'd like an editor for OpenTomb. If we can somehow create a clone which runs off the formats of the original Tomb Raider 4/5 Level Editor we could then expand upon that. I'd prefer to have a new editor written from scratch but the resources as you mentioned are so small it will just delay OpenTomb so maybe it's best to work on an editor slowly with the least priority.

It is indeed easy to add support for new level formats as you mentioned with Dreamcast. I also wanted to support every single known Tomb Raider PC format but I think that's a little bizzare and it'll only contribute to more lines of code since VT Loader is a complete mess in my opinion (I absolutely hate it). I wanted to re-write it or possibly even clean some things up...

The only problem with Dreamcast files and others in general is they don't have a "magic" identifier to detect whether the input is from a specific platform or version of the game in some cases. Due to this, it's extremely difficult to check for Dreamcast files which is why it cannot run OpenTomb concurrently with TR5's PC level loading code. The only solution would be to look into a system where it's hardcoded through scripts where the platform and level version is defined. I particularly don't like this approach so maybe it just needs to stay on it's own branch. I am still yet to add support for PS1 files but it's not much of a priority right now so I've left it. It'll only end up like Dreamcast anyway.


----

I've been looking at fixed cameras again and rebuilt the code ontop of the latest commit a few days ago. Still, I've not been successfully able to to get the "target" look at entity working. All we really need is an implementation of gluLookAt which just won't work. I'll still create a pull request today since it "works" only the camera does not look at what it's supposed to.

Regards.
Where exactly do you want the gluLookAt? I have a similar self-written function in a few other projects I wrote that I could easily adapt here. In general it's not that hard; construct a matrix corresponding the position matrix of a camera looking in the right direction (looking down its -Z axis), then invert it.
__________________
GŁter auf die Bahn!
Cochrane is offline   Reply With Quote
Old 13-06-15, 15:56   #1515
Gh0stBlade
Archaeologist
 
Gh0stBlade's Avatar
 
Join Date: Dec 2010
Posts: 2,267
Default

Quote:
Originally Posted by Cochrane View Post
Where exactly do you want the gluLookAt? I have a similar self-written function in a few other projects I wrote that I could easily adapt here. In general it's not that hard; construct a matrix corresponding the position matrix of a camera looking in the right direction (looking down its -Z axis), then invert it.
If you're able to adapt the code you have previously written it would be super useful. Main problem is camera isn't pointing in the correct direction. It is actually determined by another trigger known as "camera target" which makes the current camera look at a specific object in the world.

https://github.com/Gh0stblade/OpenTo...Camera_Tests_1

Cam_LookAtTarget@EndOf Camera.cpp is where it would need to be done.

Cheers.
__________________
No longer accepting PMs due to abuse of the system.
Gh0stBlade is offline   Reply With Quote
Old 13-06-15, 18:27   #1516
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 195
Default ragdoll

This time ragdoll correctly rendered without r_coll , test latest commit (You can use Lwmte's binded buttons r and t);
TeslaRus is offline   Reply With Quote
Old 14-06-15, 09:15   #1517
Lwmte
Archaeologist
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 1,074
Default

Unfortunately, this commit breaks ragdoll physics, as ENTITY_TYPE_DYNAMIC flag was commented... Without it, rigid body positions will be trashed by animation frame re-positioning. This is not a right way to do it.

However, the problem lies in something related. Most likely, the question is for Cochrane - there is new code part I didn't see in Render_Entity function:

Code:
        if(entity->type_flags & ENTITY_TYPE_DYNAMIC)
        {
            memcpy(subModelView, modelViewMatrix, sizeof(subModelView));
            memcpy(subModelViewProjection, modelViewProjectionMatrix, sizeof(subModelViewProjection));
        }
        else
        {
            Mat4_Mat4_mul(subModelView, modelViewMatrix, entity->transform);
            Mat4_Mat4_mul(subModelViewProjection, modelViewProjectionMatrix, entity->transform);
        }
I have no idea what's going on, but if I remove first part with memcpy, Lara will render correctly! But the problem is, other dynamic entities (like boulders) will break. I believe something is wrong here.

Edit: actually, it seems that that particular part is unrelated, as it does the same as pre-shader pipeline. I remember that I forced global mesh transformation matrix to be used for dynamic entities, but for some reason it only worked with single-mesh entities. Perhaps, some additional coding must be done to make both single-mesh and multi-mesh dynamic entities to be rendered correctly.

Last edited by Lwmte; 14-06-15 at 09:44.
Lwmte is offline   Reply With Quote
Old 14-06-15, 17:22   #1518
Cochrane
Gold Contributor
 
Cochrane's Avatar
 
Join Date: Apr 2006
Location: Germany
Posts: 16,138
Default

Quote:
Originally Posted by Gh0stBlade View Post
If you're able to adapt the code you have previously written it would be super useful. Main problem is camera isn't pointing in the correct direction. It is actually determined by another trigger known as "camera target" which makes the current camera look at a specific object in the world.

https://github.com/Gh0stblade/OpenTo...Camera_Tests_1

Cam_LookAtTarget@EndOf Camera.cpp is where it would need to be done.

Cheers.
I still can't go on the Internet except through my iPad, so right now I can't test it (can't fetch your new code), but I can tell you what you need to do. The more complex matrix manipulation is already there in Cam_Apply. You just need to calculate its inputs.
- Calculate position (as I understand it you already have that).
- Calculate view_dir; that is be the target entity's position minus the camera's position.
- Set up_dir to 0,0,1 (not the final value, just an initial "guess").
- Calculate right_dir as perpendicular to both view_dir and up_dir, and pointing the right way. For that use vec3_cross(right_dir, view_dir, up_dir).
- Calculate final value of up_dir, as perpendicular to view_dir and right_dir. Here it's vec3_cross(up_dir, right_dir, view_dir).
- Pray nobody ever looks straight up (or if you detect someone doing so, choose a different up_dir first guess; but I think this isn't a case that actually occurs in TR).

All these vectors are defined as btScalar[4], but the last component isn't actually used anywhere. If you want to be absolutely precise about it, the fourth component of position must be 1.0, and for all others 0.0 (but you don't have to do that, the code implicitly assumes that this is always the case anyway).

Sorry for not using exact mathematical notation here, typing complex stuff on an iPad isn't trivial. Good luck!

Edit to add: Completely forgot the most important part: Normalize all these vectors as you calculate them (I think there's some vec3_normalize somewhere in vmath), except position. Otherwise results will be bizarre, if anything shows up at all.
__________________
GŁter auf die Bahn!

Last edited by Cochrane; 14-06-15 at 17:37.
Cochrane is offline   Reply With Quote
Old 14-06-15, 17:58   #1519
Titak
Moderator
 
Titak's Avatar
 
Join Date: Jul 2003
Location: Drenthe, The Netherlands
Posts: 32,384
Default

As much as I like ragdoll effects instead of the old style stiff deaths, the ragdoll effects I've seen in games so far tend to be too much ragdoll.
Joints go the wrong way all of a sudden. Like knees bending sideways which they normally can't do, unless they are broken. And with the ragdoll effects this happens without effort.
And there's often too much movement, causing the character to still move (as if teh character has no weight or something) while a real dead person would be still already.


But that said, I think you guys do great work!

And I think it is good to focus just on the engine for now.
And once the engine is the way you want it to be work can be focussed on an editor.
__________________
If it walks like a duck and if it quacks like a duck, it is a duck.
Titak is offline   Reply With Quote
Old 14-06-15, 23:54   #1520
Boobandie
Professor
 
Join Date: Jul 2012
Posts: 3,867
Default

Yeah, I think Angel of Darkness was the closest to good ragdoll deaths as we've seen in the series. We don't wanna go halflife ragdolls, they need some rigidity, and limits on which way her parts can bend (unless say, there is enough velocity to "break" a particular joint, but that would be isolated to that particular piece).
Boobandie 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 23:09.


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