News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Upgrading graphical quality of Simutrans [long read]

Started by Sarlock, October 23, 2012, 06:56:58 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sarlock

I am likely dredging up some old debates and discussions about this, but I have been giving this a lot of thought over the past few weeks, so here goes.  My apologies in advance if I am overstepping, digging up old arguments.  Grab your coffee and get ready for a long read:

Simutrans is a fabulous game.  It is playable in many different ways, the vehicles all work extremely well together, the paksets each have their own unique differences and the game is quite stable given its immense complexity.  I honestly feel that the game is very complete as it is now.  Simutrans' biggest plus is its ability to play truly MASSIVE maps.  And as computers get faster, this ability makes it shine even more.  That said, I find myself comparing Simutrans to Simcity a lot.  While the gameplay idea is different: transportation simulator vs. city simulator, they share many common areas.  They are both based on isometric graphics, they both involve roads, trains and other transportation and they both have revolve around cities.  From a gameplay perspective, they are both excellent games and offer a lot of depth to the player.  After a while, however, the player exhausts the core options available and begins to branch in to customization and other play styles.  A very popular branch of playstyle for Simcity is the city role playing perspective: creating a custom city as a sandbox... much like making a model train set on a table and adding towns and other content.  Both games have an extensive library of customized content and much of the long-term player base plays with this and many are active in the development process in one form or another.  The Simcity community is much the same: customization is very popular and there are many players who are custom developing cities with very little intention of actually "playing" the game they are creating... it's all props and eye candy.  What Simcity lacks is the ability to modify the source code-they are stuck with what they have.  The computer is relegated to the role of a palette for the painter: it is restricted from doing any development of its own.  In my view, this is the one aspect where Simutrans is weaker.  The mature paksets have a wide range of graphics available but the end graphical effect pales compared to Simcity.  Our volunteer artists are just as capable as any other, so it isn't a talent differential.

So, I ask myself, what are the fundamental differences between the two graphical styles?  What is restricting Simutrans from looking more like Simcity?  They are both based on isometric graphics at their core... while Simcity draws from 3D models, the end product is still a 2D representation of the content, viewable on 4 rotations, just as Simutrans.  A sample Simcity snapshot:



Differences?

* The isometric angle is different.  This only presents a different angle view of the object and I don't think this confers any meaningful aesthetic advantage.  The Simcity camera angle is roughly 45 degrees in the sky.  This is similar to the one used in Simutrans.
* Different sized isometric grid components.  Simcity is about 100 across by 80 high, or thereabouts (I'm just guessing, looking at this picture).  This gives it no advantage, it doesn't matter what the grid size from a end graphics perspective (it does affect playability and other aspects, however - and 64x64/128x128 or whatever works just fine for Simutrans).

So if these are just cosmetic differences and don't affect the aesthetics, then what does?

The quality is seemingly much higher because they are based on 3D renders, but we can use 3D renders as our root stock as well and produce the exact same quality product.  Many of our current pictures originated as 3D renders (esp pak128.Britain). The texture choice in Simcity is quite aggressive, it gives a lot of variation in the end product which works well at this scale.

So, then, here are what I think are the core 3 items that give Simcity graphics its superiority:

1) Smoothed edges/partial transparency: The edges of the Simcity objects contain data that allows them to be combined with the objects behind them to give a smoother edge.  Compare this to the "chunky" pixelated edges of Simutrans graphics.  We have no choice in this respect because we have no knowledge of what colour(s) exist behind our painted object, so the object retains its pure colour right to the edge.  Observe how nicely the back of the barn blends in to the farm field and tree above it or how nicely the tree over the road merges with the road beneath it.  The same tree is again to the right covering over the dark warehouse.  Notice how the edge pixels of the tree change to suit each background.  This is just a bit of colour combining between the foreground and background object.  Ideas shortly.
2) More multi-grid objects.  A majority of buildings in Simcity are more than 1x1 tiles in size.  This allows construction of more complex/larger buildings.  Again, discussion below.
3) Shadows: Shadows, I think, are the #1 way to convey a sense of realistic graphics.  It convinces the eye of the three dimensionality of an object.  It gives it depth, shape and life/realism.  Simcity can draw from its 3D rootstock in order to generate a shadow and that gives it an advantage, but this can be overcome.  I will discuss this idea last.

Now, a caveat: I know many people play this game for its pure simulation potential and performance and speed is essential to a smooth running game.  There should be a toggle button in the Graphics Settings for Shadows on/off, Transparency(or another, better name for it) on/off.  This allows the core game to retain its original performance while providing a much more realistic graphical foundation for those interested in the aesthetic aspect of the game.

There may be other more subtle differences, but I think these 3 core areas capture the bulk of the graphical differences between the two styles.

I will discuss each below:


1: PARTIAL TRANSPARENCY:

This is a bit easier to accomplish.  Add support for an 8 bit alpha channel for 32 bit PNG files.  Yes, I know there will be a performance hit for this.  This can be disabled in the Graphics-Settings for those who want a more raw image and have a game that is more performance driven.  The alpha channel could be pared down to 4 bits in the makeobj process if desired, though I think 8 bits is as easy to work with as 4 bits-storage isn't much of an issue these days with gigabytes of RAM available.  I think having 16 different transparency levels would be adequate for any application.  256 would be even better.  Makeobj could scan the image for any occurence of a pixel having its alpha channel data on and store that data in a separate part of that tile's data.

The game then, (if Transparency is set ON) would apply the alpha channel at drawing time and meld the two pixels together: the one being drawn against the one already there.

This would open up a world of possibility for our graphic designers: transparent glass/windows on stations and other objects, edges of trees where the leaves are semi-transparent (trees would see a big improvement with an alpha channel), smoothing of building edges (especially rooflines), etc.  We could also produce smaller objects with much more apparent detail.  Vehicles would see a huge improvement.  Gone would be the pixelated edges of train cars and in its place would be nice smooth edges.

I'm not familiar with the code, so I don't know how easy or hard it would be to add this to the game.  If it's an option that can be turned off in the Settings, the performance issue shouldn't be a problem... just how easily it can be done and a general willingness to do it.  As someone who is creating graphics, I would be eternally happy even for just this option to be implemented.  Our artists could do some amazing things with an alpha channel option.


2: MULTI-TILE BUILDINGS:

This has been discussed before.  We can create multi-tile buildings as monuments, factories, etc, but city buildings (res, com, ind) cannot be created as multi-tiled objects.  I understand the logistical difficulty behind this, as upgrading a single tile res to a multi-tile res would require the destruction of neighboring buildings.  And as we cannot destroy roads because of their importance to the player, we cannot touch those when upgrading a building.  Still, having a 1x2, 2x1 or 2x2 building shouldn't pose too much issue in any normal city as there are plenty of those building sites available.  Going larger than 2x2 will likely result in that building not appearing very often and I think we could safely stop at 2x2 as a requirement and be fine with that.  Being able to go to 2x2 would open up an incredible set of options to pakset artists.

Let's say I create a level 11, 1x2 residential building.  In the game, there is a city and in this city there is going to be built an upgrade to a residential single tile building of, say, level 10.  It is going to grow to level 11.  In the level 11 selections we have a 1x2 residential building available along with other single tile choices.  The game randomly selects the 1x2 residential building and then must fit test this building at the site: it tests the tile beside this one, ensures that it is a city building and not a road or any other structure and then puts the 1x2 building down in this spot.  Otherwise it rejects this building choice and reverts to a 1x1 choice instead.

Later upgrades will give preference to upgrading to another 1x2 building in this spot or an upgrade to 2x2 if there is a 2x2 building available and the adjacent squares beside are available to expand in to.  If a building goes to 2x2, it will stay 2x2 for the rest of the game, of that type (res, com, ind).  I don't think downgrading should be possible.  If we weight the random selection to favour buildings that are 1x1, we wouldn't have a city that is too heavily biased towards larger buildings, though I think that a large, high level city should be well populated by larger tiled buildings, 1x2/2x1 and 2x2.  It would look very impressive.

This shouldn't be a performance issue.  It will add a bit to the city growth algorithm, but that isn't called all the time, so an extra few ticks won't impact anything there.  From a drawing perspective, it shouldn't add any extra overhead as the game will draw a 2x2 set of tiles just as fast as it would have drawn 4 1x1 tiles in the same area.


3: "REAL" SHADOWS:

While a "true" application of the shadows would require an effort equal to that being undertaken by those creating the 3D offshoot of Simutrans, the sheer immensity of this addition to the game (and the graphic artist impact) may make it a good time before it is implemented.  Calculating real-time shadows from 3D objects is CPU-intensive.

Most of my programming knowledge stems from 15-20 years ago when I was actively programming at the time.  I have little knowledge of modern programming techniques, especially those surrounding the use of GPU's (we had to do it all on the processor back in my time-most of it was done with assembly language subroutines for speed).  The key to having decent looking shadows in the game is to pre-process as much of the shadow data as possible so that at run time there is very little calculating or processing required.  I will suggest ideas that I have, but more experienced programmers may have much more elegant solutions than I do.

We do not have height data for our 2D objects.  They are just flat as far as the computer is concerned.  So what we, as graphical designers, need to provide is a shadow map with our submissions.  This can be a single colour painted on a single colour background.  This maps out what the shadow looks like projected on to a flat surface behind our object.  For small static (not moving) objects, the shadow can probably be painted right on the tile with the object and no shadow map will be required as the shadow will not fall outside of the tile.  Many images already have shadows on them.  If a map is required because the shadow extends outwards or the object is a tree or moves, then we would add a makeobj field for the .dat file:

addshadowmap=filename.1.1

If addshadowmap is not included in the .dat, then no shadows are added to the object.  This retains backward compatibility to previous pakset material and addows.  Anything without a shadow map doesn't get a shadow.  Shadows are (or not) added to new objects and/or retroactively added to existing objects by the pakset artists as they see fit.  The shadow image file would need to be a different shape/size than the tile as it will extend in a direction determined by the pakset lighting scheme.  A larger image size can work fine as we will only be saving the data for where the shadow exists, the rest is discarded.

Most small houses and such will not need a shadow map.  Basically anything that doesn't have a shadow that extends outside of the tile and doesn't have the potential for a vehicle to enter it (ie: a station).  The shadow file would be a single colour, probably black, projected on to a background colour, probably white.  Keeping it with colour FFFFFFx on 000000x would make it simple.  For most objects, I don't envision this taking more than a few minutes to create.  Just take the image, add a layer, draw in the shadow for it and save the shadow layer as the new image for the shadow map.  50% of buildings probably won't even need a shadow map.  For most paksets the light source is high in the sky and the shadow quite small.  For many vehicles, the shadow would be at most 6-8 pixels high and the length of the vehicle.  A single colour on a single colour background would also make for very small files and game data (single bit per shadow pixel).

