3D models and texture file format thoughts

[DeathByBlast]

Just sitting here thinking while I am doing yet another recompile to test some textures, it would be nice if models could be used rather than the simple objects that we have now in maps as it's fairly difficult to create textures to look reasonable for manmade looking simple objects.

On another note, I'll be looking into this, being able to use jpegs for textures along with png when transparency is not required, that could in the longrun save alot of memory, though I suspect one reason it's not being used is due to patents, etc. But isn't png patented by someone, somewhere?

?????

[DTRemenak]

PNG is completely royalty and patent free. That's the point. It's also lossless and has a full alpha channel.
JPEG is acceptable from the freedom standpoint (IIRC) but it's lossy, which is the main reason we don't use it. It would also mean we'd need to write another loader.
It would not save any memory, the textures are decompressed while they're being loaded.
You do not have to recompile to test textures, just replace them in the data directory.
Models can be used in maps, see the "mesh" object in bzw.5. Or any number of threads in this forum. You can convert wings3d objects, or .obj objects, or .3ds objects, to bzw format and copy them into a map with existing tools.

[DeathByBlast]

PNG is completely royalty and patent free. That's the point. It's also lossless and has a full alpha channel.
JPEG is acceptable from the freedom standpoint (IIRC) but it's lossy, which is the main reason we don't use it. It would also mean we'd need to write another loader.
It would not save any memory, the textures are decompressed while they're being loaded.
You do not have to recompile to test textures, just replace them in the data directory.
Models can be used in maps, see the "mesh" object in bzw.5. Or any number of threads in this forum. You can convert wings3d objects, or .obj objects, or .3ds objects, to bzw format and copy them into a map with existing tools.

Yeah I got that on the modeling part now, was reading that shortly after my post, thanks.

As for jpeg vs. png, my thoughts where that jpeg generally gives a little more control over png in regard to size vs quality thus if alpha is not required for a texture the image can be made vastly smaller in most causes without any real noticable loss in image quality, thus saving some space in video memory, though at this point in life I don't really see where it's going to really matter enough, maybe if you wanted to use an insanely large number of textures.

[TD-Linux]

thus saving some space in video memory

Textures aren't stored in memory in their native format. They are almost always decompressed and converted to a proprietary bitmap format. Video memory would stay the same either way.

[kinkyfriend85]

Png is the "best" format to go tbh, it support transparency as well as it's compressed in filesize and it doesnt originally use image compression so the quality is top notch. While a 512*512 texture in jpg may take 150 kb, png can be at 8 kb... It depends on how many colors you use, and most textures doesnt need more than 256 colors.

[DeathByBlast]

thus saving some space in video memory

Textures aren't stored in memory in their native format. They are almost always decompressed and converted to a proprietary bitmap format. Video memory would stay the same either way.

Well, not meaning to be argumentative, but that really doesn't make alot of since considering this line:

"Next-generation consoles may require reducing texture resolution by 2X, and low-end PC's up to 4X, depending on texture count and scene complexity."

http://www.unrealtechnology.com/html/te ... ue30.shtml

Now from the conversation we have had so far it would look like those folks over at Epic have alot to learn since from what I understood, you are saying they will be the same size in memory regardless.

[DeathByBlast]

Png is the "best" format to go tbh, it support transparency as well as it's compressed in filesize and it doesnt originally use image compression so the quality is top notch. While a 512*512 texture in jpg may take 150 kb, png can be at 8 kb... It depends on how many colors you use, and most textures doesnt need more than 256 colors.

Well, png is nice, depending on what you need it for ofcourse, it's a bit of a pain on the web due to IE not dealing with transparency, other than that the only real issue is size, I can almost always make a jpeg smaller than a png, though jpeg does not support transparency, as for indexing, be warned that for some reason certain textures in the game can no be indexed, if you index them you will notice lines on the vertical edges when they are drawn in the game.

Anyway though it was just a wild thought, at least we can all agree on one thing?:

"Thank God we don't have to use gif!"

LOL!

I will be glad when we can get rid of it on the web and replace it with png.

[DTRemenak]

DeathByBlast:
If you can get me an example non-interlaced png that does not work right in game, I will fix BZFlag.

