PDA

View Full Version : Load culling



rumour3
October 5th, 2015, 01:25 AM
The HF2 culling of loads is being discussed here: http://forums.auran.com/trainz/showthread.php?123263-Loads-Not-Showing-On-Flatcars
The thread has gone off into Yet Another Discussion About LOD, which rather misses the point that highly visible loads are being culled too soon, at default settings, with unacceptable visual results. A performance measure that appears to have been primarily a response to passenger loads, which are inherently high poly but not noticeable at distance because they are generally inside a closed traincar, is having an unsatisfactory impact on other loads that are far more visible.

My questions are:

Is it actually possible to build a load with LOD that won't be culled at the very short draw distance for users with the game running at the current default detail settings?

Can the game code treat passengers as a special case, and cull them sooner than other loads (or rather let other loads be culled later)?

Going forward, can highly visible loads that define the appearance of the traincar be identified by the creator and be subject to the same design and visibility considerations as any other traincar asset?

R3

WindWalkr
October 5th, 2015, 02:51 AM
Is it actually possible to build a load with LOD that won't be culled at the very short draw distance for users with the game running at the current default detail settings?

Very dependant on the specific build being used (hf2 and the internal test builds use completely different approaches here) but this varies on the detail settings (as you've noted) as well as potentially other metrics such as the number of product queue attachments.

The short version is that we need creators to be smart about culling these attachment points as soon as possible to maintain reasonable performance. Where they can't be culled outright, we need to consider alternative approaches such as LOD, gradual reduction in attachment count, or simply rethinking the number of attachments in use.



Can the game code treat passengers as a special case, and cull them sooner than other loads (or rather let other loads be culled later)?

In theory, it could, but there's no real advantage to this. We don't care about passengers specifically.



Going forward, can highly visible loads that define the appearance of the traincar be identified by the creator and be subject to the same design and visibility considerations as any other traincar asset?

Moving forward, we need to consider performance a lot more comprehensively when creating content. We've been in the habit of creating first and looking at performance as an afterthought, which isn't working out well for us in many cases. There are many aspects to this, and I'm sure everyone watching this forum has been considering this closely as we talk through the various aspects of this.

What that means in the case of product queues is that we simply can't dump crazy numbers of attachments into the scene "because that's how it works in real life." We need to be smart about this and come up with techniques that are convincing to the user while remaining reasonably efficient- whether that's by using a smaller number of attachments to start with, or having some technique to reduce the number of attachment points in the distance.

The current test builds have the ability to reduce the number of visible attachment points using LOD, but that doesn't necessarily make sense for cases where you would want to REPLACE the attachments with some kind of pre-combined geometry. If anyone has any thoughts in this direction, feel free to list them here for discussion. Perhaps a system where the entire queue of products is replaced by a single (LOD-capable) mesh at some distance- and the exact distance being a function of the user's graphical detail setting.

chris

rumour3
October 5th, 2015, 03:54 AM
Thanks Chris

Container wagons are a useful and very common case to look at. The actual traincar is usually pretty simple, and it would be very easy for it to get to a low number of polys at a reasonably short distance. The containers themselves are also easy to get down to 10-12 polys each. It should therefore be pretty easy to get the geometry of a loaded container wagon down to the normal traincar poly limit. If you were going to substitute a 'loaded asset' mesh for the whole traincar, the hard part is going to be representing the range of profiles of a partly loaded car, which (in the UK) may have one, two or three containers, and in a large variety of liveries. Any transition to a 'standard' loaded mesh is likely to be very noticeable, even at long range. Any system to combine meshes would therefore need to be clever enough to pull in the low LOD models of the specific loads being carried for each car.

R3

WindWalkr
October 5th, 2015, 05:06 AM
Container wagons are a useful and very common case to look at. The actual traincar is usually pretty simple, and it would be very easy for it to get to a low number of polys at a reasonably short distance. The containers themselves are also easy to get down to 10-12 polys each. It should therefore be pretty easy to get the geometry of a loaded container wagon down to the normal traincar poly limit.

Unfortunately it doesn't help with the number of draw calls, so it's not enough by itself. When you start talking about "large numbers of objects" and "LOD" in the same sentence, then it is necessary to find ways to reduce the number of objects, in addition to (or instead of) the per-object cost.



If you were going to substitute a 'loaded asset' mesh for the whole traincar, the hard part is going to be representing the range of profiles of a partly loaded car, which (in the UK) may have one, two or three containers, and in a large variety of liveries.

If you're talking about a vehicle which only supports three attachments, then I don't think you will be running into issues with draw-distance limits- at least not in hf2. As I mentioned before, the internal builds are different and haven't really had any significant testing in this area so I wouldn't use that as a talking point just yet.

It's still good if we can find a way to reduce those three, but it's by no means as important as on an object with twenty or more attachments.



Any transition to a 'standard' loaded mesh is likely to be very noticeable, even at long range. Any system to combine meshes would therefore need to be clever enough to pull in the low LOD models of the specific loads being carried for each car.

Not impossible to do, but not something we're likely to attack in the near future. We may be better off finding a way to transition cleanly between the highly-individualised "high detail" state, and a more generic "low detail" state.

chris

andi06
October 5th, 2015, 05:13 AM
If the issue revolves around two or three containers versus twenty sacks of grain would it not be possible to add an absolute size limit on rendered loads? Something like not rendering them at all if they are less than (pick a number) pixels wide at the current zoom.

whitepass
October 5th, 2015, 08:49 AM
Is the problem the number of attachments or the number of polys in the attached mesh? Most of the loads are not made by the car body maker.

Can we now use LOD on a load, did not work when I tried in TS12.

Pencil42
October 5th, 2015, 09:19 AM
While I like to use the :cull attachment points, there are times when it is a bit limiting - I would like to be able to cull things at different distances. Some small things or cargo in corners of a boxcar could get culled earlier, while cargo visible through the open doors would get culled later. It would also be nice to be able to turn some meshes 'off', perhaps via script. So, if enough of a car is loaded that some product meshes are hidden, then the hidden meshes would get culled.

Curtis

andi06
October 5th, 2015, 09:35 AM
From HF2 you can cull an attachment by omitting its attachment point from some of the LOD meshes.

For instance if you have a submesh named attachment attached to a.origin and a.origin is only present in the mesh for LOD-0 then attachment will be dropped as soon as LOD-1 cuts in.

If you do drop attachment points bear in mind that if they are present in a particular LOD they must also be present in all higher LODs.

In addition if an attached submesh uses an LM.txt file then that submesh can also use the renderCutOff flag with different values from those used in the parent asset.

WindWalkr
October 5th, 2015, 09:40 AM
Is the problem the number of attachments

This.



Can we now use LOD on a load, did not work when I tried in TS12.

As far as I'm aware, yes. If not, let me know and I'll get it looked at.

chris

Pencil42
October 5th, 2015, 10:41 AM
Can we now use LOD on a load, did not work when I tried in TS12.

LOD on loads has worked for a long time; but only with .lm.txt (as far as I know).

Curtis

rumour3
October 5th, 2015, 11:20 AM
Chris

It's the 'more generic "low detail" state' that will be quite difficult to achieve for a train like this:

https://youtu.be/5zMsjRFTGpQ
A very common situation in the UK. Even viewed 1km away, the gaps and colours are likely to be quite noticeable. Ideas please?

R3

andi06
October 5th, 2015, 11:32 AM
Overiride LM.text at the bottom end by cutting off attachments at a level which is based on the size of the load mesh bounding box.

norfolksouthern37
October 5th, 2015, 11:35 AM
yes container trains look absolutely ridiculous in TANE there is no way this will ever work for those and maintain the look. having them apparently load when they approach is about as far from desirable as you can get. I do like the system for other cars where you cant see the load coming at you but containers needlessly suffer and destroy the entire immersion.

rumour3
October 5th, 2015, 02:48 PM
I know Chris will hate the idea, because of the potential for abuse, but I think that a tag within the load that defines it as important to the visible traincar shape, and therefore prompts treatment, in LOD terms, exactly like a traincar asset, would be worth considering. In the 3 container traincar example, this would be like hauling the equivalent of four traincars for each loaded car, but this would surely be no worse than a consist with four different short wheelbase assets- a common situation for routes set in the steam era.

To prevent abuse by people who think their sack of corn needs to be viewed at 15km, or to prevent traincars using inefficient loads, a traincar asset could be flagged as an error if it has more than three or four attachments for products using this tag. Andi06's suggestion to use bounding box size could also be used as an error trap for loads trying to pretend they're more important than they are.

R3

WindWalkr
October 5th, 2015, 06:10 PM
To prevent abuse by people who think their sack of corn needs to be viewed at 15km, or to prevent traincars using inefficient loads, a traincar asset could be flagged as an error if it has more than three or four attachments for products using this tag.

The tag isn't necessary for something with three attachment points, because the draw distance limits shouldn't affect it anyway.

chris

WindWalkr
October 5th, 2015, 06:28 PM
It's the 'more generic "low detail" state' that will be quite difficult to achieve for a train like this:

https://youtu.be/5zMsjRFTGpQ
A very common situation in the UK. Even viewed 1km away, the gaps and colours are likely to be quite noticeable. Ideas please?

I'm not seeing any serious problem there. That's a single attachment per vehicle.

chris

ZecMurphy
October 5th, 2015, 06:58 PM
Something I have thought of with my current WIP insulated van is that a lot of loads only need to be visible in specific cases. Such as when doors are open, or when the tarp is turned off, or similar.

Could a mechanism be implemented that allows the visible loads to be turned off either via script (without emptying the queue!), or linked to something else (potentially queue size, for stacked objects - container farms being an example here), so as to reduce their impact. This, in addition to culling the attachments when visible, could reduce their impact.

rumour3
October 5th, 2015, 10:08 PM
I'm not seeing any serious problem there. That's a single attachment per vehicle.

chris
Look again at the last few cars...

WindWalkr
October 6th, 2015, 05:56 AM
Look again at the last few cars...

They look empty. Am I missing something obvious? :)

