PDA

View Full Version : internal test build 77508



WindWalkr
July 28th, 2015, 12:03 AM
Hi all,

New test build available. A number of changes, but again most importantly I'd like feedback on validation as we're hoping to update the DLS validation tools soon.

The majority of the LM features are now working, so the people playing with LOD should be able to start testing against these. The asset preview window has been improved but is still not finalised- most importantly, don't trust the LOD override control. 3D Text coloration may be fixed. Automatic distance culling of various systems is a little bit smarter but still not finished; feedback is welcome.

chris

pcas1986
July 28th, 2015, 02:03 AM
.. 3D Text coloration may be fixed. ..

chris

Is this the problem with the wrong colours being displayed on signs, etc? MartinVK, I think, reported this a few days ago although I recall it was reported back in the pre-release betas.

rumour3
July 28th, 2015, 02:06 AM
Another bad start on this build. Installed. Changed launcher settings- shadows low, Use PhysX on, Process objects behind camera on. Restart. Launch TANE, skip tutorials. Load ECML freightliner session, click OK on first session pop up. Select DCC control. Select drive, crash to desktop. No crash dump. Happened twice now.

R3

rumour3
July 28th, 2015, 02:28 AM
Persevered. Can run Hinton at reasonable framerates (mid 20s) without crashing. ECML Freightliner crashes as soon as I start to drive. Load culling still unacceptable- the wagons at the back of the train are without their loads when viewed at the same zoom level as the locos at the start of the session.

Preview viewer works ok, although I've noticed that my current project goes from a draw call of 34, 84190 triangles, down to 2, 461 triangles, but if I keep zooming out, the draw call count goes back up to 10, 477 triangles. At this point the object is a dot.

R3

pcas1986
July 28th, 2015, 07:58 AM
This is encouraging. I bumped my project loco to build 4.2 and only got this error:

- Indexed meshes are not supported for traincars as of trainz-build 3.8. It is recommended that you upgrade 'shadow.im' to a LOD mesh.
So, it looks as if the culling is working, at least for bogies. All my attachments are LM. I'm not sure what to do about the shadow mesh. For the purposes of being able to build to 4.2 I'm happy to make a LM version even if it isn't used.

WindWalkr
July 28th, 2015, 07:59 AM
Preview viewer works ok, although I've noticed that my current project goes from a draw call of 34, 84190 triangles, down to 2, 461 triangles, but if I keep zooming out, the draw call count goes back up to 10, 477 triangles. At this point the object is a dot.

Thanks. This is a known issue and should be fixed in the next build. You're seeing a few UI elements being rendered when you zoom out to extreme range.

That's a good reduction. You should ideally try for a single draw call in the lowest LOD, it makes a lot of difference. 84k polys close-up is quite a bit, I hope you're able to drop that pretty rapidly :)

Have you played with the performance analysis mode?

chris

WindWalkr
July 28th, 2015, 08:03 AM
Another one to watch out for is that you don't leave the majority of reduction to the last LOD. We obviously validate this to some extent for the polygon counts, although realistically our validation is VERY conservative and you should exceed that by a fair margin. We don't current validate this for draw calls, but you obviously don't want to hang on to the full 34 for the mid-level LODs. (Although I must say that 34 is a very decent starting number if we're talking about a loco.)

chris

andi06
July 28th, 2015, 08:13 AM
Have you played with the performance analysis mode?
Doesn't seem to be working, none of the drop down lists are populated.

pcas1986
July 28th, 2015, 08:37 AM
In my test loco I'm going from ~75,000 polys with a draw call of 48 at LOD0 down to 454 polys with a draw call of 6. The lowest LOD is a 4 sided box. I have LOD markers so I can tell where the transitions are.

andi06
July 28th, 2015, 08:41 AM
Preview Asset reads my Autocoach model correctly, including wheel placement on the bogies.

However if the bogie is loaded in its own right we see the bogie frame with both axles overlaid and centred on the origin.

If this were in game it would usually mean that the game can't find anim.kin.

WindWalkr
July 28th, 2015, 09:29 AM
Doesn't seem to be working, none of the drop down lists are populated.

Okay, must be a windows thing. Working fine for me. I'll get it fixed for the next build.

chris

WindWalkr
July 28th, 2015, 09:31 AM
Preview Asset reads my Autocoach model correctly, including wheel placement on the bogies.

However if the bogie is loaded in its own right we see the bogie frame with both axles overlaid and centred on the origin.

If this were in game it would usually mean that the game can't find anim.kin.

Bogeys aren't a placeable asset, so the preview simply reads the mesh table and doesn't try to apply any domain-specific adjustments. What it renders is what you'd see if you created a scenery object or attached mesh with the same configuration.

chris

WindWalkr
July 28th, 2015, 09:32 AM
In my test loco I'm going from ~75,000 polys with a draw call of 48 at LOD0 down to 454 polys with a draw call of 6. The lowest LOD is a 4 sided box. I have LOD markers so I can tell where the transitions are.

Work on getting that low LOD down toward 1 draw call :)

Andi can maybe share some tips.

chris

rumour3
July 28th, 2015, 11:07 AM
Thanks. This is a known issue and should be fixed in the next build. You're seeing a few UI elements being rendered when you zoom out to extreme range.

That's a good reduction. You should ideally try for a single draw call in the lowest LOD, it makes a lot of difference. 84k polys close-up is quite a bit, I hope you're able to drop that pretty rapidly :)

