Reply 60 of 92, by Antonijadis
- Rank
- Member
Hmm, but for do this I don’t need tool, isn't I?
Hmm, but for do this I don’t need tool, isn't I?
I think it helps. You might have a list of 20 pairs of textures you have found to be nearly but not quite the same, and the automatically generated equiv file will contain hundreds of groups. It would be very error prone to go looking for the groups that need to be gathered together by eye.
I'm coming to the party quite late. Did I read this right: you can now capture all level bitmaps without having to play a level!!!!!!?!!?!??!?!?!?!?!?!?!
wrote:I'm coming to the party quite late. Did I read this right: you can now capture all level bitmaps without having to play a level!!!!!!?!!?!??!?!?!?!?!?!?!
YESSSSSSSS!!! 😉
I've read through this thread but am a little confused.
Could someone summarise where we've got to and what I should be doing to make my work-in-progress compatible with what's been developed here? Sorry, I don't have a lot of time a the moment!
1) Glidos understands a new type of mapping file which records how the same textures appear multiple in different levels, and how they appear in different locations in different versions of the game. If such a file is included with your mapping file then you only have to map the texture once, and it will appear in all levels, and in all versions of the game. (As a test I installed your Caves level; then I captured both Caves and Vilacabamba; then I ran the tool to generate the file; I put the file in with
yout textures, and your passport and menu letters appeared in Vilacabamba).
2) There is a tool for creating one of these new files from the Capture folder. You must capture all the levels you wish to have textures shared between before running the tool.
3) There is a tool for performing the Capture without having to play the level. Instead it reads the level file (.phd) from the CD.
Hi!
I'm Sir from Germany. You all do a beautiful job with this TRExtra project! Congratulation! It's a great idea and we need something for the time after TR Legend, i.e. in a few weeks.
I've now begin to play TR1 with the meshes of Lara in Tomb Raider 3 and it's really fantastic. But that's the only benefit. Other things doesn't work after I have changed the level file (*.phd): TRExtra and the Audio-Triggerpoints.
What do you think? Is there a way to handle this, if everyone has other phd-files?
Here the way to change the look of Lara:
1. Open level-file of TR2, 3 or 4 (*.tr2 or *.tr4) with the TRViewer of E. Popov
2. Mark Lara, in a tr4-file mark "Lara true appearance", Rightclick: Export as .TRMVB
3. Open Level-file of TR1 (*.phd)
4. Mark Lara, Rightclick: Import of .TRMVB, only meshes
5. Save new phd-file and replace the original on the CD, i.e. burn a new one
Disadvantages:
- TRExtra and Audiotriggerpoint don't work anymore
- old savegames don't work (but new ones can be made)
- if phd-file is to big (?): back to the menu of tr1. This happen, if you replace to many animals or enemies
- tr4-meshes are managed in another way. If you import them, the figures have no joints
- textures sometimes need a little finetuning, even if they are the originals of the meshes, see for example the "motheaten" wolf
Some pics:
http://img228.imageshack.us/img228/7371/lara3level17sv.jpg
http://img313.imageshack.us/img313/7412/lara3zuhause0zj.jpg
http://img156.imageshack.us/img156/8137/lara40no.jpg
Have fun!
Sir
Try using the capture tool on the level, once before making your changes, and once after, and then compare the two capture folders. Really the only way that Glidos's texture override could stop working is if the textures have inadvertently been changed.
Hi!
Thanks!
I will try it with the capture tool. Would be fine to play with hi-resolution textures and a Lara with more polygons.
Sir
OK, I had a little time to look at this and I'm still confused.
I've created a huge EQUIV file from captured folders for the entire game.
How does this work with LINK files? How does this work with my unique folder structure?
An example: I have a texture for Lara's shorts in the caves level. It's in a folder such as
...glidos\textures\trx\common\lara\shorts.png
I release it in a stand alone pack just for the caves level
I later release a level for vilcabamba.
I don't want to re-release the shorts.png -- and as you're saying the equiv file I generated will automatically map the shorts file to my new shorts image, I don't see how this works...?
Still confused...
Also, does this mean that if I want to utilise the benefit of auto-texture assignment (offered by the equiv.txt file) for the ENTIRE GAME -- I can only do that If I texture the entire game and release it as one massive texture pack?
Still confused...
And, if I now have an equiv file for the entire game, doesn't this make LINK files somewhat redundant?
Still confused...
If link files are redundant (in terms of pointing to a duplicate texture), how does the image assignment work? Where do I put my texture?
If I replace Lara's eye in level 14 and supply the equiv file, I assume the new eye appears in all levels? How about if I place it level 2 instead? Does it matter where -- is Glidos looking in all folders for the image and then using that in all EQUIVVED folders? Isn't that inefficient?
So many questions! Sorry -- just trying to get my head around this and the best way to proceed.
Trying this out with a complete set of captured folders, and I can't get anything at all.
I have a simple mapping file in my textures folder. Just has this as contents:
GLIDOS TEXTURE MAPPING
ROOT: F:\Projects\Tomb Raider Xtra\Captures_TR_COMBINED\
I also have my equiv.txt file in the glidos\textures folder.
The entire set of captured folders is at the location specified in my mapping file above.
I have placed the cover of the passport in the folder for the title PHD. This is the last folder specified by this equiv block:
BeginEquiv
01E61BCD39E5DDC9F388E9E80E635BB3\(144--216)(0--96)
6C7FE41E229619C7ACDED8A8538E3F4E\(0--72)(0--96)
7E5129F80DD26B3F59CEA33D1BFC2AC2\(72--144)(0--96)
6374D96404C7A58754EFD0E7683320E8\(0--72)(136--232)
254A33F673C61075798CEFB512F5B4FA\(72--144)(96--192)
3F792A91CFE4648E8F27C55D48CB5845\(144--216)(0--96)
D567BDDB4027A1932F2B1DE209129038\(72--144)(160--256)
784A660713A514E8962531BB00199AB1\(72--144)(96--192)
2ABC577425F24115842D9228B9FA18AA\(144--216)(0--96)
D18304C9097376209CFF2F8E26288C22\(64--136)(96--192)
7CA502BF24FF36AE4BA3280955768322\(144--216)(0--96)
AFBA022AD4696FE41D9B0E488CED5B18\(144--216)(0--96)
E67BB360AC246FFCB7253DB0939C9266\(0--72)(0--96)
8CC22AAA7DBC6F28B3473517DE5BB446\(64--136)(96--192)
BD3BBCAAC1743848331C500384DC4626\(72--144)(96--192)
66562D1E7F1C6C0E7821900D8EC38DEB\(72--144)(96--192)
6018E6431FA65017D0F703FC8E60D589\(0--72)(88--184)
EndEquiv
I have tested this with Glidos 1.33RC5 and I get no new passport image. I've tried it by switiching modes using F4 and still no joy.
What am I doing wrong? Does the image file need to be in the first named folder in the equiv block?
I think there's something wrong with using a root mapping file with ONLY root command in it. If I move the all the captured folders into the textures folder and delete the root mapping file, Glidos does read in the captured BMPs (you can tell because the transparent parts are cyan when captured using the new tool).
However, despite this, it's still not displaying my passport image. I also get graphical bollocks all over the screen when entering the passport within a level -- lost of flickering of bits of different texture obscure the level, much like Anton complained about.
Is this because there are multiple copies of the same tiles spread over all the folders, regardless of the fact the equiv file knows about them?
Still confused...
OK, giving up for now. Can't do any more without some answers. Hope someone can help!
OK, so I worked out at least the following:
1) A duplicated texture must be in the first folder specified in a beginEquiv/endEquiv block
2) All other copies of the texture must be deleted to avoid graphical weirdness
3) Equiv files seem to ignore root mapping files -- major problem!
So, in reality, equiv files are useless for stand-alone level releases. I'm now not sure how to manage this.
How do we make a stand-alone release compatible with a future "massive pack" that has multiple levels textures and would make use of an equiv file?
Another observation based on quick perusal of the captured folders created by the new .phd extracting tool: Some textures are not extracted while others that are not required for a given level ARE extracted (for example, Lara's track suit from the house level appears in the complete BMP for lots of levels but is never used).
There will still be significant cleaning up I feel.... 😉
wrote:OK, I had a little time to look at this and I'm still confused.
I've created a huge EQUIV file from captured folders for the entire game.
How does this work with LINK files? How does this work with my unique folder structure?
It is independent of folder structure. When an equiv file shows a set of equivalent textures, your mapping system needs map just one of the set, and the rest will appear automatically.
An example: I have a texture for Lara's shorts in the caves level. It's in a folder such as […]
An example: I have a texture for Lara's shorts in the caves level. It's in a folder such as
...glidos\textures\trx\common\lara\shorts.png
I release it in a stand alone pack just for the caves level
I later release a level for vilcabamba.
I don't want to re-release the shorts.png -- and as you're saying the equiv file I generated will automatically map the shorts file to my new shorts image, I don't see how this works...?
Still confused...
Not sure exactly what you want to do. The point is that, your caves level pack, when the equiv file is present, will make the shorts appear in the vilacabamba level.
wrote:Also, does this mean that if I want to utilise the benefit of auto-texture assignment (offered by the equiv.txt file) for the ENTIRE GAME -- I can only do that If I texture the entire game and release it as one massive texture pack?
You can release separate level packs, but use of the equiv file will mean the pack for one level will cause partial texturing of other levels.