Recommended texture sizes - texture aliasing

I know this is more subjective, but I was just curious about what "size" texture files people are using in their games.  I used to think a 256x256 texture was pretty big, and should show up pretty detailed on a model, but I find that it really doesn't.  In fact, when texturing my hexboard I tried textures of many different sizes (64x64, 128x128, 256x256, 512x512) and I never really saw any improvement beyond 128x128 - and I still think the texture for the hexes doesn't look all that great.



Now I find myself loading models with some textures as large as 1024x512 and everything looks like jagged, aliased crap.  Render the same model, with the same textures in 3DS MAX and it looks great, in the game it's awful.  I have read the posts.  I have disabled S3TC.  I resized the textures (not all were "power of two") carefully in photoshop.  They still look like crap.  So, I'm just wondering, do the textures need to be larger to avoid the severe aliasing I am seeing?



Or - and this may be a totally stupid question - rather than scale the textures up, do I need to scale everything in the game down?  Like, make the geometry "smaller" compared to the size of the texture maps?  My gut tells me that should have zero impact, but I don't know exactly how this stuff works and it seems like if you scale the surface area of an object up, you are still stretching a 256x256 texture over it, whereas if you scale it down, that map covers less area and would not be so "stretched" out.  Now, my problem with this is that I already think my game world is quite small on the scale of things.  Shrinking everything down seems like it would make things unplayable, like the camera would need to be so close to "see" anything and would move so quickly that it would be impossible to do anything.  Do I also need to "scale" the camera down - for lack of a better term.  You all have permission to laugh at my ignorance.  Just tell me how to make these textures not look like utter and complete crap.  Then, laugh some more.

I'll start by pointing out I pretty much know nothing, I just hang around here and talk crap so feel free to ignore me  :stuck_out_tongue:



From what you just said it sounds like 3Ds Max is automatically rendering everything with some level of anti aliasing whereas jME doesn't.



Have you tried enabling anti aliasing in jME and can you check if 3Ds Max has it enabled by default?

I know less-than-nothing so I'm open to anything.



I am almost certain MAX does have anti aliasing enabled.  But it really seems like more of a difference than just that.  I'm not sure how to explain it.  Maybe once I get home tonight I'll post some pics.  But under MAX for textures that contain lines - like fine lines.  They seem to render at a size that looks like 2 pixels in width (these are arbitrary measurements just to give an example), even aliased they are nice and small and clean.  Within jME those same lines look like they are about 8 pixels in width, detail is lost, and they look smeared or smudgy.  Certainly enabling anti-aliasing within jME should improve the appearance - but I don't think it will fix the "scaling" issue (or at least the appearance of one), even though the textures are no longer being scaled within the game.



With that being said, how exactly do I enable anti-aliasing within jME - is it an extra pass?

display.setMinSamples…



can we see a screenshot please, that would really help us pinpoint what's wrong.

MrCoder said:

display.setMinSamples...

can we see a screenshot please, that would really help us pinpoint what's wrong.


I'll give that a shot when I get home.  Is there a recommended setting?  4? 8? 16?

I can't get you any screenies until later tonight.  My employer doesn't look kindly upon game development here at work :)  Unlike the lucky few who actually DO game development for a living.  I'll post some once I get home.

My guess would be mipmapping - try setting mipmapping off on the texture:



texture.setMipmapState(Texture.MM_NONE);



I do this for the player's plane in aircarrier, and it makes a HUGE difference to the sharpness of the texture. If you set this for all textures, it would probably slow everything down, and it has the effect of producing texture "shimmering" at long range when the texture pixels are much smaller than screen pixels. But for stuff you are looking at up close, all the time, it really works. Disabling texture compression is also often worthwhile as you say, but make sure to check it both ways to see if there is any noticeable degradation with compression.

The effect is clearly visible in a lot of commercial games as well - for example with weapons in first person shooters - the gun will get really noticeably less detailed half way along, where a lower mip mapping level kicks in. I never worked out why they didn't just disable mipmapping on weapons.

The best solution to this would probably be to adjust mipmapping distances rather than disabling mipmapping completely, but I'm not sure how to do that at the moment.

shingoki said:

My guess would be mipmapping - try setting mipmapping off on the texture:


texture.setMipmapState(Texture.MM_NONE);



I do this for the player's plane in aircarrier, and it makes a HUGE difference to the sharpness of the texture. If you set this for all textures, it would probably slow everything down, and it has the effect of producing texture "shimmering" at long range when the texture pixels are much smaller than screen pixels. But for stuff you are looking at up close, all the time, it really works. Disabling texture compression is also often worthwhile as you say, but make sure to check it both ways to see if there is any noticeable degradation with compression.

The effect is clearly visible in a lot of commercial games as well - for example with weapons in first person shooters - the gun will get really noticeably less detailed half way along, where a lower mip mapping level kicks in. I never worked out why they didn't just disable mipmapping on weapons.

The best solution to this would probably be to adjust mipmapping distances rather than disabling mipmapping completely, but I'm not sure how to do that at the moment.




This description sounds right on.  In fact, when looking in the showcase YOUR game was the one I looked at and said "why doesn't my ship look like THAT?"  And in this case the players view would be locked relatively close to their ship (with a limited ability to "orbit") so it'll always be fairly large in frame and I'd want it to be the best possible quality - without sacrificing performance.  Setting mipmap ranges sounds like the "right" solution overall, but for now I can try just turning it off.

However, I have to ask again because I'm an idiot, how do I turn it off when loading the textures with a model?  Is there some override key or option I can use?

Can I turn it off after the model loads?  There are several textures, so I'd rather just be able to set it "globally" for a model and let the loader handle it.

Not sure about that one, I guess it depends on the model format. Certainly Blender (for example) has a mipmap setting, but I don't know whether this makes it as far as jME intact. AFAIK you can set overriding texture locations for loading models, but I don't think that would include mipmapping. The best thing would be if you could provide an overriding texture loader for a model loader, so that you could then provide textures with mipmapping enabled as appropriate, when asked for a texture for a given url.



For aircarrier, I have to have a custom model loader anyway, to break apart the source models into collision, attachment points, camera positions, physics bounds, etc. so I just do the texture loading in there. That will let me do different skins later, as well as different mipmap settings now. I actually use a terrible hack looking at the names of nodes in my model to detect stuff like whether they should have environment maps, be double sided, etc. and I could also do mipmapping that way, although at the moment I just have one boolean switch for it. I set mipmapping false using that for the first person plane, then true for third person planes.

Well, further work on this is going to have to wait.  I got home last night and it seems as though my motherboard has died.  Are the gaming gods conspiring against me?!?  This is the second fatal crash I have had over the course of developing this game.  THe funny thing is, I have used this PC for quite a while and had done no development (game related) the entire time.  Now I startup development on the game again, and it tanks.



Once I can get things back up and running I'll post the results of all the suggestions here.

chirstius said:

Are the gaming gods conspiring against me?!?


Yes
Gentleman Hal said:

chirstius said:

Are the gaming gods conspiring against me?!?


Yes


At least I finally have confirmation.

Try sacrificing a chicken. Or an old NES. Or a chicken USING an old NES.

Another thought, something that got me initially with models was that i had no lightstate turned on. Ensure you do and compare with the lightstate on/off

shingoki said:

Try sacrificing a chicken. Or an old NES. Or a chicken USING an old NES.


Dammit!!

I admit, the guy deserves some respect for such high level auto thread hijacking :slight_smile:

…and it wasn't me this time. :wink:

Considering I have no PC at home to speak of at the moment and can't forward the "material" portion of this thread in any meaningful way, the hijacking seemed perfectly reasonable.  :D  Once I get a working machine again, I'll try to get this back on track.

oh…well…until then I think we've found a party thread!  8)



So what's everyone's favorite M&M color?  :stuck_out_tongue:

Blue. My wife won't go near the blue ones so I have to like them! :slight_smile:

nymon said:

Blue. My wife won't go near the blue ones so I have to like them! :)


* WHAPPAH * <-- that was my sad attempt at making a whipping sound.  :P