The "What Are You Working On?" Thread

[garyjpaterson]

Just a quick showroom preview, showing the animations and skins.

 

[LilSki]

I would be absolutely amazed if anyone guesses what track this was.

Just toying with the idea. Not sure if or when I would build it. It is an interesting idea to re-build a dead track from lidar. Track closed in 1965. Only section missing completely is where the baseball field was built soon after it closed. But I have a 1963 aerial that has the complete track.

 

[NightEye87]

Just a quick showroom preview, showing the animations and skins.

Do I spot ram-air intakes? Looks marvelous!

@LilSki The shot from the lidar data looked familiar, but that aerial shot doesn't match what I had in mind

 

[Ben O'Bro]

In the meantime, I'm looking to reduce my .kn5 size a bit - anyone have any tips for .DDS formats or anything? I don't think mine is best optimised, using DXT5 for the most part.

Kunos does actually use png files sometimes for non-square textures, don't ask me why.

in ksEditor when you try import a none squared image, it tells you something about accepting DDS only in square images (and multiple of square 2)
you guys also told me not to use png, which made me a little sad

i did some tests between formats, see below:

two scenarios.
one _body with detailed texture, and one full yellow map, all in 1024*1024px.
You can see the png is unbeatable when it comes to compress a bunch of similar pixels (yellow.png being 20ko instead of 680 in dxt1 or 1366 in dxt5!)
It seems the dxt5 and 3 are proportional to the number of pixels in the image, disregarding the content.
Same with dxt1 is somehow proportional to the pixels, but half the size of the dxt5 (mostly because no alpha is stored) - and if detailled map, equivalent to the png in size.
Maybe i missed option, but dxt3 & 5 seems similar in size

Since the beginning i haven't been paying attention to formats at all, i have almost everything in png at the moment... the conversion will be painful.
When i checked the maps for the Academy, the kn5 file is 190mo... and that's due to huge maps all in dxt5 i guess, so nothing is compressed!
My kn5 is 22mo at the moment, but not much DDS... i guess the DXT1 will be my new friend

 

[AccAkut]

PNG will be internally converted to dds by AC on loading, and without compression. So a 4096x4096 will become over 70 mb in texture. The Bentley GT3 mod has this problem, it's using only high res PNG atm.

Guess Kunos also goes this way to keep their initial kn5 size under that size limit they use (40 MB?)

 

[Gergo Panker]

At the moment only some random tiny textures are kept png (but to be avoided anyway), some really old cars suffer from unconverted pngs but in general, it's better if you convert them yourself. Use DXT5 on larger textures but a lot of the times keeping resolution low and using 8.8/8.8.8/8.8.8.8 (depending on alpha requirement) works much better.

 

[Epistolarius]

It does help understanding what DDS is, definitely. Not an expert and I don't know where the official documentation is supposed to be so I don't know if it's 100% accurate but this seemed like a nice explanation:

What are DXT and DDS?

DXT is a set of compression algorithms or codecs applied to raster/bitmap images. The set is also known as S3 Texture Compression (S3TC). They all convert 4x4 blocks of pixels to either 64-bits or 128-bits depending on the codec. All are lossy algorithms. The original codecs were created by S3 Graphics, but many non-encumbered alternatives exist now. There are many different codecs: DXT1, DXT3, DXT5, etc. I'll talk more about them in a moment.

DDS (Direct Draw Surface) is an image file format, rather like a container for storing image data compressed using one of the DXT codecs. It was developed by Microsoft and introduced with DirectX 7.

Together, a DDS file containing data organized using a DXT code creates an image file that can be used in most graphical applications, at least those that support DDS natively or via a plug-in. DDS files are very common in the game industry, where advantages in loading speed and video memory savings outweigh disadvantages.

How does it work?

DXT sees images as collections of 4x4 blocks of pixels called "texels". For every texel, DXT selects two colors from the texel, each determining one end of a color range of 4 colors. The middle two colors are interpolated. The sixteen pixels of the texel are then assigned a 2-bit index (0-3) that maps them to the color range. The two representative colors are stored as 16-bit RGB values (5:6:5). So each texel requires 2x16 bits for the colors, plus 16x2 bits for the indices, giving a total of 64 bits for each texel, which equates to 4 bits per pixel. So for any set of images having the same dimensions, compressed size will always be the same.

What if the image has an alpha channel? How DXT handles this depends on the codec used. In DXT5, the alpha channel is encoded using a second set of 64 bits for each texel. DXT5 stores alpha information in a way that is almost the same as color information. Two alpha values are selected and used as the extremes for a range of transparency values. The alpha values are represented by 8 bits each, and the range indices by 3 bits each, allowing for gradients of up to 8 shades.

DXT3 handles the alpha channel a little differently. Each pixel gets 4 bits to represent its alpha, for a total of 16 unique values of transparency. This allows the alpha channel to be represented more accurately than DXT5, but with less subtle transitions.

So, for an image with no alpha using DXT1, compression results in an image using 4 bpp (bits per pixel). For an image using DXT3 or DXT5 incorporating an alpha channel, the requirements will be 8 bpp. Note that the actual image size will likely be larger, as it will frequently include mipmap data.

What are the advantages of DDS files and DXT compression?

Fast load times. DDS files are ready to be used by the graphics system and can be read straight into graphics memory with little overhead. In situations where many files are being constantly swapped in/out of the graphics unit, this can be a substantial savings and can reduce "lag", especially with big texture files.

Mipmaps can be pre-generated and included in the DDS files. This is another savings in load times and gives the graphic designer control over mipmap construction. More on mipmaps in a moment.

Data remains compressed in video memory. All image formats except DDS/DXT are loaded into graphics memory in flat, uncompressed state. (And uncompressing them takes time and resources.) DDS/DXT files remain in their compressed state in video RAM, using special algorithms on the video card to retrieve data on demand. Compression ratio is 6:1 if no alpha channel is used, or 4:1 if an alpha channel is used. This can result in huge video memory savings.

What are the disadvantages?

DXT codecs are lossy. What is stored as compressed data is not the same as the original image, and on a fine level it may not even be close. Images with high contrast regions such as print or cartoon-like colors and borders will likely generate visible artifacts, particularly with smaller resolutions. For this reason DXT can be problematic when used with normal maps, though there are work-arounds. I'll come back to this issue. Never use DDS files for editing and archiving.

The compression degrades the original colors. It is not a good format where retention of the true color is critical, particularly in those situations where fine differences may have a large impact. DXT generates images using a 16 bit color depth. Where formats like JPG or PNG use 8 bits per channel per pixel (RGB 8:8:8) for a 24 bit color depth (32 bits with PNGs having an alpha channel), DXT reduces the spectrum down to 5:6:5 bits using an interpolation algorithm to arrive at the new color values. In short, you lose much of the original color range. But many graphic applications in games and sims don't require tight control over the colors, and good choice of color palette can eliminate any visible results of this DXT effect.

File size on disk can be large for DDS. For example, a 1024x1024 image with an alpha channel and mipmaps will result in a 1.37MB file. But file size is a relatively small consideration these days. Game/simulation performance matters far more.

...

http://www.buckarooshangar.com/flightgear/tut_dds.html

Basically, better performance with DDS as there's no need to decode, compatible GPU able to work directly with compressed DDS vs having to decompress, storage space vs compression. In the end you really only want to use DDS in (video game) production.

 

[formulaHEINE]

SuperBowl 51 Corvettes looking good ingame. Only suits & pit textures are on the list. I think i will hit the button tomorrow.

 

[LilSki]

 

[Andreas Knöpke]

[x] INTERESTED!

 

[The-IC]

Wakefield Park is still on track, I just had an itch to scratch...I jump from project to project all the time, I seem to get bogged down at a certain point if I stay on one thing too long, dunno if that happens to anyone else...

 

[Fat-Alfie]

Smooth!

I jump from project to project all the time, I seem to get bogged down at a certain point if I stay on one thing too long, dunno if that happens to anyone else...

I used to jump around from project to project too, but when I started Thomson Road I promised myself I would work on it until it was complete, and it really worked for me. Once the initial track was laid and I could drive on it, I fell in love with it more and more. If I got bogged down with texturing, or asset making, I would drive the track for a few days (rather than starting something new). The more I drove it, the more I loved it, and the more I wanted to finish it - it never really became a chore

 

[mantasisg]

@LilSki It is Vineland Speedway I knew there has to be a connection with NJMP

 

[LilSki]

@LilSki It is Vineland Speedway I knew there has to be a connection with NJMP

Haha it is indeed! It is only 5 miles or so from NJMP and is in the same lidar data set.

 

[mantasisg]

It does look like mini old Hockenheim though @Sergio Loro

 

[LilSki]

It does look like mini old Hockenheim though @Sergio Loro

It's a small little thing at 1.5 miles. It looks like they planned some sort of extention right after T1 (you run the road course clockwise). It doesn't seem to have a whole bunch of elevation changes which isn't really my style. But I think it is worth at least a basic layout test to see how it drives. It does have a final banked turn which seems to be my thing lately

Plus it could be fun to run around the .5 mile oval.

 

[Sergio Loro]

there is a bunch of forgotten great american racetracks, i think is a great ideal that Lilski provide us this gems

 

[formulaHEINE]

Final approval has been given by the pitcrew.

Download is ready in the next 20 min.
---
Hit the download here.

 

[AccAkut]

I almost kaputt-optimized the Audi's suspension...Just wanted to adjust it to fit the 3D model a little better, just a few centimeters here and there, but result was ~45° KPI, car was snaking like mad at speed, literally undriveable. So reverted it

I also again cleaned the setup.ini too late. It had gearbox settings in it that always overruled the drivetrain.ini. Car now gets up to speed faster, 300 on Mantorp straight are almost doable.

@formulaHEINE you sure are enthusiastic about those teams, I never heard of them But those skins look nice

 

[formulaHEINE]

@formulaHEINE you sure are enthusiastic about those teams, I never heard of them But those skins look nice

More about the sport in general. A bit untypical for a german guy to cheer for American Football, but the great coverage by the german TV station and action packed sport do the trick for me.
Would have loved to see the Green Bay Packers at the superbowl, not only from a skin-designing point of view.