PDA

View Full Version : LOD again (test build 78095)



geophil
September 13th, 2015, 08:27 AM
I am trying to create T:ANE compliant "UTM tiles". These are those large carrier objects for hi-res textures, usually ortho-photos, serving as a building aid during route construction.

T:ANE compliance means adding a low-triangle second LOD mesh. The software can easily generate those, but the result in T:ANE is less than convincing. The low-triangle LOD mesh will be rendered even at short view distances and I am not sure whether I can do anything about that. These objects are rather big, 1000 x 1000m or 500 x 500m and the unwanted effect appears to be the same of both sizes. The overall idea was/is that the 3D texture carrier object should follow the original terrain very closely so that the route builder can avoid frequent height adjustments to these assets when locating the spots where to place his own objects.

That's such an asset in the previewer, in the full resolution 10 m grid, LOD level 0. That's how it should be rendered:
http://img.transdem.de/albums/userpics/10001/thumb_AssetPreviewLod0.jpg (http://img.transdem.de/albums/userpics/10001/AssetPreviewLod0.jpg)

However, when slightly rotating the object, it flips to the low-triangle mesh, which has a 100 m grid, intended to rendered at far distances only.
http://img.transdem.de/albums/userpics/10001/thumb_AssetPreviewLod1.jpg (http://img.transdem.de/albums/userpics/10001/AssetPreviewLod1.jpg)

(An option to switch off fog in the previewer would be nice.)

Same effect in Surveyor. How it should be:
http://img.transdem.de/albums/userpics/10001/thumb_SurveyorLod0.jpg (http://img.transdem.de/albums/userpics/10001/SurveyorLod0.jpg)

And that's what happens when I rotate the camera:
http://img.transdem.de/albums/userpics/10001/thumb_SurveyorLod1.jpg (http://img.transdem.de/albums/userpics/10001/SurveyorLod1.jpg)
This is in wireframe mode, with the default wireframe texture replaced by a thin grid custom texture. The "UTM tile" resides 10cm above terrain level. When the low triangle mesh is rendered, the original terrain pokes through the asset surface.

Note: In T:ANE build 76536 Surveyor always rendered the low-triangle mesh, not a chance to see the LOD0 mesh.

For the time being I can let TransDEM generate a lower build number for those assets and not create a low-triangle LOD mesh at all. With the lower build, Content Manager will only issue a warning and not reject the object. But obviously this is not the best of remedies and probably can't survive in the long run.

Of course, the ultimate solution would be an option for U/V-texture coordinates for ground vertices, to let such ortho-images (and large scale maps/plans/diagrams) span multiple ground vertices, or even the entire baseboard.

WindWalkr
September 13th, 2015, 06:24 PM
I'm not entirely sure how you're planning to use these objects after they're created, but the best approach would be to reduce your tile size.

chris

andi06
September 14th, 2015, 06:15 AM
I'm not entirely sure how you're planning to use these objects after they're created
Could that be because you didn't read the first paragraph of the original post :-)

Since these objects are intended to be used to develop routes and should never be present in published assets, the solution is the long discussed, even longer awaited, 'asset-in-development' tag to allow these and similar items to be used without LOD.

WindWalkr
September 14th, 2015, 08:39 AM
Could that be because you didn't read the first paragraph of the original post :-)

Not at all. It wasn't ever stated in any detail. geophil's quite accomplished, so it wouldn't suprise me if he was doing more than simply generating assets for a user to hand-place.

chris

geophil
September 14th, 2015, 02:15 PM
A bit of background information:

In my ideal Trainz world, a baseboard would have an option to accept a single large texture to cover its entire area, very much like my 3D UTM tile.

The German simulator Zusi, for instance, does offer such a feature, because the baseboard equivalent there is implemented as an ordinary mesh.

With the existing approach in Trainz, each ground vertex has one or more textures assigned to it, implemented with an index and a lookup table which is limited to 250 textures per baseboard. Raising that limit wouldn't make much sense, though. A baseboard in 10 m grid has more than 5000 vertices and may need as many individual ground textures.

