Project Organization Thread

[Jupix]

Btw, I've attached a template.tar file with symlinks in it, so XP-users can make tars by adding ogfx directories to it (do not add trg* directories, else the symlinks will be overwritten, the ogfxe_extra directory/ openttdd/w link may have to be deleted, when a newgrf is made) with e.g. 7zip

1. Now that there is the "-extra" NewGRF project, will the extra directory never be used for anything in the future?
2. Have there been any other developments in the last few months that affect the layout of the template?

If "yes" to either or both, can you provide an updated template, please? Can you also make a parallel version that includes a root-level directory named "sources"? It would be used as an "official" tar template for the base set conversion project and other releases at the repository. (For anything anywhere else you could use the one without the sources dir if you want.)

[Jupix]

New documents at the wiki:
http://wiki.openttd.org/32bit_standard_tar_format - needs GeekToo's attention
http://wiki.openttd.org/32bit_base_set_ ... on_project

Also some changes regarding my own little pet projects.
http://wiki.openttd.org/32bit_automated_nightly_bundle
http://wiki.openttd.org/32bit_Graphics_ ... Repository - revamped and most content moved to...
http://wiki.openttd.org/32bit_Graphics_ ... ser_Manual

[maquinista]

I wil add in the wiki a section for crossings.

[Wasila]

I have recently rejoined the project as an administrator on Jupix's repo and have noticed that a vast number of projects are ready for completion; all they require is z1&2 sprites. Would anyone be willing to give some time up to get this task done so that we can release some more tars? If so, PM me and I'll point you towards some that require these sprites.

Thanks,
Wasila

[maquinista]

Doing it by hand is too long, It would be nice to have a program to make the z1 and z2 sprites from the z0 sprites.

This is not only to save it with the half size. Some empty lines must be added depending on the size of the sprite and the offsets.

• If the size of the sprite and the offset are even, the sprite could be scaled down without problems.
• If the size is odd and the offset is even, the sprite needs a new line at the end (right or bottom border).
• If the size and the offset are odd, the sprite needs a new line at the start (top or left border).
• If the size of the sprite is even and the offset is odd, the sprite needs two new lines, at the start and the sides.

Since OpenTTD can't handle quarter pixel offsets (and half pixel), We need to add these new lines when the offset cannot be divided by two. These new lines adds one to the offset value, making It divisible by two.

Remember that these rules are applied in horizontal and vertical. Also, this must be done in each downsample. I have attached a image that shows how to do it. I have downsampled the bridge sprites with this method.

Also, this is the reason because the coal mine z0 sprites uses offsets divisible by four. It's easier to downsample them to z1 and z2, because the size is also divisible by 4. PNG crop finishes the work, leaving only the not-empty areas. This trick can't be done with all sprites.

[Jupix]

Apart from the offset issue it's also important to preserve as much of the image quality and fidelity as possible. For this some manual labor has to be done and it's important that whoever does the resizing does not rush through it, otherwise the sprites will end up looking uglier. I'll quote Ben Robbins on editing the size of bitmaps:

[...] it's not a quick rescale. I did it for the grass for example but it took a long time. It was a combination of multiple resizing algorithms merged together, and then all multi-gradient sprites reassembled, and then pixel drawing to bug fix.

He also described to me some of the problems we're facing when "zooming out" from z0 sprites.

Small objects shrunk down become noise. In sprites made for z2 they do not appear at all. Ambient occlusion (soft shadowing in crevices) tends to undefined edges. Also edges get broken up and less defined in general. There is a greater need for contrast at lower zoom as each pixel in itself is more important, and there isn't space for gradual changes over many pixels.

Like he says, rescaling bitmaps is possible. However, you shouldn't do a botch job of it. That'll be in no one's interest. In the case of buildings and vehicles (and the like), where there are a lot of details, I'd prefer if actual separate models where made for the lower zoom levels where some of the details ("noise") were removed and then the sprite rendered at the correct size so that as little editing of the bitmap needs to be done as possible.

[Rubidium]

