Mapmakers Poll: Grass on Green

[mother]

Ok, I've ended up having (independently) the same discussion with a few people. So I'd like some input (from mapmakers specifically).

You obviously cannot have a two colors of green in a single XY location in a bmp. Additionally because of the way that mapconv works there is a limit to how close together trees will get before you loose the grass. Does this bother you?

I've put together a Test map: http://www.fileuniverse.com/?p=showitem&ID=1413 It includes the metalmap that was used, for reference.

I've got a couple screenshots showing both 'sparse' folliage w/ grass, about as dense as grassy trees gets, and a shot of the density at which you loose the grass.





and



But please grab the map, perhaps play with it a bit, and let me know your thoughts.

The 'fix' for this would be to use the blue channel for grass, and use shades of green for features. Personally I would trade the grass/tree granularity for having features obviously different (like blue)- but I will gladly defer to the majority opinion if needed.

Took this shot just because I liked it [and I certainly wasn't going for 'pretty' when making this particular map, heh]


P.S. Jello = Yeah

[genblood]

I would like to see another layer or two added. Say, one for
grass and one for objects. We already have a metal map, height
map, texture map and the y map for terrain changes. Another
layer for trees and grass would help design the map better.
Instead of adding trees to the metal map. Its should have its
own layer .

An comments on if this is possible?

[IMSabbel]

Hm.
How about using one of the metal map channels as a bitfield?
Thus you could toggle at least 8 features without need for more and more destinctive channels...

[mother]

I would like to see another layer or two added. Say, one for
grass and one for objects. We already have a metal map, height
map, texture map and the y map for terrain changes. Another
layer for trees and grass would help design the map better.
Instead of adding trees to the metal map. Its should have its
own layer .

An comments on if this is possible?

It's possible, and I don't think it's too overly complicated to imp.

Do we want another few layers?

[mother]

Hm.
How about using one of the metal map channels as a bitfield?
Thus you could toggle at least 8 features without need for more and more destinctive channels...

Also known as "How we can tell you're not a mapmaker"

Two problems with that:
1)GeoVents and Tree's comprise 16 different feature types without arbitrary features, so that is already the equivalent of 2 channels (now reduced from 512 -> 16 quanta).

But more importantly, how does one easily manipulate such bitfields in Gimp, PSP, Photoshop, etc.?

[Doomweaver]

It would probably make most sense if features had their own map.
The metal map may be useful at some later stage for other definitions, i.e. wind, tide, water damage, or other TC's might use it as other resources.
Remove everything but metal from it, even geothermal vents, and put the features on another one.

In the features map:
For the green channel we can have grass, with higher values indicating higher density.

Blue and red can be used together.
B=0, r=0 means nothing
For r=1, b=0 means geo vent
for r=1, b=1 to 16 The Blue can be trees, with each value of blue from 1 to 16 being a tree.
for r=1, b=17 to 255 other natural features, such as rocks.

For r = 2 to 255, we have as many different colors available as we need, so we can place any wreckages of any units, or any others for that matter (254*256=65024)
Later this could also be used to place animals or other things.

[IMSabbel]

Hm.
How about using one of the metal map channels as a bitfield?
Thus you could toggle at least 8 features without need for more and more destinctive channels...

Also known as "How we can tell you're not a mapmaker"

Two problems with that:
1)GeoVents and Tree's comprise 16 different feature types without arbitrary features, so that is already the equivalent of 2 channels (now reduced from 512 -> 16 quanta).

But more importantly, how does one easily manipulate such bitfields in Gimp, PSP, Photoshop, etc.?

Well, i also cant write 3do files wirh notepad and fail to get any avis done with mspaint.
The same with zip files... writing them per hand is SOOOO impossible...
(sarcasm off)

Just write a frigging programm to make those bitfields. Input CSV seperated feature lists that are parsed into it. 5 minutes in a scripting language, 30 in c++. Create the csv files via a graphical editor... (just as a possible example. Why should one do feature placement in photoshop or something?

[SinbadEV]

When poking around with the old mapconv I found that it pulled the grass colour from the source texture (aka.. I made a map with 10r12g10b and it came up with near black grass... maybe it would be easier to just have a whole separate bmp for grass and have it determine grass colour from said bmp... then we could have brown grass on some dunes,,, or red grass on an alien landscape... etc...

[mother]

http://www.fileuniverse.com/?p=showitem&ID=1421

Changes for tonights build:
->Feature Map (24bit bmp)
Green=trees & geos (200-215 & 255)
Blue=Grass! (0 is no grass, 255 is full grass, values in between are inbetween densities)**
Red=Arbitrary/Wreckage features (255=1st, 254=2nd)


So like I decided to go ahead and add the extra layers.

Now the grass thing:
1)The engine controls the grass color, and it indeed is involved with the terrain map color
2)Now you can place grass on non-green, and get non-green grass (caveat emptor)
3)When we say 'grass density'... We dont mean what we want to mean, see its a binary thing 'on' or 'off,' and the resolution of the vegitation map is 1/64th that of the texture, so think density like dithering, or more like the ascii thing you get from mapconv to show you what ended up grass

