High Definition Props and Textures - Discussion thread

[debutterfly]

I'm new at doing this so thanks for the advice.  I literally just started doing this on Thursday. 

Does this look a little more realistic? 









-Larry (debutterfly)

Edit: I made the tire markings and the inconsistencies tileable.

[SimFox]

Done! Scripts in ZOPs are attached to teh original message with download links.

A word of Caution, though!

If you use MAX you would need to update both GMAX and MAX scripts. This is absolutely essential! You need GMAX to create proper SC4Modle file with right Slads. Max doesn't cut slabs itself, only FSHs to match slabs cut by GMAX.

[SimFox]

It certainly does!
One thing that you'll have to remember is that it have to be tilable!

[Haljackey]

Sweet.

I'm loving this development.  Keep at it!   

[Jonathan]

Aye, that is much better
Keep up the good work!

Jonathan

[SimFox]

one thing, Debutterfly, don't post links! just files and at full resolution!

[cogeo]

Don't want to ruin the party here, but I do have some doubts:
- Has anybody really tested if making textures 256x256 indeed improves the quality? What we were presented in this thread was a special GLR texture (a very good one, I have to admit) next to the standard el-rail texture. The former of course is much more attractive, but it's too different. The same with the road textures above.
- The game's resolution is ca 11 px/m, which is quite close to 8 px/m, ie the resolution of standard textures (128px/16 m). I seriously doubt if the textures' resolution is indeed a limiting factor. For 256x256 the resolution becomes 16px/m, which still has to be scaled to fit in the game. Sincerely, I never found the textures' resolution to cause any problem (not the case with BATs). I can post some close pics to show you what I mean, but I don't think this is necessary.

[SimFox]

I'm with Cogeo on this one...
I think the quality is a bigger issue than resolution...

[buddybud]

well this text shows that it does show the extra detail. above is 256 with a single pixel red line below is a 128 with a single pixel red line. The 128 appears twice as wide in game.....

The picture below is a zoomed in picture of the one above. It happens to be twice as big.





Bud

[cogeo]

Very expected, as in both resolutions the fuchsia stripe is 1 pixel wide. There is a simple texturing technique to tone it down in lo-res, just put the stripe on a separate layer (above the background) and play with the opacity, this gives a similar effect.

