I rather suspect that cleaning up all of our dodgy lod-trees would give a significant improvement, especially since most of us just copy them from another asset without really comprehending what they do.

pcas1986

June 5th, 2015, 07:08 AM

Surely that should throw an error such as "there is no visible asset"!

I agree its a bit woolly.

andi06

June 5th, 2015, 07:11 AM

CMP for trainz-build 4.2 is perfectly happy with it :-)

andi06

June 5th, 2015, 07:17 AM

What I'm half thinking about is to write a track-lod-tree editor for AssetX which would take a table of conditions (in human understandable format) such as lod-distance, lod=length and subdivisions, together with the meshes to meet those conditions and then produce a track-lod-tree from that table.

I've no clear idea how this could be done and its further hampered by the fact that I'm not sure that I fully understand all of the possible options.

clam1952

June 5th, 2015, 07:40 AM

I have seen working splines that have no lod with lod-trees full of nothing.
A simple very low poly spline doesn't need any of it other than.

track
{
mesh-length 5
adjust-cross-section-to-ground 0

track-lod-tree
{
mesh "default"
}
}

WindWalkr

June 5th, 2015, 07:55 AM

Surely that should throw an error such as "there is no visible asset"!

Somebody would be sure to complain that it was deliberate for some reason ;-)

chris

WindWalkr

June 5th, 2015, 07:57 AM

What I'm half thinking about is to write a track-lod-tree editor for AssetX which would take a table of conditions (in human understandable format) such as lod-distance, lod=length and subdivisions, together with the meshes to meet those conditions and then produce a track-lod-tree from that table.

I've no clear idea how this could be done and its further hampered by the fact that I'm not sure that I fully understand all of the possible options.

Sounds great in principle. The biggest difficulty here really is that the system is very expressive. Understanding how best to use it all is an optimisation problem- there's no singular correct answer, but rather a number of different variables which affect how well the track looks and performs under a wide variety of input scenarios.

I think the biggest win would not be on the editing side, but rather being able to display a visual indicating exactly how the track has broken up and what part of the table corresponds with what part of the spline.

chris

martinvk

June 5th, 2015, 08:16 AM

The biggest difficulty here really is that the system is very expressiveSounds like a great candidate for a fully documented guide or wiki. since as you say
there's no singular correct answer, but rather a number of different variables which affect how well the track looks and performs under a wide variety of input scenarios clearly describing what each part and tag actually does and how they are interrelated would go a long way to helping potential and actual content creators. Trial and error is fine as far as it goes but the waste of time and effort is enormous that could be better spent in actually creating assets. There are already bits and pieces of this information scattered around. It needs to be consolidated and polished to make it easy to read and understand.

WindWalkr

June 5th, 2015, 08:42 AM

Sounds like a great candidate for a fully documented guide or wiki. since as you say clearly describing what each part and tag actually does and how they are interrelated would go a long way to helping potential and actual content creators. Trial and error is fine as far as it goes but the waste of time and effort is enormous that could be better spent in actually creating assets. There are already bits and pieces of this information scattered around. It needs to be consolidated and polished to make it easy to read and understand.

