News:

Congratulations!
 You've won the News Item Lottery! Your prize? Reading this news item! :)

Drawing all of objects under elevated ways

Started by Ichou, March 02, 2017, 12:06:51 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ichou

Hi, everyone.

Maybe as you know, part of objects under elevated ways is not drawn.
But for a purpose, I want to draw all of them.
If you know, I want you to tell me why they're not drawn.
And if it's possible, I want Simutrans to draw all of them.

I'm not sure at all, but I guess that the developers wanted to omit unnecessary drawings, and Simutrans to run more quickly.
I think drawing all of them is not difficult, because in my opinion, drawing all of them is simple processing, and omitting is more complex one.


Now I write the purpose.

A track has many elements: speed limit, color of ballast, shape of overhead wire pillar, sidewall, ...
If we split each element to different addons, we will be able to make many types of tracks by combining the addons.
For instance, when I have 3 rails, 3 ballasts, 3 sidewalls, and 4 types of overhead wire, I can make 3*3*3*4=108 types of tracks with 3+3+3+4=13 addons. That'll be more effective when there are more addons.
But the number of objects we can put on one way is limited, we usually have to merge some of them. It is a bad cause to increase the number of icons.
As for the previous example, merging rails and ballasts, I have to make 3*3=9 addons, instead of 3+3=6 addons.

Since double-height was installed, with pak128, we can build at most one way every two layers.
One day, I came up with a great idea(some else might have already known): if I set 'height_conversion_factor = 1' and assume two layers as a layer, I should be able to put twice as many objects on one way as before, without losing any functions!

So I experimented by building a transparent way over a normal track to test whether it would be drawn well or not, because I'd known the omission of drawing.
Then the result was bad. Some parts of objects on the 'lower' layer were not drawn, and most importantly, part of the vehicles was not drawn!

Thus, the largest thing preventing this idea is the 'not drawing matter.'

prissi

Every object under an and elevated way is draw. Do you mean: composing elevated way of track and support?

Ichou

Maybe my English wasn't good.
Objects are partially drawn or cut by the elevated ways.



Left: There are only way and wayobj.
Right: There is also elevated way, and the wayobj isn't completely drawn.

Dwachs

These objects are cut to avoid things shining through bridges and elevated ways. Maybe there is a problem with sliced view?
Parsley, sage, rosemary, and maggikraut.

Ichou

QuoteMaybe there is a problem with sliced view?
No, it's not limited to height-cut mode.

prissi

The problem is that these objects are too high in terms of pixel. If they are completely drawn then trees will go through bridges as houses etc. Thus, if you want something under an elevated way, it must not be too high. The 2D engine of Simutans cannot do better because a bitmap cannot tell whether a pixel is at the front or not.

At least you are alowed to put a lot of things under bridges, unlike OpenTTD ...

Ichou



Please look at the right example.
The vehicles are cut, and I cannot make lower vehicles.

And look at the left example.
If the 'lower' layer is elevated too, objects are drawn completely. I hope drawing like this, even if it's not elevated.

QuoteIf they are completely drawn then trees will go through bridges as houses etc.
If trees or houses go through bridges, I can solve this problem by breaking trees or houses.
But for not drawing problem, I can do nothing to solve it.

Leartin

Quote from: Ichou on March 03, 2017, 03:50:14 AMIf trees or houses go through bridges, I can solve this problem by breaking trees or houses.
But for not drawing problem, I can do nothing to solve it.
I think this is an issue of differing mentality.
Objects clipping through bridges is an issue that could happen to anyone, in any pak, if it was not for this precaution. Therefore it is a bigger issue than not being able to use elevated ways as secondary wayobj.

If you don't mind abusing the system, there are three ways I think could work for you:

A) Create a way that's just ballast, possibly with a waytype that's not in use. Then create the rails as an elevated way on top, drivable for the trains (which all need appropriate offset as well). Since the ballast is confined to the floor of the tile, it won't be clipped. You already showed that elevated ways on top of elevated ways won't cause clipping, so you can do with that whatever you want. Disadvantage: All your tracks need to work like this, so you can't have tunnels, because there is an offset in every vehicle.

B) Create a way that looks like a piece of elevated land. You can dig out a trench and place that way in there, so it will look like normal, flat land (you need to get rid of the fences in the pak, though) - once this is done, you can place your tracks as elevated ways. I am not entirely sure how much is clipped, so I'm not certain whether you would still have to complete land unterneath. But if that much works, just do the same as in method A, but without the need of an offset in vehicles.

C) Create ballast as roads, and use tram tracks as normal tracks. After that, you can use two way-objects. Careful though - citycars might spawn on the ballast if it's close to a city.



Certainly, I don't recommend any of these methods, since they are rather far-fetched. But it does not seem right to me to propose a change to elevated ways to complicately simulate a secondary wayobject right after you said a secondary wayobject on it's own would be too complicated and is not required oô

Ichou

QuoteObjects clipping through bridges is an issue that could happen to anyone, in any pak, if it was not for this precaution. Therefore it is a bigger issue than not being able to use elevated ways as secondary wayobj.
Why not draw completely way, wayobj, signals, and vehicles, then cut other objects?
I think this will bring us no problems, because if it brings some problems, someone should have insisted that elevated ways under elevated ways have to be cut properly.

If I were to choose one from your A, B, or C, I choose B, but I don't like it not because it's far-fetched but because I'll be not able to construct subways on the next lower layer of the ground.


QuoteBut it does not seem right to me to propose a change to elevated ways to complicately simulate a secondary wayobject right after you said a secondary wayobject on it's own would be too complicated and is not required oô
I'm glad to share the thought that we want more parts to build variety tracks.
I didn't like secondary wayobj because it brings complexity to the processing, but on the other hand, my idea will being little complexity.

Leartin

Quote from: Ichou on March 03, 2017, 08:04:11 AM
Why not draw completely way, wayobj, signals, and vehicles, then cut other objects?
I think this will bring us no problems, because if it brings some problems, someone should have insisted that elevated ways under elevated ways have to be cut properly.
I don't think many players would stack elevated ways in the first place, and if so, are most likely not concerned too much with graphical bugs or not active in the forums - so I would not count on that. However, I agree that if there is a simple solution like that without side effects, that would be best for a quick fix.

Ichou

I cannot imagine what side effects are there.
But if you don't like my idea, I can propose another idea.

How about changing the 'cutting line?'

I'm not sure it will be effective, but at least vehicles will be drawn well.

Leartin

An example for side effects: In p192c we have trees as wayobj for streets, to create a tree-lined avenue. Those trees are higher then one 'layer', so they would be visible between two tiles of elevated ways, unless they get cut. But they wouldn't, if you propose not to cut wayobj.

Now you might say it's silly to place trees under an elevated way - and I agree. In fact, any object that could cause clipping issues is probably 'too high" to be realistically placed under the elevated way. Still, unless there is a flag to forbid their use in combination with elevated ways, it's an issue.






Ichou

