Materials.

[Helena]

Hello!

A few days ago I made a pack with materials and posted it to the Discord channel for TMT people.
Crowdpleased suggested me to post it here. I guess I should do so.

It is very simple and just consists of 5 different materials.

The zip file contain the pcugc files you should put in the TMT folder. Unzip it first!

Every object contain a lineup of 11 monkey heads. From left to right, 100% white to 0% (black) increments in 10 each. 100, 90, 80, etc.

So if it is Smoothness then it is 100% smoothness down to 0 (white to black).

All the lines have same order, from white to black.

To use this you need to at least know how to assign material and make material file and name it accordingly. I won't help you with that.


Ok, I was going to include a screenshot of the objects ingame, but my computer won't let the flashbased forum picture uploader work properly. At least the file worked!

This is just something simple I dabbled with and just a small selection of materials and I realize one or two of them might need to be stacked together with other materials to work "properly" but it is at least fun to see. At very least it is helpful for RN, SM and EM.

View attachment TMT.zip

 

[Crowdpleaser]

Hello!

A few days ago I made a pack with materials and posted it to the Discord channel for TMT people.
Crowdpleased suggested me to post it here. I guess I should do so.

It is very simple and just consists of 5 different materials.

The zip file contain the pcugc files you should put in the TMT folder. Unzip it first!

Every object contain a lineup of 11 monkey heads. From left to right, 100% white to 0% (black) increments in 10 each. 100, 90, 80, etc.

So if it is Smoothness then it is 100% smoothness down to 0 (white to black).

All the lines have same order, from white to black.

To use this you need to at least know how to assign material and make material file and name it accordingly. I won't help you with that.


Ok, I was going to include a screenshot of the objects ingame, but my computer won't let the flashbased forum picture uploader work properly. At least the file worked!

This is just something simple I dabbled with and just a small selection of materials and I realize one or two of them might need to be stacked together with other materials to work "properly" but it is at least fun to see. At very least it is helpful for RN, SM and EM.

View attachment 2732

Hey Helena i can help with uploading the Pictures

 

[Helena]

Thank you!

For the picture text:
Red row: Smoothness _SM
Blue row: Roughness _RN
White row: Emissive _EM
Green row: Glass _GS
Yellow row: Translucence _AL
Black row: Metalness. _MT

(the heads are flexicolor so you can change)

And what I meant with not properly used is probably the glass one, I guess it has to be combined with other to get the proper effect.

for better visualisation please place the files in your game.

 

[Crowdpleaser]

 

[stuk71]

Thanks Helena, very helpful [happy]

 

[corkscrewloop]

Hi Helena, very helpful picture and analysis, thanks!

One thing I noticed, I applied a *_RN texture (512*512 pixels - size 0.5 kbyte!) to one object to remove the shine it has with only basic *_BC texture...
However the assignment of the RN texture already enlarged the *.pcugc file by > 300 kbyte (plus 40%!!) ending up it being almost one 1Mb in size.

That is what I noticed:
Same object (cubic object with only 6 faces):

with *_BC texture (409 bytes)			*.pcugc = 380 kbytes
with *_BC texture (409 bytes)	with *_F1, *_F2 textures (2.8 kbytes total)		*.pcugc = 550 kbytes
with *_BC texture (409 bytes)	with *_F1, *_F2 textures (2.8 kbytes total)	with *_RN texture (409 bytes)	*.pcugc = 900 kbytes

All textures used are 512*512 pixels. BC / RN feature only one color. Even they are small, they impact the size of the TMT output obviously stronger than expected.

Any advice? Maybe the devs can give a recommendation what sizes are good to keep game performance.

Any feedback would be very much appreciated! BR, Corkscrewloop[happy]

 

[Helena]

Do not worry much about the filesizes. The mermaid from Planet Coaster example is around 18 megabyte large. That give us a hint about THEIR objects.

But if your object is small, let's say it is smaller than 1 meter tall you can make it smaller than 2048px.

512px is small enough.
If your object is solid in BC as well, everything solid floodfill type you can go even smaller. I have used 16x16 px.

 

[KickAir8p]

Do not worry much about the filesizes. The mermaid from Planet Coaster example is around 18 megabyte large. That give us a hint about THEIR objects . . .

That's partly a false equivalence -- it's true for the object's part of the filesize, but not the textures, because PlanCo's own objects use big texture atlases that are significantly easier for the program to load on startup and use during the game. Using individual textures, like the Toolkit currently requires, is well-known to be inefficient game design and causes significantly higher load while playing. And the fbx for the mermaid now available in the Toolkit's examples is barely more than a meg, the rest is textures. [blah]

 

[Helena]

When talking about an object I include the textures as such as without textures it is not a complete object.

Yes they do share textures across files, BUT in the mermaid case we can clearly see it is custom unique for mermaid (seeing the BC, ambient occlusion, normal maps and flexicolor masks all unique for that specific model, you can see the clear shape of the uv islands) and not really possible and able to share across to other files.

The filesize of fbx model is not what people usually talk about when talking about filesizes. It is the whole package deal. The end people, that is the subscribers of steam, look at the pcugc file, and talk about its size. That's what we talk about.

