News:

Want to praise Simutrans?
Your feedback is important for us ;D.

clipping of walls (ways)

Started by Leartin, January 15, 2017, 05:35:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

Since Trump is president, I felt like building a wall!

The game does support barriers only as a subtype of rails, 255. I don't even think it does anything beside seperation in the menu, but clearly, the idea is not foreign to Simutrans. There are some known problems I could ignore, but my most recent attempt makes me really sad:



Since it is a way, I need to use "draw as ding" in order to get it in front of stuff in the first place. However, that only works for a certain height - most prominently, you can see the problem at the city entrance, where the red brick building clips into the left tower, and further left with a few streetlights. I'm not entirely sure why it happens, I mean, sure, ways never go that high without becoming elevated, but it still seems to be unique behaviour.


So, my request is to make walls great again - or something like that.
* Make walls have their own waytype (so they are not treated like rails anymore - no more misuse as cheap and glitchy rail service, no problem with unintended connection when building longer sections, no longer any problems with crossings,...)
* Allow them to rise higher (the clipping issue)

And I really thought there would be more, but actually, this covers almost all I could wish for. I mean, sure, one could always use another waytype as wall (if one is free), but since the clipping is the problem here, it seems to make sense to have another waytype with different clipping.

Dwachs

#1
Could you please upload the dat + image of the wall? I cannot imagine what causes this.

Are there any tiles (bridge/elevated) above the wall?

Is this 'fixed' with fast-forward?
Parsley, sage, rosemary, and maggikraut.

Leartin

https://www.dropbox.com/s/tev4vgk8jzus5bg/wall.zip?dl=0
Sources. For half heights, but that should not matter for the flat parts.


No, there is nothing above the wall that could cause the clipping, this is not a single occasion but happens pretty much everywhere, especially in forests.
To be more precise: Objects on tiles to the north of the wall will clip over the wall if they reach into the tile north-west of the wall (west of the tile the object is on). It does not happen with objects to the west of the wall reaching into the same north-west tile.

Yes, Fast-Forward + moving the scene or the mouse over it fixes it.

Dwachs

You should use frontimages: all pixels that cover something behind have to go into frontimage. (I forgot about frontimages when writing my first answer).

Or put all the image into the frontimages. Dont know if this works.
Parsley, sage, rosemary, and maggikraut.

Ters

"draw as ding". What is this "ding" supposed to be? And that is not because I don't understand German, because I understand that much. The field in weg_besch_t is called "draw_as_obj" (but documented as "draw as thing"), but weg is a subclass of obj both in the besch hierarchy and the, well, obj hierarchy. So arguably, any way a way is drawn will be a way an obj is drawn. Buildings, another "obj", can apparently be drawn in great height using only back images, which is what probably confused Leartin. So are there any other "things" in Simutrans which draws the way a way drawn as a thing is drawn?

Leartin

No, that's not really what confused me.
"draw_as_ding" is a parameter for ways. If zero (or not used), the way will be flat on the ground, and every object 'behind' it (north or west) will be drawn above it.
"draw_as_ding=1" is to be used for the way to be drawn in the 'normal' order like everything else, in case it's not flat. I used that before for delineator posts, and I used it for the wall as seen in the original screen. If that was not the case, the wall would end right at the edge of it's tile, and the sidewalk of the city behind it would be drawn above it.

That's why I don't get why frontimages should be used. It works in this case, but it really shouldn't be the solution.

Ters

Quote from: Leartin on January 15, 2017, 09:36:44 PM
No, that's not really what confused me.
"draw_as_ding=1" is to be used for the way to be drawn in the 'normal' order like everything else, in case it's not flat.

My point was that you think/thought that, but it is clearly no the case, because everything else would not run into these clipping problems. Something else might, but not everything.

Quote from: Leartin on January 15, 2017, 09:36:44 PM
That's why I don't get why frontimages should be used.

Sounds like confusion to me.

Dwachs

draw_as_ding / _obj: The display algorithm works as follows: first all the ground tiles including ways are drawn, then all objects on it.  If the `draw_as_obj` property of a way is true, then the ground and way images are not drawn in the first pass. It can be used if the way image should overlay something on neighboring tiles. IIrc pak128 uses this to generate smooth transitions between river images of different width.

Something is not working correctly here, I have to do some test if I find time. The suggestion to use front images was meant as a quick fix.
Parsley, sage, rosemary, and maggikraut.

Leartin

#8
Quote from: Ters on January 16, 2017, 06:29:04 AM
My point was that you think/thought that, but it is clearly no the case, because everything else would not run into these clipping problems. Something else might, but not everything. Sounds like confusion to me.

Yeah, I think that - I still do, because that's what everyone always says when you run into clipping problems with a way.
http://forum.simutrans.com/index.php?topic=4736
Quote from: DirrrtyDirkdid you try using "draw_as_ding=1" ? A parameter for occasions such as this. ;) After all fences are ways - and ways are designed so that they (by default) never cover/hide anything on a tile "behind" them. And for normal ways this usually makes sense. For higher structures, such as fences however... it makes indeed sense to have them covering/hiding what's behind them... and this is where the above mentioned parameter comes into play.
http://forum.simutrans.com/index.php?topic=12122
Quote from: Fabioyou need to use draw_as_ding=1 flag in dat file.
http://www.simutrans-forum.de/forum/index.php?page=Thread&postID=40388
Quote from: Alexander BroseFüge mal folgenden Parameter hinzu.  ;) draw_as_ding=1
http://simutrans-germany.com/wiki/wiki/de_WayDef#Der_Parameter_draw_as_ding
Quote from: Vermutlich FrankPDer Parameter draw_as_ding
Wird der Parameter draw_as_ding auf 1 gesetzt, dann übermalen die Grafiken des Verkehrsweges auch Grafiken, die sich auf Feldern hinter dem Baufeld befinden.

So, draw_as_ding is pretty much documented and known for what it does, or what it's intended to do. There is no confusion about that - maybe you are the one confused here?


EDIT: Thanks for confirming, Dwachs. When I first posted I thought it was intentional that ways can't go 'that high',but it's not actually that high, since the northwest-tile even borders.
Frontimage was a good idea anyways. draw_as_ding always causes tiny tears at the edges when you are not on default zoom, which is not the case with frontimages - so I suppose I will use that for walls now either way.

Ters

Seems to be confusion all around, but Dwachs is apparently going after the source of it (in the source possibly).

DrSuperGood

If the game was 3D the zdepth test would resolve all of this. However instead its a brain ache of correct render ordering. For some reason the top image is being rendered behind the bottom image. This would mean it is being rendered first or not re-rendered when sprites that overlap it are.


Ters

I found doing 3D rendering efficiently quite brain ache-y as well, but I was only looking into doing it with the GPU. Not so much doing 3D rendering, but modifying Simutrans to work with one. One could perhaps modify the current software renderer to use a zbuffer, but there is a question of how that extra reading and writing would affect performance.

Dwachs

There was indeed a bug related to drawing and clipping. It should work again with r8020.

The stray pixels while zooming are artifacts of the internal image zooming method.
Parsley, sage, rosemary, and maggikraut.