Art Recommendations - Revision history

Tonyhilliam at 08:07, 12 June 2018

2018-06-12T08:07:55Z

← Older revision		Revision as of 08:07, 12 June 2018
Line 1:		Line 1:
			TRS19 provides a major step forward in graphical capabilities, and along with those new features comes the increasing challenge to ensure as many people as possible can take advantage of the content. It is therefore our goal to assist content creators as much as possible to improve the performance and the quality of their content moving forward.

	This document seeks to provide guidance for content creators working at the [[TRS19]] modeling standard. This is a living document and will be updated based on our real-world experiences. That said, content creators should avoid the temptation to ignore the recommendations put forward in this document "for this model only" as that type of thinking quickly leads to an inefficient content set and poor overall performance. Performance is a holistic subject which requires an ongoing commitment.		This document seeks to provide guidance for content creators working at the [[TRS19]] modeling standard. This is a living document and will be updated based on our real-world experiences. That said, content creators should avoid the temptation to ignore the recommendations put forward in this document "for this model only" as that type of thinking quickly leads to an inefficient content set and poor overall performance. Performance is a holistic subject which requires an ongoing commitment.

Windwalkr at 03:21, 6 June 2018

2018-06-06T03:21:40Z

← Older revision		Revision as of 03:21, 6 June 2018
Line 1:		Line 1:
	This document seeks to provide guidance for content creators working at the [[~~TRS18~~]] modeling standard. This is a living document and will be updated based on our real-world experiences. That said, content creators should avoid the temptation to ignore the recommendations put forward in this document "for this model only" as that type of thinking quickly leads to an inefficient content set and poor overall performance. Performance is a holistic subject which requires an ongoing commitment.		This document seeks to provide guidance for content creators working at the [[TRS19]] modeling standard. This is a living document and will be updated based on our real-world experiences. That said, content creators should avoid the temptation to ignore the recommendations put forward in this document "for this model only" as that type of thinking quickly leads to an inefficient content set and poor overall performance. Performance is a holistic subject which requires an ongoing commitment.

	It is also important to understand the intent of each recommendation, rather than to blindly follow each. There are frequently conflicting demands which only the individual creator can balance. Religiously following the rules without understand why is suitable for beginner creators who are building simple variations on a fixed template, but more advanced creators will need to understand the benefits and tradeoffs of each decision that they make.		It is also important to understand the intent of each recommendation, rather than to blindly follow each. There are frequently conflicting demands which only the individual creator can balance. Religiously following the rules without understand why is suitable for beginner creators who are building simple variations on a fixed template, but more advanced creators will need to understand the benefits and tradeoffs of each decision that they make.
Line 17:		Line 17:

	=Modeling Overview=		=Modeling Overview=
	All ~~TRS18~~ art should be built with the following principles in mind:		All TRS19 art should be built with the following principles in mind:
	* There are very few items close to the camera at any time, yet paradoxically these items are typically the most important in the scene. It is very important to ensure that every item looks excellent at extreme close range. The highest [[Level of Detail\|LODs]] can afford to be fairly excessive, as long as the extra detail is removed quickly in lower LODs.		* There are very few items close to the camera at any time, yet paradoxically these items are typically the most important in the scene. It is very important to ensure that every item looks excellent at extreme close range. The highest [[Level of Detail\|LODs]] can afford to be fairly excessive, as long as the extra detail is removed quickly in lower LODs.
	* "Background-only" low quality scenery should not exist. Trainz is an open-ended game where users can use any scenery for any purpose, so the original intentions of the content creator cannot be enforced. Trainz offers efficient LOD and stitching systems, so there are no performance gains from creating "low LOD only" models. This is simply lazy modeling. Similarly, we discourage serious route creators from using such models - even if the models are used appropriately in their route - because this causes the scenery to be installed on the end-user's computer when we'd prefer to discourage the use of these items.		* "Background-only" low quality scenery should not exist. Trainz is an open-ended game where users can use any scenery for any purpose, so the original intentions of the content creator cannot be enforced. Trainz offers efficient LOD and stitching systems, so there are no performance gains from creating "low LOD only" models. This is simply lazy modeling. Similarly, we discourage serious route creators from using such models - even if the models are used appropriately in their route - because this causes the scenery to be installed on the end-user's computer when we'd prefer to discourage the use of these items.
Line 309:		Line 309:
	Ground Textures are a fundamental aspect of Trainz rendering; it is not possible to switch them off entirely. There are however various ways that you can influence the performance and quality of the ground rendering.		Ground Textures are a fundamental aspect of Trainz rendering; it is not possible to switch them off entirely. There are however various ways that you can influence the performance and quality of the ground rendering.

	~~TRS18~~ introduces [[KIND Groundtexture\|PBR ground textures]]. These are much higher quality than traditional Trainz ground textures and (if properly constructed) don't suffer from regular tiling in the same way that older textures could. This means that you don't need to continuously change texture and cross-blend textures in order to avoid tiling. In fact, it is very strongly recommended that you do not do this as it may severely impact both visual quality and performance.		TRS19 introduces [[KIND Groundtexture\|PBR ground textures]]. These are much higher quality than traditional Trainz ground textures and (if properly constructed) don't suffer from regular tiling in the same way that older textures could. This means that you don't need to continuously change texture and cross-blend textures in order to avoid tiling. In fact, it is very strongly recommended that you do not do this as it may severely impact both visual quality and performance.

	PBR ground textures support Parallax rendering. This is an expensive but effective technique which introduces a per-texel heightmap and uses it to deform the ground texture. From most perspectives, this is indistinguishable from actual geometry. The heightmap is self-shadowing and self-occluding. The heightmap will intersect correctly with surrounding geometry.		PBR ground textures support Parallax rendering. This is an expensive but effective technique which introduces a per-texel heightmap and uses it to deform the ground texture. From most perspectives, this is indistinguishable from actual geometry. The heightmap is self-shadowing and self-occluding. The heightmap will intersect correctly with surrounding geometry.
Line 384:		Line 384:

	[[Category:Modeling]]		[[Category:Modeling]]
	[[Category:~~TRS18~~]]		[[Category:TRS19]]

Tonyhilliam at 02:22, 17 January 2018

2018-01-17T02:22:23Z

← Older revision		Revision as of 02:22, 17 January 2018
Line 384:		Line 384:

	[[Category:Modeling]]		[[Category:Modeling]]
			[[Category:TRS18]]

Tonyhilliam at 00:35, 17 January 2018

2018-01-17T00:35:21Z

← Older revision		Revision as of 00:35, 17 January 2018
Line 24:		Line 24:
	* Use [[parallax mapping]] wherever it makes sense. There is a performance cost, however it is expected that users will switch it on or off as appropriate for their machine. Parallax is not a miracle-cure for low-polygon modeling, but it can substantially improve the visual quality of an already-decent model.		* Use [[parallax mapping]] wherever it makes sense. There is a performance cost, however it is expected that users will switch it on or off as appropriate for their machine. Parallax is not a miracle-cure for low-polygon modeling, but it can substantially improve the visual quality of an already-decent model.

	When modeling:		'''When modeling:'''
	* Don't create polygons which are not visible. This is pure wastage. An example of this is a cube attached to a wall. A normal cube requires 6 faces (12 polygons). A cube attached to a wall requires 5 faces (10 polygons). This can be a substantial source of wasted performance- not just because of the extra polygons (maybe only a 20% cost), but because of [[overdraw]] (up to 100% cost).		* Don't create polygons which are not visible. This is pure wastage. An example of this is a cube attached to a wall. A normal cube requires 6 faces (12 polygons). A cube attached to a wall requires 5 faces (10 polygons). This can be a substantial source of wasted performance- not just because of the extra polygons (maybe only a 20% cost), but because of [[overdraw]] (up to 100% cost).
	* Avoid creating large polygons where substantial parts of the polygon are not visible. This can introduce expensive overdraw. There is often a tradeoff between overdraw and polygon count which you will need to balance. Adding a small number of extra polygons to halve the overdraw is very worthwhile. Adding thousands of polygons for a small gain in overdraw is probably not.		* Avoid creating large polygons where substantial parts of the polygon are not visible. This can introduce expensive overdraw. There is often a tradeoff between overdraw and polygon count which you will need to balance. Adding a small number of extra polygons to halve the overdraw is very worthwhile. Adding thousands of polygons for a small gain in overdraw is probably not.
Line 33:		Line 33:
	* Vertices are not polygons. A contiguous [[mesh]] gives close to a 1:1 relationship between polygons and vertices. In cases where the meshes are not contiguous (including open edges, or unsmoothed edges) this can move closer to 3 vertices to 1 polygon. There are costs to both vertices and polygons.		* Vertices are not polygons. A contiguous [[mesh]] gives close to a 1:1 relationship between polygons and vertices. In cases where the meshes are not contiguous (including open edges, or unsmoothed edges) this can move closer to 3 vertices to 1 polygon. There are costs to both vertices and polygons.

	When texturing:		'''When texturing:'''
	* Reduce the number of [[material]]s in your asset. This is true at any detail level, but especially true at lower LOD levels.		* Reduce the number of [[material]]s in your asset. This is true at any detail level, but especially true at lower LOD levels.
	* Each separate color [[texture]] usage forces a new material, so the more textures you have, the more materials you have. Reduce the number of textures.		* Each separate color [[texture]] usage forces a new material, so the more textures you have, the more materials you have. Reduce the number of textures.
Line 46:		Line 46:
	* If your model has painted lines, as often happens with train liveries, consider aligning your texture map such that the lines flow vertically or horizontally along the texture. This may help reduce aliasing, causing your texture to look crisper. Where the lines are lightly curved, you may be able to get away with "cutting out" the line in a small number of rectangular segments, each of which holds a nearly straight line. By aligning each to the texture, you not only straighten the line along the grain of the texture but also reduce the area of texture required to map the line. Remember that you can arbitrarily cut the line at the texture edges, in a similar manner to the lines of text on this page. Straighter lines are likely to give far superior visual results when texture compression is in use.		* If your model has painted lines, as often happens with train liveries, consider aligning your texture map such that the lines flow vertically or horizontally along the texture. This may help reduce aliasing, causing your texture to look crisper. Where the lines are lightly curved, you may be able to get away with "cutting out" the line in a small number of rectangular segments, each of which holds a nearly straight line. By aligning each to the texture, you not only straighten the line along the grain of the texture but also reduce the area of texture required to map the line. Remember that you can arbitrarily cut the line at the texture edges, in a similar manner to the lines of text on this page. Straighter lines are likely to give far superior visual results when texture compression is in use.

	Texture Compression		'''Texture Compression:'''
	* By default, Trainz compresses all textures. You can adjust the texture compression algorithm or turn it off entirely.		* By default, Trainz compresses all textures. You can adjust the texture compression algorithm or turn it off entirely.
	* Texture compression saves space (boosting performance and load times and reducing VRAM usage) but reduces quality, sometimes substantially. Natural images tend to fare well, whereas two patches of contrasting colours meeting at a sharp edge can distort noticeably.		* Texture compression saves space (boosting performance and load times and reducing VRAM usage) but reduces quality, sometimes substantially. Natural images tend to fare well, whereas two patches of contrasting colours meeting at a sharp edge can distort noticeably.
Line 61:		Line 61:
	*** But be careful of [[draw call]] count. Don't add more textures if you're trying to reduce draw call count.		*** But be careful of [[draw call]] count. Don't add more textures if you're trying to reduce draw call count.

	When ~~it comes to~~ building LODs~~, the following should be kept in mind~~:		'''When building LODs:'''
	* LOD transitions take CPU time, GPU time, and may distract the user. Avoid unnecessary transitions. Try to time the transitions so that they can occur at reasonable spacing and shave off a significant number of polygons (etc) with each step. Maximise the gain from each amount of pain.		* LOD transitions take CPU time, GPU time, and may distract the user. Avoid unnecessary transitions. Try to time the transitions so that they can occur at reasonable spacing and shave off a significant number of polygons (etc) with each step. Maximise the gain from each amount of pain.
	* Texture LOD is automatic. Do not manually introduce lower-detail textures as this will simply lower performance.		* Texture LOD is automatic. Do not manually introduce lower-detail textures as this will simply lower performance.
Line 84:		Line 84:
	* TBD: polys vs normals.		* TBD: polys vs normals.

	Normal Maps:		'''Normal Maps:'''
	* Providing a correct [[normal map]] is nearly as important as providing the correct [[albedo]] (surface color) texture and is often more important the providing quality geometry. If your normal map is not suitable, you will end up with incorrect lighting conditions, with dark areas where you expect light or vice versa.		* Providing a correct [[normal map]] is nearly as important as providing the correct [[albedo]] (surface color) texture and is often more important the providing quality geometry. If your normal map is not suitable, you will end up with incorrect lighting conditions, with dark areas where you expect light or vice versa.
	* Normal maps and geometry are traditionally created simultaneously by:		* Normal maps and geometry are traditionally created simultaneously by:
Line 96:		Line 96:
	* Normal maps are stored in [[tangent space]] and are dependent on the actual geometry present in the LOD as well as the simulated geometry that is represented by the map. This means that it is not appropriate to take a normal map created for one LOD and use it for another substantially different LOD, even if the simulated geometry is identical. "Substantially different" in this case is one in which the [[vertex normals]] or [[UV mapping]] are noticeably different.		* Normal maps are stored in [[tangent space]] and are dependent on the actual geometry present in the LOD as well as the simulated geometry that is represented by the map. This means that it is not appropriate to take a normal map created for one LOD and use it for another substantially different LOD, even if the simulated geometry is identical. "Substantially different" in this case is one in which the [[vertex normals]] or [[UV mapping]] are noticeably different.

	Animation:		'''Animation:'''
	* Care should be taken when exporting animated meshes to ensure that low-LOD variants or non-animated variants do not still contain bones or other animation data. Even if an animation is not actively being played, costs are incurred by the presence of bones.		* Care should be taken when exporting animated meshes to ensure that low-LOD variants or non-animated variants do not still contain bones or other animation data. Even if an animation is not actively being played, costs are incurred by the presence of bones.
	* [[LM.txt file]]s allow you to switch off playback of animation past a certain distance. This is a separate decision to whether each submesh of the LM contains bones. An animation can be playing even though no bones are present to visualise it. Separately, an animation can be paused even though bones are present and displaying it. You should take care to both pause the animation at an appropriate distance and also to remove bones from the lowest LOD meshes.		* [[LM.txt file]]s allow you to switch off playback of animation past a certain distance. This is a separate decision to whether each submesh of the LM contains bones. An animation can be playing even though no bones are present to visualise it. Separately, an animation can be paused even though bones are present and displaying it. You should take care to both pause the animation at an appropriate distance and also to remove bones from the lowest LOD meshes.
	* [[Mesh-table]]s apply animation per submesh. Unlike LM files, they do not share animations between submeshes. If the same animation file is applied to multiple submeshes, this will load several animation instances which will then play independently. This means that mesh-table animations are typically only appropriate where the highest LOD is animated but all lower LODs are not animated. This might be useful where the animation is very subtle (so that the user can notice it when extremely close to the object, but doesn't notice it vanish and doesn't miss it while it's some distance away) but should not be used where the animation makes obvious changes to the mesh- for example on a crane. Subtle foliage wind animations, human/animal idle animations, and fan rotation might be reasonable under these limitations.		* [[Mesh-table]]s apply animation per submesh. Unlike LM files, they do not share animations between submeshes. If the same animation file is applied to multiple submeshes, this will load several animation instances which will then play independently. This means that mesh-table animations are typically only appropriate where the highest LOD is animated but all lower LODs are not animated. This might be useful where the animation is very subtle (so that the user can notice it when extremely close to the object, but doesn't notice it vanish and doesn't miss it while it's some distance away) but should not be used where the animation makes obvious changes to the mesh- for example on a crane. Subtle foliage wind animations, human/animal idle animations, and fan rotation might be reasonable under these limitations.

	General guidelines:		'''General guidelines:'''
	* Don't rely on assumptions that you are doing the right things. There are many ways to make mistakes, and many optimisations are affected by the exact construction of your asset, so it's possible to "tick all the right boxes" and still end up with a poor-performing asset because you aren't using the optimisations you were aiming at.		* Don't rely on assumptions that you are doing the right things. There are many ways to make mistakes, and many optimisations are affected by the exact construction of your asset, so it's possible to "tick all the right boxes" and still end up with a poor-performing asset because you aren't using the optimisations you were aiming at.
	* Do use the [[preview asset]] in-game. If you are seeing "wrong" results from [[preview asset]] then it is very, very likely that the results are correct and that you are making incorrect assumptions. Do not simply assume that [[preview asset]] is feeding you incorrect information and ignore it: it works by measuring the actual results, not by estimating what should happen.		* Do use the [[preview asset]] in-game. If you are seeing "wrong" results from [[preview asset]] then it is very, very likely that the results are correct and that you are making incorrect assumptions. Do not simply assume that [[preview asset]] is feeding you incorrect information and ignore it: it works by measuring the actual results, not by estimating what should happen.
Line 382:		Line 382:
	* Minimise the polygon count per meter of the spline through efficient use of LOD.		* Minimise the polygon count per meter of the spline through efficient use of LOD.
	* Use only a single draw call per spline asset. (ie. Only one material.)		* Use only a single draw call per spline asset. (ie. Only one material.)

			[[Category:Modeling]]

Pencil42: /* Modeling Overview */

2017-11-27T23:48:35Z

Modeling Overview

← Older revision		Revision as of 23:48, 27 November 2017
Line 25:		Line 25:

	When modeling:		When modeling:
	* Don't ~~creating~~ polygons which are not visible. This is pure wastage. An example of this is a cube attached to a wall. A normal cube requires 6 faces (12 polygons). A cube attached to a wall requires 5 faces (10 polygons). This can be a substantial source of wasted performance- not just because of the extra polygons (maybe only a 20% cost), but because of [[overdraw]] (up to 100% cost).		* Don't create polygons which are not visible. This is pure wastage. An example of this is a cube attached to a wall. A normal cube requires 6 faces (12 polygons). A cube attached to a wall requires 5 faces (10 polygons). This can be a substantial source of wasted performance- not just because of the extra polygons (maybe only a 20% cost), but because of [[overdraw]] (up to 100% cost).
	* Avoid creating large polygons where substantial parts of the polygon are not visible. This can introduce expensive overdraw. There is often a tradeoff between overdraw and polygon count which you will need to balance. Adding a small number of extra polygons to halve the overdraw is very worthwhile. Adding thousands of polygons for a small gain in overdraw is probably not.		* Avoid creating large polygons where substantial parts of the polygon are not visible. This can introduce expensive overdraw. There is often a tradeoff between overdraw and polygon count which you will need to balance. Adding a small number of extra polygons to halve the overdraw is very worthwhile. Adding thousands of polygons for a small gain in overdraw is probably not.
	* Remember that overdraw is paid each time a [[fragment]] is hit. If a given fragment is overlapped by 50 polygons, you are paying up to 5000% cost for that fragment.		* Remember that overdraw is paid each time a [[fragment]] is hit. If a given fragment is overlapped by 50 polygons, you are paying up to 5000% cost for that fragment.

N3vpolsen: /* Modeling Overview */

2017-11-10T02:45:03Z

Modeling Overview

← Older revision		Revision as of 02:45, 10 November 2017
Line 42:		Line 42:
	* Avoid texture tiling at the lowest LODs. It's typically not a major saving (because even a uniquely-mapped object will only be a handful of texels) and it prevents atlasing (whether by hand, or automated). It is likely to be flagged as an error condition in the future.		* Avoid texture tiling at the lowest LODs. It's typically not a major saving (because even a uniquely-mapped object will only be a handful of texels) and it prevents atlasing (whether by hand, or automated). It is likely to be flagged as an error condition in the future.
	* [[Texture Atlas\|Atlas]] where it makes sense. All else being equal, if you're going to have three meshes on the screen at the same time, it's better to share a single texture between them rather than use three separate textures.		* [[Texture Atlas\|Atlas]] where it makes sense. All else being equal, if you're going to have three meshes on the screen at the same time, it's better to share a single texture between them rather than use three separate textures.
	* Don't atlas where it makes no sense. If you build a library of assets which share an [[Texture Atlas\|atlas texture]], the entire atlas must be loaded at full resolution even if only a single of the assets is loaded. If you know that assets are unlikely to be used together in the same scene, don't atlas them.		* Don't atlas where it makes no sense. If you build a [[Mesh Libraries\|library]] of assets which share an [[Texture Atlas\|atlas texture]], the entire atlas must be loaded at full resolution even if only a single of the assets is loaded. If you know that assets are unlikely to be used together in the same scene, don't atlas them.
	* Keep the [[texels-to-meters ratio]] roughly constant across your mesh for best visual results. This is especially important within any given material, as the texture LOD algorithms work with a single pre-calculated ratio per [[render chunk]].		* Keep the [[texels-to-meters ratio]] roughly constant across your mesh for best visual results. This is especially important within any given material, as the texture LOD algorithms work with a single pre-calculated ratio per [[render chunk]].
	* If your model has painted lines, as often happens with train liveries, consider aligning your texture map such that the lines flow vertically or horizontally along the texture. This may help reduce aliasing, causing your texture to look crisper. Where the lines are lightly curved, you may be able to get away with "cutting out" the line in a small number of rectangular segments, each of which holds a nearly straight line. By aligning each to the texture, you not only straighten the line along the grain of the texture but also reduce the area of texture required to map the line. Remember that you can arbitrarily cut the line at the texture edges, in a similar manner to the lines of text on this page. Straighter lines are likely to give far superior visual results when texture compression is in use.		* If your model has painted lines, as often happens with train liveries, consider aligning your texture map such that the lines flow vertically or horizontally along the texture. This may help reduce aliasing, causing your texture to look crisper. Where the lines are lightly curved, you may be able to get away with "cutting out" the line in a small number of rectangular segments, each of which holds a nearly straight line. By aligning each to the texture, you not only straighten the line along the grain of the texture but also reduce the area of texture required to map the line. Remember that you can arbitrarily cut the line at the texture edges, in a similar manner to the lines of text on this page. Straighter lines are likely to give far superior visual results when texture compression is in use.

N3vpolsen: /* Modeling Overview */

2017-11-10T02:44:09Z

Modeling Overview

← Older revision		Revision as of 02:44, 10 November 2017
Line 42:		Line 42:
	* Avoid texture tiling at the lowest LODs. It's typically not a major saving (because even a uniquely-mapped object will only be a handful of texels) and it prevents atlasing (whether by hand, or automated). It is likely to be flagged as an error condition in the future.		* Avoid texture tiling at the lowest LODs. It's typically not a major saving (because even a uniquely-mapped object will only be a handful of texels) and it prevents atlasing (whether by hand, or automated). It is likely to be flagged as an error condition in the future.
	* [[Texture Atlas\|Atlas]] where it makes sense. All else being equal, if you're going to have three meshes on the screen at the same time, it's better to share a single texture between them rather than use three separate textures.		* [[Texture Atlas\|Atlas]] where it makes sense. All else being equal, if you're going to have three meshes on the screen at the same time, it's better to share a single texture between them rather than use three separate textures.
	* Don't atlas where it makes no sense. If you build a library of assets which share an atlas texture, the entire atlas must be loaded at full resolution even if only a single of the assets is loaded. If you know that assets are unlikely to be used together in the same scene, don't atlas them.		* Don't atlas where it makes no sense. If you build a library of assets which share an [[Texture Atlas\|atlas texture]], the entire atlas must be loaded at full resolution even if only a single of the assets is loaded. If you know that assets are unlikely to be used together in the same scene, don't atlas them.
	* Keep the [[texels-to-meters ratio]] roughly constant across your mesh for best visual results. This is especially important within any given material, as the texture LOD algorithms work with a single pre-calculated ratio per [[render chunk]].		* Keep the [[texels-to-meters ratio]] roughly constant across your mesh for best visual results. This is especially important within any given material, as the texture LOD algorithms work with a single pre-calculated ratio per [[render chunk]].
	* If your model has painted lines, as often happens with train liveries, consider aligning your texture map such that the lines flow vertically or horizontally along the texture. This may help reduce aliasing, causing your texture to look crisper. Where the lines are lightly curved, you may be able to get away with "cutting out" the line in a small number of rectangular segments, each of which holds a nearly straight line. By aligning each to the texture, you not only straighten the line along the grain of the texture but also reduce the area of texture required to map the line. Remember that you can arbitrarily cut the line at the texture edges, in a similar manner to the lines of text on this page. Straighter lines are likely to give far superior visual results when texture compression is in use.		* If your model has painted lines, as often happens with train liveries, consider aligning your texture map such that the lines flow vertically or horizontally along the texture. This may help reduce aliasing, causing your texture to look crisper. Where the lines are lightly curved, you may be able to get away with "cutting out" the line in a small number of rectangular segments, each of which holds a nearly straight line. By aligning each to the texture, you not only straighten the line along the grain of the texture but also reduce the area of texture required to map the line. Remember that you can arbitrarily cut the line at the texture edges, in a similar manner to the lines of text on this page. Straighter lines are likely to give far superior visual results when texture compression is in use.

N3vpolsen: /* Modeling Overview */

2017-11-10T02:43:37Z

Modeling Overview

← Older revision		Revision as of 02:43, 10 November 2017
Line 41:		Line 41:
	* [[Texture tiling]] is a great way to cheaply fill a large polygon with detail, however it has a number of downsides. For starters, it can make it harder (one-way tiling) or impossible (two-way tiling) to share the texture with other geometry. Secondly, each repeat is identical (unless you're using a detail texture) and so the overall result can feel quite unnatural. Be careful about what you choose to tile, to ensure that the gains outweigh the downsides.		* [[Texture tiling]] is a great way to cheaply fill a large polygon with detail, however it has a number of downsides. For starters, it can make it harder (one-way tiling) or impossible (two-way tiling) to share the texture with other geometry. Secondly, each repeat is identical (unless you're using a detail texture) and so the overall result can feel quite unnatural. Be careful about what you choose to tile, to ensure that the gains outweigh the downsides.
	* Avoid texture tiling at the lowest LODs. It's typically not a major saving (because even a uniquely-mapped object will only be a handful of texels) and it prevents atlasing (whether by hand, or automated). It is likely to be flagged as an error condition in the future.		* Avoid texture tiling at the lowest LODs. It's typically not a major saving (because even a uniquely-mapped object will only be a handful of texels) and it prevents atlasing (whether by hand, or automated). It is likely to be flagged as an error condition in the future.
	* [[Texture ~~atlas~~\|Atlas]] where it makes sense. All else being equal, if you're going to have three meshes on the screen at the same time, it's better to share a single texture between them rather than use three separate textures.		* [[Texture Atlas\|Atlas]] where it makes sense. All else being equal, if you're going to have three meshes on the screen at the same time, it's better to share a single texture between them rather than use three separate textures.
	* Don't atlas where it makes no sense. If you build a library of assets which share an atlas texture, the entire atlas must be loaded at full resolution even if only a single of the assets is loaded. If you know that assets are unlikely to be used together in the same scene, don't atlas them.		* Don't atlas where it makes no sense. If you build a library of assets which share an atlas texture, the entire atlas must be loaded at full resolution even if only a single of the assets is loaded. If you know that assets are unlikely to be used together in the same scene, don't atlas them.
	* Keep the [[texels-to-meters ratio]] roughly constant across your mesh for best visual results. This is especially important within any given material, as the texture LOD algorithms work with a single pre-calculated ratio per [[render chunk]].		* Keep the [[texels-to-meters ratio]] roughly constant across your mesh for best visual results. This is especially important within any given material, as the texture LOD algorithms work with a single pre-calculated ratio per [[render chunk]].

Windwalkr at 10:38, 18 October 2017

2017-10-18T10:38:04Z

Show changes

Windwalkr at 09:07, 18 October 2017

2017-10-18T09:07:06Z

Show changes