The track-lod-tree format is concisely and (as far as I'm aware, excepting the very latest additions) completely documented on the appropriate wiki pages. It's a complex topic, and could really do with a lot of different examples, but the tags should all be documented and their intended usage explained. The difficulty is not in knowing what the individual tags do, it's understanding what that allows you to do when you put it all together.

The best way to learn this stuff is to actually use it. If you hit a stumbling block, ask for help, and I'll make sure that the necessary information is made available. If you have problems understanding something on the wiki, then when you finally grok it, it's worth noting down what your confusion was and how you eventually overcame it- that could be invaluable for people who later follow the same path.

...
I think the biggest win would not be on the editing side, but rather being able to display a visual indicating exactly how the track has broken up and what part of the table corresponds with what part of the spline.

chris

Deane and I tried to do this with this How/To for a fence spline (http://online.ts2009.com/mediaWiki/index.php/HowTo/Create_a_Fence_Spline_Featuring_LOD_and_Random_Mes hes) although much of the discussion is about the randomness of the tag lod-random-bias. In the procedural track I have been playing with, I deliberately used brightly coloured lod schemes so I can see where lod kicks in. With procedural track that is much more predictable.

There is quite a lot of technical data on the WiKi for track but the problem is that it is not in plain speak. The How/To for procedural track tutorial (not mine) is quite good IMHO. :o)

Tested examples, with explanations, are always going to be the best way to go.

martinvk

June 5th, 2015, 09:30 AM

I thought that I said that.

The difficulty is not in knowing what the individual tags do, it's understanding what that allows you to do when you put it all together.
Most tags are pretty well defined. It's how they are interrelated that is the major stumbling block.

For example:
Why should a specific value for lod-distance be selected? How does it relate to mesh sizes, subdivisions, etc?
Why should more or less subdivisions be used? How do they relate to mesh sizes, lod-distance, etc?
With the new procedural track and many of its parts moved to separate meshes, should the lod-distances, subdivisions be synchronized?

Not looking for specific answers here but it is things like this that I find puzzling. Often an existing track-lod-tree is just reused blindly. It usually works but is it well tuned to the specific asset? Probably not. That is where better documentation would go a long way to getting better assets.

Learning by using is all well and good but if a new creation starts on the wrong track, having to back out and restart is not very efficient nor fun.

martinvk

June 5th, 2015, 09:41 AM

Grey = query
Orange mesh
Yes = left hand sub node
No = right hand sub node
That is a nice representation of the lod-tree, quite easy to understand.
Is there a simple relationship between the d values? They are now in a ratio of 4: 2.2: 4.5 Is that significant?
The corresponding mesh length ratios at ~:3:2 Should they be related

WindWalkr

June 5th, 2015, 07:13 PM

Why should a specific value for lod-distance be selected?

That's up to the specific effect you're trying to create. You obviously want the distances to be as far forward as possible without compromising the graphical quality.

How does it relate to mesh sizes, subdivisions, etc?

There is no direct relationship. As you move further away from the camera, you're going to want to represent more physical space with less polygons- there are a number of separate techniques here including using meshes which offer lower detail, replacing several subdivisions with a single mesh, and so on- but specifying this is all up to you.

Why should more or less subdivisions be used?

Performance. The more of everything you have, the lower the performance.

How do they relate to mesh sizes, lod-distance, etc?

If you take a certain interval (say, 20m) and subdivide it by 4, then the resultant interval is 5m. This means that where you were building 20m-long meshes before the subdivision, you should be building 4m-long meshes after the subdivision.

As above, there is no direct relationship with lod-distance. You would choose to subdivide more finely where more detail is required, such as close to the camera or where the track's curvature is changing rapidly.

With the new procedural track and many of its parts moved to separate meshes, should the lod-distances, subdivisions be synchronized?

There is no hard requirement, so experiment for yourself. You can avoid certain problems by doing this, but it's not guaranteed that there will be problems if you don't do this- it all depends on how your specific asset is constructed.

Not looking for specific answers here but it is things like this that I find puzzling.

I understand that. I've provided some answers anyway, but as you can see it ends up being fairly obvious, fairly general advice. The real answers come when you actually build something and find out the limitations of your own object.

It's a very flexible system, which unfortunately also means that there is no "one size fits all" system which takes full advantage of the capabilities. Depending on the time you're willing to spend and your level of expertise, you can either make something that works but doesn't take full advantage of the system, or you can spend time tinkering to best optimise for your specific requirements. This is exactly what we do when building splines- we come up with the highest LOD mesh and some basic ideas for how it should LOD, then create a LOD tree and appropriate LOD meshes and tweak it until we're happy that everything is working and looks good. If the spline is quite different from anything we've made before, this can be time consuming and can mean rebuilding the meshes a few times until we're happy with the result.