Stucture of Blitz3d mesh
Blitz3D Forums/Blitz3D Programming/Stucture of Blitz3d mesh
| ||
| Just following on from this post: http://www.blitzbasic.co.nz/Community/posts.php?topic=64500 Does anyone know the data structure of the Mesh object used by Blitz3d? Specifically I'm trying to find the pointer to the Direct3d mesh so I can pass it to a userlib dll for manipulation of vertices etc. |
| ||
| .B3D file format specks are here, if they are any help (probably not): http://www.blitzbasic.com/sdkspecs/sdkspecs.php |
| ||
| I think that will only work if the runtime mesh structure is the same as the B3D file equivalent. I suspect that's unlikely as I'm sure additional information will be compiled and stored at runtime. Also this obviously won't include the pointer to the direct x mesh (which will only be created at runtime) |
| ||
| Thinking about it, the handle of the mesh will be a pointer to a blitz3d 'entity' object. A field of that could then be the pointer to the blitz mesh object and then a field of that could be the pointer to the directx mesh. Surely someone knows what this internal data structure is? :O) |
| ||
| I'd suggest to use a RAM monitor tool. It will tell you the Adress of a loaded test mesh. In blitz you would then read the adress the entity handle is pointing to and scan a RAM range there, searching for the previously determined adress value. This should give you a static Offset that can be used to read the physical mesh adress. I'm still not sure if a mesh is stored in RAM or in VRAM. Anyone? |
| ||
| Interesting. . . though I'm not sure I fully understand the process you are describing - could you elaborate a little, perhaps with an example? RAM or VRAM - yes I'm not sure either. My initial guess was that it will be in RAM and then blitz3d and/or direct3d would move it to VRAM for the render. Then I realized that this guess has no reasoning behind it (because I don't have any knowledge of how direct3d rendering works) so it could be entirely in VRAM for all I know. Would this be important to know? If so why? |
| ||
| I'm not an expert eighter. I'm pretty sure you cannot access VRAM as you can do it with RAM. Probably you need to lock some things, to prevent DirectX to manage things to death, or whatever. Additionally, in windows XP the OS may stop you from reading just any RAM adress, due to foreign process protection etc. I can't give you an example because I never did this. It's really hacking into Marks structures - the hard way. I can only tell you what I would try, and I'm not a smart hacker. Get a "Debugger" for assembler coders that allows to display RAM content in realtime. Should be easy to find one. This is the Ram Monitor tool. See if it can monitor VRAM. Then create a single mesh without textures. Scan the Vram. There should be something (the more I think about it, the more I believe the Mesh is located in the VRam only) Hint. Use a mesh with "magic" tags, eg. vertex XYZ positions like: 3.14159 or so. You will then be able to recognize the mesh in the Vram, using the Debugger. Try to guess where the mesh starts in the Vram. If you're lucky then it will start after a lot of zero-bytes, or at the bottom of the Vram Adress space. You will however have to scan the entity description area many times, until you find the potential pointer you determined from the debugger. See the "How to hack certain properties" (or similar) thread in the tutorial section on how to scan the entity description area. Unfortunately I cannot give you any guaranty if this will work or not. PS: I said use magic numbers, but Debuggers usualy don't display RAM as Floats, so maybe you have to do it the other way round: create a string made of 4 characters, move it to a bank and read out a float, then use this float in the mesh, eg. as a vertex X position. |
| ||
| The mesh is stored in RAM always it seems. When in the camera view, it will be transfered to VRAM and presumably stay there till it's forced out by lack of use. These are just from my own observations :o) |
| ||
| This could be true. In fact for this reason I do a Render-All after loading everything, to cache the level entirely. |
| ||
| Hmm, that's a good idea... never thought of that :o) |
   |