How shadows could be applied:

I am not entirely up to speed with the fine details of how the scene is constructed on the screen, but I envision that the shadows would be layered as part of the regular layering process for a screen update.  As the tiles are drawn from back to front, the final step of each row of tiles would be to apply the shadow map for the objects that are in the next row.  The shadow is mapped on to the tiles using the same algorithm that is used for the airplane shadows.  I imagine it would be wisest to pre-construct a full screen shadow map first by polling all of the shadow maps first.  This way any shadow overlaps would be addressed at this point (we wouldn't want shadows on shadows to be "extra dark", we just want a single shadow effect-shadows shouldn't be additive).  Once we have a full screen shadow map constructed, when the screen is drawn tile by tile, the last function for that tile is to apply the shadow map for that tile, if one exists for that area.

This may be a challenge algorithmically when we deal with how to layer shadows on roads where we have the potential for multiple objects on the same tile: a bus in front, tram in middle and car at the back.  This may be a challenge especially on a corner.  I'm not sure how this data is handled by the game, though I suspect it is merely drawing pixels based on a common 0,0 coordinate for that tile and where they end up is just decided by the graphics.  They may require some effort to get it to work and layer right, but well worth the effort.  Some graphical models may not work properly with shadows if they do not conform to what we normally expect vehicles to look like and behave (especially addons) and these can just be drawn without shadow data or fixed.  This is a pakset responsibility, if they want shadows, and so isn't a programming concern.  This might actually be easily resolved at the time shadows are pre calculated, I can't quite envision where the hurdles would be with this, if any even truly exist.  It might look just fine at the small scale of vehicles even if there are some tiny inconsistencies of shadow application.

This gives us realistic shadows for all of our game art and is calculated and drawn without a heavy tax on the CPU.  It shouldn't slow the drawing process down much.

Now, this creates one graphical inconsistency:

When shadows lay on top of a non-flat object (ie: a skyscraper shading another skyscraper) the shadow map will fail to properly lay down a shadow.



How we correct the shadow to properly lay upon the next object would require having a height/elevation map/data of the object.  I have some conceptual ideas of how we can fairly easily provide this data.  If we just go with our objects being boxes of different configurations, we provide a height map using a 8 bit PNG greyscale file to indicate height of each pixel (the lighter the colour, the higher the object is).

That aside, I think that that can be a later consideration.  Maybe it will never be worth implementing.  Most buildings are smaller than the ones in this picture.  For the vast majority of shadows, it will look just fine being applied as a flat map.

Image before shadows:



Applying shadows for just trees:



This is using the exact same shadow size that is there currently for this tree, just changed from the black/transparent checkerboard pattern to computing transparency off of a pure black pattern with alpha channel enabled (about 60%).

Note how the tree's shadow lies nicely over the vehicles on the road.  There is no computation here, the shadow is merely laid over top in a flat pattern.  The vehicles are too small to notice that it isn't computed to the height of the vehicle (unless you look really closely).

Applying shadows for trees, vehicles, road catenary and buildings:



The only shadows where things get a little weird and quite noticeable is on taller buildings.  These shadows are long enough that they can cause some weird effects when they lie down the length of the building on the east side:



We'd need a height map of the buildings to make this work.

What I propose is this:

We skip the idea of a height map, at least for now.  Perhaps it will be resolved with a future 2 1/2 D version of Simutrans based off of 3D data.  This then becomes a pakset decision: Does the pakset want longer shadows for taller buildings and live with this effect or, as I think, do we just skip shadows for very tall buildings (over 6 stories) at this point and just have shadows for trees, smaller buildings, vehicles and other shorter structures.  Shadows will also get weird when against down and up slopes, but again, if the shadows are typically short from shorter objects, the distortion will not matter as much.

This gives us a fairly easy (I hope!) to code graphical addition to the game that will have a big visual impact with little downside.  Paksets can individually make the decision on where their shadows will lie (sun position) and what length of shadow is "too long".


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

Anyone still reading?  :)

If I had the programming knowledge in C, I would happily volunteer my time to help implement one or all of these ideas.  Unfortunately my antiquated programming skills are of no use, but I do have a fair bit of experience with programming, concepts and designs for programs.  With someone to help me get a better understanding of the architecture of the game, I could assist with designing a framework/system that would be fairly easy to implement for both the programmer(s) and artists.


The last question then becomes:

So... why do this?

I feel there is an entire market of players out there who would gravitate to this game if it was more graphically impressive.  Artists, programmers and other volunteers.  These people could help make an already incredible game into something even more incredible.  I just feel like this game is on the verge of an incredible metamorphosis.  Caterpillar into the butterfly, if you will.  If people love the idea of creating their own world and having trains, planes and automobiles zooming around in it, let's try and make the most graphically impressive game that we can that still runs blazingly fast even on huge maps.

Give us the tools and we artists will make this game fly to new heights.   :)


Think about it.  And I will humbly go back to making my pak128 trees :)

Thanks for reading,

Sarlock, Canadian tree hugger.
Current projects: Pak128 Trees, blender graphics

merry

Well, thank you for these observations.
For me, these are very valid, although perhaps only addressing one aspect of the issues.
BUT (and this is a big BUT) the graphical feel has not  - until now - been a prime focus of the game; it's been a transport operational simulation first & foremost. And this is good, because the playability of the game is superb. And I don't want to denigrate or criticise the game's developers up to this point: they have together made something amazing. But it's still developing and I see Sarlock's suggestions as trying to help this development.

I'd like to add one other aspect of the game's graphical feel that - IMO - massively contributes to the limited realism & sophistication of the environment. And this is the gradient / landscape system.
The limitation of only full-height tile steps (and now half or double height) gives a very 'toy block' feel to the Simutrans landscape, in stark contrast with Simcity. It also means that rather awkward (but well meaning, and intelligent) kludges have had to be applied to spread the gradient effect in Simutrans-experimental, when in fact the problem is the underlying gradient model. With a more subtle gradient model, allowing perhaps both 8 partial steps of height, and perhaps up to 8 multiple tile steps (ie cliffs!), with a foreshore at / near sea level (giving beaches), I can see the landscape being more natural, and capable of more flexible expression of different terrain characters.
Now, the main objection to this sort of gradient model that I've seen has been the graphical complexity for terrain. I would suggest that once we have the slope, half-slope, and flat landscape drawn, fractional and multiple gradient landscapes can be interpolated by the graphical engine not drawn by the artist (unless they really want to). I sincerely doubt that we would see a vast difference in landscape tile rendering, although I am sure it could be found if one looked for it.
Simcity has in the past coped with the landscape to building gradient interface by the same method as Simutrans: build a retaining wall, and IMO that is fine. The only alternative is to alter the surrounding gradients, which won't always be viable, although it would look nicer.
Think about the options: rolling smooth English landscapes, plains with gentle undulations, but also alpine peaks - ravines, cliffs, you get the idea!
Again, my ability to contribute is near non-existent (I get to play rather rarely these days, only view the forum once a week or so, and as to coding...no, C is not in my skillset - I'm an analogue engineer really). So please forgive me for making armchair commentary!
Anyway, I do hope this will be a constructive discussion, and once again I'd like to thank the developing contributors for their dedication and hard work. Please keep it up while you are able :-)

Sarlock

Doing some more thinking about this and I realized that almost all of the shadows can be resolved just by having the alpha channel.  Shadows for trees and vehicles would just be included in the PNG file as transparent dark colours that naturally cast "shadows" on objects they are in front of.

Alpha channel itself opens up a lot of possibilities.

Merry, thanks for the comments.  I agree about the terrain elevation contributing to a more "natural" feel.  I also appreciate that this is a much more complex programming challenge whose time will hopefully eventually come.  Half heights will be a great step in this direction.  In the meantime, I'm hoping to grab the "low hanging fruit"... the things with the most impact for the least (or lower) amount of programming time.  And artist's time, for that matter.
Current projects: Pak128 Trees, blender graphics

Dwachs

Thank you for sharing your ideas!

As to the individual points raised:

(1) alpha transparency: should be doable. Of course it will cost some performance. I do not know how large that performance hit will be.

(2) multi-tile buildings: as long as these buildings are created by upgrading smaller buildings (smaller both in levels and in covered tiles) the implementation should be rather straightforward. Imho this is the lowest hanging fruit in the list.

(3) true shadows: In order to make it look right, each pixel in each game object has to get height information (what is the height of the pixel above ground). Then one can try to blend the shadows on objects behind (further performance hit ofc).

(4) finer granularity of landscape height levels: This would require an entirely different approach to storing height data and to rendering the terrain than what is currently implemented.

(5) I would like to add another item to the list: smoother track and vehicle graphics. This would require more views from vehicles, curves with different radii, etc. Then consequently also changes to the vehicle movement system. Just dreaming loud :)
Parsley, sage, rosemary, and maggikraut.

Markohs

#4
Quite a long post, Sarlock, thank you for contributiong your ideas.

Can't comment your message in-depth now, but, some fast comments:

About smooth image merging you comment can only be achieved using a hardware 3D renderer like I'm trying to implement myself. You can se in this SS the result in one of my tests.

http://dl.dropbox.com/u/30024783/Untitled16.png





About the shadows, I don't think it can be achieved without a heightmap or real 3D objects and real ilumination. I whoudn't implement the algorithm you menction, because it won't look good most of the times, and it's not worth it imho.

About the multi-grid objects, I agree on your points, it's something it whould be nice to look into. Take note in SC what's strange it's a 1x1 building, pretty often "squares are 6x4, 6x5 or 6x6, where each "house" uses to be 1x2, 1x3, 2x2, or 2x3. Even 3x3. Here in simutrans just your simple building replace whould not render good enough results imo. We need to change more for this to work. And respecting roads (sc4 respects roads also, it's just that squares are way bigger, so it has more flexibility to re-assign places).

I also like to compare simutrans to Simcity4, because it's how I'd like simutrans to look like, it's my personal reference. The new SimCity is 100% 3D, and it's looking great so far from what I saw, I hope we can reach a point close to it.

oh, and about alpha transparency, I think it¡'s something we should implement some day.

Roads