It's probably best to "ensure" that the initial "big" sprites have a width, height and offsets dividable by 4. That will make downscaling those values significantly easier and removes odd rounding issues.

[maquinista]

Apart from the offset issue it's also important to preserve as much of the image quality and fidelity as possible. For this some manual labor has to be done and it's important that whoever does the resizing does not rush through it, otherwise the sprites will end up looking uglier. I'll quote Ben Robbins on editing the size of bitmaps:

[...] it's not a quick rescale. I did it for the grass for example but it took a long time. It was a combination of multiple resizing algorithms merged together, and then all multi-gradient sprites reassembled, and then pixel drawing to bug fix.

He also described to me some of the problems we're facing when "zooming out" from z0 sprites.

Small objects shrunk down become noise. In sprites made for z2 they do not appear at all. Ambient occlusion (soft shadowing in crevices) tends to undefined edges. Also edges get broken up and less defined in general. There is a greater need for contrast at lower zoom as each pixel in itself is more important, and there isn't space for gradual changes over many pixels.

Like he says, rescaling bitmaps is possible. However, you shouldn't do a botch job of it. That'll be in no one's interest. In the case of buildings and vehicles (and the like), where there are a lot of details, I'd prefer if actual separate models where made for the lower zoom levels where some of the details ("noise") were removed and then the sprite rendered at the correct size so that as little editing of the bitmap needs to be done as possible.

The problem is that doing it by hand is a lot of work. When I say a lot of work, I mean thousands of boring clicks and hundreds of hours.... I prefer to spend my time in new trains or add the new park by Antonio in the file with the new houses.

Maybe It could be interesting to apply a sharpening filter, or a little increase of the saturation.

It's probably best to "ensure" that the initial "big" sprites have a width, height and offsets dividable by 4. That will make downscaling those values significantly easier and removes odd rounding issues.

Is a good idea for new sprites, but It doesn't work when You have hundreds of finished sprites (trucks, train wagons...).

My latest sprites are coded in this way:

• Place the sprite (size: 512×512) in the screen.
• If the sprite doesn't have a offset divisible by 4, use the tool offset of GIMP or remove some lines of the sprite.
• Write the batch file for z0 level.
• Make a copy of this file for z1 level, and divide the offsets by two and replace "z0" by "z1".
• Use the batch processing plugin for GIMP and rescale the sprites, and rename them.
• Make another copy of the batch file with offsets, for z2.
• Rescale again the sprites with GIMP.
• Write all the offsets with the batch files.
• Use PNG crop to autocrop the sprites.

This is fast and easy, but It can't be used for current sprites. For example: It could be 5000 finished z0 sprites in Spain set. I prefer rescale them automatically and spend my time in new trains or finish the airport sprites.

[Jupix]

The problem is that doing it by hand is a lot of work. When I say a lot of work, I mean thousands of boring clicks and hundreds of hours....

You're right, it is a problem. But not doing it is not the solution.

I prefer to spend my time in new trains or add the new park by Antonio in the file with the new houses.

So you prefer doing something else. That's fine.

[Zephyris]

There must be someone around here who can write a gimp script to do this... Sadly the only image editing program I know how to script in destroys alpha channels...

[GeekToo]

I think that before even thinking of mass-rescaling, it's more important to have a more uniform look. I've said it before, and I'm repeating myself, but I think it essential to have a great set in the end, instead of a nice one. Some have said they think it more important to have a complete set first, and then improve things. I don't join that opinion, I think it's more important to have a consistent, high quality set to start with, and expand that.

Else all the efforts put in pngcodecing, rescaling etc would have to be repeated later.

As an example of what I mean, I've added the screenshot posted earlier, and my remarks about it, and I don't consider myself particularly gifted in judging graphics, more talented artists will probably find even more.

-red: very different textures for materials that are more or less the same
-green: pitch black shadow in the fountain, no shadow at the lamppost at all, medium shadow in other building
-pink: different levels of saturation for comparable material

[Ben_Robbins_]

