[scottb613]

Hi Folks,

Mipmaps are essential.

NVidia has free tools to handle all conversions to DDS - both as plugins for PS and PSP - and as command line tools for use in bat files or scripts. From what I gather both Gimp and Paint.net also handle DDS.

I've been using "nvDXT" command line tools for many years for both model textures and terrtex textures. TSRE doesn't add mipmaps when creating terrtex - so if you want to avoid Moire you need to add them in some other manner - I just convert them all to DDS while doing it. It works very well.

Nvidia "nvDXT" download:
https://developer.nv...y-texture-tools


I don't know if this would be any help - but - I did animate a test steam locomotive with "Bones". The "cyan" highlighted bone in the attached file will move all the other parts in the scene. Simply grab the highlighted bone and move it around to see the animation in action.

Blender Source - Bones:
 Pacific_BONES_.zip (414.08K)
Number of downloads: 78


Regards,
Scott

[gpz]

I'm afraid I am speaking about bones in a different manner: in accordance to the "skinning". In skinning the "bones" can be used as joints to the skin. These types of bones are the ones supported in gltf, they are actually just nodes.

The concept of bones in accordance to animation and using them as constraining items doesn't exist in the gltf. Animation is saved into gltf as keyframes. So these bones are of great help in generating the keyframes, but the gltf will contain only the resulted keyframes eventually. Gltf is a runtime end-format, not a physical modelling tool.

[scottb613]

Hi Peter,

Thanks for the response.

Yeah - bones are not much help with rigging keyframe animation either (at least from what I can see) - as the position/scale/rotation - isn't actually imparted on the animated objects when using bones to animate a scene. So - you can't record the needed keyframe info.

Regards,
Scott

[gpz]

Hmmm... Never did such thing in Blender, but the common sense would tell me there must be a way, just need to find it... What is the purpose of such a boning then?

[Genma Saotome]

Peter, I have been able to create a visible .gltf model. I didn't know I needed a \textues directory under the model, nor did I know I had to submit the folder holding both model and \textures in order to get it to display. I will send you the folders via a PM.

[Traindude]

Revisiting the idea of a new shape format and its utilization on articulated locomotives. It is rare that locomotives, even articulateds, have 10 or more driving axles. However, there are some known examples of this, such as the 2-10-10-2 Mallets on both the Santa Fe and Virginian, and the well-known "Triplexes" on both the Erie and Virginian. However, these go against the current ORTS/MSTS hierarchical standards.

The addition of more wheels and bogies in ORTS suggests that locomotives can, theoretically, have up to 9 driving axles--named WHEELS1 through WHEELS9. But what do you do when you're modelling an "oddball" prototype that has 10 or more driving axles?

Well, while we're developing a new shape format, we might as well think about hierarchical expansion. I propose one possible solution, which is to number the driving axles in a hexadecimal format. Take for example, the Santa Fe 2-10-10-2 (illustrated below). The first 9 driving axles are labeled WHEELS1 through WHEELS9 as they ordinarily would. However, instead of labeling the 10th driving axle WHEELS10, we label it WHEELSA, in recognition that "A" is the hexadecimal equivalent of "10".


Likewise, in the case of the Erie Triplex (shown below), the 1st through 9th driving axles are labeled WHEELS1 through WHEELS9, but the 10th, 11th and 12th driving axles are labeled WHEELSA, WHEELSB, and WHEELSC, respectively. (A=10, B=11, C=12)


I hope this makes sense to everyone. With the hexadecimal numbering of the driving wheels, we could theoretically have up to 15 driving axles (WHEELS1 through WHEELSF) if we wanted to!

[gpz]

In Openrails these tags don't have to be unique. You can have any number of wheels tagged ("named") WHEELS1 for example. The only difference is that single-digit wheels will rotate as the WheelRadius() defined in the Engine() section, while double-digit wheels as in the Wagon() section.

[Laci1959]

Hello.

Speaking of animation. Would it be possible to make a European-style light barrier? I know you should also go into the basic code, because it is based on the two-frame animation.

Sincerely, Laci1959

[gpz]

How does that differ from the currently implemented one? I'm pretty sure it will be possible with the glTF format shape, because that supports a wide range of animation styles. Why doesn't it work with .s?

[Laci1959]

Because it only knows two block animations. Open closed. This was formed 20 years ago. There were no lights at all, either flashing or steady. The developers of KUJU started from the fact that its barrier lights are not visible from the train. The trap bar, however, is visible from the train. Thus, the barriers made at that time have two cubes corresponding to the two end positions. The program ensures continuous movement between the two states.
Whether the flashing light is implemented with the number of animation frames or with a time specified in seconds is almost irrelevant. The latter is more sympathetic, even if I have to learn gltf modeling. The problem is rather that the program must also know this, i.e. the basic program of the OR must be rewritten.