I am happy to see this thread.  I support improving graphics in the game.  Perhaps some of these ideas will not work or not be worth the effort but to get to a new and better end result, ideas are what is needed, that is where the creative process begins.

I would like to add a couple of thoughts.  IMHO, the residential squares should be changed to 2x2.  The reason for this is blocks of townhouses are common almost everywhere.  New ones are not so much common in the U.S. now but existing ones are often very valuable real estate.  Of course you only need a 2x1 to display those but what are you going to put in the 2x1 square behind them?  It makes more sense to have the townhouses cover a 2x2.  This way you have several options including an open space in the middle of the four squares, a parking lot on the back side or even townhouses facing the opposite direction on the back side.  Another reason is it simply gives more flexibility to the artist.  There are many things that can be done with a 2x2 that is simply not possible with a 1x1.  Many are possible with a 2x1 but there exists the problem of what the game will place on the adjacent back side.

The other thing I want to say something about are the shadows.  I don't think black is a good color choice.  It is very easy to get an inky looking spot with black.  Also I think creating shadows on a macro level would be very tricky.  Maybe it would be better if the artist just included those in his graphic?  Simply leave it up to the artist and the comments on his work to decide.

Ters

As Markohs demonstrated, there is work being done on improving the visuals of Simutrans. Simutrans is quite old in computer years, and isn't too easy to change since some things are tightly intertwined that perhaps shouldn't. More graphics hacks is probably the last thing it needs, as there are several hard to remove bugs there already. I believe a rather intensive rewrite in the graphics code is needed to open up new possibilities. It is underway, but it's going slow.

prissi

Shadows are not really doable, as they would need to move during the cause of a day. I had once a version creating some "weather" overlay (like snow just before winter) and it was nice but affected performance very badly. Do not underestimate it. Simcity may cheat on this (as many other games do) as most of these details are switched off when tilesize of 64 or so are reached.

A 50% and 25% blacked transparency is imho enough for most stuff (especially since simutrans only use 15 bit colors internally). The problem is rather that non-way isometric tiles are not very well suited for overlapping other tiles. The way tiles actually consume about 50% of the drawing time for less than 10% of the tiles. But alternative shadows are debateable. I would suggest not as transparency, but rather as special color.

And just look at the goldrush scenario for OpenTTD. All 100% tiles, no 3D engine. And the OpenTTD engine has even more limitations. http://goldrush.badbrett.se/#0.0 or see here: http://forum.simutrans.com/index.php?topic=4473.25

Same for the old transport giant. Those were also only tiles (but this game also had not mountains, all flat. Thus good graphics can be done. But that need also rather a professional approach.

OpenTTD uses less than 20 buildings for its towns, compared to the >100 even for small sets in simutrans. I would wager also Simcity has less houses than most paks in simutrans. Thus you would need to make a pak with closed supervision from a single contributing team. Most houses for pak64.german from MHz were usually renders at 256x256 and gave an impression what would have been possible. Also pak128.germans industries are amazing.

But then, the goldrush scenario is now alsready in its third year without  release ...

Markohs

 It's true that for the 3D renderer to work correctly ideally there must be a small number of buildings, ideally they should fit in a 2048x2048 or 4096x4096 texture atlas. Maybe in 2 or 4 of them, but not much more. And current paks have way too much images on them.

This is a example of a texture atlas.

Don't know the exact numbers, but iirc pak128 had 50.000 images. I'm pretty sure even if we split images by category (road,vehicles and buildings) we'll have serious problems managing so much images.

kierongreen

Some simutrans graphics artists produce images which are of commercial standard for sure. The limit is not the talent of the artists but the time they have. Also commercial artists are likely to churn out graphics much quicker than most people doing it for a hobby I'd say.

So, addressing points individually:
1) Smoothed edges/partial transparency
My new landscape code includes routines for 5 bit transparency in addition to 15 colour bits. 24 bit colour 8bit alpha would need new image loaders but is otherwise fairly easy to implement. Speed would definitely suffer - my routines can be down to half the speed of the ones with 1 bit transparency. Look at new images in oTTD to see what 24/8bit can achieve on it's own - it's quite impressive if you have artists willing to produce the images.

2) More multi-grid objects.
Also fairly easy to implement. Although this would I think lead to most city graphics needing to be redrawn eventually as 1x2 would be the obvious standard size for houses.

3) Shadows
Nigh on impossible to implement (properly) in 2d without:
a) Requiring a lot more data in images.
b) A lot of complicated code.
c) Slowing the program hugely.


QuoteI feel there is an entire market of players out there who would gravitate to this game if it was more graphically impressive.  Artists, programmers and other volunteers.
Here is the advantage that something like SimCity has. Professional graphics to start with means that user added content needs to be of the same standard to fit in.

Simutrans on the other hand offers the opportunity for people who might not have yet developed their graphical skills to quite the same extent to still contribute.

QuoteWith a more subtle gradient model, allowing perhaps both 8 partial steps of height, and perhaps up to 8 multiple tile steps (ie cliffs!), with a foreshore at / near sea level (giving beaches), I can see the landscape being more natural, and capable of more flexible expression of different terrain characters.
Cliffs can already be made. It's relatively simple to extend them to any height, my double/half height patch increases their maximum height also for example. Anything beyond half/double heights definitely needs a full 3d renderer, which in turn means the only practical way forward is a fully 3d simutrans. Fully 3d simutrans also solves the shadow problem. This is a LOT of work (though Markohs did make significant progress on this). Downside is also reducing compatibility and performance, and throwing away a lot of existing artwork. A fully 3d landscape would need certain logic to place ways and buildings and this would also not be as easy to use as current simplified landscape.

