Synide move uv's

[Thunderbird 0]

Thanks for the interesting tool.

The only con I could find with it is the amount of parameters to adjust/predefine before merging the textures.

It would be great to further develop this tool in order to avoid to have to edit the TGAs hexadecimal codes or have to rewrite the paths as a whole.

In other words, it would be great to make this tool a pinch more user-friendly. ;]

Regards,

TB

[Snake Man 402]

It would be great to further develop this tool in order to avoid to have to edit the TGAs hexadecimal codes or have to rewrite the paths as a whole.

I just open the merged TGA image in Photoshop and save it again, works fine. Should work the same in paintshoppro(?).

[Thunderbird 0]

It would be great to further develop this tool in order to avoid to have to edit the TGAs hexadecimal codes or have to rewrite the paths as a whole.

I just open the merged TGA image in Photoshop and save it again, works fine. Should work the same in paintshoppro(?).

How didn't I think about it, cheers for the tip.

Concerning Synide's Tool, I do appreciate it but I keep using it alongside with the .PTM way since 'PaNTool' takes into consideration .PAA files as well, as it saves some time from converting .PAAs into .TGAs (Specifically when you have more than 438 textures to merge, heh).

Regards,

TB

[Snake Man 402]

Me, I'm jumping between Synide's method and pantool ptm method.

I really like Synide's method because it uses the native new p3dm mlod format editing. However I hate the nvidia atlastool as it fucks up so many times on making the merge .tai file for me, meaning the textures are all mixed up in the UV.

I like the pantool tetris puzzle when making the texture, you can choose how to place them... but I hate the fact that I need to use the old/first O2 export version to save into old p3d format, then use old o2 to do the merge and back to new O2PE again to finish it up with rvmats etc.

In a nutshell, if the atlastool would work OK then I would absolutely only use the Synide moveUV method alone. Right now I'm doing so as long as atlastool makes proper .tai file

[Thunderbird 0]

Indeed, for the same reasons, I keep using PaNtool.

Quote[/b] ]I like the pantool tetris puzzle when making the texture, you can choose how to place them... but I hate the fact that I need to use the old/first O2 export version to save into old p3d format, then use old o2 to do the merge and back to new O2PE again to finish it up with rvmats etc.

By the way, I experienced a little issue I would like to get some information about if you don't mind:

- If you have a model with 'Already Applied .rvmat' files (Linking to .rvmat files) and that you would like to get it have merged textures:

- Would you replace the .rvmat paths by nothing? [in oder words: Would you get ride of the .rvmat files and apply them later?]

- Would you attempt to merge the normals? [Knowing that it is almost impossible since every .rvmat file takes into account a texture as a whole].

Regards,

TB

[vektorboson 8]

Hi guys;

I'm doing something similar for OFP (see Flashpoint Germany-thread), and I'm planning to use the Texture Atlas-tool, too. But I'm not using DDS utilities, but ImageMagick (specifically convert.exe). It can apply many transformations/filters and has many input/output formats (I'm using it to convert DDS to TGA/PNG), and it has the advantage that you're allowed to redistribute it.

Quote[/b] ]

In a nutshell, if the atlastool would work OK then I would absolutely only use the Synide moveUV method alone. Right now I'm doing so as long as atlastool makes proper .tai file

Could you explain, in which way it doesn't work (as I may find the same problems)?

[Snake Man 402]

Quote[/b] ]- If you have a model with 'Already Applied .rvmat' files (Linking to .rvmat files) and that you would like to get it have merged textures:

Well as much as I understand texture merging its only because 1) your porting OFP model. 2) some weirdo made ArmA model with many textures.

Heh, of course there is many situations, but its quite common that texture merging only happens on OFP ported models. Anyways...

Quote[/b] ]- Would you replace the .rvmat paths by nothing? [in oder words: Would you get ride of the .rvmat files and apply them later?]

I would think that if you merge 2 (or more) textures, you just create brand new _NOHQ and _SMDI textures for the new merged one(?), therefore you can just skip the old rvmats completely. Thats as far as I understand it.

Quote[/b] ]- Would you attempt to merge the normals? [Knowing that it is almost impossible since every .rvmat file takes into account a texture as a whole].

Yeah as I said, just make new _nohq/_smdi as its much easier.

Quote[/b] ]Could you explain, in which way it [atlastool] doesn't work (as I may find the same problems)?

Actually Synide could explain it more detailed (Synide: the vte_sampanbig demo model, tai.pdf, remember?). But in a nutshell the merged texture pieces or their coordinate information is not in proper locations on the .tai file, therefore synMoveUV.exe does its job on wrong .tai information, resulting a model that has the texture information mixed up.