32bpp Standards and Rules
Moderator: Graphics Moderators
- mexicoshanty
- Traffic Manager
- Posts: 158
- Joined: 22 Aug 2006 13:15
- Location: Australia
- Contact:
32bpp Standards and Rules
Ok, i've set this thread up to cement some of the standards and rules regarding the 32bpp version of OTTD. I particularly need to know these things so i continue setting up the cataloguing of new graphics system in a way that'll enforce these rules once the system is up and running or allow for easy expandability. I like to know the specifications of what i'm developing even if i dont implement some of the features right away i will plan to make sure they fit.
Issues that need to be resolved:
1. Do we need a different render for each zoom level? Or can we just resize the sprites on the fly.
Outcome - Assuming different renders will be required for each zoom level
2. Shadows. How are they going to work? Many times it's been suggested to have shadow sprites but i just don't see how that is going to work nicely. IMO the only feasible way is to create a new lighting environment that doesn't cast shadows. Only darkens the shadow side of a building.
3. Animation.
- Fixed tile animation (Eg water, water fountains). How many frames should we allocate to the animation. Also how many frames per second?
- Animation on moving things (eg wheel rotation, propeller movement on planes). I don't think this has been mentioned before but at these high zoom levels trucks, trains and planes are going to look rather weird without any animation. Trains and vehicles especially (sliding along the ground). This feature isn't something that should be implemented straight way as it can wait but we should plan for it.
Note to developers: I'd really like your input on these issues as well
Issues that need to be resolved:
1. Do we need a different render for each zoom level? Or can we just resize the sprites on the fly.
Outcome - Assuming different renders will be required for each zoom level
2. Shadows. How are they going to work? Many times it's been suggested to have shadow sprites but i just don't see how that is going to work nicely. IMO the only feasible way is to create a new lighting environment that doesn't cast shadows. Only darkens the shadow side of a building.
3. Animation.
- Fixed tile animation (Eg water, water fountains). How many frames should we allocate to the animation. Also how many frames per second?
- Animation on moving things (eg wheel rotation, propeller movement on planes). I don't think this has been mentioned before but at these high zoom levels trucks, trains and planes are going to look rather weird without any animation. Trains and vehicles especially (sliding along the ground). This feature isn't something that should be implemented straight way as it can wait but we should plan for it.
Note to developers: I'd really like your input on these issues as well
Last edited by mexicoshanty on 20 Jan 2007 02:59, edited 1 time in total.
3) For vehicles, at least, just use variable 46. Propeller animations could possibly use variable 0A instead.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- mexicoshanty
- Traffic Manager
- Posts: 158
- Joined: 22 Aug 2006 13:15
- Location: Australia
- Contact:
http://wiki.ttdpatch.net/tiki-index.php ... nalAction2 <-- Mentions var 0A
http://wiki.ttdpatch.net/tiki-index.php ... n2Vehicles <-- Mentions var 46
http://wiki.ttdpatch.net/tiki-index.php ... n2Vehicles <-- Mentions var 46
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
DaleStan, these graphics are intended to replace the proprietary and commercial ones on which OpenTTD currently depends. To this end, newgrf isn't appropriate; these will become the default sprites. Fixing upon a standard for such things as number and pace of animation frames is a good idea, especially as mexicoshanty is designing a database in which to store all of these during their development.
If you're suggesting that the game use NFO to define the default sprite characteristics, it might be an idea to put this formally to the devs. It could be a good design decision; I don't know.
If you're suggesting that the game use NFO to define the default sprite characteristics, it might be an idea to put this formally to the devs. It could be a good design decision; I don't know.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
It seems like a good idea to me. How many people still use the default TTD vehicle set, even for OTTD MP games?Brianetta wrote:If you're suggesting that the game use NFO to define the default sprite characteristics, it might be an idea to put this formally to the devs. It could be a good design decision; I don't know.
The harder question is "Why don't you use the default graphics?" I'm not sure if I can answer the question for myself, but if the answer has anything to do with tenders, MUs, multiple liveries, or such, then there's a good reason to use NFO to encode the functionality, because simple sprite replacements and balance adjustments can't do those.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- Ben_Robbins_
- Tycoon
- Posts: 1234
- Joined: 20 Nov 2005 01:56
- Location: Abu Dhabi, UAE
2. If its not posible to have shaddow sprites, then I don't think shaddows should just be got rid of. A fully lit street* next to a wall that sits in the shaddow would look wrong. I would think if shaddow features external of the sprirte the building stands on are not posible then then the shaddow should just stop at the tile edge.
*the street being excluded from recieveing shaddows.
3. I think the current answer is to just replace what already exsists, although more may come later and this could be taken in its stride.
*the street being excluded from recieveing shaddows.
3. I think the current answer is to just replace what already exsists, although more may come later and this could be taken in its stride.
Ben
Re: 32bpp Standards and Rules
1. I think blender might produce a better result, because it wouldn't blur so much. Also the edges would be better. Maybe build a batch script that can render the whole image (4 views x 4 zoom levels)=16 times?
2, turn of shadow only use spectation (?), I see no other way to make it work.
3. We probably would need a blender template or at least a defined method describing the way the animation is to be made. And some advanced implementation, if you have animated wheels they shouldn't rotate when the verhicle is not moving.
2, turn of shadow only use spectation (?), I see no other way to make it work.
3. We probably would need a blender template or at least a defined method describing the way the animation is to be made. And some advanced implementation, if you have animated wheels they shouldn't rotate when the verhicle is not moving.
see what just AO looks like without a Sun shadow (still uses a directional sun light for 3dness of course)
or lighten the sun shadow a lot making it less powerfull, as in daylight the shade is rather bright. this will also avoid shadows looking bad if they don't go across sprites.
another work around is having an almost noon shadow, with a sideways highlight (technically incorrect, but might look best)
Alltaken
or lighten the sun shadow a lot making it less powerfull, as in daylight the shade is rather bright. this will also avoid shadows looking bad if they don't go across sprites.
another work around is having an almost noon shadow, with a sideways highlight (technically incorrect, but might look best)
Alltaken
here two images, first with shadow casting from the sun, second without.
I like the first better, but for gaming purposes the second is very acceptable, I think.
[edit] sorry forgot to remove the transparent space
I like the first better, but for gaming purposes the second is very acceptable, I think.
[edit] sorry forgot to remove the transparent space
- Attachments
-
- cot2.png (57.91 KiB) Viewed 5734 times
-
- cot1.png (56.8 KiB) Viewed 5733 times
looking quite good, however Id like to see a version where the sun shadow has been weakened a lot.
the key point that should be achieved imo isnt to create shadows on the object, but to lighten/darken the object. a good way for this is using a skydome light (which I think is used? Im not familiar with the light setup) combined with a weak shadowcasting directional light.
you will get very light shadows this way but the house will be lit up/darkened respectively. I would recommend this procedure over leaving shadows all the way, because, frankly, it will look bad.
a lack of shadows makes the grass in the above example look as if it was luminous, and on other examples will make buildings look like they float or are otherwise disconnected from the ground.
the aim should be strong diffuse shadows and very weak directional ones (so mostly rely on something called "ambient occlusion" to shade the buildings. this will already do a LOT of work for you)
the key point that should be achieved imo isnt to create shadows on the object, but to lighten/darken the object. a good way for this is using a skydome light (which I think is used? Im not familiar with the light setup) combined with a weak shadowcasting directional light.
you will get very light shadows this way but the house will be lit up/darkened respectively. I would recommend this procedure over leaving shadows all the way, because, frankly, it will look bad.
a lack of shadows makes the grass in the above example look as if it was luminous, and on other examples will make buildings look like they float or are otherwise disconnected from the ground.
the aim should be strong diffuse shadows and very weak directional ones (so mostly rely on something called "ambient occlusion" to shade the buildings. this will already do a LOT of work for you)
- mexicoshanty
- Traffic Manager
- Posts: 158
- Joined: 22 Aug 2006 13:15
- Location: Australia
- Contact:
I like the first one better too. Try what Psistorm saidbrupje wrote:here two images, first with shadow casting from the sun, second without.
I like the first better, but for gaming purposes the second is very acceptable, I think.
[edit] sorry forgot to remove the transparent space

