PDA

View Full Version : LOD and attachment points question



rumour3
July 26th, 2015, 11:35 AM
Can anyone confirm whether it is necessary for all attachment points, including the basic traincar ones (a.limfront, a.limback etc) to be present in all LODs? If a non-essential attachment point is not included in a particular LOD mesh, does this stop the attachment appearing at that LOD, as an alternative to the cull settings?

Another question- I've got my lowest LOD down to well under 500 polys, but because of the way the higher LODs are mapped, I'm still using two 2048x2048 textures that are common to all LODs. Can I rely on TANE's texture LOD to deal with this, or should I create a separate single and smaller texture? I'd prefer not to, because it would make alternative skins much more work.

R3

clam1952
July 26th, 2015, 11:52 AM
I tried leaving the attachment points out of the last two lods in TS12 and it screamed at me because they were missing..... Pure guess but an attachment point probably doesn't have much if any overhead? a.limfront and a.limback I would think were a must as you can't couple to anything without them.

rumour3
July 26th, 2015, 11:59 AM
Thanks for the confirmation.

R3

whitepass
July 26th, 2015, 12:43 PM
Yes all attachment points must be in all LOD's and no you do not need to do anything with your textures, Trainz dose it for you in CM(the old CCG's have this wrong for TS9 and newer).

WindWalkr
July 26th, 2015, 07:22 PM
Can anyone confirm whether it is necessary for all attachment points, including the basic traincar ones (a.limfront, a.limback etc) to be present in all LODs? If a non-essential attachment point is not included in a particular LOD mesh, does this stop the attachment appearing at that LOD, as an alternative to the cull settings?

Jet wanted the attachment points to be present in all LOD variants, I believe.

T:ANE currently uses only the attachment point data from the top LOD, however it's likely that this could be rethought when attachment LOD is added. Assume that the Jet requirements continue until you hear otherwise.



Another question- I've got my lowest LOD down to well under 500 polys, but because of the way the higher LODs are mapped, I'm still using two 2048x2048 textures that are common to all LODs. Can I rely on TANE's texture LOD to deal with this, or should I create a separate single and smaller texture? I'd prefer not to, because it would make alternative skins much more work.

A difficult question. It depends on how your texture is applied.

If you use most of your texture on the high LOD, and then apply the same map to the low LOD, Trainz (both under Jet and E2) will recognise that you don't need the texture at a very high resolution to fulfil your request, and the higher mipmaps will be unloaded. This saves GPU memory.

If you use most of your texture on the high LOD, and then apply a tiny corner piece to the low LOD, Trainz will recognise that you still need the texture at a high resolution to maintain the resolution of the corner piece, and thus the higher mipmaps will not be unloaded. This wastes GPU memory.

(This has nothing to do with which mesh LOD is in use, but simply estimates the texel-to-pixel ratio at which the texture is being displayed.)

In a worst-case scenario, you could map a single texel to a large part of your mesh. This forces the texture to remain at highest detail so that the required single texel is not degraded. It also tends to look bad because the mesh is a flat colour. Don't do this.

chris

VinnyBarb
July 27th, 2015, 01:05 AM
Jet wanted the attachment points to be present in all LOD variants, I believe.

If you want to see Trainz having a hissy fit, most likely a CTD, try to delete any attachment points in any LOD, most of us long time CCs know this, as we would have tried anything at some point in time in the past, including deleting attachment points. Which is now even more important (not the deleting of APs but...) to trying to reducing the lowest LOD to satisfy your TOO RIGOROUS minimum requirements for the lowest LODs, say, for highly detailed locomotives. I still don't get it, WHY the blazes you are so hell bend on forcing on us the 500 polygon limit (although you call this a 500 POLYGONS LIMIT, when 500 triangles usual are FAR LESS than 500 polygons and then even harder to achieve) for the last/least LOD for elaborate, highly detailed and good looking locomotives, which might have up to 5 animated fans, possibly some 1 to 2 driver figure(s), several similar lights/lamps/coronas/other objects placed all around the locomotive body, similar panels, say used on either side, number boards, hoses, chains, even handrails, several smoke attachments for a varied steam and/or exhaust smoke showing, night mode meshes and number board meshes, possibly cabs too and whatever else is attached to the main locomotive body via attachment points. Yet the same 500/tri limit applies to, say, a single house or shop or similar with LODs, where this 500/tri limit is relative EASY for a content creator to implement.

There MUST be a graduated polygon/tri LOD limit for different complex and not so complex assets created for TANE or N3V might as well look for and employ paid content creators, which possibly might be allowed to exceed the same on us now forced limits, as even they might be struggling to achieve what you are now asking us to do. As I can see, some/many/most good and highly detailed content creators will simply tell N3V where to go and go on to greener pastures or even give it all away for good.

I have NO problem whatsoever to apply your LOD 500/tri limit on most for TANE to be created scenery and other such simpler assets, it is, as said, mainly for highly detailed locomotives, some highly detailed rolling stock and some special scenery items I have objections to with this ridiculous 500/tri limit. After all, TANE NEEDS highly detailed and good looking assets, to justify what TANE can/might do but by using only a single, heavy handed sledgehammer limit for all, IMHO defeats this and is just not justified. Where a simple attachment CULLING configuration system of such attachments would be possibly enough, to remove these attachment meshes from memory on lower or the lowest LOD, when these can not be seen anymore, if one could only do this now for TANE but AFAIK, this does not even work in TANE. Why not?


A difficult question. It depends on how your texture is applied. If you use most of your texture on the high LOD, and then apply the same map to the low LOD, Trainz (both under Jet and E2) will recognise that you don't need the texture at a very high resolution to fulfil your request, and the higher mipmaps will be unloaded. This saves GPU memory.

This is mostly used as above by us content creators anyway, to use the same texture map(s) for all LODs of the asset. Isn't this what prudent content creators would normally do?


If you use most of your texture on the high LOD, and then apply a tiny corner piece to the low LOD, Trainz will recognise that you still need the texture at a high resolution to maintain the resolution of the corner piece, and thus the higher mipmaps will not be unloaded. This wastes GPU memory.

(This has nothing to do with which mesh LOD is in use, but simply estimates the texel-to-pixel ratio at which the texture is being displayed.)

In a worst-case scenario, you could map a single texel to a large part of your mesh. This forces the texture to remain at highest detail so that the required single texel is not degraded. It also tends to look bad because the mesh is a flat colour. Don't do this.

Why? Bad coding or what? How often would one need to do the above? Why then compress our texture maps included with the asset to different compressed levels, to use at different distances for a better performance if such a different texture map suddenly can not be used? Isn't this where LOD distances for the asset come in, to use the relevant compressed LOD texture map for the correct LOD, irrespective of using only a few pixels from such a distant LOD compressed texture map? If this is indeed not so, then better code this into TANE's code to use ONLY and ALWAYS the LOD distance specific compressed texture map on the right LOD distance for such an asset but as you say in your example above, this is NOT possible, when using a tiny portion of the texture from the same distant LOD compressed texture map and only from the texture map at a high resolution for that asset. <----(From a layman's point of view who is not a coder but thinks, why can't this be programmed into the code of TANE to use the corresponding LOD texture map with the corresponding LOD mesh at the corresponding distance?).

If the extra programming above is not possible and if one REALLY likes to use a very small, tiny portion of the main texture map(s) for such a purpose (probably a very remote case), I would think a small, extra map with its extra material type would be sufficient to satisfy that requirement. Please don't say, the extra material type is an extra performance cost, what is surely is BUT IMHO, this is the lesser evil of the above, plus one can place a few extra details if needed on such a tiny extra map, say, 64x64 pixels or even slightly larger. Not just a tiny pixel of a flat colour but colours with some noise in it to make it varied and worthwhile to use.

I know, you will shoot down my whole above argument as you are hell bend on fixing performance optimization at all costs and if this is indeed the case, please answer just a small question:

Why is TS12 with so many of these older, now included in TANE and still on the DLS available performance robbing, polygon heavy assets as d/loads, which someone can load into TS12, say on a TS12 route, including some of the REALLY heavy SketchUp created and converted for Trainz assets (some of these are well over 300K polygons or even more, I have even seen a 1.5 mill polygon sized asset on the DLS) and TS12 still runs somewhat happily along, oblivious and unaware of these issues and still performs often a LOT BETTER and more then reasonable fine as TANE presently does on medium specced PCs, where TANE might show stuttering or even a slide show with such assets loaded. In other words, if I use the same route, not the build ins, in TS12 and use the same route in TANE, with the same assets in it. Believe me, I tried this and TS12 was always the winner.

As now TANE can access ALL available memory in Win 64 bit, it is supposed to be faster running with really more and better hardware requirement needed than TS12 ever had been asked for. But TANE seems to be filling/using almost all available memory and is often up to 99% of CPU hogging, when checking this with some utilities?

Over to you, Chris.

VinnyBarb

WindWalkr
July 27th, 2015, 02:49 AM
..reducing the lowest LOD to satisfy your TOO RIGOROUS minimum requirements for the lowest LODs, say, for highly detailed locomotives.

If you say this, then you don't understand what LOD is.

LOD really has nothing to do with the amount of detail in your loco. In fact, it's fair to say that LOD allows you to INCREASE the amount of detail in your loco, while getting better performance to boot.

The whole point of LOD is to allow us to use a lot of detail up close, while dropping away the detail that you can't really see to ensure that overall performance remains good.



I still don't get it, WHY the blazes you are so hell bend on forcing on us the 500 polygon limit

Because lack of decent LOD directly impacts performance.



