Tom Clancy's Ghost Recon *.map / *.chr / *.qob

[mrmaller1905]

What are *.map / *.chr / *.qob from Tom Clancy's Ghost Recon and can someone take a look at these file formats? Can't find a proper tool to handle these file formats. Thanks in advance.

 

https://drive.google.com/drive/folders/1VwecNnNPwqu43Vz20Gv73ppM4JAnI8L7?usp=sharing

[Anti6]

Hi,

QOB = models(https://www.ghostrecon.net/html/export.htm)

RSB = texture files(https://www.ghostrecon.net/files2/index.php?act=view&id=1074)

CHR = character models(https://www.ghostrecon.net/forums/index.php?/topic/16699-skinning-resource-center/)

MAP = map model - might be able to view it the same way for QOB files since the format seems very similar.

[mrmaller1905]

2 hours ago, Anti6 said:

Hi,

QOB = models(https://www.ghostrecon.net/html/export.htm)

RSB = texture files(https://www.ghostrecon.net/files2/index.php?act=view&id=1074)

CHR = character models(https://www.ghostrecon.net/forums/index.php?/topic/16699-skinning-resource-center/)

MAP = map model - might be able to view it the same way for QOB files since the format seems very similar.

GhostRecon.net forum post contains outdated links. Can someone make a Blender or Noesis plugin to import CHR or QOBs or MAPs?

Edited October 23 by mrmaller1905

[Bigchillghost]

Why is somebody nowadays frequently demanding someone to make a tool for them, as if it doesn't require the slightest effort? A fellow like that is either too naive or a total egoist.

[shak-otay]

Yay, but what really bothers me is that he gives very little to no feedback once you have helped him.

(But in some way he helps keeping the forum alive.)

[Bigchillghost]

On 10/23/2024 at 11:17 PM, shak-otay said:

but what really bothers me is that he gives very little to no feedback once you have helped him.

It's very nice of you, to keep helping people regardless of their bad reputations. I for one will not hesitate to put them in my black list.

On 10/23/2024 at 11:17 PM, shak-otay said:

But in some way he helps keeping the forum alive.

I wouldn't exactly call that a contribution. Instead, I see no necessity for the forum to exist when it is full of requests like these. And unfortunately, seems this new forum is at struggling for its sustainability. Yet another tragedy on the back of xentax and forums alike.

[shak-otay]

59 minutes ago, Bigchillghost said:

And unfortunately, seems this new forum is at struggling for its sustainability. Yet another tragedy on the back of xentax and forums alike.

Well, it worked rather good for a year or so, imho.  Maybe there's more operation on the discord (will check it now) but discords usually don't meet my expectations.

edit: well, can't login. (Seems a higher power wants to protect me from wasting more time with 3D;-)

Edited October 25 by shak-otay

[mrmaller1905]

On 10/23/2024 at 4:57 PM, Bigchillghost said:

Why is somebody nowadays frequently demanding someone to make a tool for them, as if it doesn't require the slightest effort? A fellow like that is either too naive or a total egoist.

Can you analyze this file format in *.chr or *.map from Tom Clancy's Ghost Recon?

[Bigchillghost]

On 10/25/2024 at 8:03 PM, shak-otay said:

Well, it worked rather good for a year or so, imho. 

Was talking about the fundraising for the forum hosting cost.

On 10/30/2024 at 3:44 PM, mrmaller1905 said:

Can you analyze this file format in *.chr or *.map from Tom Clancy's Ghost Recon?

Capable maybe, but I will not. So help yourself.

[Anti6]

So, I do not have a lot of experience with 3d models, and that is a understatement. But I put this script together, it unpacks the first map(m01_caves), I am not slogging or testing a second map, all characters and weapons. It does so horribly, only some vertices I could identify get written to the .obj with some faces, there is no normals or uv's in the files. Everything else is in the txt file. Hope this helps you. Good luck.

MAP_convert.py CHR_convert.py QOB_convert.py

Edit: I was bored, but I can not feed anybody any answers, I am still learning, have fun with it.

Edit2: this script is standalone, it does not work with neosis nor blender.

Edited November 4 by Anti6

[shak-otay]

Nice.☺️

m02_farm

(Got an error, though:

Quote

python map_convert.py m02_farm.map
Traceback (most recent call last):
  File "map_convert.py", line 778, in <module>
    save_metadata(file_path, output_path)
  File "map_convert.py", line 635, in save_metadata
    outermap_word7 = f.read(outermap_word7size).decode('utf-8').strip('\x00')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 168: invalid start byte

 

[mrmaller1905]

3 hours ago, Anti6 said:

So, I do not have a lot of experience with 3d models, and that is a understatement. But I put this script together, it unpacks the first map(m01_caves), I am not slogging or testing a second map, all characters and weapons. It does so horribly, only some vertices I could identify get written to the .obj with some faces, there is no normals or uv's in the files. Everything else is in the txt file. Hope this helps you. Good luck.

MAP_convert.py 45.89 kB · 2 downloads CHR_convert.py 20.62 kB · 2 downloads QOB_convert.py 16.5 kB · 2 downloads

Edit: I was bored, but I can not feed anybody any answers, I am still learning, have fun with it.

Edit2: this script is standalone, it does not work with neosis nor blender.

I tried MAP_convert.py you've written but m03_rrbridge.map and other map models won't fully convert OBJs including full map models. Weapon models contain bad normals or UVs. Can anyone look forward to fixing bad normals or UVs in weapon or character models and including full map model support?

[Anti6]

@shak-otay, yeah. I only looked at the first map. The map file has some issues I currently don't have time to figure out. Maybe later when I get some more time. @mrmaller1905, yes. I do believe I said that in my post. If you want to have it fixed check the accompanying txt file and have the normals and uv's added to the obj by editing the script. Else maybe someone else can do it. I couldn't figure it out. M01, does fully convert. I did not and am not going to do the others at this time. I made it because I wanted to tinker, you can use the script to adapt to the other files. I am sure its just some variables that need to be altered. Btw, the map script unpacks everything. All three file types are quite similar, weapons are the least complicated and a good starting point if you want to try and figure out the normals. 

[shak-otay]

I used QOB_convert.py with squirrel.qob and it missed a sub mesh while CHR_convert.py gave the full mesh.

Didn't check other QOBs but is there a need to have a separate QOB py script?

[Anti6]

So, not really no, I wrote the QOB first, then adapted it to the CHR, then adapted it to MAP as all three files are very similar in structure. In essence, you should be able to use the MAP to open all three types of files. I was originally only going to send the map one, and added the other 2 on impulse, then proceeded to immediately forget to explain that the other 2 are kind of like older versions of the map file.

[Anti6]

I also learned stuff in the CHR that didn't make sense in the QOB and more stuff in the MAP that didn't make sense in the other 2. So in summary, the scripts can be called QOB=Rev1, CHR=Rev2, and MAP=Rev3. Sorry for not explaining in the original post. I should have waited and posted it today when I had time to think about it and type it out properly.

Edit: the QOB.py inserts what I originally thought were UV's and normals. This was removed in the other 2, because it was wrong.

Edit2: Some QOB's such as Debris1, has faces different to others, which opens correctly with the QOB.py and not with the CHR.py and MAP.py 

Edited November 5 by Anti6

[michalss]

On 10/25/2024 at 1:20 PM, Bigchillghost said:

It's very nice of you, to keep helping people regardless of their bad reputations. I for one will not hesitate to put them in my black list.

I wouldn't exactly call that a contribution. Instead, I see no necessity for the forum to exist when it is full of requests like these. And unfortunately, seems this new forum is at struggling for its sustainability. Yet another tragedy on the back of xentax and forums alike.

If you think the forum is being misused, then report it. Please don't bring a new Xentax(discord) philosophy here. I've said it many times: people ask questions, and others may or may not answer. We are not pushing anyone to help. If I see that the forum no longer makes sense, it will be closed down. The real issue I see is not giving people credit, which is a huge red flag for me, and I will take strict action against it. On the other hand, if you think this place could be improved, apply to be a moderator and help make it better. I would be more than happy to give you a moderator role to help us out.

 

[Anti6]

I updated the script.

It unpacks all QOB, CHR, and MAP files into working .obj files.

There are no normals or UVs, I don't know if someone can take a look at the '.txt' files that get generated and advise me if they see any normals or UVs.

The script should now be much easier to read and follow.

The MAP02 and MAP03 files do have an error, but that is at the end of the file and doesn't have any vertices that are used in the .obj files.

I can't figure out the logic to unpack the complete file for those two, but I'll work on it when I have time.

Meanwhile, if anyone can figure out what the rest of the vertices/float values are I can update the script, and learn something new along the way as I am still quite new to 3D models.

Ghost Recon_convert.py

[shak-otay]

Thanks!

For the squirrel.qob I'd expect the uv data between 0x1AC9 and 0x2721. Maybe there's normals, too. But whatever block division I chose, I never got proper uvs.

Looked flat, though.

At 0x1AC9 a normals block should start, I guess (looks like a sphere, 97 normals?).

Values changed at line 8 here (due to the 0.5 values I assumed a block size of 16 bytes, for example, at no avail):

v 0.133421 -0.192219 0.002577
v 0.078443 0.017889 0.219733
v 0.165537 -0.163877 0.022313
v 0.165537 -0.163877 0.022313
v 0.068816 0.060892 -0.215204
v 0.068816 0.060892 -0.215204
v 0.040640 0.625209 0.005528
>> v 0.500000 0.069918 0.559802
v 0.261893 0.838415 0.298645
v 0.828938 0.266105 0.784533
v 0.285545 0.554545 0.291278
v 0.500000 0.324709 0.557350
v 0.218080 0.500000 0.171499
v 0.568402 0.157533 0.500000
v 0.473919 0.718812 0.308615
v 0.731172 0.441933 0.767198
v 0.564355 0.754913 0.524088
v 0.810204 0.445051 0.870130
v 0.213480 0.664258 0.136362
v 0.633494 0.082787 0.500000
v 0.484894 0.500000 0.598268
v 0.500000 0.488123 0.570330
v 0.356580 0.561454 0.407168
v 0.500000 0.423783 0.559870
v 0.190656 0.756200 0.118097
v 0.876329 0.148382 0.877229
v 0.119203 0.747856 0.003974
v 0.805350 0.320963 0.661032

Edited November 7 by shak-otay

[Anti6]

That's exactly where I thought the Normals and UVs were as well, in the original QOB_unpack, and all others to be honest, I wrote the script to skip the faces, write the normals and UVs, then go back to write the faces. What is very odd, is that there is 2 pairs of face data as well. That section is 158 (0x9e) of  5 floats( FVF size of 20), I tried it every way I could for the normals, 1 2 3, 1 3 2, 3 1 2... up to 5 4 3, did not try negatives though as that would increase the variations to more than 300 and I just couldn't get myself to sit through that, but no matter how I did it I just couldn't get them to work. I am definitely missing something and it's like having something stuck in my teeth I just can't get out. There is another section starting at 0x5f9, that one is FVF size of 16, and has 190 lines. Though there are only 97 vertices, which is weird to me. Not sure if a .obj can have more normals/UVs than vertices? Though the second pair of faces does match the section you are referring to in maximum face size, The face section starting at 0x11d0 has to be split in two, first half matches the vertices, second one does not. But does match the section thereafter in size.

Edited November 7 by Anti6
Extended explanation regarding face section.

[shak-otay]

1 hour ago, Anti6 said:

Not sure if a .obj can have more normals/UVs than vertices?

I think it can.  But I'm lacking an example atm.

edit: found an explanation but it's somehow beyond my imagination...

[Anti6]

@shak-otay That gives me an idea, how does this model look?

squirrel_1.zip

Edit: This looks to have fixed the normals to my eyes?

ica_us_demolition_1.zipGhost Recon_convert.py

Edited November 8 by Anti6
Added @

[Anti6]

I am trying to find the UV's now, and got tired of looking for something to convert the rsb files.......... sooooooooo

rsb_converter.py

Works as far as I can see.

 

Edited November 8 by Anti6

[h3x3r]

Here's noesis python script for *.rsb

from inc_noesis import *
import noesis
import rapi
import os

def registerNoesisTypes():
   handle = noesis.register("Ghost Recon", ".rsb")
   noesis.setHandlerTypeCheck(handle, noepyCheckType)
   noesis.setHandlerLoadRGBA(handle, noepyLoadRGBA)
   noesis.logPopup()
   return 1
        
def noepyCheckType(data):
   bs = NoeBitStream(data)
   if len(data) < 20:
      return 0
   return 1
   
def noepyLoadRGBA(data, texList):
    bs = NoeBitStream(data)
    baseName = rapi.getExtensionlessName(rapi.getLocalFileName(rapi.getInputName()))
    bs.read(4)
    TexWidth = bs.readUInt()
    TexHeight = bs.readUInt()
    bs.read(12) 
    TexPixelFormat = bs.readUInt()
    
    if TexPixelFormat == 4:
        bs.TexSize = TexWidth * TexHeight *2 # b4g4r4a4
        print("Pixel Format > b4g4r4a4")
    elif TexPixelFormat == 0:
        bs.TexSize = TexWidth * TexHeight *2 # b5g6r5a0
        print("Pixel Format > b5g6r5a0")
                    
    data = bs.readBytes(bs.TexSize)
    if TexPixelFormat == 4:
        data = rapi.imageDecodeRaw(data, TexWidth, TexHeight, "b4 g4 r4 a4")
        texFmt = noesis.NOESISTEX_RGBA32                        
    elif TexPixelFormat == 0:
        data = rapi.imageDecodeRaw(data, TexWidth, TexHeight, "b5 g6 r5 a0")
        texFmt = noesis.NOESISTEX_RGBA32           
    texList.append(NoeTexture(rapi.getInputName(), TexWidth, TexHeight, data, texFmt))
    return 1

 

[shak-otay]

Thanks to both of you! Checked both scripts with m01_sandbags.rsb - similar result.

(Sadly I don't have  a rsb file for the squirrel...)