------

*edit* damn forgot to mention!

I've changed how mapconv does geos: now it tries to place it exactly where the dot was *first* and then goes through its LSD phase looking for viable 'close' sites.

I've also removed the LSD phase from trees completely. If you put down a row of trees, you should get a row.

[mother]

Also known as "How we can tell you're not a mapmaker"

Well, i also cant write 3do files wirh notepad and fail to get any avis done with mspaint.
The same with zip files... writing them per hand is SOOOO impossible...
(sarcasm off)

Just write a frigging programm to make those bitfields. Input CSV seperated feature lists that are parsed into it. 5 minutes in a scripting language, 30 in c++. Create the csv files via a graphical editor... (just as a possible example. Why should one do feature placement in photoshop or something?

Lol... Well why would we bother with the intermediate csv->binary conversion? When you get that that feature layout GUI made (thank you for volunteering btw!!), I'll simply have mapconv read the features from the csv file

No need to go to a binary format with it (or go binary: use int or unsigned short for feature type and x/y position, and put a header in that has a string vector containing the feature names, and an int total number of features). You might also want to look into the CSunparser stuff so you could do placement with full knowledge of footprint, if not the actuall models.

[genblood]

Here is a screen shot .... with some wreckage...




I still need to put the right unit with the right dead one. I'll
have to take some time with that issue.

[Maelstrom]

What happens if two different installs have two different models in the same spot? IE: The developer has a custom built object made to look like a car for their map. Someone downloads this who also has custom models. The colour values could then possibly load in the wrong files. Unless there is a way of defining which colour points to which model? Like color255=car-model, color254=hose-model etc.

[SinbadEV]

First of all... THANK YOU mother, THANK YOU THANK YOU THANK YOU!!!!!

Second, havn't tried it out, but I think that the models for the wreckage will be pulled from the SD7 or maps folder... but I'm not sure... if it's getting pulled from the units from the game then the SDF file is pointing at a unit type's wreckage, not a custom model, or a number between 0 and 255... so it will be in the same place as long as people are using the same mod... this could however make mod specific maps happen I think.

[NOiZE]

http://www.fileuniverse.com/?p=showitem&ID=1421
Red=Arbitrary/Wreckage features (255=1st, 254=2nd)

How do we define what value is which wreckage?

[mother]

Heh sorry about that guys.

The file is fs.txt

It's a very simple <cr> delimited text file.

whatever name is on line 1 = red 255
on line 2 = red 254
and so on.

example values for corpses are things like

Code: Select all

armckfus_dead
armflak_dead
coregant_dead
Coretoast_dead

etc.

The name is whatever is in the []'s in the tdf file. For example this is the first half of the Gantry's corpse tdf:

Code: Select all

[corgant_dead]
	{
	world=All Worlds;
	description=Wreckage;
	category=core_corpses;
	object=corgant_dead;
	featuredead=corgant_heap;
	footprintx=9;
	footprintz=9;
	height=20;
	blocking=1;
	hitdensity=100;
	metal=5270;
	damage=2440;
	reclaimable=1;
	featurereclamate=smudge01;
	seqnamereclamate=tree1reclamate;
	}

So the feature _name_ is whatever is in those []'s. The name of the 3do file is the object= line, in case anyone is wondering.

As to M's question: The 256 'arbitrary' features are per map, the red=255 stuff is only the way that the map maker tells mapconv what to put where- has nothing to do with the compiled map. In the .smf file there is a feature header which lists the different feature types which is followed by a list of features (type 0..15 for trees, 16 for geos, 17... for these features) and their coordinates.

So, in total psuedo-code, the actual 'featuremap' looks like:
TreeType1,Treetype2,...,TreeType15,Geovent,armckfus_dead;(17,100,100)

Which would put a arm cloakable fusion corpse at 100,100...

[SinbadEV]

mother, have you got a test map uploaded so we can see how this works?

[mother]

mother, have you got a test map uploaded so we can see how this works?

I should say no so ppl don't starting getting high expectations hehehe...

http://www.fileuniverse.com/?p=showitem&ID=1440

In all its glory.

Remember to either compile spring.exe from cvs (riiiight) or use the exe in the 0831 mapconv.

BTW this is the archive structure for such maps, so worth d/l just to have that heh.

*edit* Screwed up once again... I left out the grounddetailtexture bmp.
http://www.fileuniverse.com/?p=showitem&ID=1441
erase everthing after .bmp and put in either maps/ or the maps folder in the sd7, or just nuke the offending line in the smd.
*edit*

[mongus]

You mr. mother, rule. :D
great job so long, keep it up!

[aGorm]

Mother... sorry to be a pain, but i cant get this dam thing to work! it just brings up a bloody error. I hate going away on holidays, you come back and the bloody world has moved and so it's probablie I've missed somthing vital at some point and not noticed.

Its good work im sure, if only i could see it

aGorm

P.S that map is... odd to say the least.

[mongus]

you must grab this (modified by mother) mapconv.

included in that file, is a spring.exe (compiled from a recent cvs i guess).

replace your spring.exe with that one (backup first).

then, it should work.

e: some images.