(although you call this a 500 POLYGONS LIMIT, when 500 triangles usual are FAR LESS than 500 polygons

Triangles are polygons. More importantly, triangles are the ONLY polygons the Trainz supports. In Trainz (and in most other games, since this is really a GPU thing rather than something that we impose) the words "triangles" and "polygons" are interchangeable.



Where a simple attachment CULLING configuration system of such attachments would be possibly enough, to remove these attachment meshes from memory on lower or the lowest LOD, when these can not be seen anymore, if one could only do this now for TANE but AFAIK, this does not even work in TANE. Why not?

Attachment points work very differently with T:ANE/E2 than with Trainz/Jet. We are still working on the best way to emulate some of the LOD features of Jet in E2. This wasn't a high priority for us for release because we're not currently losing much by skipping this. This will also be a continued work in progress; we'll reach approximate Jet parity fairly soon but we want to take things a fair bit further so we won't be stopping there.



Why? Bad coding or what?

There's nothing the code can to to fix it. If your mesh needs the texture at high detail to avoid having user-visible degradation, the code will try to keep the texture at high detail. That's the whole point of the texture streaming system. If your model is set up so that it needs 5% of the texture at high detail despite being at several kilometres from the camera, then the code will make sure that the whole texture is at high detail even though the other 95% goes unused. (Caveat: if you use different texture detail in different parts of your mesh, the code will pick an "average" value.)



Isn't this where LOD distances for the asset come in, to use the relevant compressed LOD texture map for the correct LOD, irrespective of using only a few pixels from such a distant LOD compressed texture map?

No. You seem to be confusing meshes and textures.



Please don't say, the extra material type is an extra performance cost

Of course it is.



Why is TS12 with so many of these older, now included in TANE and still on the DLS available performance robbing, polygon heavy assets as d/loads, which someone can load into TS12, say on a TS12 route, including some of the REALLY heavy SketchUp created and converted for Trainz assets (some of these are well over 300K polygons or even more, I have even seen a 1.5 mill polygon sized asset on the DLS) and TS12 still runs somewhat happily along, oblivious and unaware of these issues and still performs often a LOT BETTER and more then reasonable fine as TANE presently does on medium specced PCs

In my experience, with a similar scene and similar performance settings, T:ANE is faster than TS12.

Don't compare T:ANE with all options enabled to TS12; TS12 simply doesn't have a lot of the capabilities of T:ANE, and those capabilities (when enabled) come with a cost. If you set TS12 and T:ANE each to maximum draw distance, you're talking about 19 square kilometres visible in TS12 and 254 square kilometres visible in T:ANE; under those conditions there will obviously be a performance difference. Similarly, T:ANE offers fully dynamic shadows, TS12 doesn't. T:ANE offers post-processing, TS12 doesn't, and so on.

chris

WindWalkr
July 27th, 2015, 02:51 AM
And to avoid this turning into a TS12-vs-T:ANE debate, I should add that we did a lot of profiling in Trainz/Jet and loco performance sucks there too. This is not about the engine, except in terms of "how can we improve content creation capabilities to enable more efficient content."

chris

VinnyBarb
July 27th, 2015, 06:47 PM
http://forums.auran.com/trainz/images/misc/quote_icon.png Originally Posted by VinnyBarb http://forums.auran.com/trainz/images/buttons/viewpost-right.png (http://forums.auran.com/trainz/showthread.php?p=1425592#post1425592)
..reducing the lowest LOD to satisfy your TOO RIGOROUS minimum requirements for the lowest LODs, say, for highly detailed locomotives.

Chris's reply:

If you say this, then you don't understand what LOD is. LOD really has nothing to do with the amount of detail in your loco. In fact, it's fair to say that LOD allows you to INCREASE the amount of detail in your loco, while getting better performance to boot. The whole point of LOD is to allow us to use a lot of detail up close, while dropping away the detail that you can't really see to ensure that overall performance remains good.

You haven't read my whole post above, mainly and plainly it is about the LAST LOD requirements you now impose on us Content Creators (CCs), it is NOT about the other LODs in an asset. Which means in PLAIN ENGLISH, the requirements/limits of polygons and triangles imposed on us CCs and enforced now FOR THE LAST/LEAST LOD mesh is IMHO too strict for complex meshes WITH attachment points where other meshes are attached to. THIS IS the whole and main point of my post above which you seem to turn into a generic LOD preaching.

For starters, my point about my meaning of polygons regarding using any 3D software to create a mesh, suitable to load into Trainz differs from your interpretation of polygons and triangles. Shall I explain the polygons I and most other content creators see in our 3D software and we mean, when CCs talk about polygons?

A polygon is any shape made up of straight lines that can be drawn on a flat surface, like on a piece of paper. Such shapes include squares, rectangles, triangles and pentagons but not circles or any other shape that includes a curve.

Triangles are polygons, but polygons aren't necessarily triangles. All polygons that have more than 3 sides can be broken down into triangles.

All 3D objects that we see on the computer screen are actually made of tiny little geometrical objects often called primitives. Quadrilaterals, triangles, n-gons etc. are example of primitives. We will concentrate on triangles mostly because of one main reason: every object can be split into triangles but a triangle cannot be split into anything else than triangles. Because of this, drawing triangles is a lot simpler than drawing polygons of higher order; less things to deal with. This is why those triangles are so commonly referenced and used in computer graphics.

End of classroom lecture.

Meaning of course, we content creators are only concerned when speaking of polygons of such square and oblong FLAT shapes, which of course contain at least 2 triangles each. Hence from our CCs point of view, a polygon IS a polygon, no matter how one turns and slices this.

You of course speak of triangles, when you speak of 500 "polygons" but you really DO NOT speak of at least 1000 triangles in these 500 "polygons" as we CCs see these as is shown in the above text, hence your 500 "polygon" limit imposed on us CCs is NOT a 1000 triangle limit for us CCs (of the last LOD required) but at the very least a 500 triangle limit only. Which even blind Freddy can plainly see (with apologies to the visual challenged). If you change the meaning and the requirements for the last LOD limit to 500 of your "polygons", one can see, you actually half this limit for the last LOD for us down to 500 triangles only, restricting us CCs even more as your 500 "polygons" are ONLY 250 of our polygons. As my and most other CCs definition of a our 500 POLYGONs is of having at least 1000 TRIANGLES.

chris
Triangles are polygons. More importantly, triangles are the ONLY polygons the Trainz supports. In Trainz (and in most other games, since this is really a GPU thing rather than something that we impose) the words "triangles" and "polygons" are interchangeable.

I understand this double meaning BUT this is NOT Content Creator speak for polygons but DO YOU REALLY understand OUR POINT OF VIEW about polygons? If you want to convey your meaning of something you try to explain, YOU NEED TO explain this to what we, as CCs are used to and what WE MEAN, when talking and posting as CCs here. After all, this forum is ABOUT content creating, FOR Content Creators.
Check above the true meaning of POLYGONS:

Triangles are polygons, but polygons aren't necessarily triangles. All polygons that have more than 3 sides can be broken down into triangles.

I understand, from your point of view and what a GPU on a video card sees and processes, this is only expressed in TRIANGLES with 3 vertices only. Actually, a GPU processes not triangles per se, it is only the 3 vertices of any triangle for its calculations are used but this is subject for somewhere else. Something to refresh your memory with:

http://blog.digitaltutors.com/modeling-with-quads-or-triangles/

https://en.wikipedia.org/wiki/Polygonal_modeling

https://en.wikipedia.org/wiki/Polygon_mesh

chris
There's nothing the code can do to fix it. If your mesh needs the texture at high detail to avoid having user-visible degradation, the code will try to keep the texture at high detail. That's the whole point of the texture streaming system. If your model is set up so that it needs 5% of the texture at high detail despite being at several kilometres from the camera, then the code will make sure that the whole texture is at high detail even though the other 95% goes unused. (Caveat: if you use different texture detail in different parts of your mesh, the code will pick an "average" value.)

If an exported mesh is set up with an LM.txt file, sure, in there is the reference to specify what to use where. No CC in his/her right mind WILL SET UP an asset several kms away to only use 5% of the texture map at high detail. What you outline there is clutching at straws and IS VERY EXTREME, IMHO.

chris
No. You seem to be confusing meshes and textures.

Who is the confused one here? I leave that to others who are reading this. All I stated in my further above post (read it again) is to say, you could code in Trainz for an asset to use a particular internal compressed texture map (remember, the game engine converts my texture map when installing my asset into several instances of compressed lesser detailed texture maps), to use either on a static scenery asset at the distance YOU coded into Trainz or I, having a LM.txt file for, say, a locomotive or an elaborate, animated scenery asset, where I can change the distances where these compressed texture maps changes might occur, to some extent, as the tag references in the LM.txt file will let me do this. By culling or stopping either animations, the asset itself, render etc. or by other means in there (I don't know if any new tags for TANE for a LM.txt file are yet made):

version 1.0

offset = 0.01;
calcpoint = center;
multiplier = 1.0;
animationCutOff = 0.00;
renderCutOff = 0.00;
attachmentCutOff = 0.06;
mesh("0.07")

etc.......

Re TS12 against TANE, it is best to leave this out of this polygons/triangles discussions, I only brought this into view to show what I experienced when importing my TS12 route into TANE and as these were set up in each version of Trainz. I understand, you need to defend yourself regarding performance optimization for TANE, my reference to TS12 and TANE was to highlight this only. These 2 Trainz versions are 2 "completely" different examples. Just briefly, WHY would we need in TANE such a big/wide/far drawing distance as in reality one, if driving a train either in outside view or in cab mode never ever will see that far ahead. Wouldn't cutting down in your code this drawing distance to realistic dimensions be a lot easier on performance IF implemented straight from the start? Not every one will adjust the options in TANE when using it. I know, I can change that in my options of TANE but surely, there has to be a performance improvement to some extend if making the drawing distance code less than it is now.

VinnyBarb

ZecMurphy
July 27th, 2015, 08:03 PM
Good Morning Vinnybarb
Remember, your object could be 2KM away on that last LOD. However, Trainz can now display objects up to 15 kilometers away. A GOOD LOD is essential for this. Remember, you're not talking about just your locomotive. You're talking about an object in an overall scene; and as such you need to ensure that your object is going to perform well in that overall scene. Not just close up, but at a long distance.

To give an example, the steam locomotive in this screenshot will LOD down to a grand total of 107 triangles at approximately 1100m: http://www.zecrail.com/files/tane/m-class-214-at-lilydale-at-night.jpg

This was done quite simply by taking renders of the left, right, front, back, and top 'sides' of the model; and applying these to a mesh made from relatively simple boxes. It has an alpha channel to provide transparency under the boiler, shape to the funnel and dome, through the cab, and through the wheels and frames. The texture is 128x128 pixels. A separate texture was done mainly to prevent using the large texture at higher mips (128x128 on a 2048x2048 map is going to cause it to display that map at quite a large mipmap level), but also to allow the best use of those higher res textures on the close up models.

It should be noted that the loco has 5 levels of LOD; each dropping by 20-50% each time. The last drop is quite substantial as well. It goes from 3595tri to 107tri. Actually, it's greater than this as I cull all attachment points at this transition, which includes bogies, couplers, etc. So it's probably going from about 6000 triangles to 107 triangles. I decided it wasn't worth making another texture to get the bogies down to a lower poly count, since the loco already does this.


In regards to mipmapping; this is automatic. Trainz will select the most appropriate mipmap for the distance from the object. It has nothing to do with your mesh LOD; and really doesn't need to have anything to do with it.

The relation of the mipmap to LOD though is that at lower LODs you should either use the same texture space; or try to scale it the same. Use a tiny area for the last LOD, and Trainz will try to display it at an appropriate size. Even tying it to the LOD transitions will just mean that this last transition would cause a larger version of the texture to be used; just to display the last LOD at what ever distance (it could be over a kilometer away from the camera!).

As to the draw distance; I did a test on one of my current maps (the Cudgewa railway in North East Victoria). From one of the bridges, in a cleared gully on the side of a mountain, I was able to the other mountain approx 15km away. Since it overlooks a relatively flat area, I would probably be ablt to see about 30KM away or more. It should be noted that this is a point at which the line is traveling somewhat north south, but turns to run east west (looking west) a short distance away, meaning that they player is essentially looking along the direction of travel. There are many other spots on the route that will produce similar views. Thankfully, it's mostly in a valley; meaning that the views north/south are restricted by mountains, so less draw distance is required (And the route is only about 10KM wide IIRC).

This view would be visible both from the locomotive cab, and from various other camera views as well. And there are plenty of other locations with similar views; it actually adds a heck of a lot to the graphical experience in the game IMO. OTOH, if you don't want to see that far, you can turn it down and get even better performance.

But, to produce such views, the LOD on all objects needs to be good.

Regards

Dinorius_Redundicus
July 27th, 2015, 09:40 PM
[That sure was a high word count to establish that polygon count = triangle count!]

Anyway, in connection with Rumour3's initial question about textures, mip-mapping and LOD, I have noticed that mip-mapping seems to be a lot more "aggressive" in T:ANE and it can be quite a problem for the modeller.

I was upgrading an old asset from TS2010 to TANE standards. It was a building, 16 x 8 x 12 metres in size, texture-mapped from a single 1024 x 512 pixel image. The same image and mapping applied to each of the 6 LOD's. If my reading of this thread is right, that's a reasonable way to build.

What I noticed was that in TS2010, the texture was suitably sharp close up and became gradually less distinct as the camera pulled back from it - meaning it looked fairly natural. However with the same model in T:ANE, the texture suddenly went from sharp to blurred just 10 metres away from the building. A sudden drop in visual quality so close to the object looks anything but natural and was not what I expected from a version of Trainz being promoted for its good looks.

My graphics are handled by an nVidia GTX980Ti card and I used the highest anti-alias settings in both versions of Trainz (4x in TS2010, 8x in T:ANE) so I can't blame those things. I tried various mip-map settings in the texture.txt file, but could not stop the sudden blurring.

Is this indeed a mip-map effect or could it be something else? Has the mip-mapping system in T:ANE been changed such that it would explain why it's performing so badly in this instance? Would N3V consider looking into improving it?

~ Deane

.

pcas1986
July 27th, 2015, 09:45 PM
In support of Zec's argument consider this coupler I made a little while back:

This is a view of the LOD0 (hi poly) version as shown in the IM viewer in AssetX.

http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.07.28_12h22m22s_001__zpss4ljdhg v.jpg

And a view of the LOD3 version. This version uses masking.

http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2015.07.28_12h23m58s_002__zps9rdsvq1 q.jpg

LOD0 tops out at 612 tris and LOD3 is only 8 tris. LOD0 is perhaps a bit high but is only ever intended to be seen at close range using an early transition to LOD1. Despite looking rather odd in the viewer, LOD3 looks very good at distance in T:ANE. If you have been reading Chris' comments in the 77412 thread you might be aware that changes are planned for attachments and LOD so I'll probably rework this particular asset to have less LOD levels and cull early.

WindWalkr
July 27th, 2015, 11:18 PM
Anyway, in connection with Rumour3's initial question about textures, mip-mapping and LOD, I have noticed that mip-mapping seems to be a lot more "aggressive" in T:ANE and it can be quite a problem for the modeller.

It shouldn't be; if you think you have a clear problem demo, please email in a simple test asset including any necessary instructions and ts12 vs tane screenshots.

Also, please be aware that you're talking about what we call "texture streaming", which is not actually mip-mapping. Mip-mapping is a process for avoiding moire effects by deliberately downsampling the textures. Texture streaming works by loading and unloading the higher-resolution mips, but it is not a function of mipmapping.

chris

Dinorius_Redundicus
July 27th, 2015, 11:56 PM
It shouldn't be; if you think you have a clear problem demo, please email in a simple test asset including any necessary instructions and ts12 vs tane screenshots.

Also, please be aware that you're talking about what we call "texture streaming", which is not actually mip-mapping. Mip-mapping is a process for avoiding moire effects by deliberately downsampling the textures. Texture streaming works by loading and unloading the higher-resolution mips, but it is not a function of mipmapping.

chris

OK, texture streaming not mip mapping, thanks for correcting that. I did have streaming enabled in my T:ANE (76536) settings when I was doing this.

The example asset is <kuid2:68213:39007:2> Temple Nai Harn 01 - a trainz-build 4.2 object available on the DLS. To see it in TS2010 (don't have TS12), I just changed the build to 3.3 and added a "light 1" tag to config.txt.

Some screenshots to demonstrate what I saw: it's the gaudy art work on the gables that most noticeably goes fuzzy at short distances in TANE but not in TS2010. And it's not just the fuzziness that bothers me, but also the way it suddenly "jumps" to that state (in TANE) which is not desirable. You could only see that effect properly by looking at the object in the game.

Chris, I can send you the objects and a more extensive set of screenshots by e-mail if you want (let me know) but I think these few pics pretty much capture the story.


~ Deane



TS2010 at 10 metres
http://i570.photobucket.com/albums/ss147/deane_tunaley/Trainz/TS2010%20Thai%20temple%20at%2010m.jpg~original



TANE at 10 metres
http://i570.photobucket.com/albums/ss147/deane_tunaley/Trainz/TANE%20thai%20temple%20at%2010m.jpg~original



TS2010 at 30 metres
http://i570.photobucket.com/albums/ss147/deane_tunaley/Trainz/TS2010%20Thai%20temple%20at%2030m.jpg~original



TANE at 30 metres
http://i570.photobucket.com/albums/ss147/deane_tunaley/Trainz/TANE%20thai%20temple%20at%2030m.jpg~original



.

WindWalkr
July 28th, 2015, 12:53 AM
Thanks.

chris

Dinorius_Redundicus
July 28th, 2015, 09:57 AM
Screenshots now inserted in my previous post.

WindWalkr
August 10th, 2015, 03:09 AM
Should be improved in the next test build. Please let me know. (Don't just test on a single asset because it's possible that there's something asset-specific going on that we haven't picked up on.)

chris