Modding the shaders

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


  • For the new underground station mod I feel some necessity to have a better rendering look, since the current effect for a closes space is some kind of a s**t, I feed unmotivated by this.
    In general I don't want this all shadow look, an underground station should also be filled with light, isn't it? To archive this, I have though the first solution: use fake mesh and materials data to get light into the space (make it open at the data level), but it seems harder than expected since I need also to remove the originals walls and use some hack work, by different possible solutions.
    Yesterday I turn my eyes on the shaders, it seems some interesting work can be done there, but I found little mods about this, so I don't know what's the capacity limit there.


    I would like to know, if someone could answer me, is it possible to modify the shaders, to use an emissive material as a lightsource, to lighten a closed space?

    This guy is too lazy to create a signature. 8o

  • What you can do with shaders is fairly limited to what you can pass to them. I am rather certain we don't have access to the internals of screen composition/postprocesses etc. Which means that even if you will be able to change shaders for a given surface, it will have to be identical in signature to the one you are replacing.


    I am currently working on the smoke shaders because I want a realistic fire and diesel smoke, but I am just modifying the smoke shader and I had to do some pretty janky hacking to get it done.

  • To showcase my work - the sample of what a fire I have gotten and more realistic diesel smoke - instead of throwing char, it throws that blueish tinted translucent fume.


    I used the 'size' shader argument. I simply moved the particle system definition ( size01 ) by 130 and 150 - respectively - and that gave me an indication of what effect to use. Particle systems in TPF don't support color natively, so I had to be creative. I think that showcases the problem you will have to deal with. My biggest issue is the translucency of the new shader to legacy vehicles - I don't want all of a sudden all steam engines to breathe fire :)


    EDIT: Regarding the original question. IF you have a way to discern what you are dealing with, THEN in a shader script you can use branching and use whatever methods to pass arguments and that is going to be your issue.


    The game reloads shaders on 'load game' and in case of an error, throws a message box with a compiler message. So it is quite straightforward. Inactive mods don't modify shaders in any way.

  • I don't think for the moment there are lot's of mod doing shader's work, most of mods in the community are vehicle mods, which is irreverent about shades, most of shader mods are about smoke, my work is concerned on material for a specific situation, so the risk is minimal, any way, if it's overwritten, the play just get a very dark station, it's not too bad to lost it.

    This guy is too lazy to create a signature. 8o

  • I only think in direction of that widely used sepia/blur shader. When you both tweak the same files... My concern is, that I dont think its possible to change single parts like base_config modding where you can change in mod A the day-length and in mod B the achievments with mods and both run fine. With shaders I fear you can only use mod A or mod B because both change the same file as a whole.

  • DarkMo is right tho, but the problem is, generally, about mod interoperability.


    LUA mods are run in sequence over the same data records.


    Take my mod for example - it shamelessly modifies all vehicle records loaded prior and sets their speeds and capacities to fit the balance scheme I envisioned. No-cost and similar mods might get their work overwritten if they were loaded prior to mine. This will end in some game weirdness.


    My mod also modifies particle systems. With version 1.1 its going to modify particle sizes to feed the modified shaders. If someone then loads a mod that also modifies that shader, then all particle effects from diesel locomotives are going to become these massive splotches of blue.


    If two mods modify the same data - then weirdness is going to occur.

  • there's a way to make a fallback working.


    There are 6 channels unused in this game, the g and b and alpha on cblend and UV1AO textures, so we can pick up a channel to store some information to do conditional branches, and some others to store useful things like lightmap. even if the shader is modified by another mod, it's just a fallback -- use the original game effect for the overwritten mod, so if it's the case, it won't be too bad.


    The screenshot is about what I have archived last night, I use a discriminator to remove the shadows on the underground platform surface, while for other material they are kept, I am going to use a lightmap to render

  • The following code in lighting.fs let you fix the yellowish ceil bug(at least I think it's a bug)



    I don't know why, but the lighting is stored in two cubic textures, and the bottom of these two are yellow, which makes the ceiling yellowish.


    I don't know where the two textures are stored, but I don't think it's the skybox, since I tried with a skybox mod and find no changes.


    The following two pics show the before and after

BlueBrixx