Have you played with the performance analysis mode?

chris
Most of the polys are in the modelled rivets, louvres, springs- these go at the first LOD change. The model is this one: https://www.flickr.com/photos/rumour3/19878133908/in/dateposted-public/
I'm away from my computer now for a couple nights, but I'll look at the performance analysis mode when I get home. Is it possible to get to a single draw call and still have two materials in the lowest LOD (for the reasons explained in my other thread)?

On the draw calls for the top LOD, I looked again and the number did vary as I panned around- 34 was when looking at the rear, but I think it was around 43 when viewed from the front. I'm not 100% sure, but I think it might have been displaying the second LOD in the rear view, but at the same distance as the top LOD when seen from the front.

There's a fair bit of optimising still to do (Blender's decimate modifier is a joy to use) but I'm hoping it's on the right lines.

R3

andi06
July 28th, 2015, 12:19 PM
I'm getting 'low-detail meshes total more than 500 polygons' on all of my procedural track sub-components. I'm seeing the same error if I open any of the built-in procedural track assets and re-commit.

The arithmetic appears to be correct (depending on how its calculated) but I don't see how these objects can ever meet this requirement, given the asset specs and the number of listed submeshes.

Once again though, there is no need to break the game for this, it should be a warning only.

andi06
July 28th, 2015, 12:27 PM
No big deal but:


Bogeys aren't a placeable asset
Agreed but I don't think that means that it won't be useful to view them.


What it renders is what you'd see if you created a scenery object or attached mesh with the same configuration.
Not quite, in the latter case the wheels would be in the right place.

This bogie convention about not specifying an animation in the mesh-table but requiring anim.kin to be present cause a lot of confusion, would it not be helpful to allow the same mesh-table syntax as any other animated asset, even if the anim.kin thing continues to be acceptable?

andi06
July 28th, 2015, 12:41 PM
Is it possible to get to a single draw call and still have two materials in the lowest LOD (for the reasons explained in my other thread)?
The answer would seem to be no.

martinvk
July 28th, 2015, 12:57 PM
I'm getting 'low-detail meshes total more than 500 polygons' on all of my procedural track sub-components. I'm seeing the same error if I open any of the built-in procedural track assets and re-commit.

The arithmetic appears to be correct (depending on how its calculated) but I don't see how these objects can ever meet this requirement, given the asset specs and the number of listed submeshes.

Once again though, there is no need to break the game for this, it should be a warning only.Is that because you have all the sub-components in a single mesh file? When I split them into separate logically related files I seem to have avoided that type of error at the cost of multiple kuids and possibly a game efficiency cost too? But easier to update different parts and submit the changes in CM. Will test my theory when I get home.

andi06
July 28th, 2015, 01:16 PM
No. The mesh-library itself (84 meshes) is validating without problems.

Its the next level sub component assets which are being rejected.

For Chris' benefit here are the kuids, all on the DLS

<kuid:122285:80010> Protrack rail-flat-bright-left
<kuid:122285:80011> Protrack rail-flat-bright-right
<kuid2:122285:80012:1> Protrack rail-flat-rusty-left
<kuid2:122285:80013:1> Protrack rail-flat-rusty-right
<kuid:122285:80014> Protrack rail-bullhead-bright-left
<kuid:122285:80015> Protrack rail-bullhead-bright-right
<kuid:122285:80016> Protrack rail-bullhead-rusty-left
<kuid:122285:80017> Protrack rail-bullhead-rusty-right
<kuid:122285:80020> Protrack chairs-pandrol-left
<kuid:122285:80021> Protrack chairs-pandrol-right
<kuid:122285:80022> Protrack chairs-bullhead-left
<kuid:122285:80023> Protrack chairs-bullhead-right
<kuid:122285:80050> Protrack conductor-third
<kuid:122285:80051> Protrack conductor-fourth

martinvk
July 28th, 2015, 02:46 PM
You must be doing things a bit differently because I thought all the rails, chairs etc were in the mesh library. Your list looks a bit like my multiple meshes except that I grouped the rails together in one mesh, the chairs in another mesh, etc. Or are these replacements of some of the 84 items in your mesh library, thus allowing you to easily substitute one of another?

andi06
July 28th, 2015, 02:50 PM
I'm using the same basic setup as Auran. All of the actual meshes are in a separate mesh-library which is validating without problems.

These assets are those which describe the attached-spline sub-components which are used in turn by the placeable track assets.

martinvk
July 28th, 2015, 06:11 PM
Looks like we're turning on nomenclature here.
My basic folder structure is
723

And in the various mesh folders, are the following IM files and their associated files
724

The six folders without the mesh numbers only contain a config file, describing the track and its parts as well as the thumbnail jpg. Before when I only had one mesh folder, I would get poly size errors when I increased the build number to 3.9. Now with 11 mesh folders, the poly error has gone away but sometimes by also artificially increasing the the poly count in LOD0 and LOD1 to get the required reductions.

ianwoodmore
July 28th, 2015, 07:53 PM
Took three attempts to download this build. Unknown network error.

Probably a polite way of indicating that we are competing with WIN10 Retail for bandwidth this morning in NZ.

You Tube videos affected so not just TANE.

I expect we will have slow internet for a week or more.


WIN10 instal was very smooth and uneventful.

