(chura) Krüger matrix selbst erstellen

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.
  • Hallo Community,


    Ich konnte schon früher in Citaro (Alterr&Wizard) eine LED-Innenanzeige eingebaut und Frontanzeige erweitert.
    Das war aber nicht mein Model, habe ich die vmatrix-model in 3ds max durch import eingestellt, dann die von mir gebaute Inennanzeigen-mesh mit den vmatrix_text, vmatrix_voll Objekte zugegeben. (Natürlich Texturen und Script erweitert und angepasst).
    Dann probierte ich mal eine von mich selbst gebaute Frontanzeigenmesh (mit gleiche Textur, Texturname) sowohl in MAN NL als auch in Citaro (Alterr) eingebaut, aber bekomme ich immer (auch mit original script) eine Integerüberlauf Fehler.
    Ich möchte in mehrere Busse Krüger-matrix einbauen, aber konnte ich noch niemals es ohne Fehlermeldungen geschafft.


    Hat jemand eine Idee, was soll ich berücksichtigen / aufpassen?


    Ich habe schon auf mehrere gedacht bei andere Bussen:
    1) Als ich weiß [scripttexture]-Befehle müssen so eingerichtet, dass nur Texturbefehle sollen früher kommen.
    Ist es auch wichtig wo die [mesh]-Befehl in model.cfg steht?


    2) Wie soll ich meine Model denn aufbauen?
    Zwei paralell Plane eine mit _voll, andere mit _text Textur.


    3) Muß ich die script für korrekte Funktion ändern?


    4) Wenn meine Mesh kleiner als die in Mercedes, aber ich benutze die gleiche Textur, sollte es funktionieren, oder brauche ich in const / osc Datei etwas ändern?
    ...


    Mein System ist Win7 (32bit), Ungarisch, Gleitkomma ist eine ',' wie bei Deutsche Einstellung.


    Busse wo ich es nutzen will:
    Setra (WIP), viele Ikarusse auch mit FOK-GYEM-Steuerung.


    Innenanzeige sollte auch ein Krüger Matrix sein, aber es erfrischt sich öfter, sollte separiert werden.


    Danke euere Hilfe im Voraus.


    Beispielbilder:
    1. Krüger-modi - Funktioniert, aber langsame Innenanzeige


    2. Lauft nur wenn Matrix init und Matrix frame deaktiviert. (schon nur init macht Probleme - frame deaktiviert) Anders Fehlermeldung nach erfolgreicher Fahrzeugsauswahl.


    3. Pläne - Jetzt FOK-GYEM mit wechsel-mesh


    (Sorry für mein Deutsch, sollte damit Probleme geben, kann ich evetuell auf Englisch nochmal mein Problem / Wunsch beschreiben).

  • An English description of your problem might be helpful, some things are a little hard to understand in the German version.


    1) I don't understand what you mean with the scripttexture entries and texture instructions. However, the position of the mesh entry in the model configuration file has an influence on the rendering sequence, so it is relevant.
    You can see this when you have an object in the bus interior which is visible through the window. If the object mesh is below the window mesh in the configuration, it will look as if the window has a hole exactly at the position of the object, i.e. the alpha value of the window material won't be added.


    2) Yes, this is how the Krüger matrix works: The script modifies the alpha channel of one of the textures so that the other one shines through at the position of the dots.


    3) If you want to use a different resolution, you must at least change values of the constants. I'm not sure if the chura Krüger adapts entirely to the values, but the standard M&R Krüger script doesn't, so you have to change the script as well. Busfanat gave a nice overview on the features of the different matrix types for OMSI somewhere in the forum.


    4) This should not be necessary if the textures are the same. The mesh dimensions are irrelevant to the script as it only touches the alpha channel of a texture.


    Hope this helps you a bit.


  • 3) In the M&R script there are 3 constants which are necessary for the height and the width


    I do not see the point, why Matrix_HxW necessary, if it is the product of the previous two.
    Additionally there are some (5) points, where instead of the here defined constant, the exact values are used.
    Once the 115 instead of Width in macro:Matrix_WriteTerminus

    :)


    1) As far as I know, it is important, to place [scripttexture] tags directly after the [texttexture] tags, espacially before any [mesh] definition.
    Is there any other limitation (which will cause errors) accordin to placing of the [mesh] of the displays?


    Before I had success in some modifications of Krüger-matrix models. E.g. Citaro (see pictures). I set the front display wider (model and script). Also extended with inside display mesh.


    Inside display would be an additional question: How can I manage to get it refreshing itself independently from the outside displays?
    Is it possible, to define multiple scripttextures for different display [mesh]es?


    I failed to create any displays to different buses somehow. I used the original textures, used the naming convention of the Citaro, used the original vmatrix script. Still always errors.
    In the bus selection dialog everything looks ok. When I try to place the bus, I got an error dialog.
    Even if I start omsi with -debug -savelogs - logall, no entry in the log at all!


    I have an original OMSI, version 2.1.993


    As you can see, there are some buses, where I would like to use the Krüger display. Later I plan to adapt my FOK-GYEM to this new display method.
    For the FOK-GYEM, I use currenty several planes with different text-textures, and I control their visibility from script. Refresh animation is harder to adapt, that's the main reason, I would like to use the Krüger.

  • 3) In the M&R script there are 3 constants which are necessary for the height and the width
    [...]
    I do not see the point, why Matrix_HxW necessary, if it is the product of the previous two.
    Additionally there are some (5) points, where instead of the here defined constant, the exact values are used.
    Once the 115 instead of Width in macro:Matrix_WriteTerminus

    :)


    This is exactly what struck me when I went through the script some months ago. Looks like it needed some cleanup. Also, I still don't quite understand why there is a certain number of PixelRefresh macro calls at one point. I couldn't relate the number to the matrix resolution. Unfortunately they always do the Q&A sessions with Marcel in the early evenings when I don't have the time to be there and ask. But maybe somebody else knows?


    1) As far as I know, it is important, to place [scripttexture] tags directly after the [texttexture] tags, espacially before any [mesh] definition.
    Is there any other limitation (which will cause errors) accordin to placing of the [mesh] of the displays?


    Not to my knowledge, as long as the general structure is met.


    Inside display would be an additional question: How can I manage to get it refreshing itself independently from the outside displays?
    Is it possible, to define multiple scripttextures for different display [mesh]es?


    This should work. What do you want the interior display to show? The bus stop name? You would need an additional script for the display, completely independent of the exterior matrix.


    I failed to create any displays to different buses somehow. I used the original textures, used the naming convention of the Citaro, used the original vmatrix script. Still always errors.
    In the bus selection dialog everything looks ok. When I try to place the bus, I got an error dialog.
    Even if I start omsi with -debug -savelogs - logall, no entry in the log at all!


    Well, I have not tried to do that myself yet. But what does the dialog say?

  • Hi,
    I've just checked the original man nl script, and made some notes and changes in an other script. A little summary about what I got.
    model.cfg
    Krüger speicher: 128x32
    Alpha-Kanal: 1024x256


    Texture size: 512x128
    Matrix Front: 115x16, SideTerminus and Nr below


    Const file:
    Pixel Factor: 8


    It should work so, that in the Krüger-speicher 1px size is 1x1. If you multiply it with the PixelFactor, we will get 1 8x8 pixel of the Alpha channel.
    Why the texture size is half of the alpha, I don't know - maybe this gives a smoother result.


    --- I've just tested the script and the model, got the same error message, as always. (w/o script mod, using original texture too) ---
    model.cfg setup:
    directly after last [texttexture] entry:


    before all glass surfaces:


    The kijelzo_full.bmp has a resolution of 1152x192


    vmatrix_config file:


    If interested I may upload the new files for the bus. At least the textures, the model file in x & o3d format, and the scripts too.


  • Yes, the Krüger-Speicher is in fact the internal equivalent to the bmp files which can be used for special displays. 1 px represents 1 dot in the matrix. When the script draws in the alpha channel, it multiplies the PixelFactor constant because 1 dot is 8x8 px in the alpha channel.


    I also agree with your last assumption: When you use alpha there's always some blur at sharp edges. This could cause a bad appearance when the alpha channel texture size matches the matrix dot texture size, i.e. neighboring dots shining through a little. With the higher resolution of the alpha channel, the "cutout" in the texture is more exact.

  • During you posted I added some extra info of the last experiences to my previous post..
    --
    Nächste schritte:

    Zitat

    Soweit mein matrix_init oder matrix_frame rennt, habe ich eine Integerüberlauf Fehler.
    Ich habe deswegen matrix_init und matrix_frame auf eine trigger gehängt.
    Wenn ich zeichnung auf scripttextur aktiviere (Elektrik an, trigger betätigt), bekomme ich statt eine Integerüberlauf Fehler eine CV.CalculateFree - AA. Wie oben.
    Map: Grundorf, Bus: Ikarus C56 vmatrix mod
    -- soweit ich habe die gleiche Sript mit MAN EN92 getestet, und dort war es Fehlerfrei, sollte ein problem mit scriptextur / model / textur sein.


    So I tested in the MAN NL (EN92) the script only - that should be fine already.
    I used original model.cfg, changed only the script in the background. Now I have only one active display (front). Changed in between to smaller (96x16)


    As I started the macro, got this nice error message. I took almoasr every line of the matrix_init to the main.osc init section. This way no problem at loading, except with this code / or it is becouse some rendering issues.

    Code
    1. (L.S.Year) (C.L.Matrix_Baujahr) - 0.01 max (C.L.Matrix_Fehlerpixel_pro_Jahr) * 971 (M.V.NrSpecRandom) 1 + * (S.L.Matrix_Fehlerpixel)



    I added my model to the EN92, and look - it's just fine. Sadly it still not working in the Ikarus C56. I think it might be a rendering issue, as the script, texture and model is the same.


    -------
    Solution found. (by padarmartin 01.2016)
    If there are other type of characters in the Regs.org (at [number] tag) files then numbers, omsi not creating the scripttextures..
    "Funny bug" as otherwise there is no problem with spaces and letters etc. there..

    Code
    1. [number]
    2. Regs_Volvo_Bp.org
    3. [registration_list]
    4. RSZ_Volvo_Bp.org


    So add list containing only numbers to the number tag and what you want to the registration list tag ..


    Without this solution no release of Setras etc..
    Maybe it will help to other developers too

    :)