One friend (who was able to take a peek of the actual game content) shared with me about the golden treasure chest (of which is a rather small object, maybe max 1 meter tall). The internal files for that (yes from the ingame) is totally 6 megabyte large (if I recall correct) for that individual object + its own textures. This is the ingame content and unique for that object.

 

[KickAir8p]

. . . Yes they do share textures across files, BUT in the mermaid case we can clearly see it is custom unique for mermaid (seeing the BC, ambient occlusion, normal maps and flexicolor masks all unique for that specific model, you can see the clear shape of the uv islands) and not really possible and able to share across to other files . . . One friend (who was able to take a peek of the actual game content) shared with me about the golden treasure chest (of which is a rather small object, maybe max 1 meter tall). The internal files for that (yes from the ingame) is totally 6 megabyte large (if I recall correct) for that individual object + its own textures. This is the ingame content and unique for that object.

The point of a texture atlas isn't just so multiple objects can use the same textures (although that helps), it's to reduce fetches (how often the program has to read a texture file). Just because an object like the mermaid has a unique texture unused by any other object doesn't mean that texture isn't in a small patch of a much larger texture atlas in-game. This gives Frontier's content a significant advantage in game-load over what we can currently do with the Toolkit, and means the example files' filesizes aren't equivelent to what Frontier has in the game (aside from obvious differences, like the example mermaid having flexicolor maps and an icon image showing them in use while the in-game version isn't flexicolored).

All that's assuming that Planet Coaster is actually using texture atlases. It seems seriously unlikely that it isn't, both given that it's game-design best practice, and that the white-texture bug would've had to be the same mistake happening identically across multiple textures instead of on one. But if Frontier really does have their content set up so each object uses its own individual texture files, as your friend described, and the way they've got us doing it with the Toolkit, that'd explain a lot about the fps issues in scenery-heavy parks. [shocked]

 

[Helena]

Ooh you are right, atlas! Forgot that.

I gotta research this and return.

 

[Helena]

And for other people reading this wondering what texture atlas is: this is good example:
As you can see it is different textures for different objects but together in one image file:

The question is if Planco use this method or individual texture file per object.

 

[KickAir8p]

. . . The question is if Planco use this method or individual texture file per object.

Yep -- I was thinking that of course PlanCo uses this method (reasons here) even though the Toolkit doesn't currently let us use it, but Helena's got some info that indicates they aren't:

. . . One friend (who was able to take a peek of the actual game content) shared with me about the golden treasure chest (of which is a rather small object, maybe max 1 meter tall). The internal files for that (yes from the ingame) is totally 6 megabyte large (if I recall correct) for that individual object + its own textures . . .

Sorry if I was obscure -- I thought the phrase "texture atlas" would be googleable for anyone who didn't already know it, I didn't realize how easy it is to read it and just think it means textures like the Toolkit wants. [redface]

 

[Helena]

Got quick reply: Majority of the items are not using atlases in that way, but there ARE some, for example the build walls. If we are reading each other correctly.

Sure wish we could cross-link textures and to use atlases.

 

[KickAir8p]

Got quick reply: Majority of the items are not using atlases in that way, but there ARE some, for example the build walls. If we are reading each other correctly.

O.M.G!!!!!

I wonder why not? Easier for the art-devs, of course, but . . . wow, really? Yikes! [shocked]

Sure wish we could cross-link textures and to use atlases.

So do I (when I get back into it) -- initial features of the Toolkit are good for a first release, but there are improvements that would go a long way to alleviating bloat, including that one. [up]

 

[corkscrewloop]

Thanks for all the posts, its a very helpful and interresting discussion! I've seen now, that its not recommended to create a scenery object without shine information (_RN texture).
Even tough the RN texture I use is only a few bytes in size, the TMT enlarges the pcugc file by almost 40% / 400Kb in my case... Looks like we have to accept that...

 

[Helena]

Yes, that's life. That's how TMT works.

Remember, the game on disk, for me is 8.24 gigabytes.
So no wonder there's a lot of space taken by the textures.

I think we just have to live with it. Buy a new hard disk maybe. [haha] (Conspiracy! )

As for the game performance, do not forget the polygons/triangles, these do count as well, and it is not noticeable in file size but noticeable in fps drop if you waste those.

 

[Helena]

Again, there could be misunderstanding (about the atlas/linked use) so please do not take my words for a fact.

 

[Samplerocker]

hi. Can you show me the different textures to get tje effect in the picture with the monkeyheads?
Im a litte bit in trouble to understand the settings.
how do I get the differnts in all the materials from high to low? Maybe you can help.
specially the SM and the AL . Maybe you can give example textures?

 

[Crowdpleaser]

hi. Can you show me the different textures to get tje effect in the picture with the monkeyheads?
Im a litte bit in trouble to understand the settings.
how do I get the differnts in all the materials from high to low? Maybe you can help.
specially the SM and the AL . Maybe you can give example textures?

The intensity of the Effect is governed by a monochrome picture file. I am not sure at the moment if a white image is more or less intense, but this is basically how it works. Create a small grayscale picture called NameofMaterial_RN (example of course, you need to give it the name of the Material in Blender that is assigned to the Area of the Model you want to change) that governs the amount of the Effect applied.