Currently only on my AMD Phenom 2 machine which is abysmal for Trainz and TANE. That machine was on Insider Fast Ring for updates. My other two machines await normal Windows update from WIN 8.1 Update.



I haven't transferred Trainzdev 77508 onto the AMD machine yet, so no indications as to if better or worse.

On Intel machine I'm getting good FPS (60+) for 77508 for Hinton and Kickstarter, but ECML Freightliner dumped me twice as I moved off. As Whitepass has mentioned the container culling looks ridiculous and is very evident at 2 x height of telephone poles.

WindWalkr
July 28th, 2015, 07:56 PM
The arithmetic appears to be correct (depending on how its calculated) but I don't see how these objects can ever meet this requirement, given the asset specs and the number of listed submeshes.

As always, if you've got a problem asset, send it over for us to look at.

chris

WindWalkr
July 28th, 2015, 07:59 PM
Agreed but I don't think that means that it won't be useful to view them.

True. It just means that the viewer will have to make assumptions about how they would be used (since it lacks the context that will be present when they're actually used in game.)



This bogie convention about not specifying an animation in the mesh-table but requiring anim.kin to be present cause a lot of confusion, would it not be helpful to allow the same mesh-table syntax as any other animated asset, even if the anim.kin thing continues to be acceptable?

It would, but it would also break compatibility with existing assets. We could introduce this at a particular trainz-build version, but that adds confusion in its own right. Not saying we won't do this at some point, but that's the problem with the approach.

chris

WindWalkr
July 28th, 2015, 08:01 PM
No. The mesh-library itself (84 meshes) is validating without problems.

Its the next level sub component assets which are being rejected.

For Chris' benefit here are the kuids, all on the DLS

<kuid:122285:80010> Protrack rail-flat-bright-left
<kuid:122285:80011> Protrack rail-flat-bright-right
<kuid2:122285:80012:1> Protrack rail-flat-rusty-left
<kuid2:122285:80013:1> Protrack rail-flat-rusty-right
<kuid:122285:80014> Protrack rail-bullhead-bright-left
<kuid:122285:80015> Protrack rail-bullhead-bright-right
<kuid:122285:80016> Protrack rail-bullhead-rusty-left
<kuid:122285:80017> Protrack rail-bullhead-rusty-right
<kuid:122285:80020> Protrack chairs-pandrol-left
<kuid:122285:80021> Protrack chairs-pandrol-right
<kuid:122285:80022> Protrack chairs-bullhead-left
<kuid:122285:80023> Protrack chairs-bullhead-right
<kuid:122285:80050> Protrack conductor-third
<kuid:122285:80051> Protrack conductor-fourth

Thanks. I'm not clear on what I'm actually supposed to be looking at from this lot? Is one of these the parent asset?

chris

martinvk
July 28th, 2015, 09:19 PM
Got 77508 in just before the big Win10 push. Did N3V slip in some optimizations? I ran a selection of built-in sessions and the FPS up in the high 50's [ 56 to 60] and the GPU load is from 56 -95%, averaging in the low 80's and the GPU temperature barely in the high 50's. All this on only a GTX 750 running windowed 1920 x 1200.

725726727728

Just when I thought, wow this is great, I placed a set of BNSF Dash 9-44CW WB's in a new Kickstarter session. Clicked on the lower right lead engine and gave it a Drive command. Clicked on the upper left lead engine and CTD. Restarted, repeated and again, CTD. Finally just clicked on the upper left lead engine and tried to spin around it to see if the invisible door issue had been repaired and before I knew it, again CTD. Restarted, same result. Hmm, something about that engine that they don't want me to see?
729

pcas1986
July 29th, 2015, 01:09 AM
Work on getting that low LOD down toward 1 draw call :)

Andi can maybe share some tips.

chris

I will, but I'm using this particular project (loco) as a test case to further my understanding of the whole LOD puzzle (LM version). I actually thought I understood it a while back but the goal posts keep moving. :o

Like R3 I'm also getting varying draw calls when an asset is rotating. In one case it varies from 1 to 13 after a half turn (180 degrees). Should we take the worse case figure?

It's all rather interesting from a creator's perspective.

andi06
July 29th, 2015, 04:30 AM
Thanks. I'm not clear on what I'm actually supposed to be looking at from this lot? Is one of these the parent asset?

This is a list of all the Protrack assets, the mesh-library and the placeable tracks (<kuid:122285:80090> onwards) are OK.

730

The tagged assets are those which validation is complaining about. They are the non-placeable attached-spline definitions for rails and chairs.

If I open the corresponding built-in assets from the Auran TANE track and re-commit, the same 500 poly message is produced.

Everything is on the DLS.

andi06
July 29th, 2015, 04:35 AM
Like R3 I'm also getting varying draw calls when an asset is rotating. In one case it varies from 1 to 13 after a half turn (180 degrees). Should we take the worse case figure?
You will get results which are consistent with those that Chris is talking about by stopping the rotation in a standard three-quarter view and zooming in and out from there. At the moment you can't rely on the figures for the lowest LOD - these will read slightly higher than they should do.

andi06
July 29th, 2015, 04:43 AM
It would, but it would also break compatibility with existing assets. We could introduce this at a particular trainz-build version, but that adds confusion in its own right. Not saying we won't do this at some point, but that's the problem with the approach.

No, I'm suggesting that you use the kin file defined in the mesh-table if it exists - if it isn't there then you look for anim.kin.

