Author Topic: Graphics engine improvements  (Read 1146 times)

0 Members and 1 Guest are viewing this topic.

Offline wlindley

Graphics engine improvements
« on: December 26, 2016, 02:49:20 PM »
If the flow and the graphics engine itself are being revised, would it be desirable to
  • make large (multi-tile) buildings natively understood by the engine, without any additional tools or steps
  • give the pak file format the ability to reuse the same graphics component tile without repeating the data each time, so modular buildings could use far less disk space
  • let industries and stores utilize the "player" eight-color primary/secondary scales for the one or two colors associated with each industry, so a single store-front or modular factory building could be used in numerous building designs (This could be done by substituting player-colors for industry-colors when the game reads the pakset into memory.)
I would like to expand the modular industry work I started, and those would make my life much easier.


Indeed the third suggestion, of reusing player-colors, has the potential to eliminate most of the "reserved" color problems from the entire workflow, does it not?

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15125
  • Total likes: 353
  • Helpful: 153
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Graphics engine improvements
« Reply #1 on: December 26, 2016, 02:56:35 PM »
I have moved this from the topic about switching to a transparent workflow in Pak128.Britain, as this is really a set of requests for improving the graphics engine in the code rather than discussion about how to make use of the recently implemented transparency feature.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4544
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: Graphics engine improvements
« Reply #2 on: December 26, 2016, 04:02:38 PM »
make large (multi-tile) buildings natively understood by the engine, without any additional tools or steps
The engine can't really do anything about this. It must be fed the rightly cut 2D images so that it can create the correct illusion of 3D. For objects that do not overlap with any other objects, I guess makeobj could possibly do this. This is a minority of the types of objects.

give the pak file format the ability to reuse the same graphics component tile without repeating the data each time, so modular buildings could use far less disk space
This has nothing to do with the graphics engine, but with data structures that drive almost everything in the game. Unfortunately, it is difficult to make such big changes without dropping support for the existing file format. One could perhaps make some conversion programs, but that might not be legal for some pak sets or add-ons.

let industries and stores utilize the "player" eight-color primary/secondary scales for the one or two colors associated with each industry, so a single store-front or modular factory building could be used in numerous building designs (This could be done by substituting player-colors for industry-colors when the game reads the pakset into memory.)
Might perhaps not be too difficult, but as always, it requires a developer who cares.

Offline wlindley

Re: Graphics engine improvements
« Reply #3 on: December 26, 2016, 05:09:43 PM »
Pak file format: Looks like we could change besch/image_writer.cc, starting about line 400, and define the next version (4) to contain a 32-bit value which would be either 0 (for literal image data follows) or nonzero (for the offset relative to current file position of the image data). As a relative value, that should work even when appending pak files, with a little care.  That should make reading the files easy.  I'll look more to see how we could detect already-written images.

Offline wlindley

Re: Graphics engine improvements
« Reply #4 on: December 26, 2016, 05:25:32 PM »
Also, besch/reader/image_reader.h contains code that re-uses existing images already read from disk. Around line 150: If the "Adler hash" of a newly-read image matches one of an existing image, it checks the image size and all the image data and in the event of a duplicate, re-uses the existing structure. The pak file may be able to simply say, "Use an existing image with Adler hash xxx" to trigger this condition directly, instead of writing the same image over and over.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15125
  • Total likes: 353
  • Helpful: 153
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Graphics engine improvements
« Reply #5 on: December 26, 2016, 05:32:00 PM »
These are some interesting ideas; the difficulty, I suspect, may well be developer time rather than the soundness of the ideas in principle.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Leartin

Re: Graphics engine improvements
« Reply #6 on: December 26, 2016, 05:43:35 PM »
Quote
give the pak file format the ability to reuse the same graphics component tile without repeating the data each time, so modular buildings could use far less disk space
What if Simutrans could read dat+png directly from a zipped file? This would work around the pak-file-format problem, at least for open paksets. Plus testing new objects would be a lot easier too - though loading time is probably longer.

Quote
The engine can't really do anything about this. It must be fed the rightly cut 2D images so that it can create the correct illusion of 3D. For objects that do not overlap with any other objects, I guess makeobj could possibly do this. This is a minority of the types of objects.
While the engine of course can't do anything about it, makeobj should be able to learn it. Feed it with, say, an 128*128 image for pak64, tell it it's a 2*2 building, and makeobj processes the image accordingly. The engine would still get the same data structure as before. I guess I'm saying one could combine makeobj with tilecutter, minus gui, to make the workflow for pak creators easier.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4544
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: Graphics engine improvements
« Reply #7 on: December 26, 2016, 06:47:07 PM »
The problem is that the pak format mirrors the internal data structures (or vice versa).

And makeobj can't read your mind, so it will only be able to partition very simple buildings.

Offline DrSuperGood

Re: Graphics engine improvements
« Reply #8 on: December 26, 2016, 07:14:00 PM »
Quote
Pak file format: Looks like we could change besch/image_writer.cc, starting about line 400, and define the next version (4) to contain a 32-bit value which would be either 0 (for literal image data follows) or nonzero (for the offset relative to current file position of the image data). As a relative value, that should work even when appending pak files, with a little care.  That should make reading the files easy.  I'll look more to see how we could detect already-written images.
Or one could change the base format to be compressed in some form which would do that implicitly to some extent. Also it would have to be 64 bit field as file offsets are 64 bit (all modern OS and partition formats allow >4 GB files).

As if disc space is a problem. In this day and age most new non-portable systems have ~1 TB of storage and even the biggest Simutrans paksets, pak128 Britain, only use <200 MB at the moment. In contrast a game like StarCraft II uses >10 GB.

Quote
Also, besch/reader/image_reader.h contains code that re-uses existing images already read from disk. Around line 150: If the "Adler hash" of a newly-read image matches one of an existing image, it checks the image size and all the image data and in the event of a duplicate, re-uses the existing structure. The pak file may be able to simply say, "Use an existing image with Adler hash xxx" to trigger this condition directly, instead of writing the same image over and over.
How much memory are duplicate images actually eating up? Map size plays a far more dominat role at consuming memory than the pakset. For example the one experimental server ran Simutrans at over 2 GB because it was 5000*7000 tiles or something outright insane.

If memory usage is a problem this could be solved by a total graphic rewright so that GPU memory could be used to hold all the sprites instead of CPU. This however is not a small task and would need decoupling of graphics from game state to be efficient (why all previous attempts have failed).

Quote
What if Simutrans could read dat+png directly from a zipped file? This would work around the pak-file-format problem, at least for open paksets. Plus testing new objects would be a lot easier too - though loading time is probably longer.
Simutrans really needs a better data solution than currently. It should not be loading everything, especially assets (artwork), when they are not needed. For example StarCraft II streams assets as they are needed rather than loading all >10 GB of assets at once. Actual object data can probably be fully loaded without any issues because it is tiny compared with all the associated artwork the objects use. In the average Simutrans game only a small fraction of all the art is in use at any time, especially seeing how much of it is related to game progression (early assets fade out during late game, late assets not available early game).

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8685
  • Total likes: 294
  • Helpful: 228
  • Languages: De,EN,JP
Re: Graphics engine improvements
« Reply #9 on: December 26, 2016, 09:44:30 PM »
Simutrans reuses identical images in memory; they only contain more space on the disc.

Multitile residental buildings require code changes on the city-rules, non-trivial ones. Automatic multitile buildings is indeed something around the read-my-brain for slightly more complex buildings.

Playercolor is limited to a shade of 24 colors. Hence mapping industry color to a player color with 16 shades is not straight forward. However, having the industry colored with a different player color (or, any buidling apart from stations and depots), is probably quite easy to implement. But you would be limited to one of 16 (random?) player color schemes. OpenTTD uses this a lot to have more variation of their very few (13) base houses.

Offline kierongreen

Re: Graphics engine improvements
« Reply #10 on: December 27, 2016, 01:13:59 AM »
I'd note that generally it would be better to have buildings that had more than colours as their only difference to distinguish them to help people who aren't as sensitive to colours.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4544
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: Graphics engine improvements
« Reply #11 on: December 27, 2016, 10:39:40 AM »
I'd note that generally it would be better to have buildings that had more than colours as their only difference to distinguish them to help people who aren't as sensitive to colours.

As long as the colors are only meant to create greater visual diversity with little effort, it should be okay. The buildings should have the same attributes otherwise, so not being able to see the difference won't mean anything for playing the game.

When trying to do hardware accelerated rendering, I split (or thought about splitting) the images (both front and back) into three layers that were later combined by a shader according to parameters. One layer contained the plain colors. Another layer contained the lights, and the parameters used here was the correct colors for each type of light for the current time of day. The third layer contained player colors, with the layer containing the shade-index and the parameters being which player color to use and the gradients for all the player colors. Unfortunately, doing this without hardware acceleration might be awfully slow, and adding hardware acceleration requires reworking almost everything to work effectively.

Offline The Hood

Re: Graphics engine improvements
« Reply #12 on: December 27, 2016, 11:30:50 AM »
If the flow and the graphics engine itself are being revised, would it be desirable to
  • make large (multi-tile) buildings natively understood by the engine, without any additional tools or steps
  • give the pak file format the ability to reuse the same graphics component tile without repeating the data each time, so modular buildings could use far less disk space
I would like to expand the modular industry work I started, and those would make my life much easier.

Here's a different way at looking at this which I think would be more powerful in the long run - it would require changes to the game code. Define a new object type as a "zone" which is made up of different building components 1x1 or even possibly larger. For example:
- coal power station "zone" made up of several different "buildings" representing coal storage bunkers, furnace/turbine hall, cooling towers, etc. Each "building" would have storage or production capacity. Upgrading production would work easily by either adding extra "buildings" (a bit like fields) or higher levels of building (a bit like city buildings).

This would allow a greater variety of building layouts and morphologies so all power stations don't look identical. It would allow irregular shapes that grow around landscape and e.g. stations and roads. It would also allow the "zone" to evolve over time as newer "buildings" are introduced so the same factory looks more modern as it gets renovated bit-by-bit over time.

The same concept could also be used in cities e.g. for shopping centres (commercial "zone") or large housing estates (so you could get large blocks of e.g. 1960s housing estates looking similar but not identical, and still fitting around roads etc.) or attractions (e.g. schools or universities that add extra blocks over time).

I'd love to see this - I think it would be very flexible and a great addition. But how much effort? Could we not just reuse a lot of existing citybuilding upgrade code?

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15125
  • Total likes: 353
  • Helpful: 153
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Graphics engine improvements
« Reply #13 on: December 27, 2016, 11:39:48 AM »
One would need to be able to accommodate graphics for large, non-modular buildings, too. Multi-tile city building recognition is something that is a long-term aim for Experimental; much of the work on this has in fact already been done in the passenger generation code (multi-tile attractions and industries function as one single building rather than a set of one tile buildings for passenger generation purposes), but what is needed (and probably very difficult) is a system for knowing where to build them inside towns: currently, multi-tile buildings such as industries and attractions are built only on undeveloped land and not in place of existing buildings, unlike 1x1 city buildings, which can upgrade. The complexity is allowing a block of nearby buildings to "upgrade" as one to a single building.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4544
  • Total likes: 165
  • Helpful: 106
  • Languages: EN, NO
Re: Graphics engine improvements
« Reply #14 on: December 27, 2016, 12:02:03 PM »
Here's a different way at looking at this which I think would be more powerful in the long run - it would require changes to the game code. Define a new object type as a "zone" which is made up of different building components 1x1 or even possibly larger. For example:
- coal power station "zone" made up of several different "buildings" representing coal storage bunkers, furnace/turbine hall, cooling towers, etc. Each "building" would have storage or production capacity. Upgrading production would work easily by either adding extra "buildings" (a bit like fields) or higher levels of building (a bit like city buildings).

This would allow a greater variety of building layouts and morphologies so all power stations don't look identical. It would allow irregular shapes that grow around landscape and e.g. stations and roads. It would also allow the "zone" to evolve over time as newer "buildings" are introduced so the same factory looks more modern as it gets renovated bit-by-bit over time.

The same concept could also be used in cities e.g. for shopping centres (commercial "zone") or large housing estates (so you could get large blocks of e.g. 1960s housing estates looking similar but not identical, and still fitting around roads etc.) or attractions (e.g. schools or universities that add extra blocks over time).

I'd love to see this - I think it would be very flexible and a great addition. But how much effort? Could we not just reuse a lot of existing citybuilding upgrade code?

Fields should be able to do some of this. As far as I have understood it, there can be several different types of fields, but I have never seen how it works, if it works at all. A limitation is that all tiles must be able to combine with all others in every direction, which means that the architecture can't be too fancy. Getting around this is lot of work for both coders and artists. I don't know if fields can have multiple height levels, but that might not be too difficult to change.

