New Graphics Problem

[Alltaken]

except with only two colours not a gradient

Alltaken

[Ben_Robbins_]

Since theres no answers for how to do shaddows, can I suggest this method. (Attached) The shaddow area that doesnt fall onto the tile, is put on its own layer, and detextured, darkens, and made 50% opake, and then this can lie on top of neighbouring tiles? A and B being the base plate and 'building' sprites that are needed at present, and C being the shaddow sprite.

C would lie on top of A but behind B, and therefore only effect the ground sprite...wich is better than nothing.

[Alltaken]

A and B can be combined as a single tile, but A should be split into Ground plane (actual ground plane, like grass or concrete) and Building, so that any shadow goes under the building and not over some of it.

but yeah it does look like a good idea.

Alltaken

[Zimmlock]

Hi to all, i have been folowing all discussions about OTTD grafix here on the forum, i even am experimenting with Blender, but cant handle it at the moment.

I would like to add a suggestion to the shadows item above.
Now you split the image in to the tile with a part of the building, the rest of the building and a small shadow part.
Why not splitting like normal TTD sprites, a ground tile, a building part, and new for OTTD a semi transparent shadow part that contains the hole shadow or all shadows of variouse structure on one tile. Advatage is that the shadow ll fall on the building standing on the next tile. And you have stil three images as you had before in your example.

[iNVERTED]

Why not splitting like normal TTD sprites, a ground tile, a building part, and new for OTTD a semi transparent shadow part that contains the hole shadow or all shadows of variouse structure on one tile. Advatage is that the shadow ll fall on the building standing on the next tile. And you have stil three images as you had before in your example.

Nice idea - also, this would allow you to turn off the shadows in the options menu.

[Ben_Robbins_]

Alltaken: B is suposed just to be the building, and A just the sprite, but i just cut them at the tile edge, rather than the building base. (lazyness). So yes, A would be the ground sprite, B the building, and C the shaddow.
Are you also sugesting that the shaddow that falls onto the tile area is part of B rather than A? or should the shaddow still just sit on the base sprite?

Zimmlock: Because of the shape of the building the shaddows would need to reform accordingly, wich is inposible, so I just asumed that would be unsolveable.

<edit> hmm, just thourght, there would need to be many different shaddow renders for differnt neighbouring tiles..wich would also involve coding. Differnt slopes, and also if the building sits on a slope itself and has a vertical wall next to it.

[iNVERTED]

Are you also sugesting that the shaddow that falls onto the tile area is part of B rather than A? or should the shaddow still just sit on the base sprite?

No, it should be on C.

In other words:

sprite A: The ground sprite, i.e. everything with zero or negligable (sp?) height, without shadow.
sprite B: The building sprite, i.e. everything with height, without shadow.
sprite C: The shadow sprite.

[Aracirion]

you can't do that if grass is on the ground tile, cause it has to grow in front of the building

[iNVERTED]

Then the building tile should be transparent where the grass should overlap it.

[Aracirion]

I just tried rendering shadows using blender. The result was fairly diffuse. When I tried to put some buildings together I thought that maybe diffuse shadows will work fairly well because you don't notice if geometry of the building which receives the shadow doesn't match the shadow itself.

The general idea would be to render all ground sprites first and then put the building sprites (which includes shadow) on top of it. So just two sprites per building.

[Ben_Robbins_]

If theres only 2 sprites per building, then a viecle that drives behind the building would also drive behind the shaddow, and the shaddows wouldnt take the shape of the viecle, and therefore the shaddow would look really strange.

One semi solution I thourght of, is having a base sprite, a building sprite, and external shaddow sprite as said above, but also having a building shaddow wich is applied when the building sits next to another. Because of buildings having different hieghts, i thourght maybe a set shaddow could be moved up and down and cut to fit (with an alpha map), relative to a preset value of the niehgbouring building. (<using x,y,z)Height/distance from edge etc)

This would need 4 layers sorta though. Base Sprtie, Building Sprite, External Shaddow, and Cast Shaddow alpha....

I'm not shore exactly how the game calculates what sprites fall ontop of one another, but the cast shaddows would need to sit above the building, but behind the neighbouring building, so couldnt just be on the next layer up from buildings all together. Kinda like the trees appear to sit on top of each other on the same sprite...dunno how thats done.

The off set of the shaddow could be worked out using the hieght of the neighbouring building (Z) divided by 2.3, - Y. Then Subtract X, and times that by 2.3. (1:2.3 being the shaddow angle ish)

