Home Risen Risen2 Risen3 Forum English Russian

Registrieren Hilfe Kalender Heutige Beiträge
Seite 2 von 6 « Erste 123456 Letzte »
Ergebnis 21 bis 40 von 103
  1. #21 Zitieren
    research Avatar von NicoDE
    Registriert seit
    Dec 2004
    Beiträge
    7.409
    Zitat Zitat von Baltram Beitrag anzeigen
    The problem is that Risen doesn't seem to use the informormation about materials contained in XMSH files. It must be stored somewhere else too.
    The resource properties are duplicated in the respective object "hash" (GH04) list.
    Have a look at the compiled_sounds.bin spec and refs, to get an idea how it works.
    "Unter diesen schwierigen Umständen bin ich mir sicher, daß diese guten Menschen meinen augenblicklichen Bedarf an deren Gold verstehen werden." -- Connor
    NicoDE ist offline

  2. #22 Zitieren
    Ehrengarde Avatar von Baltram
    Registriert seit
    Jun 2006
    Beiträge
    2.264
    Oh...

    Yes, that is indeed what I was looking for.

    And it's actually quite logic that it's there...
    I'm such an idiot. I even searched it in dll files although I didn't think it would make much sense.

    Thanks very much for that hint!
    Baltram ist offline

  3. #23 Zitieren
    Abenteurer Avatar von Siegmund
    Registriert seit
    Oct 2009
    Ort
    Russland
    Beiträge
    68
    Baltram, NicoDE, i'm sorry but i haven't understood you (i'm just an artist, not a programmer). What must i do to replase any mesh in Risen???

    P.S. Thanks for you programes!
    Siegmund ist offline

  4. #24 Zitieren
    research Avatar von NicoDE
    Registriert seit
    Dec 2004
    Beiträge
    7.409
    Every resource (e.g. *._xmsh) is stored in the following format:
    Code:
    Resource Header
    Object Properties
    Resource Data
    If you change the Object Properties (e.g. VertexCount), you also have to update/synchronize the Object Properties in the Resource Object "Header"/"Hash" list (e.g. compiled_meshes.bin). This list includes a copy of the Object Properties of all resource files of this resource type. The only difference is the format how the Object Properties are stored (Resource File: as is, Object List: archive format).
    The Engine uses the Properties from the Object List - but not the Properties of the Resource File. I don’t know if there is a way to force the Engine to read the Properties from the file (currently I do not have the time to do research on this topic).
    "Unter diesen schwierigen Umständen bin ich mir sicher, daß diese guten Menschen meinen augenblicklichen Bedarf an deren Gold verstehen werden." -- Connor
    NicoDE ist offline

  5. #25 Zitieren
    Abenteurer Avatar von Siegmund
    Registriert seit
    Oct 2009
    Ort
    Russland
    Beiträge
    68
    Ok, now it's clear for me! Thank you!
    Siegmund ist offline

  6. #26 Zitieren
    Ritter
    Registriert seit
    May 2005
    Beiträge
    1.238
    Zitat Zitat von NicoDE Beitrag anzeigen
    [...]The Engine uses the Properties from the Object List - but not the Properties of the Resource File.[...]
    ?
    I changed 5 Submesh-VertexCounts of a mesh and they were displayed ingame (okay, one missing).
    I did not change the corresponding Vertexcounts in the compiled_meshes.bin.

    (what I will do now after your explanation...)
    Shak-otay ist offline

  7. #27 Zitieren
    research Avatar von NicoDE
    Registriert seit
    Dec 2004
    Beiträge
    7.409
    Zitat Zitat von Shak-otay Beitrag anzeigen
    ?
    My statement is based on research on image and sound resources. Maybe it is not fully valid for Meshes, because of the SubMesh object array in the property stream... If I have the required spare time (and if somebody needs it) I might develop a tool to synchronize/update the BIN based on properties of the (changed) resource files.

    ps: It’s time to get the Wiki alive to collect/merge the information.
    "Unter diesen schwierigen Umständen bin ich mir sicher, daß diese guten Menschen meinen augenblicklichen Bedarf an deren Gold verstehen werden." -- Connor
    NicoDE ist offline

  8. #28 Zitieren
    Ehrengarde Avatar von Baltram
    Registriert seit
    Jun 2006
    Beiträge
    2.264
    Zitat Zitat von Shak-otay Beitrag anzeigen
    ?
    I changed 5 Submesh-VertexCounts of a mesh and they were displayed ingame (okay, one missing).
    I would say that was a fortuity. I did a lot of experiments before being illuminated (can I say that in english?) by Nico and came to the conclusion that both vertex and facecount have to be correct in order to get meshes displayed correctly (they mustn't be higher but they also musn't be lower). The number of submeshes doesn't matter (besides the fact that materials are also read out of compiled_meshes.bin) if vertex and face count are okay.

    If they aren't there are sometimes 'holes' in the mesh, sometimes there are additional faces and sometimes nothing can be seen. But if the difference isn't big there often is no obvious error in the mesh.
    Zitat Zitat von NicoDE Beitrag anzeigen
    I might develop a tool to synchronize/update the BIN based on properties of the (changed) resource files.
    That would be great! As for compiled_meshes.bin I already began to integrate a kind of BIN updater into the XMSH builder but it will only replace / add one XMSH 'entry' in one run (and I still will have to test whether it works).
    Zitat Zitat von NicoDE Beitrag anzeigen
    ps: It’s time to get the Wiki alive to collect/merge the information.
    I absolutely agree with that! I look every five seconds at the wiki whether there is a new site I might work on, because normal users can't create new ones.
    Baltram ist offline

  9. #29 Zitieren
    Ritter
    Registriert seit
    May 2005
    Beiträge
    1.238
    Zitat Zitat von Baltram Beitrag anzeigen
    I would say that was a fortuity. [...]
    Maybe...
    (But I placed Xardas tower (as a single mesh) in Risen last year and it worked without touching the compiled_meshes.bin.)

    (what I will do now after your explanation...)
    Hmm, one more submesh missing!?

    I'm ... thinking about it.

    edit: yep, got it: http://upload.worldofplayers.de/file...h_in_Risen.JPG

    thanx, Baltram.:-)
    Shak-otay ist offline Geändert von Shak-otay (10.02.2010 um 17:25 Uhr)

  10. #30 Zitieren
    Neuling
    Registriert seit
    Feb 2010
    Beiträge
    2
    Great work Baltram. I'm English so my German isn't very good I'm afraid so a lot of this thread is lost on me but I've managed to create an OBJ exporter based on Baltram's script here so I could edit meshes in Blender (obj is easy to work with and I can test the models in idTech4 for instance):

    http://symo.me.uk/risen/Risedit_1.rar

    [Bild: risedit.jpg]

    .NET Framework 3.5 needed.

    Some example screens for models imported into QuakeWars:

    http://symo.me.uk/risen/risen1.jpg
    http://symo.me.uk/risen/risen2.jpg
    http://symo.me.uk/risen/risen3.jpg
    http://symo.me.uk/risen/risen4.jpg

    I did have problems when there's more that one submesh as was mentioned earlier in the thread here but if I export them all as separate obj's and merge them back in in Blender then all is good.
    Violator ist offline Geändert von Violator (14.02.2010 um 13:19 Uhr)

  11. #31 Zitieren
    Ehrengarde Avatar von Baltram
    Registriert seit
    Jun 2006
    Beiträge
    2.264
    @Violator
    Good Job! I hope this will help to make blenderers more interested in Risen modding...

    It would be great if your program also could export vertex normals ('vn' in OBJ). In my import script this isn't featured because Max/GMax is permanently recalculating them so it would't make much sense there. But perhaps Blender or some other 3d prog/renderer could visualize them.
    In XMSHes they're usually the 3 floats right after the vertex position (and they're in the same matrix).

    It would also be helpful to have another button to choose the directory for the OBJ to be stored, by default it's always "J:\ET\QW\almostmedieval\models\risen".

    P.S. The reason for the problem with multiple-submesh-files: After the first submesh your program adds the number of previous faces to the vertex indices - not the number of previous vertices... You should fix this.
    Baltram ist offline

  12. #32 Zitieren
    Baltram ist offline

  13. #33 Zitieren
    research Avatar von NicoDE
    Registriert seit
    Dec 2004
    Beiträge
    7.409
    Many thanks for the new version - very impressive
    "Unter diesen schwierigen Umständen bin ich mir sicher, daß diese guten Menschen meinen augenblicklichen Bedarf an deren Gold verstehen werden." -- Connor
    NicoDE ist offline

  14. #34 Zitieren
    Neuling
    Registriert seit
    Feb 2010
    Beiträge
    2
    Zitat Zitat von Baltram Beitrag anzeigen
    @Violator
    Good Job! I hope this will help to make blenderers more interested in Risen modding...

    It would be great if your program also could export vertex normals ('vn' in OBJ). In my import script this isn't featured because Max/GMax is permanently recalculating them so it would't make much sense there. But perhaps Blender or some other 3d prog/renderer could visualize them.
    In XMSHes they're usually the 3 floats right after the vertex position (and they're in the same matrix).

    It would also be helpful to have another button to choose the directory for the OBJ to be stored, by default it's always "J:\ET\QW\almostmedieval\models\risen".

    P.S. The reason for the problem with multiple-submesh-files: After the first submesh your program adds the number of previous faces to the vertex indices - not the number of previous vertices... You should fix this.
    Thanks - I have got it exporting normals now, but I normally (no pun intended, honest) recalculate them in Blender anyway. I've also got it remembering all its settings as well as being able to pick the export path more easily. Still need to have a look at the submesh issue.
    Violator ist offline

  15. #35 Zitieren
    Rookie
    Registriert seit
    Jun 2010
    Ort
    Denmark
    Beiträge
    3
    Tried out the tool, and it seems to work very nicely. It's easy and clear. Perhaps another nice feature of the tool would be direct conversion between *.max or *.gmax? Perhaps that's not possible tho, I'm only capable of doing HTML.

    Preparing the Gmax file didn't take any long time, but it seems to depend on how many individual objects, your mesh consist of. I tried save one of my trees, and it took less than 15 seconds to convert 15 objects. Converting the *.gmax file to *.xmsh didn't even have a waiting time. Since I don't own Risen, I could not test my mesh in-game, tho.

    EDIT: Tested out the Forgotten City Mesh.gmax, which consists of 61 objects. Surprisingly it only took 20 seconds
    Urnemanden ist offline Geändert von Urnemanden (03.06.2010 um 20:20 Uhr) Grund: Added extra test results. Fixed misspell.

  16. #36 Zitieren
    Ehrengarde Avatar von Baltram
    Registriert seit
    Jun 2006
    Beiträge
    2.264
    Zitat Zitat von Urnemanden Beitrag anzeigen
    Perhaps another nice feature of the tool would be direct conversion between *.max or *.gmax?
    This is unfortunately not possible because the MAX/GMax file structure is extremely complex and completely different from normal 3d file formats. No one (afaik) has ever been able to read or even build these files with a program other than MAX (Deep Exploration can - but it works only with MAX installed).
    Zitat Zitat von Urnemanden Beitrag anzeigen
    Preparing the Gmax file didn't take any long time, but it seems to depend on how many individual objects, your mesh consist of.
    For each mesh there are about 10 vertices added to a kind of "info mesh". The part that takes time for the script is rebuilding all the meshes with reset transformation (thus skinning etc. is lost). You can save this time (and keep skinning etc.) by manually resetting it using "Reset XForm" (all at one time) which is very fast but unfortunately not accessible via MaxScript.
    Zitat Zitat von Urnemanden Beitrag anzeigen
    Tested out the Forgotten City Mesh.gmax, which consists of 61 objects. Surprisingly it only took 20 seconds
    20 seconds to prepare or to convert? Sounds pretty long...
    Baltram ist offline

  17. #37 Zitieren
    Rookie
    Registriert seit
    Jun 2010
    Ort
    Denmark
    Beiträge
    3
    I would take distance from MAX then, but as you don't mention Gmax as something required to be installed, for converting *.gmax files, I expect it's because the *.gmax format is a light version of the *.max format, as well?
    Is it correct stated by me, that you can convert from *.gmax to XMSH or ASE, but not the other way around? I believe that was why you created the XMSH importer.

    Zitat Zitat von Baltram
    For each mesh there are about 10 vertices added to a kind of "info mesh". The part that takes time for the script is rebuilding all the meshes with reset transformation (thus skinning etc. is lost). You can save this time (and keep skinning etc.) by manually resetting it using "Reset XForm" (all at one time) which is very fast but unfortunately not accessible via MaxScript.
    So, the marking is actually only created so your tool can recognize it - it doesn't directly have anything to do with Risen's requirements of a mesh?

    Zitat Zitat von Baltram
    20 seconds to prepare or to convert? Sounds pretty long...
    Sorry, but I don't really have any sense of time, all I can say that it (of course) took a bit longer. It didn't feel like it took twice as long to save 61 objects, as it took saving 31, tho.
    Urnemanden ist offline

  18. #38 Zitieren
    Ehrengarde Avatar von Baltram
    Registriert seit
    Jun 2006
    Beiträge
    2.264
    Zitat Zitat von Urnemanden Beitrag anzeigen
    [...] as you don't mention Gmax as something required to be installed, for converting *.gmax files, I expect it's because the *.gmax format is a light version of the *.max format, as well?
    Is it correct stated by me, that you can convert from *.gmax to XMSH or ASE, but not the other way around? I believe that was why you created the XMSH importer.
    Yes, I can read "marked" GMax / MAX files but I never ever will be able to write them. Basically the two formats are the same - for the tool it doesn't make any difference at all. You could name a .gmax to .max and it still would work.
    The act of "preparing" is roughly said (there rest still the materials, for example) creating a mesh with about 3 initial verts with "magic" position values, so it can be located by simply searching through the whole MAX file. Then more verts are added, for each mesh in the scene about 10, so they can also be found by searching through the file (but it's a bit tricky - that's why transformation has to be resetted).
    As you see I don't know anything about the file structure (besides some things about junk blocks that pierce through all the vertex, face, ... data in the file) - it is just too complicated. Hope you understand why, for me, only reading is possible.
    Zitat Zitat von Urnemanden Beitrag anzeigen
    So, the marking is actually only created so your tool can recognize it - it doesn't directly have anything to do with Risen's requirements of a mesh?
    Yes, it definitely hasn't to do anything with that.
    Baltram ist offline

  19. #39 Zitieren
    Rookie
    Registriert seit
    Jun 2010
    Ort
    Denmark
    Beiträge
    3
    Well, based on those answers/confirmations you gave me, I might get a little off-topic now. Would it be possible to read *.max files into Gmax, roughly then?
    Urnemanden ist offline

  20. #40 Zitieren
    Ehrengarde Avatar von Baltram
    Registriert seit
    Jun 2006
    Beiträge
    2.264
    Yes, it should be possible (but not fast) to read those marked MAX files via MaxScript into GMax and the other way round.
    Baltram ist offline

Seite 2 von 6 « Erste 123456 Letzte »

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •