If you use l3dt ----->>

[mufdvr222]

http://www.bundysoft.com/news/doku.php? ... 007:jun:30

[hunterw]

If my eyes don├óÔé¼Ôäót deceive me, the texture for Small Divide appears to have been made in Terragen.

aaron is correct

interesting developments for l3dt - i think it may bridge the gap for those not patient enough to learn all the annoying little details of mapmaking

[Atorpy]

Hi All,

The Spring plugin is included with the latest developmental build of L3DT Pro. If any mappers would care to try it out and give some feedback, it would be most appreciated.

Firstly, the plugin should be able to import existing Spring maps using the 'Extensions->L3DTio_Spring->Import SMF' option (this will also load the SMT). It doesn't handle SD7 archives yet, but that's on the to-do list. I've verified that it works with Small Divide and Mars, but I've not tried more sophisticated maps yet. I'm not sure how useful map decompiling will be for most users, but it's certainly helped me in debugging the SMT/SMF export code.

Okay, as for creating a map with this plugin:

For the purposes of a quick test, I recommend you make a 512x512 heightfield. The SMT compression is really slow, so small maps should be used until it's fixed. When you generate the attributes map and light map, make them 4x (faster) or 8x (better). When you generate the texture map, make it 8x (for speed, set the anti-aliasing to 0 or 1, and for quality 4 or 8 ). The texture map must be 8x the heightfield, as it is in Spring. It is not necessary to re-size the heightfield to add the extra pixel border.

Okay, then to make the other maps for Spring, use the 'Extensions->L3DTio_Spring->Create spring maps' option. This will create empty metal/type/vegetation maps with the correct sizes for Spring. You can view them using the 'View->Show map' option, and they can then be edited using the 'Edit' toolbar button. The brush tool is quite crude at the moment, but I'll tidy that up in a future release. At the moment these maps all display in the window as greyscale bitmaps, but I'll add an indexed colour mode for viewing the type/vegetation maps. Once you're done with the maps, use the 'Extensions->L3DTio_Spring->Create minimap' option to generate the minimap. Finally, to save the SMF and SMT files, use the 'Extensions->L3DTio_Spring->Export SMF' menu option. Note that in the current plugin, the DXT1 algorithm used for the texture compression is insanely slow (it might take 10 minutes to export the SMT). For the release version I'll change to a compression library that is hardware accelerated.

It's probably also worth noting that the SMT export does not have the 600MB size limit of MapConv. Thus, it should be able to export textures up to 2M x 2M pixels (L3DT's mosaic limit).

Anyway, the user interface for the plugin is still really rudimentary. I plan to add a nice 'File->Export->To Spring...' menu option and dialog once the rest of the plugin is going properly. I also need to add support for features/types/vegetation, and also do something with the SMD (suggestions?).

Feedback is most welcome!

Cheers,
Aaron.

[mufdvr222]

Many thanks Aaron, this is just what a lot of people have needed
Could you post a link to that dev version I can`t find it on your site.

[AF]

I also need to add support for features/types/vegetation, and also do something with the SMD (suggestions?).

Some mappers talked of using the lua gaia feature in the next version to place features (which means unit features with scripts and animation or basic unit AI are possible). This would allow ingame feature palcement and editing without recompiling the map.

Also, wheeras mapconv has a 600Mb limit in texture size, there is a limit within the map format itself that prevents map sizes past 62x62 iirc.

Also have you look into the sm3 format? Now you have an sm2 exporter it may be worth looking into sm3, especially considering it is much closer to l3dt in that it uses blend maps and texture splattering instead of compiled images broken into tiles. It also has no upper limit to mapsize(the limit is the amount of ram you can spare).

[hrmph]

wow this is too cool.

[Atorpy]

Hello,

The dev build is currently only available on the restricted downloads page, which is available to users who have registered for a trial of, or purchased a licence to, L3DT Professional (if you have done so, please consult your reg/receipt e-mail for the link). If you would like to register, the instructions are here.

Also, whereas mapconv has a 600Mb limit in texture size, there is a limit within the map format itself that prevents map sizes past 62x62 iirc.

Thanks for the heads-up; I'll add a warning message to stop users if they make maps larger than this. I didn't see an obvious limit in the format itself, but a limit of 62x62 map units sounds a bit like Spring has limit of less than 32768 x 32768 texture pixels (62x62 is the next step down from having 32kx32k texture pixels). Can anyone confirm this? I'm currently generating a 64x64 map to test, but it's going to take a few more hours...

Also have you look into the sm3 format?

Yes, an SM3 plugin is also on the to-do list. It's a much simpler format, but it requires a more complex user-interface to set up all the layers. By the way, is there a limit on how many layers you can use in SM3? L3DT typically uses 15+ layers to generate the texture, but I'd guess that would be a few too many to be used in runtime graphics.

Cheers,
Aaron.

[Forboding Angel]

NOOOOOOOO!!!

The map format itself does NOT have a limit.

AF is thinking of the baseline jpeg limit which is 30kx30k

The smf map format has no limit except hardware.

[mufdvr222]

I found that email link Aaron,, forgot I actually purchased a license from you late last year.
With regard to sm3, I think most games that use a similar map format to this have a max of 5 layers, it probably varies but thats the case in Supreme Commander for example.

[AF]

NOOOOOOOO!!!

The map format itself does NOT have a limit.

AF is thinking of the baseline jpeg limit which is 30kx30k

The smf map format has no limit except hardware.

No, the sm2 map format has an upper limit so said SJ back when the format was first introduced, he said that the upper limit was raised from 16x16 to 62x62 or 64x64.

IIRC it should be possible to compile a 70x70 map with mapconv but spring wont like it and theres no telling wether the map itself would eb valid or not.

[Neddie]

I believe Spring can handle an arbitrary amount, as controlled by the Setting program in the Windows version, but I may be wrong.

[AF]

The settings program under windows has nothing todo with map sizes.

And onyl sm3 has arbitrary limits imposed by the ram available.

[Tobi]

I can not find any hardcoded arbitrary limits on SMF map sizes except amount of RAM, amount of video RAM, and the number of bits that fit in a signed integer.

[Neddie]

I believe Spring can handle an arbitrary amount, as controlled by the Setting program in the Windows version, but I may be wrong.

I was talking about SM3 texture levels.

[Tim Blokdijk]

sm3 is still experimental afaik, beta at best and the worst part is that Jelmer dropped it from his todo list as he likes to code on command engine for the time being.

You would have to finish the implementation in the engine.. But then again.. it would allow you to define the format in such a way that it would match 1on1 with with L3DT capabilities. Could be interesting..

[jcnossen]

Yeah, better just use SMF.
My problem with SM3 is that making it fast enough to compete with SMF requires a lot of refactoring and rewriting. Spring's sm3 renderer puts the blendmaps in texture units. If it would combine them with the vertex buffers then it would probably be a ~80% speed bonus.

And the ATI bugs are very annoying too.