This would allow the asset to be defined in the same way as anything else while still using the old format as a fallback.

clam1952
July 29th, 2015, 05:19 AM
Validation is now picking up incorrectly named attachments in lod meshes, ones I have come across were config typos O for o L for l. Looks like attachment names are case sensitive? Also picking up missing attachments in lod meshes which it wasn't in TS12 or Release T:ANE.

pcas1986
July 29th, 2015, 05:25 AM
... At the moment you can't rely on the figures for the lowest LOD - these will read slightly higher than they should do.

Yes. I made a test asset of Suzanne (test monkey in Blender) with poly figures of 15744, 10,000, 5,000 and 450. These give a nice linear slope. Draw calls start at 2 and eventually swaps to 1 but when at pinprick size it becomes 9.

LOD changes are still inconsistent with values in the LM.TXT file.

andi06
July 29th, 2015, 05:53 AM
When you look at an actual traincar asset the picture becomes a little more confused. Rather than a clear progression through the parent asset LODs you will be looking at a combination of the traincar together with its bogies and other attachments - these are all likely to have different cut-off points.

My test asset is a loco with LOD values of 11744 / 5951 / 2283 / 182 with 2 bogies and various other attachments and effects.

In Preview this shows up as: (Draw calls, polys)

34,21851
34,19534
28,18595
28,16526
26,14679
26,8886
24,7039
24,3371
5,2287 // attachment culling kicks in just before here
3,186 // which should in fact be 1,182

There isn't any way at present of correlating these statistics with the actual LOD zoom values.

pcas1986
July 29th, 2015, 06:30 AM
When my test loco is at its lowest LOD in Preview Asset it's still showing bone count as 2 after dropping down from over a 100 (it's a complex animation). The draw count is 3. If the animation has been dropped or culled at that point shouldn't the bone count be zero?
I'm wondering if this is affecting the draw count at that level. i.e. your WiKi article says each bone gets its own chunk and each chunk gets a draw call.

andi06
July 29th, 2015, 07:38 AM
I'm also seeing bones at the lowest LODs when all animation has been hidden or culled, but these don't seem to affect draw calls.

It looks like the bone count is including visible bones regardless of whether or not they are actually active.

whitepass
July 29th, 2015, 09:11 AM
The loadable commodities at interactive scenery are also disappearing/appearing to soon, drive into the old Sea Port and logs, lumber, caol, and sand pop up.

andi06
July 29th, 2015, 03:56 PM
Here is one that may be related to the 'bogie in preview' issue. I've been seeing this same problem when this traincar is first placed in game:

731

As you can see both wheels are placed at a.bog#. Its not permanent, zoom in and out a bit and the bogie will correct itself.

After a bit of poking about it turns out that the reason seems to lie in the bogie's lm.txt:



version 1.0
offset = 0.01;
calcPoint = center;
multiplier = 1.0;
animationCutOff = 0.60;
renderCutOff = 0.00;
attachmentCutOff = 0.00;

mesh("0.30") {
name="bogie-2.im";
}
mesh("0.60") {
name="bogie-1.im";
}
mesh("1.00") {
name="bogie-0.im";
}


Alter animationCutOff to 0.55 and the glitch doesn't re-appear. I think the moral might be that you are not looking for the animation file unless lm.txt shows that animation will be activated. At the same time the Preview issue seems to show that bogies need anim.kin to find out where to put their wheels. Then again it may be something else entirely :-)

pcas1986
July 29th, 2015, 09:17 PM
I'm also seeing bones at the lowest LODs when all animation has been hidden or culled, but these don't seem to affect draw calls.

I thought a bone with an attached mesh got a draw call so this would bump the draw call count. For this particular asset (bogie) I have three versions of the valve gear, but only one version (forward, neutral or reverse) is visible at any one time. The visibility of those meshes is controlled by script. So does a bone with a non visible mesh count as a draw call?



It looks like the bone count is including visible bones regardless of whether or not they are actually active.

Related to my comment above, but I'm not sure what you mean by active. Is an inactive bone part of a culled animation?

p.s. I spent a lot of time getting this bogie animation to work. It would have been a cleaner design to have three separate animations - i.e. different kin files - but the convention of using anim.kin makes this impossible AFAIK. If there were different animations, I would prefer to cull them very early.

andi06
July 30th, 2015, 01:55 AM
This is speculation but there are several ways of dropping an animation:

1. Using the animationCutOff flag in lm.txt.
2. Culling an associated attachment point.
3. Not inluding the animation in the lower lod meshes.
4. For animated attachments, dropping the animation in the attachment's own lod scheme.

Perhaps some or all of these leave the bones visible to the game with no mesh objects attached.

I wonder whether or not similar issues might apply to pantographs.

pcas1986
July 30th, 2015, 02:51 AM
I think I've done most of those but will have another play with it.

andi06
July 30th, 2015, 03:13 AM
Chris has yet to confirm this but a huge factor in my test model was minor differences in material definitions.

This was an old model, originally gmax but ported to Max, so this may not be relevant in Blender. There were small accidental differences in specular and diffuse levels between the various submeshes which apparently prevent the software from combining small isolated segments into larger chunks. Simply removing all of the materials and re-assigning them from a single material slot (take care not to remove the UVs when you do this) allowed a saving of between 17 and 23 draw calls at the higher lod levels which was roughly a third of the total.

Since a draw call is equivalent to between 300 and 500 polys this equates to a reduction of close to 10,000 polys at some levels.