Personally I can see 1 and 2 happening in next year or two maybe. 3 can only happen with fully 3d simutrans, and I don't think that will happen myself.

Sarlock

Thanks for that, prissi, those are some interesting screenshots.

I was thinking, while laying awake in bed last night, about this a bit more and I had come to a similar thought about this.  If we can constrain transparency to just 0%(default)-25%-75%-100%(which we already have with #E7FFFF), it would still give a lot of options graphically.  To retain backward compatibility to all previous material, it could be defined in the .dat if a special colour outside of the defined special colour set is used.  ie:

set_transparent=#000000,25

Setting colour #000000 to be 25% transparent in the referenced PNG material for this object.  This would allow for custom use of special colours in an image without "breaking" that colour in all previous images that used that colour.  It also means that the artist can select which colour(s) are special in that particular object.  Could we set that special colour transparency to be any percentage from 0-100?  How many colours could an artist assign?

Could the same be done for lights?

set_light=#888888,#FFFFFF

Turns colour #888888 to pure white at night.  Is the special colour data processed at the makeobj stage?

Could we then combine the same colour for both light and transparency?

set_transparent=#800000,50  ; set colour #800000 to be 50% transparent
set_light=#800000,#B00000  ; make colour #800000 become #B00000 at night

Would it be possible to combine the two conditions for this pixel so that it is still 50% transparent at night with its assigned nighttime colour?  This would allow streetlights on roads to illuminate vehicles: an amazing night-time effect!

I love the ideas here.  What I'd love is an improvement to the graphics that 1) isn't a big programming job, 2) doesn't tax the system much and 3) allows all previous material to still work fine.  The more that can be done at the makeobj stage, the better.  If it's a big overhaul, it's likely to take a very long time to happen, if ever.  Simple is best.

I was thinking that for shadows, if the pakset favours a higher sun angle, the shadows will be shorter and mostly constrained to the tiles.  The tall buildings would just have to have no shadows... but I think the eye will generally accept that if most things have shadows.  This can be a pakset decision (pak128 uses a 60 degree sun angle from due South).

Also, I think most Simutrans players are probably using a medium zoom level for most of their playing time.  Full zoom in Simcity might look nice but no one actually plays the game at this zoom level -- it's way too close.  Making things look pretty at a medium zoom is what counts, I think.  And this also plays in to performance, as you could easily have 5,000-10,000 or more tiles on the screen at any one time at full screen on a big monitor.

From a building tile perspective, having 1x2/2x1 and 2x2 building choices would open up a huge amount of doors.  There are a lot of 2x2 spaces created with the natural road construction that happens with expanding cities, so finding spots will be easy.  The algorithm could actually just average out the levels for the 2 or 4 1x1 buildings it is replacing so that there is just a net small increase in overall population and level for the city, just as it would for a normal upgrade of a 1x1 building to its next level.  A level 5 residential building that is 2x2 would have the same mail and passenger demand as 4 1x1 buildings of level 5.  Doing buildings over 2x2 would require changing the road building algorithm and this runs into all sorts of problems... so 2x2 would be just wonderful.
Current projects: Pak128 Trees, blender graphics

prissi

There are currently 15 special colors, which are open for pak sets to change at their likeing. But pak set wide, not image wide.

Dynamically define in pak sets different colors is indeed easy. But then the source of images is no longer worked on by tools like shades. Run these images through shades (or gimp scripts) is also an easy option, which would remove the shadow from olf images (or even convert those grids to shadows).

Restraining to black 25% 50% and 75% transparency would have also the advantage of unimpotant drawing order, since it will darken anyway. Otherwise color would depend on overlay options.

Airline graphics are shadows simply drwan. Follow an aircrash and observe the various interesting shadows clipping on the ground ...

An_dz

#12
I'm not sure if there's a way to code it, but I thought about creating a heightmap from 2D graphics.
We know the axis, so I think we can create a 3D from a 2D image. With some algebra you'll probably create a 3D object.

But without creating any 3D object from this you can probably make the shadow understand where it touches a face of another object.

Check my example here, on the first tile there's a tree from 96comic. It has a shadow but I've removed and created my own in a new tile. It's to be exactly a projection from a light coming from the South. In the third tile is the post processed image with a 25% Opacity.

The shadows will always be hidden from the object faces so we can create the right projection on the wall, as you can see on the first building. On the second building I've got the post-processed version placed on the spot and I've drawn a line touching the treetop with the shadow of the treetop. This made me place the wall projection on that location.

As the shadow is parallel with the X and Y axis I thought about the angle between the X and the Z axis. This angle is shown as the word 'a' in the second building. I found that the width is twice the height meaning the tg(a)=1/2.

In the third building image I checked the distances and I've found that the treetop shadow is 12px below the treetop, and that the distance between the first pixel below the wall face is 24px far from the middle of the image and it's the same distance from the first pixel on the wall to the middle of the image.

When I've moved the tree near the wall this ratio kept the same. But this ratio is only when the shadow is parallel with the X axis, if you change the angle the ratio changes.

