![[de]](/mwf/flags/de.png "Germany")
Couldn't decide whether I put this into Off Topic or Art Workshop. Since these wall textures might be used for us - even if just for inspiration, here they are...
I have used your inspiration and textures to make a new brick texture and thought about leaving the old rectangular brick shapes. They fittet good in CR, but I think OC needs something more "detailed" and intersting, when you look at it in higher zoom levels.The following example is such a non rectangular Bricktexture made of these images. But it doesn't look very well when we just display it in rectangular blocks. What about making the borders of the material fit the borders of the bricks in the texture? The second image is made from a MapZoom 1 version of the map. The borders of the brick material where adapted with a mask to the texture borders. (this was done using a simple python script and some hand polishing afterwards).
What do you think about it?
I have to admit that it doesn't currently work very well for walls cause the bricks are all more horizontally aligned. But there a different texture for walls could do the trick. A method for adapting the borders would then have to be implemented in the engine.
I hereby license the following file(s) under the CC-by license
That sounds like a pretty good ideaIs the texture information already present and accessible when generating the landscape?
![[gb]](/mwf/flags/gb.png "United Kingdom")
Present yes, but less accessible in the sense that the algorithm doesn't depend on texture information so far. You'd have to use the usual global variable hacks.
My spontaneous thought was that an easy stab into this direction might be to generate a few "ChunkyRandom" variations in C4Landscape::DrawChunk and C4Landscape::DrawSmoothChunk and check them for compatibility (like make three examples, pick the best one?). That might be enough to give us a rough approximation of what Randrian had in mind.
My spontaneous thought was that an easy stab into this direction might be to generate a few "ChunkyRandom" variations in C4Landscape::DrawChunk and C4Landscape::DrawSmoothChunk and check them for compatibility (like make three examples, pick the best one?). That might be enough to give us a rough approximation of what Randrian had in mind.
The algorithm does have access to the material (it knows the shape, for starters). We could just load the shape texture - the green one on this case - into the same structure and there would be access to it.I'd say C4Landscape::DrawChunk would just take the shape texture, and instead of drawing a random shape, it would draw something like the smallest shape possible that only has borders on the green area in the shape texture.
Sounds interesting enough for me to have a look in the code again :)
Well, yes, maybe I phrased it strangely: It's "just" introducing a data dependency into a pass that so far hasn't had it.
Given that that's possible, of course. It might be very possible that you can't reach any green pixel from your start point. Plus I would like to keep the randomness in there.
> it would draw something like the smallest shape possible that only has borders on the green area in the shape texture.
Given that that's possible, of course. It might be very possible that you can't reach any green pixel from your start point. Plus I would like to keep the randomness in there.
How could you not reach a green pixel? The algorithm I used did just itereate over the pixels and fill the area around it till it reaches a green border. Might not be the best possible one. It could also try to reduce the pixels if less then half of the "brick" is filled by the Map.bmp Material.About the randomness, how would you keep it in there? My proposal was a static one. Like the old rectangular bricks. Either you had a brick or not. Nothing random about bricks. Here we could perhaps make the materialborders only roughly folow the brickborders and introduce a random sloppyness for the "fit". That would make the algorithm a bit more compilcated I think.
Well, we have what the map says. If we diverge from that more than one map-pixel we aren't doing a good job translating the map. So we can always only search something like a $zoom x $zoom environment for a green pixel.
And even with bricks you have some room for randomness. After all, you have to choose which pixel to use for the polygon. And we can't get around chopping bricks in half now and then (see above), so I don't see why it shouldn't be allowed to happen randomly now and then. I would see your green texture more like "hints" for where to place chunks. From the map zooming point of view, that'd make more sense to me.
But well, that's just how *I* would do it. If somebody else does it, they might use a different solution.
And even with bricks you have some room for randomness. After all, you have to choose which pixel to use for the polygon. And we can't get around chopping bricks in half now and then (see above), so I don't see why it shouldn't be allowed to happen randomly now and then. I would see your green texture more like "hints" for where to place chunks. From the map zooming point of view, that'd make more sense to me.
But well, that's just how *I* would do it. If somebody else does it, they might use a different solution.
Ok, you are right about the $zoom x $zoom environment. If we disrespect that designing maps would be difficult.Why have we to choose pixels for a polygon? We have (till now) a pixel based landscape, so we can directly use the pixels of the border. And yes, we probably have to think about solutions when the "brick" doesn't fit in. So a good heuristic for cutting it would be nice. But that would probaly have to be more complicated than a simple straight cut. That probalby wouldn't fit the "round" eges of the bricks.
Well probaly these cuts could be done by the texture designer in advance. One could paint "minor" eges in the mask. And the engine could give out a warning if the chunks of the texture are too big.
>If we diverge from that more than one map-pixel we aren't doing a good job translating the map.
Depends on whether the map designer can decide (=Landscape.txt attribute) if he wants to use those textures or not. Because when he can decide that, it's up to him whether he uses this feature in places where accuracy is important.
Or he could even prevent it on his own, using another overlay-entry
Well, the way I would do it at the moment, would be this: Upon loading, convert the mask texture to a set of polygons e.g. using potrace. Then, whenever a chunk needs to be drawn, draw all polygons that overlap the chunk.This would always draw at least the square covered by the chunk; usually more (same as the current algorithm is doing). In some cases where the bricks are large, it would draw way too much. This is alright. As a map designer, when you are using materials that have a shape texture, you must be sure to place them somewhere where an overlap of x pixels does not hurt (where x is the maximum brick shape size). For narrow passages, either use a different texture or make sure that a path is free. As long as you keep the same map zoom, the algorithm produces the same results so I don't see a problem here.
That's about what I had in mind.If the designer uses the developmode in clonk, he directly sees what he gets when he draws an additional map pixel and can use another texture (e.g. a smaller brick texture) if the brick doesn't fit in the design he intends to draw.
Btw. do we alrady have something like bumpmaps? That could be very good for bricks.
I like the texture and I even more like the idea of a 1-bit "Texture mask" for irregular textures. This goes into the same direction as my proposal to be able to create material from object graphics (var crys = CreateObject(Material_Crystal,x,y); crys->Shape(Random(5)); crys->ChangeToMaterial("Crystal"); )The texture has too much contrast though, some areas look as if they are in the background, other are so bright as if a floodlight is lighting it.
Regarding the implementation however I think it might be lot of work to create an algorithm that actually "follows" the seams of this texture mask (and of course the actual map.bmp information.
Update for the texture. I made a more uniform lightnig:I hereby license the following file(s) under the CC-by license
I think the lightness of one and the same material should still be the same everywhere. Do you see the black hole below that stone that is two times in the texture (the other one is at the bottom and flipped)? There should be stone there because "black" could be anything. I'd also lighten up the other dark stones to the same level as the bright stones because there should be a clear distinction between solid textures and background textures.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
