If the ground of the autocross area would use one, large texture, instead of looping a few small squares over and over again it would be possible for the autocross layout designers to create some very intricate tracks.

The .lyt files could, for example, have a header flag (with a file name?) which would enable the custom autocross area ground texture (which could be downloaded by the client IF they'd like to use it--If the file doesn't exist LFS would use the default, repeated textures(.

Unseen came up with another solution:
Lay down an outline on the autox area, and lfs would draw anything outside that area in a grass texture, anything inside would be the track texture. That way it would use the standard texture all over, and only overlay the grass texture (or one of a range of alternate textures) would be a lot easier, and less hassle than the download option.

Spare me your +/-1s. Thanks.

+1 cause I cant find my thanks button.

-1 to unseen's solution, will take up too much time to program.

Quote from Mikkel Petersen :

-1 to unseen's solution, will take up too much time to program.

+1 for the -1.
I will requier a complet retexturing of the AU1 wich is quiet not usefull since most of people drive on real tracks.

The whole thing isn't feasible; your original suggestion would make memory consumption go sky high in no time. Just think about it for a second. Normally you have one, lets say 2048x2048, texture loaded into memory which is repeated again and again. This uses a total amount of 4MB uncompressed. Now what kind of texture would you need to cover the whole area? A quick look shows that the longish part of AU1 is about 11x48 texture squares, which would result in a texture that is 22528x98304. A whopping 2GB.

The other idea, while much better on memory consumption, is too complicated to do and IMO not really worth the effort.

So I guess -2 it is.

I think it would be nice to be able to spray paint custom lines on the autocross arena. Wouldn't take up too much memory either.

Quote from AndroidXP :

The whole thing isn't feasible; your original suggestion would make memory consumption go sky high in no time. Just think about it for a second. Normally you have one, lets say 2048x2048, texture loaded into memory which is repeated again and again. This uses a total amount of 4MB uncompressed. Now what kind of texture would you need to cover the whole area? A quick look shows that the longish part of AU1 is about 11x48 texture squares, which would result in a texture that is 22528x98304. A whopping 2GB.

The other idea, while much better on memory consumption, is too complicated to do and IMO not really worth the effort.

So I guess -2 it is.

I agree with you, mostly..

The 2gb is slightly off! But ill just agree!

Whops, what I meant was that it would be a 2 gigapixel image, which translates to an uncompressed size of 2 gigapixel * 3 bytes for RGB = 6GB. Then depending on whether you use DXT1 or DXT3 compression, you might get this down to 750MB - 2GB. Still nothing to even remotely think about

why not having it in the autocross area. position grass areas would be slightly easy there to make. as it is now with lines and everything.

Quote from AndroidXP :

Whops, what I meant was that it would be a 2 gigapixel image, which translates to an uncompressed size of 2 gigapixel * 3 bytes for RGB = 6GB.

GIMP says that it's 16.5GB when I tried to create an image that large. I am running it in linux. Only problem is, that my swap partition is alot less then 16GB. I am still trying to create the new image.

EDIT: My RAM is just about full, now switching over to swap space.

Ouch! I get the point. :dunce:

Quote from wheel4hummer :

GIMP says that it's 16.5GB when I tried to create an image that large. I am running it in linux. Only problem is, that my swap partition is alot less then 16GB. I am still trying to create the new image.

EDIT: My RAM is just about full, now switching over to swap space.

To be honest, I was just testing this with bitmaps, which are exactly 3 times the size as it has pixels. On dds files it probably also depends if you include the mipmaps or not, and you also have an alpha channel but then again some compression too

However:

Quote from felplacerad :

Ouch! I get the point.

The version I was thinking of would actually take up less memory than the current autox ground textures.

You have one texture layed down over the whole area, like grass or whatever, then you`d use the overhead view to plot out a path like you would in photoshop/gimp. When the path is closed the area inside the path is filled with a tarmac texture. That would be 2 textures in total. One less than is currently used.

After that, then you could lay the regular autox objects as usual.

By doing it that way, the track layout would be much easier to see, and you wouldn`t have to lay out the whole course using cones, tyres, etc thus leading to higher fps overall.

The problem of your idea is not the textures, but dynamically shaping the polygons to whatever "lines" you laid out, and doing it so that the fps do not suffer from something more complex than a rectangle track. It would be like a simple form of a map editor, but that also means you have to do LOADS of sanity checks to prevent the user from doing stupid stuff that would break the game, and it would create tons and tons of support issues and users begging for improvements, like for example being able to make elevation changes. Too complex and time consuming for something that the track editor, that will probably be released at some point in the future, will be able to accomplish too but in a much better way.

again, why are we not simply able to put down "grass" objects like we do it with the chalk objects?

And how would you shape them? Ok, lets say you have a rectangle and a circle of varying sizes. 1) The textures will never align properly. 2) You will have to use lots of overlapping areas to create more complex road sections. This not only creates ugly flimmering you can already see on the chalk lines, but also has a rather poor performance (ever tried doing a donut till it is black and see how your fps like it?). Adding to that it might or might not be easy to have these overlaying textures actually affect tyre grip.

And if you're talking about real *objects*, then the performance aspect is even worse and you have even more problems with overlapping and getting the shapes right.

I would think the trick would be to have resizeable "tiles", using the checkpoint width variable to determine the size of the tile. Grab yourself a 90 degree bend tile, change the size to the size you want.

just an idea anyway.

Quote from wheel4hummer :

GIMP says that it's 16.5GB when I tried to create an image that large.

Why has everyone assumed that it has to be a 1:1 mapping? Historically height maps tend not reflect anything like the size of the actual area it represents. So why should it in this instance? There's no precision requirement that I can think of for that kind of resolution.

Of course, the size of the texture doen't need to scale linearly with area of ground it is covering. For what is boing proposed, the current level of detail is overkill. I'd imagine a reduction of three (width and height, so memory usage down by a factor of nine) would still easily suffice. That and the autocross area isn't even a rectangle, so could perhaps be chopped into three or four squares (no stretching then) that actually fit the shape of the autocross area precisely, thus eliminating memory wastage and make the idea more feasible (though still unlikely).

did somone of you ever try to replace the autocross texture that is on the ground at the moment?

Why? Everybody knows what happens...

Quote from Fischfix :

did somone of you ever try to replace the autocross texture that is on the ground at the moment?

I have several times, and I`m currently making a couple of different versions for different projects.

can you send me one of your older ones if you still have them? just to see...