BTW, the line in the Unreal article is referring to the capabilities of the machines...so they're designing large textures that mid-range PCs at the end of next year can handle. If that means 128mb decompressed per scene, then a PC with only 32mb of video ram will need a 4x reduction. Nothing to do with compression there, just matching capabilities.

And I CAN say authoritatively that BZFlag loads the PNG into an OpenGL bitmap texture space, which is non-compressed unless your device drivers do on-the-fly compression to reduce bus load. No matter what, the PNG is not stored in memory once it is loaded...only the bitmap is.

You can't DO anything with a PNG or JPEG in memory other than decompress it; there's no useful information in compressed form. You can't scale it or map it or anything unless you first rip off the compression. Textures are ONLY compressed with formats like PNG or JPEG to save disk space and download time.

[DeathByBlast]

DeathByBlast:
If you can get me an example non-interlaced png that does not work right in game, I will fix BZFlag.

Any of the textures that have to be redrawn horizontally have vertical lines on the horizontal edges when indexed, does not appear to matter the degree of indexing, for example one that's easy to see is boxwall.png, once indexed you can see these lines on the edges when you get up close enough, this is also the case with std_ground.png, pywall.png, etc. I will attach an example.

BTW, the line in the Unreal article is referring to the capabilities of the machines...so they're designing large textures that mid-range PCs at the end of next year can handle. If that means 128mb decompressed per scene, then a PC with only 32mb of video ram will need a 4x reduction. Nothing to do with compression there, just matching capabilities.

And I CAN say authoritatively that BZFlag loads the PNG into an OpenGL bitmap texture space, which is non-compressed unless your device drivers do on-the-fly compression to reduce bus load. No matter what, the PNG is not stored in memory once it is loaded...only the bitmap is.

You can't DO anything with a PNG or JPEG in memory other than decompress it; there's no useful information in compressed form. You can't scale it or map it or anything unless you first rip off the compression. Textures are ONLY compressed with formats like PNG or JPEG to save disk space and download time.

OK, maybe I'm still missing something, but wouldn't a 6kb png have some performance benefits over a 100kb png?

Even after conversion wouldn't it still be smaller or is it padded somehow to where they all become the same size?

Wouldn't it take less time to get to the state required for gameplay from png?

[JeffM]

OK, maybe I'm still missing something, but wouldn't a 6kb png have some performance benefits over a 100kb png?

Even after conversion wouldn't it still be smaller or is it padded somehow to where they all become the same size?

Wouldn't it take less time to get to the state required for gameplay from png?

Not if both images expanded out the same pixel size.

if the final image size is 512x512x32bit, then it's total size in video ram will be.
10,48,576 bytes. This is the raw image size before compression. This is how big the bitmap of the image is in open GL when it can be used. Each card does it's own packing on bound textures to optimise them for the card, but we have no controll over that.

So no, in that case there is no runtime performance difrence between images with difrent compressions. Load times will be slightly ( like nano seconds, faster ), and download times would be faster, but these are rare one time events ( once per session ), so they are not good candidates for optimisation.

What would help on video cards is to use images with smaller pxiel sizes on cards with limited ram. In that case, an image that takes up 128x128x32bit would only take up 731,136bytes. A signifigant savings. Image quality would suffer on some images, because there is less data for the texture to pull from, and would therefor interpolate more ( this would make images blury as you got close to them ).

Some images can be ok as lower res images. Mostly images where there are large areas of repated color ( like a stylised brick image ). Photo images, or images with large per pixel varation, benifit from higher res textures.

Considerting that most cards made in the past 2 years have at least 32 megs of ram on them, and any card made now usualy has at least 128 megs of ram, on card texture size isn't that big of an issue. At least not for the few textures that BZ uses. UT, quake and other engines deal with gigs and gigs of images per scene. They do not load all these into the card, since you often can not see every texture at the same time in the same frame. They use complex texture caching systems to load only the textures they need for the current frame.

While we may eventualy to that level of textures, The current BZ "engine" would not handle it well for many other reasons then texture format, and we would want to switch to a more modern, hardware centric engine, like Ogre.

To illustrate I have posted 4 images.

Big.png and small.png are the exact same pixel size. 512x512X24bit

as compressed png files, the 'big' image is over 36 times larger. But they are both the same image size. This shows the difrence in compresson that PNG can do between the images.

Now, Big.bmp, and Small.bmp are uncompressed windows BMP files. They are very very similar to how open GL stores it's data on the video card. In raw expaned data format. You will notice that both these files are the exact same size, because they are not compressed.

Compresion only helps with on disk or download sizes. It does not extend into the Open GL realm..

now if we used directX, or some openGL extenstions......... that may be another story

[DTRemenak]

DeathByBlast:
If you can get me an example non-interlaced png that does not work right in game, I will fix BZFlag.

Any of the textures that have to be redrawn horizontally have vertical lines on the horizontal edges when indexed, does not appear to matter the degree of indexing, for example one that's easy to see is boxwall.png, once indexed you can see these lines on the edges when you get up close enough, this is also the case with std_ground.png, pywall.png, etc. I will attach an example.

Specifically a one-pixel black line on the left edge...thanks to a nifty little off-by-one bug in 24-bpp palletized loading code...

It's fixed in CVS. If you notice anything else odd about any texture loading stuff, let me know. Until recently only 24-bpp RGB pngs worked with any reliability...all non-interlaced formats should work now.

On a side note: your textures will look better if you don't force BZFlag to scale them. Everything's gotta be in powers of two when it hits OpenGLTexture, so if you feed them in as powers of two it saves memory and loading time, and you end up with less ugly scaling blur.

[DeathByBlast]

DeathByBlast:
If you can get me an example non-interlaced png that does not work right in game, I will fix BZFlag.

Any of the textures that have to be redrawn horizontally have vertical lines on the horizontal edges when indexed, does not appear to matter the degree of indexing, for example one that's easy to see is boxwall.png, once indexed you can see these lines on the edges when you get up close enough, this is also the case with std_ground.png, pywall.png, etc. I will attach an example.

Specifically a one-pixel black line on the left edge...thanks to a nifty little off-by-one bug in 24-bpp palletized loading code...

It's fixed in CVS. If you notice anything else odd about any texture loading stuff, let me know. Until recently only 24-bpp RGB pngs worked with any reliability...all non-interlaced formats should work now.

On a side note: your textures will look better if you don't force BZFlag to scale them. Everything's gotta be in powers of two when it hits OpenGLTexture, so if you feed them in as powers of two it saves memory and loading time, and you end up with less ugly scaling blur.

Great and thanks, can you explain what you mean by "powers of two" exactly please. I think I understand and have been doing it that way, but I want to be sure.

[DeathByBlast]

OK, maybe I'm still missing something, but wouldn't a 6kb png have some performance benefits over a 100kb png?

Even after conversion wouldn't it still be smaller or is it padded somehow to where they all become the same size?

Wouldn't it take less time to get to the state required for gameplay from png?

Not if both images expanded out the same pixel size.

if the final image size is 512x512x32bit, then it's total size in video ram will be.
10,48,576 bytes. This is the raw image size before compression. This is how big the bitmap of the image is in open GL when it can be used. Each card does it's own packing on bound textures to optimise them for the card, but we have no controll over that.

So no, in that case there is no runtime performance difrence between images with difrent compressions. Load times will be slightly ( like nano seconds, faster ), and download times would be faster, but these are rare one time events ( once per session ), so they are not good candidates for optimisation.

What would help on video cards is to use images with smaller pxiel sizes on cards with limited ram. In that case, an image that takes up 128x128x32bit would only take up 731,136bytes. A signifigant savings. Image quality would suffer on some images, because there is less data for the texture to pull from, and would therefor interpolate more ( this would make images blury as you got close to them ).

Some images can be ok as lower res images. Mostly images where there are large areas of repated color ( like a stylised brick image ). Photo images, or images with large per pixel varation, benifit from higher res textures.

Considerting that most cards made in the past 2 years have at least 32 megs of ram on them, and any card made now usualy has at least 128 megs of ram, on card texture size isn't that big of an issue. At least not for the few textures that BZ uses. UT, quake and other engines deal with gigs and gigs of images per scene. They do not load all these into the card, since you often can not see every texture at the same time in the same frame. They use complex texture caching systems to load only the textures they need for the current frame.

While we may eventualy to that level of textures, The current BZ "engine" would not handle it well for many other reasons then texture format, and we would want to switch to a more modern, hardware centric engine, like Ogre.

To illustrate I have posted 4 images.

Big.png and small.png are the exact same pixel size. 512x512X24bit

as compressed png files, the 'big' image is over 36 times larger. But they are both the same image size. This shows the difrence in compresson that PNG can do between the images.

Now, Big.bmp, and Small.bmp are uncompressed windows BMP files. They are very very similar to how open GL stores it's data on the video card. In raw expaned data format. You will notice that both these files are the exact same size, because they are not compressed.

Compresion only helps with on disk or download sizes. It does not extend into the Open GL realm..

now if we used directX, or some openGL extenstions......... that may be another story

OK, so if I understand now, your saying that a smaller file because it is 64x64 Vs. 512x512 may be of some benefit while a smaller file due to the amount of compression used would not be other than download times and possibly slightly shorter load times? All of which seem valid for default textures assuming image quality doesn't suffer too much I.M.H.O. What about indexed Vs. rgb?

[JeffM]

power of 2 means that it is one of these sizes in each axis

2,4,16,32,64,128,512,1024

these are the sizes that openGL will pad to.
textures of other sizes will take more memory and run slower.

Basicly power of 2 is where the number can be expressed as 2 to some exponent power (whole number exponents only ).

Download times are not a huge concern at this time. Yes smaller pixel size textures will run better on software and video ram limited systems. They will make nearly no speed impact on modern hardware ( cases where you do not run out of texture memory ). The present ideal is to have the textures optimised for people who have a decent video card ( last couple years ), and let the few remaining people who have older or no 3d video cards, use lower res textures from the older versions of the game. We have thought about making a low res art pack, but there are so few people who would use it, it makes it allmost not worth it.

All textures are stored in RBG format in open GL, so indexing them won't have any in game performance increase. All it would do is make the file smaller to download, and reduce image quality.

When you remove data from the image, ether by indexing or by lowering the final pixel resoujtion you do degrade image quality. Some images ( simple ones ) can hold this quality loss well, and not have any perceptual visual changes. Most textures can not.

It is the job of the texture designer to know what format is best for his texture.. Optimising download is a good thing, but not at the cost of in game performance. Donwloads only happen once, not every frame, so if somone has to wait an extra 2 seconds to get a texture the first time they get a map, it's not as bad as a texture that causes them to loose 2 frames per second when they play, every time they play.

The thing I think you need to get is this.. Compresion only affects Download speed and file size on disk. It does not affect the game as it runs in any way.

[DeathByBlast]

power of 2 means that it is one of these sizes in each axis

2,4,16,32,64,128,512,1024

these are the sizes that openGL will pad to.
textures of other sizes will take more memory and run slower.

Basicly power of 2 is where the number can be expressed as 2 to some exponent power (whole number exponents only ).

Download times are not a huge concern at this time. Yes smaller pixel size textures will run better on software and video ram limited systems. They will make nearly no speed impact on modern hardware ( cases where you do not run out of texture memory ). The present ideal is to have the textures optimised for people who have a decent video card ( last couple years ), and let the few remaining people who have older or no 3d video cards, use lower res textures from the older versions of the game. We have thought about making a low res art pack, but there are so few people who would use it, it makes it allmost not worth it.

All textures are stored in RBG format in open GL, so indexing them won't have any in game performance increase. All it would do is make the file smaller to download, and reduce image quality.

When you remove data from the image, ether by indexing or by lowering the final pixel resoujtion you do degrade image quality. Some images ( simple ones ) can hold this quality loss well, and not have any perceptual visual changes. Most textures can not.

It is the job of the texture designer to know what format is best for his texture.. Optimising download is a good thing, but not at the cost of in game performance. Donwloads only happen once, not every frame, so if somone has to wait an extra 2 seconds to get a texture the first time they get a map, it's not as bad as a texture that causes them to loose 2 frames per second when they play, every time they play.

The thing I think you need to get is this.. Compresion only affects Download speed and file size on disk. It does not affect the game as it runs in any way.

Yeah, I got that, though I didn't really think it would, I have been able to do some pixel reduction also, though not all textures look decent at smaller resolutions and some are just a pain to get there if you are going to have them look right in the end. So, I look at the whole picture in that aspect as well as visual perception.

For example, there isn't alot wrong with the boxwall.png that comes with the game now, however, I have noticed that when you get a certain distance from it, you will start to see a pattern in the bricks, which is the case with alot of textures where repetition is invloved, so I went with a more commen red brick look, although the pixel resolution is smaller the pattern stays more intact at a distance.

Though obviously without taking any of that into consideration it would be alot easier to improve the visual perception.

In any case, when I see an option to reduce download time and disk space by reducing compressed size and the ability to slightly improve performance for some, while still having a good/arguably better visual presentation than I had before, I can't see any reason not to without having the Epic mindset of screw 'um if they don't want to drop $100-$400 on a new video card to play this game we sell for $50.

Which brings us to the whole sound question, what about sound files, is there any performance benefit to smaller file size?

[JeffM]

Thats the thing, changing to jpeg won't make your visual quality better, it'll make it worse. Jpeg is a LOSSY compression system. It removes data. I'ts not worth it. PNG is just fine our our needs.

sound files have to be in one specific format, WAV 22 khz 16 bit, sterio, in PCM format.

bzflag does not support compressed sound files AT ALL.

so there is no way to reduce sound file size other then making them shorter.

and shorter ones don't play any better or worse then longer ones.
all it affects is how much ram it takes up. Using more or less ram does not make anything go slower or faster ( unless you are out of ram and hitting virtual memory, but then you have larger problems then sound ).

sounds are not downloaed ether ( yet ).

so there is no real way to optimise them.

What problem are you trying to solve by these optimisations? What do you perceve is going on that needs help?

[purple_cow]

A couple notes:

1. The sound stuff could really use an overhaul. In the process, one could probably add support for ogg vorbis at this point without reducing platform compatibility. This would be a nice way to get smaller sound files, and make it not-completely-insane to think about having them downloadable.

2. You'll only get so far by creating new textures. Software rendering and the like will always need to use low-resolution textures, so you can't really do much there. For people with real 3d hardware, if you want to really make things look better, you'll have to go about adding multitexturing. This isn't trivial but it's not impossible. Plain, single textures run into the problem that they will either look like crap close-up or be really repetitive when tiled on a large surface (depending on how they're mapped). Multitexturing lets you create surfaces with both high- and low-frequency image data, so it won't look too boring, repetitive or pixelated.

[DeathByBlast]

Thats the thing, changing to jpeg won't make your visual quality better, it'll make it worse. Jpeg is a LOSSY compression system. It removes data. I'ts not worth it. PNG is just fine our our needs.

sound files have to be in one specific format, WAV 22 khz 16 bit, sterio, in PCM format.

bzflag does not support compressed sound files AT ALL.

so there is no way to reduce sound file size other then making them shorter.

and shorter ones don't play any better or worse then longer ones.
all it affects is how much ram it takes up. Using more or less ram does not make anything go slower or faster ( unless you are out of ram and hitting virtual memory, but then you have larger problems then sound ).

sounds are not downloaed ether ( yet ).

so there is no real way to optimise them.

What problem are you trying to solve by these optimisations? What do you perceve is going on that needs help?

Well, in regard to your question, you might look here:

http://my.bzflag.org/bb/viewtopic.php?t=4174

Much of that is answered there, but I will give some detail here also.

1. Some textures just didn't look right to me:

A few examples:

boxwall.png looked good upclose, but as you back away the tiling causes another pattern to start showing in the brick.

wall.png just looked to much like plastic to me.

pywall.png just looked too close water.png and seemed like a strange color for a pyrimid, again, too much like something plastic.

Opinions may vary.

2. To be specific to your question, while creating textures for those and others I really couldn't find a valid reason to make them any bigger than required.

In gaming we often see people that feel everyone should have the latest and greatest hardware to run their game.

Looking at the facts and applying a little common sense (which I hear is not so common and everyday I spend on the net I find more proof of that.), it seems more unreasonable to me for someone to expect that than for someone with older hardware to expect to play some of these games for several reasons:


Price:

This game: FREE
A video upgrade: $64.00 and up.

That's after careful shopping and is on a refurbed card, which B.T.W. is still far from being top of the line.

Many video games run around $50.00 when they first hit the selves, many video cards run hundreds when they first hit the selves.

Operating system:

It seems to be a secret to far too many, but most people running Linux are not doing it because they have the best PC on their block. I know for me one of the biggest things that Microsoft ticked me off about was their constant effort to force users to upgrade their hardware requirements, which they could hardly see a valid reason for.

Reasoning:

When you can get the same look on a surface using a smaller pixel resolution and increase performance on older and smaller cards, why wouldn't you.

When you can compress the textures more and shorten the download time, again, why wouldn't you.

The only answer I can conceive is the classic rich kid line of thinking:

If it costs more, it must be better and if mine costs more than yours I must be better than you because I could afford it and you couldn't, hence because I am better than you I don't care about you, only about myself and those in my same income bracket.

What those people tend to miss is that some people have other things to spend money on and though they may be able to afford that video card upgrade for their computer, why should they have to? So they can play your game? If there are no players, there is hardly any game. Makes more sense to me to be reasonable when possible instead of the other way around. The more players, the more fun.

If you have to have an 8MB video card to understand that then I would say you fit right into that line of thinking and are a lost cause.

I think if you look at some of the newer game benchmarks and the price of those cards just to get decent frame rates, you will see what I am getting at.

Though we are not near there yet, at some point those things should be thought about and there is no better time to think about them than when you are working on something that could make the difference for someone out there.

I get about 192FPS myself, so this is purely being thoughtful, which apparently is a lost art.

[JeffM]

yeah the texture bug is fixed.

and I agree if you can get simialar visual quality out of a smaller texture then using a smaller pixel size is the way to go, totaly. but I was commoneting on your origonal post of how it had to do with compression, witch it doesn't.

yeah for those with older systems, lower res textures are great.

I'd personaly like to see the higher pixel size images just have more art. And also multi textureing so they don't look so flat and bland.

but I guess that's what screamers is for

[DeathByBlast]

yeah the texture bug is fixed.

and I agree if you can get simialar visual quality out of a smaller texture then using a smaller pixel size is the way to go, totaly. but I was commoneting on your origonal post of how it had to do with compression, witch it doesn't.

Right, but it's also easy to forget that only a small minority of people have broadband in the U.S.

I'd personaly like to see the higher pixel size images just have more art. And also multi textureing so they don't look so flat and bland.

but I guess that's what screamers is for

I really haven't seen anything myself to lead me to higher res in this game, in the Windows world yes, but Linux tends to be kind of dull anyway, so it seems pointless in my case. As an example the UT textures keep getting bigger and bigger though under Linux it looks like I'm playing with 256colors regardless of my settings. I don't know why because many other games don't do that.

Going in that direction also reduces the number of players when you get to a certain point, which I think anyone could agree is a bad thing and there are soooo many games out there. I think the more players you have for a game the more it becomes to play it.

Again though it's not real critical in my case YET, but if the thought is thrown aside it easily could become an issue.

Though it would be great if the user could choose, but that would take some thought, otherwise you increase download size and that extra 10-20MB takes awhile on a dial-up. In short the game is fun, people have fun wiping the floor with me and since it's GPL I wanted to help some, but unlike some I have met I don't want to push anyone aside with anything I come up with.

Was looking at that OGRE engine and the tank wars screenshots and ideals started dancing in my head.

Has any thought been given to something like that?

I don't really see the need myseff unless the game was being taken into more realizum and away from the futuristic state of today.

But, what the hell do I know?

More now than I did for sure thanks to the many knowledgable people in this community and that's a good thing.

As you can probably tell, I am somewhat addicted to online gaming, it started when a friend of mine indroduced me to Quake awhile back. Since then I enjoy it both as a player and as an admin almost as equal and I detest cheaters in any game, though I have more respect for them whne they are atleast honest about it.

Thanks for all the help and input guys, I can't wait to see what's next for BZFlag. If I can help in anyway, feel free to ask, I'll do my best.