The construction field

[tcq]

A good compromise could be 40x40 grid. It extends building field by 8 blocks in every direction. Calculate:
Right now the plan is to make a 32x32 grid = 100%
With 40x40 it would be ca. 156%. It takes additional 50%, but I hope it is still not that much.
With 45x45 (TMUF environments) field is widen nearly twice (198%). It might be too much.
With 64x64 it is 400% of original field. It is way too much as Nadeo said.

Dunno, but aren't you guys missing this post here?

The 32x32 is better for the 'octree' than using inbetween power of two size, so we optimise also like this (instead of selection another dimension between 32 and 64) and if we move from 32x32 to 64x64, it makes 4 times more blocs on the ground (1024 to 4096) Then if you want to fill 3000 additionnal spaces to have your scenery 'not flat', the bloc costs too much for this on Canyon. It may create trouble in memory as well for the 2 Go 32 bits limit, or a least make it too difficult for small configurations.

We have then decided to go with 32x32, like the first TM and stadium. We feel it safer to start with even if I recognize that having bigger construction field is cool. We even developped a special technology to optimise it for 64x64, but I still feel it too risky to do it.

There is either 32x32 or 64x64 and nothing in between, because you save the date in binary code and from a programmers point of view it would be a loss of memory if you don't use the 64x64 but a grid >32x32, because you don't fully exhaust your reserved memory place.

And to be honest, i never had a problem where i had to stop my building process because of there wasn't enough place but because of starting on the wrong place of the map. Therefore i think the new copy/paste will solve everything.

[CraxX]

And to be honest, i never had a problem where i had to stop my building process because of there wasn't enough place but because of starting on the wrong place of the map. Therefore i think the new copy/paste will solve everything.

absolutely right tcq. i mean 32 x 32 is more then enough to build a marvelous track. and with the new copy-paste-thingie nobody will complain of to less space anymore. if there are still some, turn on your creativity - the most important thing in tm.

[fastforza]

Well said craxx!

[haenry]

agree

[Solon001]

I'll have to agree with Kakkoii, I don't believe that limits should be capped, but however, just as servers in TMNF had limits based on skill levels etc, there should be server limitations set by the server owners. so for instance if i owned a server called 001. In TMF i'd have servers like

001 | 0-50K
001 | 50K-80K
001 | 80K +
etc

However in Trackmania 2 I'd have servers more like

001| 0-50K LE
001| 0-50K HE
001 | 50K-80K LE
001 | 50K-80K HE
001 | 80K + LE
001 | 80K + HE

HE = High end - Maps that are most suited for High end machines, Examples include the High poly, custom mod/textures and intricate lighting methods.
LE = Low end - Maps that are available for any type of machine, original sized maps that aren't exactly special graphically, use low end mods and simple lighting methods.

So yeah, to all server owners who want to include high end maps, just make a high end server (maybe include a checkbox to exclude any server that include high end maps?

Anyway this is just my idea, and also is done in a way where it's fair for all, if people want to make seperate servers for high end maps, it'll obviously cost them another server but well, that's the way it goes. otherwise they'll just not include high end maps to welcome all, or include the high end maps in the hopes that it doesn't deter people.

P.S. My choice for ranking dividers aren't based on experience, I do not own any servers and can't see me doing so in the foreseeable future

[Alter-Fox]

I may be completely wrong about this, but I don't think a more complex lighting method would be a problem at all for low-end machines.
From what I understand, because lightmaps are pre-calculated and then just loaded as part of the with the track, it doesn't cause much of a performance hit if you turn the lighting detail up a notch when you play the track. It loads the lighting as part of the track, so it doesn't have to do any lighting calculations while the track is running (except for visibility I guess). I don't think the lighting adds nearly as much complexity to a track as you would get from, for example, lots of high-poly custom blocks... though I guess when complex lighting is combined with track complexity then it could start to be another issue.

By and large though, the real performance hit from lightmaps comes when they're being calculated (i.e. on the computer where the track is built). I've heard of situations in a project I'm collaborating on (as music composer, not level designer) for another game, where a map would take a week to a month to compute the lighting for. Heaven forbid the computer crash during that time (that actually did happen twice so far in this project, I think).

AFAIK the only environment in TMU that uses lightmaps is Stadium, the other environments use a form of real-time lighting I think. TM2 is going to use lightmaps (this has been said by Hylis in several places).

As for lightmap complexit... Personally I think lightmap complexity should be a player-side option, not something the track author would choose when making the track. The track should include lightmaps of each complexity level -- or each complexity level up to the one that the track author has enabled player-side, in order to actually save a track on a low-end PC. I suppose in this case, the lightmap would be computed player-side if the player has a lightmap detail setting higher than the one that the track author had enabled.

[Trackmaniack]

Okay...so now I'm confused. The lightmap data is going to be sent -with- the track upon DL, rather than having to be recalculated each time? I don't think that's going to be a big memory hit, so if I've got this right, this should greatly speed up track build/load times for all but the initial compute on the building computer, right?

[tcq]

I can't remember where i read this (not even sure if i read this ^^), but i think the map will contain data for all different shader levels and it will select the shader you are using.

[POBmaestro]

Okay...so now I'm confused. The lightmap data is going to be sent -with- the track upon DL, rather than having to be recalculated each time? I don't think that's going to be a big memory hit, so if I've got this right, this should greatly speed up track build/load times for all but the initial compute on the building computer, right?

Correct

When the track creator has finished building their track they can save all the shadows into the track so they don't need to be calculated by anyone else again. If you have lower settings selected then these will still apply, regardless of the settings used by the track creator.

[Trackmaniack]

Sweet Thanks for clearing that up, Pob