Geektoo: A definite agreement from myself. Making matching z1-2's of a z0 sprite does require some assurance that the z0 sprite isn't going to be radically changed. It is always my biggest concern when spending a lot of time on z1-2's, or just adding gridlines to a set, that it will need to be redone. A tiny tweak to the z0 can cause a mass of work to it's derivatives.

I think, if a resizing script was an option, then this wouldn't really be an issue. It could just be resized in game. Maybe the resizing algorithm would require a little too much for resizing in game? The point is that resizing is quite a lot of work. But then, if not doing anything becuase there is a lot of work is a reason not to do it, then this project hasn't a chance.

The first thing to deal with is the shadowing. The other two points are comparatively minor in terms of fixing. We need an accepted opacity of black for the bulk of a shadow that we are aiming for. Comparing it to dmh's building would influence a softer shadow to the softer image. Best to compare it more to buildings such as Geektoo's terraced set in that image which are OTTD in contrast.

I had a sprite I had a test with shadows and windows with a while ago, which I didn't release. It was a simple cubed building with true white/black and colours on. I'm not able to get to it for a week or so, but I pm'ed/messaged it to Jupix a while back in a conversation, so if you would be able to post that here, that would be an example of what I concluded is what I'm aiming for shadow window wise, and would be much appreciated! (I can't find it anywhere I can get to from this computer)

[Zephyris]

The problem with lighting/shadows and textures can be solved simply:
1 standard set of textures
1 render template
1 program

Is there any chance of this happening? My "official temperate grass" texture which (almost) 100% matched the ground tiles fell on very deaf ears.

[Jupix]

Ben: yeah, I'll post that sprite in a bit, I'm currently not on the PC it went to when you sent it. Will be heading there in 2 hours or so.

--

I'm not sure enforcing set coherency and implementing z1&z2 are mutually exclusive projects. Of course, like you said, some thought has to go into when a model is ready to be presented in all zoom levels (in other words, when it's ready for release). It's pointless to spend time making a presentable release package of content that's, in essence, unfinished.

By the way, when it comes to changing materials or lighting, we're talking of course about tasks that require the availability of sources in order to be completed properly. In fact this is one of the possible scenarios that get mentioned whenever there's an explanation for why we want sources for graphics to be available in the first place. It's why I make such a big deal about having sources here, and at the repository. If we have a sprite that doesn't fit, and no sources with which to properly edit and re-render it, a lot of man-hours will be wasted in disregarding that piece and making a new one to replace it.

When an item is finished, part of which is fitting in with the rest of the set, but missing z1&z2 sprites, I don't see why they can't be created. If someone does, then that obviously means they prefer doing it to doing something else, and we get that much closer to a proper release, so it's a win-win.

As I've said before, I'd prefer it if we manually, properly implemented items in z1&z2 instead of letting the game do it automatically using a "dumb" algorithm. This is basically because of the following reasons:

• It's more expensive (performance-wise) to use an algorithm of any kind to rescale sprites on the fly in game, than to load ready-made sprites.
• z0 sprites are modeled and rendered for z0, therefore it is very possible they don't translate well to z1&z2. They might look terrible automatically scaled, but good when some fixing and testing has been done manually.
• Tars with z0-2 work with both vanilla OpenTTD and OpenTTD-EZ, tars with z0 only work with -EZ. So straight away making content for both will only buff both projects. Making content for -EZ and not for vanilla, or vice versa, will work to divide the project into two, therefore hindering overall progress by making it appear inconsequential to devs and confusing to players.

Of course, correct me if I'm wrong there...

As for standardisation of materials and modeling/rendering technique (incl. software), this can be divided three-fold like you said, Zephyris.

• Materials: we have standardised materials. They're listed on the wiki. Not everyone uses them. Making them mandatory for the base set replacement set is, well, "in the works", shall I say. I'd rather not talk about that as it's still being thought through. But rest assured this shall be addressed in the future.
• Template: depends on the software which is the next point. But for every template exist specs, for example camera position, "sun" position and intensity, and so forth, and so far I haven't seen these specs laid out anywhere, not even on the wiki. It's my aim to get these specs out there and standardised among items but first there has to be a concensus on what those specs end up being. I can't just lay those ground rules myself.
• Software: can't be standardised because some have skills with X, some with Y and others with Z. We have so few artists we can't afford to lose anyone, so we can't go around saying only stuff rendered in X is allowed in.