kierongreen

For a number of reasons I'm in favour of separate images for special colours. This allows a lot more flexibility as you can use each of the rgba channels in that separate image for different effects - e.g. r for player colour 1, g for player colour 2, b for non darkening colour,a for transparency (well maybe 8 bits for each of these is overkill, but we need to have several levels of each for smooth antialiasing). Trying to pack more and more effects into the 15bit image isn't a long term solution in my opinion.

Edit: Potentially you could use one channel for either height information or angle for shadow calculation purposes for example.

Combuijs

QuoteI'm not sure if there's a way to code it, but I thought about creating a heightmap from 2D graphics.
We know the axis, so I think we can create a 3D from a 2D image. With some algebra you'll probably create a 3D object.

You can't do that with algebra, you need magic  :) . There is no way that you can create a 3D from a 2D image without height information. Impossible. When you are viewing the picture, you can do it in your mind because you see a house: 2 walls and a roof. In reality there is only a few pixels, no wall and no roof.

Further, your projection algorithm supposes that the wall of the house starts at the edge of the tile, but that is not always (or rarely) the case. If the wall is a bit further from the tile you get very funny effects, as with the case where there is no wall at all.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



VS

Kieron - Agreed about the 15 bits :) However, if you set transparency aside, no need for more than one additional channel, imho. All "visually smooth" information can be in current image. Then, just use the new channel to signal an enum (normal, primary, secondary) and flag (no-dark) that says how to treat the normal image. With some clever bit layout, the resulting grayscale map would be even easily read by humans.

As to shadows - it's all too complicated for my tastes. Normal maps? Height maps? Reminds me of that wtf moment when during my diploma thesis presentation, some important guy found out that "images" can be complex, not only rgba. Then, he insisted that I show him the complex image and could not get his head around dual display for magnitude & phase.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Markohs

kieron suggestion makes sense, it's also way easier to implement with pixel shaders if post-effects are in one image replica.

I'd go 32-bit rgba through, because on OpenGL/3D engines alpha enable packing formats are:

4_4_4_4 (4_4_4_4_REV): unsigned shorts.
5_5_5_1 (1_5_5_5_REV): unsigned shorts.
8_8_8_8 (8_8_8_8_REV): unsigned ints.

The first one narrows resolution per channel a bit too much and the second second just has absolute transparency

On the extra copy we can use each channel for whatever we want, as you already suggested player 1 player 2 and non-darkening pixels. This can be implemented without much problems with pixel shaders I  think. And on the current simutrans we can allways recode the image on load, to save memory usage and game speed. On a 3D enviroment that doesn't matter because it's all work on the hardware.

But this is just an idea, whould require more experimentation.

I know the 3D version doesn't even exists atm, but if you are going to change image coding, whould be nice to focus in a way that's compatible with it.

An_dz

Quote from: Combuijs on October 23, 2012, 08:49:23 PM
You can't do that with algebra, you need magic  :)
I thought so.

Quote from: Combuijs on October 23, 2012, 08:49:23 PM
Further, your projection algorithm supposes that the wall of the house starts at the edge of the tile, but that is not always (or rarely) the case. If the wall is a bit further from the tile you get very funny effects, as with the case where there is no wall at all.
The idea would add in the source of the object that gray basic shape of the building to let the shadow know if it's overlapped by any wall. And then apply the effect. Setting some defaults color, like 50% black for south, 0% west, 100% top. Anyway it won't work in complex buildings, at least not with way more stuff to slow down.

isidoro

As for point 2 (multi-tile buildings), why just limiting to 1x1, 2x1, 2x2?

An idea I pointed out some time ago is to allow all kind of dimensions but based on 1x1 blocks.  You can have a 7x1 "building" representing some terraced houses with only three different basic blocks 1x1 (both ends and houses in the middle).

That way of building would force you to say in pak files which blocks are compatible with which and when a building can be considered completed.  But the algorithm is already there! (i.e. when you build a train consist)  One only has to extend it to 2D to get it to work for buildings.

You can get not only bigger buildings, but also, realistic city walls, fences, parks, football fields of any size.  If pak designers are smart enough, they could even build quite a variable pakset with not so many different images... just combining them...


Roads

Wow!  Isidoro, that sounds great!  It is only good to have more options as far as painting goes, thought the big sticky wicket was programming...

prissi


Lmallet


isidoro

Good news!  Although I first understood that it had become open source...  That would have been better news...

I like the graphics of that game.


el_slapper

Well, I've always thought that Transport Giant's Music was the best part of the game. I'm a huge fan. For the gameplay, well, it's not bad, but no match against Simutrans.

Fabio

Quote from: prissi on October 23, 2012, 08:19:29 PM
There are currently 15 special colors, which are open for pak sets to change at their likeing. But pak set wide, not image wide.

Dynamically define in pak sets different colors is indeed easy. But then the source of images is no longer worked on by tools like shades. Run these images through shades (or gimp scripts) is also an easy option, which would remove the shadow from olf images (or even convert those grids to shadows).

An elegant way to add more (infinite) windows colors would be addine just ONE new special color (maybe mapped replacing one of the existing colors).
This new color would be transparent during day and window light at night. This color could be placed in the Front Image layer thus letting the Back image show during day, but lighting up at night.
This behavior could be coded to be "special_color[0]=-, 0x65, 0x6F, 0xD3, 0xC3, 0x80", where the "-" would mean transparency.




