anything against the removal of the SM3 map format?

[knorke]

http://springrts.com/wiki/SM3_Map_Format
---
This was the only working dl link of a sm3 map I found:
http://springfiles.com/spring/spring-ma ... assage-v02

It requires adding some commas etc to the .sm3 file or map does not load. (think because years ago the parser was made more strict wrt wrong synthax)
The included 1024x1024 minimap.png seems oversized though.

Then it seems to work in 94.1 , no graphical errors and ok performance.

Problem is that units can not move.
It might be because the terrain height is shown as -10xxx everywhere even though the units stand on ground and the waterplane is under the terrain. (beside that, water looks normal)
Airmesh is also drawn under the map. No idea if those are bugs of the map or map format.
Or if there are any other problems, but did not notice.

Guess sm3 has some advantages, HeadHunter named some.
Not having to use mapconv would imo be pretty nice: Make a change to texture/heightmap, just save the file and restart Spring. No waiting several minutes for mapconv to compile.
The way how textures are distributed also seems easier to work with to me. For example painting cliff textures can be pretty meh, basically have to use some terrain software to generate some giant texture. With sm3 can just paint some black/white lines onto a small (=easy to handle) picture.

Example workflow where sm3 is imo better than sm2:
Creating heightmap as vector graphics.
Imo super pro for heightmap because easy to make gradients (=perfect ramps) nice to make symmetry, lines etc.
Can scale make the map larger or smaller without losing detail or running out of memory.
With sm2 at some point you have to somehow create a hudge texture file, with a different software.
With sm3 you could do it all from within the vector software, and in the end it all exports to small easy to handle images.

tl;dr:
What sucks with mapping:
-waiting for mapconv to finish
-waiting for whatever software to generate hugde textures
with sm3 do not need this.

[smoth]

well go fix it and add support for SSMF features. Otherwise, stop caring. It has been years.

last I recall and the only remaining shots I have on my site are here

http://cs.selu.edu/~ssmith/spring/wipmap/sm3test/


it was rubbish by and large. I can see the points brought up if you wanted KP or other surreal maps but otherwise just give up.

(it is also worth noting I re uploaded these images, I have no idea what the original date created was)

[Cheesecan]

I experimented a bit with SM3 back when it was still relevant/hyped. Made a somewhat decent looking map that I think never got released (or it simply vanished when the filesites went belly up one after another).

Imho there's no need to care further about SM3. SSMF can give amazing results and is a lot more straightforward to use.

Map filesize is becoming less of a care with fast connections and fast computers. Most terrain rendering software allows you to do the same things SM3 does, i.e. flexible texturing. My map Hohenheim is a good example of something you even couldn't do with SM3. As for rendering times, get a faster CPU and run software that is multithreaded. Carrara will use each core to 100% - this means you half render time if you go from quad core to octa core. Having an SSD allows mapconv finish in <1 min on any map. Oh and Photoshop CS has GPU acceleration now so working with megatextures is a piece of cake, I do all my post-processing with it.

Also I think non-mappers comment too much on mapping, with no clue what they are talking about (!).

[smoth]

there are SOME advantages to SM3 but the disadvantages outweigh them

[Pxtl]

I used to be a cheerleader for SM3 back when 80 meg maps meant waiting 20 minutes for newbies to ready up, but these days large filesize maps aren't as much of a problem anymore.

[zwzsg]

But you can have small SMF maps!

[knorke]

but these days large filesize maps aren't as much of a problem anymore.

These days more players seem to play from laptop instead from desktop, at least sometimes. Every other game someone seems to write "wait a sec, I am on laptop with bad wifi signal in the bathroom."
Bandwidth/hardware limits will always stay relevant and lower limits means more a wider "market."

Anyway, It is not so much if the maps are smaller for players, though that is a plus too.
The big advantage is imo the files while *editing* are much easier to handle.
Without the batman equipment that Cheesecan mentions: no need for octa core, SSD and multithreaded software.

Only disadvantage of sm3 is that it does not work.

[Cheesecan]

Without the batman equipment that Cheesecan mentions: no need for octa core, SSD and multithreaded software.

Nah, an 8-core CPU + SSD costs just €215 around here. L3DT is €26.

[smoth]

Anyway, It is not so much if the maps are smaller for players, though that is a plus too.
The big advantage is imo the files while *editing* are much easier to handle.

and with that simplicity comes simplicity in the end result.

[knorke]

Nah, an 8-core CPU + SSD costs just €215 around here. L3DT is €26.

Realistically needs all the other parts too. Requiring the latest in hardware to make maps for an opensource game seems not right somehow.

and with that simplicity comes simplicity in the end result.

easier, not simpler. Or maybe we should hope too that spring never gets easier to use in other areas? Just think how ugly all units will suddendly should there be an easy to use animation system!

[FLOZi]

The terrain rendering system was the one I was talking about just before I got banned, where I said I'd written something that performed much better than what is in the engine, but I hadn't released it yet.

A practical tech-demo of it can be found here. I have no idea how much of it would have to be changed to work with the Spring Engine at this time, but probably very little. This build includes a build of Spring Engine and it's ready to play on Windows, I think.

It also includes the last version of POPS and some other neat stuff. I was working on getting P.U.R.E. working with all normal-mapped everything when I got banned, so there's World Builder stuff with basic normalmaps in there, etc.

I think you should probably check it out; ROAM was available then, it still had lots of performance problems when tested. I presume that its performance is better now, but what I wrote didn't have any engine support at all and was significantly faster than ROAM was then.

What I wrote, if coupled with a smarter chunking system for terrain meshes, would allow for full fidelity at typical gameplay distances on fairly crappy hardware but with very novel use of shaders and a flexible way to edit maps, as opposed to Spring's fairly-awful static-bitmap approach. In theory, a realtime editor could be built, for example, supporting brushes and stuff, allowing maps to be built and edited in-engine. It also supports glow and reflectivity channels for the shader, which you'll see if you view the second map included in the tech demo.

It was faster than anything that was done then and I suspect that it's still the best solution.

[The Yak]

so some banned dude made a a map rendering system for spring wut?

I guess I shall at least take a look before passing judgements...

If it's just a mesh rendering system like ROAM though then I don't really see how it helps with sm3

[abma]

who is xenoargh? not a single post seems to exist, also user doesn't exist ?!

[The Yak]

Based on the large amount of PURE content in this thing I'm pretty sure it's this guy: http://springrts.com/phpbb/viewforum.php?f=53

I can't get anything to work though, all just crashes upon startup

[abma]

Argh wasn't banned it seems, he just left because of RL. Someone with the knowledge please en-light us! :)

[Kloot]

Oh yes, quote Argh, banned for constantly making bullshit claims about subjects beyond his understanding, making yet another bullshit claim.

What his "terrain rendering system" consists of:

Code: Select all

-- liberally c/p'ed from MapRenderer.lua.deprecated
--
local function SetShaderUniformLocations(s)
	MapShaderLocs.cameraMatrixLoc     = glGetUniformLocation(MapShader, "cameraMatrix")
	MapShaderLocs.cameraInvMatrixLoc  = glGetUniformLocation(MapShader, "cameraInvMatrix")
	MapShaderLocs.shadowMatrixLoc     = glGetUniformLocation(MapShader, "shadowMatrix")

	--MapShaderLocs.haveShadowsLoc	= glGetUniformLocation(MapShader, "haveShadows")
	MapShaderLocs.shadowParamsLoc     = glGetUniformLocation(MapShader, "shadowParams")
	--MapShaderLocs.shadowDensityLoc    = glGetUniformLocation(MapShader, "shadowDensity")
	MapShaderLocs.treeMoveLoc = glGetUniformLocation(MapShader, "treeMove")
	MapShaderLocs.shaderTime = glGetUniformLocation(MapShader, "shaderTime")
end

local function CreateMapShader()
	local MapShader = glCreateShader({
	vertex = [[
		varying vec3 lvES;
		varying vec3 hvES;
		varying vec3 nvES;

		varying mat3 tbnInvMatrix;
		varying vec3 cdES;

		uniform mat4 shadowMatrix;
		uniform vec4 shadowParams;
		uniform mat4 cameraMatrix;
		uniform mat4 cameraInvMatrix;

		void main(void) {
			gl_TexCoord[0].st  = gl_MultiTexCoord0.st;
			gl_TexCoord[2].st  = gl_MultiTexCoord0.st * 32.0;		
			vec4 vertexDis = gl_Vertex;

			mat4 modelMatrix = cameraInvMatrix * gl_ModelViewMatrix;
			gl_Position = gl_ProjectionMatrix * cameraMatrix * modelMatrix * vertexDis;
			mat4 modelInvMatrix = gl_ModelViewMatrixInverse * cameraMatrix;

			vec3 vpES = (gl_ModelViewMatrix * vertexDis).xyz;
			vec3 cpES = vec3(0.0, 0.0, 1.0);

			vec3 svOS = gl_MultiTexCoord5.xyz;
			vec3 tvOS = gl_MultiTexCoord6.xyz;

			mat3 tbnMatrix = mat3(svOS, tvOS, gl_Normal);
			tbnInvMatrix[0].x = tbnMatrix[0].x;
			tbnInvMatrix[0].y = tbnMatrix[1].x;
			tbnInvMatrix[0].z = tbnMatrix[2].x;

			tbnInvMatrix[1].x = tbnMatrix[0].y;
			tbnInvMatrix[1].y = tbnMatrix[1].y;
			tbnInvMatrix[1].z = tbnMatrix[2].y;

			tbnInvMatrix[2].x = tbnMatrix[0].z;
			tbnInvMatrix[2].y = tbnMatrix[1].z;
			tbnInvMatrix[2].z = tbnMatrix[2].z;

			cdES = (vpES - cpES);

			nvES = normalize(gl_NormalMatrix * gl_Normal);
			lvES = normalize(gl_LightSource[0].position.xyz);
			hvES = normalize(gl_LightSource[0].halfVector.xyz);

			vec4 worldPos = gl_ModelViewMatrix * gl_Vertex;
			gl_TexCoord[3] = shadowMatrix * worldPos;
			gl_TexCoord[3].st = gl_TexCoord[3].st * (inversesqrt( abs(gl_TexCoord[3].st) + shadowParams.z) + shadowParams.w) + shadowParams.xy;
		}
	]],

	fragment = [[
		varying vec3 lvES;
		varying vec3 hvES;
		varying vec3 nvES;

		varying vec3 cdES;

		uniform sampler2D splatTex1;
		uniform sampler2D splatTex2;	
		uniform sampler2D diffuseTex01;
		uniform sampler2D diffuseTex02;
		uniform sampler2D diffuseTex03;
		uniform sampler2D diffuseTex04;
		uniform sampler2D diffuseTex05;
		uniform sampler2D diffuseTex06;

		uniform sampler2D normalTex01;
		uniform sampler2D normalTex02;
		uniform sampler2D normalTex03;
		uniform sampler2D normalTex04;
		uniform sampler2D normalTex05;
		uniform sampler2D normalTex06;		

		uniform samplerCube reflectMap;

		uniform sampler2DShadow shadowMap;

		uniform vec3 unitAmbientLight;
		uniform vec3 unitDiffuseLight;

		varying mat3 tbnInvMatrix;

		void main(void) {
			vec2 tc = vec2(gl_TexCoord[0].s, gl_TexCoord[0].t);
			vec2 dtc = vec2(gl_TexCoord[2].s, gl_TexCoord[2].t);

			vec4 splatOne = texture2D(splatTex1, tc);
			vec4 splatTwo = texture2D(splatTex2, tc);
	
			vec4 Diffuse01 = texture2D(diffuseTex01, dtc);
			vec4 Diffuse02 = texture2D(diffuseTex02, dtc);
			vec4 Diffuse03 = texture2D(diffuseTex03, dtc);
			vec4 Diffuse04 = texture2D(diffuseTex04, dtc);
			vec4 Diffuse05 = texture2D(diffuseTex05, dtc);
			vec4 Diffuse06 = texture2D(diffuseTex06, dtc);
	
			vec4 Normal01 = texture2D(normalTex01, dtc);
			vec4 Normal02 = texture2D(normalTex02, dtc);
			vec4 Normal03 = texture2D(normalTex03, dtc);
			vec4 Normal04 = texture2D(normalTex04, dtc);
			vec4 Normal05 = texture2D(normalTex05, dtc);
			vec4 Normal06 = texture2D(normalTex06, dtc);
	
			vec4 basicColor;
			vec4 extraColor;
	
			basicColor = Diffuse01;//Set initial "layer" now
			extraColor = Normal01;//Set initial "layer" now
	
			basicColor = mix(basicColor, Diffuse02, splatOne.r);
			basicColor = mix(basicColor, Diffuse03, splatOne.g);
			basicColor = mix(basicColor, Diffuse04, splatOne.b);
			basicColor = mix(basicColor, Diffuse05, splatTwo.r);
			basicColor = mix(basicColor, Diffuse06, splatTwo.g);//Only using 5 channels, 3 extra... may be possible to fit in another diffuse / normal
	
			extraColor = mix(extraColor, Normal02, splatOne.r);
			extraColor = mix(extraColor, Normal03, splatOne.g);
			extraColor = mix(extraColor, Normal04, splatOne.b);
			extraColor = mix(extraColor, Normal05, splatTwo.r);
			extraColor = mix(extraColor, Normal06, splatTwo.g);//Only using 5 channels, 3 extra... may be possible to fit in another diffuse / normal
	
			mat3 tbnMatrix;

			tbnMatrix[0].x = tbnInvMatrix[0].x;
			tbnMatrix[0].y = tbnInvMatrix[1].x;
			tbnMatrix[0].z = tbnInvMatrix[2].x;

			tbnMatrix[1].x = tbnInvMatrix[0].y;
			tbnMatrix[1].y = tbnInvMatrix[1].y;
			tbnMatrix[1].z = tbnInvMatrix[2].y;

			tbnMatrix[2].x = tbnInvMatrix[0].z;
			tbnMatrix[2].y = tbnInvMatrix[1].z;
			tbnMatrix[2].z = tbnInvMatrix[2].z;

			vec3 nvTS = vec3((extraColor * 2.0) - 1.0);

			float nvDOTlv = 0.0;
			float nvDOThv = 0.0;
			vec3 reDirES;

			vec3 nv_OS = normalize(tbnMatrix * nvTS);
			vec3 nv_ES = normalize(gl_NormalMatrix * nv_OS);


			nvDOTlv = max(nvDOTlv, dot(nv_ES, lvES));
			nvDOThv = max(nvDOThv, dot(nv_ES, hvES));
			reDirES = reflect(normalize(cdES), nv_ES);

			float shininess = extraColor.a * 4.0;

			float specPow =
			(nvDOTlv > 0.0 && nvDOThv > 0.0)?
			max(0.0, pow(nvDOThv, shininess)):
			0.0;
	
			vec3 texCube = textureCube(reflectMap, reDirES).rgb;

			vec3 specColor = texCube * specPow * extraColor.a;
			vec3 reflColor = texCube;

			vec3 diffColor = (unitDiffuseLight * nvDOTlv) + unitAmbientLight;  //boost light values

			reflColor = mix(diffColor, reflColor, extraColor.a);
			reflColor += basicColor.a;

			gl_FragColor.rgb = basicColor.rgb;
			gl_FragColor.rgb = gl_FragColor.rgb * reflColor + specColor;

	
			//if(haveShadows != 0) {
				float shadow = shadow2DProj(shadowMap, gl_TexCoord[3]).r;
				if (shadow ==  0.0) {
				gl_FragColor.rgb = gl_FragColor.rgb * unitAmbientLight;
				}	
			//}
			gl_FragColor.a = 1.0;
		}
	]],

	uniformInt = {
		splatTex1 = 0,
		splatTex2 = 1,
		diffuseTex01 = 2,
		diffuseTex02 = 3,
		diffuseTex03 = 4,
		diffuseTex04 = 5,
		diffuseTex05 = 6,
		diffuseTex06 = 7,
		normalTex01 = 8,
		normalTex02 = 9,
		normalTex03 = 10,
		normalTex04 = 11,
		normalTex05 = 12,
		normalTex06 = 13,	
		shadowMap  = 14,	
		reflectMap  = 15,		
	},
	uniform = {
		unitAmbientLight = {glGetSun("ambient", "unit")},
		unitDiffuseLight = {glGetSun("diffuse", "unit")},
		shadowParams  = {gl.GetShadowMapParams()},
	},
	uniformMatrix = {shadowMatrix = {glGetMatrixData("shadow")},}
	})
	return MapShader