This would work less well the less square a building on slopes, but i think it could look better than 1) no shaddowing, or 2) shaddows that just fall over the neigbouring sprites and make it appear flat.

Hope that makes some sence

[lowman]

I think I follow Ben's idea and it seems to make sense, although like a lot of grfx questions, it basically comes down to "Is it worth the effort?"

In that vein, could I suggest a simplification? Instead of every building having its own shadow map, have 3 standard types of shadow: 1 for low (less than 4 stories) buildings that don't cast shadows beyond their tile, another for tall buildings that cast partial shadows, and a third for very tall buildings that cast complete shadows

The shadow data could then reside in the building being shadowed, all the building is to know is how big the building next to it is, and therefore how much shadow to display.

That way you avoid all of the problems with getting one object to modify the appearence of another dynamically, and you don't have to break the tile-ability.

[Ben_Robbins_]

Would a developer, or someone who understands the coding side of all this, be able to comment? Specifically on what is possible...how many layers are avaliable etc. Cheers.

Also, The grid lines that break up the tiles. Is it going to be posible to have the option to remove them (as ive heard this suggested a few times)

If so...would there be 2 sets of each ground sprite, 1 with lines 1 without. OR...would there be an alpha for the border that would sit ontop of the base sprite, and base shaddow?.... OR... is this just not posible.

Also, Would the lines go equally around the tile, or would they just be on 2 sides of every tile? (I'm awair of how the original graphics work). I ask this, as if there is a raised ground bit, like a pavement, or grass for example, then the shaddow would appear as 2 seperated thin lines, if the shaddow is on all 4 sides of the tile.

-------------------------------------------------------------------------------------

<EDIT> I've been looking for many many many hours, trying to read through all of the topics about developing the idea of making these graphics. Theres still things I havn't found I'm shore, but one thing I came across was this: (2 Years Ago)

Celestar: ok after a quick dev meeting, we more or less decided on this:

0 - Road (8 way, two sets, one for left hand drive, one for right hand drive)
1 - Normal Rail (what we have now, limit 160km/h on straights)
2 - Normal Rail with overhead wires.
3 - High Speed Rail (rail on a concrete foundation, up to 300 - 350km/h)
4 - Maglev / Monorail.
5 - Narrow Gauge (has two tracks in the main directions, instead of one)
6 - Trams (basically narrow gauge plus roads)
7 - Rack Railway (a third, toothed rail in the middle)

Has this been updated? Would Road types not be a posiblitiy (so that its not inposible if the option is ever wanted)

Is there a similar basic list, of the amount of layers each tile can have. eg:

1. Base Sprite
2. Base Shaddow
3. Grid
4. Building
5. Building Shaddow

Once All these questions are sorted, I'll try and stick together a more uptodate artists starters guide so It's more clear than it is currently. Should stop them rearising.

[Alltaken]

Grid lines are seperate and don't even need sprites (the lines can be coded/calulated ont he fly) so no sprites will have grids.

shadows on the side of buildings is not worth the effort involed, but would be possible

shaodws going over adjacant ground sprites (but under buildings and vehicles) should be possible. and is pretty much what we are expecting.

0 - Road (8 way, two sets, one for left hand drive, one for right hand drive)
1 - Normal Rail (what we have now, limit 160km/h on straights)
2 - Normal Rail with overhead wires.
3 - High Speed Rail (rail on a concrete foundation, up to 300 - 350km/h)
4 - Maglev / Monorail.
5 - Narrow Gauge (has two tracks in the main directions, instead of one)
6 - Trams (basically narrow gauge plus roads)
7 - Rack Railway (a third, toothed rail in the middle)

Yep they all look right, but can i clarify that road being 8 way means it goes through the corners also? if so then i agree.

1. Base Sprite
2. Base Shaddow
3. Grid
4. Building
5. Building Shaddow

there is no limit, we have lots of layers each is programable based on situation.

vehicles have no seperate shadows (if they are on the ground, since the shadows are so little) but planes would have seperate ones, and perhaps large ships.... this is programable in the graphics format.

buildings can have any number of states of construction, any number of angles (the game will call those needed/ usable) and any number of overlays.

company colour overlay (computer controled hue/saturation changes)
shadows
livalries
seasonal plants
night/day
fences (if they are a specific thing to the building)
wear and tear
...
...
...

the base sprites are done in such a way that you can change a terrain and have all the buildings largely look like they are in place (rather than looking funny as they do now if you change the grass colour a bit etc..)

the wiki does list the ones required and many that are thought of. but the limit is limitless (graphics coding)

Alltaken