For the SandDry (the old FlySand), which I want to rename to just Sand, using the Earth material with sandy textures instead of the former "Sand".
So if you dig sand, you get earth chunks, if you dig dry sand, you get sand chunks? That sand texture you posted here is not very good, IMO.
Is it possible to save the texture of the material for the Earth-Chunk? Currently we have 3 different earth textures (and I just added 2 more for shading, may very well change). Digging one earth and having it turn into after breaking the chunk would be quite strange.
No, this is what materials are for. A hacky solution would be to find out what texture the earth has at the point where the earth chunk was created und alter the graphic (+name+description) based on that wacky information. But currently not even that should be possible to find out (only the material).
Throwing an earth chunk and getting a part of this would be weird in it's own way...
We don't have a function to read which texture a material has, neither is that passed to the chunks which are created, but that should be relatively easy to do. (C4Object.cpp:2877) But you also need an extended version of InsertMaterial (C4Landscape.cpp:1256) to specify the texture (And probably of DrawMaterialQuad and some other functions). I don't see a reason that I couldn't do that, just a question: Should I pass around the texture names per String or per Index (by allowing script access to C4TextureMap::GetIndex)?
We don't have a function to read which texture a material has, neither is that passed to the chunks which are created, but that should be relatively easy to do. (C4Object.cpp:2877) But you also need an extended version of InsertMaterial (C4Landscape.cpp:1256) to specify the texture (And probably of DrawMaterialQuad and some other functions). I don't see a reason that I couldn't do that, just a question: Should I pass around the texture names per String or per Index (by allowing script access to C4TextureMap::GetIndex)?
The index is created automatically in the engine, isn't it? So it doesn't make sense to pass that around because it is more of an internal variable that can change anytime. The texture name on the other hand is not that likely to change. But still... why not have an own material for each texture?
Well, the material number is an internal value which can change, too. (With savegames, e.g.) We pass it around anyway, because it's a lot faster than copying a string every time.
> We pass it around anyway, because it's a lot faster than copying a string every time.
It isn't. The difference between a String and an Integer for this is in the noise, while the added robustness is significant.
Well, see it the other way: If you made a bunch of earth chunks from different sources and threw it all together, would you want the result to be a pixely intermingling of all the different earth kinds you used? From an aesthetical point of view, I think the newly inserted pixels should just adapt to their immediate surroundings.
That should be a straightforward engine change, as well. You'd just have to insert a bit of randomness so it doesn't end up producing hard lines.
That should be a straightforward engine change, as well. You'd just have to insert a bit of randomness so it doesn't end up producing hard lines.
You are confusing me. The landscape shader is coloring pixels all the time? Each pixel has a material and a texture, both can be pretty much chosen as you wish, as long as there aren't more than 127 material-texture combinations total. An earth pixel getting inserted could quickly check surrounding pixels and derive the texture to use from that.
Edit: This is what I mean.
Edit: This is what I mean.
Ah, okay. I thought you were talking about a random color like in the old SetLandscapePixel(). Textures are fine, of course.
The randomness I was talking about is that it shouldn't have a fixed order like always giving priority to material directly below, as that would produce a straight vertical line. With choosing randomly from pixels around as my patch should do, it should give you a more natural random-walk line when you spray earth over a texture switch. I'll probably test that later today.
I'm with Guenther and Caesar here. Textures should only show the structure of a material, i.e. variations in density. When dug out, this structure is lost and dropped chunks of earth all share the same texture.
Yes. You should be able to tell immediately which behavior the chunk of material in the Clonk's hand will exhibit once it hits the ground. And the behavior should be the same as the behavior the material had before it was dug out. This means two graphics, one for the stable Earth and one for the instable Sand. It might be cute to have different shades of brown for earth chunks depending on the texture at their origin, but the confusion that would cause is not worth the increased realism. Having different earth textures for the landscape is worth it though, because you're looking at the landscape much more.
As for using one material per texture, that's just unnecessarily complicates scripts. Unlike Clonk 4, we can have one material per distinct gameplay element and should finally reap the advantages of that simplification.
As for using one material per texture, that's just unnecessarily complicates scripts. Unlike Clonk 4, we can have one material per distinct gameplay element and should finally reap the advantages of that simplification.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill