The International Simutrans Forum

 

Author Topic: Pak64 longstanding train alignment issues  (Read 364 times)

0 Members and 1 Guest are viewing this topic.

Offline passengerpigeon

  • *
  • Posts: 50
  • Languages: EN, ES, FR
Pak64 longstanding train alignment issues
« on: June 17, 2018, 02:22:53 AM »
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.

Offline Frank

  • Inactive/Retired
  • *
  • Posts: 1431
  • Languages: DE
Re: Pak64 longstanding train alignment issues
« Reply #1 on: June 17, 2018, 04:37:54 AM »
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/

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5368
  • Languages: EN, NO
Re: Pak64 longstanding train alignment issues
« Reply #2 on: June 17, 2018, 08:26:28 AM »
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.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2836
  • D'oh
    • by An_dz
  • Languages: pt, en, it, (de)
Re: Pak64 longstanding train alignment issues
« Reply #3 on: June 17, 2018, 09:35:53 AM »
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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5368
  • Languages: EN, NO
Re: Pak64 longstanding train alignment issues
« Reply #4 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 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).

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2836
  • D'oh
    • by An_dz
  • Languages: pt, en, it, (de)
Re: Pak64 longstanding train alignment issues
« Reply #5 on: June 17, 2018, 07:04:15 PM »
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 😛

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).
I did not notice that at first, in this case there really has a z-fighting.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5368
  • Languages: EN, NO
Re: Pak64 longstanding train alignment issues
« Reply #6 on: June 17, 2018, 08:11:59 PM »
I 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).