pcas1986
July 30th, 2015, 04:40 AM
...There were small accidental differences in specular and diffuse levels between the various submeshes which apparently prevent the software from combining small isolated segments into larger chunks. ....
But wouldn't these be separate materials anyway?

It would be useful if there were a table or some other reference list to the reasons why chunks are created. There was a thread back in June where Chris provided some information on this. I might build my own reference table.

You and Chris are on a different level of understanding of these issues but us plebs need something a little more simplistic. This stuff is getting more complex by the day but at least my brain is getting a workout. :D

andi06
July 30th, 2015, 05:36 AM
But wouldn't these be separate materials anyway?
Unfortunately max doesn't actively prevent multiple objects from having the same name.

It may be an issue that's specific to gmax or to max or to source files which are ported from one to the other.

Each door animation controlled three doors, each door comprised three elements: exterior and interior skins and glass. For whatever reason differences in specular and/or diffuse lighting meant that there were in effect a total of 9 materials in the door animation and hence 9 draw calls. In certain circumstances the code is capable of combining items with matching materials into the same draw call and would (if it were not for these mismatches) have reduced the effective number of calls to 3. Re-assigning the materials and re-texturing the door interior from the exterior texture reduced these 9 calls to 2. Ditto for the other side and ditto for one or two other attachments.


You and Chris are on a different level of understanding of these issues but us plebs need something a little more simplistic. This stuff is getting more complex by the day but at least my brain is getting a workout. :D

I've sent copies of this asset offline to Chris and I think he has used it to help establish what the performance statistics in Preview can do - up until a few days ago these tools simply haven't been available to any of 'us plebs'. I've learnt a lot from this process and I will pass on what I can. Overall I don't think its as hard as it sounds, my model has gone from a TRS2004 horror to something with a fairly efficient lod system over the course of three or four days and I didn't know any more than you do now at the outset.

At the moment I think the biggest difficulty is that the Preview doesn't yet indicate which of the main asset lods the model is currently being viewed at. It may also be useful to know which draw calls and polys are attributable to which meshes and sub-meshes - I believe that the [LOG] button will eventually hold the answer to this.

pcas1986
July 30th, 2015, 06:06 AM
...
At the moment I think the biggest difficulty is that the Preview doesn't yet indicate which of the main asset lods the model is currently being viewed at. It may also be useful to know which draw calls and polys are attributable to which meshes and sub-meshes - I believe that the [LOG] button will eventually hold the answer to this.

Some of my test assets have boxes or balloons to indicate the LOD level but that skews the results. Maybe it will become a little clearer when the tools are working.

Thanks for the various bits of information. I'm sure with a little more practice it will get easier.

andi06
July 30th, 2015, 06:21 AM
I think a coloured (m.notex) rectangle will always be 1 draw call and 2 polys. You could probably test that by moving it on and off screen.

pcas1986
July 30th, 2015, 09:29 AM
I think a coloured (m.notex) rectangle will always be 1 draw call and 2 polys. You could probably test that by moving it on and off screen.

I would agree with that without testing.

Currently I'm playing around with attachments. My project loco has 11 of them including couplers (with a separate kuid), windows, sliding roof covers, etc. Some have LM LOD but others, with very low poly counts, do not.

I'm trying to understand the nexus between the AttachmentCutOff value in the default mesh and the AttachmentCutOff values in any attachment LM file. I assumed that the default (mesh) LM AttachmentCutOff would be the "parent" so that when the value of that tag was achieved then all the attachments were effectively delete/void/non existent. That doesn't appear to be the case.

For example, when my lowest LOD (default) mesh is displayed, Preview Asset is saying that 7 attachments are still visible. I would expect it to be zero.

Hopefully that makes sense. It's a bit late here and ...

JCitron
July 30th, 2015, 06:35 PM
The following assets work fine in retail build and previous test build, but have LOD errors in build 77508:

<kuid:122285:80022> Protrack chairs-bullhead-left
<kuid:122285:80023> Protrack chairs-bullhead-right
<kuid:122285:80016> Protrack rail-bullhead-rusty-left
<kuid:122285:80017> Protrack rail-bullhead-rusty-right
<kuid:122285:80022> Protrack chairs-bullhead-left
<kuid:122285:80023> Protrack chairs-bullhead-right
<kuid:122285:80016> Protrack rail-bullhead-rusty-left
<kuid:122285:80017> Protrack rail-bullhead-rusty-right

- The low-detail meshes total more than 500 polygons. This may have a negative impact on performance: 0: 2238

whitepass
July 30th, 2015, 07:20 PM
The poly count is off in CM, I get warnings for over 500 on the lowest LOD and the two working doors if I have build at 3.7 if set to build 4.2 they are errors.

Is the car/loco numbers in CM "View Asset" the some of the body and the bogeys?

JCitron
July 30th, 2015, 07:21 PM
ECML crashed to desktop during drive.

Doing nothing fancy, driving the Freight Liner session for about 30 miles out and then POOF! Gone!

I have a crashdump file if you want it, Chris.

Setup:

Hardware:

i7,
32GB RAM
EVGA GTX780Ti
3x Hard drives, 1x SSD (Boot and programs) 2 x Seagate 2TBs for data. T:ANE beta on D:, T:ANE Retail on E:

In game settings, which are similar to my every day retail T:ANE settings.:

Display config: 1980 x 1080 60hz.
Shadow Quality: High
Main shadow resolution: 4096
Texture Detail: High
Post Processing: High
Water Quality: High
Antialiasing: 2x

All check boxes checked for multiple render threads, PhysX simulation, etc., and Developer box checked for advanced Debug Tools.

In Game Settings, as set under Options:

Draw Distance: 8000m
Scenery Detail: Ultra
Tree Detail: Ultra
Post Processing: High
Process Objects Behind Camera: Checked.

The frame rates were quite good and did not have any floating containers as others mentioned. FPS ranged from 20 to 59fps with no stutters in and out of the cab while swinging the camera view around quickly up, down, etc.

John

pcas1986
July 30th, 2015, 08:04 PM
The poly count is off in CM, I get warnings for over 500 on the lowest LOD and the two working doors if I have build at 3.7 if set to build 4.2 they are errors.

Is the car/loco numbers in CM "View Asset" the some of the body and the bogeys?

The total includes all the attachments including bogies, couplers, doors, windows, etc. I've been adding up the numbers and am about 2000 polys short of what Preview Asset is saying but it is in the same ballpark.

I did manage to get a clean 4.2 validation after ensuring all the attachments are culled.

WindWalkr
July 31st, 2015, 03:24 AM
For example, when my lowest LOD (default) mesh is displayed, Preview Asset is saying that 7 attachments are still visible. I would expect it to be zero.

The number of attachments in the scene is .. complicated. This isn't just the number of explicit "a.foobar" attachments from your source meshes, but also any implicit attachment points in the scene hierarchy. Attachment points also won't necessarily be introduced into the scene until they're actually used for something, and won't necessarily be removed from the scene just because they're no longer used.

It can be a useful relative metric to compare the complexity of one object to another, but I wouldn't get too fixated on the absolute numbers.

chris

pcas1986
July 31st, 2015, 03:42 AM
The number of attachments in the scene is .. complicated. ...
chris

Everything in this process is complicated. :o If you have the time I would like some clarity about processing of multiple LM files in the same asset. See post #47 in this thread. I've been messing around with LM values in my test asset but nothing seems to change much although I do have a clean validation at build 4.2.

My next steps in trying to reduce draw calls is rather more drastic. This includes combining meshes and trying to get the number of chunks down. This will be a lot of work but happy to do it with this project. But I'd rather not get into a continual rework cycle chasing an elusive target.

WindWalkr
July 31st, 2015, 03:45 AM
See post #47 in this thread. I've been messing around with LM values in my test asset but nothing seems to change much although I do have a clean validation at build 4.2.

I'm game, but you don't really ask any questions. If you have something specific that I can help with, send over the mesh and ask away.

chris

pcas1986
July 31st, 2015, 04:12 AM
OK. My loco mesh has an LM mesh with these values (abbreviated):



animationCutOff = 0.09;
renderCutOff = 0.00;
attachmentCutOff = 0.10;
mesh("0.10") {
name="body840-lod3.im";
}
mesh("0.30") {
name="body840-lod2.im";
}
mesh("0.95") {
name="body840-lod1.im";
}
mesh("1.00") {
name="body840-lod0.im";
}


The loco has a bogie attachment and two coupler attachments. They have LM LOD.

There are 11 other attachments most of which have LM LOD but a couple do not as they are very small meshes (36 polys).

So if the loco LM file specifies the attachmentCutOff as 0.10 then can I assume the LOD mechanism for any attachment is ignored after 0.10 is reached for the loco asset?
Do the LM LOD level values for the attachments apply to the size of the attachment mesh or the parent (loco) mesh size?

If you are interested I can send you the loco package. The interior only has a few controls implemented and the textures are not very good and will be redone.

WindWalkr
July 31st, 2015, 04:31 AM
The loco has a bogie attachment and two coupler attachments. They have LM LOD.

So if the loco LM file specifies the attachmentCutOff as 0.10 then can I assume the LOD mechanism for any attachment is ignored after 0.10 is reached for the loco asset?

Yes, with a margin of tolerance.



Do the LM LOD level values for the attachments apply to the size of the attachment mesh or the parent (loco) mesh size?

The LM values apply to that LM mesh, not to a parent or a child.



If you are interested I can send you the loco package. The interior only has a few controls implemented and the textures are not very good and will be redone.

There are two cases where it really makes sense to send me an asset:

1. If you've hit a wall in trying to figure something out, and it's something that can't simply be expressed in words. Email in the asset and question, making sure to include any necessary dependencies and repro steps, and we'll try it out internally and get back to you with whatever answers we can come up with. This could take us a week or more, so it's not worth your time or our time to do this for problems that you can solve on your own- but if you're truly stuck then this is the way to go.

2. If you've done everything that you can think of performance-wise and would like an opinion on the result. Obviously, we can't do this for everybody for every asset, but while this is a hot topic and the tools are newly formed, doing this kind of thing on a case-by-case basis can help us ensure that you have the right tools and documentation.

chris

andi06
July 31st, 2015, 04:42 AM
The number of attachments in the scene is .. complicated. This isn't just the number of explicit "a.foobar" attachments from your source meshes, but also any implicit attachment points in the scene hierarchy. Attachment points also won't necessarily be introduced into the scene until they're actually used for something, and won't necessarily be removed from the scene just because they're no longer used.

