Anyone Have a B3d Loader?
Blitz3D Forums/Blitz3D Programming/Anyone Have a B3d Loader?
| ||
| I don't need it to support animation, just to load a static mesh, with brushes, textures, multitexturing, hierarchy, etc. The only one I can find in the code archives, by Halo, is not declared PD, and doesn't load the first example b3d I threw at it anyway. I'm currently reading through the docs and trying to write my own, but I don't think it's gonna be long before I start crying uncontrollably ( around the time I get to quaternions, I suspect ) |
| ||
| maybe a stupid question, but why do you need one? If you load a mesh usig LoadMesh, I think you have access to all aspects of the model, no? |
| ||
| It's a fair question. I'm using a whole bunch of textures which I do not have the right to distribute except in an encrypted form. Since Blitz is not going to get load-from-bank I either have to parse the B3d files and textures myself, or I have to go elsewhere for the next game. I figured parsing the b3d and textures would be slightly easier than learning a whole new engine or whatever. ( I'm having my doubts now.. lol ) |
| ||
| Use Molebox! |
| ||
| Use Molebox! And risk incompatibility on a consumer's PC! |
| ||
| And risk incompatibility on a consumer's PC! We risk it with everything we write. If it's a requirement that the textures must be encrypted, then I don't see much of an alternative. |
| ||
| If it's a requirement that the textures must be encrypted, then I don't see much of an alternative. Except write your own loader that decrypts then loads them. Afterall, you can create images and you can write pixels to them. you can create models and give them vertices, tris, and texturing. I'm not sure about anims though :/. The main problem is sound - there aren't many ways other than using an external dll. |
| ||
| Except write your own loader that decrypts then loads them. Afterall, you can create images and you can write pixels to them. you can create models and give them vertices, tris, and texturing. I'm currently reading through the docs and trying to write my own, but I don't think it's gonna be long before I start crying uncontrollably ( around the time I get to quaternions, I suspect ) It doesn't sound like that's really an option! Besides, if I recall correctly, Mike Boeh did some testing on his huge stack of 3D cards, and there are some that don't like writing to textures - so for all that extra work, you've still added incompatability. |
| ||
| mm. ouch. I wonder how blitz can load textures if it can't write to them... ah well. I might take a shot at it. [edit] decided I might as well, and mine'll be PD and optimized |
| ||
| If the quat stuff is freaking you out just use this. Create a quat, put data in from the file, convert to a rotation, and orient the mesh. No need to know how it works :D http://www.dscho.co.uk/blitz/tutorials/quaternions.shtml Also, if you're still trying to write yours here's my crazy optimized way of identifying a ChunkID if your interested: chunkID=PeekInt(bank,i) Select chunkID Case 1398293844 ;TEXS Case 1398100546 ;BRUS Case 1162104654 ;NODE Case 1213416781 ;MESH Case 1398035030 ;VRTS Case 1397314132 ;TRIS Case 1296649793 ;ANIM Case 1162760002 ;BONE Case 1398359371 ;KEYS End Select And here's my read c string function: Function ReadString$(Bank) Repeat ascii=PeekByte(Bank,i) If ascii=0 Then Exit Else out$=out$+Chr$(i) i=i+1 Forever i=i+1 Return out$ End FunctionAssumes a global i which represents the position to be read (it also intcrements this up to the byte after the end of the string -ready for more reading. |
| ||
| Why not use TeraBit's DataPak? It does the same as molebox (you can stick your data on the end of an exe), is free and works on all pc's. You can encrypt your data too. |
| ||
| This was my first attempt at one for vivid, based off's mark's dump-file. It works on static and anims, you just have to convert the parts that feed that data into banks into the equivilent b3d func(I.e instead of poking verts into bank cverts, acctually add verts to a b3d mesh. Sorry, it's a bit messy, but bear in mind I was butchering up someone elses code as a prototype ;) (Hence it being pd too) |
| ||
| Thanks Bot and Ant. Plenty of code to get me going there. Big&: Because DataPak plasters the textures all over the harddrive before putting them in the recycle bin. It would contravene the license agreement. No Blitz-made packer can do anything else, unless it limits itself to static meshes and textures as sounds and animated models cannot be created from scratch within Blitz. Michael: Because Molebox seems to have problems with recent PC's and writing to textures should only affect older PC's that aren't going to run the game anyway. Whenever there's a molebox'ed demo floating around, there are always a handful of people shouting "MAV", and even if it's not Molebox's fault but rather user error, I've still got to live with it. EDIT: At least if/when I get a loader working, I can make a test and see how it works. Then I have some kind of first hand evidence to compare to the results of Molebox'ed demos. |
| ||
| How about running the textures through some sort of compression algorithm, turning the compressed data into Data statements, then rebuilding the textures internally at runtime (uncompress data, CreateTexture/WritePixel)? There are a couple of compression algorithms in the Code Archives that could probably be modified to write to Data statements and read into bank and/or texture. |
| ||
| Yeah James. I was thinking about doing something along those lines, but when I use LoadAnimMesh() to load a level I create in Gile[s] with lots of entities and textures and surfaces and whatnot, it loads textures using LoadTexture, so I need to be able to parse the b3d myself in order to use my own texture load/create commands. I've managed to fix Halo's code in the code archives so that it actually parses the b3d correctly now. It was written so that it would only read one texture per chunk, only one brush per chunk, and it ignored vertex colours and vertex normals, which sent the whole thing screwy because it didn't bypass them either. Now I just have to make it build the mesh correctly. Then I'll rewrite it myself from scratch if and when I have it working. No point rewriting until I've got it working with Halo's basic structure. Ant's code has been very useful in showing me where Halo's code was lacking, so thanks for that. Hopefully Bot Builder's code will help me build the meshes to match the parsed data. |
| ||
| Ok, I think I'm making progress. I can't see any obvious differences between the two, but there might be something I'm missing. Here's what my Gile[s] exported alley.b3d looks like when loaded with LoadMesh()  Here's what the same alley.b3d looks like when loaded with my loader :  |
| ||
| That seems an odd place to put a static camera? |
| ||
| There are no cameras in the scene. It's not from my game, I just happened to steal an alley from the game to test with, since Gile[s] is where all my level meshes will be coming from. I just used this code to get two identical positions and angles so that I could reasonably compare the results to see if anything is wrong. Graphics3D 640,480
SetBuffer BackBuffer()
camera=CreateCamera()
CameraViewport camera,0,0,GraphicsWidth(),GraphicsHeight()
alley=Loadb3d("d:\my games\b3d loader\alley\alley.b3d",0,"d:\my games\b3d loader\alley\")
hierarchy_tree(alley)
PositionEntity alley,0,-10,0
Repeat
;RotateEntity camera,0,135,0
TurnEntity camera,0,1,0
UpdateWorld
RenderWorld
Flip
Until KeyHit(1)>0Hierarchy tree is JFK's code from the code archives to ensure the mesh has the same hierarchy as the original too. I've tried overlaying the images in Photoshop and I can't see a pixel difference, so I guess it's working :D |
   |