Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor

Reply
 
Thread Tools
Old 05-01-20, 21:29   #1
TRJTA
Member
 
TRJTA's Avatar
 
Joined: Sep 2007
Posts: 3,411
Exclamation Help needed for further development of Tomb Raider III HD Remaster!

I just finished the first level and first cutscene for the Tomb Raider III HD Remaster. I was just preparing for the second level and investigated ways to improve my workflow.

Sadly I discovered a big issue in Rview (the tool by Turbo Pascal which I use to edit the room geometry.) This issue is an addition to another issue this tool has, but unlike that one I can't fix this issue.

ISSUE 1 - (inconvenient, but has a way to fix it)

When exporting and importing back the geometry of a room, the vertex colors/lighting gets scrambled, completely changing the lighting of the room. When exporting and importing back again this doesn't happen again.

The workaround for this is to relight the room once imported. It's a bit frustrating but at least it can be fixed.

ISSUE 2 - That major problem, I need a fix for this desperately!
Using the DXF exporter in Rview shifts the geometry a tiny bit in a diagonal direction. When importing it back this will result in a seam between the rooms. I tried compensating this by shifting the room back a tiny bit in the opposite direction in Metasequoia, but it seems like the coordinates get rounded off. So it will either be positioned a tiny bit too much in either of the directions, but never in the exact right spot. So the seams are inevitable at this moment. I noticed a few of them when working on the Jungle level, but always thought they were caused by mistakes I made myself. Through a lot of fiddling and dirty solutions I managed to make them mostly unnoticeable in the Jungle level, but it was a horrible task which will probably always result in remaining seams all over the place.

I already sent a message to Turbo Pascal about this, but I saw he hasn't been on the forums for over a year.

I also know IceBerg was the one who improved Rview with revision 3. Perhaps he/she could do something about this? But I would now know how to contact him/her. Maybe someone else does?

I really hope there's someone here who could help me with this. Either by fixing the programming of the Rview tool, or by teaching me about a different way to export, edit and reimport single rooms from a TR2 file to DXF with textures and vertex colors intact

Right now sadly continuing my work on the TRIII HD project is pointless untill I find a way to fix this.

Thanks in advance!

Last edited by TRJTA; 05-01-20 at 21:33.
TRJTA is offline   Reply With Quote
Old 06-01-20, 02:42   #2
sapper
Member
 
sapper's Avatar
 
Joined: Sep 2007
Posts: 1,684
Default

Sadly I think IceBerg passed away.

I have email for TurboPascal but he hasn't responded in a long while.
sapper is offline   Reply With Quote
Old 06-01-20, 08:26   #3
TRJTA
Member
 
TRJTA's Avatar
 
Joined: Sep 2007
Posts: 3,411
Default

Quote:
Originally Posted by sapper View Post
Sadly I think IceBerg passed away.

I have email for TurboPascal but he hasn't responded in a long while.
Oh no! I did not know that.
Would you be willing to share his mail address with me through PM? And would you maybe know of a way to fix these problems?
TRJTA is offline   Reply With Quote
Old 06-01-20, 18:51   #4
not again!
Member
 
not again!'s Avatar
 
Joined: Feb 2008
Posts: 1,145
Default

Could you post an image or describe exactly how much the room is shifted?
This sounds like a familiar issue which might have more to do with the fact that it's hard to reach perfect accuracy in modelling softwares, which is due to floating point precision errors - it's a know problem when building models which are meant to tile in a game.
The fact that the room while it's in the modeling software is most likely on a much smaller scale (maybe 1:100) compared to the game, means that those small inaccuracies get blown up in scale too when imported back and are quite noticeable in game then.

edit: better yet - could you upload one of those faulty .dfx files?

Last edited by not again!; 06-01-20 at 18:55.
not again! is offline   Reply With Quote
Old 06-01-20, 20:59   #5
TRJTA
Member
 
TRJTA's Avatar
 
Joined: Sep 2007
Posts: 3,411
Default

Quote:
Originally Posted by not again! View Post
Could you post an image or describe exactly how much the room is shifted?
This sounds like a familiar issue which might have more to do with the fact that it's hard to reach perfect accuracy in modelling softwares, which is due to floating point precision errors - it's a know problem when building models which are meant to tile in a game.
The fact that the room while it's in the modeling software is most likely on a much smaller scale (maybe 1:100) compared to the game, means that those small inaccuracies get blown up in scale too when imported back and are quite noticeable in game then.

edit: better yet - could you upload one of those faulty .dfx files?
Yes I think you are totally right. It probably has something to do with the small scale.
After some more investigating i noticed that it's not that the room is shifted in position a tiny bit, no, the room seems to be upscaled a tiny bit!

Here is a exported .dxf of Room 19 from ROOFS.TR2 (Thames Warf).