It can be a useful relative metric to compare the complexity of one object to another, but I wouldn't get too fixated on the absolute numbers.
Its not that simple Chris. If we are trying to track down inefficiencies in models we first need to find out where they are coming from. This is the process you went through in identifying the Autocoach door meshes as the source of excess draw calls. Like it or not it is sometimes going to be necessary to establish just where all the resources are being used.

When we get the 'Performance', and the 'Log' options this will hopefully be easier.

@Paul
If it helps I've carried out some comparisons between TRS Preview and the AssetX mesh viewer.

733

At the level of an individual mesh the following appears to be true.

1. Poly counts reported by AssetX are exactly the same as those reported by Preview
2. Each texture in the AssetX texture list (reflection maps excepted) will produce at least one draw call in TRS.

WindWalkr
July 31st, 2015, 04:55 AM
Its not that simple Chris.

I'm afraid it really is. The attachment numbers are not under your direct control and vary depending on how the asset is being used and has been used, rather than what's in the model file, so fixating on them won't get you very far. They're useful to have around as general numbers, but trying to add up all of the attachment points in your meshes and wondering where the extra ones came from or the missing ones went is simply not going to work for you. The good news is that the GPU never sees the attachment points, so they are not a direct indicator of performance either.



2. Each texture in the AssetX texture list (reflection maps excepted) will produce at least one draw call in TRS.

Textures mean nothing; materials are everything. If you bind three textures to a single material and draw three polygons, that's one draw call. If you bind one texture each to three materials, and draw one polygon with each, that's three draw calls.

Just to make life difficult for you, the exporters perform a huge bunch of optimisation at export time, T:ANE performs additional optimisations at load time (combining effectively duplicated materials), the stitched mesh system optimises further and then E2 has a final stab at it per frame. The preview window gives you the final numbers that make it through to the GPU, so will always be correct regardless of how many successful optimisations were made along the way.

The rules are fairly set at each step of the way, so it's not like this leaves you guessing what you should be doing, but when things aren't working as you'd expect it can be tricky to work out where you've made the mistake. The log output can help here, by showing you what's being passed to the GPU- it's not something for the faint-hearted to read, however.

chris

pcas1986
July 31st, 2015, 05:09 AM
I won't send in my asset as I still have some ideas to follow up but, as I said, they involve a bit of work. That will take a while.

This was useful:
...If you bind three textures to a single material and draw three polygons, that's one draw call. If you bind one texture each to three materials, and draw one polygon with each, that's three draw calls...


For Andi: I'm using the AssetX tools and even the IM text representation to see where the chunks are. I'd be totally in the dark without it.

andi06
July 31st, 2015, 05:35 AM
I've just had a database rebuild for no apparent reason, followed by a total loss of all user settings.

This continues to happen far too frequently and you still haven't provided a simple means of restoring basic settings. Its intensely irritating and scanning the forums will show that its not just me that is irritated by it.

Also throughout this process I've found it impossible to disable the chat add-on. Another irritation because whenever you look in the log its totally clogged up by UserStatus messages. Who cares?

WindWalkr
July 31st, 2015, 05:40 AM
For Andi: I'm using the AssetX tools and even the IM text representation to see where the chunks are. I'd be totally in the dark without it.

If you're looking at the individual chunks, then one chunk = one draw call (ignoring any potential optimisations which might occur between loading the mesh and displaying it.)

chris

andi06
July 31st, 2015, 05:54 AM
It should be straightforward to add a chunk count to the mesh-data display and to modify the texture list to a material list, I'll put in on my to-do list.

pcas1986
July 31st, 2015, 07:39 AM
It should be straightforward to add a chunk count to the mesh-data display and to modify the texture list to a material list, I'll put in on my to-do list.

Every hint helps. Although I'm no stranger to looking at hex dumps I'd rather some tool did it for me. :)

While we are discussing materials and textures, I've often wondered why the IM file quotes a full path for textures. It doesn't seem to add any value. See below:


http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.07.31_22h34m21s_001_%20Mesh%20F ile%20Data-%20body840-lod0-im_zpsbtbcucyi.jpg

WindWalkr
July 31st, 2015, 08:12 AM
While we are discussing materials and textures, I've often wondered why the IM file quotes a full path for textures. It doesn't seem to add any value. See below:

I suspect that whomever defined the original file format might have thought it useful for deduplication. They wouldn't have had our multi-user scenario in mind, so a duplicate filepath would mean a duplicate texture.

Other possibilities include "this is how Max does it, so this is how we do it".

Certainly doesn't make a huge amount of sense to me :)

chris

RPearson
July 31st, 2015, 09:40 AM
Hi all,

New test build available. A number of changes, but again most importantly I'd like feedback on validation as we're hoping to update the DLS validation tools soon.

The majority of the LM features are now working, so the people playing with LOD should be able to start testing against these. The asset preview window has been improved but is still not finalised- most importantly, don't trust the LOD override control. 3D Text coloration may be fixed. Automatic distance culling of various systems is a little bit smarter but still not finished; feedback is welcome.

chrisChris I still see blue color instead of the rgb value specified with this config entry:


effects
{
0
{
kind "name"
fontsize 0.15
att "a.name0"
fontcolor 204,77,32
name "E A S T B R O A D T O P"
}
}
Deleted the asset and replaced it on the map. In surveyor it looks the same blue color as previous versions of TANE. In TS12 it is an orange color.

Build 77508. This is in WIN 10 - I just updated yesterday.

