High Definition Props and Textures - Discussion thread

[RippleJet]

I can see a number of prop packs needing some updating...

I have enlarges the first model to 200, reLOD and export.
With the Reader I have save the 4 FSH (30400,30410,30420,30430)
Then I imported this 4 FSH in the "normal export" to replace 4 initial
Only the FSH I don't understand why you import the S3D

David, you were the smart one in here!

Of course, dividing the vertices of the doubled sized model is unnecessary,
as you already have the original, unscaled zoom 5 render...

With the new scripts, the question is academic...
I just needed you to know that I noticed it though.

[jeronij]

Regarding this question:

- I see you have set the transparency too. Was this done in the script as well? Then I should rather consider stop working on my utility (its functions would be resizing of models, and set/remove transparency). In such a case you should make three scripts though, so that all combinations of HD and transparency become available.

and the answer:

Cogeo:
- transparency wasn't set by the script. You'll see how simple the "scripting" was later on. It was done manually in iLive Reader. I don't think that thing like that could be accomplished with Max script since manipulation of data outside of Max is required. So, if you are making some sort of utility that would automate these sort of things that would be great! What are you writing it in?

I just can second SF's words, and express my interest in such a tool as well   

[Diggis]

The Gmax script file certainly does what it says it does.

Attached to this post is a re-rendered prop of a deodara tree which I released in the W2W prop pack. the original is on the left; the HD on the right. The difference is remarkable.

The size of the tree is basically 17mx17mx37m. The old SC4.model file was 79KB - this new one is 206KB; more than double...but I never thought I would ever see such clarity from gmax 

I could get banned for the first word out my mouth when I saw that!

[Orange_o_]

Thank you very much Simfox, you are the best 

mattb325 : you're tree is beautifull 

Ripple : It is sure that the export machine is overheating this weekend

[callagrafx]

I can see a number of prop packs needing some updating...

We need to be extremely cautious with this, as the increased overhead in filesize will be an issue for mega prop packs and distributing them, both in terms of space and bandwidth.

[Diggis]

We need to be extremely cautious with this, as the increased overhead in filesize will be an issue for mega prop packs and distributing them, both in terms of space and bandwidth.

Added to the fact that we have no idea what effect this will have on the game engine.

[Orange_o_]

In french we say : "killjoy"

[callagrafx]

In English we say "Overkill"   

[RippleJet]

I guess updates to old prop packs could be optional add-ons, by distributing only the FSH files for zoom 5...

[Diggis]

In french we say : "killjoy"

Untill you grind the engine to a halt because it can't handle the strain in which case you are killing the joy. 

I think this is an increadible development and love the result, but we do need to be cautious.

[z]

We need to be extremely cautious with this, as the increased overhead in filesize will be an issue for mega prop packs and distributing them, both in terms of space and bandwidth.

One thing we can do is use better compression software, which addresses both issues.  For example, there's the free 7-zip program.  Although it creates regular zip files, it also creates files in its own 7z format, which are supposedly 30% to 70% smaller than standard zip format.  And since it's free, access is not a problem.

Other people may know of even better solutions.  But something along these lines would help a lot.

[BarbyW]

I agree with Diggis and Cal that extreme caution should be exercised in how this is approached. It isn't the compression for distributing that concerns me so much as the effect on the game engine and graphics. I know that when I put a lot of CP trees in God Mode it slows the graphics down enormously. This is a superb discovery but I think we should hold back a bit from deciding that all prop packs need updating. This needs to be tested in game for a time before any final decisions are taken about updating. To my knowledge this has been tested with one or two items in plugins in game. It needs longer testing and with many more HD props first.

[Orange_o_]

Yes it is sure that it must be before tested


I experimented different zoomsize by modifying the script, it's the results for the aspect and for the size of the SC4model :



For the fun (2) I use a complexe LOD to compare with the normal LOD


Orange

[z]

I agree with Diggis and Cal that extreme caution should be exercised in how this is approached. It isn't the compression for distributing that concerns me so much as the effect on the game engine and graphics. I know that when I put a lot of CP trees in God Mode it slows the graphics down enormously. This is a superb discovery but I think we should hold back a bit from deciding that all prop packs need updating. This needs to be tested in game for a time before any final decisions are taken about updating. To my knowledge this has been tested with one or two items in plugins in game. It needs longer testing and with many more HD props first.

I couldn't agree with you more, Barby.  I think some actual performance numbers here would be invaluable in assessing the impact of these changes.  I think one saving grace here is that only zooms 5 and 6 are affected, which means that only a relatively small portion of the city is displayed.  But again, tests are necessary to fully understand the impact.

The other thing to consider is that the impact will also vary depending on what kind of computer and graphics the player is using.  Some may be able to use the new format with ease, others may need to stick with the old format.  Again, hard numbers should be useful guidance in this area.

[RippleJet]

