PDA

View Full Version : Mesh Culling Techniques



andi06
September 26th, 2015, 05:38 AM
I realise that I may be lynched for starting yet another LOD related thread but here goes.

Some of these questions may seem a little weird so I'd better start off by giving you a context. With fixed track junction objects it will be quite important that the LOD scheme matches the scheme employed by procedural track as closely as possible, otherwise there will be obvious visual glitches.

The objects themselves will support stitching so, except for the animated blades, they will use mesh-table LOD. Like the tracks they will be split into separate mesh-objects so that a mix of texture-replacement and mesh swapping will be employed to enable them to be configured to match the tracks. The objects themselves vary widely in size, at LOD 0 this will be from about 4K polys up to (I'm guessing here) about 40K, regardless of this they will need to employ the same LOD scheme.

Assuming that mesh-detail-level-count is 4 then each submesh can be displayed at a single LOD level or, if the lod-level tag is omitted, it can be displayed at all LOD levels. There is no mechanism which will allow a mesh to be displayed at LODs 0 AND 1 but hidden at LODs 2 AND 3.

You've already stated that we can cull meshes in LM.txt by omitting their attachment points.

1. Can we use the same technique to control mesh visibility in mesh-table LOD schemes. This would enable a mesh to be displayed at LODs 0, 1 and 2 but hidden at LOD 3?

2. If the attachment point has a functional purpose in addition to being a mesh attachment point, will its function be affected if the helper point is culled? For instance if a.origin is used to attach a mesh and to define the location of an attached-trigger, will the function of the trigger be compromised if the attachment is missing at certain LOD levels?

3. Is it permissible to control the display of a mesh by introducing an attachment point which isn't present at a higher LOD? For example if we have a.origin which is present in the parent at LOD 3 and 4 only, and we have a submesh attached at a.origin, can we use this to define a mesh which will be visible ONLY at LOD 3 and 4?

4. Is an LM.txt file which looks like this going to be any problem? The file defines one animated blade mesh only but uses the animation and render cut off flags to suppress display at levels corresponding to LODs 3 and 4.



version 1.0
offset = 0.01;
calcPoint = center;
multiplier = 1.0;
animationCutOff = 0.50;
renderCutOff = 0.50;
attachmentCutOff = 0.00;
mesh("1.00") {
name="blade.im";
}


5. At the moment I have two mesh libraries, one for the tracks and one for the junctions. Nevertheless both sets of objects use exactly the same textures and exactly the same materials. I assume that since the material sources are in different assets they will not stitch together?

These questions may have a wider application. One of the complaints about mesh-table LOD is that the lower LODs are cutting in too early. I think the real issue is that, for some objects such as buildings, what is really required for visual purposes is for LODs 0 and 1 to be served by the same mesh.

Mike10
September 26th, 2015, 06:24 AM
3. Is it permissible to control the display of a mesh by introducing an attachment point which isn't present at a higher LOD? For example if we have a.origin which is present in the parent at LOD 3 and 4 only, and we have a submesh attached at a.origin, can we use this to define a mesh which will be visible ONLY at LOD 3 and 4?

I've been seeing these errors on some of my content in build 78602, so that leads me to believe that may not work.

"- LoadE2MeshObjectLMTXT> LOD of 'body/body_2.lm.txt' introduces new attachment point: a.door2 "

Resolved by removing the relevant attachment point from the lower LOD.

Not tested for this though;


You've already stated that we can cull meshes in LM.txt by omitting their attachment points.

whitepass
September 26th, 2015, 10:03 AM
You've already stated that we can cull meshes in LM.txt by omitting their attachment points.


Where did that come from, if I omit an attachment point I get Errors, did this in TANE on a under 500 poly LOD.

clam1952
September 26th, 2015, 11:30 AM
Where did that come from, if I omit an attachment point I get Errors, did this in TANE on a under 500 poly LOD.

Same here I actually had one missing in a lod mesh for one of my items I imported into T:ANE which promptly informed me it was missing. TS12 didn't seem to be bothered by it being missing though.

andi06
September 26th, 2015, 11:39 AM
Where did that come from, if I omit an attachment point I get Errors, did this in TANE on a under 500 poly LOD.

Stay awake folks, it comes from here (http://forums.auran.com/trainz/showthread.php?121687-LOD-and-attachment-points-question&p=1425531#post1425531) and from a later confirmation (that I can't find at the moment) stating that it would be ok to omit attachment points in the lower LODs - and it does work in the Dev builds, probably not in 76401. Actually I should stay awake too because the same post explains why introducing new points isn't going to work.

I'm just exploring options here, not making any statements.

Assuming that this sort of additional flexibility would be possible and useful, could lod-level be implemented as an integer array, as in lod-level 1,2 meaning that this mesh would be visible at 1 and 2 but hidden at 0 and 3?

pcas1986
September 26th, 2015, 03:22 PM
?..
Assuming that this sort of additional flexibility would be possible and useful, could lod-level be implemented as an integer array, as in lod-level 1,2 meaning that this mesh would be visible at 1 and 2 but hidden at 0 and 3?

First up no discussion on LOD is ever wasted - there is more to learn.

I was left with the impression that any given attachment mesh LOD was independent of it's parent LOD system.

But I rather like the idea of specifying when an attachment mesh level is visible RELATIVE to the parent LOD level. This seems to be related to questions posed by Mike10 in another thread.

Sorry, I don't enough about fixed track to respond to the original question.

andi06
September 26th, 2015, 04:11 PM
I was left with the impression that any given attachment mesh LOD was independent of it's parent LOD system.
I don't think that can be true because mesh-detail-level-count is at the top level of config and must therefore apply to the entire mesh-table.


Sorry, I don't enough about fixed track to respond to the original question.
As far as LOD is concerned they are the same as any other scenery object.

VinnyBarb
September 26th, 2015, 06:05 PM
Just to get this straight, will this mean it will now be possible to exclude (cull) any not needed attachment points in lesser LODs, to lower the overall 500 triangle limit for the lowest LOD? If so, I guess, this will be via the LM.txt file for traincars, like "cull attachment point a.xx" etc.. If this is indeed the case, this will resolve all my previous objections and protests re including all attached meshes in the 500 triangle count limit for the lowest LOD. Or is this under discussion only and hopefully this can be implemented for TANE?

I am here only concerned for creating locomotives and rolling stock as this is where I create for.

VinnyBarb

WindWalkr
September 26th, 2015, 07:59 PM
You've already stated that we can cull meshes in LM.txt by omitting their attachment points.

1. Can we use the same technique to control mesh visibility in mesh-table LOD schemes.

I don't think so, no. You're likely to run into some undefined behaviour if you try this, but the short version is that mesh-table visibility is separate from mesh-table LOD. A mesh can be flagged as visible (in which case, it's children may also be visible) without being at the appropriate LOD to actually render.



2. If the attachment point has a functional purpose in addition to being a mesh attachment point, will its function be affected if the helper point is culled?

No, although in more complex cases you could find yourself exposing undefined internal details, such as whether an animation on an invisible mesh continues to play.



3. Is it permissible to control the display of a mesh by introducing an attachment point which isn't present at a higher LOD?

You're thinking in terms of LM, but (as far as I understand) you're still talking about mesh-table LOD.

Mesh-table LOD doesn't introduce or remove any meshes, or even change them to suit the LOD, it simply hides and shows them. If you have an attachment point on mesh #3, changing LOD isn't going to make it go away (and vice versa.)



4. Is an LM.txt file which looks like this going to be any problem? The file defines one animated blade mesh only but uses the animation and render cut off flags to suppress display at levels corresponding to LODs 3 and 4.

As long as you pass validation, you should be fine.



5. At the moment I have two mesh libraries, one for the tracks and one for the junctions. Nevertheless both sets of objects use exactly the same textures and exactly the same materials. I assume that since the material sources are in different assets they will not stitch together?

Correct. If they're separate files, Trainz will not consider them to be related.

chris

andi06
September 27th, 2015, 03:33 AM
To match the behaviour of the track assets I would need to provide two ballast meshes: (a) 12 polys visible at 0, 1 & 2 and (b) 2 polys visible at 3 (this mesh is actually rendering the entire asset not just the ballast).

The only way that I could specify this is:

mesh-detail-level-count 4
mesh-table {
0 {
lod-level 0
mesh ballast-A
}
1 {
lod-level 1
mesh ballast-A
}
2 {
lod-level 2
mesh ballast-A
}
3 {
lod-level 3
mesh ballast-B
}
... submeshes for other components
}

1. I assume that, since validation can't know which submeshes are related, it won't be trying to apply a 20% reduction per level check?
2. Does validation get upset if the same submesh is specified in more than one container?
3. Would this cause any other issues?


Assuming that this sort of additional flexibility would be possible and useful, could lod-level be implemented as an integer array, as in lod-level 1,2 meaning that this mesh would be visible at 1 and 2 but hidden at 0 and 3?
Did you miss this question or are you thinking about it?

[Edit]
Re Q1: You seem to be actually totalling up every lod so this is applied overall rather than per submesh
Hence I get the message: - The meshes in LOD level 2 must total at least 20% fewer polygons than the next higher LOD: 0: 4445, 1: 0, 2: 0, 3: 0
Fair enough, although I might point out that 20% fewer than zero is either zero or a mathematical absurdity :-)

Re Q2: You don't seem to mind duplication of meshes

WindWalkr
September 27th, 2015, 08:04 PM
To match the behaviour of the track assets

I don't really understand what you're trying to do here, to be honest. You don't typically need (or want) to match LOD transitions between separate objects. The important thing is that the LOD change shouldn't substantially change the appearance of the object.



1. I assume that, since validation can't know which submeshes are related, it won't be trying to apply a 20% reduction per level check?

I would think that this would be applied at the asset level, not per mesh. So it doesn't care about whether the submeshes are related.



2. Does validation get upset if the same submesh is specified in more than one container?

No. However, if it thinks you're trying to cheat the LOD system, it may get unhappy.



3. Would this cause any other issues?

It lowers performance.



- The meshes in LOD level 2 must total at least 20% fewer polygons than the next higher LOD: 0: 4445, 1: 0, 2: 0, 3: 0
Fair enough, although I might point out that 20% fewer than zero is either zero or a mathematical absurdity :-)

Yeah, that isn't right at all. On the flipside, if you tell it to expect four LODs and only provide one, you may want to rethink your asset :)

chris

andi06
September 28th, 2015, 02:25 AM
I don't really understand what you're trying to do here, to be honest.
The mesh-table LOD config syntax allows me to specify that a submesh is either:
- 1. Visible at all LOD levels
- 2. Visible at a single level only.
- 3. There is no way to specify that a submesh is visible at 0, 1 and 2 but dropped entirely at 3.

To achieve what I want to achieve I need to split the asset into four different submeshes and I can easily achieve an overall lowest LOD of 1 draw call and 2 polys, but the syntax of mesh-table LOD is preventing from doing this.


You don't typically need (or want) to match LOD transitions between separate objects. The important thing is that the LOD change shouldn't substantially change the appearance of the object.
For a standalone asset I would agree with you entirely, however these assets are so closely related to tracks that a reasonable match is essential.

I have this working to a degree which will hopefully illustrate my points. I will send it to you later today.

WindWalkr
September 28th, 2015, 03:03 AM
For a standalone asset I would agree with you entirely, however these assets are so closely related to tracks that a reasonable match is essential.

I don't see how the relationship with tracks is relevant. It either individually looks good, or it doesn't. Unless they shape is changing substantially (which it shouldn't) the fitting between the various components will not be affected by LOD.



I have this working to a degree which will hopefully illustrate my points. I will send it to you later today.

thanks.

chris

andi06
September 28th, 2015, 03:43 AM
I don't see how the relationship with tracks is relevant. It either individually looks good, or it doesn't.
Tracks are a special case for LOD, in a particular scene a track asset may well be simultaneously visible at all of its LOD levels and the junction between one level and the next can be glaringly obvious at some viewing angles. Believe me it is impossible to achieve a track LOD scheme which will work perfectly at any angle.

I have anti-aliasing turned right down here to exaggerate the effect, and its difficult to capture in a screenshot anyway, but hopefully this will show what I mean (all of the objects here use the same scheme but have slightly different cut off levels):

807

WindWalkr
September 28th, 2015, 08:38 AM
I think you might have something more going on there than just LOD. Anyway, I'll check out the asset you sent in and get back to you.

chris