Bob Pearson

JCitron
July 31st, 2015, 07:56 PM
Surveyor still forgets where we were last editing, and leaves us off somewhere else on the map, I think it's where it was when the map is first loaded up. This was mentioned way back in the betas and then in CE test versions, however, the bug is still there and quite annoying. Please add this to the fix it sooner than later list.

John

martinvk
July 31st, 2015, 08:30 PM
I well remember that issue back in the beta days of T:ANE but I've not seen that behavior for quite some time. Just created a new route and whenever I return after leaving, I'm at the place I was when I left. Then I added a new session to ECML moved to a new position and exited. When I returned, it was to the new position and not to the place entered the first time.

martinvk
July 31st, 2015, 09:24 PM
So I was testing some more in 77508. Opened Milwaukee Road Avery-Drexel and created a new session.
The first time, after moving the the West end, I placed three consists and two track marks. Before I could save, CTD as I was zooming out from the second trackmark. (Crashdump 2015-07-31 Avery-Drexel)
The second time, I placed three engines and saved. Then two trackmarks and saved. Again, when I was zooming out to locate the other end of the route, CTD. (Crashdump 2015-07-31 Avery-Drexel 2)
Reopened the saved session, zoomed out and CTD. (Crashdump 2015-07-31 Avery-Drexel 3)

There seems to be a pattern here. Zooming out seems to cause a Crash to Desktop.

Do you want the dump files as well as a CDP of the session?

Coincidentally, I just updated NVidia to 353.62 on my Dev test box still with Win7 SP1 64 bit and a GTX 750

JCitron
July 31st, 2015, 10:33 PM
I well remember that issue back in the beta days of T:ANE but I've not seen that behavior for quite some time. Just created a new route and whenever I return after leaving, I'm at the place I was when I left. Then I added a new session to ECML moved to a new position and exited. When I returned, it was to the new position and not to the place entered the first time.

I've had the same old behavior still occurring. I've edited a route, exited and come back and find myself off long away from where I planned to be.

I saw your CTD... This is a very common problem it seems. I'll try zooming in and out and see what happens with that.

whitepass
August 1st, 2015, 01:35 PM
Found a bug in the AI, this is in all TANE builds. The AI is changing a junction to "navigate to" and then the junction is going back to it's default under the train and derailing it. Dose this on my old test map under AI, under me driving with DCC no derailment. Also I had the AI test with derailment set to none.

735

clam1952
August 1st, 2015, 02:11 PM
I've had the same old behavior still occurring. I've edited a route, exited and come back and find myself off long away from where I planned to be.

I saw your CTD... This is a very common problem it seems. I'll try zooming in and out and see what happens with that.

Re the CTD Same here John in both driver and surveyor, also happens if the camera view changes from close to a long shot.

The surveyor issue seems to be a case of not always but sometimes here, haven't checked properly but I think if you merge the session with the route it goes to the right place and if you don't it goes elsewhere! Same on release versions as well.

JCitron
August 1st, 2015, 06:10 PM
Re the CTD Same here John in both driver and surveyor, also happens if the camera view changes from close to a long shot.

The surveyor issue seems to be a case of not always but sometimes here, haven't checked properly but I think if you merge the session with the route it goes to the right place and if you don't it goes elsewhere! Same on release versions as well.

This makes sense regarding the camera. I was thinking that the camera location is kept with the session. The reason is when I originally imported a route, the camera was placed on the very opposite of where I wanted to drive after doing my clean up and kept doing so when I would go back in and edit at various times. I then created a driving session on the opposite end of the route, and that became the "default" camera location on start up afterwards and has remained there ever since.

Regarding the CTDs I had another one last night of course in the retail version. I ran Windbg (Windows Debug) on the crash dump file. There's some interesting stuff in there which I never saw before, but I think it's related. Here's an excerpt from that crash.dmp. It is the retail, however, so keep that in mind. Where is drive F:? There isn't one on my system unless I insert my DVD. :) I have seen the invalid pointers before in other crash dumps including the test builds when analyzing the CTDs.


... Lot's more above including lots of hex numbers and repeats of the same stuff below.

BUGCHECK_STR: APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINT ER_READ

IP_ON_HEAP: 000000002307ca68
The fault address in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module which may
contain the address if it were loaded.

FRAME_ONE_INVALID: 1

LAST_CONTROL_TRANSFER: from 000000002307ca68 to 00007ffd11d5c3f9



FAULTING_SOURCE_LINE: f:\dd\vctools\crt\crtw32\string\amd64\memcpy.asm
FAULTING_SOURCE_FILE: f:\dd\vctools\crt\crtw32\string\amd64\memcpy.asm
FAULTING_SOURCE_LINE_NUMBER: 128
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: msvcr120!memcpy+39
FOLLOWUP_NAME: MachineOwner

MODULE_NAME: msvcr120
IMAGE_NAME: msvcr120.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 524f83ff
STACK_COMMAND: ~87s; .ecxr ; kb

FAILURE_BUCKET_ID: STRING_DEREFERENCE_c0000005_msvcr120.dll!memcpy
BUCKET_ID: APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINT ER_READ_msvcr120!memcpy+39
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:string_dereference_c0000005_msvcr120.dll!memcpy
FAILURE_ID_HASH: {3640237b-6ccd-432a-12d5-5c9d832f18ab}

Followup: MachineOwner


John