High Definition Props and Textures - Discussion thread

[callagrafx]

I think it's safe to assume that the same would apply to HD textures.

False premise, as you tested it without other game assets in play, such as an operating transit network, growing buildings, animations, Sims, etc etc etc...  HD Props need to be tested on developed cities otherwise the test is useless.  I would suspect the display was faster was because there were no other processor hungry assets in use.

[z]

False premise, as you tested it without other game assets in play, such as an operating transit network, growing buildings, animations, Sims, etc etc etc... 

This was intentional, as I wanted to properly isolate the prop display time from all those other factors.  Otherwise, you have no idea as to what's causing what.

HD Props need to be tested on developed cities otherwise the test is useless.

Absolute display times may certainly increase in developed and running cities, but why would the relationship between different types of displays change dramatically?  To the contrary, the fact that display times for lower zoom levels increased in the same way I have observed them increasing in fully developed cities is evidence supporting the claim that the relationship between display times is independent of city content.

[buddybud]

I wouldn't say it's useless...i'd say it's a good start! thanks for taking the time to start testing z.

[SimFox]

False premise, as you tested it without other game assets in play, such as an operating transit network, growing buildings, animations, Sims, etc etc etc...  HD Props need to be tested on developed cities otherwise the test is useless.  I would suspect the display was faster was because there were no other processor hungry assets in use.

False premise, you say? Would you care to elaborate as to exact link between the tested feature and other things you've mentioned? And relevance of such a connection? What happened to the "keeping all other things being equal" principal?

Z had made a scientific test, you, on the other hand suggest something that would prove to be totally irrelevant since it introduce such a huge number of uncontrollable variables into equation that distinguishing the exact effect of proposed alteration would be impossible.

and this quote:

I would suspect the display was faster was because there were no other processor hungry assets in use.

suggests that you haven't really read the whole of Z message, may be just glanced it diagonally. Nothing wrong with this method as long as you get what is written, or don't start to comment on it.

Z:
These finding are very much in line to what I have been predicting.

Fast zoom6
Simply displaying 2d data should be faster then generating new (Zoom6) although this process is so fast anyway that the difference wouldn't necessarily be noticeable - think of scrolling photo on your screen, or watching video. HD props display textures in 1.1 ration at zoom6 so no additional manipulation of data is called for (as compared to non-HD props). So there is already some time advantage, however this is (imho) a minuscule one. Generally zoom6 as any higher zoom may be faster because the game is still 3d at is' basic core. This means that the higher the zoom the less of 3d models it needs to display. To support this logic I can call on the help file that comes with bat that calls for the simplifications of the LODs for smaller zooms - again to reduce strain on 3d engine at smaller zooms.

The only strain HD models/textures may create would be on memory subsystem. At this experiment you have had entire city filled with one and same model, It was cached and from the point of games/computer memory was just an one model. so the difference was a mere 100kb (or so) - beyond inconsequential for memory subsystem not only of today systems but even for a 20 years old one...
But the strain will rise as more unique models are used. Game, no doubt have some algorithms on saving memory space and bandwidth. One such method would be certain subsetting done by the game - have you noticed that in a given city you don't all your buildings to pop up, rather you see same one growing here and there. If you have 20 St Ritzies in your city only one is sitting in the memory. For this reason the HD Textures would mean very little increase in overall memory usage since these are heavily instanced. I also believe that different zooms are loaded as needed. So use of the HD props will put a strain only at the time zoom utilizing them is used.

All this means that impact of the use of "HD" props and textures on the overall game performance would be minuscule, or, in certain situations, possibly even positive.

Specific of HD textures, or any other terrain/network/puzzle piece textures is that they are never displayed as is (unlike BAT FSHs). they are always manipulated to one degree or another. And in case of Network Puzzle pieces most work is required. So if you want to lighten things for your computer (especially in software mode) uninstall the NAM or at least don't use any of the puzzle pieces). Sounds silly , doesn't it? I mean the point of game is for us to enjoy it not to make it as easy for computer as possible...

[SimFox]

Yep!
That's why Maxis textures should be studied carefully to see how such an effect has been created there...

[callagrafx]

Z had made a scientific test, you, on the other hand suggest something that would prove to be totally irrelevant since it introduce such a huge number of uncontrollable variables into equation that distinguishing the exact effect of proposed alteration would be impossible.