I think one saving grace here is that only zooms 5 and 6 are affected, which means that only a relatively small portion of the city is displayed.

My thought as well.
Initially I think we should restrict ourselves to HD'fying only smaller props though... and, indeed David, only such that have a simple LOD box, and test the performance in the game after that.

[jeronij]

I would not recommend to substitute the existing prop/textures packs. I'd suggest new HD packs, only with the needed textures as Tage said  , which would override the existing ones, if the player wish to do so, and his/her system specs can support it   

[SimFox]

Couple of thought aloud...

1 replacing...
well even if it is done (and I bet it will take some time) I what to enquire how "over-writes" work...Original is loaded into memory, when program while loading comes to the over-ride what does it do? discard the already loaded file/files and replace it with a over-ride, or does it keep both?
This situation may be made worse/more complicated when we are talking of BAT packs and over-rides that cover only part of such a dat. How is data structured in memory? as individual exemplar, FSH, S3d files or as a DAT block. Cause if it is a second case creating over-rides will effectively put greater strain on memory system More data would have to be kept loaded and performance of graphics every time game would need check for over-rides and select ten for display hence putting extra burden on game (may be not graphic engine, but memory management and database), anyway increasing overall

2. strain
I might be wrong but I think that the size of the textures as such doesn't create any additional burden for graphic engine. That is when they are shown as is. Screen has fixed (for a given system) number of pixels that are managed by graphics engine. Increasing/ decreasing the resolutions of Textures doesn't affect this number and as such doesn't affect engine. But manipulating those textures will certainly create extra work for it. Manipulating like scaling up (for Zoom6 in the original) or scaling down (for zoom5 in HD version). This is second reason (apart from fidelity) I would prefer to stay with 1:1 ration, rather than do any scaling

2. Bandwidth and compression.
Some material in files may be compressible and some may not be such. You can only 8as a rule) compress uncompressed data eg BMP could be compressed, PNG couldn't
More then that, at least sometimes compressing compressed data will result in much smaller compression ration and larger archives as compared to compressing uncompressed data.
I made a little experiment using identical image files one saved as 24 bit BMP and another as interlaced PNG (bigger than normal PNG). And compressed those with best (strongest) compression in WinRAR, WinZip and 7Zip
here are results

Compressor	BMP	PNG
none	288 056 bytes	137 022 bytes
WinRAR	88 343 bytes	137 094 bytes
ZIP	131 115 bytes	137 095 bytes
7Zip	111 555 bytes	137 779 bytes

            
As you can see PNG doesn't compress at all, and 7Zip has biggest overhead!

As far as Bandwidth is concerned, one solution may be to keep files off site. In place like www.rapidshare.com not only it doesn't charge for bandwidth, but it also gives bonuses for greater bandwidth use.
BTW this new export affects ONLY zoom5 Zoom6 is a virtual construct, which brings me to the next topic/news and this isn't a good one.
I've tested this morning the idea we have been mentioning with Tage – creation of independent Zoom6 by adding appropriately named/coded S3d and FSH files to the SC4Modle with normal 5 zooms in it.

Unfortunately this test had failed – zoom 6 was not picked by game. Instead of it displayed scaled up Zoom5.

I wouldn't dismiss this idea altogether, at least not till somebody (preferably at least a couple of people will replicate said result.
SC4Modle File I used/created for this test could be had here.

[jeronij]

SF, I am using MAX7 and I am getting an error when I try to run the modified script. Is there an easy way to fix that?. I cant afford a new MAX version atm 

[callagrafx]

As far as Bandwidth is concerned, one solution may be to keep files off site. In place like www.rapidshare.com not only it doesn't charge for bandwidth, but it also gives bonuses for greater bandwidth use.

No way Bubba...Rapidshare makes you wait at least 30 secs for a download and that's if there is little or no burden on it's servers, because it's a marketing ploy to make you pay for their service.  The LEX is fine as a distribution medium, as it's under our control and downloads are tracked.  At the moment, most megapacks come in at around 6-8MB...imagine if they were converted to HD, the file size would be approaching 20MB and would simply bloat out your hard drive.  To be honest, I really can't see the point if we've survived this long with the status quo....Fine create new props and small buildings, but don't go mad.  This site and LEX sit on a dedicated server that costs a lot of money per month to maintain, the last thing needed is a strain on resources.

[SimFox]

SF, I am using MAX7 and I am getting an error when I try to run the modified script. Is there an easy way to fix that?. I cant afford a new MAX version atm 

My oh My! how did that get there?!

Somehow part of HTML code got itself into the MS file. Most probably this was caused by the way you have downloaded/saved the file. I bet you didn't really downloaded it but rather displayed it in the browser window and then some how saved from there... It may be so that you some how associated .ms file type with browser... Normally solution would be right click and choose save link as... but in case of Rapidshare it doesn't work cause it isn't really a link there but a button (with probably some code) behind it.

I'm attaching it to this message in ZIP archive