SM3
Moderator: Moderators
Re: SM3
- 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
- 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
Re: SM3
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
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
Re: SM3
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.
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.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: SM3
Not only square maps. You can set the play area to whatever, so it is entirely possible to have multiple sizes.
Re: SM3
Bumpmapping works for me. Just need to specify Bumpmap tag at the right location in the file
Cube environment mapping (e.g. like unit reflections) shouldn't be too hard to make.
Before my (small) fix some ATi users said it worked fine, and it only had problems on nVidia.
Code: Select all
[trocks]
{
File=Maps/res/rocks+det.png;
Bumpmap=maps/res/rocksbump.png;
TileSize=50;
}
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.)Gota wrote: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...
Cube environment mapping (e.g. like unit reflections) shouldn't be too hard to make.
neddiedrow wrote:Why only square maps, and what would it take to change that?
jcnossen wrote:- 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
Forboding Angel wrote:Not only square maps. You can set the play area to whatever, so it is entirely possible to have multiple sizes.
Indeed, seems it's currently enforced to be equal to height map size.AF wrote:If I recall that functionality with play areas doesn't quite work
Yes please.Argh wrote: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...
Before my (small) fix some ATi users said it worked fine, and it only had problems on nVidia.
Re: SM3
It works, but the lighting angle is clearly wrong.Bumpmapping works for me. Just need to specify Bumpmap tag at the right location in the file
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.
- very_bad_soldier
- Posts: 1397
- Joined: 20 Feb 2007, 01:10
Re: SM3
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.Beherith wrote: Would everyone please do me a favor and test the map I uploaded? It uses 5 2k*2k textures in 4 blend operations (also 2k*2k blendmaps).
- very_bad_soldier
- Posts: 1397
- Joined: 20 Feb 2007, 01:10
Re: SM3
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...
But another thing I found in the infolog (dunno if it is important):
Code: Select all
You are missing the "ARB_shadow_ambient" extension (this will probably make shadows darker than they should be)
Code: Select all
[ 41] Set Shadows to 1
[ 109] Set water rendering mode to 3 (reflective&refractive)
[ 109] [myGL::CheckParseErrors] Shader compilation error at index-1 (near " !!ARBfp1.0
# water reflectiv") when loading fragment-program file waterRefractTR.fp:
[ 184] Set water rendering mode to 4 (bumpmapped)
[ 259] Set water rendering mode to 4 (bumpmapped)
[ 331] Set water rendering mode to 4 (bumpmapped)
- Attachments
-
- infolog.txt
- (27.24 KiB) Downloaded 116 times
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Re: SM3
but spring releases for windows are all 32 bit
Re: SM3
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:
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:
Code: Select all
[WATER]
{
BumpWaterEndlessOcean=0;
WaterSurfaceColor=0.6 1.0 0.4;
WaterPlaneColor=0.0 0.0 0.0;
WaterBaseColor=0.3 0.5 0.2;
WaterAbsorb=0.01 0.01 0.01;
WaterMinColor=0.0 0.0 0.0;
//WATER 4
WaterSurfaceAlpha=0.6;
WaterPerlinStartFreq=15;
WaterPerlinLacunarity=12;
WaterPerlinAmplitude=1.0;
}
- thesleepless
- Posts: 417
- Joined: 24 Oct 2007, 04:49
Re: SM3
DevIL isn't dealing with the GPU so i can't see how that would make any difference.Argh wrote: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).
Re: SM3
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).
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).