I agree that appearing between two elevated ways is wrong, but disappearing at a certain height is wrong too.
I admit that we sometimes want to hide objects which are automatically created, such as trees and houses.
But since wayobjs are built by a person, (I don't know about multiplayer mode well, so they might be built by AI in multiplayer mode.) who wants to make such a wrong situation?(Perhaps Leartin wants.)

If both are wrong, it should be more useful in other situations: in my case, the situation that using as an additional eye candy.

I agree that making a new flag is one solution, if there is no other good way.
But if I can, I want to do without new flags.

DrSuperGood

QuoteI admit that we sometimes want to hide objects which are automatically created, such as trees and houses.
One is not meant to be able to build such object under elevated ways or elevated ways over them. As it is elevated way construction is forbidden over any object that is more than 1 image high.

The problem is the logic is incomplete/inconsistent. Cities and players think nothing of placing an impossible building under an elevated way, even if they cannot place an elevated way over it.

Ichou

QuoteOne is not meant to be able to build such object under elevated ways or elevated ways over them.
I think it's fine but a little overdoing, because buildings low enough should be able to be put under ways.
And I can say one more problem: there are already a lot of save data which contradict to the new principle that there must not be trees or houses under elevated ways.

QuoteThe problem is the logic is incomplete/inconsistent. Cities and players think nothing of placing an impossible building under an elevated way, even if they cannot place an elevated way over it.
I cannot understand what you mean.(It may be my English skill problem.)
Cities and players will not be able to build such objects under elevated ways if programmed so.

DrSuperGood

QuoteI think it's fine but a little overdoing, because buildings low enough should be able to be put under ways.
Yes however not buildings 2 images high. One should also not be able to place such (2+ high) buildings under bridges that are low. Elevated ways should also be allowed above 2 high buildings if they are 2 high themselves.

To solve this I plan to remove the height check on elevated ways, and eventually properly implement it as a game setting that affects bridges, elevated ways and placing buildings under them. This does not break existing games where such objects are under elevated ways but will allow future games to have more strict elevated way rules if the player desires. Servers might want to keep it off to allow easier bridging in crowded maps.

QuoteCities and players will not be able to build such objects under elevated ways if programmed so.
Except they are not programed so. It is also no easy 1 line fix because one also needs to apply it to bridges for the implementation to be complete and allow cities to upgrade houses as long as there is enough clearance. This is a long running issue that I plan to eventually fix.

Ichou

Wow, there are too many things to complete the implementation, and it seems to bring some complexity.

I think your idea is good and a little revolutionary, but is seems to take a long time to be achieved.
And most importantly, will it help me achieve my purpose: the use of elevated ways as additional eye candy to tracks?

Hey, I tried to conclude the ideas until now.("elv" stands for elevated)
Which do you prefer? Or any other comments to this table do you have?









IdeaAdvantageDisadvantage
<A> No change

No task
There are alternative to achive various tracks.
No growth
Each alternative has each problem.
<B> Draw objects completely
Use of elv ways as additional eye candiesTrees, houses, and any other objects go through elv ways.
<C> Use 2 drawing systems by
whether it's way-friendly
Use of elv ways as additional eye candies
Trees and houses don't go through ways.
Still addons like streets' trees can cause a problem.
(But I disagree such a phenomenon cause a bad problem.)
<D> Change the 'cutting line'


At least vehicles are drawn well, and maybe
most of other wey-ferindly objects are drawn well.
Trees and houses don't go through elv ways.
There is still a height-limit to lower wayobjs.
<E> Make a new flag meaning whether cut

What should be cut will be cut,
and should be drawn will be drawn.
It need new makeobj.
Perhaps it brings system complexity.
<F> Secondary wayobjMost intuitive
Maybe most convenient.

System complexity
It has been refused once.
<G> New regulation to building under elv ways
(I think maybe drawing method will be <B>)
(Not discussed well yet)
More accurate and realistic regulationI think it brings some system complexity
Compatiblity with older version

I like <C> the best, and next to it, I like <E>.

prissi

Simutrans cannot guess if an oject fits under an elevated way or not since a front side pixel and a backside pixel at the same height have different "pixel height". Therefore, further information (flag) would be needed.

Also there are (in the japanese addons) a lot of houses specially made to be put under certain elevated ways. However, these would not fit under the brickways of pak128.britain. Hence, even if there is a flag, it is very unlikely that this will help, since there are too many different elevated ways.

So there are three solutions: Forbid everything under it (and then of course no problems, apart for the clipping of wayobjs directly under them), enforce the flag (fits_under_single and fits_under _double) which mean almost nothing will be built in current pak sets, or the current flexible system but which will eventuall have houses and trees cutted.

Leartin

One more option would be a flag in the elevated way/bridges whether stuff beneath it should be cut.


I see it this way: If elevated ways become supported as decorative objects, it becomes a somewhat 'official' way to go, and chances for actual secondary wayobjects would slim down. Instead, there would be precedence for fixing elevated ways to be usable for ths task. Which would be a shame, since elevated ways are practically frontimage only, cause problems when you try to place a signal on the track (you might hit the elevated way instead), stay even after you deleted the way beneath, invite to all kinds of floating vehicles (don't say players won't do it, I've seen too many trains on my borderposts to believe that), don't work with tunnels, disable bridging over them,... and I really don't think even the most ambitious programmer would try to fix all that. Slippery Slope Fallacy maybe, but still.

I'll probably try and resurrect the old dual-wayobj thread with a more detailled description and images in the next few days.

An_dz

Following the One-way patch a secondary way-obj is almost on the road-map, or basically an 'overtake-obj'. Seems like the best solution for that patch.

Ichou

#20
QuoteOne more option would be a flag in the elevated way/bridges whether stuff beneath it should be cut.
I think this is a great idea because it'll enable the use of elevated ways as additional eye candies, and because it almost saves the current flexible system of drawings about trees and houses.

Quoteit becomes a somewhat 'official' way to go, and chances for actual secondary wayobjects would slim down.
I don't think so because there are already addons which enable us uses not expected at first, and none of them is supported as an 'official' way to go.

Quotecause problems when you try to place a signal on the track (you might hit the elevated way instead)
I've known about it, so I've planned how to 'divide' elements to objects, and finally I found a well-diving way not to cause such a problem. Basically, what should be placed back will be put lower, and the fronts will be upper.

Quoteinvite to all kinds of floating vehicles (don't say players won't do it, I've seen too many trains on my borderposts to believe that)
You wrote "don't say players won't do it," but I can say players won't do it with assurance.
There are already many addons which use ways to another purpose.
For example: piers under elevated ways, pedestrian-way, floor of plazas, truss bridge's stiffener, pipeline, etc...
Yet there are so many, I haven't heard of inviting vehicles accidentally, so I can say that additional eye candy doesn't bring accidental inviting, either.

Quotedon't work with tunnels
Actually, I think one wayobj is enough to tunnel ways because overhead wire's pillars aren't needed there.
If you want in tunnels too, you can build additional way over it, since it might take some effort.

Quotedisable bridging over them
So I wrote this.
Quoteif I set 'height_conversion_factor = 1' and assume two layers as a layer, I should be able to put twice as many objects on one way as before, without losing any functions!
You might not know it, pak128's default is 'height_conversion_factor = 2.'
So if I set 'height_conversion_factor = 1' and use additional elevated way, we can bridge them same as before.
With the current setting, bridges can be built over 2 or more layers higher than lower way, because of 'height_conversion_factor = 2.'
And this condition will not change because bridges must be higher than additional way, which is higher than normal way, but 'height_conversion_factor = 1' is set.

Thus, to me, Leartin's idea has no problem, contrary to what Leartin insisted.




QuoteFollowing the One-way patch a secondary way-obj is almost on the road-map, or basically an 'overtake-obj'. Seems like the best solution for that patch.
(The problem is maybe that my English skill is weak.)
The first half of the quotation seems to suggest that we bring that discussion's idea to this discussion.
But the last half clearly suggest the reverse thing.
Which does it mean?


Leartin

Quote from: Ichou on March 04, 2017, 03:37:27 PM
(The problem is maybe that my English skill is weak.)
The first half of the quotation seems to suggest that we bring that discussion's idea to this discussion.
But the last half clearly suggest the reverse thing.
Which does it mean?

It means that the oneway-patch might use way_obj to indicate whether a road is a one-way road. If that's the case, there needs to be a method to get electrified one-way roads as well - which might lead to two way_objects for one tile. If so, those can be used for decoration as well. Even better, they would be asymetric - which means the player could choose on which side of the track poles for overhead wire are placed. Juicy stuff - let's hope for the best ;)

Ichou

QuoteIt means that the oneway-patch might use way_obj to indicate whether a road is a one-way road. If that's the case, there needs to be a method to get electrified one-way roads as well - which might lead to two way_objects for one tile. If so, those can be used for decoration as well. Even better, they would be asymetric - which means the player could choose on which side of the track poles for overhead wire are placed. Juicy stuff - let's hope for the best ;)
Yeah, let's hope for the best.
But since it's not completed yet, it should be discussed on another board.


Let's go back to the subject.
QuoteOne more option would be a flag in the elevated way/bridges whether stuff beneath it should be cut.
It's my second time to say, I think this idea is great.

We can consider it as adding a new function.
As Leartin said, there might still be some problems with using elevated ways as additional eye candies, after the function is implemented.
But at least, this addition doesn't make the environment worse and doesn't make players unhappy, because those who hate this function can do without it. So at least this change is a good change.

prissi

There are no planned efforts to have a dedicated elevated eyecandy road. It will break the drawing system even more. (One cars driving on it, you can use the 255 type to avoid driving on it). Also the one way wayobj will still allow for only a single wayobj per type. (Allowing more is than one wayobj is very easy but leads to all sort of troubles at crossings or when one wayobj ends, not to mention the removal of the "desired one only".)

It is more likely to make a wayobj with the waytype 255 which is allowed on every way. The idea was to have wayobjs for city roads liek tree etc.

Ichou

QuoteThere are no planned efforts to have a dedicated elevated eyecandy road.
Oh, OK. Then I give up my idea.

QuoteIt is more likely to make a wayobj with the waytype 255 which is allowed on every way.
So does it enable double wayobj, in the same way that tram-wayobj and road-wayobj are allowed to built on the same tile because they are different waytype?
I think we should make a new board to discuss this idea.

An_dz

Quote from: Ichou on March 05, 2017, 12:37:15 AM
So does it enable double wayobj, in the same way that tram-wayobj and road-wayobj are allowed to built on the same tile because they are different waytype?
Apparently, and so far, yes.

Vladki

Hey cool, are the lamps tge second wayobj of type 255?

Sent from my ONEPLUS A3003 using Tapatalk


An_dz

In fact the electrification poles are. The lamps were already built in the save and are road type. But it works, I can build on any way type.

prissi

This is very cool, since I did not changed a single line of code yet for that. Congratulation, hidden feature unlocked.

An_dz

Well, not 'hidden' because I had to hex edit the way-obj and do some code changes ;D ;D ;D

Leartin

Just so I understand this correctly:
Rather than a second wayobj per way, we get a generic wayobj that can be used on any way, in addition to the way-specific wayobj. Therefore, something like noise protection walls, hedges or even overhead wires need to be made only once and can be used on any way, rather than there being a need to recreate them for every way seperately. But if something only fits one particular waytype, it can be made as a wayobj for that waytype. Is this about correct?

If so, I propose drawing the generic wayobj on the outside and the specific on the inside. Reasoning being that generic wayobj most likely accompany the way on it's edge, while specific wayobj might be closer to the way itself. For example, a solid middle line only works for roads, and a third rail only for tracks.

Vladki

And most importantly, does this work out of the box, or is there a patch necessary to make it work?

Sent from my ONEPLUS A3003 using Tapatalk


An_dz