Dinorius_Redundicus
kuid 68213
If you were asked to identify the technically "most harmful" asset on the Download Station without actually downloading and examining every asset, how would you do it?
It seems to me that the definition of "most harmful" would be some product of how inefficient the asset is AND how many downloads it has accumulated. This would estimate the overall load an asset has placed on the community, not just on an individual user.
Inefficiency
This is usually related to a combination of high poly count (without LOD) and/or a high number of separate texture materials (or more accurately, draw calls). Would asset File Size (as listed in CM) serve as an approximation of those two factors? If so, it could provide a quick way to get a short-list of the potentially worst culprits for closer examination. It might be especially apt for pre-TANE assets which did not have mandatory LOD requirements and were more likely to use simple m.onetex materials.
Downloads
This is more problematic. CM gives no information on the number of downloads. The DLS website does state the downloads, but it requires looking at each asset individually. Is there an N3V database listing kuids against download numbers that could be made accessible? If not, the best I can think of is to filter first by File Size (proxy for "inefficiency"), get a short-list of the worst assets and then examine each one of those on the DLS website to get download numbers.
Why do I ask?
If I could rank my own assets by how "harmful" they have been, then I could prioritize which ones to revisit and improve.
I also get requests to create and issue versions of other creators' assets under my own kuids (often to fix mesh or poly-count issues and/or to improve appearance). I have only done this on a few occasions, and only when I can cite clear permission from the original creators. Rather than wait and rely on requests for things, I could perhaps do the community more good by identifying the most popular/inefficient assets and issue improved versions of those (if permitted). They would not obsolete the originals, but they can be used to replace them.
.
It seems to me that the definition of "most harmful" would be some product of how inefficient the asset is AND how many downloads it has accumulated. This would estimate the overall load an asset has placed on the community, not just on an individual user.
Inefficiency
This is usually related to a combination of high poly count (without LOD) and/or a high number of separate texture materials (or more accurately, draw calls). Would asset File Size (as listed in CM) serve as an approximation of those two factors? If so, it could provide a quick way to get a short-list of the potentially worst culprits for closer examination. It might be especially apt for pre-TANE assets which did not have mandatory LOD requirements and were more likely to use simple m.onetex materials.
Downloads
This is more problematic. CM gives no information on the number of downloads. The DLS website does state the downloads, but it requires looking at each asset individually. Is there an N3V database listing kuids against download numbers that could be made accessible? If not, the best I can think of is to filter first by File Size (proxy for "inefficiency"), get a short-list of the worst assets and then examine each one of those on the DLS website to get download numbers.
Why do I ask?
If I could rank my own assets by how "harmful" they have been, then I could prioritize which ones to revisit and improve.
I also get requests to create and issue versions of other creators' assets under my own kuids (often to fix mesh or poly-count issues and/or to improve appearance). I have only done this on a few occasions, and only when I can cite clear permission from the original creators. Rather than wait and rely on requests for things, I could perhaps do the community more good by identifying the most popular/inefficient assets and issue improved versions of those (if permitted). They would not obsolete the originals, but they can be used to replace them.
.