mapconv

[user]

rgb is also good, it is a raw rgb format, no alpha, tif suport will also be added, jpg quality is good at 100 quality, but png is still better, i would
add more formats, but that is all DevIL supports.

[aGorm]

Is there a link to this version?

Oh, and yhe, I don't care if its png,tga,tiff... whatever. Just as long as its lossless. Just.... safer. Even if 100% jpg are practically lossless.

By the way the last version I tried gave me weird grass... like the grass had stripes of white , stripe of normal grass, stripe of white... is that fixed/known about?

aGorm

[user]

the grass is ok, its color is changed to follow the map texture color,
so in a yellow map, your grass will be yellow.

version 1.0 has not been relased yet, but its almost done.

for detail you will be able to use the raw image formats such as .rgb
or .tiff, .raw, for speed i would recommend using jpg.

[user]

DevIL can load .hdr, but would .hdr images work?
their format is different from the other images.

[user]

i will test a few times and then relase,suport for the image formats will
work like this:

-w option text file.

in the file:

Code: Select all

<any other options>
formatbmp

or

Code: Select all

<any other options>
formatpng

the formats will be bmp,png,jpg,tga,dds,raw,h,rgb,tiff.

<any other options> will be options like ignoreheight, and some other things.

ignoreheight, will be used to ignore the heightmap when placing features.

i cant think of any other options, any suggestions?

and some of the files listed above are not suported by nvdxt.
the nvdxt suported formats are:
.tga, .bmp, .gif, .ppm, .jpg, .tif, .cel, .dds, .png, .psd, .rgb, .bw and .rgba

[Argh]

I really can't think of any, short of making new versions for SMF in Spring, to support more mip levels... but that's more than enough for a day's work! Really, really impressed with this app at it's current state.

It let me build the line-less version of this, which was well-worth the many test runs, trust me:


Right-click to enlarge.

[user]

i made a urban map, it looks good, would look really good with those buildings.

it has no lines.

here a screenshot:

[Argh]

It's not about the buildings. It's about the fact that the map's never the same way twice... among other things...

Same map, different run:


Right-click to enlarge. Compare with previous.

[user]

there are some trees on the urban area,

you should make the building placement run before the tree placement,
and tree placement should check the area around to see if there arent any buildings.

and does my map look good?

[Argh]

you should make the building placement run before the tree placement,
and tree placement should check the area around to see if there arent any buildings.

It does. I just have random "holes" in the cities right now, where nothing is being placed. Then trees sometimes fit in the holes when that pass runs. The final version will fill the holes and not allow that to happen, I just don't have all of the buildings and other stuff done yet.

