There are tools like OGLE which often fail and there is 3DRipperDX which is for DirectX. Both of these never get stuff in t-pose. There is also GameAssassin which I've heard does amazing stuff but is not free and has some very odd payment method, plus it's not completely translated to english.
Has anyone ever thought of making a program like this himself?
I use Python so I could probably use PyOpenGL. However I have no idea how this can be done. You would need to "inject" the ripper to the game, but how would you access the stuff it sends to the GPU? I have no idea.
I guess it would be possible to get t-posed geometry if the skinning is done on the GPU for that game, not on the CPU by the game engine.
I make games, but this is totally different. I never needed to know if you can get stuff sent to the GPU, etc.
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
how about making an OpenGL ripper?
-
- ultra-veteran
- Posts: 423
- Joined: Mon Aug 11, 2008 11:30 pm
- Has thanked: 27 times
- Been thanked: 15 times
Re: how about making an OpenGL ripper?
To a format which almost nothing opens, almost never gets textures right and of course never manages to get the t-posed geometry.
If I knew where to look, I'd give it a shot myself, but there doesn't seem to be any documentation on accessing stuff in the GPU anywhere.
If I knew where to look, I'd give it a shot myself, but there doesn't seem to be any documentation on accessing stuff in the GPU anywhere.
-
- Moderator
- Posts: 1007
- Joined: Mon Mar 23, 2009 2:57 am
- Has thanked: 44 times
- Been thanked: 505 times
Re: how about making an OpenGL ripper?
All you'd need to do is create an opengl32.dll wrapper and put your own hooks in to override draw calls and pull data out of the bound buffers. (and accumulate your own data for immediate mode drawing, and store VBO handles locally, and possibly some other stuff) This would get you T-pose data minus bones/weights for any game that does skinning in a vertex shader, assuming it's feeding a T-pose in and isn't doing skinning in joint-local space. Getting texture data is just as easy, all you'd need to do is keep track of uploaded textures in your wrapper and you can dump them at any time. If you had any idea what you were doing, getting bones and weights wouldn't be that difficult either (for games that skin on the GPU) but would require a small amount of custom handling on a per-title basis.
If you wanted to do this, I'm sure there are plenty of opengl wrappers already that you could hijack for the purpose, although auto-generating a wrapper from a DLL is also fairly trivial. (Noesis will spit out wrapper code for DLL's with unmangled export names for you as well, if you try exporting any Windows PE file) All that said, I have absolutely no interest in something like this. Good luck though!
If you wanted to do this, I'm sure there are plenty of opengl wrappers already that you could hijack for the purpose, although auto-generating a wrapper from a DLL is also fairly trivial. (Noesis will spit out wrapper code for DLL's with unmangled export names for you as well, if you try exporting any Windows PE file) All that said, I have absolutely no interest in something like this. Good luck though!
-
- double-veteran
- Posts: 929
- Joined: Fri Jul 08, 2011 12:06 pm
- Location: Torrance, CA
- Has thanked: 10 times
- Been thanked: 274 times
Re: how about making an OpenGL ripper?
I don't think python supports hooking so you'll have to man up to the platform sdk. Hooking is not hard with regular api functions. I was thinking of doing it to get the rage textures.
-
- Moderator
- Posts: 1007
- Joined: Mon Mar 23, 2009 2:57 am
- Has thanked: 44 times
- Been thanked: 505 times
Re: how about making an OpenGL ripper?
Oh, Rage is on my todo list as well, whenever I get around to installing the PC version. From what Carmack has said, it sounds like it just uses a simple wavelet-based image compression. Shouldn't be hard to figure it out from the disassembly.howfie wrote:I don't think python supports hooking so you'll have to man up to the platform sdk. Hooking is not hard with regular api functions. I was thinking of doing it to get the rage textures.
-
- Moderator
- Posts: 1007
- Joined: Mon Mar 23, 2009 2:57 am
- Has thanked: 44 times
- Been thanked: 505 times
Re: how about making an OpenGL ripper?
If it were a console game, maybe, but when you have IDA with online debugging and data breakpoints, no. Typically it takes me a few hours to isolate the code I care about and break it out into my own module. From there it's just a matter of translating the code back up to C, and given that this algorithm has to be fast enough to regularly decode large volumes of texture pages on the fly, I doubt it's going to be more than 40 pages or so of x86. That means, collectively, 1-2 days of real effort. Which in my case is probably around 3-4 real days, around playing SWTOR (god help me) and doing things which could very loosely define me as a valuable member of society. I might move it above FF12 in the queue, since it's actually likely to be less of a pain in the ass.howfie wrote:That sounds like it will take a lot of time lol.
Re: how about making an OpenGL ripper?
I don't think I'll be able to do it without learning more OpenGL and learning C then.
BTW, the word "wrapper" in python is usually used for a code which makes a non-python library callable by python.
I think what you mean is to rewrite the OpenGL library where the required functions are replaced with your own "wrapper" functions, which dump geometry before passing them to the actual function. Sounds a lot of work.
BTW, the word "wrapper" in python is usually used for a code which makes a non-python library callable by python.
I think what you mean is to rewrite the OpenGL library where the required functions are replaced with your own "wrapper" functions, which dump geometry before passing them to the actual function. Sounds a lot of work.
Re: how about making an OpenGL ripper?
Well how would that work?
Would you need to rename the original dll, create a dll with the original name and tell it to use the renamed dll, so it will get needed data before passing it to the original (renamed)?
Would you need to rename the original dll, create a dll with the original name and tell it to use the renamed dll, so it will get needed data before passing it to the original (renamed)?