DFF mesh format loader
one more issue where i could need help: when using my GTA SceneNode using the initialisation code mentioned above (which uses a FPS camera scene node), the entire world is rotated in the x angle by 90 degrees (IIRC).
this results in the problem that i can use the camera to fly over the scene and higher the altitude, but i cannot lower the altitude without flipping my complete camera first.
i tried rotating the entire scene node to fix this, but this made the camera to behave really weird.
any idea how this issue can be solved easily (hopefully without any static math)?
this results in the problem that i can use the camera to fly over the scene and higher the altitude, but i cannot lower the altitude without flipping my complete camera first.
i tried rotating the entire scene node to fix this, but this made the camera to behave really weird.
any idea how this issue can be solved easily (hopefully without any static math)?
Yes, I can fix this. I'll look at the loader.loki1985 wrote:one more issue where i could need help: when using my GTA SceneNode using the initialisation code mentioned above (which uses a FPS camera scene node), the entire world is rotated in the x angle by 90 degrees (IIRC).
this results in the problem that i can use the camera to fly over the scene and higher the altitude, but i cannot lower the altitude without flipping my complete camera first.
i tried rotating the entire scene node to fix this, but this made the camera to behave really weird.
any idea how this issue can be solved easily (hopefully without any static math)?
I can do these too (img as file format and TXD texture loader) as long as I can get info on the file formats.i already asked for this feature here: http://irrlicht.sourceforge.net/phpBB2/ ... highlight=
plus a TXD format loader (which is some work, but absolutely possible) and then your idea works, loading the entire city from the IMG file.
Last edited by loki1985 on Wed Oct 08, 2008 10:50 pm; edited 1 time in total
I should have some time over the weekend and next week to have a good look at these issues.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
OK, I've got the file formats for IMG and TXD. Looks fairly straightforward to make IMG archive and TXD texture loaders for Irrlicht. I'll let you know how I get on...
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
sounds good. you can use the RenderWare clump format parsing from my DFF loader, because textures in TXD files are also in this clump format, just like DFF files.sio2 wrote:OK, I've got the file formats for IMG and TXD. Looks fairly straightforward to make IMG archive and TXD texture loaders for Irrlicht. I'll let you know how I get on...
you just have to react on different sector type ids.
also, i would advise to use the scenemanager parameters to allow the user to pass the specific texture he wants to load from the TXD archive.
I'll start on the IMG archive support. Once done I'll add it as a patch to the Patch Tracker on Irrlicht's sourceforge page.
The TXD loader looks pretty straightforward to implement. Just use one of the other loaders (such as PBG or TGA) as a template for the new class. Please use only Irrlicht containers though - no STL - that way we can keep the base source clean (I'd prefer to convert the lot to STL, but that's another matter).
The TXD loader looks pretty straightforward to implement. Just use one of the other loaders (such as PBG or TGA) as a template for the new class. Please use only Irrlicht containers though - no STL - that way we can keep the base source clean (I'd prefer to convert the lot to STL, but that's another matter).
Not quite sure what you mean here. Once implemented, the loading of TXD texture files will be transparent to the user - Irrlicht will look in an IMG archive (if the user has specified one) if it can't find it on disc.also, i would advise to use the scenemanager parameters to allow the user to pass the specific texture he wants to load from the TXD archive.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
well, TXD files are archives themselves. one TXD file does not equal one texture, but usually contains multiple textures, with several encoding and compression formats possible (mostly S3TC DXT1 - DXT5).sio2 wrote: Not quite sure what you mean here. Once implemented, the loading of TXD texture files will be transparent to the user - Irrlicht will look in an IMG archive (if the user has specified one) if it can't find it on disc.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
How does the mesh reference the textures inside the archive? I guess there would be the need to do some hierarchical naming scheme then, which could be mapped to the archive content by the texture loader as well. Another way would be to add another archive type to the file system, but this would only make some benefit if the access to the archives is more complex than just an offset into the images.
DFF meshes only have a string reference to the texture name. in the IDE definition files of the game, it is defined in which TXD the textures for the specific DFF file are found.
that way, the same model can have multiple appearances by simply switching it to another TXD file. mainly this was used to load or unload TXDs depending on position of the camera, since some TXDs where region-specific. this also means textures often exist multiple times in different TXDs.
that way, the same model can have multiple appearances by simply switching it to another TXD file. mainly this was used to load or unload TXDs depending on position of the camera, since some TXDs where region-specific. this also means textures often exist multiple times in different TXDs.
Hmmm. Perhaps we don't want to load textures from TXD files in general, but only need to access them in the context of a DFF model loader. We don't need a TXD loader, only a model (DFF) loader. The code for accessing textures from a TXD would reside in the DFF loader and would hence have the info it needs to load texture X from TXD file Y.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
i currently did not start with a TXD loader, since it does not really fit into the engine architecture. simply implementing it as an Image Loader won't work, since the engine would not load another texture from the same TXD, since it thinks it already has that image loaded, assuming the file is only 1 image.
i also don't feel good with the idea of implementing it into the DFF loader, also because that would eliminate some of the codes flexibility.
i think i will currently leave it the way it is, and maybe when irrlicht will get a file archive plugin concept, then a TXD loader could be implemented as a file archive loader.
for me there still remains problem mentioned some posts above, the one with the whole world being incorrectly rotated by 90 degrees. fixing this would make my demo much better controllable, any help there?
i also don't feel good with the idea of implementing it into the DFF loader, also because that would eliminate some of the codes flexibility.
i think i will currently leave it the way it is, and maybe when irrlicht will get a file archive plugin concept, then a TXD loader could be implemented as a file archive loader.
for me there still remains problem mentioned some posts above, the one with the whole world being incorrectly rotated by 90 degrees. fixing this would make my demo much better controllable, any help there?
thanks to Acki, now also the world is correctly rotated, also i cleaned the code up a little here and there, now calling render() manually at least once is not necessary anymore.
updated code:
http://b66883.com/projects/dffloader/CG ... 081118.zip
updated code:
http://b66883.com/projects/dffloader/CG ... 081118.zip
Last edited by loki1985 on Wed Nov 19, 2008 10:27 am, edited 1 time in total.
today i revisited the moomapper source code searching for the bug which caused GTAVC and GTASA DFF meshes to not display properly. i found that most of these newer DFFs use triangle strips instead of triangle lists. now i added support for that, and voilá, VC and SA are displayed correctly.
i found some issue with some of the textures flickering (as if 2 textures where put on the same face and now are z-fighting). but that might be because of my notebooks graphics card or something, and i cannot test this at the moment.
updated DFF loader:
http://b66883.com/projects/dffloader/CD ... 081201.zip
i also changed the GTA Scene Node to use Irrlichts internal Quaternion implementation for
conversion instead of the selfimplemented version, here are the updated files:
http://b66883.com/projects/dffloader/CG ... 081201.zip
some screenshots:
Vice City:
San Andreas:
(both are in LOD mode and as such look low-detail, since i really cannot render the complete city on my notebooks on-chip graphics card)
i found some issue with some of the textures flickering (as if 2 textures where put on the same face and now are z-fighting). but that might be because of my notebooks graphics card or something, and i cannot test this at the moment.
updated DFF loader:
http://b66883.com/projects/dffloader/CD ... 081201.zip
i also changed the GTA Scene Node to use Irrlichts internal Quaternion implementation for
conversion instead of the selfimplemented version, here are the updated files:
http://b66883.com/projects/dffloader/CG ... 081201.zip
some screenshots:
Vice City:
San Andreas:
(both are in LOD mode and as such look low-detail, since i really cannot render the complete city on my notebooks on-chip graphics card)