News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

A 3D Simutrans?

Started by RealAmerican1776, January 13, 2020, 07:53:35 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

RealAmerican1776

Hello, I recently stumbled on an old form about a 3D Simutrans and I would like to work on it. My first question is where I would start? I don't want to start from scratch and make a whole new game and I have little if any experience in coding.

jamespetts

This is an interesting thought, but this will be a very, very difficult project; not impossible, of course, but it will take a truly gargantuan amount of work.

The reason that there has not been any hardware acceleration for Simutrans so far is that the code is written in such a way that the graphics code is closely integrated with the main logic. I am no expert in 3d graphics programming, but from what I understand, this is fundamentally incompatible with the way in which it is necessary to code for 3d graphics to make them work effectively (i.e., for hardware acceleration to have any effect). Thus, in order to code a 3d version of Simutrans, you would need to rewrite a very large proportion of the existing code (perhaps 20-35%; this is a very, very rough guess).

Further, a 3d version of Simutrans would need all new graphics. The amount of work necessary to do this would also be enormous, although for somebody creating a new pakset in any event, this will not be an issue as there would be much work to do in any event.

The short answer is that this is theoretically possible, but truly enormously difficult. I do not recommend this to somebody who is not already very experienced in coding 3d graphics, experienced with the Simutrans code-base and knowledgable about coding generally.

I really do not wish to discourage you from doing coding work, but this is not a good first project because of how fundamental a rewrite that this would require, and I suspect that you would find the reality of trying this project more discouraging than realising in advance just how difficult that this is likely to be. If you are looking for a coding project, I recommend trying one of the projects from this thread.
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.

CK

Recoding Simutrans into 3D would almost definitely require a rewrite of the graphics logic. I think only things like pathfinding could be copied over.

Mariculous

I totally agree this would require an immense amount of work and really is not a project to start with coding.

ASV62

For 3D you'd better buy yourself Cities:Skyline , Transport Fever 2 instead, raster isometric image rendering nature would never change for Simutrans.

People who was born with this kind of lifestyle is an artist, while talents are philosophist ....

prissi

As for graphics, there are blender files for many objects in pak128 britain; but the level of detail is unlikely to give any satisfied 3D experience.

Mashinky https://store.steampowered.com/app/598960/Mashinky/ looks like it really combined 2D isometric tiles with realistic (as much as the scale limitations allow) 3D rendering. UNfourtunately it is too demanding for my old PC.

DrSuperGood

Quote from: jamespetts on January 13, 2020, 08:48:12 PMThe reason that there has not been any hardware acceleration for Simutrans so far is that the code is written in such a way that the graphics code is closely integrated with the main logic. I am no expert in 3d graphics programming, but from what I understand, this is fundamentally incompatible with the way in which it is necessary to code for 3d graphics to make them work effectively (i.e., for hardware acceleration to have any effect). Thus, in order to code a 3d version of Simutrans, you would need to rewrite a very large proportion of the existing code (perhaps 20-35%; this is a very, very rough guess).
A lot of this argument only applies to using 3D hardware acceleration to draw the current 2D graphics. The graphics are simple enough that the overhead of instructing a GPU to draw them approaches the time needed to draw the graphics directly, especially with older APIs like OpenGL. There is certainly little to nothing to gain from a performance perspective. The main reason one would want to do this would be to enable new graphic features which are worth the performance reduction trade-off as they would otherwise be too slow to perform on the CPU.

However if one scraps the existing graphic approach and instead goes full vector/3D then things would be a lot easier to implement. Pretty much only the graphic draw routines of objects would need to be rewritten to interface with a 3D engine. All object Z layering is solved trivially by the GPU Z buffer and complex terrain can be converted into static meshes. None of the pixel fill reduction optimizations (only redraw parts of screen that change) are required as one could get the GPU to redraw everything every frame anyway as that is its only job. The changes made to an object visually can be processed together during draw preparation. The GPU can also draw frames in parallel to the game updating state.

If one does plan to make a hybrid approach then I would suggest first abstracting away primitive graphic calls from object implementations and instead using some sort of actor/scene engine to handle the graphics. This should allow an efficient draw preparation stage which could produce more optimal draw commands. This engine would also be where new 3D/vector functionality could be hooked into since it can take consideration of the existing graphics. In theory a software fall back could still exist but chances are it will perform worse than currently and performance will certainly tank if it is expected to support 3D/vector functionality. For APIs there is OpenGL and Vulkan. I recommend Vulkan since it has at least some support on MacOS via MoltenVk unlike OpenGL which is stuck with an impractically old API version. In any case the minimum requirements of Simutrans would be raised considerably.

ASV62

Quote from: DrSuperGood on January 14, 2020, 05:46:45 AM
A lot of this argument only applies to using 3D hardware acceleration to draw the current 2D graphics. The graphics are simple enough that the overhead of instructing a GPU to draw them approaches the time needed to draw the graphics directly, especially with older APIs like OpenGL. There is certainly little to nothing to gain from a performance perspective. The main reason one would want to do this would be to enable new graphic features which are worth the performance reduction trade-off as they would otherwise be too slow to perform on the CPU.

However if one scraps the existing graphic approach and instead goes full vector/3D then things would be a lot easier to implement. Pretty much only the graphic draw routines of objects would need to be rewritten to interface with a 3D engine. All object Z layering is solved trivially by the GPU Z buffer and complex terrain can be converted into static meshes. None of the pixel fill reduction optimizations (only redraw parts of screen that change) are required as one could get the GPU to redraw everything every frame anyway as that is its only job. The changes made to an object visually can be processed together during draw preparation. The GPU can also draw frames in parallel to the game updating state.