Offline DrSuperGood

Re: Graphics engine improvements
« Reply #15 on: December 27, 2016, 02:47:11 PM »
Each sort of factory type would need its own set of construction rules. A Supermarket would open other shops and take advantage of streets where as a coal mine would open up new mine heads or open cast pits. Factory build rules would then need to change, promoting bigger factories over multiple same sized factories with cities showing specialization to some extent.

Fields do not have the required placement logic or mechanics as far as I can tell. They do not even really make sense...

I thought about a way to implement this a while ago. It would require some form of basic "zoning" logic. A zone would be an arbitrary rectangular area which does not overlap with any other zones. Each zone can contain at most 1 factory, and the factory determines the zone construction logic. Cities are a collection of zones, each potentially having certain construction styles. When a city expands, it does so by fragmenting a nearby empty zone and adding it as a city zone. Two cities cannot share zones, solving city overlap problems that currently exist. Industries can expand their zone by consuming space from a neighbouring zone based on priorities, with consumers getting highest priority (as they represent prime commercial land) and low density producers having the lowest priority (no one cares if a few acres of field or a mine head vanish). When part of a zone changes purpose the buildings that are no longer suitable for the new purpose are slowly removed and replaced. Producers such as farms would have massive zones and automatically tile the entire zone with field to produce a more realistic world with massive rolling fields instead of tiny fields in seas of grass. Placing any part of a stop inside a factory zone could give access to the factory that governs it. The factory itself could then be tied to the zone rather than a building, allowing players more freedom to demolish lesser industrial buildings or farm steads for better line positioning. For logical purposes at least 1 set of functional factory buildings (eg a burner, generator hall, smoke stack and substation for a power station) cannot be destroyed by players so that a factory zone will always be able to produce something. Public service player would have special tools to modify zones, such as dezoning or rezoning zones. Zones would be generated by fragmenting the map into ever smaller rectangles with some randomness.

Online Vladki

Re: Graphics engine improvements
« Reply #16 on: December 28, 2016, 09:47:30 PM »
One would need to be able to accommodate graphics for large, non-modular buildings, too. Multi-tile city building recognition is something that is a long-term aim for Experimental; much of the work on this has in fact already been done in the passenger generation code (multi-tile attractions and industries function as one single building rather than a set of one tile buildings for passenger generation purposes), but what is needed (and probably very difficult) is a system for knowing where to build them inside towns: currently, multi-tile buildings such as industries and attractions are built only on undeveloped land and not in place of existing buildings, unlike 1x1 city buildings, which can upgrade. The complexity is allowing a block of nearby buildings to "upgrade" as one to a single building.

This seems to me partially done. I have seen a 5x4 attraction appear in the centre of the city in a server game - rearranging roads and destroying a block of houses. But perhaps some other player did that... :)

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15125
  • Total likes: 353
  • Helpful: 153
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Graphics engine improvements
« Reply #17 on: December 28, 2016, 09:53:33 PM »
This seems to me partially done. I have seen a 5x4 attraction appear in the centre of the city in a server game - rearranging roads and destroying a block of houses. But perhaps some other player did that... :)

Interesting. I have not really looked into the part of he code that chooses where city buildings are built. So far as I know, the code does either one of two things: either finds a suitable place on empty land on which to construct a new building, or upgrades an existing building to another type. There is no code as far as I am aware that looks for and demolishes a set of existing buildings to make way for a new building, so this may well have been player action (and the player action may have just been in the demolition; the game engine may have built the attraction on a space cleared by the player).

Can anyone who knows the position with respect to the city building code confirm the position?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Vladki

Re: Graphics engine improvements
« Reply #18 on: December 28, 2016, 10:14:37 PM »
Actually it happened twice. The current game has big castle in the city center. Before that I remember a small 1x1 attraction (tower) appeared in the middle of road, with roads all around (a roundabout). I have removed that as it was a traffic bottleneck. In both cases the main road has been rebuilt (moved one tile aside).

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15125
  • Total likes: 353
  • Helpful: 153
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Graphics engine improvements
« Reply #19 on: December 28, 2016, 10:22:24 PM »
Interesting. Is anyone with knowledge of the workings of this part of the code able to comment?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.