Important information: this site is currently scheduled to go offline indefinitely by end of the year.
3D Model Researcher - extract 3D models with Python
Re: 3D Model Researcher - extract 3D models with Python
hey man, I am just wondering, is model researcher safe?
-
Lazov
- veteran
- Posts: 84
- Joined: Sat Oct 08, 2016 11:56 am
- Has thanked: 17 times
- Been thanked: 55 times
Re: 3D Model Researcher - extract 3D models with Python
Safe in what sense? It's just a small program.
Re: 3D Model Researcher - extract 3D models with Python
I also bought the professional version, but I'm not familiar with the usage. I also tried to analyze some simple but complex ones. The big brother is very busy and doesn't reply to my case email...
-
Lazov
- veteran
- Posts: 84
- Joined: Sat Oct 08, 2016 11:56 am
- Has thanked: 17 times
- Been thanked: 55 times
Re: 3D Model Researcher - extract 3D models with Python
You should expect the Pro version update, which will include new features from the free version update.
I'm not working on support for skeletal animation yet. I only worked with one type of skeletal animation format from one game. More examples are needed to add support.Re: 3D Model Researcher - extract 3D models with Python
Hi, i really need help i try learn the program but its to complicated for my, i read the tutorial form de page, i view the video tutorials buts whit the archive to i try to extrat its not work, i really need help 
https://www.mediafire.com/file/t8uk0mbo ... 1.pmf/file
if can explain me how use, with that archive i really appreciate it very much.gif "Smile")
Sorry for my bad english
https://www.mediafire.com/file/t8uk0mbo ... 1.pmf/file
if can explain me how use, with that archive i really appreciate it very much
Sorry for my bad english
-
gpktm
- beginner
- Posts: 29
- Joined: Mon May 17, 2010 9:58 pm
- Has thanked: 5 times
- Been thanked: 3 times
Re: 3D Model Researcher - extract 3D models with Python
If I select Integer or Short I am getting a "Mismatch of Faces and Vertices". Is there still a possibility of a combination between the Padding and Pad Inter to solve this or does it mean that automatically I need to choose "Bytes" for my faces?
-
Lazov
- veteran
- Posts: 84
- Joined: Sat Oct 08, 2016 11:56 am
- Has thanked: 17 times
- Been thanked: 55 times
Re: 3D Model Researcher - extract 3D models with Python
Unfortunately, due to the global situation, I can no longer sell the Pro version of the program. I removed all links from the site.
Will the Pro version be free? Most likely yes, because the situation will not change in the near future.
In addition, I now have very little free time that I can devote to the development of the program.
-
Sparagas
- beginner
- Posts: 25
- Joined: Thu Feb 18, 2016 7:57 pm
- Has thanked: 3 times
- Been thanked: 7 times
Re: 3D Model Researcher - extract 3D models with Python
If you are really gona do it free and don't have free time, maybe you could make it open source and post it in GitHub? Maybe someone will try to improve it.Lazov wrote: ↑Sat Sep 17, 2022 7:48 pmUnfortunately, due to the global situation, I can no longer sell the Pro version of the program. I removed all links from the site.
Will the Pro version be free? Most likely yes, because the situation will not change in the near future.
In addition, I now have very little free time that I can devote to the development of the program.
-
Machinedramon
- advanced
- Posts: 77
- Joined: Mon Apr 08, 2019 6:13 pm
- Has thanked: 13 times
- Been thanked: 42 times
Re: 3D Model Researcher - extract 3D models with Python
That would be certainly interesting. I would totally be interested in learning how the program works and if possible work on few things, had been using the program for quite some time and i find it one of the most versatile when working with 3d models....
If made open source that would allow for many interesting developments and features.
If made open source that would allow for many interesting developments and features.
-
Lazov
- veteran
- Posts: 84
- Joined: Sat Oct 08, 2016 11:56 am
- Has thanked: 17 times
- Been thanked: 55 times
Re: 3D Model Researcher - extract 3D models with Python
Maybe in the future. This would be useful if some developers would like to work on the project.
What would you like to improve?
Recently, I figured out one format of models from animations. So I'm thinking of adding skeletal animation support. In addition, part of the work is already done.
-
Sparagas
- beginner
- Posts: 25
- Joined: Thu Feb 18, 2016 7:57 pm
- Has thanked: 3 times
- Been thanked: 7 times
Re: 3D Model Researcher - extract 3D models with Python
Well, Pro version is not up to date with Free version. Version numbering for Free/Pro is inconsistent.
There are no release/update notes. I have to look in the forums, what's new was added.
Rename data types. Like Half-Float and Short_Signed. One with "-" and the other with "_". Preferably it should be with " ". Also, it Should be Singed Short and not Short Signed. And what TStripFF means?
Silent Hill 1 has a weird buffer: the first buffer is XYXYXYXYXYXY... and then there is a buffer ZZZZZZ...1
It would be awesome to add a way to read it here.
A way to read info from separate files.
Add vertex colors.
Maybe add export to other file formats, like glTF.
-
Machinedramon
- advanced
- Posts: 77
- Joined: Mon Apr 08, 2019 6:13 pm
- Has thanked: 13 times
- Been thanked: 42 times
Re: 3D Model Researcher - extract 3D models with Python
well... ideas, i have been talking with another friend that also uses mrp for researching 3d models from games and have compiled a set of things we think might be important, ill mark with bold the most important ones though. here i go:
-multi uvs in containers and support for the python api to auto generate the content(this means that when saving as a .obj that every uv channel gets saved into a new mesh, because .obj has no support for multi-uvs)
-add more information in comments for 3d models from either the python api or the program import(mainly stuff like data of save and origin of the file would be a plus, many times working on long worked projects id like to know the original place and it be hard to recall 100 files)
-autogenerate faces in the program and also automethod for the python api(similar to how hex2obj and AXE)
-vertex color/vertex weights(as said from the other guy, being able to see the vertex color is a very important part given so many games use vertexcolor as a way to split the meshes, and having to code a full python script just to test be a bit annoying)
-(probably hard to implement but would be najs to have: vertex numbering in render; this would be useful to debug how face indexes work)
-interface editor for color, specially the text/hex; moreover being able to save the settings into a specific file that would work as a theme file that could be interchangable and shareable(themes pls?)
-Struct tab where to put information regarding all the different parts and make a bit of a structure before tackling any file(where you can asign colors sizes and padding for different stuff, how to read the header, where the pieces of information regarding sizes offsets and all the other stuff is)
-More colors, more forms to mark stuff in the hex viewer(if there is gonna be stuff like more uvs, also if possible being able to see what is x,y,z, what is u,v and all the other stuff the better, or at least have the possibility to check such stuff if you wanted to)
-Hex viewer rezising tool with different strides(very important to check on how stride pattern works without needing to check every single time in hxd)
-non blocking files, but maybe doing something like cache'ing the data or just making a prompt if the file gets edited by other application(this be important cause sometimes when working on a file from different editor at a time mrp always creates a conflict and requires cloning the file only for the purpose of being able to use the same information at the same time)
-being able to work with more information than just 2 windows at a time, changing the tabs to docking mode if possible(being able to read hex and inputing the places while checking the 3d at the same time would be great, same goes for the pipeline when working on uvs)
-being able to save into other formats(this will be specially hard given how stuff works regading FBX, but maybe CSV would be nice to have; moreover as said before there are many other file formats that could be nice to at least leat people implement)
-multi file working for separated vertexes from faces or any other data(as said before from the other user, not all games have the formats where all the information is stored in 1 file, many use multi file and its a bit annoying when you dont know exactly which file is the one that matches to copy paste, reopen mrp test and do it over and over again, in cases like PGR it could be around 100 files for 1 model...)
-more data types, and also a rework of the existing ones; first of all, many of them, as the guy before said, have bad naming, i dont remember now if the different shorts have been fixed, but at the time there was some problem with uvs using shorts, not to mention many games use formats that are not even here or even possible to read, like for instance int10 that is to be found in xbox360 games, also formats like bit jumps for faces(yes in ps2 in some games you can find that the sequence for the faces might be defined by using a bit to declare if there is a jump or not; although this one might be kinda hard cause its not as simple as if its a 1 is okay and 0 jump... but i guess if there is a way to implement something that can be scripted would be nice); btw, what is that in UVS tab that there is "invert X Y Z"??? if something needs to be corrected to U and V...
-regarding the data read there are also something more that can be really important is both scaling and positioning, not all games give you the information directly where it is suposed to be or the scaling factor, bear in mind that scaling is not always uniform in all the coordinates, so having a scaling factor for each xyzuv would be best to have, in UVS is quite normal to find scalling values in 6th/7th gen consoles. Position probably having 1 set of of XYZ like 1 vertex that translates the pivot of the mesh should be okay, also normal to be found in meshes that are super big(like maps).
-Texture render tab, here there are a lot of things that need fixing, first of all, everything rendered does not go over 1,1 which means it overlaps other stuff and doesnt help visualize how tiled textures work properly, besides that, why not make the whole window 1 uniform color? adding a grid to understand the size of things would also be great, and being able to pan around and zooming if possible
-turn the "flip" function off as default, it is quite common to do things wrong because that thing is on from default and specially for new users that are not accostumed to it might find it problematic at first
-zlib decomping method needs a proper rework, either that you are able to unpack inside the file itself the compressed values or just being able to duplicate the file with a proper decomped segment while keeping the header and other stuff, if possible to add a "scan" for 78 01/78 5E/78 9C/78 DA/78 20/78 7D/78 BB/78 F9 would be great mainly cause for many people that are not that used to working with compressed files might find it hard to even see where the compressed values begin
-auto save option both for python and the current data; there have been sooo many times that i have been working for hours on some file for the program to hang and break without even a warning that i cannot save what i was working on and gotta do it all back again from memory, not even loading mrp in ram helps snipeting the code
-the open file dialog not in mrp folder but last opened(save direction to some variable in a sheet in the mrp folder)
-also a language translation file by doing a database with all the information regarding the variables would be nice to have
-in real time connection between data from mrp and python api for being able to call both of them from one another; many times i have this trouble where i need to know the name of a file or the directory it is in while working on python script while i was testing on mrp, yeah i know i can use open(file.dat, 'r') and then call the directory using glob.glob() and all that shit, but why not just let it all be called through mrp.get_bfile()???; moreover, if i am testing a file and i cannot find faces and need to do some code snippet, why cant i not just go and call the vertexes already rendered in mrp through mrp.get_mesh(root) or something like that? would be nice to have
-input() from python being allowed with a prompt in windows, also a key interrupt escape would be so welcomed, not everyone that works on this is a programer and making mistakes like infinite whiles or reading stuff wrong makes some scripts hang in the run process, thus having a way to stop the code like how in python ctrl + C stops it
-multi uvs in containers and support for the python api to auto generate the content(this means that when saving as a .obj that every uv channel gets saved into a new mesh, because .obj has no support for multi-uvs)
-add more information in comments for 3d models from either the python api or the program import(mainly stuff like data of save and origin of the file would be a plus, many times working on long worked projects id like to know the original place and it be hard to recall 100 files)
-autogenerate faces in the program and also automethod for the python api(similar to how hex2obj and AXE)
-vertex color/vertex weights(as said from the other guy, being able to see the vertex color is a very important part given so many games use vertexcolor as a way to split the meshes, and having to code a full python script just to test be a bit annoying)
-(probably hard to implement but would be najs to have: vertex numbering in render; this would be useful to debug how face indexes work)
-interface editor for color, specially the text/hex; moreover being able to save the settings into a specific file that would work as a theme file that could be interchangable and shareable(themes pls?)
-Struct tab where to put information regarding all the different parts and make a bit of a structure before tackling any file(where you can asign colors sizes and padding for different stuff, how to read the header, where the pieces of information regarding sizes offsets and all the other stuff is)
-More colors, more forms to mark stuff in the hex viewer(if there is gonna be stuff like more uvs, also if possible being able to see what is x,y,z, what is u,v and all the other stuff the better, or at least have the possibility to check such stuff if you wanted to)
-Hex viewer rezising tool with different strides(very important to check on how stride pattern works without needing to check every single time in hxd)
-non blocking files, but maybe doing something like cache'ing the data or just making a prompt if the file gets edited by other application(this be important cause sometimes when working on a file from different editor at a time mrp always creates a conflict and requires cloning the file only for the purpose of being able to use the same information at the same time)
-being able to work with more information than just 2 windows at a time, changing the tabs to docking mode if possible(being able to read hex and inputing the places while checking the 3d at the same time would be great, same goes for the pipeline when working on uvs)
-being able to save into other formats(this will be specially hard given how stuff works regading FBX, but maybe CSV would be nice to have; moreover as said before there are many other file formats that could be nice to at least leat people implement)
-multi file working for separated vertexes from faces or any other data(as said before from the other user, not all games have the formats where all the information is stored in 1 file, many use multi file and its a bit annoying when you dont know exactly which file is the one that matches to copy paste, reopen mrp test and do it over and over again, in cases like PGR it could be around 100 files for 1 model...)
-more data types, and also a rework of the existing ones; first of all, many of them, as the guy before said, have bad naming, i dont remember now if the different shorts have been fixed, but at the time there was some problem with uvs using shorts, not to mention many games use formats that are not even here or even possible to read, like for instance int10 that is to be found in xbox360 games, also formats like bit jumps for faces(yes in ps2 in some games you can find that the sequence for the faces might be defined by using a bit to declare if there is a jump or not; although this one might be kinda hard cause its not as simple as if its a 1 is okay and 0 jump... but i guess if there is a way to implement something that can be scripted would be nice); btw, what is that in UVS tab that there is "invert X Y Z"??? if something needs to be corrected to U and V...
-regarding the data read there are also something more that can be really important is both scaling and positioning, not all games give you the information directly where it is suposed to be or the scaling factor, bear in mind that scaling is not always uniform in all the coordinates, so having a scaling factor for each xyzuv would be best to have, in UVS is quite normal to find scalling values in 6th/7th gen consoles. Position probably having 1 set of of XYZ like 1 vertex that translates the pivot of the mesh should be okay, also normal to be found in meshes that are super big(like maps).
-Texture render tab, here there are a lot of things that need fixing, first of all, everything rendered does not go over 1,1 which means it overlaps other stuff and doesnt help visualize how tiled textures work properly, besides that, why not make the whole window 1 uniform color? adding a grid to understand the size of things would also be great, and being able to pan around and zooming if possible
-turn the "flip" function off as default, it is quite common to do things wrong because that thing is on from default and specially for new users that are not accostumed to it might find it problematic at first
-zlib decomping method needs a proper rework, either that you are able to unpack inside the file itself the compressed values or just being able to duplicate the file with a proper decomped segment while keeping the header and other stuff, if possible to add a "scan" for 78 01/78 5E/78 9C/78 DA/78 20/78 7D/78 BB/78 F9 would be great mainly cause for many people that are not that used to working with compressed files might find it hard to even see where the compressed values begin
-auto save option both for python and the current data; there have been sooo many times that i have been working for hours on some file for the program to hang and break without even a warning that i cannot save what i was working on and gotta do it all back again from memory, not even loading mrp in ram helps snipeting the code
-the open file dialog not in mrp folder but last opened(save direction to some variable in a sheet in the mrp folder)
-also a language translation file by doing a database with all the information regarding the variables would be nice to have
-in real time connection between data from mrp and python api for being able to call both of them from one another; many times i have this trouble where i need to know the name of a file or the directory it is in while working on python script while i was testing on mrp, yeah i know i can use open(file.dat, 'r') and then call the directory using glob.glob() and all that shit, but why not just let it all be called through mrp.get_bfile()???; moreover, if i am testing a file and i cannot find faces and need to do some code snippet, why cant i not just go and call the vertexes already rendered in mrp through mrp.get_mesh(root) or something like that? would be nice to have
-input() from python being allowed with a prompt in windows, also a key interrupt escape would be so welcomed, not everyone that works on this is a programer and making mistakes like infinite whiles or reading stuff wrong makes some scripts hang in the run process, thus having a way to stop the code like how in python ctrl + C stops it
-
cod2enthusiast2132
- ultra-n00b
- Posts: 2
- Joined: Sat Mar 13, 2021 10:52 pm
Re: 3D Model Researcher - extract 3D models with Python
Hello everybody I am just wondering if anybody can help me extract the meshes from call of duty 2 big red one. I am working on the panzer model right now, and I have succeeded at finding the vertices at 0x3000 but the faces however I cannot find in the model itself. If anybody can please look at this mesh and see if it's even possible for me to extract it. luxox18 probably used the same method with call of duty 3 but i don't know
You do not have the required permissions to view the files attached to this post.