OK, so 16-bit PNG works... that's something I can deal with. That said, cliffs present big problems... meh, I guess I can live without cliffs until invisible heightmaps exist.

- Heightmaps need to be power of two + 1, like 33x33, or 1025x1025.
- You should be able to use 8 bit or 16 bit raw heightmaps. That means a 257x257 16 bit map should be exactly 132098 bytes. If it's not, then the loader can't calculate the size of it.
- Power of 2 sizes are required because it's using a quad tree to do the visibility culling and lod, but yeah that's not really a good excuse. Ideally it would just make a quad tree with fewer branches, but its not ideal

Keep in mind that cob locations fail past 128.

Frost, the point of sm3 isnt nearly just larger maps, anything above 32*32 is more or less unplayable with most mods for totally different reasons.
Its for MUCH nicer textures and smaller file sizes and faster rendering and prettiness.

Square maps is a huge bummer. Also noticed the lack of grass support

Vertical walls?will that be possible?will the texture stretch on high slope cliffs?
how about reflection?ice maps.Crystal maps.realistically looking metal maps...

None of that is possible with SM3. I'm also finding the lack of burned-in lighting is a problem- that really let me highlight geometry more. That can be fixed with a smarter shader, ofc.

All that said, it works, and in some ways it's an improvement on SMF- the overall lighting feels richer, and the additional detail level is nice (although all of a sudden all of my ground-tile stuff is looking rather pixelated, meh).

Maybe after we've all had a chance to learn how to do a few things (I've figured out a technique to optimize blends per-sector, amongst other things, which helps performance considerably) it will be possible to build maps that aren't slideshows and are genuine improvements on the best we can get out of SMF.

IDK yet. I'm more interested in the concept of "build-on-site" atm, I think that it's probably closer to what we actually need.

Why only square maps, and what would it take to change that?

Not only square maps. You can set the play area to whatever, so it is entirely possible to have multiple sizes.

If I recall that functionality with play areas doesn't quite work

Guess I'll have to test that. Should I re-consolidate my list of bugs here?

Oh, and have any ATi / Intel users tested this yet? Kinda concerned about that...

Bumpmapping works for me. Just need to specify Bumpmap tag at the right location in the file



No, there's no special support for that; textures will still stretch on high slope cliffs. I think with SM3 this might be solvable tho. (by allowing layers with texture coordinate generation based on another plane then the ground plane.)

Cube environment mapping (e.g. like unit reflections) shouldn't be too hard to make.





Indeed, seems it's currently enforced to be equal to height map size.


Yes please.

Before my (small) fix some ATi users said it worked fine, and it only had problems on nVidia.

It works, but the lighting angle is clearly wrong.

It's like the light's coming from a right angle, or something. The main lighting (i.e., where specular highlights aren't a major factor) seems to be OK, it's just the specular glints are wrong. I thought that that was why we needed the TBN matrix, but since we apparently don't need that, I guess it's just not using the right matrix.

And yeah, I'll get the rest of my list put together, but I've gotta sleep, I've been insomniac a lot this week and I need to catch up a bit this weekend.

Runs smoothly but I got the same look-through geometry effects as Tobi (current spring, 0.80.5.2). Even shadows (units and terrain) seem to work.

did you put the shader in shaders as tobi said ?

Errrrm, no, it seems I missed that point. But it works flawlessly when I do!

But another thing I found in the infolog (dunno if it is important):


and this:


Read the whole story in the appended infolog...

I am on a 64bit os.

but spring releases for windows are all 32 bit

Current bugs:

1. The lighting angle used by the normalmap was clearly wrong.

This is being discussed in the other thread.

2. It occasionally gives a false true to the logic that determines whether we can build. IE, turns green, but the build command fails.

Haven't had time to pin it down, but it appears that it's on fractional results.

3. It won't load RAW, at least not over here, so the heightmap looked distinctly pixelated in spots.

This can be mitigated by using 16-bit PNG, although I want to see testing results with ATi / Intel users first (in my experience, the DeVIL is not totally consistent across hardware, so we should be careful in our assumptions).

4. It needs to use ROAM, desperately.

5. It needs an "optimizer" mode, where some fixed-function display (really doesn't need to be super, just put down red squares or something) can tell mappers where they are blending 4 or more layers. Why not 3? Because 3 will be the typical situation, even though SM3 wasn't really designed for that, just to meet minimum beauty requirements, imo. By "3", I'm including the base layer (just preventing some confusion here).

6. If cliff stretching is going to be addressed- yay! My only request is that we have control over the "breaking angle"- i.e. the difference in the angle of the resulting mesh normal before this internal rule gets invoked, so that we can use it when surfaces are somewhat less than 90 degrees.

7. I've seen occasional clipping issues, but nothing too bad.

8. The play-area limits are borked.

9. Water has various issues, depending on the mode.

Water4: the moment the first "wave" starts, all I see is a blank plane. You won't see it until the first gameframe.

[EDIT]Correction: it's not blank, it has a weird line going through it that's some sort of massively-distorted reflection. Clearly the shader's not getting the right information.[/EDIT]

Water1: the reflections are all wrong. And they aren't nearly strong enough- where's the skycube?

Water2: works, but is unbelievably slow. Also seems to be missing the skycube.

Water0 works, as always.

Water3 doesn't work on my hardware atm, same shader error as was stated above.

Overall, it's in pretty good shape, though.


Water settings used:

DevIL isn't dealing with the GPU so i can't see how that would make any difference.

Eh? I thought it was using OpenGL for certain things. It's definitely been my experience that some things work, image-format-wise, on my hardware, but have failed on other peoples'. That said, IIRC DeVIL got updated, and this is a lot less of a problem than it was.

I'm just urging that we test this before we all go that route, start thinking about explaining the build process to mapper nubs... and whoops, it breaks on ATi or Intel chipsets (Intel especially, that software fallback mode needs get tested a lot).