end


function gadget:Initialize()
	...
	Spring.SetDrawGround(false)
	MapShader = CreateMapShader()
	...
end


local function GetUnitDefMaterial(unitDefID, preDL, pstDL)
	...
	textureNames[unitDefID] = {
		[1] = "maptiles/blend1.bmp",
		[2] = "maptiles/blend2.bmp",
		[3] = "maptiles/base.dds",	
		[4] = "maptiles/tex1.dds",
		[5] = "maptiles/tex2.dds",
		[6] = "maptiles/tex3.dds",	
		[7] = "maptiles/tex4.dds",
		[8] = "maptiles/tex5.dds",	
		[9] = "maptiles/basebump.dds",	
		[10] = "maptiles/tex1bump.dds",
		[11] = "maptiles/tex2bump.dds",
		[12] = "maptiles/tex3bump.dds",	
		[13] = "maptiles/tex4bump.dds",
		[14] = "maptiles/tex5bump.dds",		
	}

	local matTbl = {
		texunits = {
			[0] = {tex = textureNames[unitDefID][1],   enable = true},
			[1] = {tex = textureNames[unitDefID][2],   enable = true},
			[2] = {tex = textureNames[unitDefID][3],   enable = true},
			[3] = {tex = textureNames[unitDefID][4],   enable = true},	
			[4] = {tex = textureNames[unitDefID][5],   enable = true},
			[5] = {tex = textureNames[unitDefID][6],   enable = true},
			[6] = {tex = textureNames[unitDefID][7],   enable = true},
			[7] = {tex = textureNames[unitDefID][8],   enable = true},
			[8] = {tex = textureNames[unitDefID][9],   enable = true},
			[9] = {tex = textureNames[unitDefID][10],   enable = true},
			[10] = {tex = textureNames[unitDefID][11],   enable = true},
			[11] = {tex = textureNames[unitDefID][12],   enable = true},
			[12] = {tex = textureNames[unitDefID][13],   enable = true},
			[13] = {tex = textureNames[unitDefID][14],   enable = true},
			[14] = {tex = '$shadow',   enable = true},	
			[15] = {tex = '$reflection',   enable = false},		
		},
	},
	shader = MapShader,
	prelist = preDL,
	postlist = pstDL,
	...