As for your map... well, if the streets are roughly "to scale" (a very loose concept- a Weasel from BA is bigger than a car, in OTA's "scale", which was very loosely and inconsistently defined)... then it should be a lot of fun, because there wouldn't be billions of buildings on-screen at once. Having a giant city packed with nothing but buildings, even with the performance-enhancing stuff in World Builder, would present a lot of problems, however, due to the way that Spring handles them. I can't see enough detail in your shot, though, to get a feeling for how detailed that map really is.

I'd think that the coolest-possible implementation of a city would probably have more areas that were static, hand-painted for a specific use, and had "spectaculars" defining them- giant skyscrapers, huge sports arenas, massive factories with lots of animations, and the like. World Builder pretty much frees us from the limitation of static content, so our stuff can be whatever we feel like. Having defined areas in a city- "landmarks", if you will, surrounded by procedurally-generated content- will probably be more interesting than generating the whole thing from a small number of random objects. It really depends on how many people contribute content to the library of objects, honestly...

[Tobi]

All mipmap levels that make sense are already included in the map. (It's only 4 for DXT1 compressed 32x32 tiles, can't subdivide more because DXT1 stores 4x4 blocks of pixels at a time.) Only by making the tiles bigger more mipmap levels can be defined.

Shouldn't be too hard to make Spring accept other stuff since it stitches multiple tiles together anyway in software. (could even make it read png /jpg tiles I think, though the variable tile size (in bytes, not pixels) may be a challenge.)

[user]

the small tile size is the number of bytes that a 32x32 dxt1 compressed
image with 4 mipmaps takes, it is:

the size of 32x32 (32*32)/2 -----image.
the size of 16x16 is the size of 32x32 / 4.-------first mipmap.
the size of 8x8 is the size of 16x16 / 4. ---------second.
the size of 4x4 is the size of 8x8 / 4. ---------third.
1x1 is 4x4/4 ---last one, nvdxt doesnt creates the last mipmap.

this is different for dxt3 and 5, for dxt 3 and 5 it is bigger.

making it read jpg and png is not needed, dxt compression is better.
it would need a check to see if the version is old, or it would break all
the old maps, this could be done using the smf variable version.

[user]

about my map, it is currently 10x10, the streets are not big, but i will make it 14x14, my map was made to just see how urban would look in spring, i made some building models, but their detail was really bad,
and they didnt work in spring, they were big rectangles with a big hit
sphere, i will make a few screenshots of my map.

[user]

i am doing some tests on the dds file format, to find out the size of
dxt 3 and 5, i made a 32x32 808 bytes, the dds data size is (filesize-ddsheadersize)

while the dds header size is 128 bytes and a 32x32, dxt1, 4 mips, is 808 bytes.

to find out the size of the data just do (808-128 = 680).

thats why dxt1 tiles are 680.

the size of the data of dxt 3 and 5 is 1360 for both. so just increase the tile size to that, it was not hard to find.

[user]

version 1.0 is done, but not released yet, because i am testing it, tested
using all formats.

and about the next version(probably 1.1), the only thing i can think of making is improving the new -w options parameter, and special support for nvcompress, which seems to have problems.

uploading version 1.0 ...

here it is:

http://www.unknown-files.net/spring/4044/mapconv10/#

new features:

-w <text file>

lets you specify lots of options for choosing how it will make your map, the currently avaiable options are: ignoreheight, keepminimap, format<imageformat>,

where ignore height, makes the heightmap be ignored when placing features,

keep minimap makes the minimap not be deleted when finished compiling,

and format, is used to choose the format of the temporary tile files.


any suggestions for new options for the -w parameter?

[Argh]

Hmm. Maybe more smoothing functions? The current smoothing algorithm (the lowpass filter) is alright, but not super, and doesn't seem to take relative distances of final objects into account- iow, if your final heights are going to be really far apart, it doesn't smooth enough, whereas for small differences, it smooths too much. That's about the only thing I can think of, frankly. This is already a far-better tool than the previous versions, by a very wide margin...

[user]

ok, i made a smoothing function, at version 0.6, it is documented in the readme, but it is currently not working properly, i just found out how lowpass works, i will to remake the lowpass filter.

the old lowpass filter, all it did was smoothing by a fixed value, allways the same, i will make it now take a value and smooth it based on the value.

the old one worked like this:
for every value in the heightmap x,y, it will check a 4x4 block around it and see if it is a steep slope, if it is it will take every value in that block and lower by a certain number.

the new one will loop x amount of times in a bigger block.

but i will first finish my urban map.

[user]

i am working on smoothing right now, but, what exactly to you want it to do?

currently it will apply a new smoothing algorithm x amount of times, x is specified by the user.

[Argh]

I think that the main thing it should do is have a way to adjust it for height differences- i.e., a way to shut down smoothing, if distance < whatever, but smooth if distance > whatever, or the inverse. That'd give a bit more control over the final result of the smoothing. This is all just bells-and-whistles stuff, though, no need to spend a lot of time on it unless it's very easy...

[user]

i am making a new algorithim for smoothing, still testing, lowpass wont
be removed.

what the new one will do, is smooth slopes based on a 7x7 block around it, and based on the heights.