- mexicoshanty
- Traffic Manager
- Posts: 158
- Joined: 22 Aug 2006 13:15
- Location: Australia
- Contact:
Re: 32bpp Standards and Rules
Yeah, i'm just unsure how the current system works or what's going to be better for memory/performace with the new 32bit sprites. I'll go ahead and assume this is what is going to happen. I guess if a batch script is made not much harm is done if the extra renders aren't needed at some stage.brupje wrote:1. I think blender might produce a better result, because it wouldn't blur so much. Also the edges would be better. Maybe build a batch script that can render the whole image (4 views x 4 zoom levels)=16 times?
I got a PM from the user Chicago Rail Authority that had similar idea's about generic templetes, here's what he had to say (hope he doesn't mind):brupje wrote:3. We probably would need a blender template or at least a defined method describing the way the animation is to be made. And some advanced implementation, if you have animated wheels they shouldn't rotate when the verhicle is not moving.
Maybe we could put together a pack for artists. We already have a lighting setup and texture pack but how about adding some template .blender files and batch scripts for rendering?Chicago Rail Authority in a PM wrote:Perhaps things have progressed since I last attempted some work in Blender for some newer graphics, so I apologize if I have missed something...
But as an 'aspiring' artist, I'd think some add'l base tiles would be extremely helpful...
Suggestions:
* 1x1 road tile pre-built with appropriate curb height, etc.
* 2x1 "" ""
* 2x2 road tile on two consecutive tiles, plain concrete on the add'l two tiles
Templates like those, rather than just lighting setups, would probably enable many more people to join in the development steps.
As this development progresses, I'd think comprehensive templates will expedite the process and eliminate the 'your curb is too high / too low' debates that will necessarily happen down the road...
Just a thought.
Re: 32bpp Standards and Rules
To a question of animationmexicoshanty wrote: 3. Animation.
- Fixed tile animation (Eg water, water fountains). How many frames should we allocate to the animation. Also how many frames per second?
- Animation on moving things (eg wheel rotation, propeller movement on planes). I don't think this has been mentioned before but at these high zoom levels trucks, trains and planes are going to look rather weird without any animation. Trains and vehicles especially (sliding along the ground). This feature isn't something that should be implemented straight way as it can wait but we should plan for it.
I put sample Propellers Plane-
Vickers Viscount-700 of 1950
Graphics by Paasky
New mathematical model of flights
Need Full Animation and Full Detail
Archive in the size of 380 KB here
http://lidars.narod.ru/Files/OpenTTD/Ai ... ack10w.rar
Sergey.
- Attachments
-
- I put sample Propellers Plane-
Vickers Viscount-700 of 1950 - Viscount_700_1950.png (109.38 KiB) Viewed 5401 times
Re: 32bpp Standards and Rules
Ugh.Sergej_S wrote:Graphics by Paasky
No, they're not. They're Locomotion graphics.
Do you listen to anything anyone tells you? I'm very surprised you're not banned yet.
- athanasios
- Tycoon
- Posts: 3138
- Joined: 23 Jun 2005 00:09
- Contact:
Don't go to extreme!
I repeat again: We are still using TTD original graphics, he prefers the Locomotion ones or whatever game he is fond of (a bit altered I think). TTD has 'borrowed' graphics from other games too.
Naughty Russian! Let him have his ideas, but not a thread (locked). Or 'fix' his reply removing offending graphics and link.
Probably he doesn't understand English!
I repeat again: We are still using TTD original graphics, he prefers the Locomotion ones or whatever game he is fond of (a bit altered I think). TTD has 'borrowed' graphics from other games too.
Naughty Russian! Let him have his ideas, but not a thread (locked). Or 'fix' his reply removing offending graphics and link.
Probably he doesn't understand English!

http://members.fortunecity.com/gamesart
"If no one is a fool I am also a fool." -The TTD maniac.
I prefer to be contacted through PMs. Thanks.
"If no one is a fool I am also a fool." -The TTD maniac.
I prefer to be contacted through PMs. Thanks.
In most countries, ignorance of the law is no excuse. (Meaning, it's still a copyright violation, even if he can't understand us when we point that out.)
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: 32bpp Standards and Rules
we already have some templates, without roads. But I guess that's nice to have also.mexicoshanty wrote: Maybe we could put together a pack for artists. We already have a lighting setup and texture pack but how about adding some template .blender files and batch scripts for rendering?
Who is online
Users browsing this forum: Amazon [Bot] and 12 guests