How is testing something out of context a scientific test?  No-one knows the impact a lot of HD props will make to people who play the game as it's intended, not just plop the same thing over and over again.  There are more things going on under the hood and a finite amount of VRAM to display them with...now when you add in that at zooms 5 and 6 there is a lot more animation going on (cars, people etc etc etc etc etc etc) then logically there will be an impact.  It's the same principle with the level of detail settings in game...those with lesser processors/cards set to medium or below because their cards can't cope with high detail.  If it has to load in an FSH file that's twice the size of normal into it's cache, that cache will fill up much quicker causing more spools to disk.

[Jonathan]

Ok that test isn't the best to do, oh well lets test it in better way, instead of getting into the details of how that test wasn't good.

So a better test would be to take an existing city with neither the HD or SD GLR shelter, measure what you need to(I'm guessing speed, RAM, CPU and maybe FPS?),
put in the SD shelters, measure,
put in the HD shelter and measure again.?

Jonathan

[mightygoose]

Ok that test isn't the best to do, oh well lets test it in better way, instead of getting into the details of how that test wasn't good.

So a better test would be to take an existing city with neither the HD or SD GLR shelter, measure what you need to(I'm guessing speed, RAM, CPU and maybe FPS?),
put in the SD shelters, measure,
put in the HD shelter and measure again.?

Jonathan

preferably completed repeatedly over a spectrum of computer power....

[mightygoose]

they do look good though, your efforts are most appreciated....

[Xyloxadoria]

preferably completed repeatedly over a spectrum of computer power....

I can do the test, but before we do it, there has to be an agreement on which city we will use to do the testing, or at least something similar to keep this consistent.

What i suggest is to use the "Big City Tutorial" city that comes with the game. It should be be the same for everyone, and if its not, you can reset it in the options.

Another thing that will need to be agreed on is the number of props that we will use, and how the lot they are on will look like (i could make default testing lots if they are needed) which should keep everything about the same, as varying these results could make one type of computer preform differently from another.

Of course these are just my suggestions, and you're free to do whatever you want. If we do want to set a default for the test, then feel free to post what you think they should be.

[mightygoose]

xylo i totally agree with the big city tutorial idea, i think it should be tried with a range of plugins too, so some running maxis only and some running no maxis 5gb+ plugins. a set of test lots would also be a good idea i think.

[Xyloxadoria]

I have made lots for the high and standard definition renders of the station i showed in my test earlier. They are just a building on a blank 3x1 lot, heres what they look like

and heres where you can get them
HD and SD Lots

[TheTeaCat]

hey guys, here is a HD asphalt universal sidewalk replacement mod, very similar to the standard resolution one on the stex that loads of people use.  It may well need to go into a candidacy thread once more testing has been done but i invite you all to have a play with it...

(the texture is one of my creation)

I dl'd your mod MG and have no probs so far, admittedly its only in a small tile without many residents but it looks great 
and has caused no effects that I can see at the mo.

Will keep you informed if anything untoward  happens:thumbsup:
In fact you can see bits of it in my last update in Tales at TeaTime


TTC

[z]

I have some further results that may be of interest.

When I originally said that the HD display was "slightly faster" in hardware mode, I didn't quantify this because the display times were so fast that it was difficult to get a very accurate measurement.  The SD display took about half a second; the HD display was noticeably faster.  A principle of human perception says that the brain can normally perceive time differences down to about 200 msec; this would imply about a 40% increase in speed.  For obvious reasons, I didn't want to make that claim based on that little data.

However, I have found an experiment that is much better at quantifying this time difference.  This involved positioning the display right above the massed stations, and then scrolling through them.  At Zoom 5, this took a consistent seven seconds for both SD and HD models, in both software and hardware modes.  At Zoom 6, this took a consistent seven seconds for SD models in both modes.  It took a consistent five seconds for HD models in hardware mode, and a consistent seven seconds for HD models in software mode.  So the SD models took 40% longer to display in hardware mode at Zoom 6 - completely consistent with my previous results.  In software mode, display times were equal, again completely consistent with previous results.

The tests I did had about 40 stations being displayed at a time at Zoom 6.  In my normal cities, I have about four stations displayed in the same area.  I can't see how any tests that use a normal distribution of stations for that area are going to give measurable results.  If such an area were filled with lots of different props, first SD and then HD, you might see something.  But again, although absolute display times might well increase, I can't see any scenario which would make the shorter method (and significantly shorter at that) turn into the longer method.  As SimFox pointed out, the size of the props isn't big enough to make a difference.

We can also get hints from the way the game is designed.  The display options panel is set up to naturally show more and more detail at the higher zoom levels.  This implies that the total game, and not just the block of stations I have tested, has increasingly better display capabilities as the zoom level is increased.  This is consistent with all my measurements.

The computer I used for these tests is a 5-year-old machine with an Opteron 256 CPU and an ATI 9600 XT graphics card.  For people with more modern hardware, especially more modern graphics, I think that it is very possible that even bigger performance increases would show up when using HD models.

To me, all of these things put together is enough to tell me that HD props are good for your game performance in hardware mode, and neutral in software mode.  For those people who disagree, I would suggest holding off on calling these tests "not good," "useless," etc., unless and  until better tests are run that produce significantly different results.  Personally, I don't think that's going to happen.

[SimFox]

How is testing something out of context a scientific test?  No-one knows the impact a lot of HD props will make to people who play the game as it's intended, not just plop the same thing over and over again.  There are more things going on under the hood and a finite amount of VRAM to display them with...now when you add in that at zooms 5 and 6 there is a lot more animation going on (cars, people etc etc etc etc etc etc) then logically there will be an impact.  It's the same principle with the level of detail settings in game...those with lesser processors/cards set to medium or below because their cards can't cope with high detail.  If it has to load in an FSH file that's twice the size of normal into it's cache, that cache will fill up much quicker causing more spools to disk.

wee... more words than meaning. Let's take a closer look at them.

"How is testing something out of context a scientific test?"
This is exactly the core of scientific method - isolation of cause -effect link, along with modeling (system modeling not BAT modeling, naturally). Naturally this should be done based on some theory, better still hypothesis. BTW all you have written isn't, but more on that later.
"No-one knows the impact a lot of HD props will make to people who play the game as its intended, not just plop the same thing over and over again."
This line cares emotion, but hardly any meaning. What is that suppose to mean, apart from that thinly veiled admition that you yourself don't know what is going one and have not idea or suggestion?  Also HD props will not have any effect on people... Also what is your evidence, or theoretical framework for suggesting that plopping different HD props will have any significantly different impact that plopping different normal props? Mind you I'm not saying that they don't. I just want to know what causal effects you expect so that Z could create an experiment to test for them?
This you concern is particularly surprising given how strong proponent of a Skintight load button in Bat4Max "3" you are...

"There are more things going on under the hood and a finite amount of VRAM to display them with...now when you add in that at zooms 5 and 6 there is a lot more animation going on (cars, people etc etc etc etc etc etc) then logically there will be an impact."
Would you care to name some of those "things going on under the hood" that need VRAM to "display them with"? Also, how exactly do you suggest adding animations would alter the results that Z had demonstrated in his experiment. I mean some explanations, not just "the end is nay" type of things. BTW, simply adding word "logically" doesn't make it logical. If you think it logical - present the logic so other can examine it in order to agree or disagree.

"It's the same principle with the level of detail settings in game...those with lesser processors/cards set to medium or below because their cards can't cope with high detail."
I don't think so. Again, instead of just dropping some statement you should have at least tried to explain it. If you do so you may have come to the conclusion that there are some significant differences. But since you didn't it just a "panic attack" - "Something" "may" happen. Very bad premise for an experiment - looking for something somewhere... Again would be interesting to hear explanation why the experiment by Z had failed in this respect. To hear with explanation not just "False assumptions". Also "detail" is to broad of the term here. What details? How do they affect what part of computer system, at least to hear some speculation/idea...

"If it has to load in an FSH file that's twice the size of normal into it's cache, that cache will fill up much quicker causing more spools to disk"
This is very slippery slope.  But first let me ask do you know how and what is loaded to the cache? Where that cache is located?
But at least this line does have some technicality. However what are the merits of it, apart for being alarmist. At it's very, very reduced core it is true, sort of, if you add and add something to some container it will eventually get full.
Question remains WHAT exactly is added, to WHAT container. You say FSH file... Well, what FSH file?
This is interesting and important point and it has to be discussed. The rest of it... It pseudo scientific yada-yada-yada about context and VRAM and "a lot under the hood" does nothing but saws confusion. And the discussion that followed

Yes, lets' do a test on a range of hardware, with empty and 5+ gb pluging folder, at day and at night, at full moon and at new mood, during monsoon season and Bengal tiger mating season and while tilting head to the left and another while tilting it to the right... what else have I missed?

[BarbyW]

Can we keep this thread to a discussion about the HD props and not start sniping at each other?
I would like to see testing being done in a variety of situations as I do fear the result if lots of these HD props are used. I may be totally wrong and will be happy to say so but although these will be good for some they could be research hoggers and slow the game down to a crawl.
Let's have some more tests. z, whilst I appreciate your comments I still feel that multiple plopping of one single prop  without any thing else is not a truly representative test.
We should have learned by now that extensive testing is vital for anything new no matter how desirable it may be.

[Diggis]

My god this battle between the pair of you is getting old.  Give it a rest already.

While Z's test was useful, I do think that there is a point that it needs to be tested trying to load multiple files, not just one instanced copy, that is most likely to be a larger drain on the processor.

Additionally, it needs to be tested in regular usage.  IE with the computer working on a transit network, animation and additional props and automata running.  Given that only Zooms 5 and 6 are affected this may not have a large effect, but we do need to test this.

Another thing to consider is load times, this appears to make a file 4 times larger.

[Orange_o_]

Anyway to make a representative test, would be needed an important number of different HD props ...
Today there is no or little.

And even if this test showed itself positive, it would not maybe prevent a crash when a more important number of HD prop will be used

Thus the utility of a test is pointless because in quite way we cannot reproduce an ultimate situation.

[z]

Earlier, Callagrafx made the following statement:

If it has to load in an FSH file that's twice the size of normal into it's cache, that cache will fill up much quicker causing more spools to disk.

It is true that the cache will fill up quicker, but what effect does this have on performance?  To answer this question, as well as the questions raised by Barby, Diggis, and Orange_o_, I did more experiments.  I don't have a large number of HD files to work with, but actually I don't need that.  All I need is a lot of buildings with a lot of large FSH files.  For example, an area full of large skyscrapers will have much more storage area devoted to FSH files than any set of HD props possibly could.  Fortunately, I have such an area already built - Downtown Chicago:



As you can tell, there's a wide variety of large buildings, and they all have lots of large FSH files, requiring lots of storage space.  What is the impact on performance?  I repeated the exact same tests I used for HD props, although this time I used only hardware mode.  Surprisingly enough, the results were virtually identical to the results I obtained for SD props.  Going from Zoom 5 to Zoom 6 took the same half second as with the props, while going the other way took a bit longer, as it did with the props as well.  There was no measurable difference.

Scrolling through a full screen of skyscrapers also took about the same time it did for scrolling through a screen full of props, although it might have been a fraction of a second longer than for the props.  There was one significant difference here, though.  Whereas the props scrolled fairly smoothly, the skyscrapers scrolled more in jumps.  It seemed that the game wanted to maintain performance, and did so by reducing the number of times it had to repaint the screen.

But these are huge skyscrapers - not props.  The difference between SD props and HD props pales in comparison.  So if the game can maintain performance when using skyscrapers instead of props (and a wide variety of skyscrapers at that), I don't see why there is anything to worry about in the relatively small difference in size between SD and HD props.

And even if this test showed itself positive, it would not maybe prevent a crash when a more important number of HD prop will be used

On what basis do you think there might be a crash when a higher number of HD props are used?  Do you have any evidence for this statement?

Thus the utility of a test is pointless because in quite way we cannot reproduce an ultimate situation.

This makes no sense to me; using this reasoning, all testing is pointless.  And what is an ultimate situation?  And why do we have to reproduce it if we understand the behavior of these props fully enough, which is what my tests have been designed to help us do?

[Orange_o_]

Z: Zen, my English is approximate and I am afraid that you badly interpreted him.

What I wanted to say it is that for me, it is useless to make supplementary tests, what you made previously is enough for me.
Knowing that if ever, a crash had to occur, it would belong of to an ultimate situation (private individual) whom we could not foresee with difficulty. ... It is the definition of the risk and the risk 0 does not exist