Open BPI-919 opened 1 year ago
leezer3
commented
1 year ago ScaleXFunction, ScaleYFunction and ScaleZFunction have now been added.
I'm not really convinced by the color functions- They're somewhat more symptomatic of the lack of a decent multiple light model than anything else, as you need all three elements to make up a valid color. Adding a hex color function might work (a hex color is just an int after all), but I really don't like that.
BPI-919
commented
1 year ago In fact, I only wanted to reach with that Color function is: I don't really want object command duplications, I mean: My problem is, if I have a .b3d object file and I also want to change for example the lighting in a train's 3D cab or in an interior space of this train, now I only can do that in this way:
In fact, firstly we can just remove all the "EmissiveColor 255, 255, 255" commands from the .b3d file, then we can add "EmissiveColorAll 255, 255, 255" command after the last command of the .b3d file, and then we make a copy of that file and we also rename the copied one on that way how I mentioned it above. And after that, we just need to put a semicolon before the EmissiveColorAll command, and that's it, we will have 2 .b3d files, the first one will keep / retain its colors, the second one won't retain them in "Lighting: night" mode.
But the problem is, that we need to make a copy from that .b3d file for this implementation. It's just not about the duplications. If we want to make some corrections on this object file, e.g. oh, this seat is not high enough, I want increase the Y values of some Vertex / vertices, we need to make modifications both of the 2 files at the same lines, we need to change the currect parameters by 2 files, too, instead of make the rewritings by 1 file. That's not very comfortable. So this is the problem, I don't know how to implement this without file duplications. Do you have any idea from your side?
The .animated file seems like this (it's just an example) : [Object] States = seat.b3d, seat_dark.b3d StateFunction = if[playerTrain == 1, pluginstate[109], 0]
I hope, you can understand what I wrote above.
BPI-919
commented
1 year ago I was thinking more about the EmissiveColorFunction, you have previously mentioned that we only need here only one new function and you are right, because the Colors are made by 3 components: red, green and blue; and in case of 3 different functions, if one component is missing or any one of the 3 functions is missing, we will get an error message, and this case and also the handling of this case is really complicated, and the explanation - which would go to the developer documentation - could not also be very understandable... So I think, the EmissiveColorHexFunction will only be the workable idea.
In this example:
[Object] States = seat_light.b3d, seat_dark.b3d StateFunction = If[playerTrain == 1, pluginState[109], 0]
[Object] States = seat_dark.b3d EmissiveColorHexFunction = If[playerTrain == 1, If[pluginState[109] == 1, #000000, #ffffff], #ffffff]
The "seat_dark.b3d" file does not contain any EmissiveColor / EmissiveColorAll function, however the "seat_light.b3d" contains those functions. In the first example case, the differences between the "seat_light.b3d" and "seat_dark.b3d" files are related to the EmissiveColor / EmissiveColorAll command only.
BPI-919
commented
1 year ago @leezer3 : Could you please implement the ColorHexFunction and the EmissiveColorHexFunction as I wrote about it above? For me these functions would be very useful and important, and I would use them, because I don't want to duplicate .b3d and .png files in that case, when there would be also an easier way to accomplish, what I want to create. I hope this functions could be feasible somehow. Many thanks! :)
leezer3
commented
1 year ago I'm still I'm afraid entirely unconvinced.
I really don't like the hex color idea, it's just the only thing that I can think of making work halfway sensibly. Essentially, it's obtuse as hell (adds another place where a different color variant is used), and adding another layer of hackiness to what's already a mess- Color changes should be done in the mesh, anything else is lighting.
Basically, the real solution is to implement additional light sources. That's on a list, somewhere........
That came to mind that the .b3d files there are these commands:
Of the above commands only the first two have a function that can be mapped at the .animated file level:
My idea would be to give other .b3d file level commands a function that can be matched at the .animated file level, similar to what was written above, so:
Personally, I would welcome these innovations to avoid duplication of file content, because if other .b3d files cannot be referenced in .b3d files, hopefully there is another way to avoid this problem, such as introducing new .animated file features.
Suppose we have two .b3d files that differ only in that at one end there is a command like this: "RotateAll 0, 1, 0, 180". Both .b3d files are linked to one .animated file, so:
" [Object] States = something_1.b3d
[Object] States = something_2.b3d "
Instead, we could solve it by having only the file something_1.b3d, and we would duplicate it two times, after reversing the duplication:
" [Object] States = something_1.b3d
[Object] States = something_1.b3d RotateYFunction = 3.1416 "
This is also okay, but for example for the EmissiveColorAll command, I can't solve this with the current methods like this:
" [Object] States = something_1.b3d
[Object] States = something_1.b3d EmissiveColorRFunction = 255 EmissiveColorGFunction = 255 EmissiveColorBFunction = 255 "
Unfortunately, here you need two identical .b3d files with an "EmissiveColorAll 255, 255, 255" command at the second end.
If this feature extension were feasible, there would be no need to worry about file duplications. In case of duplication, it is necessary to modify in both files, if we modify or specify something, or we also reserve unnecessary storage space.