end

local function GetPreDisplayList()
	...
	-- see maps/{FireAndIce.sdd,SmokeCity.sdd}/unittextures/
	gl.Texture(1,"maptiles/blend1.bmp")
	gl.Texture(2,"maptiles/blend2.bmp")
	gl.Texture(3,"maptiles/base.dds")	
	gl.Texture(4,"maptiles/tex1.dds")
	gl.Texture(5,"maptiles/tex2.dds")
	gl.Texture(6,"maptiles/tex3.dds")	
	gl.Texture(7,"maptiles/tex4.dds")
	gl.Texture(8,"maptiles/tex5.dds")	
	gl.Texture(9,"maptiles/basebump.dds")	
	gl.Texture(10,"maptiles/tex1bump.dds")
	gl.Texture(11,"maptiles/tex2bump.dds")
	gl.Texture(12,"maptiles/tex3bump.dds")	
	gl.Texture(13,"maptiles/tex4bump.dds")
	gl.Texture(14,"maptiles/tex5bump.dds")	
	gl.Texture(15,"$shadow")
	gl.Texture(16,"$reflection")
	...
end
local function MapUnit(unitID)
	...
	local preDL = GetPreDisplayList(unitID)
	local pstDL = GetPostDisplayList(unitID)
	SUR.SetMaterial(unitID, 1, "opaque", GetUnitDefMaterial(unitDefID, preDL, pstDL))
	...
end

function gadget:RecvFromSynced(fun, unitID)
	if (fun == "MapUnit") then
		-- see mods/WORLD_BUILDER_CONTENT/Units/grid_test.fbi and maps/{FireAndIce.sdd,SmokeCity.sdd}/objects3d/0000001_grid_test.s3o
		MapUnit(unitID)
	end
end

So it uses the UNIT-rendering API to draw some special (map-geometry) units with a custom shader material that does nothing but trivially combine textures (through a splatting scheme not unlike SSMF's), and this is supposed to be a viable replacement for either SMF or SM3. Sure, whatever floats your boat.

[FLOZi]

Don't shoot the messenger. I think my views on Argh are fairly well known but I couldn't resist mentioning it - seemed pertinent with so many people spouting off about SM3 who know nothing about it...

@abma; see pm.

[Cheesecan]

If you want to reduce map file size, how about you:

1. Write a Carrara plugin that takes this shading tree:


2. Exports it into the SM3 format (this includes adding the corresponding SM3 API functionality missing for things like distribution functions, noise filters, projection mapping, etc).

3. Have it render inside Spring in real-time (Carrara takes 2 hours).

[Forboding Angel]

Honestly, if you want to have a map format that works well, you essentially need to implement how L3DT renders textures, in real-time.

That is to say, everything in l3dt is rendered using the power of MATHS.

You have layers based upon steepness of grade, altitude, etc. Ok, so have those rules, simplify them a bit, splat textures on those areas and call it a day.

Of course, it isn't a silver bullet and is only really suitable for terrain style maps. I imagine it would be shit for city type maps.

Still would need detail texture splatting and normal mapping a la ssmf to be ever remotely considerable.

Imo, sm3's biggest downside was that it used images to determine where the textures should be splatted. I could be wrong, but that seems extremely inefficient to me. Better to use calculations to figure that out, isn't it?

Anyway, whatever, sm3 is due for death. Let it go.

[Funkencool]

Well technically l3dt uses the attributes map in the the same way. Then you can still make adjustments that could otherwise never be calculated.