There are very minor differences otherwise, and the 128x128 texture is very acceptable to my opinion, esp if compared to models, which in comparison look both pixelated and blurred (?!) in close views (I'm not talking about yours, I mean models in general). The 128x128 texture is really very good, and differences with the 256x256 one are only noticable if both are shown next to each other. That is the higher (double) resolution didn't improve the end result as much, as then there is the game's resolution that becomes the limiting factor.

EDIT: sorry, but the "x2 Zoom" doesn't really apply ingame.

[SimFox]

yes it does... but this is a zoom6 ONLY thing.
at zoom6  game tile has side of about 212 pixels. meaning that normal 128 pix texture would need to be stretched (doesn't have enough pixels so upward interpolation occurs) With 256 pix downsizing occurs - texture has excess of pixels.

At zoom 5, however normal 128 pix texture is sufficient since game tile is half the size of  zoom 6.
Of course the textures aren't applied to the top-down view, so some distortions always occur, so some excess data may be instrumental.

[buddybud]

well all i know is that at the closest zoom a single pixel at 256 appears clearly. There is little to no distortion as my pictures show. I don't see the issue. I'm concerned with detail and that is what i mod for. For me this is quite useful.

Bud


um sorry my logic dictated that an image zoomed in twice as much as the original is zoomed twice as much  surely you understand what i meant???..the picture is zoomed in double from the above one.

[z]

@SimFox: You should test the compression levels with a FSH file (or a bunch of them), not with BMP and PNG. BMP isn't even used in the game, and PNGs mainly for icons and UI graphics, which do not contribute to the HD prop idea. I noticed that the Nullsoft Installer (used for the NAM etc.) is able to compress FSH textures a whole lot better than a standard ZIP file (that's why the Mac versions are always much larger). I'm using the LZMA compression algorithm, which seems to be the best one so far. I'm not sure what RAR and 7ZIP are using, but even RAR is not as effective as the LZMA algorithm.

Yes, that was my feeling when I made the post.  If you really wanted to, you could compress PNG files with the program crushpng.  But for overall compression, the PAQ8P program is the best I've found.  I tried it on a real-life example:  BSC Mega Props - JES Vol03.dat.  It produced a file 25% smaller than the compressed one distributed in the zip file, and 50% smaller than the original.

[SimFox]

You picture isn't zoomed in 2x . It is magnified 2x or stretched 2x...
Zooming is reducing view angle it maintains th resolution. You, on the other hand made picture bigger but halved it resolution. In a way it is pointless as you don't actually see more...

[buddybud]

the freaking point is that a single pixel appears in a 256 texture.....get it....do ya get. it.....please get it please


my apologies i need some time off

Slightly burnt Bud 

[jeronij]

I'll do that - put Zips on Rapidshare.

May i ask how you do your export form the look of your FSHs  something is very wrong with it.
BTW Slab - is a piece of S3d file, FSH is, well FSH... a texture that is applied to Slab.

Also Do get it correct you've ONLY replaced script file in MAX? Right?

Thanks for replying. I discovered the hard way that both scripts must be installed if you are using MAX  

I have been able to create some HD props after that, but nothing really worth showing it yet

The fsh's are rudely cutted from a print screen so dont alarm about that. Now I have everything running perfectly.

Btw, why dont upload the scipts to the LEX, or elsewhere, so they are easily accessible for many more users?. Of course once the scripts have been tested a little bit more... but from my own I have no problems to report so far 

[SimFox]

Well, I think that uploading them to some place like LEX is a bit premature. Not that I believe that there are some bugs as far as functionality is concerned. But the whole thing is rather user unfriendly as of yet. I mean the need to go and change scripts manually etc.
I have an idea how to integrate it all into the existing interface (both GMAX and MAX) so that it will be something like check box (x)SD or (x)HD. Still even then it for people using Max there will be need to remember that both should be set the same.
I'll try to get it made sometimes after the Easter if I'll get some work projects ready before then.

[Gwail]

One thing that you'll have to remember is that it have to be tilable!

That's why all the "imperfections and nuances" should be gentle. Otherwise they will look as odd repeatable pattern, unless you don't use multitextured FSHs.

[Orange_o_]

jeronij :
The main problem is that this script works for all the exports, now I disadvise it for big Bat, only the prop.
One would need that effectively an interface which allows to choose the script SD or HD, I think that it maybe possible but I do not master these modifications

[z]

On the previous page, Barby expressed concern about the effect on performance HD props would have, and I agreed with her.  So I did some basic testing.  First, here's a picture of my test setup:



It may be a bit hard to recognize, but this is SimFox's new GLR shelter, displayed here a little while ago.  I put it on a T-RAM platform, and then filled a 1920x1200 screen at Zoom 5 with these.  I compared a standard definition model against a high definition model, and I tried each in both software and hardware mode.  I cycled through the various zoom levels, went from Zooms 5 and 6 to subway level (i.e., an empty screen) and back, and did the same thing with the zones view.  The results were consistent across all tests.

In software mode, there was no detectable difference between display times for standard definition models and high definition models.

In hardware mode, Zoom 6 actually displayed slightly faster with the high definition model than with the standard definition model.  Display times for all other zooms were equivalent for the two models.

What was especially interesting was that Zoom 6 was always the fastest level to display in any of my tests.  If I started at Zoom 6 and kept zooming out to Zoom 1, each level took a little longer to display than the previous one.  As expected, when I zoomed back in, the reverse was true.

My explanation for these results is the obvious one:  You've got a fixed number of elements to display at any given zoom level, and that number is no different regardless if you're starting from a standard definition file or a high definition file.  Why that number increases as you zoom out is hard for me to say, but I've noticed that effect for a long time.

As for why the high definition display at Zoom 6 was displayed slightly faster in hardware mode than the standard definition display, I would assume it's due to the fact that the high definition model provides all the data points that are needed for the display, while with the standard definition model, additional data points need to be generated, which takes additional time.

So my conclusion is this:  In software mode, high definition models have no effect on display times, while in hardware mode, they actual shorten them slightly.  In other words, in hardware mode, high definition models improve the game's performance slightly in Zoom 6, and have no effect at other zooms.

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