In an ordinary mesh we have U/V coordinates to indicate the right portion of the texture for each triangle. I think that some sort of U/V mapping already exits in the Trainz baseboard structures, to accommodate the 5m terrain grid, where no additional user effort is required to align ground textures designed for the 10 m grid. If such an option existed for the entire baseboard, UTM tiles would be obsolete.


But for the moment I don't see a feasible alternative to those 3D texture tiles. Its predecessors have been around since the early days of Trainz. The most popular and presumably the original one was called “Base Map”, a large flat object of 1000 x 1000m with the single purpose to act as a texture carrier. It was down to the user to first produce a suitable texture from a topo map or an ortho-image and secondly in Surveyor manually place that textured carrier object, like any other object into the scene. Other variants exist, some with different dimensions like 720 x 720m.

When I started with TransDEM for Trainz, I called “Base Maps” “UTM tiles” because in my case they are always aligned with the UTM grid. I automated the texture painting process, but still left it to the user to place the object in Surveyor. Then, with the next major release, I also added automatic placement adding them to the .obs file. However, UTM tiles remained to be flat objects, and the more mountainous the terrain the more cumbersome it becomes to always keep the tile object at proper height. We introduced 500m tiles as an alternative, still flat but a bit handier. Unfortunately you need four times as many.

At some point I discovered N3V's XML Mesh Importer and that made it possible to create 3D UTM tiles. The shape of the terrain is taken from the .gnd file and just copied to my texture carrier. It's a computational intensive task, but made faster through parallelization including parallel sub-processes to run the Mesh Importer. The 3D variant was quickly adopted by TransDEM users.

(Each UTM tile, 2D or 3D, is a unique object, with its own KUID. In OO-lingo we'd call it a class. Only one reasonable instance of that class exists, at the particular geo location where it was created for.)


A typical (somewhat simplified) workflow in TransDEM consists of two phases. In the first phase TransDEM follows a path of geo coordinates to acquire a series of ortho-images or large scale map clippinps via the internet from a public WMS or Map Tile provider. Typically, such a path represents the rough course of a railway line. TransDEM processes the images and their geo-references and converts them to the UTM coordinate system which TransDEM uses internally. In the second phase a similar or often the same path is used to let TransDEM generate the UTM tiles, to make the ortho-images/large scale plans accessible in Surveyor.

Both phases run mainly unattended and as they are relatively fast, TransDEM users tend to create rather large routes, sometimes beyond the scope of what could be realistically finished during later stages of route building. But when a route nears completion, all these UTM tiles will be removed as they have fulfilled their purpose as a building aid.

A typical TransDEM route project that employs ortho-images will produce UTM tiles en masse, often hundreds and with 500m tiles even over thousand in one go. The 500m variant is always produced as groups of four. (The operation is limited to 1000 square kilometres per invocation.)


This brings me back to the LOD issue. Yes, I could further reduce tile object size, to 250m perhaps. But that would quadruple the amount of tiles again and with the sheer number of them make it rather difficult for the user to manage. All those tiles have to be imported with Content Manager which is a bottleneck.

So, hopefully, another solution can be found.

rumour3
September 14th, 2015, 02:58 PM
Could validation relating to LOD simply be supressed for all objects with a surveyor-only tag? LOD seems like an unnecessary complication for utility objects such as guides and markers.

R3

WindWalkr
September 14th, 2015, 06:45 PM
This brings me back to the LOD issue. Yes, I could further reduce tile object size, to 250m perhaps. But that would quadruple the amount of tiles again and with the sheer number of them make it rather difficult for the user to manage. All those tiles have to be imported with Content Manager which is a bottleneck.

Trainz performs ground LOD at the 240m level. Even that's quite large for a Trainz meshobject asset. They're not really designed for the kind of usage that you're putting them to. LM can probably give you the visual results that you want, and could reduce the number of assets, but it will come with a performance penalty.

I agree that we don't really want to be importing thousands of tile objects. It shouldn't take very long for CM to process it unless the textures are huge, but the end result is very messy.

Allowing an explicit overlay layer that can be shown might be possible for us in the future, but that would probably have the opposite issue- texture resolution, even on a large texture, would be pretty low if the map was large.

As I'm sure you're aware, the ground file is stored as a heightmap, so custom UV mappings are not possible.

chris

WindWalkr
September 14th, 2015, 06:46 PM
Could validation relating to LOD simply be supressed for all objects with a surveyor-only tag? LOD seems like an unnecessary complication for utility objects such as guides and markers.

I don't see that this is beneficial for the users. The point of LOD is to ensure reasonable performance. If we turn that off for Surveyor items, then Surveyor's performance will be penalised as a result. I don't really find that it's acceptable for Surveyor to run poorly, any more so than Driver. A lot of people spend much of their interaction time with the game in Surveyor.

chris

rumour3
September 14th, 2015, 09:59 PM
I'm 100% behind the decision to enforce LOD for performance reasons. However, Surveyor-only assets are generally very different to normal objects in both design and usage- they usually don't represent real-world objects, and I can't think of a circumstance where you would use them in anything like the number/density of a SpeedTree forest, for example. Geophil has an example of a very unusual object that is awkward to work around the LOD rules, and my suggestion would solve his specific problem. I'm not convinced that the typical range of surveyor only objects poses a significant threat to performance if LOD were not used, and it would remove a level of complexity for creators. I appreciate you don't want to open a load of back doors for poorly performing assets, but the specific case here is an example of where the rules are not helpful.

R3

WindWalkr
September 14th, 2015, 10:26 PM
I'm 100% behind the decision to enforce LOD for performance reasons. However, Surveyor-only assets are generally very different to normal objects in both design and usage- they usually don't represent real-world objects, and I can't think of a circumstance where you would use them in anything like the number/density of a SpeedTree forest, for example.

On the contrary, geophil's example adds up to some number of millions of polygons. LOD is a very good idea indeed.

chris

andi06
September 15th, 2015, 03:35 AM
So you have two LOD levels, Level 0 is full resolution, Level 1 is zero polys and applies to any tile which isn't under the cursor.

I'm not sure that LM.txt would work with these objects (which won't stitch) but this LM.txt might achieve something like that result:



version 1.0
offset = 0.01;
calcPoint = center;
multiplier = 1.0;
animationCutOff = 0.00;
renderCutOff = ##; // value which equates to half of the tile dimension
attachmentCutOff = 0.00;

mesh("1.00") {
name="UTM-Tile.im";
}

geophil
September 15th, 2015, 11:36 AM
LM can probably give you the visual results that you want, and could reduce the number of assets, but it will come with a performance penalty.


I'm not sure that LM.txt would work with these objects (which won't stitch) but this LM.txt might achieve something like that result:
[...]


Thanks a lot for this suggestion. I'll give it a try.

andi06
September 15th, 2015, 12:11 PM
LM can probably give you the visual results that you want, and could reduce the number of assets, but it will come with a performance penalty.
You keep saying this but you have stated in another thread (http://forums.auran.com/trainz/showthread.php?121256-LOD-Techniques&p=1421994#post1421994) that there is only a significant performance difference between LM and mesh-table LOD when using LM would prevent mesh stitching. That isn't the case here.

martinvk
September 15th, 2015, 03:32 PM
I'm following this thread with great interest. Many of my Surveyor only guides are already pretty simple with a low number of polys at LOD0. getting a significant reduction to LOD1 and LOD2 is often well nigh impossible without severe distortion. So I end up inflating LOD0 just to have something to remove later. Not the ideal but that's what is needed to keep the poly police at bay.

And as Rumour3 mentioned, they are only ever used sparingly. Once they are no longer needed, it should be up to the designer to remove them if performance becomes an issue. We already have this situation with the built-in rulers. Leave too many in the map and performance also takes a nose dive, so nothing new here.

WindWalkr
September 15th, 2015, 08:16 PM
You keep saying this but you have stated in another thread (http://forums.auran.com/trainz/showthread.php?121256-LOD-Techniques&p=1421994#post1421994) that there is only a significant performance difference between LM and mesh-table LOD when using LM would prevent mesh stitching. That isn't the case here.

Probably true as the problem is stated; if each mesh is using its own materials then stitching is off the cards (you'll still be paying the performance penalty, it's just that avoiding LM won't be enough to resolve this.)

What you would ideally be doing instead is using one texture for multiple ground meshes. Doubly true if you're going for the smaller (more numerous) tiles. At this point stitching is possible, and my point about LM files is relevant.

To be honest, this whole thing is pretty nasty. We're talking about ways of achieving something that the game can basically do natively, except in a slightly different manner than introduces a whole host of side effects such as thousands of unwanted assets, thousands of extra objects in the scene, millions of extra polygons (hopefully substantially less with LOD, but there's still a cost here.)

Geophil, what is the texture resolution that you're hitting in the end? If it's not notably in excess of one pixel per 5 meters (~144 pixels per baseboard) then we're probably wasting our time talking about this.

chris

WindWalkr
September 15th, 2015, 08:18 PM
So I end up inflating LOD0 just to have something to remove later. Not the ideal but that's what is needed to keep the poly police at bay.

Not really. It might do that for a few months, but then we'll cotton on to the problem and your assets will be flagged as problematic. Please don't do deliberately stupid stuff, you'll just cause heartache for everybody down the line.

chris

Pencil42
September 15th, 2015, 09:22 PM
Geophil, what is the texture resolution that you're hitting in the end? If it's not notably in excess of one pixel per 5 meters (~144 pixels per baseboard) then we're probably wasting our time talking about this.


4 pixels / meter is not uncommon (2048^2 texture on a 512^2 m mesh). Improved resolution is used to accurately place objects on prototypical DEM routes:

http://carsoncarshops.com/images/web/baseboard.jpg

Curtis

geophil
September 16th, 2015, 02:31 AM
Geophil, what is the texture resolution that you're hitting in the end? If it's not notably in excess of one pixel per 5 meters (~144 pixels per baseboard) then we're probably wasting our time talking about this.

I'll come up with a couple of pictures tonight (European time). Curtis has already shown an example.

The standard approach in TransDEM has always been the monochrome texture colour palette, not invented by me, but by the author of HOG. With this approach and the 5m terrain grid since TS2009 we get 1 pixel per 5m and can resolve topo maps up to 1:25,000 (or 1:24,000 in the US). Anything larger becomes too blurred.

That's where the UTM tiles kick in. TransDEM creates their texture size based on map/ortho-image scale. Scale is part of the meta data accompanying the georeferenced bitmap sources for the textures. The absolute maximum texture size TransDEM will produce is 4096 px. Applied to the 500m tile we get about 1 px per 10cm. For ortho-images this will resolve tiny but important trackside objects like dwarf signals (30 cm wide). Detailed track plans, the other data source for really large scale, are often in the 1:1000 range. Due to the inherent abstraction of cartography we need a little less resolution here, but rendering 1:1000 still requires about 1 px per 20 cm, or 2048 px per 500m tile.

WindWalkr
September 16th, 2015, 03:09 AM
I'll come up with a couple of pictures tonight (European time). Curtis has already shown an example.

No need; I'm more interested in the numbers.



That's where the UTM tiles kick in. TransDEM creates their texture size based on map/ortho-image scale. Scale is part of the meta data accompanying the georeferenced bitmap sources for the textures. The absolute maximum texture size TransDEM will produce is 4096 px. Applied to the 500m tile we get about 1 px per 10cm.

What sized routes are you generating with this technique, roughly speaking? Or perhaps a simpler question to answer: how many tiles are you generating for a given route?

chris

andi06
September 16th, 2015, 04:59 AM
So I end up inflating LOD0 just to have something to remove later. Not the ideal but that's what is needed to keep the poly police at bay.
Slightly off topic but I'm seeing this same recommendation (from someone who ought to know better) being circulated on an external forum in response to people who are really struggling to understand the LOD errors they are seeing from TANE. The longer it takes you to get this issue sorted and documented the more problems it is going to generate.

clam1952
September 16th, 2015, 05:46 AM
Thoughts.
As UTM Tiles 3d or otherwise are only ever going to be used in surveyor during accurate route construction, do they really need to be fully lod compliant? In fact does anything that is only used as a guide or template in surveyor and not destined to be actually used in driver need lod?
As said previously a lod requirement exemption, if the asset contains a surveyor only tag would seem to be an obvious solution.

andi06
September 16th, 2015, 07:28 AM
We came up with the solution in one of the earliest threads in this forum.

A new tag 'development-asset 1' or similar which has the following effects:

1. An asset with this tag can't be uploaded to the DLS and can't be installed in-game unless the user ID of the asset is the same as the user ID of the TRS installation.

2. On installation non fatal errors are reduced to warnings, enabling objects to be built free of validation problems in the initial stages.

I can't find the thread but I believe Chris promised to look into whether this was practicable.

Pencil42
September 16th, 2015, 09:02 AM
Well, if the .lm.txt will work, I think I'd prefer that - it would give better performance in surveyor with less of these objects being rendered. Perhaps even add a couple of intermediary lods, such as a 20m grid and a 50m grid.

norfolksouthern37
September 16th, 2015, 02:45 PM
It may just be my interpretation of your posts Chris, but it doesnt appear that you understand completely that these tiles are only used for placement of objects in surveyor during route creation and then are removed forever when placement is complete. They are only for getting a geo-reference for objects in the real world to the DEM terrain. These items are not to remain on the route and be used as the ground. They do not get distributed with the final route, and are not ever used in driver.

geophil
September 16th, 2015, 03:10 PM
What sized routes are you generating with this technique, roughly speaking? Or perhaps a simpler question to answer: how many tiles are you generating for a given route?We have to distinguish my own testing, my suggestions to TransDEM users and what users actually do. For the latter I am relying on user feedback.

During my tests I created several hundred square kilometers for a route, both as 1000m and as 500m tiles. The 3D variant was added late 2013 and I mainly tested with TS12. Texture resolutions vary, but that wasn't new for the 3D variant. We added the 500m tiles and the maximum texture size of 4096 a few years earlier. Curtis had provided the 2D mesh templates, simple boxes, of course, no worry about triangles. Texture resolutions vary. But 10cm ortho-images for a larger area would take ages to acquire, consume lots of local disk space and memory. So, even if automatic, that limits the largest scale to the more sensitive areas. Mass production will more likely be with a scale of 1:5000 or 1:10000.

What I suggest in the TransDEM manuals and in reply to questions is to build with a topo map painted as ground textures, 1:50000 (10 m Trainz terrain grid) or 1:25000 (5m terrain grid) as the basis and add UTM tiles only where high detail is needed, like stations, yard areas etc. However, some of the feedback I receive tells me that a number of users are really trying to max it out and create 3D UTM tiles for their entire route.



Now, I did some testing with with LM.txt last night, with the 1000m tile. Technically it works, but it does not appear to be very practical. First, Content Manager takes a long time to import the asset, and then in Surveyor it turns out that maximum drawing distance is quite limited. This would make it difficult to navigate as you will often be in wireframe mode and would need to switch back to grasp some ground texture for orientation.


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

mesh("0.30") {
name="utm_1000low.im";
}

mesh("1.00") {
name="utm_1000.im";
}


From that experience it seems that the standard mesh LOD table might be the better option - for as long as we cannot paint the ground directly with the hi res texture. I have no objections to and no problems with that additional low poly mesh, TransDEM simply reruns the mesh generator with a larger grid width and the gain is substantial. Textures are the same for both meshes.

But the LOD switching threshold currently does not work for this. Chris clearly stated it hadn't been designed for which I fully understand. But couldn't that be altered with a mimimum of work? From a developer's point of view I would look for a solution that avoids adding a parameter to the outside interface like a new tagged value in config.txt. Couldn't the asset size be evaluated and the LOD threshold be based on bounding box diameter or something like that?




To illustrate this rather dry matter for readers not that familiar with this stuff a couple of more images. These are older ones, all taken with TS12.

Ground texture 1:25,000 topo map, four 500m tiles with different scale and different texture sizes. 1:1000 track plan, 1:5000 topo map and two different ortho-image sources, none of them Google.
http://img.transdem.de/albums/userpics/10001/thumb_utm3dtiles07.jpg (http://img.transdem.de/albums/userpics/10001/utm3dtiles07.jpg)http://img.transdem.de/albums/userpics/10001/thumb_utm3dtiles08.jpg (http://img.transdem.de/albums/userpics/10001/utm3dtiles08.jpg)http://img.transdem.de/albums/userpics/10001/thumb_utm3dtiles10.jpg (http://img.transdem.de/albums/userpics/10001/utm3dtiles10.jpg)

Ortho-image applied as ground texture, 1:5000 map applied to UTM tile.
http://img.transdem.de/albums/userpics/10001/thumb_utm3dtiles11.jpg (http://img.transdem.de/albums/userpics/10001/utm3dtiles11.jpg)http://img.transdem.de/albums/userpics/10001/thumb_utm3dtiles12.jpg (http://img.transdem.de/albums/userpics/10001/utm3dtiles12.jpg)

1:10000 map applied on UTM tiles, based on 2.5 m DEM (!) re-sampled to 5m for 5m baseboards.
http://img.transdem.de/albums/userpics/10001/thumb_TransDEM25Franzensf01.jpg (http://img.transdem.de/albums/userpics/10001/TransDEM25Franzensf01.jpg)http://img.transdem.de/albums/userpics/10001/thumb_TransDEM25Franzensf02.jpg (http://img.transdem.de/albums/userpics/10001/TransDEM25Franzensf02.jpg)

Finally a test for drawing distance in TS12, texture rather low-res here and not important, with 1/9 arc sec DEM. The distant mountains are about 10 km away, IIRC. About forty sq km and as many UTM tiles in this route module.
http://img.transdem.de/albums/userpics/10001/thumb_bonneville01.jpg (http://img.transdem.de/albums/userpics/10001/bonneville01.jpg)http://img.transdem.de/albums/userpics/10001/thumb_bonneville02.jpg (http://img.transdem.de/albums/userpics/10001/bonneville02.jpg)

WindWalkr
September 16th, 2015, 06:20 PM
Now, I did some testing with with LM.txt last night, with the 1000m tile. Technically it works, but it does not appear to be very practical. First, Content Manager takes a long time to import the asset ..

CM should be spending the majority of it's time compressing the 4k texture. Your choice of LOD technique should have no appreciable impact on this.



.. and then in Surveyor it turns out that maximum drawing distance is quite limited.

This is controlled by you in the LM file (up to the point where the entire scenery object becomes hidden by the game, which will be unaffected by your choice of LOD.) Try lowering your renderCutOff value.

chris

geophil
September 17th, 2015, 02:02 PM
CM should be spending the majority of it's time compressing the 4k texture. Your choice of LOD technique should have no appreciable impact on this.
Confirmed, same for both LOD techniques. It also appears that CM uses parallelization when importing multiple assets which significantly speeds up the process. (Some people will complain about heat development.) I found CM import performance quite acceptable, with a small series of 3D UTM tiles and 2048 px textures (maximum CPU utilization on all cores.) And 4096 px textures shouldn't be the normal case. That was very slow and took 1:50 min for my example.


This is controlled by you in the LM file (up to the point where the entire scenery object becomes hidden by the game, which will be unaffected by your choice of LOD.) Try lowering your renderCutOff value.I set it to 0 but I am still not happy. As it seems to me, build 76536, compared to current test 78095, had a significantly larger max drawing distance.

norfolksouthern37
September 17th, 2015, 04:54 PM
as a side question - do we get to use 4k textures now or is the mem limit still in effect?

for those who dont know, previous trainz versions would limit a texture to the next highest mip level (in most cases 2048x) if the texture exceeded a certain memory size limit. it is for this reason that using 4096x textures in the past was futile and did nothing but make an asset take up more disk space.

WindWalkr
September 17th, 2015, 08:09 PM
I set it to 0 but I am still not happy. As it seems to me, build 76536, compared to current test 78095, had a significantly larger max drawing distance.

You should be able to get up to about 8km draw distance with max settings. If you're using max settings and are seeing the objects drop out sooner than this, it's likely a problem with your asset (perhaps try comparing it to some other stock objects- speedtrees, simple buildings, whatever.)

If you can't figure it out, send in one of your objects and I'll test it.

chris

WindWalkr
September 17th, 2015, 08:18 PM
as a side question - do we get to use 4k textures now or is the mem limit still in effect?

I don't really recommend it. Texture compression will take 4x as long as a 2k texture. You typically won't see better visual results in anything but the most extreme cases. Performance will bottom out on a lot of cards (they're simply not up to pushing that size of texture.) Disk usage is up 4x. VRAM usage is up 4x. etc. Any frame rate drops while uploading the texture will be 4x as bad. Loading times will be 4x as long. etc. etc.

We technically allow 4096x4096 source images in T:ANE, because TS12 allowed it and we didn't want to break existing content, but I definitely don't recommend it. We do have a texture quality slider that can be used to mitigate the runtime impact of the textures on lower-end machines, but even so it will blow out download sizes, texture compression time, etc.

chris

geophil
September 18th, 2015, 10:57 AM
You should be able to get up to about 8km draw distance with max settings.
Yes, those were still on default for 78095. Appears to be OK now.


it's likely a problem with your asset No, it was the settings. 3D UTM tiles are rather simple objects, just a height map modeled as a mesh, with side panels and a bottom. For a 1000m tile with a 10 m raster this gives 100 x 100 x 2 triangles for the top, 101 triangles for each side panel, 2 for the bottom, 20406 in total. LOD1 would lower the raster with to 100 m, 10 x 10 x 2 triangles for the top, 11 triangles for each side panel, 2 for the bottom, 246 in total, quite a heavy reduction and definitely worth it when it works.

I will now implement the creation of lm.txt in code and then run a test with mass production and get back with the results.

norfolksouthern37
September 18th, 2015, 11:38 AM
I don't really recommend it. Texture compression will take 4x as long as a 2k texture. You typically won't see better visual results in anything but the most extreme cases. Performance will bottom out on a lot of cards (they're simply not up to pushing that size of texture.) Disk usage is up 4x. VRAM usage is up 4x. etc. Any frame rate drops while uploading the texture will be 4x as bad. Loading times will be 4x as long. etc. etc.

If only I could do math I would have figured this out all on my own.


We technically allow 4096x4096 source images in T:ANE, because TS12 allowed it and we didn't want to break existing content, but I definitely don't recommend it.

TS12 allowed the source image to be 4k but the game would never display that resolution and was always hard limited to the 2k mip level. - I was asking if that has been lifted.

WindWalkr
September 19th, 2015, 08:12 AM
TS12 allowed the source image to be 4k but the game would never display that resolution and was always hard limited to the 2k mip level. - I was asking if that has been lifted.

As above, T:ANE will honour a 4K texture.

chris

norfolksouthern37
September 19th, 2015, 11:46 AM
As above, T:ANE will honour a 4K texture.

chris


but you didnt answer the question.

Again, 4k was 'allowed' but displayed at 2k and was pretty useless. Why can't you simply answer if this is still the case or not?

VinnyBarb
September 19th, 2015, 05:53 PM
As I understand this and as has been posted somewhere here in the past (couldn't find the relevant post), 4k textures being used for TANE will be compressed into their individual levels of size used for various distances but ONLY the internal 2k texture map will be used as the highest pixel texture map in game for closeup viewing.

I am open to correction by Chris.

VinnyBarb

WindWalkr
September 19th, 2015, 09:51 PM
To make it explicit, since I'm obviously not getting my point across :)

* T:ANE will correctly handle 4K textures.
* This is for compatibility only. You're likely going to run into a host of performance problems if you use it.
* Actual texture detail displayed in game is controlled by the end-user, and at the highest setting WILL display 4K textures. As in the actual 4K texture. Not a 2K reduction of it.

chris

norfolksouthern37
September 19th, 2015, 09:54 PM
thank you! finally an answer.

rumour3
September 20th, 2015, 01:53 AM
Related to this, what about non-square textures? A 4k x 2k texture contains the same pixels as two square 2k ones, but would be useful to allow, for example, the side of a long loco to be textured at a good resolution without a break. What are the pros/cons of one large v two smaller textures in this scenario?

WindWalkr
September 20th, 2015, 02:16 AM
Lower-end GPUs struggle with larger textures due to the bandwidth requirements. The cost of splitting the texture is an extra draw call (and the associated state shuffling in the GPU.) Which one wins is situational and hardware-dependant, but if the 4k texture loses, it's likely to lose hard.

Example considerations:

* A 4k x 2k texture used some distance from the camera might be LODed to 1k x 512 anyway, in which case render performance isn't going to be problematic regardless of your hardware.
* A single texture is going to handily beat two textures if there are no bandwidth concerns and there isn't a lot of geometry involved.
* If there's a lot of geometry, then the cost of a second texture is negligible (since it doesn't scale with the number of vertices) whereas the cost of the 4k texture may still be substantial on some hardware.
* A single texture is likely to remain at high LOD for longer than two smaller textures (assuming some locality of texturing- if you splatter the two smaller textures all over the model at random then this won't hold true.)

Similarly with other performance characteristics:

* Two textures will allow two cores to operate while performing texture compression. (This is true at the moment; in theory we could add a multi-core solution for some types of texture compression in the future, or we could swap to OpenCL or whatever.)
* Separate textures means that we can load the textures to the GPU independently, which may reduce jerkiness even assuming that the same number of texels are being transferred.

With a smaller texture size, it would absolutely be the right thing to do to combine them into a single larger texture, but as we start to approach or exceed hardware capabilities, the balance changes. Exactly where the tipping point is would require you to do extensive testing of your model against different generations and makes of GPU, which isn't feasible for most users. For this reason, I simply recommend not going above 2k.

chris

rumour3
September 20th, 2015, 03:00 AM
Thanks Chris, that's clear.

geophil
September 20th, 2015, 11:37 AM
Just a quick report back on the original topic.

I have implemented the lm.txt technique in code and ran a couple of tests, creating a bunch of tiles. Geometry and LOD switching seem fine. I will let the user decide where to set the threshold from high to low poly. The default is at 0.4 which works as expected in 78095.

I will still have to play with lighting to find a good balance between ground textures and UTM tile textures. With the same settings as for TS12, my UTM tile textures look overexposed in T:ANE by two or three stops.

http://img.transdem.de/albums/userpics/10001/thumb_brightness03.jpg (http://img.transdem.de/albums/userpics/10001/brightness03.jpg)http://img.transdem.de/albums/userpics/10001/thumb_brightness01.jpg (http://img.transdem.de/albums/userpics/10001/brightness01.jpg)http://img.transdem.de/albums/userpics/10001/thumb_brightness02.jpg (http://img.transdem.de/albums/userpics/10001/brightness02.jpg)

A remark on texture resolution: I have the impression that the crispness of the original texture loses quite a bit in the 3D processing pipeline. I probably never looked that closely before, but with the discussion on 4k textures I became curious. The textures I compared are "only" 2k. Any ideas?

http://img.transdem.de/albums/userpics/10001/thumb_tex2048-orig.jpg (http://img.transdem.de/albums/userpics/10001/tex2048-orig.jpg)http://img.transdem.de/albums/userpics/10001/thumb_tex2048-3D.jpg (http://img.transdem.de/albums/userpics/10001/tex2048-3D.jpg)

TRam__
September 20th, 2015, 12:32 PM
With the same settings as for TS12, my UTM tile textures look overexposed in T:ANE by two or three stops. Open "edit environment" setting and adjust "exposition" what ever you want. (For example, half of maximum "sun color" and half of "envirement color")

Auran Jet was not able to increase texture brightness, it is possible in Jet (incl. TS12) only make them darker.

WindWalkr
September 20th, 2015, 06:38 PM
A remark on texture resolution: I have the impression that the crispness of the original texture loses quite a bit in the 3D processing pipeline. I probably never looked that closely before, but with the discussion on 4k textures I became curious. The textures I compared are "only" 2k. Any ideas?

There are at least two good reasons for this:

1. All textures are compressed. This process is lossy, and is designed for "natural" looking textures, so it will not do as well for line art.
2. Once it's in the 3D world, the texture is no longer scaled the same or aligned to pixels. This will naturally add some amount of blurriness even at 1:1 scale because one source texel will be shared between two destination pixels, etc.

chris