New map format

SinbadEV · Post by **SinbadEV** » 26 Jul 2006, 22:37

I found it helpful to go into the map view and mouse over the map where I want to place features and then divide by 8... I concur that allowing feature placement IN PARTICULAR VARIABLE ROTATION... would be a lot better then fiddling around with endless shades of near identical reds (I usually give up after about 5 shades)

Post by **jcnossen** » 26 Jul 2006, 23:02

Edit: I probably won't be doing much with the new format until the bumpmapping is implemented, otherwise everything just looks like crap to me.

Really? I had the idea that most of your maps are quite suitable for a remake in sm3, with higher texture resolutions. Can you explain more?

Forboding Angel · Post by **Forboding Angel** » 26 Jul 2006, 23:25

All my maps barring about 3 of them (the early ones) have used high texture resolution. Lately with the massive maps I've been releasing the reason they look so omgwtfpwn is because the Normal-bumpmapping that I've applied to them. I can't do that with the new map format yet, so naturally everything looks very bland in comparison.

Yes, every map I have done is suitable for a remake. Only a few of them will be though.

See the thing is, if I want perfect details I still have to go through the process of running attributes mapping in l3dt, export as bmp, load in CS, select color range, new image, paste, greyscale, save.

THat's if you want perfect details, and me being the picky bastard that I am will probably end up doing that.

I could jsut use color range selection in photoshop, but I prefer quality. Quality takes a lot of time and effort, therefore, I'm not exactly in any hurry.

Now, if bumpmapping was implemented, I would have already done several maps.

And JC, will you please address my question? Rectangle textures get turned into squares in the new map format. Can you please take a look into this?

Forboding Angel · Post by **Forboding Angel** » 27 Jul 2006, 09:50

Got curious today.

Could someone explain why the base sand texture is not catching the dark areas? that's kinda wierd.

Sorry for the file size, but it's very dirty. I only worked on this for about half an hour (all the time I could spare between this n that).

Files:

http://www.yousendit.com/transfer.php?a ... 0D793B7F75

SM3 File:

Code: Select all


[MAP]
{
	Description=Flat map with a few mountains and metal in the middle
	TidalStrength=0;
	Gravity=155;						//in units/sec^2
	AutoShowMetal=0;                                        // 0 no show 1 show
	MaxMetal=1;						//how much metal a map square with the maximum metal value gives
	ExtractorRadius=40;				//radius that a single extractor(mine) extracts from
	MapHardness=300;

	[INFOMAPS]
	{
		metal=Maps/dry_data/metalmap.png;
		type=Maps/dry_data/typemap.png;
	}

	[ATMOSPHERE]
	{
		FogColor=0.80 0.79 0.70;
		FogStart=0.4;

		CloudColor=0.12 0.12 0.12;
		SkyColor=0.30 0.40 2.00;

		SunColor=1.20 1.00 1.00;
		CloudDensity=0.2;

		MinWind=0.6;
		MaxWind=24;
	}
	[WATER]
	{       
		WaterDamage=0;  //Amount of damage water does
		WaterBaseColor=0.4 0.5 0.8;  //color at water surface
		WaterAbsorb=0.004 0.004 0.002;  //how fast different colors are absorbed by the water
		WaterMinColor=0.1 0.1 0.3;  //the min value the water colors will go down to
	}
	[LIGHT]
	{
		SunDir=2 1 0;						//direction of sun (spring will normalize it later)(y 

component is upward)
		
		GroundAmbientColor=0.2 0.2 0.2;		//ambient (non sun lit) color of ground (and grass etc)
		GroundSunColor=1.0 1.0 1.0;			//color of ground where fully sun lit (added to ambient)
		GroundShadowDensity=0.8;			//how far from the non shadowed to the ambient color stuff in shadow 

will go

		UnitAmbientColor=0.1 0.1 0.1;		//ambient (non sun lit) color of units (and wreckage etc)
		UnitSunColor=0.5 0.5 0.5;			//color of units where fully sun lit (added to ambient)
		UnitShadowDensity=0.8;				//how far from the non shadowed to the ambient color stuff in shadow 

will go
	}
	[TEAM0]
	{
		StartPosX=1806;
		StartPosZ=1481;
	}
	[TEAM1]
	{
		StartPosX=7656;
		StartPosZ=7481;
	}
	[TEAM2]
	{
		StartPosX=7793;
		StartPosZ=556;
	}
	[TEAM3]
	{
		StartPosX=2268;
		StartPosZ=8468;
	}
	[TEAM4]
	{
		StartPosX=8656;
		StartPosZ=4581;
	}


	[TERRAIN]
	{
		ForceFallback=0;
	
		HeightScale=600.0;
		HeightOffset=10.0;
		Heightmap=Maps/dry_data/whakamatungariri.png;

		NumTextureStages=6; // all texture stages are multiplied
		AutoBumpmapStages=1;

		[texstage0]
		{
			// the first texture stage operation is ignored
			source=catchsand;
		}
		
		[texstage1]
		{
			operation=blend; // use the incoming alpha to blend between 2 textures
			source=crackeddirt;
			blender=crackeddirtblend;
		}
		[texstage2]
		{
			operation=blend; // use the incoming alpha to blend between 2 textures
			source=rock;
			blender=rockblend;
		}
		[texstage3]
		{
			operation=blend; // use the incoming alpha to blend between 2 textures
			source=sandycracked;
			blender=sandycrackedblend;
		}
		[texstage4]
		{
			operation=blend; // use the incoming alpha to blend between 2 textures
			source=drydirt;
			blender=drydirtblend;
		}
		[texstage5]
		{
			operation=blend; // use the incoming alpha to blend between 2 textures
			source=sand;
			blender=sandblend;
		}
		

/* TEXTURES */
		[rock]
		{
			File=Maps/dry_data/rock3.jpg;
			Bumpmap=Maps/dry_data/rock3_bump.jpg;
			TileSize=20;
		}
		[crackeddirt]
		{
			File=Maps/dry_data/desert1.jpg;
			Bumpmap=Maps/dry_data/desert1_bump.jpg;
			TileSize=20;
		}
		[sandycracked]
		{
			File=Maps/dry_data/lightdesertcracked.jpg;
			Bumpmap=Maps/dry_data/lightdesertcracked_bump.jpg;
			TileSize=20;
		}
		[drydirt]
		{
			File=Maps/dry_data/drysmallcracked.jpg;
			Bumpmap=Maps/dry_data/drysmallcracked_bump.jpg;
			TileSize=20;
		}
		[sand]
		{
			File=Maps/dry_data/dirtysand1a.jpg;
			Bumpmap=Maps/dry_data/dirtysand1a_bump.jpg;
			TileSize=20;
		}
		[catchsand]
		{
			File=Maps/dry_data/dirtysand2a.jpg;
			Bumpmap=Maps/dry_data/dirtysand2a_bump.jpg;
			
		}
		
/* BLENDERS */
		[catchsand]
		{
			Blendmap=1;
			OriginHeight=10;
			MaxHeight=0.5;
		}
		[rockblend] // a rock blender loaded from file for a specific map
		{
			Blendmap=1;
			File=Maps/dry_data/rockblend.jpg;
		}
		[sandycrackedblend] // a rock blender loaded from file for a specific map
		{
			Blendmap=1;
			File=Maps/dry_data/sandycrackedblend.jpg;
		}
		[drydirtblend] // a rock blender loaded from file for a specific map
		{
			Blendmap=1;
			File=Maps/dry_data/drydirtblend.jpg;
		}
		[sandblend] // a rock blender loaded from file for a specific map
		{
			Blendmap=1;
			File=Maps/dry_data/sandblend.jpg;
		}
		[crackeddirtblend] // a rock blender loaded from file for a specific map
		{
			Blendmap=1;
			File=Maps/dry_data/crackeddirtblend.jpg;
		}
	}
}

Weaver · Post by **Weaver** » 27 Jul 2006, 10:23

For some reason it doesn't like the name "catchsand" change it to "sand2" and see that works, it did for me.

Das Bruce · Post by **Das Bruce** » 27 Jul 2006, 11:31

Shading looks wrong.

mufdvr222 · Post by **mufdvr222** » 27 Jul 2006, 13:06

Well thats the first map in the new format that my machine will run, but it exits the game when I hit enter, "file Maps\dry.smd not found"

I like the increased texture detail but will we have as much controll over exactly what texture will go where?

Forboding Angel · Post by **Forboding Angel** » 27 Jul 2006, 15:01

mufdvr222 wrote:Well thats the first map in the new format that my machine will run, but it exits the game when I hit enter, "file Maps\dry.smd not found" I like the increased texture detail but will we have as much controll over exactly what texture will go where?

exact control, check out my blendmaps for some interesting info,

Post by **jcnossen** » 27 Jul 2006, 15:24

Wow nice!

Some comments:
- You have a catchsand texture and a catchsand blender. I think this actually results in a blender loaded from file Maps/dry_data/dirtysand2a.jpg
In any case, identically named sections don't work in a TDF.
- In the blender catchsand there is still OriginHeight, which is an outdated thing. I accidentally put it in one of the example files. You don't seem to be using this blender though so it's no problem here.

I can't find problems with rectangular textures from looking at the code so far, so i'll do a test sometime.

:D

I uploaded a new exe including forbodings map (I hope you don't mind...) Features/trees are broken on SMF maps in it, since it's very much work-in-progress.
However the autogenerated blendmaps that weaver was testing work now properly, and there is culling of terrain parts outside the camera.

http://user.supradigital.org/jcnossen/spring-sm3-v2.zip

Forbodings map runs at ~300 fps for me, but I wonder what slower cards experience. With the texturing that is currently in place, which is for older video cards, the texture stages are rendered with 5 passes! My 6800 GS renders it 5 times and still has 300 FPS :)

colorblind · Post by **colorblind** » 27 Jul 2006, 15:34

I get about 20 fps with my fx5200, but that's probably due to my old cpu (a good ol' P3 @ 0.9ghz).
This is a factor 1.5 slower than the old renderer, but when you take into account the scene is processed 5 times, it's actually 3,3 times faster

Very nice work JC.

Post by **jcnossen** » 27 Jul 2006, 15:58

My guess it would be fillrate of the 5200, not cpu speed. The terrain renderer has quite low cpu usage I think.

You could try setting NumTextureStages=3 and see if you have 40 fps..
Whakamatunga Riri with 6 stages is one of the higher end maps I guess.

Forboding Angel · Post by **Forboding Angel** » 27 Jul 2006, 16:05

6 Stages is high end? *groans* There are still 2 more textures left for that map.

I just can't win.

On a lighter note, that was all photoshop work. If I get some extra time tonight I will have l3dt generate the rock and redsand blendmaps for me so that they will be much more realistic.

I'm glad you like it. I can only seem to see the things I did wrong with it lol.

colorblind · Post by **colorblind** » 27 Jul 2006, 16:10

Well it is high end for pc's like mine, but not for pc's like JC's :).

Setting NumTextureStages=3 did indeed double my FPS. Which got me thinking that a "maxNumTextureStages" setting (in settings.exe) for low-end pcs might be a good idea ...

Forboding Angel · Post by **Forboding Angel** » 27 Jul 2006, 16:18

Any idea as to when bumpmapping will be working?

Post by **jcnossen** » 27 Jul 2006, 16:36

maxNumTextureStages sounds like a good idea to me yeah, from that point the renderer can switch the most ugly but fast texturing method, which still has some bugs right now.
That basically renders the texture stages to another texture first, and then uses that texture for actual terrain rendering. The texture detail is lost that way, but it is fast.

I'm working on features/trees/map drawings/grass right now, but it's not going very fast :S. Maybe I'll pause that for a while and work on bumpmapping and other cool shaders instead :) Bumpmapping could be done quite fast (few days) because I did it before and there are no major design problems.

It's still a long way before the next spring release though, so I guess there is no rush for mappers. Although you could play online if you both use the same sm3 test exe.

centurion-1 · Post by **centurion-1** » 27 Jul 2006, 17:01

I just had to chip in that I really appreciate what you are doing here and when designing GC i always think for example "Well, the range of the HRP cant be that long.... untill we get the new map format, then i can go crazy

"

Superlarge maps (ie 40x40-60x60) were my favorite in TA for some reason and i look forward to large maps making an entry to Spring...

...how large maps will be possibly while maintaining ok fps with the new map format? Is there a max draw distance variable for spring btw... would be good with new, bigger maps i guess

Lindir The Green · Post by **Lindir The Green** » 27 Jul 2006, 17:45

The new map format crashes for me...

Maybe I installed it wrong. Was I just supposed to dump it all in the spring directory, overwriting anything? Coz that's what I did, and it crashed on Forboding's map right as it was "generating trees."

Oh, and I have a FX 5200.

Post by **jcnossen** » 27 Jul 2006, 18:32

...how large maps will be possibly while maintaining ok fps with the new map format? Is there a max draw distance variable for spring btw... would be good with new, bigger maps i guess

It's not really the draw distance, with proper lod you can make that run fine. It's the memory use, spring uses currently ~40 bytes per heightmap pixel.
A 64x64 map would be (Assuming 512x512 heightmap is one ota unit) (512*64)^2 = 32768*32768 = 1074 MB in memory, which is too big, at least for my PC.
OTA did 64x64 maps because their heightmap resolution was lower AFAIK.

With optimization I might reduce it to 20 bytes per heightmap pixel though. It's a tradeoff between what you calculate on loading, and what you calculate realtime.

Lindir: you are supposed to install it that way yeah, so I'm clueless about that

hrmph · Post by **hrmph** » 27 Jul 2006, 18:45

Forboding Angel wrote: See the thing is, if I want perfect details I still have to go through the process of running attributes mapping in l3dt, export as bmp, load in CS, select color range, new image, paste, greyscale, save.

I've already come to the same conclusion... My problem is... how do you export the attributes map in fullsize. The only option I have is for screen capture which produces a 570x570 image. (maybe the option is in the more advanced version I don't have)

Forboding Angel · Post by **Forboding Angel** » 27 Jul 2006, 18:58

2.4 Has an "export as" option. I went through some stress over that one until I figured it out. 2.3d only has screen cap, I was about to cry over taht lol.

Spring RTS Engine

New map format