[maquinista]

The house by Antonio could be modified and rendered again with your grass and with a smaller building.

The shadows are a bigger problem. I prefer tinny shadows, more light when They are far from the base of the object.

The streetlamps are not finished. I think that They should be a bit smaller.

About the textures: I prefer to have different textures, but with saturation and hues not very different. For example, I would prefer a less saturated bricks in the group of 3 houses.

About z1 and z2 sprites: the trees doesn't look good at z1 and z2 level because the algorithm uses the highest value of alpha channel of the z0 in the z1 and z2 sprite. This is good for ground sprites, but It doesn't look good in trees.

[Ben_Robbins_]

Zephyris: Idealisingly simple I think:

1 set of textures

This was originally done. Aracirion stuck a set of standard textures on the wiki. The problem is that as things have developed better textures have been made, and/or things have been done which couldn't have been stated before hand. I.e. grass. To make stuff fit with the grass required the grass to be made first. Also water. Likewise for buildings...a few buildings needed to be made before textures could be taken from them.

We have standard textures, but this needs to be updated. There can be variation, but a nice set of graphics should have textures either very different or exactly the same. Contrast, or conformaty, but no clash's.

1 program

There only needs to be 1 lead program. I.e if something can be done in that program (Blender), then it is fine to replicate this however you wish. The problem with just saying people have to use that 1 program is that it filters off a lot of people. I am not a blender user for 1. Maybe I could learn, but it would take me some time, in fact ages, and I would not produce work at the same speed as I can in softwear I use from day to day.

1 render template

I agree 1 render template...but per bit of softwear. Hence my slight objection in relation to the recent max lightsetup posted. But 1 template for 1 renderer takes the same point as above.

In short, as long as there are images/diagrams of what current sprites look like, and it is clear that any 'included' work has to match this, then people can get to it how ever they wish.

Jupix: Feel free to make a call on what materials and such like you would choose to make standard, or say if we need others. I'd follow it, and don't think it would be out of place for you to make this spec.

[Jupix]

On shadows: here's Ben's prototype sprite.



Take note of the sharp edges and high opacity.

For comparison, here's a tree with a very soft shadow.



What we want across the field is something that fits well with the overall theme of TTD, not necessarily something that's "realistic" or whatever. Bear in mind the original graphics set has nearly no shadows and the gameworld is overall very bright and light looking. As a result I would recommend sharp edges and low opacity. Comparison shots would be ideal, though, so the desided effect can be verified before widespread adoption.

[maquinista]

I have attached some examples of shadows.

The first is shadow on train wagons. I think that low opacity shadows overlaps better (Mmm... I think that I need a better glass texture for the locomotive). The shadow of my wagons is not very noticeable in screenshots, It looks better when the train is moving.
The second file has some light shadows over vertical elements (like walls). The area is more dark, but the shape of the shadow is not very noticeable.
The third is a dark shadow over a vertical element. The shape of the shadow looks strange, because the shadow of this building was rendered over a horizontal surface, and It only looks good if there is a horizontal area.

IMHO, is better to have shadows with low opacity. They overlaps better over other shadows and other not plain areas.

[Ben_Robbins_]

A short responce; needs more thought. The issue with the light shadows, especially on the train, is that they sit next to a dark 'shadow' side of the train. So the train in the shade is dark, but the ground on the shade next to it is lit. The 2 issues you state about dark shadows are still present for any shadow, but more subtle. I wonder if the shadow overlapping issue on neighbouring buildings is in any way solvable in relation to sprite draw order?

[Jupix]

To be honest I've always thought the trains are a little bit too dark anyway. CC don't really pop, and differentiation between cargo types is difficult outside z0.