chris

WindWalkr
October 6th, 2015, 05:57 AM
Ah, I think you're talking about the few before that, with the two blue-green loads?

chris

Pencil42
October 6th, 2015, 08:47 AM
From HF2 you can cull an attachment by omitting its attachment point from some of the LOD meshes.

Thanks, Andi - I knew there was some talk about this, but didn't know when it was going to be implemented in a 'production' version.

Curtis

rumour3
October 6th, 2015, 10:14 AM
Ah, I think you're talking about the few before that, with the two blue-green loads?

chris

Yes. Possibly not the best example, but the point is that any car can have none, one or two (sometimes up to three) containers of varying sizes and in any position, in any livery. If the loaded state is to be modelled as part of the low detail traincar model, it will somehow need to get the size, position and livery of the specific combination of containers that are loaded, and use an appropriate mesh/texture. This sounds like it would need quite a bit of complex content creation at our end, or programming at yours.

Treating a container load like an individual traincar, with similar impact to up to four traincars, doesn't seem like too much of a compromise, when you think of it in comparison with the amount of work the game would have to do to display four short wheelbase wagons (only slightly longer actual train length, compared to a single container flat car) of the kind you may get in a long steam era freight train.

R3

WindWalkr
October 6th, 2015, 09:33 PM
Yes. Possibly not the best example, but the point is that any car can have none, one or two (sometimes up to three) containers of varying sizes and in any position, in any livery. If the loaded state is to be modelled as part of the low detail traincar model, it will somehow need to get the size, position and livery of the specific combination of containers that are loaded, and use an appropriate mesh/texture. This sounds like it would need quite a bit of complex content creation at our end, or programming at yours.

Yeah. Not something I'm particularly worried about in the short term because of the low counts involved. Long term we might be able to solve this with a form of mesh stitching. It's when the numbers start to ramp up that we get more concerned and start thinking short term.

chris

whitepass
October 7th, 2015, 09:14 AM
Is there a way to have just the unused attachment points culled, I know on my flat cars I have put in a lot as the number and size of loads can go from 1 to 7 for each load.

WindWalkr
October 7th, 2015, 09:22 AM
I'm not really clear on what you mean. If they're unused, then there's nothing to cull anyway.

chris

whitepass
October 8th, 2015, 09:52 AM
I have a flat car with 14 attachment points but you can only use 7 at the most and 1 at the lowest so I have from 7 to 13 a.loads not used, all 14 if empty. It is set to load 7 general goods, 2 lumber, 3 logs, 3 pipes, and 1 big load in the center. The attachments have to be in the right place to make the loads look right and most of the loads are built in ones.

WindWalkr
October 8th, 2015, 07:29 PM
I have a flat car with 14 attachment points but you can only use 7 at the most and 1 at the lowest so I have from 7 to 13 a.loads not used, all 14 if empty. It is set to load 7 general goods, 2 lumber, 3 logs, 3 pipes, and 1 big load in the center. The attachments have to be in the right place to make the loads look right and most of the loads are built in ones.

These are separate queues, so the only one relevant to this discussion is the 7 general goods. This one has enough attachments to be considered for early culling.

chris

whitepass
October 9th, 2015, 09:41 AM
Good to know, now what is the max number we can use 4, 5, or 6?

WindWalkr
October 9th, 2015, 09:24 PM
At the moment the magic safe number is 4, but that's an implementation detail. Obviously the lower you can keep any numbers, the better. I'm open to alternative techniques for tackling the issue of excessive load meshes. Other possible avenues include:

* Setting the maximum draw distance based on the number of items actually in the queue, rather than on the maximum size of the queue. I think this is more likely to be confusing, to the extent that it probably outweighs the minor benefits that it offers.
* Moving to a sliding scale where the maximum draw distance gets progressively shorter as the queue gets larger (with some minimum and some maximum, obviously.) This means that going one or two steps over the magic number would not immediately apply the full penalty.

If you've got other suggestions that could be implemented simply on both our side and yours, then feel free to offer them up.

chris

whitepass
October 10th, 2015, 08:52 AM
The sliding scale sounds good.

whitepass
October 12th, 2015, 09:34 AM
All ready getting post on this. I forgot the scenery part as I do not make them but a lumber yard that can only have 4 loads visible is not good and some Stations have 40 to 50 passengers.