When undoing/redoing the dxf import back into Rview i noticed a seam appeared on the one side of the room, but not on the other. So the room got scaled up a tiny bit into one direction, not from the center.

This really seems like a math rounding error.

I hope there is something we can do to fix this!

Last edited by TRJTA; 06-01-20 at 21:22.
TRJTA is offline   Reply With Quote
Old 06-01-20, 22:23   #6
not again!
Member
 
not again!'s Avatar
 
Joined: Feb 2008
Posts: 1,145
Default

Is that an unmodified .dfx straight from RView? The coordinates look fine to me. If so could you please share one that you have edited and where the coordinates are off?

The possible solution I had in mind is fixing the incorrect coordinates in Notepad++.
As you know one horizontal grid square is 1024 x 1024, so the coordinates should all be based around that (2048, 3072, etc). RView seems to export a room at a scale of 1:1000 since the coordinates when you open the .dfx in Notepad are 1.024000, etc.
We need to check by how much the coordinates are off of the correct value in a "corrupted" .dfx. I hope that is generally something like 1.025000 instead of 1.024000, since that could be easily fixed by a search and replace. (if the corrupted values are more along the lines of 1.025673 instead of 1.024000, then this possible fix isn't feasible anyway... edit: on second thought those values get rounded when imported into RView so this method might still work after importing and then exporting again from RView since then you have rounded values again which could be easily replaced in Notepad)

Notepad++ has a Recording function where you can record a series of actions and then play them back. So for instance you could record the action of performing a "search and replace" and replace the wrong coordinate value of 1.025000 with the correct value of 1.024000. When you then open the .dfx for the next room you can just replay what you recorded and Notepad will fix the file for you automatically by replacing all the wrong values with the corrected ones.

Last edited by not again!; 06-01-20 at 22:43.
not again! is offline   Reply With Quote
Old 07-01-20, 05:42   #7
TRJTA
Member
 
TRJTA's Avatar
 
Joined: Sep 2007
Posts: 3,411
Default

Quote:
Originally Posted by not again! View Post
Is that an unmodified .dfx straight from RView? The coordinates look fine to me. If so could you please share one that you have edited and where the coordinates are off?

The possible solution I had in mind is fixing the incorrect coordinates in Notepad++.
As you know one horizontal grid square is 1024 x 1024, so the coordinates should all be based around that (2048, 3072, etc). RView seems to export a room at a scale of 1:1000 since the coordinates when you open the .dfx in Notepad are 1.024000, etc.
We need to check by how much the coordinates are off of the correct value in a "corrupted" .dfx. I hope that is generally something like 1.025000 instead of 1.024000, since that could be easily fixed by a search and replace. (if the corrupted values are more along the lines of 1.025673 instead of 1.024000, then this possible fix isn't feasible anyway... edit: on second thought those values get rounded when imported into RView so this method might still work after importing and then exporting again from RView since then you have rounded values again which could be easily replaced in Notepad)

Notepad++ has a Recording function where you can record a series of actions and then play them back. So for instance you could record the action of performing a "search and replace" and replace the wrong coordinate value of 1.025000 with the correct value of 1.024000. When you then open the .dfx for the next room you can just replay what you recorded and Notepad will fix the file for you automatically by replacing all the wrong values with the corrected ones.
It is indeed an unmodified dxf straight from Rview.
I think Rview messes the dxf up a bit when exporting for the first time. Because the seams already appear when I import it back without modifying it. Or maybe something goes wrong when importing a dxf.

The mess up only happens once. When I import the dxf and then export and import it again, the seams stay the same. It's not as if the seam/fault increased with every time I export it. Which is kind of weird. There seems to be a math rounding problem somehow only the first time.

Thanks for your help! Sardoc is also trying to find a fix for this. Through a hex editor he already found that there's indeed a fault in the values of a exported unmodified dxf by only 1 number. He's going to dive further into this. I will definitely keep this in mind!

Last edited by TRJTA; 07-01-20 at 06:02.
TRJTA is offline   Reply With Quote
Old 07-01-20, 07:43   #8
sapper
Member
 
sapper's Avatar
 
Joined: Sep 2007
Posts: 1,684
Default

I sent email to Turbo but I don't expect a reply.
EDIT: email address no longer valid!

Hopefully sardoc can get to the bottom of the problem.

Last edited by sapper; 08-01-20 at 05:39.
sapper is offline   Reply With Quote
Old 07-01-20, 12:42   #9
not again!
Member
 
not again!'s Avatar
 
Joined: Feb 2008
Posts: 1,145
Default

Quote:
Originally Posted by TRJTA View Post
Sardoc is also trying to find a fix for this. Through a hex editor he already found that there's indeed a fault in the values of a exported unmodified dxf by only 1 number.
Ah, that's fantastic news then. Crossing my fingers that this will be easy to fix! I love the screenshots you have posted so far in the TR3 HD Remaster thread.
not again! 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 12:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.