Manually define vehicle bounding boxes

Discussions about the technical aspects of graphics development, including NewGRF tools and utilities.

Moderator: Graphics Moderators

Post Reply
Bad_Brett
Transport Coordinator
Transport Coordinator
Posts: 355
Joined: 01 Feb 2007 17:59
Location: Stockholm, Sweden

Manually define vehicle bounding boxes

Post by Bad_Brett »

I'm using extra turning angles by splitting each vehicle into several parts and then use the other_veh_curv_info variable to get the correct angle. This works great. However, I have one issue:

Let's say I have an engine with the length of 8. That will also generate a bounding box with the length of 8. But in my case, I split this engine into 8 different parts, which means that I get 8 different bounding boxes, that all have the length of 1. I figurered that my best bet would be to add the sprites to one of the parts in the middle, but the bounding box is still an issue, as seen in the picture:
overlapping.png
overlapping.png (589.21 KiB) Viewed 2307 times
There are a couple of solutions. I could slice all my sprites into 8 parts. That would work great, exept for slopes, but perhaps it's possible to get around that with the other_veh_z_offset callback? But the easiest would be if it was possible to define the bounding box manually, so that I could make may midle sprite cover the "dummy" sprites as well. If this is not possible, what would you say is the best solution to my problem?

I have another question that might be off-topic, but anyway...

- I'm using the animation_counter variable to get smoother animations on my locomotives. Only problem is that the vehicle_is_stopped callback doesn't seem to fire when I expect it, which means that the animations keep playing even when the engine is stopped. Has anyone encountered this issue before?
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: Manually define vehicle bounding boxes

Post by Eddi »

problem with bounding boxes: once bounding boxes start to overlap, you get more problems instead of less.

problem with "vehicle_is_stopped" is that this applies only if the player clicked the "stop" button, it doesn't apply to "vehicle happens to have speed of 0". we discussed this somewhere in the past, but i've got no clue where.
Timberwolf
Transport Coordinator
Transport Coordinator
Posts: 318
Joined: 22 May 2006 18:25
Location: London-ish.
Contact:

Re: Manually define vehicle bounding boxes

Post by Timberwolf »

I found the following were necessary to get extra turning angles to work with a minimum of clipping:
  • When the vehicle is travelling in a straight line on flat track, split it into a sprite for each sub-vehicle.
  • When going round a curve, use a single "long" sprite for the centre vehicle.
  • When going up/down a hill, use a single "long" sprite for the centre vehicle to prevent splitting. (This can also be a dedicated hill sprite, allowing vehicles to appear more natural when climbing slopes)
I probably could have saved myself a lot of time and effort here by looking closer at Eddi's work for CETS, which IIRC uses this approach - I don't recall if it has separate sprites for climbing the hills, but we arrived at much the same logic for handling these cases.

Splitting to three sub-vehicles is sufficient for the "extra turns" logic to work if you're using a 24-angle scheme. This kind of "multiple vehicles in one" hack has a noticeable impact on performance of the game so splitting to 8 might reduce the number of trains someone can build in a large game. Obviously you lose some granularity on being able to detect where a vehicle is in each turn, it requires some tuning to get vehicle lengths split in a way which looks nice.

This scheme will still clip occasionally when a turn or transition to hill happens next to a tile with a slope foundation. I never figured out how to avoid that, but at least it's rare in gameplay compared to traversing bridges and stations.
Bad_Brett
Transport Coordinator
Transport Coordinator
Posts: 355
Joined: 01 Feb 2007 17:59
Location: Stockholm, Sweden

Re: Manually define vehicle bounding boxes

Post by Bad_Brett »

[/quote]
Eddi wrote: 01 Jul 2021 11:42 problem with bounding boxes: once bounding boxes start to overlap, you get more problems instead of less.

problem with "vehicle_is_stopped" is that this applies only if the player clicked the "stop" button, it doesn't apply to "vehicle happens to have speed of 0". we discussed this somewhere in the past, but i've got no clue where.
Ok, I see... Thank you for making it clear. In that case, using current_speed == 0 should work, right?

Timberwolf wrote: 01 Jul 2021 13:15 I found the following were necessary to get extra turning angles to work with a minimum of clipping:
  • When the vehicle is travelling in a straight line on flat track, split it into a sprite for each sub-vehicle.
  • When going round a curve, use a single "long" sprite for the centre vehicle.
  • When going up/down a hill, use a single "long" sprite for the centre vehicle to prevent splitting. (This can also be a dedicated hill sprite, allowing vehicles to appear more natural when climbing slopes)
