New Graphics Problem

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

Alltaken
Tycoon
Tycoon
Posts: 1285
Joined: 03 Dec 2003 06:24
Location: Christchurch, New Zealand
Contact:

Post by Alltaken »

except with only two colours not a gradient :P

Alltaken
User avatar
Ben_Robbins_
Tycoon
Tycoon
Posts: 1234
Joined: 20 Nov 2005 01:56
Location: Abu Dhabi, UAE

Post by 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.
Attachments
Shaddows Example.PNG
Shaddows Example.PNG (130.01 KiB) Viewed 3933 times
Ben
Alltaken
Tycoon
Tycoon
Posts: 1285
Joined: 03 Dec 2003 06:24
Location: Christchurch, New Zealand
Contact:

Post by 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
User avatar
Zimmlock
Tycoon
Tycoon
Posts: 2112
Joined: 02 Dec 2003 16:01
Location: Belgium

Post by 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.
Hodie Mihi Cras Tibi
iNVERTED
Route Supervisor
Route Supervisor
Posts: 387
Joined: 24 Apr 2005 21:21
Location: Torquay, England
Contact:

Post by iNVERTED »

Zimmlock wrote: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. ;)
User avatar
Ben_Robbins_
Tycoon
Tycoon
Posts: 1234
Joined: 20 Nov 2005 01:56
Location: Abu Dhabi, UAE

Post by 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.
Ben
iNVERTED
Route Supervisor
Route Supervisor
Posts: 387
Joined: 24 Apr 2005 21:21
Location: Torquay, England
Contact:

Post by iNVERTED »

Ben_Robbins_ wrote: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.
User avatar
Aracirion
Traffic Manager
Traffic Manager
Posts: 241
Joined: 15 Jan 2006 15:15
Contact:

Post by Aracirion »

you can't do that if grass is on the ground tile, cause it has to grow in front of the building
iNVERTED
Route Supervisor
Route Supervisor
Posts: 387
Joined: 24 Apr 2005 21:21
Location: Torquay, England
Contact:

Post by iNVERTED »

Then the building tile should be transparent where the grass should overlap it.
User avatar
Aracirion
Traffic Manager
Traffic Manager
Posts: 241
Joined: 15 Jan 2006 15:15
Contact:

Post by 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.
Attachments
shadow-test.png
shadow-test.png (133.25 KiB) Viewed 655 times
User avatar
Ben_Robbins_
Tycoon
Tycoon
Posts: 1234
Joined: 20 Nov 2005 01:56
Location: Abu Dhabi, UAE

Post by 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
Attachments
Shaddow Example Cubes.PNG
Shaddow Example Cubes.PNG (159.8 KiB) Viewed 667 times
Ben
User avatar
lowman
Engineer
Engineer
Posts: 31
Joined: 19 Apr 2006 01:35
Location: Melbourne, Australia
Contact:

Post by 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.
User avatar
Ben_Robbins_
Tycoon
Tycoon
Posts: 1234
Joined: 20 Nov 2005 01:56
Location: Abu Dhabi, UAE

Post by 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.
Ben
Alltaken
Tycoon
Tycoon
Posts: 1285
Joined: 03 Dec 2003 06:24
Location: Christchurch, New Zealand
Contact:

Post by 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 :D (graphics coding)

Alltaken
Post Reply

Return to “Graphics Development”

Who is online

Users browsing this forum: No registered users and 20 guests