News:

SimuTranslator
Make Simutrans speak your language.

Pak64 longstanding train alignment issues

Started by passengerpigeon, June 17, 2018, 02:22:53 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

passengerpigeon

Dear community,
I have recently restarted the development of my addon pack for Pak64, but am still having some niggling alignment issues with my train carriages. All of the carriages that I have in the pack so far are the same length, but glitch into each other from all perspectives. Attached is an image of a test train and the image and .dat files of one of the types of carriage in it (the others are all set to the same length and use the same image alignment). I aligned my images a while back using Tenuki-Sharyo's train add-on as a template, and this seems to have fixed the issue of trains hanging off the tracks in corners, but the z-fighting remains. Do I need to increase the length or are my images still misaligned?
Thank you,
Passengerpigeon.

Frank

change length=8 to length=9 in the dat file

And better use the pak64 files. They are up-to-date, some add-ons are very old and no longer agree in size and orientation.
https://sourceforge.net/p/simutrans/code/HEAD/tree/pak64/vehicle/track/

Ters

Well, pak64 isn't entirely in agreement with itself, either. There is the odd vehicles here and there that is off alignment when moving diagonally, mostly locomotives (and/or their tender).

I think it has something to do with the length of diagonals having been changed at some point.

An_dz

Good point, it's better to align using the most recent objects.

And that's not 'z-fighting', just not enough separated wagons. Z-fighting is when the image that should be on the background ends up in the foreground. And in this case there's no z-fighting, they are all in their correct orders.

Ters

Z-fighting happens when there are two overlapping co-planar polygons at the same distance from the camera, within the precision of the coordinates. The computer can not tell which is foreground and which is background, causing it to randomly select one. I don't know if the term can be used when a z-buffer isn't used, but if it can, it fits what happens in align2.png (except that it is entire images that fight, as opposed to individual pixels).

An_dz

Quote from: Ters on June 17, 2018, 11:25:30 AM
Z-fighting happens when there are two overlapping co-planar polygons at the same distance from the camera, within the precision of the coordinates. The computer can not tell which is foreground and which is background, causing it to randomly select one.
I see you like to be technical 😛

Quote from: Ters on June 17, 2018, 11:25:30 AMI don't know if the term can be used when a z-buffer isn't used, but if it can, it fits what happens in align2.png (except that it is entire images that fight, as opposed to individual pixels).
I did not notice that at first, in this case there really has a z-fighting.

Ters

Quote from: An_dz on June 17, 2018, 07:04:15 PMI see you like to be technical 😛
Well, I am a computer engineer. If we're not technical, then who is? It should be noted that what I wrote was what causes z-fighting, not the definition of z-fighting (which probably mandates a z-buffer).