If one does plan to make a hybrid approach then I would suggest first abstracting away primitive graphic calls from object implementations and instead using some sort of actor/scene engine to handle the graphics. This should allow an efficient draw preparation stage which could produce more optimal draw commands. This engine would also be where new 3D/vector functionality could be hooked into since it can take consideration of the existing graphics. In theory a software fall back could still exist but chances are it will perform worse than currently and performance will certainly tank if it is expected to support 3D/vector functionality. For APIs there is OpenGL and Vulkan. I recommend Vulkan since it has at least some support on MacOS via MoltenVk unlike OpenGL which is stuck with an impractically old API version. In any case the minimum requirements of Simutrans would be raised considerably.
Very intense work on rewriting the game engine needed for your new approach, and the current raster-based paksets would no longer compatible, some graphics inside paksets is already 10+ years old from the old 0.86 0.85 days.

Is it really worth the effort making the vanilla Simutrans engine into what you've think of? Compatibility issue and new function implementation are not finish yet. Is hardforking a 3D Simutrans from unstable builds ok for that?

The middle ground between raster and vector 3D gameplay is create new paksets out of export Sprite from Blender models.

People who was born with this kind of lifestyle is an artist, while talents are philosophist ....

Mariculous

#8
To adress the Z- layering, one does not neccessarily need to add a 3D engine to the game itself. Instead, one can bake that kind of information to a depth mapping channel/image at rendering time, which would describe the exact z-position of an object within one tile.
Moving objecs (or in general any object that is not aligned to the tile grid) will need to calculate their Z-offset from their 3D position within their tile, which then can simply be added to the values in the z-map.
Whilst such information is quite simple to generate for rendered 3D objects, it will be quite hard for 2d-artists to mannually paint these.
High buildings could even be supported without splitting them into multiple tiles thisway, as long as we paint the screen from top-to bottom, it will simply paint-over existing pixels behind it, which is even fully compatible to transparent objects.

In short, even without a real 3D engine ingame, we can maintain a z-buffer if we don't throw-away that kind of information from an external 3D engine (the renderer) at Render time.
This works, because we have a fixed parallel perspective.

prissi

I feel that in the end one gets something like Machinsky, where the isometric grid can be switched to 3D. However, this community has little experience in highly detailed 3D models (apart from pak256 perhaps ...) So it will be a total restart.

DrSuperGood

Quote from: Freahk on January 14, 2020, 08:09:17 AMo adress the Z- layering, one does not neccessarily need to add a 3D engine to the game itself. Instead, one can bake that kind of information to a depth mapping channel/image at rendering time, which would describe the exact z-position of an object within one tile.Moving objecs (or in general any object that is not aligned to the tile grid) will need to calculate their Z-offset from their 3D position within their tile, which then can simply be added to the values in the z-map.Whilst such information is quite simple to generate for rendered 3D objects, it will be quite hard for 2d-artists to mannually paint these.High buildings could even be supported without splitting them into multiple tiles thisway, as long as we paint the screen from top-to bottom, it will simply paint-over existing pixels behind it, which is even fully compatible to transparent
It would need to be GPU accelerated to not have a major performance impact due to the extra memory bandwidth used by the CPU to process the Z layer.

Currently Z is implemented entirely by sequencing draw calls.

RealAmerican1776

There is actually a way to make a 3D simutrans without having it be 3D, it will have to be a Pak520. It won't be the multiple views like in a 3D game but it will give you the detail for 3D. For example, I have a 0-6-0 road switcher from the days of the United States Railroad Administration, the nationalized railroad during World War One which was put into law by President Woodrow Wilson. You can see the differences in the image file and the amount of detail in the locomotive in 520 compared to something from the standard pak128. Would this be an option?

Mariculous

I don't understand this.
What exactly does 2D/3D have to do with the resolution of sprites?

Have a look at pak256 for extended if you simply want higher resolution graphics.

jamespetts

I believe that 256x256 sprites is the current limit of the graphics engine, so modifying the graphics engine would be necessary for 512x512 sprites (I am not sure why 520 specifically was chosen; 512 is a more normal choice, being a power of 2). I do not know how easy that it would be to modify the Simutrans graphics engine to allow 512x512 sprites, but I suspect that this would be much easier than modifying the code to provide for 3d graphics.

However, as Freahk says, it might be that you find 256x256 sufficient for your purposes, and that requires no coding work at all.
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.

RealAmerican1776

I have experimented with making different pak sets in Makeobj to see what it's capable of and 520 is the max size you can go. The problem with 520 is is that it's TOO big, you can see EVERY pixel. I personally like 256, it's not too big like 520, or too small like 64 or 128 and it still allows you to have detail.

DrSuperGood

The sprites still have the same limits as existing sprites. A full 3D engine could have an entirely different set of limitations. For example they might support interpolated curving of vehicles instead of just fixed angle graphics. They might also support vehicle animations such as for wheels turning. Dynamic reflections such as from real time raytracing could be supported for the shiny paintwork on some trains. Vehicles could also case real time shadows which change with time of day.

There is also a major issue with scaling up sprites currently. A single pak512 image may use as much memory as 64 pak64 images. For a pakset of equal complexity that means 64 times the pakset loading length as well as 64 times the memory Simutrans must use to hold all the graphics which get loaded at start up. I am aware the graphics are technically compressed so in reality the result might be less than 64 times, but still such scaling might not be viable for very complex paksets.