About real PNG transparency, I agree that 5 bit transparency could be more than enough (100% - fully transparent; 75%; 50%; 25%; 0% - fully opaque). On the other hand, I believe PNG  sources should have a full Alpha channel and Makeobj should do the job of thresholding the alpha channel (e.g. 0-12%->0%; 13-37%->25%; 38-62%->50%; 63-87%->75%; 88-100%->100%).
This way #E7FFFF would become obsolete and possibly reused for the special color requested in the first part of this post.

Sarlock

I agree, that was my thought, Fabio.  If a PNG image is processed through makeobj, it strips the 8 bit alpha channel and reduces it down to whatever number of bits works best (2, 3, whatever).  I'd even settle for just a 50% transparency option as a compromise... since we already have 100% as #E7FFFF.  That would allow shadows at 50% transparency instead of dithered as they are now.  You can have a half-decent looking anti-aliased edge at 50% transparency.  If we get 2 bits, we could have transparency settings of 20/40/60/80.

This allows all old graphics/addons to still work the exact way they did before.  It's just 32 bit alpha PNG's that have the transparency bit processed at makeobj time.  24 bit PNG's would just be processed like they are now.

Then we add setting custom special colours in the .DAT file.  They are applied to the image at makeobj time.  Items that require processing at run-time (I assume this includes night lighting) get passed with the .PAK to Simutrans.  The number of custom special colours can be limited to a manageable number.  Having 6-8 custom special colour options we be great.

IE:

specialcolour=#8F0000,50,#8F0000

This assigns colour 8F0000 in the PNG file to have a night colour of 8F0000 with 50% transparency.  During the day this colour would be assigned the transparency it gets from the .PAK information.

This also allows us to turn off shadows at night.  If we used #000000 to be our shadow colour, then we set:

specialcolour=#000000,100,#000000


This makes the setting of custom special colours and alpha transparency reserved for those who actually want to use it.  The old method of making PNG images in 24 bit will work just the same as it did before and all old addons and imagse will work just as before.
Current projects: Pak128 Trees, blender graphics

Fabio

Actually the part I would like the most to see is the first one: the possibility to have a color be transparent during day and lit at night. This would help hugely with glass buildings, as they could be textured much more naturally and yet have windows lit at night.

Sarlock

You could create night lights that way, too.  You have a FrontImage that has a 100% transparent light colour and at night that colour is assigned 50% transparency so that when night comes, the light adds to the colours on the BackImage and creates the effect of night lighting.
Current projects: Pak128 Trees, blender graphics

ӔO

My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

mEGa

It's hard for me to understand problem and suggestions for solutions (I'm poor english speaker and poor technician) , but I'm agree about to enhance graphics and get transparency. So I completely  trust you like experts. I also hope that there will be a precise documentation when the modifications will have arrived.

Current projects in progress : improvements of few designed french paks

prissi

But most of that stuff is not really needed for nice graphics. If you just got to the pak US demo from the OpenTTD buldings: Those are completely devoid of any transparency problems. The problem is rather that most buildings are not realistic enough be to generic and lacking too much detail from the beginning. pak128.german factories are nice examples what can be done, and rmax hand drwan pak128 are probably the limit on hand draw stuff.

50% transparency for shadows why not. But for a completely different overlay system I still have to see a graphics that requires this.

Fabio

Quote from: prissi on October 29, 2012, 10:06:01 AM
But for a completely different overlay system I still have to see a graphics that requires this.

I asked something different: using existing front/back images, I would like to place in the front image a special color which during daylight is totally transparent (like #E7FFFF) but at night is lit like a window. Basically, what I'm asking is the possibility to map a special color to totally transparent as well. I believe this won't require any heavy implementation, as everything is already there.

Sarlock

That would make all sorts of night lighting options being able to do that with FrontImage.

I tried making a street light with 50% transparency that comes on at night but it doesn't look right.  The only way to realistically do that would be to be able to restore some of the original light intensity's brightness rather than masking a colour over that section with some percentage of transparency.  Not worth the work to do that.

50% transparency makes very nice looking shadows, however.

To summarize:

[#1]: 50% transparency option, set as a special custom colour in each .DAT?  (that way we don't "break" old addons and graphics that may have this colour)

set_custom_transparency=#010101,50  [sets this custom colour to be 50% transparent]

Effect:




[#2]: Option to customize special colours in .DAT file.  Special colours can be set to have a different night colour and transparency level (50% or 100%).

set_special_colour=#020000,100,#FF0000,0  [sets a special colour, #020000, to be 100% transparent (invisible) during day and colour #FF0000 at 0% (fully visible) for night)

Effect, using colour #020000 as 100% transparent during day, #FF0000 at night, as FrontImage:



This is just a silly example.  Some great effects can be done with this method.


#2 might be more difficult.  Hopefully #1 isn't too much work.
Current projects: Pak128 Trees, blender graphics

kierongreen

If we are changing graphics format my opinion is this should be done once only and should include methods for various levels of transparency as well as special colours for player colours and nighttime effects. For maximum flexibility that means going to a full 32 bit rgba format, probably png, with additional images for player colours and non darkening nighttime colours. Of course nothing currently would take advantage of this, it would be for pakset maintainers to decide whether to redraw graphics.