I probably could have saved myself a lot of time and effort here by looking closer at Eddi's work for CETS, which IIRC uses this approach - I don't recall if it has separate sprites for climbing the hills, but we arrived at much the same logic for handling these cases.

Splitting to three sub-vehicles is sufficient for the "extra turns" logic to work if you're using a 24-angle scheme. This kind of "multiple vehicles in one" hack has a noticeable impact on performance of the game so splitting to 8 might reduce the number of trains someone can build in a large game. Obviously you lose some granularity on being able to detect where a vehicle is in each turn, it requires some tuning to get vehicle lengths split in a way which looks nice.

This scheme will still clip occasionally when a turn or transition to hill happens next to a tile with a slope foundation. I never figured out how to avoid that, but at least it's rare in gameplay compared to traversing bridges and stations.
This "hybrid" method actually crossed my mind as a possible solution, since the most obvious issuses occur on straight tracks. Nice to hear that it works pretty well :). I think I will try that, since it seems to be the least amount of work. I guess it would be possible to get around the issue with foundations by splitting all sprites and then check for both other_veh_curv_info and other_veh_z_offset, but that would certainly be complex.

When it comes to performance, yes, I realised that it would have quite an impact, and I would suspect that sprite layers affect this as well. Did I mention that I use different sprites for left and right turns? :)

So far, I haven't reach the limit, but if it becomes a problem, I can always reduce the number of parts. Do you know if the maximum number of train parts is fixed or if depends on the amount of RAM?
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: Manually define vehicle bounding boxes

Post by Eddi »

Bad_Brett wrote: 01 Jul 2021 14:13 Ok, I see... Thank you for making it clear. In that case, using current_speed == 0 should work, right?
i seem to recall that there was a problem with that approach. it might work at stations, but at signals a train is constantly trying to accelerate and resets back in case of red signal, which commonly results in non-zero speeds
Timberwolf wrote: 01 Jul 2021 13:15 This scheme will still clip occasionally when a turn or transition to hill happens next to a tile with a slope foundation. I never figured out how to avoid that, but at least it's rare in gameplay compared to traversing bridges and stations.
IIRC MB has done some work on trying to iron out these glitches, but he has never released that work, and i don't know any details.
So far, I haven't reach the limit, but if it becomes a problem, I can always reduce the number of parts. Do you know if the maximum number of train parts is fixed or if depends on the amount of RAM?
memory isn't really the problem, but the CPU time to move each vehicle part.

there used to be a limit on the total number of vehicle parts on the map, but i'm fairly sure that got increased to a number you shouldn't reach any time soon.
Bad_Brett
Transport Coordinator
Transport Coordinator
Posts: 355
Joined: 01 Feb 2007 17:59
Location: Stockholm, Sweden

Re: Manually define vehicle bounding boxes

Post by Bad_Brett »

Eddi wrote: 01 Jul 2021 18:44
i seem to recall that there was a problem with that approach. it might work at stations, but at signals a train is constantly trying to accelerate and resets back in case of red signal, which commonly results in non-zero speeds

Ok... is there any other variable I can use? Or perhaps check for speeds below 5 km/h or something like that?
IIRC MB has done some work on trying to iron out these glitches, but he has never released that work, and i don't know any details.
Interesting... I guess I could slice those parts as well and check if there's a z difference, but it will generate a ton of combinations...
memory isn't really the problem, but the CPU time to move each vehicle part.

there used to be a limit on the total number of vehicle parts on the map, but i'm fairly sure that got increased to a number you shouldn't reach any time soon.
Alright... My OpenTTD rarely exceeds 1% CPU usage on my computer (on normal speed), so I don't think it will become an issue on modern PC's.
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: Manuallye define vehicle bounding boxes

Post by michael blunck »

Eddi wrote: IIRC MB has done some work on trying to iron out these glitches, but he has never released that work, and i don't know any details.
There were quite a number of experiments to get rid of foundation glitches, but in the end the additional overhead was quantifiable in comparison to exiguous improvements. So I decided to not use them in my set.

Unfortunately, there are quite a number of long-standing bounding box issues in OTTD, not only with foundations.

regards
Michael
Image
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: Manuallye define vehicle bounding boxes

Post by Eddi »

michael blunck wrote: 02 Jul 2021 07:40 Unfortunately, there are quite a number of long-standing bounding box issues in OTTD, not only with foundations.
unfortunately, those are by nature unfixable. as in, you try to fix one, and it opens up another one elsewhere.

you'd have to transition to a proper 3D-engine... and that's not going to happen.
Post Reply

Return to “NewGRF Technical Discussions”

Who is online

Users browsing this forum: No registered users and 5 guests