The International Simutrans Forum

Development => Patches & Projects => Larger Projects => Topic started by: eddielexx on January 02, 2010, 03:38:33 PM

Title: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: eddielexx on January 02, 2010, 03:38:33 PM
Well, I have played this game for a long time, but I have never felt a need for posting anything on this forum, cuz, simply, everything I have ever needed was added in every new version. But, personally, I think that this game needs a new style, new look and new design. Old isometric system is now totally obsolete, and 3D is its future. With this so many addons and features that none game on market has ever had, I think that Simutrans project could rise in something very very big. And how to do that. I see that there is really a lot of quite capable people who would be able to do this. What? To convert this game in real 3D.

Well, how to do that. My first idea was to make a team composed by people from this forum, and divided in teams. So, if someone knows how to design in 3D, he will belong to design group. I think it is clear. So basically we will need three groups in beginning. Design, Programming and Ideas. We have to find open-source 3D engine, the easiest one, or one that is abandoned. Then we have to start everything from scratches, we have to begin making a base of the game. OFc it will take some time, but in the end, we will have workin engine, working game mechanics, and then, we will have Design and Ideas team, who will start converting, adding and suggesting old and new features and addons. When we make that game core, we will be able to continue developing it in every single way we want. I'm telling WE, cuz this game will probably be opensource, and free for all.  Unless We decide opposite. What do you think, could we do this? And yes, I know a little bit of C and C++, and I am workin in 3dsMax actively... what do u think. Should we do this, but all of us, who plays this game, and develop it.


..
3D engine : Irrlicht  http://irrlicht.sourceforge.net/
Title: Re: Simutrans in 3D
Post by: vilvoh on January 02, 2010, 05:18:39 PM
It sounds tempting but I'm afraid you haven't considered all the aspects of this titanic task. You suggest to start everything from scratch, as it was easy to carry out. In terms of code, Simutrans it's not a 2k game and the use of 3D engines means collisions and physics, that would increase the task complexity.

On the other hand, there're impressive commercial games that use isometric view mixed with pseudo-3D like Simcity 4, so imho the use of a real 3D engine is not a requirement to make Simutrans a good game. It may help, but must assess whether it is worth the effort.

From my point of view, I would prefer to increase the quality of graphics instead of using a 3D engine. It implies less critical changes and would be achievable with the current implementation.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 05:27:45 PM
I considered that too... But, u have to admit that idea is good, and that we all have enough acknowledge for doing that. And why shouldnt we start it from scratches? Well, it wont be from scratches totally, cuz complete economical system wont be changed. Numbers stays numbers. I am just saying, why shouldnt we try? Cuz, i would like to see parallel tram and train tracks, better looking interface, and graphic in total, more industrial chains, better industry placing algorythms, better done underground system, many other things which are simply not possible to be added in this game, unless we harm entire game code... U have to admit that this game has terrific potential and that we have to use it. I mean, imagine that, playing game, building transport system, and then, in some point of time, u simply zoom in to the street level, and watching trams and troleeys and trains going around you.... I mean, im dreamin to see that... But I cant do that on my own :D
Title: Re: Simutrans in 3D
Post by: vilvoh on January 02, 2010, 05:40:39 PM
Dreaming is free, but as Bruce Lee said:

QuoteA goal is not always meant to be reached, it often serves simply as something to aim at

I'm not saying you can't try it, I'm just trying to show that perhaps there're other less complex ways to get the same result. Anyway, If you're fully convinced, then go on. Simutrans is open source, so the code is public and accesible. A possible solution would be to create a fork as jamespetts did with Simutrans Experimental.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 06:06:24 PM
Well, u know that I cant do it on my own... And I hope that, if I start doing this, someone will help me... Abd tell me the way of reaching all those thingsa I said, without using 3D?
Title: Re: Simutrans in 3D
Post by: Dwachs on January 02, 2010, 06:37:30 PM
Impressive first posts on the forum!

You are proposing to undertake a huge thing here. Some of the very fundamental concepts of the game have to be reworked. Nothing I want to participate.
Title: Re: Simutrans in 3D
Post by: Ashley on January 02, 2010, 06:46:11 PM
Simutrans 3D?

The problem with 3D games is they take a lot more work to make them look good than 2D ones. With a 2D game you're restricted in viewpoint and the artist has much greater control over the style of the graphics (since they know that the views they are creating are the only ones which can ever be seen). In the 3D world you have to model objects to be viewed in all directions, close up and far away.

A 3D game also tends towards having greater realism. E.g. free-form tracks, free motion of vehicles, realistic physics etc. These things add a lot of complexity on top of the kind of complexity that is already required for a transport sim game like Simutrans. Designing a game around discrete tiles actually gives you many cheats to get around complex programming tasks (e.g. pathfinding, economic calculations (these can be approximated to tiles), building placement in cities, road/track graphical placement etc. etc.)

And overall, what does it really gain in terms of gameplay? Is the game more fun for being 3D? That's the key question, and one that sadly many games developers failed to ask when developing 3D versions of classic 2D games. Was Sim City in 3D more fun than Sim City in 2D? Was Lemmings? Was RRT?

I've actually looked into the logistics of creating Simutrans 3D before, and decided that the extra effort wasn't worth it given the rewards in terms of gameplay and the fun factor. I never took it beyond a few experiments though.

If you want to contribute to Simutrans, there are still lots of ways that you can (the big ones being AI and network play) which would make a much bigger difference than a 3D engine. Both of these will improve the actual gameplay and fun factor much more than a new graphics engine would.

If you want a 3D transport sim game, then I'd recommend either checking out one of the existing attempts (e.g. Transport Tycoon 3D) or starting an entirely new project under a new name (as you seem to suggest). Just be aware that doing a 3D game well takes (IMO) an order of magnitude more work than doing a 2D one well.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 07:03:48 PM
Well, I know it's gonna difficult, but why not to try?? My biggest problem is gonna be pathfinding, everything else I will sort out, cuz i already have a plan how to do everything else.. So, I wondered if someone knows how to solve this... I'd appreciate it so much... Why shouldnt we start it as 3D Simutrans? As I see, ever1 is afraid of starting 3D Simutrans. Why?
Title: Re: Simutrans in 3D
Post by: vilvoh on January 02, 2010, 07:16:52 PM
I'm afraid you haven't get the point. The primary question is not why, actually is Is it worth it?. From your point of view, the problem is easy but people with more experience on Simutrans development says it's quite complex. You think it's fear to change, but imho, we're just realistic. It has been already discussed before and the conclusion was it's not worth the effort.

Anyway, we're not stopping you. As I said before, if you are fully convinced that it's as easy as it seems then start the development and post here your ideas. We surely can discuss them and provide support for this new adventure.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 07:22:50 PM
Quote from: vilvoh on January 02, 2010, 07:16:52 PM

Anyway, we're not stopping you. As I said before, if you are fully convinced that it's as easy as it seems then start the development and post here your ideas. We surely can discuss them and provide support for this new adventure.

I like this :D:D

Firstly, May I name it as Simutrans 3D?
And Secondly, why shouldn't I make this game, but with using of tiles, just like 2D Simutrans? I think that is the best idea for now :D Only the camera and models will be real 3D :D
What do you think:D
Title: Re: Simutrans in 3D
Post by: The Hood on January 02, 2010, 07:58:02 PM
I'd agree with Timothy.  Simutrans is a great game, and IMHO it's more important to have a fun game with good gameplay and OK graphics than a game with amazing 3D graphics (and I can't think of any transport game that comes into the amazing 3D category).  And maybe it's just because I grew up playing TTD and Civ 2, but I'm a bit nostalgic about isometric tile games... :)
Title: Re: Simutrans in 3D
Post by: prissi on January 02, 2010, 08:43:01 PM
If you just do an easy conversion with the same tile structure but rendered as isometric tile/3D alternatively, you can almost completely keep the game core. The graphics layer is quite seperate from the game mechanics, and would allow for a 3D replacement.

There are several engines working, like the ogre engine, which the people of transport empire http://www.tt-forums.net/viewforum.php?f=56 (http://www.tt-forums.net/viewforum.php?f=56) use.

But the only game with a sensible economy and working 3D was the never finished 3DTTT, which is closed source and now dead, unfourtunately. It has many innovative concepts on dealing on the problems/freedom of 3D transport simulators while still being somewhat close to the simutrans concepts.
Title: Re: Simutrans in 3D (in: topic moved and renamed)
Post by: IgorEliezer on January 02, 2010, 09:04:00 PM
Topic moved and renamed from "New Simutrans" to "Simutrans in 3D".
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 09:33:30 PM
Quote from: prissi on January 02, 2010, 08:43:01 PM
If you just do an easy conversion with the same tile structure but rendered as isometric tile/3D alternatively, you can almost completely keep the game core. The graphics layer is quite seperate from the game mechanics, and would allow for a 3D replacement.

There are several engines working, like the ogre engine, which the people of transport empire http://www.tt-forums.net/viewforum.php?f=56 (http://www.tt-forums.net/viewforum.php?f=56) use.

But the only game with a sensible economy and working 3D was the never finished 3DTTT, which is closed source and now dead, unfourtunately. It has many innovative concepts on dealing on the problems/freedom of 3D transport simulators while still being somewhat close to the simutrans concepts.

Well, this is good point. I already have chosen Irrlicht engine for this :D So, give me some hints for converting game in 3D. And yes, only problem here is graphic, every other aspect of the game can easily be transferred inthis new one :D Am i right :D 
Title: Re: Simutrans in 3D
Post by: Spike on January 02, 2010, 10:01:04 PM
Quote from: prissi on January 02, 2010, 08:43:01 PM
If you just do an easy conversion with the same tile structure but rendered as isometric tile/3D alternatively, you can almost completely keep the game core. The graphics layer is quite seperate from the game mechanics, and would allow for a 3D replacement.

Going this route is simple, programming-wise. I had considered that by myself, using OpenGL. But the amount of 3D models needed was scary. So I gave up on the idea.

If you can gather a team of 3D artists - well at least one dedicated person and a programmer who has experience with one of the 3D APIs (a portable one, please!) it should be doable.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 10:09:10 PM
Quote from: Hajo on January 02, 2010, 10:01:04 PM
Going this route is simple, programming-wise. I had considered that by myself, using OpenGL. But the amount of 3D models needed was scary. So I gave up on the idea.

If you can gather a team of 3D artists - well at least one dedicated person and a programmer who has experience with one of the 3D APIs (a portable one, please!) it should be doable.


Then, what are we waiting for ?? Lets do that Hajo then !!
I have a lot of friends who will be able to help me. I mean, we only need one example of tram, train, trolley, building , road, bridge, and that is it. Even I can make a modle for that :D When we succeed in converting the game, I bet that entire forum will be with us, cuz I already saw that there are a lot of people who found that it is easier for them to design in 3D than in 2D. Let's do it Hajo !! I can use Irrlicht, cuz it is very eligible for game design and it is really simple to use :D And it supports DX8.1, DX9 and OpenGl :D When do we can start with this :D 
Title: Re: Simutrans in 3D
Post by: Amelek on January 02, 2010, 10:34:55 PM
well to tell the truth, it would be nice to have 3d simutrans incorporated in normal game, so it could load 3d-paksets and 2d paksets. Idea of writing game from scratch or creating completely separate branch is probably bad - game logic which is (i suppose) more important part of game would remain the same.
Title: Re: Simutrans in 3D
Post by: prissi on January 02, 2010, 10:41:32 PM
irrLicht is also very portable and sounds like a good choice too. Especially since it is around for years. But I fear the look of just tiles converted will not satisfy expections, just have a look at the 3D TTD for PSP.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 10:45:51 PM
Quote from: prissi on January 02, 2010, 10:41:32 PM
irrLicht is also very portable and sounds like a good choice too. Especially since it is around for years. But I fear the look of just tiles converted will not satisfy expections, just have a look at the 3D TTD for PSP.

Well OFC we will make it better and more beautiful than those tiles are now :D What i am trying to tell is that we should make tile in constant size but to add zoom, but enhanced zoom, so on unzoomed view, detail of tile wont be that good. It will be just appropriate for quick map moving and creating tracks blablabla in oreder to keep game playable and with big fps. But when we zoom in totally, than tiles will be more detailed and better looking, and it will be just enough detailed to enjoy looking your creation getting alive. I thought to add free walking, and free camera angles in maximum zoom, so in fact we can walk through city :D I think that is good idea :D What other thinks :D
Title: Re: Simutrans in 3D
Post by: jonasbb on January 02, 2010, 11:04:44 PM
Sounds nice.
If you start, I hope you work for a playable 3d version and that this project would not sleep.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 02, 2010, 11:08:29 PM
Quote from: jonasbb on January 02, 2010, 11:04:44 PM
Sounds nice.
If you start, I hope you work for a playable 3d version and that this project would not sleep.

It will sleep if noone helps me. This is a huge project and I would like everyone enough free and with enough enthusiasm to help me :D This is gonna be something good. really :D
Title: Re: Simutrans in 3D
Post by: skreyola on January 03, 2010, 04:05:39 AM
OTOH, having a fork like experimental would afford some interesting opportunities... like allowing player to place truck stops without making road and having the trucks wear a path like in Settlers 3 (or was it 4?) that becomes dirt road.
Anyway, I think this is an interesting idea. However, I'm not sure I could play it. My computer already has trouble running pak128, so the added graphical requirements would probably shut me out.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 09:54:30 AM
:D Good Mornin'

I was trying to figure out which 3D engine we should use, Ogre or IrrLich and I still don't know which one to chose, cuz IrrLicht is really simple, but OGRE looks two times better :D Well, If someone knows something more bout this topic, he should say something, and give me some advices for choosin the correct one :D
Title: Re: Simutrans in 3D
Post by: Spike on January 03, 2010, 11:13:55 AM
Both are well-established 3D engines. If Irrlicht looks easier to you, then use that. Simutrans 3D won't need fancy light effects, or anything very sophisticated.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 11:15:39 AM
Okay then.
IrrLicht :)
Title: Re: Simutrans in 3D
Post by: Spike on January 03, 2010, 11:27:21 AM
To prevent misunderstandings - I'm usually either lazy or busy with ideas of my own. I've worked on Simutrans way too long, I don't want to come back, except for the occasional image or two.

Actually, I think I have forgotten most of my former C++ knowledge, so I'd be of no use to such a project. I will read here now and then, and try to help with ideas and advice if I can.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 11:31:48 AM
Quote from: Hajo on January 03, 2010, 11:27:21 AM
To prevent misunderstandings - I'm usually either lazy or busy with ideas of my own. I've worked on Simutrans way too long, I don't want to come back, except for the occasional image or two.

Actually, I think I have forgotten most of my former C++ knowledge, so I'd be of no use to such a project. I will read here now and then, and try to help with ideas and advice if I can.


:D That's good help too :D:D
I finally installed Visual Basic, and I am going to begin with work :D
Title: Re: Simutrans in 3D
Post by: Spike on January 03, 2010, 11:43:18 AM
Mac OS and Linux fans will cry if Simutrans 3D gets done with Visual Basic, I think.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 01:06:47 PM
Why? Could I use Visual C++ then, instead?
IS it gonna be compatible then?

I downloaded both, and there are tutorials for both :D
Title: Re: Simutrans in 3D
Post by: Spike on January 03, 2010, 03:35:47 PM
C++ is a more portable language. Since most code of Simutrans is C++, it should be a good choice as language for Simutrans 3D; I assume you don't want to rewrite all code.

Just be careful not to use system specific APIs, at least not directly, so that the code can be ported to other systems easily.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 05:54:09 PM
http://www.filehosting.org/file/details/96105/Oj1QqaJNX3FD5iiH/Simutrans_3D_Terrain.7z

this is terrain that I finally generated. i am now facing a problem. What will happen with curved terrain when i start implementing tiles :S If i decide to build a building i.e., what will happen. Should I add some kind of autoleveling, or a platform for buildings??
Title: Re: Simutrans in 3D
Post by: Spike on January 03, 2010, 09:33:21 PM
Currently Simutrans uses foundations for buildings. These work like little platforms. I think keeping that idea will be the easiest way to have building in sloped terrain.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 09:52:10 PM
Cool :D Now I need Simutrans source code.. Where to find it?
Title: Re: Simutrans in 3D
Post by: jonasbb on January 03, 2010, 09:56:50 PM
svn://tron.homeunix.org/simutrans/simutrans/
username "anon"
Title: Re: Simutrans in 3D
Post by: eddielexx on January 03, 2010, 10:01:49 PM
Quote from: jonasbb on January 03, 2010, 09:56:50 PM
svn://tron.homeunix.org/simutrans/simutrans/
username "anon"

It is telling me that "Page cannot be displayed :S"
What to do?
Title: Re: Simutrans in 3D
Post by: IgorEliezer on January 03, 2010, 10:24:27 PM
svn:// addresses are not "understandable" by Internet browsers so they display "Page cannot be displayed" or "Firefox doesn't know how to open this address. You'll need to get a Subversion Client in order to be able to open a svn address.

TortoiseSVN is, say, the most "famous" among subversion clients out there. Below are an article about svn and a list of subversion clients:

http://en.wikipedia.org/wiki/Subversion_%28software%29
http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients
Title: Re: Simutrans in 3D
Post by: Fabio on January 04, 2010, 08:05:20 AM
by the way, i'll give you my 2 cents about 3D.
I think the game would benefit the most from a first 3D rendering of vehicles. They could ride normal roads/tracks, but with much better turning/climbing. Also, still being a long 3D painting work, it would be much smaller than painting in 3D all buildings. Additionally, (1) i believe that most of vehicles have somewhere 3D sources and (2) the same vehicles could be rendered on-the-fly for both pak64 and pak128 (i exclude pak96c, as it has a completely different style :::))
Title: Re: Simutrans in 3D
Post by: eddielexx on January 04, 2010, 09:42:50 AM
Quote from: fabio on January 04, 2010, 08:05:20 AM
by the way, i'll give you my 2 cents about 3D.
I think the game would benefit the most from a first 3D rendering of vehicles. They could ride normal roads/tracks, but with much better turning/climbing. Also, still being a long 3D painting work, it would be much smaller than painting in 3D all buildings. Additionally, (1) i believe that most of vehicles have somewhere 3D sources and (2) the same vehicles could be rendered on-the-fly for both pak64 and pak128 (i exclude pak96c, as it has a completely different style :::))


Well, my goal is to create working 3D game, and if Community find to like it, then we should start creating 3D models. I just need a way to extract graphic engine from the game, but it is gonna be otugh, cuz I dont know where to start :D I downloaded source code... I thought just to convert graphic system into 3D and all game mechanic should remain intact. What do u think
Title: Re: Simutrans in 3D
Post by: Isaac Eiland-Hall on January 04, 2010, 09:55:03 AM
I really don't think it's anywhere as simple as you seem to think, but I don't think that's necessarily a problem. If you can managed to get a workable 3-D engine into Simutrans, I'd be happy with that.

I wouldn't be surprised if you don't find much in the way of coding help here, though - we're a pretty small community, and most everyone who can work on things is already spending their free time doing so. So if you make calls of "help me!" and very few respond, if doesn't mean everyone hates the idea; I think it means more than everyone who can do, is already doing.
Title: Re: Simutrans in 3D
Post by: eddielexx on January 04, 2010, 10:02:26 AM
Quote from: Isaac.Eiland-Hall on January 04, 2010, 09:55:03 AM
I really don't think it's anywhere as simple as you seem to think, but I don't think that's necessarily a problem. If you can managed to get a workable 3-D engine into Simutrans, I'd be happy with that.

I wouldn't be surprised if you don't find much in the way of coding help here, though - we're a pretty small community, and most everyone who can work on things is already spending their free time doing so. So if you make calls of "help me!" and very few respond, if doesn't mean everyone hates the idea; I think it means more than everyone who can do, is already doing.

That's good, just, in the coding chaos (english + german, now I need even a translator :D:D) I really can't find any library or cpp that is responsible for graphic rendering. I have an Idea of importing Irrlicht in game, but firstly I have to remove old engine. And I really dunno where is it. For now, that is the only help I will need.
Title: Re: Simutrans in 3D
Post by: Dwachs on January 04, 2010, 10:11:17 AM
the drawing happens in simview.cc, the display routine there.
Title: Re: Simutrans in 3D
Post by: skreyola on January 04, 2010, 08:50:59 PM
Quote from: Hajo on January 03, 2010, 11:43:18 AM
Mac OS and Linux fans will cry if Simutrans 3D gets done with Visual Basic, I think.

I cry when anything is written in Visual Basic. ;)
Title: Re: Simutrans in 3D
Post by: Reddog785 on February 08, 2010, 09:11:58 PM
Quote from: skreyola on January 04, 2010, 08:50:59 PM
I cry when anything is written in Visual Basic. ;)

You...Cry. You actually...cry. Why? Is it because you can't understand it?
Title: Re: Simutrans in 3D
Post by: Spike on February 08, 2010, 09:24:53 PM
No, because this language is one of the least portable languages. That means, using Visual Basic will look lock out a lot of people from using Simutrans 3D (but the thread is so old, I doubt the project is still going. And I'd assume a serious try to use a language that is easier to link with C++, the language Simutrans is written in).

Edit: Typo fixed.
Title: Re: Simutrans in 3D
Post by: vilvoh on February 08, 2010, 09:45:29 PM
Every time somebody writes code in Visual Basic, God kills a kitten.
Title: Re: Simutrans in 3D
Post by: VS on February 08, 2010, 10:11:29 PM
We could make a silly poll to determine which language/framework should be used for "new Simutrans" of any kind. Here are some serious contenders:

Erlang
Perl, Ruby, Python (take your pick)
assembly with AT&T syntax
Lua
Matlab
J2ME (mobile, whee!)
Cobol
autotools
jQuery
bash

...not all on this list are actually jokes :)
Title: Re: Simutrans in 3D
Post by: Reddog785 on February 08, 2010, 10:12:28 PM
Quote from: VS on February 08, 2010, 10:11:29 PM
We could make a silly poll to determine which language/framework should be used for "new Simutrans" of any kind. Here are some serious contenders:

Erlang
Perl, Ruby, Python (take your pick)
assembly with AT&T syntax
Lua
Matlab
J2ME (mobile, whee!)
Cobol
autotools
jQuery
bash

...not all on this list are actually jokes :)

Lua! Woo Hoo!
Title: Re: Simutrans in 3D
Post by: Spike on February 08, 2010, 10:21:39 PM
Lua is cool actually. We could compile the C++ code of current Simutrans into a library and use that from Lua ;D

At least I have successfully intertwined C++ and Lua code in the past.
Title: Re: Simutrans in 3D
Post by: Fabio on February 09, 2010, 08:02:39 AM
Quote from: vilvoh on February 08, 2010, 09:45:29 PM
Every time somebody writes code in Visual Basic, God kills a kitten.

This is why I don't see too many kittens around me... These days at work I have a wide use of Visual Basic, ihihihih
Title: Re: Simutrans in 3D
Post by: robofish on February 09, 2010, 05:16:37 PM
You forgot Haskell (http://en.wikipedia.org/wiki/Haskell_%28programming_language%29)!!

Simutrans is going functional :)

(You can actually use SDL with Haskell - and it even looks quite nice [at least on the first glance])
Title: Re: Simutrans in 3D
Post by: jamespetts on February 09, 2010, 10:42:12 PM
How about QBasic?
Title: Re: Simutrans in 3D
Post by: Isaac Eiland-Hall on February 10, 2010, 04:25:18 AM
How about I SLAP YOU AROUND?

;-)
Title: Re: Simutrans in 3D
Post by: jamespetts on February 10, 2010, 10:30:07 AM
Only if you can write a "slap you around" programme in QBasic...
Title: Re: Simutrans in 3D
Post by: Spike on February 10, 2010, 11:00:13 AM

10 print "slap"
20 goto 10


;D
Title: Re: Simutrans in 3D
Post by: jamespetts on February 10, 2010, 04:44:41 PM
Or maybe:


10 print "Slap"
20 pause 10
30 goto 10


?
Title: Re: Simutrans in 3D
Post by: The Hood on February 10, 2010, 04:46:41 PM
That would be the additional feature in slap-you-around-experimental ;)
Title: Re: Simutrans in 3D
Post by: markus on February 10, 2010, 08:45:42 PM
lol
Title: Re: Simutrans in 3D
Post by: skreyola on February 11, 2010, 10:37:04 PM
Quote from: Reddog785 on February 08, 2010, 09:11:58 PM
You...Cry. You actually...cry. Why? Is it because you can't understand it?
I used to write GWBasic programs, so I doubt I'd have trouble understanding it. As someone already suggested, it's not the most portable language in the world; hence the crying.
Title: Re: Simutrans in 3D
Post by: mjhn on February 13, 2010, 05:08:40 PM
I have a theory that the best eficiency in results would be to use a partially 3-D engine, where the ground, track, and building foundations are 3-D, while everything else is the existing sprites. This could probide opportunities for several gameplay changes that at least I would consider improvements, such as variable heights and diagonals on slopes, as wells as removing the incredible numbers of sprites that the grounds in the current version of simutrans are using, while not requireing all of the building and vehicle sprites to be replaced.

as for languages, any language will do as long as it will compile and run on either http://en.wikipedia.org/wiki/MONIAC_Computer (http://en.wikipedia.org/wiki/MONIAC_Computer) or http://en.wikipedia.org/wiki/Hex_(Discworld) (http://en.wikipedia.org/wiki/Hex_(Discworld))
Title: Re: Simutrans in 3D
Post by: prissi on February 13, 2010, 06:34:50 PM
The problem is, that the routing of vehicles is tile based. Changing that (efficiently) is not easy.
Title: Re: Simutrans in 3D
Post by: Isaac Eiland-Hall on February 13, 2010, 06:51:26 PM
Quote from: mjhn on February 13, 2010, 05:08:40 PM
or http://en.wikipedia.org/wiki/Hex_(Discworld) (http://en.wikipedia.org/wiki/Hex_(Discworld))

+++ OUT OF CHEESE ERROR +++
Title: Re: Simutrans in 3D
Post by: mjhn on February 21, 2010, 03:29:46 PM
Prissi: My idea was to have a map that's tile based in 2-D, but with height not being fixed points. Existing buildings would be usable (with 3-D foundations) as they would be on flat squares as currently in simutrans. Trains would still work as the fact that the vehicles fail to line up on slopes would often be less visible than currently as the slopes would often be less steep. Track, trackobjects, stations, and bridges would need new graphics to follow the terrain (partly, as left to right would still be kept flat with some kind of foundation)

Issac: You need a cheese industry
Title: Re: Simutrans in 3D
Post by: eddielexx on February 21, 2010, 05:17:18 PM
Very very good idea :)
Title: Re: Simutrans in 3D
Post by: kierongreen on February 21, 2010, 06:15:08 PM
Quote from: mjhn on February 21, 2010, 03:29:46 PM
Prissi: My idea was to have a map that's tile based in 2-D, but with height not being fixed points. Existing buildings would be usable (with 3-D foundations) as they would be on flat squares as currently in simutrans. Trains would still work as the fact that the vehicles fail to line up on slopes would often be less visible than currently as the slopes would often be less steep. Track, trackobjects, stations, and bridges would need new graphics to follow the terrain (partly, as left to right would still be kept flat with some kind of foundation)
The current system has the advantage it is easy to see whether a tile is flat or if it is a slope. With variable slopes this becomes more difficult.

Yes you can reuse building graphics but all track has to become 3d (it's impractical to draw all the possible combinations). Likewise bridges and stations have to go 3d. Then it becomes tricky making graphics consistent between 2d and 3d parts of the game...
Title: Re: Simutrans in 3D
Post by: Fabio on February 21, 2010, 08:41:05 PM
Quote from: mjhn on February 21, 2010, 03:29:46 PM
Prissi: My idea was to have a map that's tile based in 2-D, but with height not being fixed points. Existing buildings would be usable (with 3-D foundations) as they would be on flat squares as currently in simutrans. Trains would still work as the fact that the vehicles fail to line up on slopes would often be less visible than currently as the slopes would often be less steep.
I very much like this idea!

Quote from: kierongreen on February 21, 2010, 06:15:08 PM
Yes you can reuse building graphics but all track has to become 3d
Not necessarily. Slopes could be not entirely free, but, say, 10%, 20%, 30%, 40%, 50% (existing ones).
Tracks and roads could limited to 10% (roads and tracks), 20% and 30% (roads only).
Steeper slopes would need to be smoothed in order to host ways, whereas only roads would need more (and only 3) different slopes.
Title: Re: Simutrans in 3D
Post by: VS on February 21, 2010, 09:35:39 PM
Railroad Tycoon 2 uses something similar, I think... terrain is 3d-like, but some items like buildings and trees are 2d. It's also exceptionally ugly compared to Simutrans ;D And the whole world is simpler, there are not so many things interacting with terrain.
Title: Re: Simutrans in 3D
Post by: Spike on February 22, 2010, 09:00:04 AM
Quote from: kierongreen on February 21, 2010, 06:15:08 PM
Yes you can reuse building graphics but all track has to become 3d (it's impractical to draw all the possible combinations). Likewise bridges and stations have to go 3d. Then it becomes tricky making graphics consistent between 2d and 3d parts of the game...

Why do stations need to become 3D models? I think 2D sprites like now would still work in a 3D landscape, given that the landscape isn't freely rotatable  and the stations are only build on flat ground.
Title: Re: Simutrans in 3D
Post by: kierongreen on February 22, 2010, 11:40:54 PM
Quote from: Hajo on February 22, 2010, 09:00:04 AM
Why do stations need to become 3D models? I think 2D sprites like now would still work in a 3D landscape, given that the landscape isn't freely rotatable  and the stations are only build on flat ground.

Because once you have variable slopes it actually starts to become tricky to get perfectly level ground. You can try and code workarounds for this but it would get tricky (only practical way is to automatically level terrain when building stations, adjusting height of surrounding tiles when required, but this introduces problems too). Similarly for bridges it becomes less obvious whether there is enough height difference between two ways crossing.
Title: Re: Simutrans in 3D
Post by: Spike on February 23, 2010, 09:16:20 AM
Settlers II and III flattened the area for a building. I'd  assume that it's possible in Simutrans 3D, too. But you are right, this requires extra thought and maybe some tricks.

Another idea for moderately level ground would be 3D foundations to have level ground for the station, while the track is slightly sloped. This may or may not work, most likely one would have to make a few mockup screens to judge the visual appearance.
Title: Re: Simutrans in 3D
Post by: itec on February 24, 2010, 05:25:12 AM
before this gets to far along could anybody give an example of a commercial game that was isometric and then moved to 3d and get better? I personaly cant think of any!
Title: Re: Simutrans in 3D
Post by: Spike on February 24, 2010, 08:58:30 AM
Quote from: itec on February 24, 2010, 05:25:12 AM
before this gets to far along could anybody give an example of a commercial game that was isometric and then moved to 3d and get better? I personaly cant think of any!

I don't know any either. And given the fact that we talk since years about Simutrans 3D but neither have any code nor models, I'd not fear this gets too far along before ... I don't know. Currently the situation is that he official dev team does nothing in this direction, and volunteers all have stopped their work, if they even started.
Title: Re: Simutrans in 3D
Post by: vilvoh on February 24, 2010, 09:03:58 AM
GTA 3, Fallout, Warcraft 3, Command & Conquer, Starcraft 2, MMORPGs like Ultima Online, Football games like FIFA or PES...Perhaps they didn't improve the gameplay, but at least they look different... ;)
Title: Re: Simutrans in 3D
Post by: IgorEliezer on February 24, 2010, 03:39:35 PM
Good looking is essential for commercial games.
Title: Re: Simutrans in 3D
Post by: mjhn on February 24, 2010, 05:17:34 PM
The only instance I can think of a business game where making it 3d improved the game was Rollercoaster Tycoon 3 - but that was still grid-based (improvements in gameplay were mainly based around more flexibility in track shapes and more different slopes - all the rest was eyecandy).

You must notice, through, that recent discussion have not centred on making Simutrans 3-D, but using 3-D technology to improve the isometric graphics system (more flexibility in slopes, for example)
Title: Re: Simutrans in 3D
Post by: sdog on February 26, 2010, 03:56:50 PM
going full 3D would make content creation less effort in the long run. as i understood it is quite a lot of work to create the images, with all rotations, from the 3D models, since a lot of postproduction is required. i guess this is also likely the reason why almost all the commercial game developers created only 3D games from the late 90s on.

3D should also provide higher performance and higher detail if LODs are chosen well.

the huge workload will be on the code side.
Title: Re: Simutrans in 3D
Post by: Spike on February 26, 2010, 04:05:01 PM
Quote from: sdog on February 26, 2010, 03:56:50 PM
going full 3D would make content creation less effort in the long run. as i understood it is quite a lot of work to create the images, with all rotations, from the 3D models, since a lot of postproduction is required. i guess this is also likely the reason why almost all the commercial game developers created only 3D games from the late 90s on.

It depends. To me it seems that full 3D usually means more work for the artists. Also it locks out all people who paint, instead of modeling items.

If there is no option to use painted sprites and tiles, I can immediately dump my plans and ideas for things like pak.Excentrique (http://forum.simutrans.com/index.php?topic=3702.0). Nothing there is made with a 3D program that would be compatible with the polygon-based way to display images that nowadays graphics cards and all 3D games use (well except the few voxel and raytracing based ones).

The reason for 3D in commercial games was not saved work for the developers, but marketing, in my opinion.
Title: Re: Simutrans in 3D
Post by: sdog on February 26, 2010, 04:34:40 PM
from other mod projoects i've noticed that there's never a lack of 3D artists. maybe because creating 3d models is not an art at all and requires not a lot of imagination -- so it's more nerd compatible. back in the low texture size days people who could do good textures were really rare. now with photo based textures and shader effects it also became a technical instead of an artistic challenge, so there's no lack of textures either. The 3D models typically also got shared between games/mods, further reducing the workload. (Well, i guess more than half of the repositories are filled with weapon models, but there are also plenty of buildings)

i don't want to suggest making* simutrans 3D, i just think that creating the 3D content is not the real problem.

but of course going 3D would just mean swimming with the stream, excentricism is something i value very highly. And there's quite a lot of content in the available paksets.

the players response during the switch from painted 2D to modeled 3D was mostly negative, it just looked really ugly with the primitive 3D back then. being excited with new technological possiblities has also been a factor in game industries, i think.


* the key word is also 'make' i don't do anything, so i don't have a right to suggest anything anyway.
Title: Re: Simutrans in 3D
Post by: Spike on February 26, 2010, 08:14:00 PM
Sorry, I just wanted to say, I had/have a bad day, and my message was a bit over the top, also I missed the point a bit. I'm sorry. Another day I'll try a more reasonable response.
Title: Re: Simutrans in 3D
Post by: sdog on March 08, 2010, 03:56:56 AM
no offence taken, and no need to be sorry. i also can't see where your message is over the top. my footnote was also not related to your reply, just me in general feeling that since i don't contribute to the project i'm a bit too much of a smartass by being so vocal.

ps.: reading my posting again, it sounds a bit offensive on 3D artists, wich i did not intent. See it less as a statement of their lack in creativity and more as my lack in writing skills (and creativity)
Title: Re: Simutrans in 3D
Post by: Spike on March 08, 2010, 09:11:24 AM
With pak128.Britain we have a set that is made in Blender in big parts. I assume that will help to get a 3D version of Simutrans started if someone wants to try, since there is a good number of models that can be used with only little extra effort.

I see OpenGL being used more and more also for 2D games, just because the hardware acceleration of current graphics cards helps so much. Maybe in a first step, someone could try to write a OpenGL rendering backend for the current Simutrans code, and in a second step this OpenGL backend can be expanded by full 3D capabilities?
Title: Re: Simutrans in 3D
Post by: prissi on March 08, 2010, 02:51:25 PM
ANy openGL render has very limited amount of images it can handle (less than 1024). Thus it would involve a lot of chaching logic. (Some people tried this for OpenTTD, which has even less unique images per set).
Title: Re: Simutrans in 3D
Post by: VS on March 08, 2010, 03:11:57 PM
I'm no expert, but could this be solved by using image sheets (generated at runtime) as textures and drawing them clipped? After all, a 128*128 tile is not stored as a complete bitmap, is it...
Title: Re: Simutrans in 3D
Post by: Spike on March 08, 2010, 03:16:56 PM
Quote from: prissi on March 08, 2010, 02:51:25 PM
ANy openGL render has very limited amount of images it can handle (less than 1024). Thus it would involve a lot of chaching logic. (Some people tried this for OpenTTD, which has even less unique images per set).

This is point that was mentioned again and again, but I do not quite believe it, because nowhere else I have heard about this, and I visit a lot of game developer forums.

Are there some references to back up this point? I have once made a small OpenGL renderer which worked fine, but had less than 1024 textures, so I wouldn't have run into the problem. Still, in all the documentation that I read, I never saw such a limitation mentioned. But that can just mean I didn't read it carefully enough ...

Quote from: VS on March 08, 2010, 03:11:57 PM
I'm no expert, but could this be solved by using image sheets (generated at runtime) as textures and drawing them clipped? After all, a 128*128 tile is not stored as a complete bitmap, is it...

I see this done often. There are even "image packers" that try to fit as many small images into one large texture as possible (which is tricky if the small images have arbitrary sizes) and create offset lists to blit the small images from the big texture onto the screen as needed.
Title: Re: Simutrans in 3D
Post by: vilvoh on March 08, 2010, 04:19:27 PM
About the images issue, as far as I know, what people usually do is to unwrap 3D models into a single image, so you can have just a texture for all the elements of the object. If you want to go further, as Hajo said, you can use wad-style files, that gather all textures in a single huge file.
Title: Re: Simutrans in 3D
Post by: VS on March 08, 2010, 06:57:49 PM
Quote from: vilvoh on March 08, 2010, 04:19:27 PM
If you want to go further, as Hajo said, you can use wad-style files, that gather all textures in a single huge file.
Umm, that isn't exactly what both of us meant. The thing with opengl is, you can't have many textures (as prissi says), but you can have them large. But drawing only parts of the texture is cheap. So it makes sense that when stuffing the pictures into graphics card, you combine many small pictures into big ones.
Title: Re: Simutrans in 3D
Post by: prissi on March 08, 2010, 08:33:34 PM
OpenGL has issues (which can be solved of course)
- sometimes small spritebuffer
- does not handle images with a sizes!=power of 2 well
- no good 15 bit support/player color support
- do work good with partial screen rendering
- do not work on many devices (like iPod touch, Haiku, ... )

http://www.tt-forums.net/viewtopic.php?f=33&t=38151&hilit=OpenGL&start=0 (OpenTTD GL patch from 2008 working, then abandoned)
http://www.tt-forums.net/viewtopic.php?f=32&t=36780&hilit=OpenGL&start=0 (some discussion about OpenGL blitter)

And this shows nicely the haggles with 3D construction ... (and nice graphics)
http://www.youtube.com/watch?v=WCD3FFcbtmM&feature=related
Title: Re: Simutrans in 3D
Post by: vilvoh on March 08, 2010, 09:55:03 PM
Then, what are the alternatives to OpenGL? Ogre, Irrlicht, own 3D engine?
Title: Re: Simutrans in 3D
Post by: prissi on March 08, 2010, 10:06:41 PM
Irrlicht seems rather portable ... Orge may do it too.

Imho modelling and usability issues (not to mention the pathfinder) and movement code must be sorted out first.
Title: Re: Simutrans in 3D
Post by: Joker on March 09, 2010, 12:41:39 AM
Quote from: Hajo on February 26, 2010, 04:05:01 PM
It depends. To me it seems that full 3D usually means more work for the artists. Also it locks out all people who paint, instead of modeling items.


Not always the case. There are game out there that painters excel at.  Just as examples Rfactor Or the 18 Wheels of Steel Series. Both allow incredible freedoms when it comes to painting or creating Skins as most are referred as. I am no good at the 3D modelling side, But I have created many skins for both of those examples with realitive ease. Granted it would first be upto the Modellers to prove templates for such things.

On the other hand this would mean the Modellers would be the on the hook for new content. Paint takes minimal effort and can be produced much quicker then great models.

Just a thought :)

Cheers Joker
Title: Re: Simutrans in 3D
Post by: Archon on March 13, 2010, 08:15:25 PM
Iris2 is open source ultima online client that works with free serververs.

It uses ogre for graphics rendering and has 2d and 3d mode.

It might be helpful if someone wants to make openGL version of simutrans.

http://www.iris2.de/index.php/Main_Page (http://www.iris2.de/index.php/Main_Page)
Title: Re: Simutrans in 3D
Post by: Václav on April 12, 2010, 11:46:57 AM
I think that full 3D may be sometime helpful but I also saw how it can give very bad result (on RCT3). So I vote for staying in isometric.
Title: Re: Simutrans in 3D
Post by: vilvoh on April 12, 2010, 02:45:14 PM
Prissi told in a recent interview at the official blog that in the future, Simutrans might need to go 3D in order to survive.
Title: Re: Simutrans in 3D
Post by: prissi on April 12, 2010, 04:21:53 PM
Well, not by me of course ... but somebody might try.
Title: Re: Simutrans in 3D
Post by: Václav on April 12, 2010, 05:24:19 PM
I don't think so ... that 3D is needed to be Simutrans alive. If I am right, at this time only one silimar game use 3D - Sid Meyer's Railroads. And it was published in year 2006.
Title: Re: Simutrans in 3D
Post by: nitromefan on July 23, 2010, 10:00:04 AM
Quote from: VaclavMacurek on April 12, 2010, 05:24:19 PM
Sid Meyer's Railroads. And it was published in year 2006.

Just correcting you it's Sid Meier's Railroads.

Anyway i think your a little wrong Vaclav Simcity 2 is in 3D anyway. :)
Title: Re: Simutrans in 3D
Post by: Isaac Eiland-Hall on July 23, 2010, 10:49:47 AM
Simcity 2 is not in 3-D. It's isometric 2-D with layers, similar to Simutrans.
Title: Re: Simutrans in 3D
Post by: Isaac Eiland-Hall on July 23, 2010, 03:00:37 PM
Please note that nitromefan has been changed to a "Lounger"; therefore, any followups for them from this thread should be directed there.

For more information, see here: http://forum.simutrans.com/index.php?topic=5620.0

If this post is a double-post, it is intentional.

Please continue the thread. If you have any questions about this post, please start a new topic in the Help Requests board.
Title: Re: Simutrans in 3D
Post by: sdog on July 23, 2010, 07:51:41 PM
?

could you explain this a bit more please?
Title: Re: Simutrans in 3D
Post by: eddielexx on August 01, 2010, 01:45:03 PM
Hello. I was so busy, working in 4 countries, and I was unable even to be near my PC in 3 months, not to mention that I haven0t had time for anything else than saying hello to my gf over facebook and thats it. I was thinking about Simutrans in 3D. I would really like to make this game working, but I realised that it is impossible task to accomplish alone. I have programming skills, but not enough for makin game. I would really like someone to help me, because Simutrans in 3D wont have boundaries, it will be simply amazing. But I need a team, someone who ahs programmed before.
Title: Re: Simutrans in 3D
Post by: skreyola on August 02, 2010, 12:13:48 AM
@Vaclav: RRT2 uses a similar 3-d system... but you may be right about the relative age.
Title: Re: Simutrans in 3D
Post by: Spike on August 02, 2010, 08:33:09 AM
@Eddielex:

Maybe it will help if you write up a little design document. Write up what you want to keep from Simutrans, what you want to change. Why the changes are good and how they improve the game.

With that, you might have an easier time to find helpers, particularly programmers.

Even better was if you could make a prototype or demo of how it will look like - an example landscape with a few sample models on it, and basic user controls. Doesn't need to do anything, just show off how it could look like. Such uses to attract peoples attention easily.
Title: Re: Simutrans in 3D
Post by: eddielexx on August 02, 2010, 12:18:56 PM
Okay, I will write down PDF file, with all the ideas, and upload it here. Okay?
And if u like it, I will try to make a preview.
Title: Re: Simutrans in 3D
Post by: Spike on August 02, 2010, 12:22:59 PM
Might be a start :)
Title: Re: Simutrans in 3D
Post by: eddielexx on August 02, 2010, 12:33:40 PM
Well, I had an idea of making city building game + Simutrans. What do u think about that? It would be unique? And if it is possible, to push that idea to real developers?
Title: Re: Simutrans in 3D
Post by: Spike on August 02, 2010, 12:49:00 PM
In the past people have asked to expand Simutrans with SimCity'ish elements. So there seems to be some interest. But you know, you are combining two already big games there, and the resulting project will be rather huge.

A problem is, if you do not consider yourself a developer, you need good team building and marketing skills to get the project going. Usually people wait till someone gets something going and only jump onto the train if they see a certain chance of success.
Title: Re: Simutrans in 3D
Post by: eddielexx on August 02, 2010, 12:57:38 PM
Yeah, I know that, but I think that gaming community would accept that kind of game on big scale. I can make a plan for every single aspect of the game, and try to push that idea to developing studios. I just dont know how to do that :( We can start building something on our own too. But I am not developer, you are.
Title: Re: Simutrans in 3D
Post by: Spike on August 02, 2010, 01:07:50 PM
"Studios" sounds wrong to me somehow. So far I was thinking of a hobby/open source project, much like Simutrans itself is.

Personally, I'd be scared about the size of such a project. I've set my mind on much smaller projects, things that I can do within a few weeks and then call them finished. But this is just me, and I see in other places that people can stick with projects many years.

I'd say, start with the 3D change for Simutrans. If you can get that going, add the SimCity expansion.
Title: Re: Simutrans in 3D
Post by: eddielexx on August 02, 2010, 01:12:52 PM
Okay, I will think about that. But is is huge project already, cuz I need firstly to translate half of coding. God helps me. But, firstly, I will upload PDF with ideas. There are already a lot of thing that needs change. :D
Title: Re: Simutrans in 3D
Post by: Václav on August 06, 2010, 03:39:23 PM
Quote from: skreyola on August 02, 2010, 12:13:48 AM
@Vaclav: RRT2 uses a similar 3-d system... but you may be right about the relative age.
I am deeply sorry for quite delayed answer: Thanks for info. I looked on some screenshots - but it seems that this game (meant RRT2) uses mainly isometric 2D.

I still think that Simutrans does not need to be 3D - but some else things which are currently in queue of deprecated/denied features can be implemented instead it.
Title: Re: Simutrans in 3D
Post by: skreyola on August 06, 2010, 10:07:24 PM
Quote from: VaclavMacurek on August 06, 2010, 03:39:23 PM
I am deeply sorry for quite delayed answer: Thanks for info. I looked on some screenshots - but it seems that this game (meant RRT2) uses mainly isometric 2D.
I was going to say it was similar (3d) to Railroads, but looking at Youtube videos (It's been a while since I played RRT2 and I may have gotten rid of it), it looks like you're right. It just really feels 3d... perhaps because of the way track can be laid down.
Title: Re: Simutrans in 3D
Post by: eddielexx on August 07, 2010, 10:52:07 AM
hello, I think that 2D Simutrans should continue developing, but that we really deserve something better looking and with more features, after almost 10 yrs. Good news is that I am almost finished with my PDF, and development project should be started soon, in one month max :D
Title: Re: Simutrans in 3D
Post by: greenling on August 13, 2010, 09:16:03 PM
Hello
i Find that simutrans cant not to be go in 3D.
3D requiend more power from the CPU´s,Graficcard,Ram and Harddisk.
A Computer or Laptop with 3D useable Graficchip,CPU,Harddisk and Ram cost
new more than 700€.
That is for some people very many money that not be growe on tree!

greenling
Title: Re: Simutrans in 3D
Post by: Spike on August 14, 2010, 10:03:47 AM
I'm pretty sure that the 2D versions of Simutrans will continue to be developed. So it shouldn't be a problem if some people have older hardware, they just continue to use the versions and pak sets that they use now.

Slightly unrelated, but I'd still assume that a OpenGL rendering backend gives a performance boost, not a slowdown, if the rest of the code is kept as it is.

Quote from: eddielexx on August 02, 2010, 01:12:52 PM
But is is huge project already, cuz I need firstly to translate half of coding.

I'm not quite sure why one would need to translate half of the coding to go 3D. In a first step, it would suffice to replace one of the rendering backends with one that supports 3D, like OpenGL or Direct3D. Also to adapt the pak files so they can store 3D models and textures instead of bitmaps.

But the rest of Simutrans can stay unchanged.

Anyways, I'm slightly curious what you actually will do ;D
Title: Re: Simutrans in 3D
Post by: eddielexx on August 15, 2010, 08:04:08 AM
What you suggest is to change only engine, so tile system can remain intact? That sounds good to me. And very possible to be done. Do you have MSN or FB or mail Hajo?

The only problem are Slopes. I still don't have any idea how to resolve that. The existing system is ofc obsolete and unusable in #d. Anyone has any idea?
Title: Re: Simutrans in 3D
Post by: Spike on August 15, 2010, 10:00:33 AM
Mail icon is left of this posting ;)

But since this discussion might be interesting for other people I'd prefer to keep it public. There might be more opinions and ideas how to implement a 3D view for Simutrans.

Why does the slope system not work in 3D? A tile in Simutrans has 4 corners, and each corner has a height (at least it was this way when I retired from coding ...) If you split the tile in two or four triangles, it should be quite straightforward to display a tile.

For the artificial slopes, you need additional quads or triangles to fill the gaps to the side and next lower tiles. Since Simutrans already knows where to put the slope bitmaps, it should be fairly straightforward to put extra quads and triangles there.

Prissi's concern was, that the storage of textures in the graphics memory can be a problem. My concern was that there might not be enough manpower to create the 3D models needed. Also there is a slight concern that Simutrans might show way too many models at once, so even modern GPUs might have problems to display, unless one implements tricks. Like several levels of detail (simpler models being used when many objects are on screen).

I think the basic coding is comparably easy, but the problems mentioned above will be the real problems that make or break the project.
Title: Re: Simutrans in 3D
Post by: inkelyad on August 15, 2010, 11:12:27 AM
Quote from: Hajo on August 14, 2010, 10:03:47 AM
Slightly unrelated, but I'd still assume that a OpenGL rendering backend gives a performance boost, not a slowdown, if the rest of the code is kept as it is.
As I understand, SDL can use hardware acceleration for 2D rendering. But current simutrans engine don't relay rendering work to SDL.
Title: Re: Simutrans in 3D
Post by: Spike on August 15, 2010, 03:07:25 PM
Yes, Simutrans uses SDL only as a framebuffer and manages the bitmaps itself. This was done so to get maximum ease for porting to other rendering backends.
Title: Re: Simutrans in 3D
Post by: Banter on March 05, 2011, 07:00:13 PM
Quote from: Hajo on August 15, 2010, 10:00:33 AM
My concern was that there might not be enough manpower to create the 3D models needed.


I am happy to help with 3D models. Is there any particular person to talk to about it?

Regards
Title: Re: Simutrans in 3D
Post by: neroden on March 07, 2011, 03:39:34 AM
I will state this: if you want to go 3d, or even "pseudo-3d", while retaining *ANY* of the existing code, it is important to separate the game logic from the rendering.

At the moment it's all mixed up.

Some of the work I have been doing will separate parts of the game logic from the rendering.  Once we have a game with clean(er) separation between game logic and rendering, we can think about putting in a 3d engine.  The game logic will still be grid-based, but the grid for game logic purposes need not have such a tight linkage to the rendering.  But there's no point in trying to do it while the rendering is completely mixed up with the game logic, as it is now.
Title: Re: Simutrans in 3D
Post by: prissi on March 07, 2011, 11:30:09 AM
The rendering is very little mixed with the game logic. Just replace (in simintr.cc)

void intr_refresh_display(bool dirty)
{
wasser_t::prepare_for_refresh();
dr_prepare_flush();
welt_ansicht->display( dirty );
win_display_flush(welt_modell->get_active_player()->get_konto_als_double());
dr_flush();
}

by your rendering code ... (Of course, event handling and the like still needs to be processed by whatever framework you use. You may of course also need to replace mark_xyz_dirty by dummy calls, since this just optimisation for current handler.)
Title: Re: Simutrans in 3D
Post by: Václav on March 07, 2011, 08:24:54 PM
Mostly for Neroden:
I think that complete separation of (game) logic from graphics is foolishness. It is good idea - but something what is hard to do - in games (or even in web pages programming) and sometimes quitely irrelevant. At all times you will have some level of mixing of logic and graphics.
Title: Re: Simutrans in 3D
Post by: lukesleftleg on March 07, 2011, 09:04:39 PM
I haven't posted here for quite a while. Mostly because I've been extremely busy with my degree (BSc Multimedia & Computer Science), but for my final year's project, I've been working on a 3D engine for a Simutrans-type game.

It's still in a very early stage: A-Star pathfinding is implemented, I've got trains following tracks (which are a bit different from the Simutrans type, and come in straight or curved sections much like in Locomotion), and I've just implemented signals, although I've still got some bugs to iron out with them. Oh and inertia is in, but more physics such as mass and gravity still need implementing.

There's a video of the current version here:
http://www.youtube.com/watch?v=J_UwKyueRgc

There's also this, which was a very early test to see if I could get trains to follow a path of vectors. This train's got 500 carriages. It seems to work smoothly enough.
http://www.youtube.com/watch?v=PBSmgplCeV0

I haven't started any kind of game logic yet, although I've always intened the game to play more like Simutrans than any of the other transport sim games (TTDX etc), assuming I get that far with it.

I'm afraid I don't speak C or C++ yet, which is why I haven't looked at any of the Simutrans code, and which also explains why my code is currently written in Java using the jMonkey 2 Engine.

I've been having a few problems with that though, as GUI support seems a bit flaky. JME3 is out, but I haven't been able to get it working yet. I was vaguely thinking about porting it to C# with XNA, which is very nice, but only compiles for Windows machines (or XBOX 360).

Anyway, I've got another six weeks or so to work on it before it's due to be handed in for marking, but once that's been done and it's been handed back, I'd be happy to share my code, if it's of any use.

It's a bit of a mess right now, and like I say, not entirely bug-free, but I've got to tidy it up before handing it in anyway.

Oh yeah, there's also these:
This one's a grab of the landscape generator I'm currently using.
http://s107.photobucket.com/albums/m286/LukesLeftLeg/?action=view&current=Terrain1.jpg

And this one's an early render of the rail pieces.
http://s107.photobucket.com/albums/m286/LukesLeftLeg/?action=view&current=Models.jpg
Title: Re: Simutrans in 3D
Post by: Banter on March 07, 2011, 09:19:47 PM
@lukesleftleg what is the possible file format for 3D models in your engine? 3ds, obj, other?
Title: Re: Simutrans in 3D
Post by: lukesleftleg on March 07, 2011, 09:43:26 PM
Well, with jMonkey 2, I can take them as either OBJ or 3DS and convert them to JME, which is jMonkey's internal 3D model format. Pretty much just a data-dump of an internal TriMesh object, as far as I can tell.

Either work well, but I've been using OBJ mostly.

It'll do a couple of other formats, but I think it has trouble with them.
There's a load of links about 3/4 of the way down this page about model formats with JME.
http://jmonkeyengine.org/wiki/doku.php/jme2:jme2

Title: Re: Simutrans in 3D
Post by: vilvoh on March 08, 2011, 08:18:05 AM
That 3D engine looks great, lukesleftleg!
Title: Re: Simutrans in 3D
Post by: lukesleftleg on March 08, 2011, 09:56:43 AM
Well thank you very much.

Shall I keep at it then?

I'm afraid I can't make it public until it's been marked, but once that's done, I'll release it.
Title: Re: Simutrans in 3D
Post by: Ashley on March 08, 2011, 11:32:29 AM
Looks great, the tracks representation especially. Can you summarise in more detail how you're drawing the track sections? I am guessing that they are automatically generated somehow based on a particular curve?

I was working on a more flexible track system which made use of bezier curves to draw track a while ago. I wasn't using vectors for motion though (maybe that's a better approach!) and I'd be interested to know how that works for you exactly. The method I chose for track following was to use the intersection between a circle (or sphere in 3D) and the track to model bogies on the cars and the linkages between them.

Great stuff though, do keep at it. :)
Title: Re: Simutrans in 3D
Post by: lukesleftleg on March 08, 2011, 04:40:05 PM
Hi Timothy.

I can certainly try. Although I’ll apologise in advance if this gets convoluted.

Originally, I actually tried making the tracks totally grid based, much like the RIBI system in Simutrans, but the main problem I found with that was the sheer number of track or viaduct models that would have to be made for every possibility of rail combinations in each square. Also, I wanted to try something else.

The way it works is that it’s still grid based in terms of the placing of each track piece (although this could be adapted), but the vectors that the trains follow are part of the track piece, rather than part of the main world grid.

In the current version, there are nine different types of track piece, eight of which are shown here. (The ramp piece isn’t shown as it’d look exactly the same as the straight piece).

(http://i107.photobucket.com/albums/m286/LukesLeftLeg/TrackDEMO.jpg)

Basically, in the constructor for a Rail object, all the vectors (the white dots) get set up depending on the required type of Rail piece and its rotation and position in the world grid, along with a number of ‘Location’ objects, which are simply placeholders for grid locations, and also the start and end directions for the Rail piece.

For each piece, there are two sets of Location objects. One set remembers the start and end locations for the Rail piece (shown in pink), and the other set keeps track of the ‘LookAt’ locations (shown in green), which are the locations where it would expect to find another Rail piece that might (or might not) connect with itself.  In the case of diagonal ends, the start/end locations are in the same spots as the LookAt locations. I wasn’t sure if this would work, but it seems to work ok with the extra direction check.

There’s also a third set of Location objects, which account for every Location that the Rail piece occupies, and the ‘World’ object keeps track of these in the main world grid. All the Rail object knows about is the X,Y and Z values for its own set of locations, and it’s own vectors, but it does have a method called canConnectWith(Rail other), which is used to check whether or not it can connect with another piece by checking its own start/end and LookAt locations against those of the other Rail piece being checked, as well as checking its own start/end direction against the other piece’s start/end direction.

All the pathfinding (A-Star) happens in World, which returns an array of Rail pieces which are then used in the constructor of a Route object, which basically copies the vectors from the rail pieces into its own array of vectors. Route objects were originally intended to be fairly throw-away, but they’ve got more complex as time has gone on, but it’s the vectors in the Route object rather than the Rails that the train is following.

The algorithm for moving (one carriage of) the train along the vectors looks something like this (in pseudocode):

distanceToGo = currentSpeed * timePerFrame;
nextVector = (get next vector in the route);
distanceToNext = length(nextVector - currentPosition);
while (distanceToGo > distanceToNext)
   currentPosition.moveTo(nextVector);
   subtract the distance moved from distanceToGo;
   nextVector = (get next vector in the route);
   distanceToNext = length(nextVector - currentPosition);
lineToNext = nextVector – currentPosition;
currentPosition = currentPosition + (the unit vector of lineToNext, scaled by whatever’s left of distanceToGo)


I was worried that this would run fairly slowly, which is why I wrote the test with the 500 carriages, but as you can see from the video, it’s perfectly happy about it, even though there’s at least one unavoidable square-root calculation in that algorithm.

But I’m fairly confident that it could be adapted to your Bezier approach. As long as it’s possible to generate the vectors, there’s not necessarily any need to stick to pre-defined rail pieces (although the modelling could get complex, but it might even be possible to generate the rail models from code. I’ve done a lofting algorithm before).

I can’t find it now, but a while back, there was talk of adding Bezier curved rail pieces to Simutrans. There was this applet that someone wrote (was it you?) where rail sections were dragged not so much from square to square, but more from square-edge to square-edge. Anyway, assuming you could generate the vectors, I don’t see why this wouldn’t work with something like that.

Anyway, I think that sort of explains it. Please let me know if there’s anything unclear in that explanation though. The problem is it makes perfect sense in my head, but I’m not sure if I’ve translated that into English particularly well.

Title: Re: Simutrans in 3D
Post by: prissi on March 08, 2011, 07:52:45 PM
Actually, with a little extra information for pathfinding (since now not exactly neighbouring nodes connect and some more check in the way builder (to avoid curves through curves) such a system is certainly also possible within the simutrans framework. (Locomotion does a similar thing, but using isometric graphics with predefined curves.)

But how a user can either select one or the other radius? This seems difficult to me. Also to make the track layout less place consuming, I think in a real game implementation I would prefer the short curve.

As I said before, as long as the objects still move within tiles, such 3D could be relatively easily put into the simutrans engine, given that problems like objects (simple, but nice) and UI (in 3D difficult) are solved. Not by me, of course, but it would keep all the logic of passenger generations, productions, and most of pathfinding etc.
Title: Re: Simutrans in 3D
Post by: lukesleftleg on March 08, 2011, 08:54:24 PM
Yeah, my pathfinding does still need some work, it has to be said. It's not bad, but I think there are some rail configurations that could confuse it a bit.

Unfortunately, my trains aren't defined by the tiles they're in, but rather which rail pieces they're on, or more accurately, which vectors they're positioned between (or on).

But as for selecting rail pieces that have already been laid (different radiuses), this isn't actually too bad when done in 3D because you use mouse picking, which basically fires an imaginary 'ray' directly into the scene through the tip of the mouse pointer and into far infinity, and picks up any meshes it finds along the way. The closest one that turns out to be a rail piece is checked against a HashMap to find the rail object it belongs to, and this is returned.

Again, my one need some work, but it's not too bad. I'll try and demonstrate in a video at some point.

Anyway, I just uploaded this, which was an early demo of the terrain generator. The rail pieces in this one are just mock-ups, and the camera handler needs a little attention.
http://www.youtube.com/watch?v=MSZsQZtZqRg
Title: Re: Simutrans in 3D
Post by: Ashley on March 09, 2011, 07:49:26 PM
Your explanation is very good, thanks. It's an interesting (and very good) system for drawing tracks. Certainly the way you use vectors and have those form the basis for movement/pathfinding gives me something to think about.

The varying curves are also quite nice since it gives you the possibility to have a wider radius of curve (and thus a more realistic railway layout) than with curves limited to being formed inside a tile. My system would allow only for the tighter of the two 90-degree curves you describe (using two pieces of track) so it's a little less flexible. I never really fancied drawing the curves manually :)

It was probably my post, it's one of those great ideas I had and then didn't have time to finish. The post was here: http://forum.simutrans.com/index.php?topic=2474.0, and more on the idea here: http://forum.simutrans.com/index.php?topic=1459.msg14748#msg14748 and here... http://archive.forum.simutrans.com/topic/04061.0/index.html

I got as far as a mostly-working implementation of the track drawing (using bezier curves to automatically produce the sections) and an implementation of A* (to allow for drawing more than one tile's worth of track at a time). Then I ran out of free time :(

I wish I could be at university and work on this stuff full-time :)
Title: Re: Simutrans in 3D
Post by: neroden on March 10, 2011, 03:32:03 AM
Quote from: lukesleftleg on March 08, 2011, 04:40:05 PM
Hi Timothy.

I can certainly try. Although I'll apologise in advance if this gets convoluted.
Looks great!

I'll just say this: keep an abstraction layer (translation layer) between the world coordinates / distances and the rendering distances/coordinates/pixels, and similarly keep an abstraction layer between the internal game-based times and the graphical frame rate / real time stuff.  You've probably done this already, or your graphics engine may do it for you. But it's valuable for stuff like zooming, rotating, slowing the game, speeding up the game, generating minimaps, etc.

Simutrans clearly had to hack the abstraction layers into the code after the game was written, and this *shows* in the code -- this is the sort of stuff which makes the code hard to read.  I also know graphics engines designed for first-person-shooters usually do *not* have that kind of abstraction layer.
Title: Re: Simutrans in 3D
Post by: lukesleftleg on March 10, 2011, 12:17:32 PM
@Timothy

Hehe, I hear you there.  :)
This project would be so much further along if my University didn't keep throwing work at me (as would some powerlines I promised Sojo a couple of years back for Pak96.Comic, but that's another story).

Anyway, thank you very much. Just one thing I think I might have been unclear about though, my pathfinding happens at the rail piece level, rather than at the vector level. The vectors are only used for pulling the train along.

The pathfinding as I've got it currently goes from start rail piece to end rail piece. Starting with the first piece, it gets any rails that are connected to the current rail by looking at the LookAt locations of the current rail. Any rail with a start/end location at that point are tested for connectivity, and added to the ToDo list if they do connect. (The A* heuristic just uses pythagoras on the average position of all vectors on a rail piece, which'll be somewhere around the mid-point. Any suggestions for a better heuristic would be most welcome).

I'm afraid I can't take credit for designing those rail pieces though. Those shapes are almost straight copies of the pieces in Locomotion, although I still had to sit down and work out all the geometry for them myself. Those pieces aren't set in stone though, I just needed some pieces I could work with so I could get on with other parts of the program. Like I said, the system would probably work for any curves you can generate the vectors for.

I took a look at your website. Fascinating stuff, although I'll have to install Python to get it to run, which I'll do when I get home from school today. Actually, it wasn't the one I was thinking of (although very interesting in it's own right).

After a little digging, I found the link I was looking for, and who'd have thunk it, but it was a link in one of your posts.
http://theory.stanford.edu/~amitp/game-programming/road-applet/roads.html

I had a look at the source code, and I think he just uses Java's own bezier functions. I need to read up on it, but as far as I understand, a bezier algorithm isn't too hard to write, and as long as you can do that, generating vectors from it shouldn't be a problem. Lofting a simple cross-section shape along it to generate a 3D object isn't too hard either, although a viaduct with arches cut out would be harder.

@neroden

Thanks very much.
Don't worry though. The rendering is completely seperate from the world logic.

In fact, I think the only time 'World' (the back end) and 'Game' (the front end) talk to each other is when Game says "World.act(timePerFrame)", which moves everything, and a bit later when World is telling Game where everything it has to draw is.

I have to be honest though. The timing is happening in the front end at the moment, and is tied up with the frame-rate, but I'll heed your advice, and see what I can do about separating that.
Title: Re: Simutrans in 3D
Post by: Václav on March 14, 2011, 04:38:02 PM
Quote from: Timothy on March 09, 2011, 07:49:26 PM
and here... http://archive.forum.simutrans.com/topic/04061.0/index.html
...
(http://archive.forum.simutrans.com/topic/04061.0/13320/loco-madness.JPG_thumb)
Locomotion bridge chaos ... it is something why I have played it for quite short time (in comparison with Simutrans and TTD).
Title: Re: Simutrans in 3D
Post by: skreyola on March 15, 2011, 05:36:02 PM
What about diagonal crossings? I know those have been requested in ST main, so it might be worth considering.
Title: Re: Simutrans in 3D
Post by: Markohs on May 11, 2011, 09:58:22 AM
Hi.

After reading this whole post I think I can share you my toughts on this:

- I think a 3D rendering engine whould make simutrans a better game.
- This new 3D rendering engine should work with any of the existing pak's, it should just add suport for 3D models, but the old objects should be displayed anyway. This will open the path to existing PAK's expanding to full 3D when the artists wish to.
- The map foundation, tiles with slopes should be preserved as it is, just displayed in 3D, all the path-finding and possible layouts of tracks whould be the same. After this 3D port progresses, we *could* add new features like spline railtracks or so, but that whould break the back-compatibility, I'd leave this for the future.
- I think you should stick to C++, integrating lua into game for "addons/macros" in the future, but as another development project within simutrans. Both are great ideas, 3D and lua, just I think they are independant ideas and have to be developed independently.

I have myself good programming skills, I'll try to make some experiments and see if I can help you, no idea if I'll be able or no, don't wanna raise false expectations. ;)

Thank you all developers/artists/mantainers for making such a beautiful and great game.
Title: Re: Simutrans in 3D
Post by: Markohs on May 13, 2011, 12:01:51 PM
 I'm trying to figure if this 3D simutrans project is feasible, as a personal project just for the sake of having some fun coding. Reading the code and learning the OGRE framework, I'd like to ask the developers a few questions. So far I think the project is not easy but is doable, but to make me things easier:

I was thinking into implementing the basic map tile with 4 corners, using 3d shapes, the Y coordinate of the corners diference must be 0 or 1, as in game, that whould make just 4 shapes necessary, that can be rotated as needed, flat, one corner up, 2 corners up and 3 corners up. Map whould be a composition of all those tiles. My first aproach to the problem was this one, later I found http://www.ogre3d.org/tikiwiki/Ogre+Terrain+System, that generates the terrain from a heightmap and manages all the light/mapblocks/textureloading for itself, I have to see if this module mixes good with the idea I had in mind, what do you guys think?

About the OGRE framework, it integrates well with OIS input/output system, while simutrans uses sdl for all this  I *think*, am I wrong?

About simutrans code, it whould help me if someone can point me a bit wguch files implement the "view" code, so far I've identified "simgraph?.cc" as important files, I miss much more?

Regarding the UI widgets my first idea was just leaving them there.

I know my message is vague and it doesn't really say much, I just wanted to know if someone can point me a few ideas and just some pointers of where to start.

Thanks fo your time.
Title: Re: Simutrans in 3D
Post by: Dwachs on May 13, 2011, 02:29:48 PM
Quote from: Markohs on May 13, 2011, 12:01:51 PM
About the OGRE framework, it integrates well with OIS input/output system, while simutrans uses sdl for all this  I *think*, am I wrong?
Simutrans supports SDL, GDI, Allegro as such a system

Quote
About simutrans code, it whould help me if someone can point me a bit wguch files implement the "view" code, so far I've identified "simgraph?.cc" as important files, I miss much more?
simgraph*.cc contains the low-level stuff: drawing pixels, lines, text, images into an image buffer. This buffer is then used by eg SDL to be copied to the actual screen.

simview.* is the drawing routine for the main view of the landscape.

Somewhere in simwin.cc is the main draw routine intr_refresh_display(), that also calls function to draw the gui, ticker, bottom bar etc.

In order to implement a new display framework, you have to rebuild the functionality of simgraph (for low-level pixel moving) and of simsys_* (for OS dependent stuff, interface to simutrans event handler). If you wnat to go full 3D then a lot more has to be changed, as there will be no sprite images to be drawn but rather 3d models.
Title: Re: Simutrans in 3D
Post by: Markohs on May 13, 2011, 04:30:46 PM
Quote from: Dwachs on May 13, 2011, 02:29:48 PM
Simutrans supports SDL, GDI, Allegro as such a system

Then there is not really a need to add another dependency with OIS, I guess. I'll try to stick to SDL for input/output, if possible.

Quote
simgraph*.cc contains the low-level stuff: drawing pixels, lines, text, images into an image buffer. This buffer is then used by eg SDL to be copied to the actual screen.

simview.* is the drawing routine for the main view of the landscape.

Somewhere in simwin.cc is the main draw routine intr_refresh_display(), that also calls function to draw the gui, ticker, bottom bar etc.

In order to implement a new display framework, you have to rebuild the functionality of simgraph (for low-level pixel moving) and of simsys_* (for OS dependent stuff, interface to simutrans event handler). If you wnat to go full 3D then a lot more has to be changed, as there will be no sprite images to be drawn but rather 3d models.

Mmmm... that makes much sense, thanks.

Yea, the plan was going full 3D, using 2D shapes where no 3D model is available, like the "DOOM" game objects for example, like on trees or buildings for example. Ground tiles will allways be 3D with a texture applied (dunno yet if picking the same texture from the current tiles in PAK files or just treat ground just diferently). I also have to get into the thing of making a plugin for ogre so he can pick the models/textures from the current PAK files, and making them able to store 3D meshes and textures, maybe. But that will come in the future, atm I'm just wishing to be able to import a savegame and showing the terrain, with a working camera and showing our current UI.
Title: Re: Simutrans in 3D
Post by: Banter on May 13, 2011, 07:26:19 PM
Quote from: Markohs on May 13, 2011, 04:30:46 PM

Yea, the plan was going full 3D, using 2D shapes where no 3D model is available, like the "DOOM" game objects for example, like on trees or buildings for example.

As a 3D artist, I am more than happy to help you with this project, Markohs.
Title: Re: Simutrans in 3D
Post by: Markohs on May 14, 2011, 01:28:45 AM
Quote from: Banter on May 13, 2011, 07:26:19 PM
As a 3D artist, I am more than happy to help you with this project, Markohs.

Thank you, Banter, so far the project is far from done, I'll contact you when I have more details and have some code base ready to use models/textures, but in:

http://www.ogre3d.org/tikiwiki/OGRE+Exporters

You can check some exporters that might be useful to us, I've been thinking about making simutrans tiles x=1 z=1 y=0.3 in sizes and making some experiments about texturing/lights, I'd love simutrans objects/mountains to project shadows. I'll work this weekend and contact you soon, I hope.

It whould be great to have a building, a train (animated and non animated), one tree and a bus to make some tests and see how things mix together, so if you got some spare time please try to send me them.

Thank you for you interest!
Title: Re: Simutrans in 3D
Post by: Markohs on May 14, 2011, 05:39:27 PM
Quote from: Dwachs on May 13, 2011, 02:29:48 PM
Somewhere in simwin.cc is the main draw routine intr_refresh_display(), that also calls function to draw the gui, ticker, bottom bar etc.

Dwachs, I think you are redfering to 'void win_display_flush(double konto)' in simwin.cc, am I right?

It's hard to read some parts of the code since all the german around, but I think I have more or less the idea now of how to plug the new code here, testing...
Title: Re: Simutrans in 3D
Post by: Markohs on May 18, 2011, 07:25:48 AM
Quote from: Markohs on May 14, 2011, 05:39:27 PM
Dwachs, I think you are redfering to 'void win_display_flush(double konto)' in simwin.cc, am I right?

I answer myself, he refered to:

void intr_refresh_display(bool dirty)

in simintr.cc
Title: Re: Simutrans in 3D
Post by: Markohs on May 18, 2011, 08:55:08 AM
I have working on this project for some time, so far I have a 3D viewport working, with a camera and some basic functions. I have some questions that maybe someone can help me with

As a 3D program, I need to have the triangle mesh of the map created as a whole or some method to create it when needed, to be able to render the view correctly, I can't re-create the whole terrain "physically" each frame. Basically simutrans if I understanded it correctly redraws the screen each time it's necessary from the internal structures, in simworld.cc. I see simutrans code stores all terrain in a array 'plan' of 'planquadrat_t' objects, that contain the tiles per se, with all their atributes. that's ok.

I'm having some problems locating where the heightmap is stored and how to map those tiles corners in the 3D space, where are the heigh coords of each corners, are they stored in grid_hgts? I see void karte_t::init(einstellungen_t* sets, sint8 *h_field) receives the heights in the h_field

Another problem I face is locating when a change in the world's "geometry" is happening, is there a function where I can interecept when one "point" changes height?

I'm sorry if this are basic questions to you, but I'm reading code for some hours already and some pointers could save me quite a lot of time. :)

Thank you!
Title: Re: Simutrans in 3D
Post by: prissi on May 18, 2011, 10:06:30 AM
The heightmap was discarded several versions ago. Currently the height is stored in the z-koordinate of each ground and its slope is also stored there. There is however the array grid_hgts, which are the "natural" grid height of most tiles. (Those disagree on tunnels, houses, bridges, and artificial slopes, but are correct for almost anything else. Thus a good starting point imho.)

set_grid_hgt() sets a height; but this is not called for articial slopes.
Title: Re: Simutrans in 3D
Post by: Markohs on May 18, 2011, 10:39:26 PM
mmm... ok, thank you.

So I'll start on grid_heights, to display the basic mesh.

If I understand it all this correctly for complete landscape rendering I'll have to deal with the planquadrat_t and grund_t classes. I'm thinking myself planquadrat and grund classes could just simply notify the 3D layer when they get created/modificated, in a observer pattern fashion, that whould make things very easy, even through I'm not sure if performance whould be crappy, what do you think?
Title: Re: Simutrans in 3D
Post by: prissi on May 18, 2011, 11:06:29 PM
The got altered really a lot of times, at least when they are ways etc. Actually such tiles are merked dirty before the redraw, i.e. a dirty tiles within field of vision have a new content.

But I am curious. How else would you handle some millions of things if not on different tiles? A list containing all of them does not really work; simutrans had those lists once, but they ceased working reasonable at 1024x1024 tiles.
Title: Re: Simutrans in 3D
Post by: Markohs on May 19, 2011, 12:14:06 AM
I'll try to reuse the current memory structures, expanding them as little as I can, to save the memory footprint of the program.

I'm using a #define 3dengine to add 3d code where needed without breaking the 2D code, or coping and renaming source files when needed.

About the tiles, each tile will correspond to 4 vertexes forming 2 triangles, assuming lowest detail, it might be richer if I see it works. The problem will be that storing all that mesh in memory will be impossible assuming video cards use to have 256Mb - 1 Gb memory it will be completely impossible to have all vertexes/shades/textures loaded, so I'll have to use paging. Generating the complete mesh and writing it to a external file, and loading it when required to the video card. This sounds harder than it actually is, since Ogre Framework already has support for this and it's done automatically.

http://www.ogre3d.org/tikiwiki/Paging+Scene+Manager
http://www.ogre3d.org/tikiwiki/Ogre+Terrain+System




Maybe I didn't understand your message, now that I read my reply again, I'll try to explain myself.

At the moment the program shows the normal Simutrans-2D window plus an extra 3D window with a movable camera, making you able to fly-through the world.

No, I think the current way of simutrans to handling the tiles is perfect, and my aim is to not change anything of the simutrans inner code, I just want to make a 3D view capable of showing the terrain and objects. The inner code of simutrans should stay as it is, given it's proven software and it's been working for years. Also, I'm not interested of changing a single thing of that cause there is not really a reason to.

My problem is how to extract the geometry of all to be able to keep a 3D mesh working showing all what's happening in the simutrans world, and so far I'll just add some calls to re-sync the 3D world with the inner structures everytime grid_hgts is changed in any way.

trees, buildings, ways,stations, underground tiles, a new UI... That will come in the future, not thinking on it *yet*.

Title: Re: Simutrans in 3D
Post by: Markohs on May 20, 2011, 11:42:45 AM
I'd need the help of some artists to get some ground textures, just basic ground, I've thinking in making

- Deep ocean
- Close to shore ocean
- Shore water
- Beach
- Grass
- Dark vegetation
- Desert
- Rocks with vegetation
- Rocky formations
- Light Snow over grass
- Snow

And maping them directly with heigh, but I have not decided nothing yet, any ideas/volunteers?

They whould need to be in DDS format:

http://www.rigsofrods.com/wiki/index.php?title=Making_DDS_textures
http://developer.nvidia.com/legacy-texture-tools

Specular and heigh versions for each one.
Title: Re: Simutrans in 3D
Post by: VS on May 20, 2011, 11:55:54 AM
Simutrans already generates some tiles from textures, so you could just take these. Perhaps this is good enough for start?

http://simutrans.svn.sourceforge.net/viewvc/simutrans/pak128/base/grounds/texture-climate.png?revision=480&view=markup

Bumpmap is flat, of course.
Title: Re: Simutrans in 3D
Post by: Markohs on May 20, 2011, 02:04:05 PM
mmm... yea, it will be enough for now, thx a lot! ;)
Title: Re: Simutrans in 3D
Post by: Markohs on May 21, 2011, 01:27:48 AM
Thought maybe some of you whould like to see how it's looking, 2 screenshots of the  work so far, I'm progressing, slowly but progressing...

http://imageshack.us/photo/my-images/821/86548913.png/ (http://imageshack.us/photo/my-images/821/86548913.png/)
http://imageshack.us/photo/my-images/20/ss2li.png/ (http://imageshack.us/photo/my-images/20/ss2li.png/)

Today I did read prissi's words about 3D in simutrans in a interview and after some programming I have to agree on what he did say about the inner parts of simutrans are maybe too dependant on the 2D display mechanics, even mantaining the tile structure.

I don't really have the whole idea of the changes needed so far, when I have a schema of what whould be good to change, do you mind if I post here them and submit some patches ?

Edit: changed URL to hicher resolution versions
Title: Re: Simutrans in 3D
Post by: Ashley on May 21, 2011, 09:49:56 AM
That's pretty good progress :)
Title: Re: Simutrans in 3D
Post by: prissi on May 21, 2011, 12:26:22 PM
Since that interview a lot of things evolved. For instnace you have now internall 36 positions (or 170 on diagonals/curves). But displaying stuff in curves will be still a challenge, as some other thing too.

In older versions one tile level was ctually 16 subtiles. The defines to reanble that are still there. (However, since only 8 bits for z-koordinate are used, using 8 levels intratile seems more useful.)
Title: Re: Simutrans in 3D
Post by: Markohs on May 21, 2011, 02:12:07 PM
More Screenshots:

http://imageshack.us/photo/my-images/854/ss3xe.png/ (http://imageshack.us/photo/my-images/854/ss3xe.png/)
http://imageshack.us/photo/my-images/695/ss4cx.png/ (http://imageshack.us/photo/my-images/695/ss4cx.png/)
http://imageshack.us/photo/my-images/839/ss5y.png/ (http://imageshack.us/photo/my-images/839/ss5y.png/)

Back to work now!
Title: Re: Simutrans in 3D
Post by: vilvoh on May 21, 2011, 04:55:07 PM
Looks awesome :D
Title: Re: Simutrans in 3D
Post by: Markohs on May 22, 2011, 04:50:51 PM
A binary win32 preview of the program:

http://dl.dropbox.com/u/30024783/simutrans3d.zip

it doesn't have any pak installed, you'll need one, I was using "pak128.open.r503"

If you don't unzip it in c:\simutrans3d you'll need to edit the resources.cfg and put the correct route there. It will crash if you try to load a savegame, sometimes. Just start a new world, with a size < 2048 or might crash too.

You can fly-though the map, ASDW keys to move, SHIFT to move faster, mouse orients teh camera, and R switch the rendering mode.

I'll share the source code if anyone wants to have it a look or contribute some code, just ask me, any help is welcome.

Areas I'd really love to have someone help are:

1) Textures: As you see, \media\materials\textures\water-diffusespecular2.dds is not really working good, not projecting reflections like the other textures do. So far I'm just adding .png textures from the sample VS pointed me to, but I'm not that good with image editing, my thing is coding, so any help is welcome.
2) Models: meshes are not still in game, but next step I think it's gonna be add some stations or buildings, and I tried to export them from the blender archives I've found. Didn't managed to do it yet, so, if someone can generate some ogre .mesh form http://graphics.simutrans.com/displayimage.php?album=30&pos=2 if whould be great, atm a tile is 10x10 in size.
3) Coding: Any help is welcome, one thing that needs some coding is the UI, if someone wants to make simwin.cc sit on top of ogre or CEGUI or any other contribution, tell me :)
Title: Re: Simutrans in 3D
Post by: prissi on May 23, 2011, 01:09:13 PM
Maybe we should put this into a branch into the svn. It would be good to spread the source to prevent any loss due to whatever problem might happen on your computer.
Title: Re: Simutrans in 3D
Post by: Markohs on May 23, 2011, 04:24:17 PM
Yea, I'm happy to open the code, just give me some time to clean up the debugging code and fix a pair of things. I'd love ppl can give ideas , correct my mistakes, and to hear comments about the code and how to name structures/files in a more correct way.

It's basically adding simsys_ogre.cc and modified simworld.cc and simintr.cc, plus a "3dview" extra directory.

EDIT: But yea, if you open the branch, with the current revision (I synced my code with the svn yesterday), I'll upload the new code tonight.
Title: Re: Simutrans in 3D
Post by: Markohs on May 24, 2011, 02:48:46 PM
Tell me when tghe branch is ready plz, ready to upload the data here.
Title: Re: Simutrans in 3D
Post by: Markohs on May 25, 2011, 12:13:26 AM
More progress:

- Learned how to generate textures with normal maps, now they receive correct specular light. Next release won't have any Nvidia texture, only "simutrans" ones.
- Increased resolution of layer blending that was causing incorrect offsets on textures on big maps.
- Cleaned up code, removed some unnecessary calls, corrected some crashes, reduced memory usage.

Another SS:

http://dl.dropbox.com/u/30024783/ss6.png
Title: Re: Simutrans in 3D
Post by: Markohs on May 27, 2011, 06:45:47 PM
While the svn gets up I've thought I should modify all my work so far to comply with coding_styles.txt, I'm on it, but some questions.

On the origin, I've created a class representing the 3D view, that will contain the GUI, and the game view,  to open the door to having more than one UI open on the same game, that whould be good for multi-monitor computers and might be useful for multiplayer games, maybe. I even thoguht about the possibility of implementing the game in a "windowmanaged" way, so you could open the 2D and the 3D view working at the same time, or having vehicle windows around, like TTD had, but well, we'll see.

But:

At the current code, most of the functions of the GUI in simwin.cc or simworld.cc are global functions, not objects. I understand this generates faster code, that maybe has a historical motivation, and I understand that you prolly prefer it that way, I just wanna know and hear your oppinions about turning all that code into a more OO-oriented code, did you ever thought on that or it's okay as it is now to you?

As a related thing I was thinking about the singleton concept http://en.wikipedia.org/wiki/Singleton_pattern, and use it around, what do you think?

I have a conflict myself, I don't know if I'm using OO too much in the code.

Most of the integration with external libraries is quite heavily object-oriented, the libs I use are:

Ogre: http://www.ogre3d.org/
OIS:http://sourceforge.net/projects/wgois/
CEGUI: http://www.cegui.org.uk/wiki/index.php/Main_Page

Most of these libraries are OO-heavy, and many things are better implemented through inheritance. For example, main class of the new code is defined as:

---------------
class Simu3DApp : public Ogre::FrameListener, public Ogre::WindowEventListener, public OIS::KeyListener, public OIS::MouseListener {
public:
   Simu3DApp(void);
   ~Simu3DApp(void);
---------------

I have to confess even through I have programming knowledge I don't feel confortable taking all the decisions myself, cause I'm just learning and trying new things often, and I have deep respect for Simutrans current coders, I'd like to hear their comments when they feel wanna share something. :)

I wanna state any comment about the code or the design is more than welcome, and I'm a bit embarassed about the quality of the code so far, it needs more clean-up, but I think uploading the code asap will be good for the community, and maybe anyone will get some interest into contributing something. ;)

Title: Re: Simutrans in 3D
Post by: Dwachs on May 28, 2011, 07:30:55 AM
Quote from: Markohs on May 27, 2011, 06:45:47 PM
At the current code, most of the functions of the GUI in simwin.cc or simworld.cc are global functions, not objects. I understand this generates faster code, that maybe has a historical motivation, and I understand that you prolly prefer it that way, I just wanna know and hear your oppinions about turning all that code into a more OO-oriented code, did you ever thought on that or it's okay as it is now to you?
Is is absolutely necessary to change that? I would advise to keep the differences between your branch and the original code as small as possible. That is, implement the 'interface' as defined in simwin.h in whatever way you like, but do not change the interface. I do not know whether this is possible though.
Quote
As a related thing I was thinking about the singleton concept http://en.wikipedia.org/wiki/Singleton_pattern, and use it around, what do you think?
Usign this is fine. The most prominent example in the simutrans code is the class karte_t, which represents the world. There is only one instance of this object alive. This can be made much more explicite in the code for sure.
Title: Re: Simutrans in 3D
Post by: prissi on May 28, 2011, 12:23:09 PM
You could still use the current dialogues, as they just draw into 2D arrays, which could be just bitblt into almost any 3D screen after rendering. If not possible they could be a top layer of foremost flat objects.

As an advice of somebody who learned OOP while coding for simutrans: Do not try OOP just for OOP. Go slowly, it took me quite some time to see really when it made sense to do OOP and at which places it was not such a good idea.
Title: Re: Simutrans in 3D
Post by: Markohs on May 29, 2011, 11:33:49 AM
Quote from: Dwachs on May 28, 2011, 07:30:55 AM
Is is absolutely necessary to change that?
No. I just wanted to hear your oppinions on it.
Quote from: Dwachs on May 28, 2011, 07:30:55 AM
I would advise to keep the differences between your branch and the original code as small as possible. That is, implement the 'interface' as defined in simwin.h in whatever way you like, but do not change the interface. I do not know whether this is possible though.
Yes, I think doing that will be the best.
Quote from: Dwachs on May 28, 2011, 07:30:55 AM
Usign this is fine. The most prominent example in the simutrans code is the class karte_t, which represents the world. There is only one instance of this object alive. This can be made much more explicite in the code for sure.

Yea, I though it can be a nice idea, I'll try to use it around on the new classes, makes code a bit more understandable.
Quote from: prissi on May 28, 2011, 12:23:09 PM
You could still use the current dialogues, as they just draw into 2D arrays, which could be just bitblt into almost any 3D screen after rendering. If not possible they could be a top layer of foremost flat objects.
My first aproach to the area was that one, then I thought reworking the UI could be good, but... well, maybe that's work for another project. Yea, you are right.
Quote from: prissi on May 28, 2011, 12:23:09 PM
As an advice of somebody who learned OOP while coding for simutrans: Do not try OOP just for OOP. Go slowly, it took me quite some time to see really when it made sense to do OOP and at which places it was not such a good idea.

Thank you for your advise, I think that makes much sense. I'll try to do it like that.

Thanks for your comments, Dwachs/prissi! :)
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2011, 07:29:40 PM
I wanted to remake my simsys_ogre.cc (that it's just a copy of the old wimsys_w16) from simsys_s (that I figure it's the SDL version) and I have one problem.

Visual Studio doesn't supply the dirent.h file, even through it's in the posix interface, that windows NT is suposed to support, well, no problem. Problem is all simsys_*.cc files require it, except simsys_w. What does this mean, you build the SDL version with MinGW only? You can't do it with MSVC?

The 3D version should work in linux also, and I like to code with Visual Studio that's my problem. :)
Title: Re: Simutrans in 3D
Post by: TurfIt on June 04, 2011, 07:52:04 PM
Looking at gui/loadsave_frame.cc and gui/pakselector.cc might help as they both use dirent.h. Guess MSVC users don't like SDL...
Title: Re: Simutrans in 3D
Post by: prissi on June 04, 2011, 09:37:58 PM
Look at the defines in said files ...


#ifndef _MSC_VER
#include <unistd.h>
#include <dirent.h>
#else
#include <io.h>
#include <direct.h>
#endif
#include <sys/stat.h>
#include <time.h>
...


By the way, before fiddling with the GUI more needed might be a fall back for non 3D objects, like displaying trees for instance like a cardboard wall with a semi-transparent texture.
Title: Re: Simutrans in 3D
Post by: Markohs on June 05, 2011, 02:43:07 AM
Quote from: TurfIt on June 04, 2011, 07:52:04 PM
Looking at gui/loadsave_frame.cc and gui/pakselector.cc might help as they both use dirent.h. Guess MSVC users don't like SDL...

Mmm... oh, I see, thanks!

Quote from: prissi on June 04, 2011, 09:37:58 PM
Look at the defines in said files ...


#ifndef _MSC_VER
#include <unistd.h>
#include <dirent.h>
#else
#include <io.h>
#include <direct.h>
#endif
#include <sys/stat.h>
#include <time.h>
...


By the way, before fiddling with the GUI more needed might be a fall back for non 3D objects, like displaying trees for instance like a cardboard wall with a semi-transparent texture.

ok, I see what you mean.

Yea, but I wanted to play a bit more with the gui and mouse map movement, to have some decent map movement tools.

The idea so far was using what you suggest, a plane with the transparent texture applied , that will make objects look crap if not from the 4 fixed camera angles the current isometric view uses, not counting the zoom efect. One option is restricting the camera to those 4 angles, and restrict zoom to reasonable levels. This is the simplest option and I think I will implement it, that should make not only trees, but buildings/stations/vehicles displayable, and should not be hard to implement.
Title: Re: Simutrans in 3D
Post by: Dwachs on June 10, 2011, 04:52:52 PM
one should mention that there is now a 3d-branch in the simutrans repositoryat branches/simutrans3d.
Title: Re: Simutrans in 3D
Post by: Markohs on June 10, 2011, 07:04:30 PM
Yea, syncing my code as long as I progress, I go slow but steady I think.

Trying to figure when and where the images from the pakset are loaded in atm, I need to load them all or most of them on the videocard memory (generating SceneManager::createMaterial materials for each) at the startup, trying to understand grund.cc, simview.cc now.

I shall repeat, that if someone wants to give me a hand, there are lots of place I could use a hand, just mail me. ;)

Learning lots of german so far... ;)

BTW: Shall I put:

/*
* Copyright (c) 1997 - 2001 Hansjörg Malthaner
*
* This file is part of the Simutrans project under the artistic licence.
* (see licence.txt)
*/

On all files? All my code is given to the simutrans comunity, just don't know what to put on the headers. ;)
Title: Re: Simutrans in 3D
Post by: prissi on June 10, 2011, 08:57:10 PM

/*
* This file is part of the Simutrans project under the artistic licence.
* (see licence.txt)
*/


should be ok.

About the images: There was once a lot of discussion. Simutrans hat about 10000-65000 images; too much for many OpenGL drivers. Also they are not in any standard format. One "simple" way out would be to render them into a screen with a real alpha channel and only have one large bitmap to copy to the screen. (Since with 3D darkening during night could be done by light setting, rendiering all visible images is not needed.)

The images are loaded in simgraph16.cc under register_image. Their format can be best seen from image_reader.cc or image_writer.cc. It is a 15 bit RLE code with 16 special colors.
Title: Re: Simutrans in 3D
Post by: Markohs on June 10, 2011, 10:57:10 PM
 The idea is to just apply the textures to the Ogre::Billboard items, they are just 2D rectangles that rotate along the Y axis allways facing to the camera, with the texture applied and each with his alpha mask. That makes the rendering trivial, and ogre already provides support for this.

The only problem will be the movable objects (vehicles, pedestrians etc...) that might be needed to be rendered on a second render pass maybe, to draw them on top of the "static" sprites, or they won't be visible until they cross the billboard... or not, considering the texture has a alpha channel this might work without extra code, I'll soon know after some tests.

About the number of textures, well, modern video cards have like a minimum of 128 Mb memory, and considering that the ground will be completelly 3D, and maybe even the roads, rail... that's quita a lot of 2D shapes that won't need loading, just buildings, vehicles, stations... We'll see. :)

Also, the idea is just leading the images when they are in use in map, just load them when any object in map needs them, maybe even discarding far away objects that won't be rendered considering the viewport.

EDIT: if we face memory problems we can even compress the sprites using the Nvidia DDS format, so they are stored compressed in-memory, the hardware uncompresses them on the fly when they are needed. I think this will be no problem.
Title: Re: Simutrans in 3D
Post by: Markohs on June 11, 2011, 12:21:18 AM
prissi:

if I understand the code correctly, you use the zlib functions to create the frequency hash of the images to implement the RLE decoding, and you store the *uncompressed* image in the imd class, but:

   PIXVAL* data; // current data, zoomed and adapted to output format RGB 555 or RGB 565

Can they actually be on both encodings or one of them is historical or decided at compile time? According to:

http://www.ogre3d.org/docs/api/html/group__Image.html#ga7e0353e7d36d4c2e8468641b7303d39c

I should have no problem setting PF_R5G6B5 and plugging the data straight to ogre.

Thanks!

EDIT: nvm, I foundbild_besch_t::decode_img now
Title: Re: Simutrans in 3D
Post by: Markohs on June 11, 2011, 11:28:43 AM
btw, what does "besch" mean? I've found the meaing ribi, dinge, keine, bild, leer... but dunno what besch is intended to mean. :)
Title: Re: Simutrans in 3D
Post by: jamespetts on June 11, 2011, 11:36:42 AM
In the context of Simutrans, "besch" refers to an underlying type. For example, an individual vehicle in the game has a vehicle object. That vehicle object has a pointer to a "besch", which is the type of vehicle (for example, a Routemaster 'bus). The "besch" object, of which there is one for each type of vehicle, will have information about that particular vehicle's capacity, power, maximum speed, etc. - all of the things that are the same for each type of vehicle. The vehicle object, meanwhile, will have data about the vehicle's schedule, its current position and speed, the goods/passengers on board it at present, etc. - all of the things that do vary between types of vehicle.
Title: Re: Simutrans in 3D
Post by: Markohs on June 11, 2011, 11:47:19 AM
That was very useful, thanks james!
Title: Re: Simutrans in 3D
Post by: Dwachs on June 11, 2011, 12:58:52 PM
My guess would be 'besch' = 'Beschreibung' = description / descriptor.
Title: Re: Simutrans in 3D
Post by: prissi on June 11, 2011, 08:00:01 PM
Back to images. The images in simutrans are never uncompressed.

The are darked and rescaled and recolored with player color in PIXVAL* data; But not in any common format, teh format is rather (word=16 bit)
skip pixel, length of next data (in words), data word, skip pixel (until w>pixelw)

Look for recode or display_img_xxx (some of them do player color recolering on the fly). You could just add another entry to this structure pointing to a RGBA 16 bit image, which is always generated on load time.
Title: Re: Simutrans in 3D
Post by: Markohs on June 12, 2011, 12:31:38 PM
Ok, thanks you all for your comments! Working on this now, should be doable, I think the way to go is to create a new resourcemanager for ogre that instanciates the textures on demand, using the functions prissi pointed out. I wasn't aware of the player coulours he pointed, also. Soon I'll know more. :)

http://www.ogre3d.org/docs/api/html/classOgre_1_1ResourceManager.html
Title: Re: Simutrans in 3D
Post by: Markohs on June 14, 2011, 04:45:49 PM
This is being even harder than I expected. Simutrans models the world as quite a lot of different objects and structures, and the render code just uses all that information and renders it when necessary, taking all that information in consideration.

Even a basic object object like a tree is quite complex, considering it has different images that vary on seasons.

My initial aproach of maping initial 2D images to each tile on map creation/loading and leave them static looks poor now, and not sufficient. To do a complete 3D port of the game will require keeping in sync current simutrans objects with the 3D versions, expanding the currrent objects (baum_t,  gebaeude_t,....) with new functionality, or just with some listener code and subscription.
I don't got a clear idea yet of how to make all this, got to think a bit more on it.

Getting the raw images it's no problem, I've done some coding there already and it's doable no problem.

Just stating this to see if anyone has any idea to share. ;)


Edit: I entered panic too soon, ofc I need way more code to display objects, I just focused too soon on see some results fast, it's not possible. Forget what I wrote. ;)
Title: Re: Simutrans in 3D
Post by: prissi on June 14, 2011, 06:54:47 PM
Actually, how to compile the branch. The makefile has no preparations on Ogre or whatsoever?
Title: Re: Simutrans in 3D
Post by: Markohs on June 14, 2011, 09:02:30 PM
mmm.. no, I get an error uploading the vcxproj file, because it's windows CR and the svn rejects it(I know there must be a workaround to make this work but didn't managed to do it yet), but my settings are (replace the paths according your installation):

include_path:
C:\code\CEGUI-SDK-0.7.5-vc10\cegui\include;C:\code\bzip2;C:\code\zlib-1.2.3\include;C:\code\SDL-1.2.14\include;$(OGRE_HOME)\include\OIS;$(OGRE_HOME)\include\OGRE;$(OGRE_HOME)\Samples\Common\include;$(OGRE_HOME)\boost_1_42;%(AdditionalIncludeDirectories)
library_path:
C:\code\zliball\static32;C:\code\bzip2;$(OGRE_HOME)\lib\$(Configuration);$(OGRE_HOME)\boost_1_42\lib;C:\code\CEGUI-SDK-0.7.5-vc10\lib;C:\code\SDL-1.2.14\lib;%(AdditionalLibraryDirectories)
libraries linked in:
SDL.lib;SDLmain.lib;CEGUIBase.lib;CEGUIOgreRenderer.lib;OgreTerrain.lib;kernel32.lib;user32.lib;gdi32.lib;winmm.lib;zlibstat.lib;advapi32.lib;ws2_32.lib;libbz2.lib;OgreMain.lib;OIS.lib


it should compile in linux even I didn't really tried it.

it uses SDL,CEGUI(for basic mouse support, I'll maybe drop that dependency and use just SDL) and OGRE

You can download the binaries (liboost is a prerequisite but gets shipped with ogre) for windows or linux in:

http://www.ogre3d.org/download/sdk/
http://www.cegui.org.uk/wiki/index.php/Downloads

Also, when you generate the executable, you should unpack http://dl.dropbox.com/u/30024783/simu3dfiles.zip in the simutrans directory where you have a working simutrans installation (without the simu3dfiles prefix)
Title: Re: Simutrans in 3D
Post by: prissi on June 15, 2011, 10:17:03 AM
As you are still early in the project, and after looking into the requirements I start to doubt if Ogre is really a good choice. Especially requiring boost will kick out many plattforms, like Haiku (due to gcc 2.95.xx). Also requiring 200 MB of libraries does neither sounds very performant nor giving small distribution packages ...

Maybe one could consider Irrlicht, as this is even more portable (even on Solaris and with software renderer), has a null device usable for servers, uses anyway 16 bit textures, is smaller and claims to be faster ... but there are of course other still like sauerbraten/cube2 http://sauerbraten.org/,

But in the end it will depend on how easy and performant is the integration with the simutrans world model, i.e. with the current mixture of dynamic stuff (pedestrians, vehicles) and scenery. It seems nearly all engines wants to maintain their own scene. Then it boils down on how well they handle millions of tree objects and changes to them.

I think one needs to create a map including billboard trees and some roads and compare the engines again. Preferable over one year including a full season cycle with trees spawning/dying and so on to finally decide.

Btw, nearly all houses in pak.german64 are rendered by a single program. The are very detailed, but reducing them to a simple texture and a simple shape seems possible when the next stage is required.
Title: Re: Simutrans in 3D
Post by: Markohs on June 15, 2011, 10:56:57 AM
Quote from: prissi on June 15, 2011, 10:17:03 AM
As you are still early in the project, and after looking into the requirements I start to doubt if Ogre is really a good choice. Especially requiring boost will kick out many plattforms, like Haiku (due to gcc 2.95.xx). Also requiring 200 MB of libraries does neither sounds very performant nor giving small distribution packages ...

Well, the requred dll's are about 16 Mb only, it's the SDK that are about 200 Mb in size.

About libboost and Haiku (had no idea that OS existed still :) ) you are right, I didn't even think on that.

If they have no libboost, it will break compatibility on them, libboost is mainly used for threads support afaik. Is there any other plattform affected about this? I'm talking about plattforms with OpenGL or Direct3D support, ofc, that requisite is not avoidable I guess.

Quote from: prissi on June 15, 2011, 10:17:03 AM
Maybe one could consider Irrlicht, as this is even more portable (even on Solaris and with software renderer), has a null device usable for servers, uses anyway 16 bit textures, is smaller and claims to be faster ... but there are of course other still like sauerbraten/cube2 http://sauerbraten.org/,

I'll have them a look, yes you are right. I didn't coded so much and I binded myself to Ogre maybe too early without evaluating the alternatives.

Quote from: prissi on June 15, 2011, 10:17:03 AM
But in the end it will depend on how easy and performant is the integration with the simutrans world model, i.e. with the current mixture of dynamic stuff (pedestrians, vehicles) and scenery. It seems nearly all engines wants to maintain their own scene. Then it boils down on how well they handle millions of tree objects and changes to them.

Yea but that's a inherent idea of any 3D engine, the engine has to "own" the world model, to be able to load/unload the objects/textures/materials when necessary to the videocard, I think there is no way to avoid that, even using bare OpenGL requires you to fetch them to the library, and using openGL directives to "modify" the loaded world.

Quote from: prissi on June 15, 2011, 10:17:03 AM
I think one needs to create a map including billboard trees and some roads and compare the engines again. Preferable over one year including a full season cycle with trees spawning/dying and so on to finally decide.

Btw, nearly all houses in pak.german64 are rendered by a single program. The are very detailed, but reducing them to a simple texture and a simple shape seems possible when the next stage is required.

Ok, I'll proceed like that, get to the point that this code is able to render some spreites and compare with other engines.

BTW, excuse me for my poor english, I try to express me clearly, and undestand you the best I can. :)
EDIT: According to http://en.wikipedia.org/wiki/Haiku_%28operating_system%29 they menction they will support GCC 4 in a future release. This sounds a bit strange, Solaris has the same ABI since Solaris 2.5 and binaries are executable even today's version 10, dunno why operating systems developers don't follow this scheme to mantain backwards-compatibility. Well, not the point, through.
Title: Re: Simutrans in 3D
Post by: prissi on June 15, 2011, 02:03:39 PM
Actually the solaris compiler is pretty incompatible with gcc and C99 and would have (at least when I was programming for real Suns in 2000) surely choked on boost; maybe even simutrans back then.

The problem with an OO operation system like haiku or MacOS is, that is actually very tightly bound to the object modell of the compiler. Very simple example is the old old 68k MAC need pascal strings while windows/GEM used C-strings. That is the origin why mac new line is 13 instead of unix 10 or windows 13 10 ...

But back on topic: I think performance will be deciding factor. boost will not run (or will not be favourable) on small machines like smartphones where 16 MB of DLL in 128 MB main memory can make a difference; but then those machines might anyway not be able to run any big 3D game at all.

From a little more googling it seems like Orge is the windows of the 3D libs, large, loaden with features, but neither small nor fast (and imho not so nicely documented). Irrlicht claims speed, sauerbraten memory footprint. But first lets get something to work within Orge as you have it already working; it appears to me that all libs use quite similar concepts, so switching might be not too bad if needed.
Title: Re: Simutrans in 3D
Post by: Markohs on June 15, 2011, 10:10:28 PM
This must be trivial for you I'm sure, but I've been debugging this for some time and I don't see my error, I extract the images and plant them on a square of image[bild].base_w x image[bild].base_h, I "extract" the shape with the following code:


void display_get_base_spritebuffer(unsigned bild,unsigned short* buff){

if (bild < anz_images) {
PIXVAL *src,*dst;

/* src=images[bild].base_data + images[bild].base_y*images[bild].base_w;
dst=(PIXVAL *)buff;*/

src=images[bild].base_data;
dst=(PIXVAL *)buff+images[bild].base_y*images[bild].base_w;


KOORD_VAL h=images[bild].base_h;

if (h<=0)
return;

do {
uint16 runlen = *src++;
do {
// first, transparent pixels
while(runlen--){
*dst++ = 0x8000;
}
// colored pixels:
runlen = *src++;
while (runlen--)
*dst++ = *src++;
}
while ((runlen = *src++));
} while (--h);
}
}


And I get the following result:

http://dl.dropbox.com/u/30024783/Untitled.png (http://dl.dropbox.com/u/30024783/Untitled.png)

What am I doing wrong, is that working as expected? why images "deform" on the top and the bottom while the middle part remains good, are they mean to be drawn on a "diamond" and not on a regular square?
Title: Re: Simutrans in 3D
Post by: VS on June 15, 2011, 10:49:24 PM
Apparently it's not as easy as dumping a buffer.

It's clear that images that fill 100% of width are unchanged, but the others are distorted terribly. Parts of images that fill 100% look ok, but are still shifted, with wrap-around. (I do know these images, heh)

My guess is that you get some part of in-memory compression horribly wrong. I think each scanline has a start/end offset of some sort. The shear-like effect would then come from (not?) shifting the scanlines in the whole buffer by some missing spaces. The effect is then cumulative since you have one continuous buffer... And since the middle part of image is usually widest, it is not distorted that much or less.



edit: I hope it's easy to understand, it's past midnight here, I'm terribly tired and forced to still work mentally ::( Family uncaring for their deadlines but technically disabled, yay.

edit2: Yes, after you take into account the (variable) spacing on sides, an average image "content area" could be roughly diamond-shaped, especially on bottom. That's just an after-effect though.
Title: Re: Simutrans in 3D
Post by: Markohs on June 15, 2011, 11:35:46 PM
Thanks VS, I'm sleepy too hehehe ;)

At the end I managed to fix it, it caused the effect you menction. I was ignoring the initial xoffset, so I was drawing a image of size x,y in a buffer sized x+num,y+num, that was originating the deformation No, I was ignoring the x_start coordinate exactly like you said. :) I also manged to get the alpha blending working.

Thanks a lot!

The "correct" code is:


void display_get_base_spritebuffer(unsigned bild,unsigned short* buff){

if (bild < anz_images) {
PIXVAL *src,*dst;

src=images[bild].base_data;
dst=(PIXVAL *)buff+images[bild].base_y*images[bild].base_w;


KOORD_VAL h=images[bild].base_h;

if (h<=0)
return;

for(  sint16 y=0;  y<h;  y++  ){

PIXVAL *line = ((PIXVAL *)buff) + (y*images[bild].base_w);
uint16 x=images[bild].base_x;

uint16 runlen = *src++;
do {
// first, transparent pixels
while(runlen--){
line[x++] = 0x0000;
}
// colored pixels:
runlen = *src++;
while (runlen--)
line[x++] = (*src++ | 0x8000);
}
while ((runlen = *src++));
}
}
}


And now looks a bit better:

http://dl.dropbox.com/u/30024783/Untitled2.png (http://dl.dropbox.com/u/30024783/Untitled2.png)
Title: Re: Simutrans in 3D
Post by: prissi on June 17, 2011, 03:02:13 PM
Its may comes to late, but there is a code in patches which exactly converts an images into a rectangular bitmap ... (dump_png.diff)
Title: Re: Simutrans in 3D
Post by: Markohs on June 17, 2011, 03:58:05 PM
oh, I see... hehe :)

Well, anyway I was still having problems with some images, but here is a hint I found in that diff:

uint16 width = max( 192, besch->pic.w+besch->pic.x );

The problem it's for example the bild number 8 if I recall correctly, that had x=0,y=0,width=10,height=10, that should be a image that fills in a 100 PIXVAL buffer, but no, accounts for a total of 128 pixels after the RLE decompression. That caused me some segmentation faults, strange.

Maybe that 192 magic number is the min size of a buffer, I'll have it a look, wanted to compile a pak myself and look at the pak creation utilities code to understand it better.

But well, bitmap extraction is more or less done, now I'll move to the next part, extracting a bitmap of the whole dinge, because the image cutting that's done for simutrans objects doesn't apply to simutrans3d objects, for example those large office buildings that fill 2 or 3 tiles should mean just one 3D billboard, not 3.

Working on it. :)
Title: Re: Simutrans in 3D
Post by: Markohs on June 17, 2011, 04:50:17 PM
Quote from: prissi on June 15, 2011, 02:03:39 PM
Actually the solaris compiler is pretty incompatible with gcc and C99 and would have (at least when I was programming for real Suns in 2000) surely choked on boost; maybe even simutrans back then.

Yeah, but that's the compiler per se, I was talking about the binary, You can execute a binary compiled in a Solaris 5.1 machine in a actual solaris 10 machine, without doing *NOTHING*, they are completely compatible backwards, it even executes SunOS 4.0 binaries, given they were compiled for sparc, not motorolla or another chip.

Quote from: prissi on June 15, 2011, 02:03:39 PM
The problem with an OO operation system like haiku or MacOS is, that is actually very tightly bound to the object modell of the compiler. Very simple example is the old old 68k MAC need pascal strings while windows/GEM used C-strings. That is the origin why mac new line is 13 instead of unix 10 or windows 13 10 ...

Yea, didn't think on it, you are right, didn't knew about the pascal lines and MacOS. But even Apple is a good example of backwards-compatibility, if even sold dual processor machines when they changed from motorola to powerPC, to be able to execute old applications, for some time.

Well, sorry about the oftopic, I'm a sysadmin and I like old machines. ;)

Quote from: prissi on June 15, 2011, 02:03:39 PM
But back on topic: I think performance will be deciding factor. boost will not run (or will not be favourable) on small machines like smartphones where 16 MB of DLL in 128 MB main memory can make a difference; but then those machines might anyway not be able to run any big 3D game at all.

From a little more googling it seems like Orge is the windows of the 3D libs, large, loaden with features, but neither small nor fast (and imho not so nicely documented). Irrlicht claims speed, sauerbraten memory footprint. But first lets get something to work within Orge as you have it already working; it appears to me that all libs use quite similar concepts, so switching might be not too bad if needed.

I have to agree with you, I'll try to arrange the code in a way that allows to switch the rendering engine code wiithout much effort, you made me curious about Irrlicht now, I'll have it a look.

And no, Ogre3D has not a great documentation. Most of the info I need I find it on the wiki tutorials or the forums.
Title: Re: Simutrans in 3D
Post by: prissi on June 17, 2011, 05:05:56 PM
So from documentation I like Irrlicht more ...

But on topic: Maybe first only model tree as billboard, as they will probably stay as those even ingame. But for hoses, I think real modells are needed. Some stations are in ravens renders. You can find them on my hp:
http://www.physik.tu-berlin.de/~prissi/simutrans/ for instance Almuthof Station.rar Not sure how much polygon this is though. But the shape is simple enough I think.
Title: Re: Simutrans in 3D
Post by: Markohs on June 18, 2011, 12:47:37 AM
 Well, the diference is not so huge, compare:

http://irrlicht.sourceforge.net/docu/classirr_1_1video_1_1_i_texture.html
http://www.ogre3d.org/docs/api/html/classOgre_1_1Texture.html

One thing I liked from what I read of irrlicht appart from speed and lower memory footprint was:
Quote
Extreme stability. Most libraries for realtime applications crash when the user does something the library programmer did not expect. This is different in the Irrlicht engine. It prints out a warning to (debug-)log and continues, always trying to keep on running.

This can make the development smoother, and the project more stable. I experienced quite a lot of crashes from ogre already, and well, they are not suposed to happen if you code things right, and catch exceptions, but well, maybe it's too picky.

Also, from what I saw so far, Ogre renders look way better than irrlicht ones.

We'll see, the only way to know is trying, I'll implement terrain + sprites + models with both, and then we can compare.
Title: Re: Simutrans in 3D
Post by: Markohs on June 18, 2011, 04:31:55 PM
Quite a piece of art that station. This starts looking very nice, having some problems with blender textures importing, I completed a "learn-blender-in-an-hour" youtube video watching session. :)
Title: Re: Simutrans in 3D
Post by: prissi on June 18, 2011, 09:46:01 PM
I think with Irrlicht, one could stay with 16 bit bitmaps, this could really make a difference. At least hen thinking of simutrans 15 bit pak files ...

But since you are the only one so far go ahead. I am pretty sure soon you will know more about 3D programming than any of us here ;)
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 12:29:37 AM
Quote from: prissi on June 18, 2011, 09:46:01 PM
I think with Irrlicht, one could stay with 16 bit bitmaps, this could really make a difference. At least hen thinking of simutrans 15 bit pak files ...

Ogre supports 16 bit bitmaps too, that's not a problem.

Quote from: prissi on June 18, 2011, 09:46:01 PM
But since you are the only one so far go ahead. I am pretty sure soon you will know more about 3D programming than any of us here ;)

Well, I try to, prissi, learning a lot this last month, I just had some 3D theory plus OpenGL basics  from the degree in computer science, not that I'm really a expert in 3D, but learning.

About Irrlicht, I think I'll end deciding to use that engine for the project, but first I want to end what I started, to make the decision based on solid motivations. :)

But I also know you prefer Irrlicht because it's german/austrian software!! ;) (joking)

A screenshot of the progress so far (coudn't code much since I had to spend quite a lot of time to learn how to use blender, had no idea :) )

http://dl.dropbox.com/u/30024783/Untitled3.png
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 03:39:16 PM
Can anyone translate me this from german please? :)

   /**
   * Dies ist der Zeiger auf den Besitzer des Objekts.
   * @author Hj. Malthaner
   */
   uint8 besitzer_n:4;
Title: Re: Simutrans in 3D
Post by: alexbaettig on June 19, 2011, 03:51:03 PM
I hope that helps,

* This is the cursor on the owner of the object.
Besitzer = owner
Title: Re: Simutrans in 3D
Post by: VS on June 19, 2011, 03:51:30 PM
Pointer to object owner.

I guess "pointer" should be understood somewhat loosely though ;)
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 03:56:07 PM
Thank you both! :)
Title: Re: Simutrans in 3D
Post by: alexbaettig on June 19, 2011, 03:57:56 PM
Pointer is better...
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 06:10:17 PM
Wohooo!! this starts looking better! :)

http://dl.dropbox.com/u/30024783/Untitled4.png
Title: Re: Simutrans in 3D
Post by: prissi on June 19, 2011, 06:14:57 PM
Looks very nice concerning that most came from 2D 15bit bitmaps! Maybe the shadows are a little deep?
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 06:39:07 PM
Yea, I was making some tests on lights, I have to get the ambient light brighter. :)

Right now I'm concerned on the effect the transparent pixels create, they fade from white to the pixel colors, and generates strange effects:

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

I'll see what can I do to fix it.
Title: Re: Simutrans in 3D
Post by: prissi on June 19, 2011, 09:42:01 PM
Well, I think for your project best would be trees without shadow. Then the white borders would be fine. Maybe just modify the graphics a little. YOu can look into the pak64 svn for the images. SInce the shadows are very dark pixels in a rectagular pattern, those could be even removed when creating the images in memory. Try the following code for decode_img():


/**
* decodes an image into a 32 bit bitmap
*/
void bild_besch_t::decode_img(sint16 xoff, sint16 yoff, uint32 *target, uint32 target_width, uint32 target_height )
{
// Hajo: may this image be zoomed
if(  pic.h > 0  && pic.w > 0  ) {

// since offset is implicit within image, do not "xoff += pic.x;"!
yoff += pic.y;

// now: unpack the image
uint16 *src = pic.data;
for(  sint32 y = yoff; y < pic.h+yoff; y++  ) {
uint16 runlen;
uint8 *p = (uint8 *)(target + max(0,xoff) + y*target_width);
sint16 max_w = xoff;

// decode line
runlen = *src++;
do {
// clear run
p += runlen*4;
// color pixel
runlen = *src++;
if(  runlen==1  &&  src[runlen]<5  &&  *src==0  ) {
src += runlen;
p += 4*runlen;
max_w += runlen;
}
else {
while (runlen--) {
// get rgb components
uint16 s = *src++;
if(  max_w>=0  &&  max_w<target_width  &&  y>=0  ) {
if(  s>=0x8000  ) {
// special color
*p++ = 0;
*p++ = rgbtab[s&0x001F]>>16;
*p++ = rgbtab[s&0x001F]>>8;
*p++ = rgbtab[s&0x001F];
}
else {
*p++ = 0;
*p++ = ((s>>10)&31)<<3;
*p++ = ((s>>5)&31)<<3;
*p++ = ((s)&31)<<3;
}
}
max_w ++;
}
}
runlen = *src++;
} while(  runlen!=0  &&  y<target_height  );
}
}
}
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 10:02:12 PM
Thx for the code, integrating it now, I managed to fix the white near transparency, it's due the way the 3D engine handles the bitmap, it scales it to a bigger scale, and since I was using 0x7FFF as a transparent color, taht was "transparent white", what made the transition to not transparent pixels start on pure white, changing it to 0x0000 made the trick, they start from black and look way more natural.

Looks like this now:

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

I'll tell you when the code is integrated, I have some things I've been thinking about how to integrate 2D and 3D items on this simutrans3D versions and hear your oppinions.

Soon more, thanks. ;)
Title: Re: Simutrans in 3D
Post by: Markohs on June 19, 2011, 11:32:39 PM
Well, the thing I wanted to comment to all developers is:

Right now I think there are 2 ways implement the Simutrans3D project, one is a complete back-wards compatible version and the other is a more pure 3D version.

The basic problem are the sprites they are not so easy to move from the 2D version to the 3D version, because some problems arise:

1) Positioning the sprite: I see various approaches to this subject, on the begginging I thought on just planting the middle of the tile, like this:

(http://dl.dropbox.com/u/30024783/Diagram1.png)

This doesn't really work most of the times, because most of the times, the sprites are like this:

(http://dl.dropbox.com/u/30024783/Diagram2.png)

I could place them on top of the green circle I marked, and than whould work, if the camera was facin one of the four isometic angles.

Another option is placing the sprites allways on top of the white line, on the point closer to the camera, that whould look better, but the floor whould show up a lot.

As a conclussion, sprites won't show up good ever, only from the 4 fixed isometric camera angles. That makes me consider limiting the camera to those 4 points of view, and to not offer a free camera at the moment.

2) sprites have more problems, like for example the bitmaps that have 2 layers of images, the base and the "after" one, that happens on bridges or stations for example, that I know, prom pak128, one bridge fabio made:

(https://simutrans.svn.sourceforge.net/svnroot/simutrans/pak128/base/crossings_all/Canal_crossing.png)

The images without road are meant to be painted after the road, and the possible vehicle, are drawn. This is doable in the 3D space I  think, maybe playing with the render passes or the Z-Buffer ordering, I have to investigate this further, but it certainly makes things quite harder. 3D shapes do not suffer from that problem.

3) As prissi pointed out, current simulated shadows are a problem too, but I could maybe try to detect them and remove them.

And maybe more problems I can't think about now.

So, my main idea was just porting the game making an exclusive usage of 2D shapes, and open the door to add 3D models for every item, like vehicles, buildings, gradually, because I think we maybe lack enough artists to make 3D versions of all the items, and it whould be cool to just being able to play pak128, for example, just with 3D rendering. I think this is possible, and I'd like to make it work. Even thought what whould really be amazing is a full 3D world, but lots of code and artist creations are needed for that still.

The blender files from some simtrans images I saw already are a huge help, but require work to plu into the game, they require to be transformed into a single mesh, scaled to correct dimensions and the materials have to be changed lightly. They require work, artists work.

So well, I just wanted to share this tought and hear of any of the coders/artists ideas, anything is welcome. :)
Title: Re: Simutrans in 3D
Post by: jamespetts on June 20, 2011, 12:04:19 AM
I have some doubts that using a 3d engine to render 2d sprites will be much of an improvement on what we already have - in my view, we'd be better off with the option (selectable at the pakset level) of either using a full 2d engine or a full 3d engine. Something half-way between the two is likely to be worse than both.

Note that almost all Pak128.Britain graphics were made from 3d models and should be relatively easy to make into 3d models for the game if there is an easy exporter for Blender.
Title: Re: Simutrans in 3D
Post by: Markohs on June 20, 2011, 07:41:51 PM
 I get your point, makes sense, maybe I should focus 3D and just leave sprites for basic items like trees or pedestrians. More comments? :)
Title: Re: Simutrans in 3D
Post by: inkelyad on June 20, 2011, 08:13:14 PM
Quote from: jamespetts on June 20, 2011, 12:04:19 AM
I have some doubts that using a 3d engine to render 2d sprites will be much of an improvement on what we already have.
But OpenGL accelerated 2d engine can be an improvement. Simutrans is somewhat cpu-hungry on big, wide, FullHD displays.

Markohs, can you make demo for this mode?
Title: Re: Simutrans in 3D
Post by: sdog on June 20, 2011, 08:17:35 PM
Not a dev, still commenting to provide more complexity to discussion. Feel free to disregard.

There's a very good running 2D engine to render 2D paksets. The advantage of 3D is stepless zooming, full rotation and much easier content generation. Don't see a lot of sense of using 2D sprites. If it was an easy stepping stone to get a proof of concept it would make sense, but it seems not really effortlessly to do so.

Can you use shaders to get the vegetation for zoomed out views? Do the engines you plan to use support LoD? (fast google shows, irrlicht no, ogre yes) With the enormous number of objects this might be important.
Title: Re: Simutrans in 3D
Post by: prissi on June 20, 2011, 09:28:14 PM
I think sprites are needed for trees and basic items and as fallback. But due to the very different scales in the end rendered buildings are needed.

But unfourtunately, as far as I know, most blender files will have way too many polygones for a gome. One need to reduce the shape to the essential minimum and do everything else with a texture. I am not sure if there are blender scripts for that.

I think only using trees and maybe pedestrians etc. a full 1024x1024 runs is needed; especially with 3D people will want to see larger worlds ...
Title: Re: Simutrans in 3D
Post by: sdog on June 20, 2011, 09:39:53 PM
reducing the polys is not a big deal, other way round is more demanding :-). For the near lods you want high poly count anyway. For distant lods, you couldn't see the textures. At the beginning simple textures should do.

There are also automated ways to create the normalmaps from higher poly. The finer structures of the objects is left to the shader.
Title: Re: Simutrans in 3D
Post by: Markohs on June 20, 2011, 09:42:48 PM
Quote from: inkelyad on June 20, 2011, 08:13:14 PM
But OpenGL accelerated 2d engine can be an improvement. Simutrans is somewhat cpu-hungry on big, wide, FullHD displays.
Markohs, can you make demo for this mode?

Yes, maybe it's a good idea to render a full scene in 2D first also, and compare results, shoudn't be too hard since code is not that far form there.

Quote from: sdog on June 20, 2011, 08:17:35 PM
Not a dev, still commenting to provide more complexity to discussion. Feel free to disregard.

There's a very good running 2D engine to render 2D paksets. The advantage of 3D is stepless zooming, full rotation and much easier content generation. Don't see a lot of sense of using 2D sprites. If it was an easy stepping stone to get a proof of concept it would make sense, but it seems not really effortlessly to do so.

mm... maybe not complete 2D but most of things can be done, I'll give it a try.

Quote from: sdog on June 20, 2011, 08:17:35 PM
Can you use shaders to get the vegetation for zoomed out views? Do the engines you plan to use support LoD? (fast google shows, irrlicht no, ogre yes) With the enormous number of objects this might be important.

Ogre has better support for shaders, I was reading today about it and it's one of the reasons ogre screenshots use to look better than irrlicht, the suppor of various shader operations, what do you mean, remove the 2D sprites of the trees at certain distance and substitute them by a static texture of vegetation? Didn't think on that yet, what's exactly what you were thinking of?

Yea, LoD is a must in this game I think, but all that is natively supported by ogre, just need to generate the LoD versions outside of the game from what I was reading today:

http://www.ogre3d.org/tikiwiki/-LOD
http://www.joserodolfo.com/mesh_lod_with_ogre

ogre has function to create the LOD versions in the runtime, so we can generate them before packing the meshes

Title: Re: Simutrans in 3D
Post by: Markohs on June 20, 2011, 09:44:41 PM
Quote from: prissi on June 20, 2011, 09:28:14 PM
I think sprites are needed for trees and basic items and as fallback. But due to the very different scales in the end rendered buildings are needed.

But unfourtunately, as far as I know, most blender files will have way too many polygones for a gome. One need to reduce the shape to the essential minimum and do everything else with a texture. I am not sure if there are blender scripts for that.

I think only using trees and maybe pedestrians etc. a full 1024x1024 runs is needed; especially with 3D people will want to see larger worlds ...

I can write a program that loads and lowers the vertex count of meshes already, it's not hard I think, just need to use

http://www.ogre3d.org/docs/api/html/classOgre_1_1Mesh.html#aee0bf1b9c384b31f18d8e5b307df1832

And write the model back maybe, but never tried.
Title: Re: Simutrans in 3D
Post by: sdog on June 20, 2011, 09:48:21 PM
creating the meshes with different lods is something easily left to the graphics people, most are used to do this anyway. there are lots of tutorials and workflows for this out there, it's also not much work. No comparison with the effort to do the uv wrapping for the textures.



edit:
Quote
...what do you mean, remove the 2D sprites of the trees at certain distance and substitute them by a static texture of vegetation?

didn't really comprehend this line at first. And no, what i meant is not to care for the tree sprites at all. The concept is terrain clutter. You just define if a region has clutter but don't care for individual trees, a property set to the ground texture causes the engine to render it with shaders. For such bloody big things as trees, close in you'd need a model though.

Not sure to what degree ogre is going to support it, but there's a bit to be found with google. But if there's something comming, it might be worth to skip eyecandy like trees and shrubbery altogether until the rest is done, perhaps the engine has caught up in the meantime.
Title: Re: Simutrans in 3D
Post by: Markohs on June 21, 2011, 07:49:04 AM
If Pak128.britain has blender sources of most of the items, we could start over there, from my tests with blender it whould be necessary:

0) Use Blender Blender 2.49b or any app that can export to OgreXML
1) Restrict the list of materials and textures, to one common set all models use.
2) Create single mesh versions of the items, and scale them to 10x10 base size (I chose that size, but it can still be varied if we think it's too big)
3) Create LOD versions of the items, maybe 50,200 and 500 or so.

This is quite a lot of work, but well, no problem... Well, anyway, I'll get my hands dirty on 2D + sprites first,
Title: Re: Simutrans in 3D
Post by: Markohs on June 21, 2011, 09:55:38 PM
I'm having some FPS problems just with trees (no buildings even) on a 256x256 map, but found about:

http://code.google.com/p/ogre-paged/

I think this is the way to go, I'll keep you informed if I get importat progresses. :)
Title: Re: Simutrans in 3D
Post by: jamespetts on June 21, 2011, 10:14:28 PM
Hmm - it seems as though it might be a gargantuan amount of work to do that for all the graphics. Have a look at this (http://forum.simutrans.com/index.php?topic=2401.0) thread for some samples of Pak128.Britain .blend files if you'd like to have a look to see the sort of material that we use and think about how best to process the files. Do you think that any of the steps outlined above could be automated?
Title: Re: Simutrans in 3D
Post by: Markohs on June 21, 2011, 11:57:34 PM
it's a quite a  manual repetitive work, but can't be automated easily:

1) Materials: This has to be done by a group of artists, they need to agree on a common material list, maybe a big list, but a list.
2) Appling those materials to the creations is artists work also. (UV maps are supported by ogre afaik, so this can be easy)
3) making a single mesh and exporting it to Ogre XML can maybe be automated using blender python scripting.
4) Postprocessing the OgreXML, scaling the creations to the correct size, move them to the correct offsets and generate the .meshes from them, can be automated too.
5) A direct relation with the .dat name atribute of each .mesh has to be done manually too.




btw, that paging system gives a new direction to my code I think, instead of creating the map and keeping it in-sync with the simutrans world, I'll need to do what prissi pointed out time ago, just load regions on demand and extract the information of that region from simutrans inner tructures.

I'm also planning to change current simutrans3D tiles from being 2 triangles to a mesh of maybe 8x8 vertexes, and simulate a bit more complex tiles than current implemented ones, it will look better.

About the vegetation/trees they are being useful for texting the engine, but I won't use those shapes at the end I think, I'll generate random (or semi-random, basd on climates maybes or heigh) vegetation on zones with trees. The current trees 2D engine relies heavily on x_offsets to generate some entropy and clutter effects, that's not so good idea maybe in Simutrans3D, and the vegetation examples I posted look very nice. We'll see.

Mod note: please do not double-post (http://forum.simutrans.com/index.php?topic=4529.0#post_item4e). Edit your last comment instead.
~fabio


Title: Re: Simutrans in 3D
Post by: Markohs on August 09, 2011, 10:47:12 PM
btw I'm currently coding for my final work in the degree, I'll be able to get back to this in 4 months more or less, if somebody wants to change something or take over the code I'll be happy to help meanwhile.
Title: Re: Simutrans in 3D
Post by: jarocks on August 13, 2011, 10:55:08 PM
Quote from: Markohs on August 09, 2011, 10:47:12 PM
btw I'm currently coding for my final work in the degree, I'll be able to get back to this in 4 months more or less, if somebody wants to change something or take over the code I'll be happy to help meanwhile.

I very much would love to assist with development, with that said I would be willing to take over for the moment
Title: Re: Simutrans in 3D
Post by: jamespetts on August 13, 2011, 11:32:30 PM
If you are interested in a repository of vehicles for Simutrans in Blender format, look here (https://github.com/jamespetts/Pak128.Britain-blends). These are for Pak128.Britain.
Title: Re: Simutrans in 3D
Post by: Markohs on August 17, 2011, 07:39:55 PM
More coding is required before you can start using 3some nodels. you can get the 3some code in the subversion repository. there are some things that need to be sorted out:

- I started using ogre 3d api. it uses quite a lot of memory and the lib binary is big. one of the biggest problems was the terrain module api, its support for paging is not mature. this is a must for simutrans, you can't have a 1024x1024 in memory. I did read there was a guy working on it for Google summer of.code. didn't check if a new version has been released. it might be a good idea to check irrlich api.
- as a first step I think you should do simview.cc work over the 3d viewport. shoudnt be too hard using it as a framebuffer, or using some support from ogre layers.
- mouse support, map navigation needs work too.
- there are kora of other areas that.need work. I got some models to.test around, contact me if you need something, add me to.MSN or par e-mail.

sorry for spelling errors, using a phone atm.:)
Title: Re: Simutrans in 3D
Post by: Markohs on November 28, 2011, 10:00:34 AM
Just for the case someone is wondering, I'm still alive, finishing my degree project still, will take me some time, but getting a lot of new ideas and experience for simutrans 3D (my personal degree project is also a 3D project). ;)
Title: Re: Simutrans in 3D
Post by: Markohs on January 13, 2012, 11:20:38 AM
 I've got some spare time this week and was having a look to this project again and seeing I was a bit stalled in the map rendering (needs too much memory atm) I decided to let it mature a bit more on my head and focus somewere else.

So I thought it was a good idea to start thinking how will I manage the UI, my idea was just reuse the current code mainly in simwin.cc and make those windows/widgets write to the 3D framebuffer each frame, on top of the rendered image.

Having a look at the current code, if I understanded it corectly all widgets are drawn each frame, to the framebuffer, that's returned in "unsigned short *dr_textur_init()", in simsys_x.cc . Am I wrong?

Using a overlay can make the image composition faster, since it's hardware accelerated. I think there are 2 ways to go:

1) Make a big overlay filling whole screen and just let current code write over it each frame.
2) Create one overlay for each graphical element (window) of the UI, and let the overlay system compose the image.

This might even allow to render the current isometric landscape, playing with the z-order of the overlays, but I don't really know if it's worth going that way, anyone knows where does current simutrans use more CPU? Is graphic rendering a CPU bottleneck atm or it's somewere else?

I'll have it a look and see if some profiling is possible already with the code.

Thank you!
Title: Re: Simutrans in 3D
Post by: prissi on January 13, 2012, 12:19:54 PM
I think 1 would not require any code change but the activation of the overlay texture before drawing. That way also menu bar and message bar and so on could be kept.

Option 2 looks a little more complicated. One would set the xy-coordinate for each frame to zero just before drawing starts and activate the individual overlay.

But as there are always main menu buttons and bottom line, I would just go for 1.
Title: Re: Simutrans in 3D
Post by: Markohs on January 13, 2012, 01:56:58 PM
yea, looks like the simplest solution, we can allways refine it in the future, I'll do like that.

About the performance, do you know if drawing the screen takes a significant percentage of the CPU and were? Or the time is spent mostly anywere else.
Title: Re: Simutrans in 3D
Post by: TurfIt on January 13, 2012, 03:00:15 PM
display_image_nc is at the top of the profile. Screen resolution and zoom level have a large impact, but on a small map at normal zooms, think 75%+ CPU used there. As the world population grows, simulation routines start demanding more. Medium to large maps I see 50-50 split image-sim.

The GUI drawing is rather insignificant CPU wise.

Option 1 is likely 'good enough'. As long as the video drivers/card don't have an issue with a full screen transparent overlay.
Title: Re: Simutrans in 3D
Post by: Markohs on January 13, 2012, 03:22:30 PM
zoom and bitmap copying can be completely hardware accelerated, maybe even doing a smooth zoom not limited to a few discrete values, I'll make some tests.
Title: Re: Simutrans in 3D
Post by: Spike on January 13, 2012, 10:28:08 PM
I can't say much about 3D coding, having too little experience myself. But I want to express some sort of support for this project, now that there is actually something happening  :)
Title: Re: Simutrans in 3D
Post by: Markohs on January 14, 2012, 02:01:47 AM
Thx for your support, Hajo. :)

One of the biggest problem I'm facing is trying modify the code to a degree 2D and 3D builds are possible and can coexist, but code is too coupled to the isometric view. I guess it's normal, since this game was designed to work that way, and games do not tend to be thinked in a reusable and modular way that much, specially games with so much history like this one, and were performance is critical.

But that's my target, reaching a point where you choose to run it in 2D or 3D, even having a window inside the 3D game with the current 2D render, or try to display current 2D art in the 3D game, since I think it's a waste all current models disapear.

But maybe at the end I'll realize only 3D models are a option. Step by step.
Title: Re: Simutrans in 3D
Post by: jamespetts on January 14, 2012, 12:51:46 PM
Quote from: Markohs on January 14, 2012, 02:01:47 AM
But that's my target, reaching a point where you choose to run it in 2D or 3D, even having a window inside the 3D game with the current 2D render, or try to display current 2D art in the 3D game, since I think it's a waste all current models disappear.

Not a complete waste - some paksets, such as Pak128.Britain, are drawn by first making a 3d model in Blender, then rendering it. Actually, many of the Blender models have more detail than can be seen in the 128x128px renders, so, in one sense, the greater waste is not to use 3d. The challenge, of course, would be to standardise the material list between the models (theoretically possible, but a great deal of work) and finding a way to export them to the correct format for the (presumably 3rd party open source) 3d rendering engine.
Title: Re: Simutrans in 3D
Post by: Ashley on January 14, 2012, 12:54:28 PM
Does it make sense to maintain the internal representation of the world as a grid of squares given the freedom of movement afforded in a 3D space? Especially if we're going to consider replacing sprites with 3D models, the possibilities available from more complex terrain, or free-form track start to make it look very attractive to re-engineer other aspects of the game as well...
Title: Re: Simutrans in 3D
Post by: Markohs on January 14, 2012, 01:03:52 PM
james: Yes, but you have the comic paksets or the Excentrique one. Of course they can replicated again in 3D, but they are created as pixelart. I'd like to find a way to make some use of those old graphics.

As I see it now 3D is a extension, add 3D versions of the items to the pak, so the pak can keep working in 2D, and use 3D versions of the object if they exist, easing the transition.

Timothy: That's a posibility we can explore, but AFTER we got a working 3D version, I'd focus in having what we have now in 3D, and leave rest to the future, as extensions.
Title: Re: Simutrans in 3D
Post by: Ters on January 14, 2012, 02:11:09 PM
I suspect dropping the grid would be such a major change that it would no longer be Simutrans, but another game, a sequel of sorts. Personally, I find that games start looking worse as the landscape becomes more realtistic than in Transport Tycoon and Simutrans. Both Railroad Tycoon 3 and Locomotion look worse, despite having better graphics.

When the graphics is simple, I can live with the fact that trains go up 30 degree inclines and turn on a dime. But when I had trains going up 30 degree inclines in Railroad Tycoon 3, it just looked stupid. Basically, at some point, which for me comes rather early on the realism scale, you have to ditch the various different scales. That in turn means you need very large maps. A single mountain would be thousands of "tiles" wide. But there are games and applications that can pull that off, like flight simulators and Google Earth. Well, that was a rant from me.
Title: Re: Simutrans in 3D
Post by: Markohs on January 14, 2012, 04:35:22 PM
 Have to agree with you Ters. Since we can't simulate the world to a photorealistic point, a comic-like or clearly artificial view seems more natural to us, just like World of Warcraft for example doesn't aim to photoquality models but to comic-like ones, when one tries to make it look real, it doesn't just look good enough, like Age of Conan for example. And applied to Simutrans, the grid is part of this.

But implement some type of spline based rails or something that makes the game a bit more flexible that it's now can be good, for example diagonal double tracks, that look horrible now, or some intersections of ways, and the way trains turn on curves, can be better in 3D. Or add some light sources or transparencies, we'll see.

My goal is that simutrans looks a feels like something similar than Simcity 4 or Starcraft 2. Will I manage to get close to that? I don't know, I hope to get close enough. ;)
Title: Re: Simutrans in 3D
Post by: missingpiece on January 15, 2012, 05:47:28 PM
Wow, I just found this thread and read through the "story of ST going 3D" in time-warp of the past two years that this has been going on. And it was a very exciting read. I only speak Java, but I have no idea how to paint a pixel on a display object. So I think it is amazing what you wizzards do with available frameworks and the material of simutrans. Let me tell you that screenshots of your work in progress are much appreciated by the "Joe Average" in the thread's audience. You may even want to post performance graphs if that is what you're working on. Geek porn FTW.

One question I had when you were talking about how to go 3D with paksets that have pixeled assets : isometric view has the benefit of not "losing" any visual information from the front edge of a house to the rear ones that we see in the sprites today. The viewed object does not narrow down towards the rear ( I'm no 3D artist and may lack the technical terms for the optical effect ). Anyhow, would it not be possible to automate the recalculation of the two sides into two straight panes ( being orthogonal to the view ) ? And then you would use that as a texture to put on a very, very simple model ? Not as an ingame calculation, but as a post-production work in the pakset teams to at least have something.
Title: Re: Simutrans in 3D
Post by: Markohs on January 15, 2012, 06:29:26 PM
Thx for your comments missingpiece.

What you are refering to I think it's about orthogonal and perspective projection, orphogonal projection doesn't take distance to the camera as a factor, just as those plans we made at hand I guess when we were 10 years or so at school. Perspective projection takes distance as a factor so objects far from the camera look smaller than the ones in the front.

Well, the idea was just planting a 2D plane over the ground, and set his properties to allways face the camera, that way we can use the old graphics. They are called Billboards, playing with the placing I think we'll manage to get a good render even without 3D models.

ATM I'm just substituting simgraph16 with new code that uses hardware mapped buffers to do all the 2D drawing, I think it can give lots of performance now, without not much extra coding, hardware can copy, scale apply transparencies way faster than we do now in our code.

http://www.ogre3d.org/docs/api/html/classOgre_1_1HardwarePixelBuffer.html (http://www.ogre3d.org/docs/api/html/classOgre_1_1HardwarePixelBuffer.html) , have a look at the blitFromMemory function for example.
Title: Re: Simutrans in 3D
Post by: Markohs on January 15, 2012, 07:02:03 PM
mmm... having problems with the internal RLE compression all images in simutrans have in memory, hardware can't process those streams and I need to pre-process them. I think I'll have to have them uncompressed in memory, dunno if memory usage will skyrocket, we'll see.

EDIT: Still not working hehehe :) :

(http://dl.dropbox.com/u/30024783/Untitled9.png)
Title: Re: Simutrans in 3D
Post by: prissi on January 16, 2012, 09:49:50 PM
I read once all images must be 2^(2*n) in dimensions or else (depending on architecture). Not true if this is the reason.

And I think you converted them to 32 bpp before right?
Title: Re: Simutrans in 3D
Post by: Ters on January 17, 2012, 05:57:11 AM
It's been a while since the power-of-two restriction started going away, though it is possible that low price hardware still has that requirement, or that such old hardware is still in use. There is still the confusion of images having two widths, but that goes for 2D too, as can/could be seen in Allegro and possibly also SDL (havn't check there).
Title: Re: Simutrans in 3D
Post by: Markohs on January 17, 2012, 08:36:57 AM
 Fixed already, it was an offsets problem. About the depth, I can choose a lot. of them, the renderer will be 16 or 32 bit depth, but layers have to be choosen from:

http://www.ogre3d.org/docs/api/html/group__Image.html#ga7e0353e7d36d4c2e8468641b7303d39c (http://www.ogre3d.org/docs/api/html/group__Image.html#ga7e0353e7d36d4c2e8468641b7303d39c)

So I think I'll just make PF_R8G8B8A8  Layers and render them. My idea was:

1 layer for the GUI, and for the map all that are necessary, and let the hardware apply the transparencies and generate the image.

Since images are written in rhombus and not squares, might be necessary to use 2 layers for graphics, one for odd positions and another for even, making tests still to see if all this takes any performance gain or not.
Title: Re: Simutrans in 3D
Post by: Markohs on January 17, 2012, 04:41:24 PM
Have been thinking about this as usual in the trip in the metro to work and I might have had a good idea.

Let's see, assume I finish this Ogre 2D renderer, let's say I just create a multilayered plane, with RGBA layers, of the screen resolution size, and the blending results in the actual game, hardware accelerated.

Let's for example say layers are (from back to front)

- ground
- ways
- movable objects and vehicles
- buildings
- GUI

And the image is the blend of the layers. Maybe next step can be replacing the layers one by one with 3D renders? Like for example, have the ground rendered from a 3D model, and rest use the current pixel art, or mix 2D and 3D renders of the vehicles in the corresponding layer.

Don't know if I made myself clear, whet do you think? This whould of course fix the camera to the 4 isometric views, at least on this first release, we can simulate another agnles deforming the bitmaps.

EDIT: I'm thinking now layers are not really grouped by type allways, just a discrete order of z-values, that will compose the image, for example ground whould allways be 0, but a station and his "cover" will be at different z-coord layers, but maybe this is possible, have to think more about it.
Title: Re: Simutrans in 3D
Post by: prissi on January 17, 2012, 08:19:40 PM
Actually the rendering of vehicles and ground is currently quite complex with three runs with partial clipping. Dwachs made this algorithm. Ask him, it is quite clever albeit complex. Not sure of billboard rendering can achieve this.
Title: Re: Simutrans in 3D
Post by: isidoro on January 18, 2012, 12:17:21 AM
@markohs: why instead of trying to reproduce exactly those four views don't you take the volumes of the objects and paint them approximately and replace them once the 3d models are available in a special pak designed for 3d?

I'll explain further.  For a car, take a box and paint each of the faces based on the images of the pak.  The dimensions of the box are those of the car approximately.  Once you have a real 3d model you take out the box and put the 3d model instead.  The same for a bridge, etc.

Or, have a default car, ship, plane, etc. that will be shown if the 3d model is not available with the real image in properties or even on a frame above the default model...

Title: Re: Simutrans in 3D
Post by: Markohs on January 18, 2012, 12:56:35 AM
Yea Isidoro, that's allways an option, but it will look very bad, dunno if it's the best option, and it can take a lot of time to make the 3D models. It whould make all current art useless, but maybe it's the best option, you are not the only one pointing to that, iirc james said something in that line more than one time. :)
Title: Re: Simutrans in 3D
Post by: sdog on January 18, 2012, 01:06:20 AM
the 2d will live on, so the 2d images won't be useless. Perhaps in future the 2d would be the interesting option for portable devices, while 3d for larger machines. 2d images for different views also are very helpful in creating 3d models, as one doesn't have to think much about proportion anymore.

isidoro has a good point, since as soon as there is a 3d game requiring models, and it is clear what the specifications are, people will start working to provide those models. The pak authors who did only 2d are still very valuable then, as textures are always high in demand. If simulating the isometric view with sprites is too difficult, it's perhaps wise to skip it. (i can't judge that at all, i just said this to reduce a restriction)
Title: Re: Simutrans in 3D
Post by: Markohs on January 18, 2012, 08:55:55 AM
@prissi: I'll read more the code (it's indeed quite complex) before contacting dwachs, don't wanna make him lose much time. Thank you. :)
Title: Re: Simutrans in 3D
Post by: Markohs on January 22, 2012, 01:34:09 AM
 clap clap clap @prissi, really, I'd have saved lots of time testing what you did say days ago.

Indeed looks like some cards don't like non-power-of-two pixelbuffers, I have a nVidia GeForce 9800 GTX here and spent some days debugging this, the bizarre thing is the same code worked perfectly on a cheap brand ATI Card.

One of the greatest problem was ogre framework reported the incorrect sizes and silently the video drivers resized the buffer, so I was like a headless chicken finding for the bug. This can be corrected rendering over the closest power of two width and scaling back via hardware before sending to screen. Okay, next step now. ;)

ATM I have a build that only uses OGRE3D and OIS as dependences, having removed SDL, losed quite a lot of time here.


http://www.ogre3d.org/forums/viewtopic.php?p=192709 (http://www.ogre3d.org/forums/viewtopic.php?p=192709)

(http://dl.dropbox.com/u/30024783/Untitled10.png)

Title: Re: Simutrans in 3D
Post by: isidoro on January 22, 2012, 02:24:32 AM
 :award: That's a big step  :award:
Title: Re: Simutrans in 3D
Post by: missingpiece on January 22, 2012, 01:14:55 PM
So, if I understand correctly, the 2D version of simutrans will be able run off the same graphics backbone as the 3D version may eventually do ?
Title: Re: Simutrans in 3D
Post by: Fabio on January 22, 2012, 02:06:31 PM
I think it would be nice to have a first step in which 3D Simutrans faithfully replies 2D Simutrans (and this step seems close now). 3D engine could be used to achieve nice stuff like continuous zooming, perspective shift (i.e. Lowering or raising the point of view resizing the e.g. 64x64 tiles to 64x48 or 64x96) and so on. This could even prove to be faster or more efficient than current graphic engine without changing the paksets at all and could go to trunk as a replacement or an alternative to sdl or other backend.

Then we could think if to make a 3D models pakset (tilesize shouldn't matter there anymore).
Title: Re: Simutrans in 3D
Post by: Markohs on January 22, 2012, 03:03:16 PM
yea, it's exactly as fabio points. first render current simutrans, then add new features, including 3d models for vehicles, ways, buildings... we'll see after that.
Title: Re: Simutrans in 3D
Post by: Spike on January 22, 2012, 10:19:01 PM
Very good, seems you are on a good track there!
Title: Re: Simutrans in 3D
Post by: jamespetts on January 22, 2012, 10:23:24 PM
Quote from: Hajo on January 22, 2012, 10:19:01 PM
Very good, seems you are on a good track there!

Pun intended? ;-)
Title: Re: Simutrans in 3D
Post by: Spike on January 22, 2012, 10:25:30 PM
Totally  ;)
Title: Re: Simutrans in 3D
Post by: Markohs on January 22, 2012, 10:48:01 PM
 I think I don't really understand the pun. ;)

Working on this, I start to see the light at the end of the tunnel.

btw, I have more advances, the mouse control is working now, I miss the keyboard. Have to adapt to current simutrans event handling, creating a fifo of events from OIS/windowmanager to serve to the simmain poll.

From what I'm seeing so far, code looks like 25% slower than current SDL version, but didn't made a single optimization yet, we'll see what can I manage to get. I also think I render the frame twice each loop. Until the simintr.cc code starts to work (that's where I hooked the renderframe() code), dunno really know how I'll control when to refresh the screen. Aiming to a point where the screen render is queued and the control is given back to simutrans, so scene blending and the rest of the code can run in a paralel fashion.

Solved the display corruption too, looks like nVidia cards at least allocate power of 2 widths allways, you just have to ignore the exess pixels on each line when drawing, the render will only take the useful bytes.

Once you get the "rowpitch", that's according the manual: "Number of elements between the leftmost pixel of one row and the left pixel of the next."  code changed to something similar to:


   if (h > 0) {
      PIXVAL *tp = textur + yp * disp_width;
      do{
       ...
       tp += disp_width;
    } while (--h);
}


with:


   if (h > 0) {
      PIXVAL *tp = textur + yp * rowpitch;
      do{
      ...
          tp += rowpitch;
      } while (--h);
   }
Title: Re: Simutrans in 3D
Post by: Ters on January 23, 2012, 05:46:43 AM
I mentioned this concept of two different widths (visible width and number of pixels until next row) a week ago, but maybe I was a bit vague. What's strange is that I find nothing about it in Ogre's API documentation. Doesn't Ogre support that concept, except when locking only a part of a texture?

Are you using the DirectX or OpenGL backend for Ogre? I couldn't find more than one width in OpenGL either, but OpenGL used to abstract things a bit more. I didn't check the newer texture API.
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 09:06:30 AM
I use the Direct3D plugin backend, but only refer to generic ogre directives. Should work on linux and other systems with OpenGL too, since I don't use any Direct3D directives.

The classes and the withs you menction can be found in:

Note the "virtual const PixelBox &    lock (const Image::Box &lockBox, LockOptions options)"
http://www.ogre3d.org/docs/api/html/classOgre_1_1HardwarePixelBuffer.html

And here the "rowPitch"

http://www.ogre3d.org/docs/api/html/classOgre_1_1PixelBox.html

Looks like every driver has hiw own way of sizing buffers, some will give you exact size buffers, with "rowPitch"=="width" and some will give you bigger buffers.

ATM I just lock the entire buffer, code is:

void dr_prepare_flush()
{
   pixels->lock(Ogre::HardwareBuffer::HBL_NORMAL );
   const Ogre::PixelBox& pixelBox = pixels->getCurrentLock();
   Ogre::uint8* pDest = static_cast<Ogre::uint8*>(pixelBox.data);
   size_t pitch = pixelBox.rowPitch;
   set_textur(pDest,pitch);
}

void dr_flush(void)
{
   display_flush_buffer();
   pixels->unlock();
   if (renderWindow->isActive()){
      root->renderOneFrame();
   }
   else
      if (renderWindow->isVisible()){
         root->renderOneFrame();
         renderWindow->update();
      }
}
Title: Re: Simutrans in 3D
Post by: Ters on January 23, 2012, 04:08:45 PM
I saw that lock method that locks the entire texture didn't return a PixelBox, unlike the other lock method, but missed the getCurrentLock(). When you start programming against low level stuff, you'll find all kinds of strange things that's made the way it is because of some not immediately intuitive cost saving and/or performance reason.
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 06:32:46 PM
I uploaded a compiled Win32 version here (http://dl.dropbox.com/u/30024783/simutrans.zip), I'd be happy to hear it works or not in other videocards and the buffer looks ok.

it includes a pak128, didn't tested on other paks but it should work too.

Known problems are:

- Keyboard doesn't work correctly.
- tiles that have the mouse on top will be shown black, happens to selected buttons too
- On zones with lots of trees, mouse will slowdown and framerate will drop to aprox 50% of the normal SDL version.
- on splash screen, mouse won't work.

What should be working good:

- Mouse control should be functional past the spash screen.
- frame rate should be similar to SDL version, but slower.
- Screen should be rendered with correct offsets, look at the last screenshots I posted here to see what do I mean.

Thank you!
Title: Re: Simutrans in 3D
Post by: jamespetts on January 23, 2012, 10:31:47 PM
Trying to run this test, I get the message,

"The program can't start because d3dx9_42.dll is missing from your computer. Try reinstalling the program to fix this problem".
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 10:58:52 PM
I think you miss directX9 on your computer, don't have it? :)

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=35 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=35)

Edit: It's either that or put this file on the simutrans folder:

http://dl.dropbox.com/u/30024783/RenderSystem_GL.dll

And on the plugins.cfg file. uncoment the line refering to that renderer. But you need your computer to have OpenGL support libraries installed. (I think most installations have it ionstalled by default)
Title: Re: Simutrans in 3D
Post by: HDomos on January 23, 2012, 11:19:12 PM
It asked for msvcp100.dll and msvcr100.dll, but when i put them into the simutrans folder, it worked perfectly (except the known issues)
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 11:21:06 PM
Wich graphic card do you have hdomos?

****, didn't know Visual C++ 2100 generates binaries with runtime library dependencies. Is there any way to avoid the msvcr100.dll dependency?

Well, I guess they can be downloaded from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5555 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5555) , but didn't really tested it
Title: Re: Simutrans in 3D
Post by: HDomos on January 23, 2012, 11:36:46 PM
I have NVIDIA GeForce 9600 GT
Title: Re: Simutrans in 3D
Post by: jamespetts on January 23, 2012, 11:42:15 PM
Ahh, thank you; that worked. However, it crashed when I tried to maximise it...

Edit: This was from the ALT+SPACE menu; when ALT+TABbing to release the mouse and maximising with the mouse, it works. Seems smooth. I assume that the trapped mouse is a known issue.
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 11:46:17 PM
thank you both for your tests! Wich is your video card, jamespetts?
Title: Re: Simutrans in 3D
Post by: jamespetts on January 23, 2012, 11:47:47 PM
Radeon HD 5800 series.
Title: Re: Simutrans in 3D
Post by: HDomos on January 23, 2012, 11:54:20 PM
I tested it with a nightly of pak128 1.4.6 with MLM addon and an 1024*1024 map, and it worked fine. Though it was a bit slow...
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 11:57:38 PM
Yea, just fixed the trapped mouse thing in the code, will remove the current mousecursor, it was just a test. Didn't tried to maximize with ALT+SPACE (didn't knew about that shortcut hehe). Works well on nVidia, I'll try to figure where does that crash come from. Thank you.
Title: Re: Simutrans in 3D
Post by: Markohs on January 23, 2012, 11:59:07 PM
Just noticed I rendered the scene like 10 times each frame. :) There are lots of places to tweak too, I'm just focusing it to render correctly, performance will come after that. Thank you both!
Title: Re: Simutrans in 3D
Post by: jamespetts on January 24, 2012, 12:10:12 AM
It's looking good so far! This is a fairly exciting development. I'm looking forward to seeing some of my/Kieron's/James's Blends in Simutrans directly! They have more detail than the .pngs made from them.
Title: Re: Simutrans in 3D
Post by: Markohs on January 24, 2012, 12:17:45 AM
I was thinking that on the metro trip to work, that's not so far. One of the first things we'll have to solve is how vehicles turn in curves, how to rotate and animate them so it looks realistic. When I'm able to render current simutrans and make it run at least as fast as it runs today, it won't be hard to add another layer with 3D renders. In fact the zones that currently appear black are transparent zones, "holes" that show the scene that's behind, that's actually a camera focusing and empty space.

I also wanna see some models moving soon, I have one model Zeno sent me that's gonna look great! ;)

(http://dl.dropbox.com/u/30024783/Untitled11.png)
Title: Re: Simutrans in 3D
Post by: jamespetts on January 24, 2012, 12:31:45 AM
I was wondering about animation, actually - that might involve quite a lot of extra work for vehicles, might it not?
Title: Re: Simutrans in 3D
Post by: Markohs on January 24, 2012, 12:33:48 AM
Well, didn't look so much at that part of the code yet, but vehicles aren't affected by that sync_step function? Maybe we can apply a rotation/translation there, a function of how far in the "tile" are. We can also use animated textures, the framework supports this easily.

Other thing to have in mind is that this current approach forces us to use non perspective cameras, but isometric projection ones (CAD style), so items won't get deformed by distance, only from the POV, should be np, it will all look good I think.

But yea, there are lots of parts that need to be decided, for example, how to map player colours to textures, if models can have animated parts(wheels), if models will vibrate, how do we simulate the smoke/pollution, how much vertexes can a model have, if we can add lights to models (headlamp or passenger cars inner light), etc...

The framework supports also skeletal aanimations, and lots of stuff, but I don't really think we'll use them:

http://www.youtube.com/watch?v=dGaaxiSwH_Y
Title: Re: Simutrans in 3D
Post by: jamespetts on January 24, 2012, 01:19:01 AM
Yes - if vehicles need animated wheels (etc.) that'll add a lot of work for pakset creators; but, without, it might look rather silly. As to the orthographic view - I am familiar with this from Blender, and it really looks odd. Can we not get a perspective view?
Title: Re: Simutrans in 3D
Post by: Ters on January 24, 2012, 05:47:40 AM
Quote from: Markohs on January 23, 2012, 11:21:06 PM
****, didn't know Visual C++ 2100 generates binaries with runtime library dependencies. Is there any way to avoid the msvcr100.dll dependency?

I think there is an option for static linking, but that would prevent Microsoft for patching the runtime through Windows Update (I received a patch for the 2005 runtime just now). The option might also have been removed for exactly that reason.

As for d3dx9_42.dll, it's not (just) DirectX 9 that is missing (that is unlikely), but DirectX 9 update 42. I think newer updates include such files from older ones, but the opposite is obviously not possible.
Title: Re: Simutrans in 3D
Post by: Markohs on January 24, 2012, 09:52:14 AM
Using a perspective camera whould require deforming the current render, requires a lot more of work, let's start on orthografic I think, maybe it doesn't look so bad, after all we've been using it for lots of time in simutrans.

(http://db-in.com/blog/wp-content/uploads/2011/03/projection_example.gif)
Title: Re: Simutrans in 3D
Post by: jamespetts on January 24, 2012, 10:11:23 AM
Hmm - why does deforming the current render require more work? At least, why does it require more work for you? Is not the extra work required for that already in the Ogre 3D engine...? The cube on the left appears to be a very odd shape indeed, with the back part larger than the front (as one expects perspective and therefore for the back to be smaller than the front of it is an evenly sized cube).

(Incidentally - Zeno's tram is most impressive! Did I tell you where all the Pak128.Britain models are located? They're all open source and in a big repository...)
Title: Re: Simutrans in 3D
Post by: Markohs on January 24, 2012, 10:20:59 AM
No, the render doesn't require more work, ogre does this automatically. I was refering to deform the current 2D map cells in the 2D pixelart, so they align to a projection camera render cells, but maybe I can find an acceptable solution.

Yea maybe you told me where they were but it can't find it now, tell me the link so I can make some experiments. :)
Title: Re: Simutrans in 3D
Post by: prissi on January 24, 2012, 10:23:38 AM
Perhaps you could first starting to tilt vehicles on slopes. That would give you an estimate of the problems (tilting must start half a tile different to actually entering the slope and so on.) Not completely unsolvable (there was even a path a long long time agon on this, which did not take it into account and thus did not look so great.)

To aviece that, you may need another vehcile variable, like
"starting_tilt_step" (From this tile on to the end of step_next the tilt will increase)
"full_tilt_step_from/until" (Full tilt maintained until this step)
"ending_tilt_step" (stopping tilting)
Those are most likely set by "hop()"

Calc_height might be a good candidate to do the tilting. (Unfourtunately this routine is already one of the most called ones ... :( )
Title: Re: Simutrans in 3D
Post by: jamespetts on January 24, 2012, 10:49:36 AM
Quote from: Markohs on January 24, 2012, 10:20:59 AM
No, the render doesn't require more work, ogre does this automatically. I was refering to deform the current 2D map cells in the 2D pixelart, so they align to a projection camera render cells, but maybe I can find an acceptable solution.

Yea maybe you told me where they were but it can't find it now, tell me the link so I can make some experiments. :)

Ahh - perhaps it could be set up so that it uses perspective mode for proper models? It'd be worth finding a workaround for this issue, as orthographic mode is distractingly peculiar.

As for Blender repositories, see here (http://forum.simutrans.com/index.php?topic=7928.0). Some of my latest things have not been uploaded there yet, but you have enough to be getting on with, I think.
Title: Re: Simutrans in 3D
Post by: missingpiece on January 24, 2012, 12:53:52 PM
Quote from: Markohs on January 24, 2012, 12:33:48 AM...if we can add lights to models (headlamp or passenger cars inner light), etc...
Oh, gee !!! Lights inside the train which light up the ground and near trees where the vehicle is passing by ?!  :o

Quote from: Markohs on January 24, 2012, 10:20:59 AMI was refering to deform the current 2D map cells in the 2D pixelart, so they align to a projection camera render cells, but maybe I can find an acceptable solution.
I would have to see it in a mockup to know if that is a problem. But frankly, the billboard approach to bringing 2D pixel art into a 3D scene will create much worse artifacts than cell border and building ground texture not exactly mapping...

Also, with James virtually jumping up and down in anticipation, my guess is the drag to create 3D-mature paksets will be sufficient.
Title: Re: Simutrans in 3D
Post by: prissi on January 24, 2012, 01:09:46 PM
I think the amount of work needed to have acceptable models for a 3D pak set is completely underestimated. You cannot simply use blender model, or you would end up with ridiculus polygon counts fast. Thus you need to create a sufficiently detailed texture on a simple modell. I am not sure, if there is any good way to automize this.
Title: Re: Simutrans in 3D
Post by: Markohs on January 24, 2012, 02:03:13 PM
Well, step by step, right now I have other things in my TODO:

- OIS::Keyboard mapping to Simutrans events (not so easy because of multilanguage)
-  replace dr_flush code with blit() code in texture layers (requires uncompressed images in imd* images, simgraph.cc)
- Find one way to hook a periodic renderframe() on the code, since simintr.cc -> intr_refresh_display is only called when world is created, not on initial dialogs (language, pakset selection,banner and load ticker). Right now I'm just rendering on dr_flush, dr_textur is not an alternative vecause it's called more than once each frame.
- Minor mouse movement fixes.
- display_img_blend is not working ok, related to "Map player/daynight colors to the correct A1R5G5B5 value, or even use 32-bit color precision A8R8G8B8 for gradual transparencies".
Title: Re: Simutrans in 3D
Post by: prissi on January 24, 2012, 02:58:06 PM
THe drawing during start is handled by modal_dialogue() change it and intr_refresh_display should be enough.
Title: Re: Simutrans in 3D
Post by: sdog on January 24, 2012, 05:02:11 PM
Quote from: prissi on January 24, 2012, 01:09:46 PM
I think the amount of work needed to have acceptable models for a 3D pak set is completely underestimated. You cannot simply use blender model, or you would end up with ridiculus polygon counts fast. Thus you need to create a sufficiently detailed texture on a simple modell. I am not sure, if there is any good way to automize this.
The way to go is typically to build avery detailed model first. From this a set of low poly models for each LOD (if aplicable) is generated as are shadow maps etc. Typically most work is mapping the surface of the model to a flat mapping (uv wrapping), this often is not trivial.

ps.:  i often have the feeling of samming this thread, however the matter of 3d objects is something one should be aware of, should we have a new thread for this?
Title: Re: Simutrans in 3D
Post by: Ters on January 24, 2012, 05:05:20 PM
Perspective mode also makes interacting with the world harder. Not just to program, but for players too. When drawing a road into the distance, a small uninterntional movement could make the road much longer than originally intended. Not so much a problem when the camera angle is fixed like now, but I suspect few want to move to 3D and keep it that way.

A perspective mode for just viewing the world would still be great, sometime far into the future, when all graphics have been adapter to 3D. I liked the way you could attach the camera to a train in Railroad Tycoon 3 and see everthing from the trains perspective.
Title: Re: Simutrans in 3D
Post by: Markohs on January 24, 2012, 05:58:40 PM

@prissi, ok, thank you, I'll hook the render() there.
@sdog, we still don't know the details of how should the models/textures be, we have to refine that seeing the memory/performance we achieve.

Seeing there is enthusiasm to see some fast results I decided to postpone my TODO list a bit more and I'm already adding the code to see some 3D objects on top of the map now.

This way we can see some results. it won't have clipping yet, so the renders can be on top of other items they shoudn't.

Now we have 3 layers (from back to front):

- 3D background (nothing here yet)
- current 2D simutrans
- 3D objects.

All this layers are alpha blended. Will post some screenshots when I have it working.
Title: Re: Simutrans in 3D
Post by: Markohs on January 25, 2012, 03:10:37 PM
You can download a new build here (http://dl.dropbox.com/u/30024783/simutrans.zip), this time it doesn't ship any pak, to make the zip smaller.

you can see a rotating ogre head on the center to check the effect of the extra 3D layer. It's a orthogonal camera, see how it doesn't look so bad, james. The same object rendered with a perspective camera looks like this:

(http://cubansephiroth.files.wordpress.com/2010/06/screenshot06212010_113806814.jpg)


Right now I'm trying make the camera move with the 2D viewport, I remember seeing a graph or some page with the camera angles you use on your blender renders, but can't find it, anyone knows were can I find that information?

If anyone wants to play around the mesh is taken from media/models/ogrehead.mesh, and media/materials/scripts is scanned for material descriptions, you can use OgreBlenderExporter  (http://www.ogre3d.org/tikiwiki/Tools%3A+Blender)fo put your blender creatins there, but you will need to make a SINGLE mesh of your model first (all your creations I saw so far were composition of meshes, I made one export from one station that looked cool, but don't have it here now at this computer).

Remember you might need to update directx or OpenGL http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=35 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=35) and install C++ redistributables  http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5555 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5555)

I'd be happy to hear your experiences trying it. I'm aware of:

- Background is blue now(http://www.ogre3d.org/tikiwiki/Tools%3A+Blender%20to%20create%20a%20mesh%20from%20any%20of%20your%20creations%20to%20test.%20Have%20in%20mind%20that%20your%20blender%20files%20will%20not%20have%20your%20model%20in%20a%20single%20mesh,%20you%27ll%20need%20to%20make%20one%20mesh%20with%20all%20the%20subcomponents%20and%20export%20it%20using%20the%20exporter,%20it%20also%20creates%20the%20material%20script.%20I%27d%20like%20to%20read%20some%20people%20testing%20this%20and%20telling%20me%20if%20they%20had%20problems%20or%20not,%20and%20wich%20was%20their%20videocard.%20Remember%20you%20might%20need%20to%20update%20to%20last%20DirectX,%20or%20use%20OpenGL%20renderer.%20And%20you%20might%20need%20to%20update%20the%20C++%20redistributable%20libs.), I'm aware transparencies won't work (as mouseover, station coverage etc)
- It's slower than the SDL version
- Keyboard doesn't work correctly
- Window resize should work now
- There is a double mouse cursor

Should look similar (and with acceptable framerate at that zoom level) to:

(http://dl.dropbox.com/u/30024783/Untitled12.png)
Title: Re: Simutrans in 3D
Post by: jamespetts on January 25, 2012, 09:07:39 PM
Hmm, not working for me - does nothing on attempted startup.
Title: Re: Simutrans in 3D
Post by: Markohs on January 26, 2012, 09:53:48 AM
what was the window like, full black? did the music started to play?
Title: Re: Simutrans in 3D
Post by: jamespetts on January 26, 2012, 12:02:11 PM
There was no window.
Title: Re: Simutrans in 3D
Post by: Markohs on January 26, 2012, 12:28:50 PM
 Can you try to start it with -debug 1 -log 1 and check the simu.log file? and the "ogre.log" that's created on the same folder than the executable, please. Maybe there is some error that shows up there, I tried it again here and it works perfectly.

Also, can you edit the "plugin.cfg", uncomment the "Plugin=RenderSystem_GL" line and delete the file "ogre.cfg"?

Thank you for your help. ;)
Title: Re: Simutrans in 3D
Post by: prissi on January 26, 2012, 04:02:12 PM
If I delete Ogre.cfg, and select D3D I see a window with a pointer and then the music plays, so it is obviously starting up, while the screen stays violett. With GL as rederer, not even a GDI windows opens.

With opengl

16:57:52: Creating resource group General
16:57:52: Creating resource group Internal
16:57:52: Creating resource group Autodetect
16:57:52: SceneManagerFactory for type 'DefaultSceneManager' registered.
16:57:52: Registering ResourceManager for type Material
16:57:52: Registering ResourceManager for type Mesh
16:57:52: Registering ResourceManager for type Skeleton
16:57:52: MovableObjectFactory for type 'ParticleSystem' registered.
16:57:52: OverlayElementFactory for type Panel registered.
16:57:52: OverlayElementFactory for type BorderPanel registered.
16:57:52: OverlayElementFactory for type TextArea registered.
16:57:52: Registering ResourceManager for type Font
16:57:52: ArchiveFactory for archive type FileSystem registered.
16:57:52: ArchiveFactory for archive type Zip registered.
16:57:52: DDS codec registering
16:57:52: FreeImage version: 3.15.1
16:57:52: This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
16:57:52: Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2,pfm,pct,pict,pic,3fr,arw,bay,bmq,cap,cine,cr2,crw,cs1,dc2,dcr,drf,dsc,dng,erf,fff,ia,iiq,k25,kc2,kdc,mdc,mef,mos,mrw,nef,nrw,orf,pef,ptx,pxn,qtk,raf,raw,rdc,rw2,rwl,rwz,sr2,srf,sti
16:57:52: Registering ResourceManager for type HighLevelGpuProgram
16:57:52: Registering ResourceManager for type Compositor
16:57:52: MovableObjectFactory for type 'Entity' registered.
16:57:52: MovableObjectFactory for type 'Light' registered.
16:57:52: MovableObjectFactory for type 'BillboardSet' registered.
16:57:52: MovableObjectFactory for type 'ManualObject' registered.
16:57:52: MovableObjectFactory for type 'BillboardChain' registered.
16:57:52: MovableObjectFactory for type 'RibbonTrail' registered.
16:57:52: Loading library .\RenderSystem_Direct3D9
16:57:52: Installing plugin: D3D9 RenderSystem
16:57:52: D3D9 : Direct3D9 Rendering Subsystem created.
16:57:52: D3D9: Driver Detection Starts
16:57:52: D3D9: Driver Detection Ends
16:57:52: Plugin successfully installed
16:57:52: Loading library .\RenderSystem_GL
16:57:52: Installing plugin: GL RenderSystem
16:57:52: OpenGL Rendering Subsystem created.
16:57:52: Plugin successfully installed
16:57:52: *-*-* OGRE Initialising
16:57:52: *-*-* Version 1.7.4 (Cthugha)
16:57:52: Added resource location 'media/materials/scripts' of type 'FileSystem' to resource group 'General'
16:57:52: Added resource location 'media/materials/textures' of type 'FileSystem' to resource group 'General'
16:57:52: Added resource location 'media/materials/textures/nvidia' of type 'FileSystem' to resource group 'General'
16:57:52: Added resource location 'media/models' of type 'FileSystem' to resource group 'General'
16:57:52: OGRE EXCEPTION(6:FileNotFoundException): 'ogre.cfg' file not found! in ConfigFile::load at ..\..\..\..\OgreMain\src\OgreConfigFile.cpp (line 83)
16:57:52: OGRE EXCEPTION(6:FileNotFoundException): 'ogre.cfg' file not found! in ConfigFile::load at ..\..\..\..\OgreMain\src\OgreConfigFile.cpp (line 83)
16:57:52: OGRE EXCEPTION(6:FileNotFoundException): 'ogre.cfg' file not found! in ConfigFile::load at ..\..\..\..\OgreMain\src\OgreConfigFile.cpp (line 83)
16:58:04: CPU Identifier & Features
16:58:04: -------------------------
16:58:04:  *   CPU ID: AuthenticAMD: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
16:58:04:  *      SSE: yes
16:58:04:  *     SSE2: yes
16:58:04:  *     SSE3: yes
16:58:04:  *      MMX: yes
16:58:04:  *   MMXEXT: yes
16:58:04:  *    3DNOW: yes
16:58:04:  * 3DNOWEXT: yes
16:58:04:  *     CMOV: yes
16:58:04:  *      TSC: yes
16:58:04:  *      FPU: yes
16:58:04:  *      PRO: yes
16:58:04:  *       HT: no
16:58:04: -------------------------
16:58:04: *** Starting Win32GL Subsystem ***
16:58:04: Parsing scripts for resource group Autodetect
16:58:04: Finished parsing scripts for resource group Autodetect
16:58:04: Parsing scripts for resource group General
16:58:04: Parsing script AxisMaterial.material
16:58:04: Parsing script Examples.material


DX

17:00:31: Creating resource group General
17:00:31: Creating resource group Internal
17:00:31: Creating resource group Autodetect
17:00:31: SceneManagerFactory for type 'DefaultSceneManager' registered.
17:00:31: Registering ResourceManager for type Material
17:00:31: Registering ResourceManager for type Mesh
17:00:31: Registering ResourceManager for type Skeleton
17:00:31: MovableObjectFactory for type 'ParticleSystem' registered.
17:00:31: OverlayElementFactory for type Panel registered.
17:00:31: OverlayElementFactory for type BorderPanel registered.
17:00:31: OverlayElementFactory for type TextArea registered.
17:00:31: Registering ResourceManager for type Font
17:00:31: ArchiveFactory for archive type FileSystem registered.
17:00:31: ArchiveFactory for archive type Zip registered.
17:00:31: DDS codec registering
17:00:31: FreeImage version: 3.15.1
17:00:31: This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
17:00:31: Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2,pfm,pct,pict,pic,3fr,arw,bay,bmq,cap,cine,cr2,crw,cs1,dc2,dcr,drf,dsc,dng,erf,fff,ia,iiq,k25,kc2,kdc,mdc,mef,mos,mrw,nef,nrw,orf,pef,ptx,pxn,qtk,raf,raw,rdc,rw2,rwl,rwz,sr2,srf,sti
17:00:31: Registering ResourceManager for type HighLevelGpuProgram
17:00:31: Registering ResourceManager for type Compositor
17:00:31: MovableObjectFactory for type 'Entity' registered.
17:00:31: MovableObjectFactory for type 'Light' registered.
17:00:31: MovableObjectFactory for type 'BillboardSet' registered.
17:00:31: MovableObjectFactory for type 'ManualObject' registered.
17:00:31: MovableObjectFactory for type 'BillboardChain' registered.
17:00:31: MovableObjectFactory for type 'RibbonTrail' registered.
17:00:31: Loading library .\RenderSystem_Direct3D9
17:00:31: Installing plugin: D3D9 RenderSystem
17:00:31: D3D9 : Direct3D9 Rendering Subsystem created.
17:00:31: D3D9: Driver Detection Starts
17:00:31: D3D9: Driver Detection Ends
17:00:32: Plugin successfully installed
17:00:32: Loading library .\RenderSystem_GL
17:00:32: Installing plugin: GL RenderSystem
17:00:32: OpenGL Rendering Subsystem created.
17:00:32: Plugin successfully installed
17:00:32: *-*-* OGRE Initialising
17:00:32: *-*-* Version 1.7.4 (Cthugha)
17:00:32: Added resource location 'media/materials/scripts' of type 'FileSystem' to resource group 'General'
17:00:32: Added resource location 'media/materials/textures' of type 'FileSystem' to resource group 'General'
17:00:32: Added resource location 'media/materials/textures/nvidia' of type 'FileSystem' to resource group 'General'
17:00:32: Added resource location 'media/models' of type 'FileSystem' to resource group 'General'
17:00:32: OGRE EXCEPTION(6:FileNotFoundException): 'ogre.cfg' file not found! in ConfigFile::load at ..\..\..\..\OgreMain\src\OgreConfigFile.cpp (line 83)
17:00:32: OGRE EXCEPTION(6:FileNotFoundException): 'ogre.cfg' file not found! in ConfigFile::load at ..\..\..\..\OgreMain\src\OgreConfigFile.cpp (line 83)
17:00:32: OGRE EXCEPTION(6:FileNotFoundException): 'ogre.cfg' file not found! in ConfigFile::load at ..\..\..\..\OgreMain\src\OgreConfigFile.cpp (line 83)
17:00:35: CPU Identifier & Features
17:00:35: -------------------------
17:00:35:  *   CPU ID: AuthenticAMD: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
17:00:35:  *      SSE: yes
17:00:35:  *     SSE2: yes
17:00:35:  *     SSE3: yes
17:00:35:  *      MMX: yes
17:00:35:  *   MMXEXT: yes
17:00:35:  *    3DNOW: yes
17:00:35:  * 3DNOWEXT: yes
17:00:35:  *     CMOV: yes
17:00:35:  *      TSC: yes
17:00:35:  *      FPU: yes
17:00:35:  *      PRO: yes
17:00:35:  *       HT: no
17:00:35: -------------------------
17:00:35: D3D9 : Subsystem Initialising
17:00:35: Registering ResourceManager for type Texture
17:00:35: Registering ResourceManager for type GpuProgram
17:00:35: ***************************************
17:00:35: *** D3D9 : Subsystem Initialised OK ***
17:00:35: ***************************************
17:00:35: Parsing scripts for resource group Autodetect
17:00:35: Finished parsing scripts for resource group Autodetect
17:00:35: Parsing scripts for resource group General
17:00:35: Parsing script AxisMaterial.material
17:00:35: Parsing script Examples.material
17:00:35: Compiler error: reference to a non existing object in Examples.material(253)
17:00:35: Compiler error: reference to a non existing object in Examples.material(772)
17:00:35: Compiler error: reference to a non existing object in Examples.material(784)
17:00:35: Compiler error: reference to a non existing object in Examples.material(1281)
17:00:35: Compiler error: reference to a non existing object in Examples.material(1473)
17:00:35: Compiler error: reference to a non existing object in Examples.material(1508)
17:00:35: Compiler error: reference to a non existing object in Examples.material(1617)
17:00:35: Compiler error: reference to a non existing object in Examples.material(1622)
17:00:35: Compiler error: reference to a non existing object in Examples.material(1716)
17:00:35: Parsing script GridMaterial.material
17:00:35: Parsing script Ogre.material
17:00:35: Finished parsing scripts for resource group General
17:00:35: Parsing scripts for resource group Internal
17:00:35: Finished parsing scripts for resource group Internal
17:00:35: D3D9 : Created D3D9 Rendering Window 'Simutrans Nightly 110.0.2' : 640x480, 32bpp
17:00:35: D3D9 : WARNING - disabling VSync in windowed mode can cause timing issues at lower frame rates, turn VSync on if you observe this problem.
17:00:35: RenderSystem capabilities
17:00:35: -------------------------
17:00:35: RenderSystem Name: Direct3D9 Rendering Subsystem
17:00:35: GPU Vendor: ati
17:00:35: Device Name: Monitor-1-ATI Radeon X1200 Series (Microsoft Corporation - WDDM)
17:00:35: Driver Version: 8.14.10.630
17:00:35:  * Fixed function pipeline: yes
17:00:35:  * Hardware generation of mipmaps: yes
17:00:35:  * Texture blending: yes
17:00:35:  * Anisotropic texture filtering: yes
17:00:35:  * Dot product texture operation: yes
17:00:35:  * Cube mapping: yes
17:00:35:  * Hardware stencil buffer: yes
17:00:35:    - Stencil depth: 8
17:00:35:    - Two sided stencil support: yes
17:00:35:    - Wrap stencil values: yes
17:00:35:  * Hardware vertex / index buffers: yes
17:00:35:  * Vertex programs: yes
17:00:35:  * Number of floating-point constants for vertex programs: 256
17:00:35:  * Number of integer constants for vertex programs: 16
17:00:35:  * Number of boolean constants for vertex programs: 16
17:00:35:  * Fragment programs: yes
17:00:35:  * Number of floating-point constants for fragment programs: 32
17:00:35:  * Number of integer constants for fragment programs: 16
17:00:35:  * Number of boolean constants for fragment programs: 16
17:00:35:  * Geometry programs: no
17:00:35:  * Number of floating-point constants for geometry programs: 0
17:00:35:  * Number of integer constants for geometry programs: 3
17:00:35:  * Number of boolean constants for geometry programs: 0
17:00:35:  * Supported Shader Profiles: hlsl ps_1_1 ps_1_2 ps_1_3 ps_1_4 ps_2_0 ps_2_b ps_2_x vs_1_1 vs_2_0
17:00:35:  * Texture Compression: yes
17:00:35:    - DXT: yes
17:00:35:    - VTC: no
17:00:35:    - PVRTC: no
17:00:35:  * Scissor Rectangle: yes
17:00:35:  * Hardware Occlusion Query: yes
17:00:35:  * User clip planes: yes
17:00:35:  * VET_UBYTE4 vertex element type: yes
17:00:35:  * Infinite far plane projection: yes
17:00:35:  * Hardware render-to-texture: yes
17:00:35:  * Floating point textures: yes
17:00:35:  * Non-power-of-two textures: yes (limited)
17:00:35:  * Volume textures: yes
17:00:35:  * Multiple Render Targets: 4
17:00:35:    - With different bit depths: no
17:00:35:  * Point Sprites: yes
17:00:35:  * Extended point parameters: yes
17:00:35:  * Max Point Size: 10
17:00:35:  * Vertex texture fetch: no
17:00:35:  * Number of world matrices: 0
17:00:35:  * Number of texture units: 8
17:00:35:  * Stencil buffer depth: 8
17:00:35:  * Number of vertex blend matrices: 0
17:00:35:  * Render to Vertex Buffer : no
17:00:35:  * DirectX per stage constants: no
17:00:35: DefaultWorkQueue('Root') initialising on thread 00321350.
17:00:35: Particle Renderer Type 'billboard' registered
17:00:35: DefaultWorkQueue('Root')::WorkerFunc - thread 00341168 starting.
17:00:35: DefaultWorkQueue('Root')::WorkerFunc - thread 00341138 starting.
17:00:35: Mesh: Loading ogrehead.mesh.
17:00:35: Texture: GreenSkin.jpg: Loading 1 faces(PF_R8G8B8,256x256x1) with  hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
17:00:35: Texture: spheremap.png: Loading 1 faces(PF_R8G8B8,256x256x1) with  hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
17:00:35: D3D9 : ***** Dimensions altered by the render system
17:00:35: D3D9 : ***** Source image dimensions : 96x96
17:00:35: D3D9 : ***** Texture dimensions : 128x128
17:00:35: Texture: tusk.jpg: Loading 1 faces(PF_R8G8B8,96x96x1) with 7 generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
17:00:35: D3D9 : ***** Dimensions altered by the render system
17:00:35: D3D9 : ***** Source image dimensions : 640x480
17:00:35: D3D9 : ***** Texture dimensions : 1024x512
17:00:35: D3D9 : ***** Dimensions altered by the render system
17:00:35: D3D9 : ***** Source image dimensions : 640x480
17:00:35: D3D9 : ***** Texture dimensions : 1024x512
17:00:35: *** Initializing OIS ***
17:00:35: Texture: entis.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
Title: Re: Simutrans in 3D
Post by: Markohs on January 26, 2012, 04:20:18 PM
thx, having it a look.
Title: Re: Simutrans in 3D
Post by: Ters on January 26, 2012, 04:50:13 PM
I get the same result as prissi, though I can see the Simutrans logo with an Ogre head in the violet. Both look OK. I also have an ATI card, but an ATI Mobility Radeon HD 5850.
Title: Re: Simutrans in 3D
Post by: VS on January 26, 2012, 05:15:04 PM
Are you using textures that are not 2^n -sized? That doesn't work everywhere...
Title: Re: Simutrans in 3D
Post by: Markohs on January 26, 2012, 05:16:31 PM
Just one question @prissi or someone that knows about this, I was trying to understand this macro in simgraph.h


#define display_set_image_proc( is_global ) \
{ \
    if(  is_global  ) { \
        display_normal = display_img_aux; \
        display_color = display_color_img; \
        display_blend = display_rezoomed_img_blend; \
        current_tile_raster_width = get_tile_raster_width(); \
    } \
    else { \
        display_normal = display_base_img; \
        display_color = display_base_img; \
        display_blend = display_base_img_blend; \
        current_tile_raster_width = get_base_tile_raster_width(); \
    } \
}


As I see it changes the drawing functions, it's used on 2 places of the code:

karte_ansicht_t::display in simview.cc, before drawing the "world" and in gui_world_view_t.cc :


void world_view_t::internal_draw(const koord offset, ding_t const* const ding)
{
    display_set_image_proc(false);
...


I inserted a breakpoint in that line and it only triggered when I opened the finances window, not the world map as the name suggested. Can't really understand this mechanism, why does only the finances window need different drawing routines?

Thank you!
Title: Re: Simutrans in 3D
Post by: Markohs on January 26, 2012, 05:35:46 PM
@VS, yes, using non power of 2 textures on the code, but I think that's not the issue because it worked on jamesonpetts computer on the first version (it was already a non power of 2 texture). I'm a bit clueless now why isn't working at prissi,james and Ters computer while it works in my 2 computers, and the logs don't show anything. prissi's log also shows it supports non power of 2 texures.

If that ends being the issue, I might need to use a high resolution texture and let the renderer scale it back each frame (this is suposed to be done by the HW)

if music starts to play and the whole screen is violet that means the 2 overlays are not being blended with the background, the reason might be many, from the blending code not being supported by that driver (it should show in the log or simulated in software by Ogre), to the textures not being assigned correctly (I think that's the issue, even through it's strange because prissi sees the pak selection screen).

The structure is:

- A normal camera focusing a empty(violet) scene
- On top of it, a overlay with a material applied, filling whole screen. The material is composed of (from back to front):
   * A A1R5G5B5 texture, sized to the same dimensions of screen. All simgraph routines write there. it's named "tex".
   * A A1R5G5B5 texure,  sized to the same dimensions of screen. It's a RTT (render-to-target) texture, a scene it's rendered to it each frame, it's background is transparent. It's named "rtt_texture".

The material is blended with the scene, and the blending between layers is:

The alpha of the resulting blending is the sum(Ogre::LBX_ADD):

transparent=0, non_transparent=1 => transparent+transparent = 0; transparent+non_transparent = 1; non_transparent+transparent = 1; non_transparent+non_transparent=1

The color values are just interpolated (Ogre::LBX_BLEND_TEXTURE_ALPHA,Ogre::LBO_ALPHA_BLEND)


      matPass->setSceneBlending(Ogre::SBT_TRANSPARENT_ALPHA );

      pTexState1 = matPass->createTextureUnitState( tex->getName() );
      pTexState2 = matPass->createTextureUnitState( rtt_texture->getName() );

      pTexState1->setTextureAddressingMode(Ogre::TextureUnitState::TAM_CLAMP);
      pTexState1->setColourOperation(Ogre::LBO_ALPHA_BLEND);

      pTexState2->setTextureAddressingMode(Ogre::TextureUnitState::TAM_CLAMP);
      pTexState2->setColourOperationEx(Ogre::LBX_BLEND_TEXTURE_ALPHA ,Ogre::LBS_TEXTURE,Ogre::LBS_CURRENT);
      pTexState2->setAlphaOperation(Ogre::LBX_ADD,Ogre::LBS_TEXTURE,Ogre::LBS_CURRENT,1.0);
Title: Re: Simutrans in 3D
Post by: VS on January 26, 2012, 08:47:29 PM
My information might not be up to date, but support for non-2^n (aka NPOT) textures depends on actual hardware and maybe driver as well. I wouldn't rule this out...
Title: Re: Simutrans in 3D
Post by: Ters on January 27, 2012, 05:54:11 AM
I would be really disappointed if my graphics "card" and driver was so low end that it didn't support NPOT textures. I'm pretty sure support for that started appearing a decade ago (or maybe more, time flies) in consumer hardware, and my computer is less than a year old. I'll see if I can look into it a bit myself this weekend.
Title: Re: Simutrans in 3D
Post by: Dwachs on January 27, 2012, 11:55:51 AM
Quote from: Markohs on January 26, 2012, 05:16:31 PM
Just one question @prissi or someone that knows about this, I was trying to understand this macro in simgraph.h

#define display_set_image_proc( is_global ) \
{...
  } \
}

iirc, this method changes the way images are drawn: to show unzoomed (base) images or zoomed images.
This is set when the gui needs to show images of in-game objects. This way, the unzoomed images are shown in the gui, while the world view may be zoomed out/in. Before this change, the images of vehicles in depot window etc were zoomed as soon as the world view zoomed.

Finance window calls it to show image of headquarter location unzoomed. Any information window for houses, factories etc should also have call to this macro.
Title: Re: Simutrans in 3D
Post by: Markohs on January 27, 2012, 12:05:49 PM
Thank you, I noticed it gets called on clicking on a vehicle too, the mini-screen that follows the vehicle.
Title: Re: Simutrans in 3D
Post by: isidoro on January 27, 2012, 12:29:56 PM
Maybe a small OT, but I seem to have noticed, while playing, that that small window is drawn differently from world view.  Some graphic overlapping, specially at covered bridges happens there and not in the world.  Is that true?

Title: Re: Simutrans in 3D
Post by: Markohs on January 27, 2012, 12:41:46 PM
yeah, I think I noticed it too while playing. I think it's directly related to this 2 modes of drawing, but don't really know yet.
Title: Re: Simutrans in 3D
Post by: Dwachs on January 27, 2012, 01:05:50 PM
Quote from: isidoro on January 27, 2012, 12:29:56 PM
Maybe a small OT, but I seem to have noticed, while playing, that that small window is drawn differently from world view.  Some graphic overlapping, specially at covered bridges happens there and not in the world.  Is that true?
Yes thats true. It would require to adapt the not-so-new drawing method also in info windows. There the 'old' method is still used. This gives the ability to compare with the good old days....
Title: Re: Simutrans in 3D
Post by: Markohs on January 27, 2012, 05:53:06 PM
Just a screenshot of the program now, I replaced the ogre model with an export of Almuthof Station.blend I found somewere time ago. It's not aligned with the grid, yet, working on it. :)

This will be a productive weekend I hope. :)

I got the station, on one mesh, ready to be exported in:

http://dl.dropbox.com/u/30024783/Almuthof%20Station.blend

(http://dl.dropbox.com/u/30024783/Untitled13.png)
Title: Re: Simutrans in 3D
Post by: missingpiece on January 28, 2012, 02:39:38 AM
I love screenshots of WIP.  8)
Title: Re: Simutrans in 3D
Post by: Markohs on January 28, 2012, 04:44:40 AM
Not all Screenshots of WIP are so cool :)

(http://dl.dropbox.com/u/30024783/Untitled14.png)
Title: Re: Simutrans in 3D
Post by: Zeno on January 28, 2012, 09:25:47 AM
Well, not so cool, but keeps being really promising :)
Title: Re: Simutrans in 3D
Post by: Ters on January 28, 2012, 02:47:08 PM
I managed to get simutrans3d to compile with mingw after doing a few changes. I've attached a patch for some of the changes, that doesn't seem like correct C++ to me. I also had to comment out line 48 in sim32map.cc, but that may be because something is missing in svn.
The executable I compiled also crashes. The debugger tells me that this is because dr_query_screen_resolution() queries renderWindow, that is NULL. dr_query_screen_resolution() is called from line 679 in simmain.cc, but as far as I can tell, renderWindow isn't initialized until dr_os_open() is called, which first happens when simgraph_init() is called at line 691 in simmain.cc.
I check out revision 5138. Is that revision supposed to work?
Title: Re: Simutrans in 3D
Post by: Markohs on January 28, 2012, 04:03:17 PM
 Hi Ters, thank you for taking the time and your help.

Applied the patch you sent me.

Well, all files in the sim3d folder need to be excluded from the project, they are not used atm, you only need to compile simsys_ogre.cc and simgraphogre.cc, replacing simsys_s.cc and simgraph_s.cc.

The sim3d/ files are the previous code I made when I focused the game to be full 3d, and will be useful in the future, atm I'm just focused on rendering current simutrans2D, using the ogre framework.

About the crash:

In my computer dr_query_screen_resolution() isn't called at all, the CPU reaches there having already values for disp_heigh and disp_heigh. But it's suposed to return the max allowed win dimensions, the correct way of handling it whould be parse:

static Ogre::StringVector foundRenderDevices;
static Ogre::StringVector foundResolutions;

That should be already been populated by the init code in "dr_os_init", but I didn't took the time to parse it yet, you can just return 640x800 or something manually till I write the code to parse it, or you can do yourself. :)

This code should fix the problem.


resolution dr_query_screen_resolution()
{
   resolution res;

   res.w=800;
   res.h=600;

   return res;
}


Title: Re: Simutrans in 3D
Post by: Ters on January 28, 2012, 04:32:14 PM
At least some of the header files in sim3d are included by files elsewhere, so they either need to be unincluded or fixed.

Once I changed dr_query_screen_resolution(), the game stops crashing when using Direct3D. No map though, but most of the GUI is there in right colors and proportions. Active toolbar buttons are missing, though.

When using OpenGL, it appears this problem occurs: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=8699 (http://www.ogre3d.org/forums/viewtopic.php?f=2&t=8699)
Title: Re: Simutrans in 3D
Post by: Markohs on January 28, 2012, 04:49:02 PM
 Just made a commit including your fixes, and some new code. Can you compile again now please?

Also, you'll need a new media folder:

http://dl.dropbox.com/u/30024783/media.zip (http://dl.dropbox.com/u/30024783/media.zip)

BTW, wich version of the SDK are you using? I use 1.7.4, also have in mind you'll have to move the DLL's to the directory of simutrans, it just needs:

OgreMain
Rendersystem_GL
RenderSystem_Direct3D9
OIS

I think cg.dll it's not necessary, but I have it there too.

On ogre.log you can see hints of error, but well, I see you already know all of this. :)

About the GL error:

Moving initializeallgroups call to after creating the renderwindow it's I think doable, I'll have it a look.
Title: Re: Simutrans in 3D
Post by: Ters on January 28, 2012, 06:44:57 PM
I use version 1.7.2 of the OGRE SDK, since that's the last pre-built version for mingw.

Apart from the head having changed to a building, the Direct3D version is unchanged. The OpenGL version now gets far enough to render the building, but nothing else, then crashes inside my graphic card's OpenGL driver. Last line in the log says it's loading or have loaded entis.png. I think there is reason to doubt that this is a fault in simutrans 3d.
Title: Re: Simutrans in 3D
Post by: Markohs on January 28, 2012, 07:05:59 PM
 Might be related to the initializeallgroups directive, maybe, at least on the OpenGL part. let's see....

simsys_ogre.cc, line 464:

   Ogre::ResourceGroupManager::getSingleton().initialiseAllResourceGroups();

move it to

int dr_os_open(int w, int const h, int const fullscreen)
{

   renderWindow = root->createRenderWindow("Simutrans " VERSION_NUMBER,w,h,fullscreen);

   if (renderWindow==NULL){
      fprintf(stderr, "Couldn't open the window.\n");
      return 0;
   }

   DBG_MESSAGE("dr_os_open(Ogre)", "Ogre realized screen size width=%d, height=%d depth=%d (requested w=%d, h=%d  depth=%d)", renderWindow->getWidth(), renderWindow->getHeight(),renderWindow->getColourDepth(), w, h,COLOUR_DEPTH);

   display_set_actual_width( w );

   Ogre::ResourceGroupManager::getSingleton().initialiseAllResourceGroups();

   dr_fb_setup();

   wl=new windowListener();
   root->addFrameListener(wl);
   rtt_render_texture->addListener(wl);

   return w;
}


About the screen not rendering good problem, I'll try to figure what's going wrong, some questions:

- Are you running in windowed or fullscreen mode?
- Wich is your video card?
- Can yoou post a screenshot of the failed render?
- Does the rendered building rotate or stays quiet?

Sounds like it's not a non-pow2 issue since at elast some parts of the screen are rendered okay, I'll get more computers to test what's wroing wrong, all looks good here. :(

Thank you for your help, Ters
Title: Re: Simutrans in 3D
Post by: Ters on January 28, 2012, 08:45:29 PM
Quote from: Markohs on January 28, 2012, 07:05:59 PM
About the screen not rendering good problem, I'll try to figure what's going wrong, some questions:

- Are you running in windowed or fullscreen mode?
- Wich is your video card?
- Can yoou post a screenshot of the failed render?
- Does the rendered building rotate or stays quiet?
Are you asking about the Direct3D or OpenGL results? In either case, I run the game windowed and on an ATI Mobility Radeon HD 5850. With Direct3D, the game was running, but with OpenGL, it crashed and I could only see something because either the debugger or the Windows error reporting tool kept the program in limbo.

I suggest not looking into the OpenGL problem unless other people still report problems after the resource initialization call has been moved. It might just be something with my computer, or the way I built the executable.
Title: Re: Simutrans in 3D
Post by: Markohs on January 28, 2012, 09:14:28 PM
Okay, as a sidenote:

- Found that HardwarePixelBuffer:blt (http://www.ogre3d.org/docs/api/html/classOgre_1_1HardwarePixelBuffer.html#afa8ebd4831c5e9a5538c486581d01ab0)  DOESN'T blend, just copies squares, overwriting and not blending using alpha, so my approach is not valid. This approach made possible to draw current simutrans in a hardware-accelerated fashion easy.
- Given that, I considered using 2 hardwarepixelbuffers, and blend them together on the render one for odd and other for even square positions, but I think this solution won't work because graphics have x and y offsets, and the z-order wont be feasible.
- The new approach is using yet another RTT layer and render the quads in a 2d fashion, like this (http://www.ogre3d.org/docs/api/html/classOgre_1_1HardwarePixelBuffer.html#afa8ebd4831c5e9a5538c486581d01ab0).

I'll keep you updated as usual for the case anybody is interested, or has a new idea. ;)

EDIT: I think I'm on the right track now: using a RTT texture, setting his camera viewport no not update every frame, and each frame, just render the queued items on top of the previous frame. This should support alphablending and image scaling without problems.

Looks like all 2D drawing functions were banned from DirectX9+ from what I read. Using a 3D library layer looks like the only way to accelerate games nowadays.
Title: Re: Simutrans in 3D
Post by: Markohs on January 30, 2012, 02:03:32 AM
 My preliminary tests are being quite sucessful, this method (rendering images as quads using alphablending textures using the 3D renderer) looks very promising. On some tests I've been making I've averaged 207 fps rendering 100 items each frame, plus a standard render of one 3D model at the same time. I think that's enough for simutrans. Buffer is not cleared each frame, so it works in the current framebuffer fashion, only writing changed sprites.

If this algorithm is faster or not than current simgraph routines, remains to be seen.

Thinking about this, at the end of this I think I can give new hardware accelerated features to current 2D simutrans.

- Arbitrary map zoom, applied by hardware.
- Partial transparencies, this can be applied to underground modes. Current pak graphics don't have a alphachannel, but this can open the possibility of 32 bit (R8G8B8A8) images instead of the current 16-bit (RGB with special colours) ones .
Title: Re: Simutrans in 3D
Post by: prissi on January 30, 2012, 10:19:29 AM
The ground could be transparent also in curretn simutrans, as we could draw transparent tiles. However, I am not sure if this would make access much easier; I rather doubt it.

But I am curiuos how the HW-accellerated simturans would compare. (Actually, the BLTs are currently most likely HW accellerated too).
Title: Re: Simutrans in 3D
Post by: Markohs on January 30, 2012, 10:52:02 AM
 Yea, it's not clear how we could apply those alpha partial renderings in the actual 2D, and they are already possible in current code. I don't really know if they will be useful or not (maybe to GUI items). But blending and color interpolating are computed by our rutines in pix_blendxx_xx manually, new routines for blending use the 3D engine to blend them, since a graphic card is a vectorial CPU (http://en.wikipedia.org/wiki/Vector_processor) it can compute complete lines in just one "cycle". This textures will be allocated to the VRAM of the memory card, with the speed boost that can mean.

This approach also eliminates the need of clipping the borders of the screen, and makes possible other clipping using texture offsets, even through don't think this will transform in way better performance since the clipping code I guess doesn't consume much CPU.

Another example of possible performance gain is the "display_img_nc", atm it's optimized I think to the full extent what it can be optimized, including that very clever 32-bit copying+1 16-bit copy.

The problem in that routine is that's not vectorizable for just one reason: the rle encoding, each line has a varying size, so one line can't rastered in a vectorial fashion. The only way to accelerate this is uncompressing the image in memory at the expense of maybe higher memory footprint, and make the alpha pixels explicit. That makes rendering the bitmap by hardware possible.

I'll just have to keep one uncompressed version in memory, since the zoomed versions are not necessary any longer, and player coloured versions cwill be created on the fly too, storing them all, not just one like now.

At least, that's my current way of implementing this, all can vary since I'm doing this in a trial-and-error way. ;)
Title: Re: Simutrans in 3D
Post by: Fabio on January 30, 2012, 12:18:32 PM
Enhancing 2D display and enabling full png alpha transparency look like two awesome possibilities!
Title: Re: Simutrans in 3D
Post by: Markohs on January 30, 2012, 02:04:30 PM
Quote from: fabio on January 30, 2012, 12:18:32 PM
Enhancing 2D display and enabling full png alpha transparency look like two awesome possibilities!

Yea, I think so, but don't really know wich can the possibilities be, beside to give you artists the chance to apply alpha to your creations freely.

I was thinking underground modes and maybe add some transparency to buildings when a vehicle passes after them, or making high city buildings partially transparent, not like they are now, grayed down.
Title: Re: Simutrans in 3D
Post by: Markohs on January 31, 2012, 01:59:56 AM
This starts looking better, but still lots of work to do, tomorrow more. :)

(http://dl.dropbox.com/u/30024783/Untitled15.png)
Title: Re: Simutrans in 3D
Post by: Markohs on January 31, 2012, 04:47:30 PM
Advanced more, the CPU usage is high, close to 100% of one core, but I think I can assign a second thread to the 3D rendering of the frame and leave the other to the current singlethreaded simutrans.

EDIT: No, I just noticed I was running it in debugging mode and -log 1 -debug 4, without those options it actually consumes less CPU than 2D simutrans, but I lack rendered objects still.

The image looks way smoother, result of the image blanding and interpolating, we also have a 0.5 pixel error now that might be fixed easy.

Look at the trees shadows, all looks better, but I don't know if this blurring will look good at the end.

(http://dl.dropbox.com/u/30024783/Untitled16.png)
Title: Re: Simutrans in 3D
Post by: Spike on January 31, 2012, 09:53:42 PM
I like the shadows, they help to give an impression of the contours and IMHO "glue" together the things.
Title: Re: Simutrans in 3D
Post by: Markohs on February 01, 2012, 08:53:04 PM
Still on this, progressing, all is working good so far. Just one question.

Who coded makeobj? Do you think it can be modified to create 32 bit pixels .pak too easy (8bit alpha, 8 red 8 blue 8 green)? Since source images are .png I guess this can be done without much problems?
Title: Re: Simutrans in 3D
Post by: kierongreen on February 01, 2012, 10:17:26 PM
It was coded along with the rest of simutrans. I'm not sure how you'd extend paks to have 32bit images - you'd have to choose a new format for the image data (could well leave it as png). You probably won't notice the difference in colour depth in game, alpha more than 4 bits won't be clear either really. Could well use some of the alpha bits to indicate player or whether pixels are illuminated (giving you a wide range of lit colours).
EG
Bits 1-4 alpha
Bit 5,6,7: 0 normal, 1 primary player colour, 2 secondary player colour, 3 retain colour at night time, 4 show black during day (unlit windows). If any value other than 0 then the alpha bits indicate the strength of effect, to allow antialiasing around player colour and window areas.

Still leaves some free values for bits 5,6 and 7, and bit 8 unused. Would require special tools to edit images properly though...

But maybe that is just pushing sprites too far and indicates 3d models would be more flexible (though you'd have to have a way of indicating player colour and lights on those too). Personally I'd go down that route rather than trying to overcomplicate 2d images which in long term you'd be trying to replace with models anyway.
Title: Re: Simutrans in 3D
Post by: Spike on February 01, 2012, 10:33:13 PM
Quote from: Markohs on February 01, 2012, 08:53:04 PM
Who coded makeobj? Do you think it can be modified to create 32 bit pixels .pak too easy (8bit alpha, 8 red 8 blue 8 green)? Since source images are .png I guess this can be done without much problems?

Volker Meyer made it. I had a rather monolithic file for all graphics before, and he invented the pak files to store object attributes and graphics together. The monolithic file didn't really allow mods and we were looking for a way to allow players to make their own addons.

It's not so hard to extend the image nodes to 32bit graphics data. But I'd suggest to create a different node type for those, so that you can use the same pak for traditional display with 16bpp images, and the 3D display with 32bpp images from one pak file.
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 01:10:50 AM
Thank you both.

Sometimes (specially today) I think forcing the sprite drawing algorithm in a 3D renderer it's pushing too far too, kierongreen.

Today I'm facing the problem that rendering the bitmaps one by one like I'm doing it now isn't fast enough, each call to  display_img_aux, display_color_img... it's queued to be rendered and EACH requires one RenderOperation by itself. This pushes performance below current Simutrans 2D code. Scaling is done on-the-fly by the renderer, but the current code caches the zoomed images in memory, so it's only slower when you switch zoom level, so the performance gain on that by Simutrans3D vanishes.

But maybe I'm missing something, or disabled the dirty tile management somehow because in a 1280x800 screen like this:

(http://dl.dropbox.com/u/30024783/Untitled17.png)

I'm getting 954 sprites draw PER FRAME, don't really ounderstand where do they come from since the window is mostly static, no action around.

Or maybe I have done something wrong and I'm wasting CPU performance anywere else.

I can try to draw entire horizontal tile lines in just one render operation, but that has one restriction: One renderoperation can only use one texture, so it whould be only useful on flat terrains for example (you can batch all tiles to one renderop) or on seas. This batching whould require also the use of hashes or some kind of memory structure, it's a bit complicated and the performance gain whould only apply to some circunstances so it's not really a solution per se.

I'm also trying to make one renderop using multiple textures and render batched lines of the map, but I don't really know if this is even possible. If that's possible performance whould be better than Sim2D within a huge difference.

Well, anyway I'm happy because all of this is making me understand the inners of simutrans, I'll find one solution one way or another.

Or I'll just forget about the 2D and just write a pure 3D program, like many people advised me here in the past.

We'll see, errors are part of learning. ;)

EDIT:

By the way, I've found rendering trees is being the biggest performance problem most of the times, and I'm pretty sure it pushes current simutrans badly too. But I guess that if the game needs to be able to render a full moving city, it should be abe to render a forest too. :)

Maybe grouping the renderops by texture, and playing with the z-order... Actually that might work, I'll try tomorrow, then the algorithm whoudn't have a O(X*Y*K) cost, it whoukld just be O(num_of_different_textures_in_viewport). ;)

Or maybe not, because that whould render items in the incorrect order...
Title: Re: Simutrans in 3D
Post by: kierongreen on February 02, 2012, 08:44:42 AM
If you can store all objects on the screen as 2d textured surfaces within a 3d world, then render that in one operation you should be ok. You'll have to have a table of links from objects to the surfaces though so that vehicles moving will update positions of the display surfaces. Surfaces can then be substituted for models in time, and in theory you get a slow change from 2d to 3d simutrans which remains playable throughout the transitio.....

Then viewpoints displayed within windows would have to be created as new rendered worlds with their own object->surface links. Alternatively (although I suspect memory constraints would not allow this) the entire map could be stored and updated every frame as a 3d word.

If you are having to render each one manually every frame performance, as you can see will suffer....

Don't knock what you have achieved so far though!!
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 10:02:14 AM
thx for the reply kierongreen.

Actually that whoudn't work either. everytime I plant one 2d textured image in the map, that means one render operation just for that item.

Rendering in 3D is quite similar to doing it in 2D, it basically draws all the visible items one by one like painter's algorithm way:

http://en.wikipedia.org/wiki/Painter%27s_algorithm (http://en.wikipedia.org/wiki/Painter%27s_algorithm)

But hardware uses extra framebuffers and has one framebuffer dedicated to the Z-koord os the last opaque item in the viewport, and just draws items that will be shown.

The problem is that for every item in the scene it has to perform a "RenderOperation", it's just one draw of one geomery that's accumulated on the color buffer (the actual output data). The sum of all those renderops, will create just one frame.

The idea is grouping some of the viewable items together in a single geometry (it hasn't to be continuous in space, just composed of triangles), and apply one texture to them, offsetting the texture in the vertexes as you need. So just on one renderoperation, you can draw lots of sprites on screen just in one pass. The problem in Simutrans2D is that given the inherent isometric view, I have to draw the image from top to bottom, in rows, so items in the back are not drawn AFTER that items in the front.

Looks like the solution to this is using texture atlas:

http://www.gamerendering.com/2009/12/08/texture-atlas/ (http://www.gamerendering.com/2009/12/08/texture-atlas/)
http://http.download.nvidia.com/developer/presentations/2005/GDC/Direct3D_Day/D3DTutorial03_Optimization.pdf (http://http.download.nvidia.com/developer/presentations/2005/GDC/Direct3D_Day/D3DTutorial03_Optimization.pdf)
http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf (http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf)

Maybe I can apply this, have to think about this a bit more. The actual code works, it's just too slow.
Title: Re: Simutrans in 3D
Post by: prissi on February 02, 2012, 10:17:02 AM
May<be tree are changing (depends on seasons) and if you use the new clipping algorithm (which will not be useful for your approach, tiles are draw many times when a pedestrian is on them. Set
simple_drawing_tile_size = 255
or so will activate the old behaviour with a single pass.

However, if the OpenGL renderer is slower than the normal CPU driven one, than this would not surprise me, as the speed is limited by the main memory access (or are the sprites loaded to the HW buffer on the card?) At least all attempts for OpenTTD was resulting in this. THus maybe rather go 3D.
Title: Re: Simutrans in 3D
Post by: Dwachs on February 02, 2012, 10:30:17 AM
Quote from: Markohs on February 02, 2012, 01:10:50 AM
But maybe I'm missing something, or disabled the dirty tile management somehow because in a 1280x800 screen like this:
I do not know up to which point you merged trunk, but there was a bug introduced in r4901 and fixed in r5118 that prevented resetting the dirty flag.
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 10:40:54 AM
The bottleneck is not the memory access I thik, since all sprites are loaded into the video RAM, the problem is the fact that the number of image drawing operations is very high, since I don't have a way to group them, losing all the advantage of a GPU. More time is spent switching to one sprite to the other, and rendering than the actual time a render takes.

That nVidia document menctions that rendering more than 1000 batches per frame it's too much. We should aim to 1000, only.

An on normal zoom image I'm getting 954 sprites, already.

The algorithm is basically:

1) load all needed textures to VRAM (this is not speedlight fast, but it only has to be done at the estart, not at each frame)
2) from simintr.cc, intr_refresh_display:
   - tons of sprites are queued to be drawn, this has not performance impact
   - At the end of the frame, all sprites are rendered:
     - Creates a HardwareVertexBuffer (no cost)
     - Fills the HardwareVertexBuffer with the geometries (2 triangles for each sprite, plus the offsets of the texture to apply)
     - foreach(sprite)
       * Create a renderop
       * set texture to the renderop
       * Set the geometry start pointer in the vertexbuffer to the renderop, and it's size (allways 7 vertexes)
       * Tell GPU to render the renderop on top of the framebuffer

The time is spent in the '*' lines. If we can group the operations somehow, the '*' part of the algorithm will be less performance punisher. But for this we'll need a texture atlas, to be able to not switch the texture *SO* often, and play with the offsets.

To make it short: A GPU likes you to fetch some small number of batches (1000 at most) with lots of geometries and texture offsets (GPU will draw it super fast), than lots of batches with a simple geometry (atm, just 2 triangles forming a square, more time is wasted starting renderops and switching to the next than teh actual render)

EDIT: Thx for your comments, I'll have it a look to the dirty setting you menction, prissi/dwachs.

BTW, this also helped me to get lots of new ideas for the 3D tilemanager I need to implement anyway for rendering the map in 3D, learning new things is never a waste! :)
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 11:40:29 AM
Quote from: Dwachs on February 02, 2012, 10:30:17 AM
I do not know up to which point you merged trunk, but there was a bug introduced in r4901 and fixed in r5118 that prevented resetting the dirty flag.

I have merged 5129 in my branch, anyway I'll echeck 5118 to see where was the bug and if I still have it. Thx!
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 12:03:29 PM
Given that the screen drawing it's done in 3 important steps:

- Ground
- Things
- Overlays

If I could manage to get a atlas image of all the sprites used in each phase, this whould work.

But I don't know if all those sprites can fit in an atlas of let's say 8192x8192 pixels. Ground ones will fit for sure, but for things this can be maybe impossible.

That whould need generating atlas just for Simutrans3D, and render the paks unusable, or maybe I can create the atlas dynamically in memory as the game demands new images.

I'm not really sure if this work is really worth it, but I'm pretty sure it whould work good. I fancied making a 3D renderer for current simutrans2D and releasing it before starting with the pure 3D simutrans.

I think I'll give the dynamic atlas creation a try, have a boodbeat about it.
Title: Re: Simutrans in 3D
Post by: TurfIt on February 02, 2012, 02:46:32 PM
Are there limits to the texture size?
i.e. Can you load all the sprite images into a single texture allowing a single renderop for the 'Things'?

Also, how would going full 3D help this situation? Instead of rendering 954 objects with 2 triangles each (billboard), you'd be rendering 954 objects with say 100 triangles each. Since number of triangles isn't the bottleneck (within reason), I don't see the difference...
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 03:23:49 PM

Just checked the revision you pointed me, Dwachs, and your patch was applied already to my code, thx. :)

From what I saw, in the current simutrans standard code, simgraph16.cc, line 2231:

void display_img_aux(const unsigned n, KOORD_VAL xp, KOORD_VAL yp, const sint8 use_player, const int /*daynight*/, const int dirty)

But the image is drawn anyway, the "dirty" bool just makes sure dr_textur is called to tell the low level routines to make sure it's copied to screen.

Then... Why is it drawn at all if dirty=false? isn't this wasting CPU? I think I misunderstood the concept of dirty tiles applied to my renderer.

I just made a if(drty)return; and the sprite number dropped a lot:

16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 146 sprites
16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 32 sprites
16:17:00: Ogre2D has 32 sprites
16:17:01: Ogre2D has 146 sprites
16:17:01: Ogre2D has 144 sprites

But I'm getting tiles not redrawn  when pedestrians and city traffic passes over them, and on a zoom:

(http://dl.dropbox.com/u/30024783/Untitled18.png)

Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 03:32:27 PM
 Turfit, the same situation arises in 3D, yes.

You can't just put one 3D mesh for each item in the map, you have for example applied to a terrain, construct one SINGLE mesh and give it the form it has to have, and in our case, simulate the "tiles" applying a multilayered texture over it and tweak the blending values in the needed positions.

Same applies to for example roads they have to be "fusionated" and sent to the render as a single mesh.

Since this approach is hard to do, it's splitted in big chunks of vertexes, for example every 512 vertexes, you create a new mesh. Uses to be powers of 2 for many reasons (most of them I don't know yet), but basically because b-trees are used to generate them in optional computing time.

That's why for eaxmple buildings will have to be modeled in a single mesh. and most objects have to be grouped somehow. The more batches you render each frame, the poorest performance you'll get, since most of the work will be done by the CPU instead of the GPU.

Think like this:

It's an order of magnitude faster rendering 10 batches of 1000 triangles than 100 batches of 100 triangles.

This will have lots of implications in how we'll manage the objects in simutrans. For example cities will be modeled as a single mesh or in a low number of sub meshes, and the mesh will have to be recreated if any of the components has changed. But you can render it super-fast, in any angle, in almost constant time.

Same will happen to forests, for example. Or we can just group items by 3 categories:

1) Almost immutable geometries.
2) Geometries that have to change often.
3) Movable objects, like vehicles.
Title: Re: Simutrans in 3D
Post by: TurfIt on February 02, 2012, 03:53:23 PM
Quote from: Markohs on February 02, 2012, 03:23:49 PM
From what I saw, in the current simutrans standard code, simgraph16.cc, line 2231:
void display_img_aux(const unsigned n, KOORD_VAL xp, KOORD_VAL yp, const sint8 use_player, const int /*daynight*/, const int dirty)
But the image is drawn anyway, the "dirty" bool just makes sure dr_textur is called to tell the low level routines to make sure it's copied to screen.
Then... Why is it drawn at all if dirty=false? isn't this wasting CPU? I think I misunderstood the concept of dirty tiles applied to my renderer.
Dirty tiles is a higher level concept. Once down to the actual display routine, it's being called because the image needs to be drawn...
If the tile is not marked dirty, the objects on it aren't processed.


Quote from: Markohs on February 02, 2012, 03:32:27 PM
Turfit, the same situation arises in 3D, yes.

<...>

That's why for eaxmple buildings will have to be modeled in a single mesh. and most objects have to be grouped somehow. The more batches you render each frame, the poorest performance you'll get, since most of the work will be done by the CPU instead of the GPU.
I think that's what I was trying to ask above. Put all the images into one texture, and merge all the 2 triangle billboards into one render call. I take it Ogre doesn't allow you to render multiple meshs with one call? Is there any hardware support for merging meshs?
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 04:09:32 PM
Quote from: TurfIt on February 02, 2012, 03:53:23 PM
Dirty tiles is a higher level concept. Once down to the actual display routine, it's being called because the image needs to be drawn...
If the tile is not marked dirty, the objects on it aren't processed.

But I'm getting almost 1000 display_img_aux each fram on a non unzoomed position, is that normal? I might have screwed something up, because I'm getting also heap corruption. So I've commmented out code that messes with pointers I shoudn't have commented out. I'll check it.

I'm also checking the option prissi pointed out.

Quote from: TurfIt on February 02, 2012, 03:53:23 PM
I think that's what I was trying to ask above. Put all the images into one texture, and merge all the 2 triangle billboards into one render call. I take it Ogre doesn't allow you to render multiple meshs with one call? Is there any hardware support for merging meshs?

Yeah, that's the "atlas" concept. You create a single texture with all the images you might want to show, like this:

(http://www.gamerendering.com/wp-content/uploads/textureatlas.jpg)

Then you render the whole screen in just one render operation, sending the geometry. That whould work for sure. And it whould be light-speed fast.

The problem is I think I can't put all images on a texture, since pak 128 for example has like 2.000 images if I recall correctly. I think there is a limit to a texture size, that can vary from driver to drive, maybe with a minimum of 1024x1024. I don't think they can fit on the same image, maybe splitting in multiple atlas can work. One for backgrounds, one for buildings, another for movable objects...

Or create the atlas in-memory on demand, but it's a complicated algorithm if you wanna take max profit of the texture surface, since images have different size, and coputimg optimal distribution it's an exponential problem, even you knowing all the sices on startup. A simple algorithm whould render much unused space on the texture.

So I can render all in 3-6 render passes. Have in mind every render writes on TOP of the previous renders, so this has to be done in the correct order.

EDIT: Info about texture sizes in vendors:

[link]http://vterrain.org/LargeTextures/[/link]
Title: Re: Simutrans in 3D
Post by: TurfIt on February 02, 2012, 05:13:46 PM
Quote from: Markohs on February 02, 2012, 04:09:32 PM
But I'm getting almost 1000 display_img_aux each fram on a non unzoomed position, is that normal? I might have screwed something up, because I'm getting also heap corruption. So I've commmented out code that messes with pointers I shoudn't have commented out. I'll check it.
That does appear excessive for the screen shots you've shown. I'd have to wade through your 3D branch code to find where all you've hooked into the display routines, but it sounds as though you've done so at quite a low level. The entire current structure of the code is oriented towards 2D and its requirements. To optimally use 3D (or even this hybrid billboard approach) you'll need to change away from this 2D code completely. 


Quote from: Markohs on February 02, 2012, 04:09:32 PM
I'm also checking the option prissi pointed out.
prissi was referring to an option that controls the 2D clipping. That software 2D clipping shouldn't be necessary for 3D rendering? ??


Quote from: Markohs on February 02, 2012, 04:09:32 PM
So I can render all in 3-6 render passes. Have in mind every render writes on TOP of the previous renders, so this has to be done in the correct order.
I'm getting lost here, need to see the code to comment much further I thinks...

Isn't the whole idea to populate a scene with several objects, all with their own meshes/textures, located at 3D coordinates, and render once? (excluding the background landscape and foreground overlay) The render operation should take care of the correct order in hardware.

If you're calling a render object by object, back to front as the current 2D code does, then I think you've created a 3D decelerator like was done for OpenTTD.  :o
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 05:40:14 PM
hehe, I'll try to explain it clearly now:

I've just modified simsys and simgraph with code that calls to Ogre functions, the modifications have been:

- In Symsys, nothing really fancy, opening the window, handling of events, etc..
- In simgraph:

- 'textur' is gone, there is not a framebuffer accesible anymore.
- this functions:

display_img_aux
display_color_img
display_rezoomed_img_blend
display_base_img

And all that manipulated the "textur" pointer (font management, line rawing etc), have been commented out.

- in simintr.cc, intr_refresh_display I have hooked one funcion called renderframe() that forces a image rendering of screen.

At this state the program should show a black screen completely.

Okay, after that:

rezoom_img() has been modified to just assign the new x,y,w,h of the images, the image is not recomputed.

AND:


/**
* Zeichnet Bild mit verticalem clipping (schnell) und horizontalem (langsam)
* Draws image considering vertical and horizontal clipping
* @author prissi
*/
void display_img_aux(const unsigned n, KOORD_VAL xp, KOORD_VAL yp, const sint8 use_player, const int /*daynight*/, const int dirty)
{
    if (n < anz_images) {
        // need to go to nightmode and or rezoomed?

        KOORD_VAL h, clip_bottom, clip_top;

        if (use_player) {
            return;
/*            FIX: Handle colored data
            sp = images[n].player_data;
            if (sp == NULL) {
                printf("CImg %i failed!\n", n);
                return;
            }*/
        } else {
           
            // REZOOM AND RECODE ARE NOT NEEDED ANYMORE
            if (images[n].recode_flags&FLAG_REZOOM) {
                rezoom_img(n);
//                recode_normal_img(n);
            }
/*            else if (images[n].recode_flags&FLAG_NORMAL_RECODE) {
                recode_normal_img(n);
            }
*/
            // SIM3D:
            // generate uncompressed version

            if (!images[n].data_pb){
                decode_img(n);
            }

        }

        if (!dirty){
            return;
        }

        // now, since zooming may have change this image
        yp += images[n].y;
        h = images[n].h; // may change due to vertical clipping

        // in the next line the vertical clipping will be handled
        // by that way the drawing routines must only take into account the horizontal clipping
        // this should be much faster in most cases
        // SIM3D: only discard items not visible at all

        // bottom of the screen

        // calculate how much height will fall outside and exit if nothing will be visible
        clip_bottom = yp + h - clip_rect.yy;

        if ((clip_bottom > 0) && (h-clip_bottom <= 0)) {
                // not visible at all
                return;
        }

        if (clip_bottom<0){
            clip_bottom=0;
        }

        // top of the screen

        clip_top = clip_rect.y - (int)yp;
        if (clip_top >= h) {
            // not visible at all
            return;
        }

        if (clip_top<0){
            clip_top=0;
        }


        // new block for new variables
        {
            // needed now ...
            const KOORD_VAL w = images[n].w;
            xp += images[n].x;

            // clipping at poly lines?
            if (number_of_clips>0) {
                    // FIX: Handle this
                    //display_img_pc<plain>(h, xp, yp, sp);
                    display_img_2dogre_vclip(n, xp, w, yp, h, clip_top, clip_bottom);
                    if (dirty) {
                        mark_rect_dirty_wc(xp, yp, xp + w - 1, yp + h - 1);
                    }
            }
            else {
                // use horizontal clipping or skip it?
                if (xp >= clip_rect.x  &&  xp + w <= clip_rect.xx) {
                    if (dirty) {
                        mark_rect_dirty_nc(xp, yp, xp + w - 1, yp + h - 1);
                    }
                    display_img_2dogre_vclip(n, xp, w, yp, h, clip_top, clip_bottom);
                } else if (xp < clip_rect.xx  &&  xp + w > clip_rect.x) {
                    if (dirty) {
                        mark_rect_dirty_wc(xp, yp, xp + w - 1, yp + h - 1);
                    }
                    display_img_2dogre_vclip(n, xp, w, yp, h, clip_top, clip_bottom);
                }
            }
        }
    }
}


As you can see, at the start it just checks if the texture has already been processed and it's registered.  decode_img() does that, after calling it, there is a square texture in NVRAM with the contents of that "imd[n]", it's called "imd_n" with n as the index of the image).

After that, following the previous code I just find if the image needs vertical clipping, because horizontal it's not needed, the 3d renderer will discar those pixels. The vertical clipping it's important to not write over the toolbar nor the bar on the bottom.

And then I just

                    display_img_2dogre_vclip(n, xp, w, yp, h, clip_top, clip_bottom);

This code is:


void display_img_2dogre_vclip(const unsigned n, const KOORD_VAL x, const KOORD_VAL w, const KOORD_VAL y, const KOORD_VAL h,const KOORD_VAL clip_top, const KOORD_VAL clip_bottom ){

    std::string textureName = Ogre::String("imd_"+Ogre::StringConverter::toString(n));

    double x1,x2,y1,y2;
    double tx1,tx2,ty1,ty2;

    double half_w = (double)disp_width/2;
    double half_h = (double)disp_height/2;


    tx1=0;
    tx2=1;
    x1=(double)((x-half_w)*2)/(disp_width);
    x2=(double)(((x+w)-half_w)*2)/(disp_width);

    if (clip_top){
        ty1 = (double) clip_top/h;
        y1=(double)(-((y+clip_top)-half_h)*2)/(disp_height);
    }
    else{
        ty1 = 0;
        y1=(double)(-((y)-half_h)*2)/(disp_height);
    }

    if (clip_bottom){
        ty2 = (double) (h-clip_bottom)/h;
        y2=(double)(-((y+h-clip_bottom)-half_h)*2)/(disp_height);
    }
    else{
        ty2=1;
        y2=(double)(-((y+h)-half_h)*2)/(disp_height);
    }

    ogre2dManager->spriteBltFull(textureName,x1,y1,x2,y2,tx1,ty1,tx2,ty2);
}


This normalizes the coordinates to the [-1,1] coordinate system, and QUEUES the image to be drawn on the next render(). I know some algebra whould simplify those calculations, but that shoudn't be performance punishing at this level now.

x1 is left, y1 is top, x2 is right and y2 is bottom. tx1,tx2,ty1 and ty2 are the offsets of the texture he should use over the geometry.

Each spriteBlted, QUEUES a  renderoperation, that renderoperation will take place when renderframe() is called.

And yea, atm is a DECELERATOR. :)
Title: Re: Simutrans in 3D
Post by: prissi on February 02, 2012, 07:56:14 PM
I thing the way to go it modifying simview, as there you also get a z-coordinate. You can sent then all stuff to the engine with that z-coordinate and it will dot the display automatically. (Ok, that was naive, but I hope you get my meaning.)
Title: Re: Simutrans in 3D
Post by: Markohs on February 02, 2012, 08:04:42 PM
Yea, z-ordering plus atlas generation might be the answer to all of this.

Having a look to gorilla, that's claimed to outperform all 2D managers over Ogre, getting some ideas from it's code.

[link]https://github.com/betajaen/gorilla/blob/master/README.md[/link]

Just had a look and pak128 has 14967 images, dunno how much buffers will take to get that into memory, and it's size. If size is a problem we can allways use a texture compression utility, GPU uncompreses and uses them on the fly.

Maybe rendering the GUI in different layers can make things easier too. ;)

As a side note: I don't know if I already said this explicitly but my intentions in this first phase of the project is touching the minimum number of files I can, so I can keep using the current code, including the UI and the core game engine of Simutrans, and both builds can coexist with minimum problems.

Once we have to keep in sync the simutrans model and the 3D world, it will be unavoidable modifying more and more files, and add functions that don't exist in current simutrans. But the UI and the inners and simutrans will remain the same, if I can.
Title: Re: Simutrans in 3D
Post by: Markohs on February 03, 2012, 01:05:10 AM
I wanna thank to whoever added a assert in the function mark_tiles_dirty (disabled by preprocessor, but still). The heap corruption was coming from there, it was writing some extra bytes ahead and giving me all those problems. :)

Man, I think I'd have never been able to track it if it wasn't for the assert. ;)
Title: Re: Simutrans in 3D
Post by: O01eg on February 12, 2012, 03:24:10 PM
Is it possible to build simutrans3d under Linux? I fix Makefile and change backslash to slash but some win-specifics like TRUE and Sleep cause errors:

simsys_ogre.cc: In function 'int dr_os_init(const int*)':
simsys_ogre.cc:396:36: error: new declaration 'int dr_os_init(const int*)'
simsys.h:63:6: error: ambiguates old declaration 'bool dr_os_init(const int*)'
simsys_ogre.cc:466:9: error: 'TRUE' was not declared in this scope
simsys_ogre.cc: In function 'int dr_os_close()':
simsys_ogre.cc:773:21: error: new declaration 'int dr_os_close()'
simsys.h:74:6: error: ambiguates old declaration 'void dr_os_close()'
simsys_ogre.cc:779:9: error: 'TRUE' was not declared in this scope
simsys_ogre.cc: In function 'long unsigned int dr_time()':
simsys_ogre.cc:1151:6: error: 'first' was not declared in this scope
simsys_ogre.cc:1156:41: error: 'first' was not declared in this scope
simsys_ogre.cc: In function 'void dr_sleep(uint32)':
simsys_ogre.cc:1163:12: error: 'Sleep' was not declared in this scope

Revision 5283
Ogre 1.7.3
Title: Re: Simutrans in 3D
Post by: Markohs on February 12, 2012, 03:36:58 PM
There are some things going on here:

- I never compiled it in linux, so some tweaks might be necessary
- I didn't knew TRUE was windows specific.
- that sleep is copied from the SDL version(simsys_s.cc), I guessed it should work but wasn't really sure. Might be a include missing.
- I recently updated from subversion head revision, and simsys.h headers have changed since the last time, that needs a fix too.

I'll have it a look when I'm able to, but now I'm focusing more in the CEGUI project, but any patch you or anybody makes is welcome.
Title: Re: Simutrans in 3D
Post by: isidoro on February 12, 2012, 04:58:41 PM
In fact TRUE is a macro of windows.h.  I guess it comes from the times of C.  C++ has a full-fledged true keyword.  The same goes for BOOL, WORD, LPWORD, etc., all Microsoft stuff...

Sleep is also a Win32 API call, though SDL may have an equivalent function...

Title: Re: Simutrans in 3D
Post by: jamespetts on February 12, 2012, 05:12:19 PM
Weren't all the instances of "TRUE" replaced by the standard C++ "true" in the code in Standard recently?
Title: Re: Simutrans in 3D
Post by: Ters on February 12, 2012, 05:38:14 PM
I think so, but that was after Simutrans 3D forked and could not spread to files unique to Simutrans 3D.
Title: Re: Simutrans in 3D
Post by: Markohs on February 12, 2012, 06:05:49 PM
No, in fact I typed TRUE in caps myself, correcting it.
Title: Re: Simutrans in 3D
Post by: O01eg on February 12, 2012, 06:09:08 PM
I fix some more errors.
Title: Re: Simutrans in 3D
Post by: Markohs on February 12, 2012, 08:04:33 PM
Thank you, just applied them
Title: Re: Simutrans in 3D
Post by: IgorEliezer on February 12, 2012, 08:16:57 PM
Quote from: O01eg on February 12, 2012, 06:09:08 PM
I fix some more errors.
Thanks dude. And welcome to the community.
Title: Re: Simutrans in 3D
Post by: O01eg on February 17, 2012, 03:00:08 PM
What is the difference between ogre, cegui and opengl backends?
Title: Re: Simutrans in 3D
Post by: Markohs on February 17, 2012, 03:13:28 PM
 They are 3 projects, thought as an incremental implementation of the final goal, a simutrans with 3D models in it:

- opengl just renders the window using OpenGL+SDL, it's mainly the code Ters made in the CEGUI topic.
- cegui it's based on the opengl build, and targets the migration of the current GUI windows to CEGUI engine, that allows many improvements in the current GUI.
- ogre is the final 3D enabled project, it will use cegui as a base. It will render current simutrans2D objects plus 3D objects, that will be merged in the screen.

I'm mainly alone on this, if anybody wants to help in any of these projects, just tell me and we can find a area you are comfortable working with.  I just have some spare time some days a week to program atm, will be able to spend more time in a few months.
Title: Re: Simutrans in 3D
Post by: Markohs on February 17, 2012, 03:26:22 PM
The TODO list (from the top of my head) is:

opengl:
- Fix known bugs.
- Explore if using non-pow2 texture is a problem in a significant number of nowadays computers, and find a acceptable solution.
- Fully document the simsys_opengl.cc file.

cegui:
- Figure how to integrate with the current simwin.cc, gui/* classes in a way they can co-exist in the first steps of the development.
- Adapt .lookandfeel file to the needed simutrans widgets.
- Artistic work in the .imageset file
- Design how we can provide customizable .layout, .lookandfeel and a LUA interface to the PAK creators so they can modify default settings freely.
- Migrate current simutrans widgets/windows to CEGUI
- Explore new/interesting ideas all the windows scaling/deformation/alphablending capabilities have can be applied to the GUI
- Generate a in-memory imageset from the PAK GUI images, they are needed across the GUI

ogre:
- Implement the current 2D drawing algorithm using imagesets to get performance closer or better than current code.
- Explore the new possibilities sprites alpha and rotation/scaling can give to the 2D render (rotate trains on curves for smoother display, train tiling, inclination on slopes )
- Replace the world fundament drawing part of the algorithm with a 3D (perspective) world, it needs memory paging or we'll reach the 2Gb limit easy.
- Figure a way to get rid of the trees so they don't punish performance, LOD levels will be necessary.
- replacing vehicles with 3D models
- replacing buildings with 3D objects.
Title: Re: Simutrans in 3D
Post by: O01eg on February 17, 2012, 04:01:30 PM
I've fixed yet some error but one cann't be fiexd:

simgraphogre.cc: In function 'void display_img_pc(KOORD_VAL, KOORD_VAL, KOORD_VAL, const PIXVAL*)':
simgraphogre.cc:1769:16: error: 'textur' was not declared in this scope
simgraphogre.cc:1769:30: error: 'rowpitch' was not declared in this scope


How can it be compilable even under Windows?
Title: Re: Simutrans in 3D
Post by: Markohs on February 17, 2012, 04:16:01 PM
Comment out the whole function body. Have in mind that code is not complete and only the display_img_aux function is implemeted using ogre.

Just implementing that, showed the perfromance was not acceptable, and a new approach, requiring imagesets, is necessary.

The textur pointer is gone, since there is not any buffer there.

That code lacks code for display_color_img,display_rezoomed_img_blend,display_base_img and display_base_img_blend
Title: Re: Simutrans in 3D
Post by: Ashley on February 17, 2012, 05:13:32 PM
Once I get the Quartz frontend working I'll work next on making a Quartz + OpenGL version too, since this would be complimentary. I'm still seeing all sorts of random crashes which I don't think are from my additions though.
Title: Re: Simutrans in 3D
Post by: O01eg on February 17, 2012, 05:46:59 PM
All compiles but doesn't link.

$ grep -n -R "set_3d_map" *
sim3d/sim3dmap.cc:48: welt->set_3d_map(this);
simworld.h:1084: void set_3d_map(sim_3d_map* sim3dmapin);


Did you forget commit changes to rep?
Title: Re: Simutrans in 3D
Post by: Markohs on February 17, 2012, 05:50:28 PM
I'll comit as soon as I arrive home, can't do it here. :)

References to sim3dmap.cc have to be removed atm, they are not needed now, I thought I removed them some days ago, I'll have it a look too.

About the OpenGL in quartz, it can be a good addition, I don't think you'll have much problems integrating it. :)
Title: Re: Simutrans in 3D
Post by: Markohs on February 17, 2012, 08:47:37 PM
Applied your patch, 001eg, with some minor modifications
Title: Re: Simutrans in 3D
Post by: O01eg on February 18, 2012, 03:51:59 AM

build/default/simgraphogre.o:(.data+0x8): multiple definition of `large_font_height'
build/default/simgraphogre.o:(.data+0x8): first defined here
build/default/simgraphogre.o:(.data+0x18): multiple definition of `tile_raster_width'
build/default/simgraphogre.o:(.data+0x18): first defined here
build/default/simgraphogre.o:(.data+0x1a): multiple definition of `base_tile_raster_width'
build/default/simgraphogre.o:(.data+0x1a): first defined here
build/default/simgraphogre.o: In function `min':
/mnt/another/tmp/simutrans3d/simtypes.h:153: multiple definition of `display_normal'
build/default/simgraphogre.o:/mnt/another/tmp/simutrans3d/simtypes.h:153: first defined here


It's inconceivable.
Title: Re: Simutrans in 3D
Post by: Markohs on February 18, 2012, 11:08:28 AM
Might be related to the Makefile including in SOURCES simgraphogre 2 times:

line 367:

ifeq ($(BACKEND),ogre)
  SOURCES += simgraphogre.cc
else
  SOURCES += simgraph$(COLOUR_DEPTH).cc
endif

and line 479:

  SOURCES += simgraphogre.cc

  Updated the svn. Have in mind, 001eg, as I told you already I never compiled that in linux (I build it with visual studio 2010), and code is work in progress.
Title: Re: Simutrans in 3D
Post by: O01eg on February 18, 2012, 11:12:08 AM
Can you also rename *.cpp to *.cc because Makefile doesn't support .cpp extension?
Title: Re: Simutrans in 3D
Post by: Markohs on February 19, 2012, 04:13:36 AM
done, 001eg
Title: Re: Simutrans in 3D
Post by: O01eg on February 19, 2012, 08:34:42 AM
I've fixed last error. Now it compiles. It's possible to remove sim3dmap.* and sim3dwin.*

I copy sim from build/default/ to simutrans/ folder. Whet I run its I get error:


terminate called after throwing an instance of 'Ogre::FileNotFoundException'
  what():  OGRE EXCEPTION(6:FileNotFoundException): 'resources.cfg' file not found! in ConfigFile::load at /tmp/portage/dev-games/ogre-1.7.3/work/ogre_src_v1-7-3/OgreMain/src/OgreConfigFile.cpp (line 83)
Title: Re: Simutrans in 3D
Post by: Markohs on February 19, 2012, 07:40:02 PM
You need a media folder on simutrans folder, use this one: http://dl.dropbox.com/u/30024783/media.zip
Title: Re: Simutrans in 3D
Post by: O01eg on February 20, 2012, 01:00:06 PM
Fixes for rev5398. Don't use \ in include path. Types for functions' arguments must be equal in declaration and implementation. bool and int are different types. Don't use int for logical variables.

Errors in gui_templated/pakselector.cc:

gui_templated/pakselector.cc: In member function 'void pakselector_t::fill_list()':
gui_templated/pakselector.cc:123:22: error: aggregate 'pakselector_t::fill_list()::_finddata_t entry' has incomplete type and cannot be defined
gui_templated/pakselector.cc:126:42: error: '_findfirst' was not declared in this scope
gui_templated/pakselector.cc:135:25: error: '_A_SUBDIR' was not declared in this scope
gui_templated/pakselector.cc:149:35: error: '_findnext' was not declared in this scope
gui_templated/pakselector.cc:151:19: error: '_findclose' was not declared in this scope
make: *** [build/default/gui_templated/pakselector.o] Error 1


Also media.zip doesn't contain resources.cfg.
Title: Re: Simutrans in 3D
Post by: Markohs on February 20, 2012, 02:19:56 PM
 Thank you for your comments and patches, 001eg, just applied your patch.

Yes, I know pakselector.cc doesn't work in linux atm, I first want to make a working windows code and solve how will I manage the event handling, that's unclear to me yet. That code it's based in gui/savegame_frame.cc, there is the non visualc code too.

Right now I'm not coding anything ogre related, my focus is the CEGUI version, but you can use a resources.cfg like this one:


[General]
FileSystem=media/materials/scripts
FileSystem=media/materials/textures
FileSystem=media/materials/textures/nvidia
FileSystem=media/models


plugins.cfg:


# Defines plugins to load

# Define plugin folder
PluginFolder=.

# Define plugins
# Plugin=RenderSystem_Direct3D9
# Plugin=RenderSystem_Direct3D10
# Plugin=RenderSystem_Direct3D11
Plugin=RenderSystem_GL
Title: Re: Simutrans in 3D
Post by: O01eg on February 22, 2012, 09:32:18 AM
Quote from: Markohs on February 20, 2012, 02:19:56 PM
Yes, I know pakselector.cc doesn't work in linux atm, I first want to make a working windows code and solve how will I manage the event handling, that's unclear to me yet. That code it's based in gui/savegame_frame.cc, there is the non visualc code too.

Why do not you use code for searching files from trunk? It works both under Linux and Windows. It's need to change gui related stuff to CEGUI.
Title: Re: Simutrans in 3D
Post by: Markohs on February 23, 2012, 06:54:16 PM
Yep, that's plan, 001eg
Title: Re: Simutrans in 3D
Post by: missingpiece on February 26, 2012, 08:31:28 AM
Just wanted to give a shout out to the brave coders in this thread hacking on the 3D version. You have my compassion. Looking forward to anything presentable.
Title: Re: Simutrans in 3D
Post by: Markohs on February 26, 2012, 10:17:05 AM
There is indeed a lot of code to be done still.
Title: Re: Simutrans in 3D
Post by: O01eg on April 05, 2012, 02:37:10 PM
Fixes for simutrans3d branch:

Index: Makefile
===================================================================
--- Makefile (revision 5610)
+++ Makefile (working copy)
@@ -477,7 +477,14 @@
   SOURCES += music/no_midi.cc
   SOURCES += sound/no_sound.cc
   CFLAGS += $(shell pkg-config --cflags OIS)
+  CFLAGS += $(shell pkg-config --cflags CEGUI)
+  CFLAGS += $(shell pkg-config --cflags CEGUI-OPENGL)
+  CFLAGS += $(shell pkg-config --cflags sdl)
+  CFLAGS += -DSIM_CEGUI
   LIBS += $(shell pkg-config --libs OIS)
+  LIBS += $(shell pkg-config --libs CEGUI)
+  LIBS += $(shell pkg-config --libs CEGUI-OPENGL)
+  LIBS += $(shell pkg-config --libs sdl)
endif


Index: simsys_cegui.cc
===================================================================
--- simsys_cegui.cc (revision 5610)
+++ simsys_cegui.cc (working copy)
@@ -21,8 +21,8 @@
#include <CEGUIScheme.h>
#include <CEGUIImage.h>

-#include <elements\CEGUIItemListbox.h>
-#include <elements\CEGUIItemEntry.h>
+#include <elements/CEGUIItemListbox.h>
+#include <elements/CEGUIItemEntry.h>

#include <GL/gl.h>
#include <GL/glext.h>


I can successfully compile sim with this patch but get this errors when try to run:

$ ./sim
Use work dir /mnt/another/tmp/simutrans3d/simutrans/
Reading low level config data ...
parse_simuconf() at config/simuconf.tab: Reading simuconf.tab successful!
Preparing display ...
Screen Flags: requested=12, actual=12
CEGUI::InvalidRequestException in file CEGUIDefaultResourceProvider.cpp(103) : DefaultResourceProvider::load: /mnt/another/tmp/simutrans3d/simutrans/./media/gui/imagesets/WindowsLook.png does not exist
DefaultResourceProvider::load: /mnt/another/tmp/simutrans3d/simutrans/./media/gui/imagesets/WindowsLook.png does not existLoading font 'font/prop.fnt'
font/prop.fnt successfully loaded as old format prop font!
Init done.
CEGUI::UnknownObjectException in file CEGUIWindowFactoryManager.cpp(180) : WindowFactoryManager::getFactory - A WindowFactory object, an alias, or mapping for 'WindowsLook/FrameWindow' Window objects is not registered with the system.
CEGUI::InvalidRequestException in file CEGUIGUILayout_xmlHandler.cpp(233) : GUILayout_xmlHandler::startElement - layout loading has been aborted since no WindowFactory is available for 'WindowsLook/FrameWindow' objects.
GUILayout_xmlHandler::startElement - layout loading has been aborted since no WindowFactory is available for 'WindowsLook/FrameWindow' objects.CEGUI::UnknownObjectException in file CEGUIWindowFactoryManager.cpp(180) : WindowFactoryManager::getFactory - A WindowFactory object, an alias, or mapping for 'WindowsLook/ListboxItemCustom' Window objects is not registered with the system.
CEGUI::InvalidRequestException in file CEGUIGUILayout_xmlHandler.cpp(233) : GUILayout_xmlHandler::startElement - layout loading has been aborted since no WindowFactory is available for 'WindowsLook/ListboxItemCustom' objects.
GUILayout_xmlHandler::startElement - layout loading has been aborted since no WindowFactory is available for 'WindowsLook/ListboxItemCustom' objects.


media/gui/imagesets/ contain only WindowsLook.imageset and WindowsLook.png doesn't exists anywhere.
Title: Re: Simutrans in 3D
Post by: Markohs on April 05, 2012, 05:12:12 PM
Yep that's because I've tried to upload it to svn and it rejects it, says it has no newline because it expects text, not binaries.

It also doesn't allow me to upload the .ttf. You can dowload here (http://dl.dropbox.com/u/30024783/media.zip).

I plan spending more time with this this week again, I also got a working linux machine to test it there too, so soon I'll make a new release that will hopefully fix those things.
Title: Re: Simutrans in 3D
Post by: prissi on April 05, 2012, 07:23:15 PM
Then set teh appropriate properties for the thing in question. svn propset shoudl do this.
Title: Re: Simutrans in 3D
Post by: Markohs on April 05, 2012, 07:36:02 PM
Tried already to se their mime-tipe to binary, I desisted. :)
Title: Re: Simutrans in 3D
Post by: O01eg on April 05, 2012, 07:52:23 PM
Nice. It starts, loads pak and language but than crashes after "Show banner ... ":

Program received signal SIGSEGV, Segmentation fault.
0x00000000005ab625 in haltestelle_t::reroute_goods (this=0x69a7580, units_remaining=@0x7fffffffb8be) at simhalt.cc:915
915 if(ware.menge==0) {
(gdb) p ware
$1 = (ware_t &) @0x5c00f500709f03: <error reading variable>
(gdb) p j
$2 = 8
(gdb) p *warray
$4 = {data = 0x5c00f500709ea3, size = 14, count = 9}
(gdb) p warray->data[0]
Cannot access memory at address 0x5c00f500709ea3

or

Program received signal SIGSEGV, Segmentation fault.
0x000000000040c9e7 in grund_t::get_weg (this=0x66611d8, typ=track_wt) at bauer/../boden/grund.h:552
552 const waytype_t wt = w->get_waytype();
(gdb) p w
$6 = (weg_t * const) 0x5637dd0

But in boden/wege/weg.h
Code (c++) Select

virtual waytype_t get_waytype() const = 0;
Title: Re: Simutrans in 3D
Post by: Markohs on April 10, 2012, 10:44:04 PM
001eg, I updated svn code to last trunk release, I did do a first test and all looked good so far, it might solve the crash you posted. I'll add more code soon, this past weekend has been busy for me and coudn't spend much time on this. But this weekend I hope to have the time to give it a good push.
Title: Re: Simutrans in 3D
Post by: Ters on June 03, 2012, 03:45:03 PM
I'm not sure this fits here, but as the result might prove useful here eventually (as well as on it's own), here goes:

I got a purer OpenGL version of Simutrans up and running today in a kind of playable state (not bad for two days work). It's an extension of what I and Markohs have done with simsys_opengl.cc into simgraph. I haven't checked if I have reinvented something Markohs has done elsewhere, but the primary thing is that textur is gone. Everything is drawn using OpenGL primitives, though it's still strictly 2D (so no reason for those of you waiting for Simutrans 3D to get exited). To get things running smoothly, I batch both images (including glyphs) and primitives. The last I remember reading from Markohs on rendering Simutrans with the GPU was bad performance from swithing textures all the time. I now stream everything through one 1024x1024 texture.

There is a lot work left to do, since I stripped simgraph almost completely down, so I'm not attaching any code yet. Neither blending (except totally transparent parts of images), zooming or color customization works. Clipping of text does not work on a sub-character level, and some other clipping is missing in the world view (probably that poly clip stuff). I have also noticed that text sometimes get stretched vertically only to pop back into shape shortly after. The batching also has room for optimizations, though I don't experience any performance issues.
Title: Re: Simutrans in 3D
Post by: Markohs on June 03, 2012, 11:32:37 PM
Impresive! But... 1024x1024 can fit all the images? I don't think so. About the text, I thought aproaching that just rendering the UI and the text overlays in one separate layer with the current routines (so, simwin.cc etc, all the GUI just writes to a transparent texture, and you just render it on top later), and the scene on the other. So you just whould render in 4-5 steps, using batching, but that requires making atlas of images of about 1024x1024 or more, with all the possible images.

So it could go:

1) One big batch with all the the "ground, water and slopes, one atlas hereand just one batch.
2) One batch with all the things/dinges/vehicles, using alpha transparencies and z-coords so the image is drawn in just one render operation, this whould reuire of another atlas, with all the buildings/vehives etc, I doubt we can fit all the images on one texture on this step.
3) On this step, we'd just render one quad , with the UI/overlays.

So, 1 frame -> 3 render operation.

My precious aproach was each display_img_aux -> one render operation . All looked good and the render was corrent, but on far zoom levels, gave too low fps, efectivbely as you already menctioned because not having a big texture atlas with all the objects, forced me to just use a render operation for each object, not allwing to bath them on a big batch and just using one texture atlas and offsetting the texture coords.
Title: Re: Simutrans in 3D
Post by: Markohs on June 03, 2012, 11:40:14 PM
Quote from: Ters on June 03, 2012, 03:45:03 PM
There is a lot work left to do, since I stripped simgraph almost completely down, so I'm not attaching any code yet. Neither blending (except totally transparent parts of images), zooming or color customization works. Clipping of text does not work on a sub-character level, and some other clipping is missing in the world view (probably that poly clip stuff). I have also noticed that text sometimes get stretched vertically only to pop back into shape shortly after. The batching also has room for optimizations, though I don't experience any performance issues.

My implementation can be found in simsys_ogre.cc but it's at I think broken, it's very similar of what you menction.

About player colours, the lack of dr_textor utility, I faced the same problems. what I did is generating a PF_A1R5G6B5 image for each image registered in if I recall correctly simgraph16.cc, and render the things with the aid of sim3d/ogre2d-main.cc, that used hardware vertex buffers, on ogre, so it can work on direct3D, I guess you have a similar aproach.

One thing that I thought too was trying to make at elast some parts of those vertex buffers persistant on each frame, saving lots of CPU so they don't have to be filled each frame. on the svn you can find all the code I made. I'm very happy seeing you progressing on this, atm I don't have much time to spend on this project until I solve some thing in real life, but I hope being able to spend time on this in a few months, or the summer. I'd also love to hear of your progress or discussing whatever you find interesting here. :)

I also moved simgraph16.cc to simgraphogre.cc to not polute the common file, iirc.

Other project you might be interested is replacing the ground code with a 3D render of ground, my previous aproach was using Ogre Terrain Manager, bu I faced memory usage problems, since the game on maps close to 2000x2000 tiles memory consumtion aproached 2Gb, what's nto acceptable on 32-bit systems. So the way to go was keep using that aproach but swap the map in a file and page the zones of the map required, or implementing a map vertex/texture manager ad-hoc for simutrans, fine-graining to our needs. On the last weeks I was pretty sure the only viable option is the second one.

Also, to note, that if you are to mix a real 3d object to the scene, I think the only solution is using a non-perspective camera, a ortho one.
Title: Re: Simutrans in 3D
Post by: Ters on June 04, 2012, 05:01:32 AM
Not all images fit in the 1024x1024 texture. (It can actually be smaller if the system doesn't support that size. Larger just made performance worse.) When image drawing calls come in to the render queue, the image is added to that texture if it's not already there. When there is no more room in the texture, it and all batched up rendering commands are sent to the graphics card. I haven't done any statistics yet on how often this happens during a frame, or how full the texture really gets, but I did once record that one batch contained about two thousand quads. That was when the game was running in a small window with the default map shown before loading or starting a game.

I have no intention of changing rendering into phases at the moment. That would involve going beyond simgraph and simsys. My goal at the moment is this streaming texture thing.
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2012, 08:21:41 AM
that's a very interesting approach, and very in line with the previous implementation of simsys_opengl, but I think it will suffer from performance issues because it puts much stress in the AGP/PCIe bus since you are creating let's say 2 or 3 textures each frame and you don't re-use them after, so most of the time is spent transfering from the system memory to the videocard memory.

I hope you prove me wrong, but I *think* that solution won't scale good, since relies too much on system bandwith, if you say you get poorer performance using let's say a 2048x2048 texture than a 1024x1024 it might be that maybe all the frame whould fit in a 2048x1024 texture, and the rest of the texture image is wasted on empty spaces at the end, so all that memory transfer was not needed and it's waste. Also, an algorithm that doesn't waste much space is needed, using as low CPU as possible. That's necessary since all images have different sizes, and just positioning the images in a grid fashion whould render many empty spaces, wasting GPU memory and system bandwidth.

One of the posible solutions to aleviate this, and I guess you might be doing this already is defering the frame rendering one frame and using PBO's, hardware pixel buffers and transfering the pixels in a background non-CPU dependant DMA process ( http://www.songho.ca/opengl/gl_pbo.html (http://www.songho.ca/opengl/gl_pbo.html) ). So on a frame, using double pixelbuffer, you just trigger the render of the previous frame, and start filing the texture of the next frame, so when the time to render a new frame, they are already filled you you don't waste CPU time and the render operation is asynchonous.

But a definitive implementation I think it should be one of:

1) creating textures with all the game images, and re-use them each frame, since you got a z-buffer working, you can just batch the geometry by wich texture it belongs to and render the whole image in 2-3 render operations, if the images overlap, the hardware zbuffer will do the clipping antumatically for you.
  you can posibly group the texture atlases by category as I menctioned earlier but I'm not sure it will have advantages.

2) Same as 1) But generating the texture atlases statically with the pak creation tools and writing them as .png and just load to videocard on pak selection, that might allow for a more cpu-costly image composition algorithm, that will generate a image with less "holes". iirc pak128 had about 50K images. We might need to modify the pak creation tools.

We can maybe use this NVIDIA tool that does exactly that (Texture Atlas Tools):

http://developer.nvidia.com/legacy-texture-tools (http://developer.nvidia.com/legacy-texture-tools)

I think the key to having a good implementation, with just optimal framerate is re-using the texture atlases, and not stream them each frame. But if this streaming option you are developing has good performance, you are already proving me wrong. :)
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2012, 09:44:58 AM
I have been thinking a bit more over this while having the coffe and while the z-buffer will sort the clipping, having like we have partially transparent images, it's mandatory we have to respect some order in the drawing. it whould need some tweaking in simworld.cc iirc to make sure that for example the order is something similar to:

1) ground
2) fundaments
3) vehicles
4) buildings and overlays.

yep, it's more work but the current drawing algorithm is more or less suitable to our needs, so we might not need to touch much, just some way of comunication between simworld.cc and simgraph.cc to signal when each batch is finished and trigger de batch render operations. But anyway, if your current streaming algorithm is working good so far, I'd personally like to see it finished, see how it's working and modify it later, improving it with whatever techniques we find necessary.

Good work, Ters!
Title: Re: Simutrans in 3D
Post by: Ters on June 04, 2012, 03:48:54 PM
I just did a quick test, and with a reasonable well developed pak64 city maximized on a 1920x1080 screen, it rendered everything in just two batches. If I were not using 32-bit texture just because it's easier, that would have been roughly the same amount of IO to video memory as the current simsys_opengl.
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2012, 04:09:56 PM
Maybe you can test a 2048x1024 texture, and see if it's just one batch, and if the fps get way higher.

Anyway, it will be way faster than my version, where I did about 20.000 renderops per frame, your version will do 2-3 renders per frame. I'd like to have a look to your code when you have the time and will to show it, to commit to svn, do some cleanup, document, and improving it when and where we can. :) Like we did with the previous version.
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2012, 04:54:29 PM
By the way, about the fps you are getting now, is there a improvement in fps compared to the current simsys_opengl ?
Title: Re: Simutrans in 3D
Post by: Ters on June 04, 2012, 07:16:45 PM
The debug build reaches 25 fps even when maximized, at which point Simutrans doesn't appear to go any higher. CPU usage is about the same as the optimized SDL version. Opening a window with graphs sent the fps plummeting, though, as I can't integrate the line rendering into the quad rendering. If Simutrans alternately draws the graph lines and the squares on them, my renderqueue will switch in and out of batching mode, uploading a big texture with almost nothing in it everytime it switches out.

I got outline blending and zooming working today without having to do much, but I'm getting bothered by the amount of state I have to send from simgraph to my renderqueue. Outline rendering requires an extra square in the texture, but zooming just scales on the GPU during rendering. The texture is populated directly from the run-length encoded image in bild_t.

Progress will likely be slower during the week, as work consumes most of my energy.
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2012, 07:57:52 PM
The UI shoudn't bother you much, we can allways use the current UI routines to write in a different pixelbuffer and blend with the rest of the scene, imo, should be easier.

I'd just focus on the map rendering, forget about the UI. I can work out the UI code for that if you want so you can focus on the map, but as you wish. :)
Title: Re: Simutrans in 3D
Post by: Markohs on June 04, 2012, 10:03:26 PM
 And about the outline blending, I guess you refer to the station signs, coverage and busy bars, the overlays, that can also be handled separately in another layer.

That layer has also the advantage it doesn't have to be updated every frame, for example station coverage can be implemented as a solid semi-transparent quad (not requiring a texture), even playing with the color tones to have some kind of degradation pattern. It can also be be persistentplaying with vertex buffers I think, only being updated on map moving or some  puntual events, saving further CPU cycles/bandwidth.
Title: Re: Simutrans in 3D
Post by: Ters on June 05, 2012, 04:49:34 AM
As far as I can tell, simgraph just receives a bunch of draw this and draw that calls. It has no idea where the calls are coming from or what they are for. I have no intention of doing anything beyond simgraph and simsys for this little project, which is independent of, but might benefit, Simutrans 3D and/or Simutrans CEGUI. It might also be a dead end.

Blending is used for, but may not be limited to: Aircraft shadows, transparent buildings (the alternative to hidden), tile under cursor, selected tool button, reserved tiles (I think) and waypoint markers (looks a lot like reserved tiles). The first two can't be done without using a texture generated from bild_t. The other just tag along for the ride and don't use much space in the texture. I'm not sure simgraph can tell the difference reliably. Of the two blending types, I have only implemented outline blending. The other is recode blending, but I'm not sure what uses what, because everything looks OK with just outline blending.
Title: Re: Simutrans in 3D
Post by: Markohs on June 05, 2012, 07:11:39 AM
ok, perfect.

about the recode blend, might be refered to recolor images to player colors maybe, trains, stations etc?
Title: Re: Simutrans in 3D
Post by: Ters on June 05, 2012, 05:43:06 PM
The term recode is used for that too, but this recode blend thing seems to be normal blending. While outline blending blends a constant color with the destination color, but only where the image is opaque, recode blending blends the color from the image with the destination color.
Title: Re: Simutrans in 3D
Post by: kierongreen on June 05, 2012, 05:51:09 PM
I'm not sure how much if at all the recode blend routines are used as the outline ones were quicker, and also looked better for the places blending was added to.
Title: Re: Simutrans in 3D
Post by: Markohs on June 05, 2012, 05:53:58 PM
it might be the new code prissi and yorkeiser added to the new map window lines, I can't recall it being used anyere else.
Title: Re: Simutrans in 3D
Post by: Yona-TYT on June 06, 2012, 01:34:01 AM
I see that the project is very active
But so I read some administrators do not want to collaborate on this project and I am surprised
so I offer my humble collaboration

I thought of a page on facebook "3D simutrans http://www.facebook.com/Simutrans.3D" locate me to add them as administrators

salutations
Title: Re: Simutrans in 3D
Post by: Markohs on June 06, 2012, 07:57:41 AM
Quote from: tadeoadeo on June 06, 2012, 01:34:01 AM
I see that the project is very active

It's alive, but not *very* active since my personal time doesn't allow me  so for some months.

Quote from: tadeoadeo on June 06, 2012, 01:34:01 AM
But so I read some administrators do not want to collaborate on this project and I am surprised

No that's not true, many of the developers, specially prissi/Dwachs have helped me a lot giving my their opinion and help understanding/planning the code. Other administrator have stated they like this project and give their support (still only moral :) ) They are not simutrans3d developers, but have been very helpful.

It's been some time I'm on this, but takes time to understand the simutrans inner parts, and every time I understand something, I have to sometimes reconsiderate parts of my previous work. So it's going slowly, but I'm sure we'll have something good enough to be played someday.

Quote from: tadeoadeo on June 06, 2012, 01:34:01 AM
so I offer my humble collaboration

Oh, great! I first need to know what can you help in, so we can get an area you can submit to.

So:

- you have knowledge of blender or 3d modeling?
- can you write C++ code?
- do you have experience in 2d bitmap creating?

There are lots of areas we could use a helping hand, did you had something in mind?

Quote from: tadeoadeo on June 06, 2012, 01:34:01 AM
I thought of a page on facebook "3D simutrans http://www.facebook.com/Simutrans.3D (http://www.facebook.com/Simutrans.3D)" locate me to add them as administrators

It's a bit soon to open a page like that since the version is still on its infancy, and it's not easy to colaborate to the project since we don't have much idea yet of what's missing and how will it be done.
Title: Re: Simutrans in 3D
Post by: Yona-TYT on June 06, 2012, 06:50:00 PM
-I think I'm wrong with managers have given a great contribution to this project my apologies
Title: Re: Simutrans in 3D
Post by: Ters on June 08, 2012, 05:50:33 PM
I just realized that when zooming far out, the data that must be sent to VRAM just for the vertices might be more than the size of the frame buffer.
Title: Re: Simutrans in 3D
Post by: Markohs on June 08, 2012, 07:54:23 PM
yes you are right, plus the texture transfer. but there are lots of ways we can work around that on the future, once your code is working. I'd just stick to your plan, we'll optimize it later. we'll need to create  persistent geometry for sure.
Title: Re: Simutrans in 3D
Post by: Ters on June 12, 2012, 05:23:03 PM
Here's what I've done so far. simgraphgl.cc and simsys_opengl2.cc replaces corresponding files. Requirements should be the same as for simsys_opengl.cc.
Things that don't work are (I may have forgotten something):Separating GUI rendering from world rendering is probably the next step to take in order to take advantage of the GPU. I'm not taking upon myself to do that, at least not now.
Title: Re: Simutrans in 3D
Post by: Markohs on June 12, 2012, 09:16:31 PM
Thanks for sharing your work, I'll take it as a base to the implementation, improving where it's possible. :)

Thank you for your work!
Title: Re: Simutrans in 3D
Post by: IgorEliezer on June 12, 2012, 09:24:40 PM
My congratulations for the valuable effort. :)
Title: Re: Simutrans in 3D
Post by: Yona-TYT on June 13, 2012, 12:43:06 AM
I hope this project to proceed
congratulations
Title: Re: Simutrans in 3D
Post by: Markohs on October 23, 2012, 11:18:50 PM
Just compiled your code Ters and it's working.

Your work it's quite impressive, will take me some time to understand all, but I got the general idea, thank you!

I'm getting heap corruptions,segmentation faults and some unexpected behaviour but I'll fix it, I guess most of the problems come from the code that changed in trunk since you made the patch. Maybe it's my videocard that has some different parameters than  yours also and behaves a bit different. Wich vcard brand did you had? A nVidia Geforce 9700 GTX here.

All the things that are not implemented are easy to fix or not really much important and have a workaround.

As you posted already the graph code needs quite a lot of rework.

I'll try to group pak images in texture groups, should boost performance. The GUI is atm a big problem, I think I'll just make it write to a transparent buffer with current routines so I don't have to modify much and overlay it over the screen each frame, we can allways rework it deeper in the future, not worth to spend much time on that.

Another idea is makig persistent vertex buffers for static images and just update those buffers.

Well, thx a lot for your code, I'll get my hands on it.
Title: Re: Simutrans in 3D
Post by: Ters on October 24, 2012, 04:43:32 AM
My latest stunt has been to use Ogre3d as a back-end and draw Simutrans using present methods into an overlay with 50% transparency. The goal is then to render the landscape using 3D drawing commands behind that, so that the two scenes match up. But synchronizing the movement of the two viewports turned out to be unexpectedly difficult. (And OIS isn't exactly the ideal input library.)
Title: Re: Simutrans in 3D
Post by: Markohs on October 24, 2012, 07:20:26 AM
how did you implemented that landscape, with manualobjects? i had lots of problems with ois too
Title: Re: Simutrans in 3D
Post by: Ters on October 24, 2012, 04:57:11 PM
It's a single manualobject at the moment. It's not even based on the actual landscape, except for sizes. Just a simple grid to see if I got the synchronized scrolling working. The intention is to eventually make a manualobject (or some other entity) out of a X times X block of tiles, possibly along with certain fixed objects, but it's a long way to go and I'm not always moving.
Title: Re: Simutrans in 3D
Post by: Markohs on October 24, 2012, 05:12:10 PM
ok, great. I'll focus on the texture atlas and current "sprite" drawing, we'll need it anyway and it needs to be fast.
Title: Re: Simutrans in 3D
Post by: Ters on October 24, 2012, 05:34:40 PM
It is possible that it would be faster if animations were in a separate texture and then update the texture with different frames, or cycle through different textures, rather than change the texture coordinates in the mesh. Especially when all objects with the same animation show the same frame at the same time.
Title: Re: Simutrans in 3D
Post by: Yona-TYT on October 25, 2012, 12:14:07 AM

is good to know that the work continues :D :D :D :D
always attentive. greetings ¡¡¡¡ Yona (yonatan.el.amigo@gmail.com)
Title: Re: Simutrans in 3D
Post by: Roads on October 25, 2012, 02:54:27 AM
Just want to say I found this thread only last night and have read it.  Markohs you have been a trooper to say the least, showing great resolve in sticking to this project.  It is good to see others who can do have joined you - I only wish I could be one of them.

I'm wondering if...now that we have bigger and wider monitors, thinking this would make it more acceptable...if the scale of the buildings was increased...if that would increase performance significantly?


Modify:  The other thing I was wondering about...
At some point you mentioned it would be good if sometime we could actually go to street level.  Would it be possible to put the horse before the cart here and have Simutrans 3D  at street level or some zoom fairly close to that and then 2D zoomed out.  I'm thinking much like the mini map in the corner of the screen?
Title: Re: Simutrans in 3D
Post by: Ters on October 25, 2012, 04:34:55 AM
I'll tell what I'm thinking, which may or may not be what Markohs is thinking.

Quote from: Roads on October 25, 2012, 02:54:27 AM
I'm wondering if...now that we have bigger and wider monitors, thinking this would make it more acceptable...if the scale of the buildings was increased...if that would increase performance significantly?
I guess a little, but not much. Besides, I want a bigger world with more buildings, vehicles and other stuff, not pak256.

Quote from: Roads on October 25, 2012, 02:54:27 AM
Would it be possible to put the horse before the cart here and have Simutrans 3D  at street level or some zoom fairly close to that and then 2D zoomed out.  I'm thinking much like the mini map in the corner of the screen?
The main view will be 3D in some way always. Simutrans is in many ways 3D as it is. Perspective projection for street level and orhtographic projection for overhead views is something I've been thinking a little about, but I'm not sure how one would transition between them.
Title: Re: Simutrans in 3D
Post by: Roads on October 25, 2012, 11:02:16 AM
Ters,

Until your post I had not even considered the idea of people wanting to see more on the screen.  Maybe we are all different in what we want.  Perhaps there is a way to satisfy everyone.  Even the mini map is not adequate for very large maps.  What if we had three types of maps - all resizable and all with different levels of zoom?  That way you could see your entire map on the mini map, you could see a great deal of "stuff" in 2D zoom and with 3D zoom you could see such things as:

a train coming around a mountain to the valley below
people milling about in a train station, some lined up waiting to board a train
old men sitting on a bench outside smoking a pipe
a small pond with cattails and ducks flyin up into the sky as a truck passed on a nearby road 
Title: Re: Simutrans in 3D
Post by: Markohs on October 25, 2012, 11:35:15 AM
Glad to have time for this again. :)

About the animated textures, yes, will do it that way.

About ters comments:

Building scale makes not really a difference, it just will need more (videocard) memory, and in theory less items will be displayed each tame (less will fit), that might improve performance a bit, but it's not really important, because GPU processors are designed to deal with immense number of objects. A normal (cheap) GPU can draw around 1.000 million polygons per second, at 30 fps that means about 33'3 million polygons per frame more or less.

Abou the camera placement, the normal way is just a isometric projection, that will look exactly as current images in simutrans look. We can do some expansions later to see the world in projection cameras, but that will force us to get rid of all 2D images, or things won't really look good enough.

It's the memory of the vcard that uses to put the limit, and taking into account that changing textures is a function that really hits down performance, the idea is having less images, and re-use them often. Or optimizing the texture atlas with wise manual placement so more images fit on them.

EDIT: Reading your post, what you are describing is called Level Of Detail (LOD) (http://en.wikipedia.org/wiki/Level_of_detail). The closer we are from the oject, we'll see more details, when far away they will just show up, often as a 2D sprite.

Anyway we are still far from that, first we have to make a version that displays equal to current simutrans, and requiring less CPU. From that, we'll add more things to the mix.
Title: Re: Simutrans in 3D
Post by: Roads on October 25, 2012, 12:42:57 PM
I may be a child here bugging the adults with chatter and questions that is just an annoyance.  If this is true please say so and from now on I'll just watch the progress silently.

Early in the thread I googled LOD so I do know what it means.  Prissi said at some point that you couldn't simply display images from Blender because there would be far too many vertices for the computer to handle.  Prissi, I apologize if I misunderstood what you said.  If not then that was my thinking on the 2D window, that you couldn't simply zoom out enough in 3D to give a view of the game large enough for doing things like laying down roads, railroad tracks or just the view that some prefer and all of us at times need.
Title: Re: Simutrans in 3D
Post by: Markohs on October 25, 2012, 01:19:54 PM
Quote from: Roads on October 25, 2012, 12:42:57 PM
I may be a child here bugging the adults with chatter and questions that is just an annoyance.  If this is true please say so and from now on I'll just watch the progress silently.

No worries Ters, it's allways good hearing all oppinions. :)

Quote
Early in the thread I googled LOD so I do know what it means.  Prissi said at some point that you couldn't simply display images from Blender because there would be far too many vertices for the computer to handle.  Prissi, I apologize if I misunderstood what you said.  If not then that was my thinking on the 2D window, that you couldn't simply zoom out enough in 3D to give a view of the game large enough for doing things like laying down roads, railroad tracks or just the view that some prefer and all of us at times need.

I don't know the exact details of how will be developed, still. We'll see. :)
Title: Re: Simutrans in 3D
Post by: Markohs on October 25, 2012, 05:14:56 PM
Ters, why not using > 1024 textures? Just curious. renderqueue.cc

Quote
   texture_size = min(dr_get_max_texture_size() / 2, 1024); // Avoid too large texture
Title: Re: Simutrans in 3D
Post by: Ters on October 25, 2012, 05:25:37 PM
It was slower.
Title: Re: Simutrans in 3D
Post by: Markohs on October 26, 2012, 01:06:52 AM
Okay the segfaults I was getting were coming from the multithreaded code, this code is not thread safe, not STL nor the algorithms themselves. I'm still unsecure of separating all the GUI draws from the rest, your solution works quite good, but maybe it will be better to split the GUI framebuffer. Anyway all the code will be useful.

Your code has been an interesting read, I like your way of thinking. :)
Title: Re: Simutrans in 3D
Post by: Ters on October 26, 2012, 04:38:38 AM
There is no way of, or no point in, multithreading the rendering when doing it with OpenGL. I completely disregard it, or even remove it, when doing these things. Some of the thread stuff I saw looked rather shaky, at least at a glance.
Title: Re: Simutrans in 3D
Post by: Markohs on October 26, 2012, 09:44:31 PM
If somebody wants to try Ters version, I compiled a version, you can get here (https://dl.dropbox.com/u/30024783/st/SDL.zip). I activated linear filtering of textures, so on zoom levels all graphics are a bit anti-aliased. You might need to install C++ redistributable (http://www.microsoft.com/es-es/download/details.aspx?id=5555) too.

We know it has rendering problems and works too slow very far zoom levels.
Title: Re: Simutrans in 3D
Post by: Roads on October 27, 2012, 12:24:53 AM
Put the compiled version in my Simutrans directory (the one with ver 111.3), started a new game and it ran fine.  The only thing I noticed was there were no maps to choose from and my mini map was just a solid blue color.  I do not have C++ installed.  At one time I did install it but removed it.  Still, you know how Windows does stuff, often when you remove an application it doesn't remove all the files so maybe some of the files this needed is still there. 
Title: Re: Simutrans in 3D
Post by: Markohs on October 27, 2012, 12:41:05 AM
Yea, known problems. Minimap and some other things are not implemented still. Did you tried to start a new game and zoom in and out to see how graphics are scaled compared with current simutrans?
Title: Re: Simutrans in 3D
Post by: Lmallet on October 27, 2012, 01:38:36 AM
Woah, the zooming is quite something.  Pak64 looks pretty good in this version.
Title: Re: Simutrans in 3D
Post by: Roads on October 27, 2012, 01:39:20 AM
I did start a new game with an empty map.  I switched to Public Player and created a city - this is how I usually do new games.  I should not have said there were no maps.  There certainly were you just could not see them in the little picture when starting a new game.

I did not try zoom or loading a saved game.  I'll do that sometime tonight as I don't have time right now.


Modify:  After seeing Lmallet's comment I had to try loading a saved game and zooming.  WOW!  WOW!  WOW!  I guess you can ascertain from this I really like it!  At max zoom in it still looked good.  I could even see the stripes on the train engine!  8)
Title: Re: Simutrans in 3D
Post by: Fabio on October 27, 2012, 04:52:40 PM
So I guess (hope) also 2D paksets will benefit from this OpenGL port?

I'm too fond of our 2D artwork paksets (and too involved as well) to want to lose them to the 3D mode...
Title: Re: Simutrans in 3D
Post by: Ters on October 27, 2012, 06:09:12 PM
There is a significant difference between an OpenGL port and 3D mode, at least in the way I would use the terms. The OpenGL porting I've been doing is no more 3D than Simutrans is today. But for 3D mode, every piece of graphics has to be redone except GUI elements, ground textures and smoke.
Title: Re: Simutrans in 3D
Post by: Fabio on October 27, 2012, 06:15:15 PM
So the thread title is misleading, or at least incomplete ;)

The current project, if I understood correctly, will enhance present Simutrans, improving the display routines and possibly the GUI.

Thanks for the explanation, this is something I'm looking forward to.
Title: Re: Simutrans in 3D
Post by: Markohs on October 27, 2012, 06:30:16 PM
yeah, the current goal is displaying the game using OpenGL, wich means mostly hw-accelerated. it will prolly include new visual effects. full 3d will come later.
Title: Re: Simutrans in 3D
Post by: Fabio on October 27, 2012, 06:33:28 PM
Quote from: Markohs on October 27, 2012, 06:30:16 PM
yeah, the current goal is displaying the game using OpenGL, wich means mostly hw-accelerated. it will prolly include new visual effects.
Great! :thumbsup:

Quote from: Markohs on October 27, 2012, 06:30:16 PM
full 3d will come later.
I hope it won't ;)
Title: Re: Simutrans in 3D
Post by: Roads on October 27, 2012, 06:40:21 PM
Perhaps 3D doesn't have to replace 2D anymore than pak128 replaced pak64...
Title: Re: Simutrans in 3D
Post by: Markohs on October 27, 2012, 07:02:44 PM
we'll see how this develops, my idea is getting to the point the opengl backend ouperforms the current ones, making it the prefered by the community. next step is implementing features unique to it too (like 32-bits rgba images plus extra masked effects, smooth animated zoom, image blending...). next step is making mixing 2d and 3d like sim city 4 does. Thr idea is giving the pak mantainers full ammo to make whatever they decide it's better. we're programmers, not artists after all.
Title: Re: Simutrans in 3D
Post by: Ters on October 27, 2012, 07:11:01 PM
For practical reasons, pak sets will have to go fully 3D before Simutrans itself can go fully 3D (free moving camera). It is possible that Simutrans will branch at this point, as keeping support for both 2D (especially with 2D pak sets) and full 3D in the same code base can be too unwieldly. But that's far off into the future considering where we are today.
Title: Re: Simutrans in 3D
Post by: Markohs on October 28, 2012, 11:16:42 AM
To solve the fps issue on the zoom out I only see one option, generating a vertex and geometry buffer in the GPU and update it each frame on the items that changed only, that includes:

- Objects that moved
- Objects that appeared/disapeared
- Animated textures

I guess the easiest way of implementing this is some type of dirty image managing system. I'm also unsure if we can manage to map the whole map in this buffer or we have to just map the viewable part of the world.

Some effects can be managed teh same way we do now, smoke for example, can be just drawn manually.
Title: Re: Simutrans in 3D
Post by: Ters on October 28, 2012, 11:57:22 AM
Quote from: Markohs on October 28, 2012, 11:16:42 AM
To solve the fps issue on the zoom out I only see one option, generating a vertex and geometry buffer in the GPU and update it each frame on the items that changed only

That's my plan, at least for terrain and buildings since they rarely change, but it requires tracking down and hooking into all places where changes to these are done. Ideally, I want to do this by making it possible for a renderer to register a listener with the world class. When the renderer gets notified of a change to the world, it would regenerate the affected batch(es). Each batch could also be clipped against the viewport when rendering.

Moving stuff like vehicles and smoke would get their geometries regenerated each frame as long as the graphics stay 2D. I don't think there is much to save on vehicles standing still for a moment.
Title: Re: Simutrans in 3D
Post by: Markohs on October 28, 2012, 12:20:15 PM
how about just marking those objects dirty on modification and keep a deleted items list? that whould allow to use almost the same routines that already exists
Title: Re: Simutrans in 3D
Post by: Ters on October 28, 2012, 01:43:47 PM
Which objects? Considering vehicles will be put together in one (or few) big buffer(s), it might be just as quick, or quicker, to recreate the entire buffer as it is to update those elements that changed, which probably is most of them anyway.

In any case, it will require experimentation and profiling to find the best solution, and I'd rather start with what's easiest to implement. I've already done the recreate all geometry every frame solution, which was too slow, and keeping the landscape in buffers from frame to frame seems like the next logical step.
Title: Re: Simutrans in 3D
Post by: Markohs on October 28, 2012, 07:06:50 PM
Well, you are right, then we can keep at least 2 mostly-static buffer, one with the landscape (can be made write_only, this is easy to manage) and another with buildings/ways/trees. Rest of sprites can be redrawn each frame, yes. What I was refering to as "objects" is the class "ding_t", extending it to manage "dirty", as meaning "I have changed my display image(s) since the last time you asked me about it".

Making some experiments about this now.

The thing that's going to change is that we need to update the camera position now, since it's not going to be a normalized identity projection as it is now, at elast for the static geometry layers (landscape and buildings).

Another problematic thinig are going to be animated textures (like water), where we'll need to update each sprite u and v, each frame for each of them, no? Even if I got one texture with all the animation steps, I need to update those values, or is there a better way of handling this?
Title: Re: Simutrans in 3D
Post by: Fabio on October 28, 2012, 07:25:43 PM
Water could have a different approach altogether. One static layer filled with texture and another layer with the same texture, 25% opaque (transparency 75%), moving one px downwards each frame, both clipped to the water boundaries. This is what I did for Pak 128 oceans.
Translating a whole layer would indeed only need to crop one line at the bottom and put it at the top each frame and the effect is quite realistic.
Title: Re: Simutrans in 3D
Post by: ӔO on October 28, 2012, 08:01:52 PM
For water, why not do them in 3D? If the polygon count is kept low, then it shouldn't impact performance too badly, would it?
I have seen that it was possible to animate some simple waves in blender.
Title: Re: Simutrans in 3D
Post by: Ters on October 28, 2012, 08:05:32 PM
Water is a very different animation from the others. I wouldn't worry much about it at the moment. As for the other animations, I still think what I proposed earlier might work.

I've finally gotten my Ogre landscape to match the position and movement of the landscape as rendered by the current graphics system. The next step will be to try and make clean interfaces between karte_ansicht_t, karte_t and the Ogre renderer. Currently, there are Ogre calls scattered through simview.cc. But C++ coding isn't as fun as Java coding, at least with the tools I have.
Title: Re: Simutrans in 3D
Post by: Markohs on October 28, 2012, 09:10:59 PM
I see you are pretty active coding, why don't we make a TODO list and assign each other tasks so we don't write code about the same thing? We can maybe give you access to the svn so you can upload to the branch freely and we can see each other code easily? What do you think
Title: Re: Simutrans in 3D
Post by: Ters on October 28, 2012, 09:24:46 PM
I've spent a few hours this week, and then nothing before that for a long long time. I won't commit myself to anything when my motivation is so random.
Title: Re: Simutrans in 3D
Post by: Markohs on October 28, 2012, 09:28:09 PM
 I can understand that, Ters, but this is not a contract. As long as you feel like contributing, it's easier to keep our work synced if you commit to the branch svn. It even makes possible you to commit to the simutrans trunk when you feel like that. Prissi pointed it in Programmer's Corner a few weeks ago, even.

Well, up to you. Anyway if you feel you have new interesting code, I'd appreciate you to share it to me somehow like you already did various times in the past. :)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on October 29, 2012, 05:52:40 PM
With heightmaps, climates, shore, transitions... pak128 gives after grund_besch_t::calc_water_level 216 tile variations. Will be impossible to fit all of them on a 1024x1024 texture atlas, that can fit 64 images at most, dunno if all vcards support 2048x2048. And that only includes basic tiles, water animation will have to go in another texture.

Also, if we want to use GL_LINEAR interpolation we have to have a 1 pixel fully transparent border around the image I think to avoid the sampler to mix some colour of the neighbour images.

I'll make some experiments with bump mapping and lighting, to see if we can achieve similar results to the one simutrans greates, it can even maybe be useful for water.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Ters on October 29, 2012, 09:09:44 PM
I've been contemplating doing blending between texture levels in hardware, though I haven't checked if it's doable without pixel shaders.

As for the bleeding at the edges, I think the solution is to offset the texture coordinates a little. I thought I did so in my demo/test. With mipmaps, there will be additional constraints. Adding a transparent border will cause bleeding into transparency rather than the next image, which isn't good for ground textures. Repeating the row and column on the opposite side of the image would work there.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: prissi on October 29, 2012, 09:38:47 PM
Any object that has been modified has the dirty flag set. Unfourtunately objects that are modified heeds to trigger redraws of larger areas. That is why we made so much effort with the dirty tile buffer.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on October 29, 2012, 11:02:44 PM
@Ters: Yeah, maybe just offsetting will be enough, write the 128x128 tiles and just render the inner 126x126, so they overlap a bit might work, I'll test it. Anyway we can allways CLAMP as you did and wait for a complete 3D terrain render on the future that will look afc better.

@prissi: I'll have it a look. I guess you refer to ding_t::flags bit 1? Does grund_t::flags dirty *ONLY* refer to the ground or includes buildings and ways over it?
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: prissi on October 30, 2012, 10:19:20 PM
dirty gound means everything on it is dirty. Well and dirty things are dirty. Both are resetted during redraw.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on October 30, 2012, 10:33:29 PM
Ok, thank you prissi.

Just posting this, I know some people in the forum like to see some images of work in progress. ;)

Debugging that window, requires FOUR 1024x1024 texture atlas to be drawn each frame, Ters code creates those on-the-fly, posting them:

pak64 behaves better with this backend, because more images fit in each atlas. The current plan is making those atlas persistant in the video card memory and re-use them, saving bandwidth between the CPU and the video card.

in-game:

(https://dl.dropbox.com/u/30024783/debug/Untitled.png)

tex 1

(https://dl.dropbox.com/u/30024783/debug/texture_1.png)

tex 2:

(https://dl.dropbox.com/u/30024783/debug/texture_2.png)

tex 3:

(https://dl.dropbox.com/u/30024783/debug/texture_3.png)

tex 4:

(https://dl.dropbox.com/u/30024783/debug/texture_4.png)



Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 14, 2012, 01:01:36 AM
Making some tests I saw something I don't understand fully so I'll ask here for the case somebody knows.

I made atlas images form all the images generated in grund_besch_t::calc_water_level, and everything is going good, but on the pak128 atlas some dark tiles are generated (on the lower right of the image) and I can't figure out where are then used in, I raised one mountain in-game and can't see them really used anywere. Are they necessary? Do they come from an unused climate?

PAK128

(https://dl.dropbox.com/u/30024783/st/texture_textureatlas128.png)

PAK64:

(https://dl.dropbox.com/u/30024783/st/texture_textureatlas64.png)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Dwachs on November 14, 2012, 07:44:13 AM
Both atlases have the same number of images, so nothing seems to be wrong. Maybe you did not raise the mountain high enough?

There is a debug message at grund_besch_t::calc_water_level, line 444, which should tell you, which climate is present at which height.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: VS on November 14, 2012, 09:49:31 AM
It is climate "rocky", which is usually so high that it is covered with snow even in summer. Mind your snowline settings :) Further, game starts in January, which is definitely winter. Fast forward to July, any you may actually see something ;)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 14, 2012, 09:51:41 AM
Thanks! :)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 14, 2012, 03:23:29 PM
Forcing a 8192x8192 resident texture buffer and using your algorithm Ters, modified to re-use the same buffer each frame (only rebuilding it if it's completely full) and just mapping/unmapping if there is any change that frame, I got a quite significant performance boost, now you can use it completely zoomed out at a similar speed than the SDL version.

The texture corrupts itself in some strange way I could not identify still (I must have made an error somewere, on it), it looks funny:


(https://dl.dropbox.com/u/30024783/Untitled31.png)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: VS on November 14, 2012, 03:34:45 PM
Ghost forest :O
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 14, 2012, 03:49:03 PM
Quote from: VS on November 14, 2012, 03:34:45 PM
Ghost forest :O

;D
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Ters on November 14, 2012, 04:23:06 PM
I just wonder if that texture might be too big for Simutrans players' hardware.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 14, 2012, 04:29:03 PM
I'll just let it use the biggest one he can use.

Well, I fixed the bug, did some tests. I was too optimistic. We were at 0,3 fps at max zoom out (more or less), we have 3 fps now with this implementation in the same situation. WinGDI gives 22 fps. This buffered texture display will be used in some things I think, mainly the GUI and maybe smokes and something else, we'll see.

Well, we improved 1000%, it's a start.

Next thing, static geometry buffers, working on it...
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 20, 2012, 12:14:51 AM
Can anybody explain me why when drawing the landscape certain grunds are not drawn and are drawn later as dings? Why is this necessary? In the example I post here, whoudn't just draw them in this same pass render the exact same result?

The items are processed in rows, so why this objects are treated and drawn later?

Thank you!

(https://dl.dropbox.com/u/30024783/Untitled33.png)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 20, 2012, 12:32:01 AM
mmm... I think I understand why this happens, it's because of vehicles or pedestrians that need to be rendered too (later) and might become partially visible because of images that get extra heigh like that factory? That whould make sense since we don't have any z-buffer here, no? And slopes are affected too since they also can have the same effect (they can hide objects that are in the rear, but only slopes that go upwards, the ones going south don't force drawing as ding)?
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Dwachs on November 20, 2012, 06:20:57 AM
Quote from: Markohs on November 20, 2012, 12:14:51 AM
The items are processed in rows, so why this objects are treated and drawn later?
For the first row of images it seems that this is not necessary. Could be room for optimization. (Also in the second row, too many tiles are drawn later imho)

In general, tiles are drawn later if tile graphics and/or vertical walls have to cover something on the tiles behind. Then there are bridge heads, which also are sometimes drawn differently. And there can be ways that carry a flag to trigger this behavior (used with rivers sometimes?).
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 20, 2012, 10:07:49 AM
 Thanks for the explanation, reading the code now. :) Yea, I *think^there are a few cases when display as ding is not 100% needed, and it's not allways cleared correctly on modifications. But the impact on performance is not really important I think.

I think I almost understand how this works now. Not trivial stuff at all, I'm not 100% sure I can simulate the complete current behaviour using a z-buffer, not on the station overlays at least. I'll see how can I manage this.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 26, 2012, 01:16:37 AM
I've been debugging my last code for about 25 hours, it was showing NOTHING. I rewrote vertex arrays objects code, debugged the vertex coordinates, wrote fragment shader programs, looked at OpenGL 4 , looked in forums like crazy, and at the end... I was rendering the quads against a texture I forgot to update from the PBO (but I didn't forget to initialize to full transparent, so the quads were invisible). Don't you hate when you lose so much time looking everywere around and the problem was so trivial?

Oh man... Well, at least I advanced now. ;)

(https://dl.dropbox.com/u/30024783/Untitled34.png)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Fabio on November 26, 2012, 01:32:14 AM
It's horrible, man.
Like just when you work hours and you feel you must start it all over again until a light turns on and you get in a moment how you should have done from the start.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 26, 2012, 02:23:28 AM
Yes, indeed... :)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Ters on November 26, 2012, 05:51:11 AM
The last few years, I've begun saying "If you want to do <something>, then you must do <something>." An example would be "If you want to show a window on the screen, then you must show the window on the screen", which means that I've spent lots of time figuring out why my window doesn't appear, only to realize I've coded everything (making the window, population it with items, giving it the right size and position) except the one line of code that tells the window to become visible.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 26, 2012, 01:03:08 PM
Found a link taht might be interesting to someone:

http://stackoverflow.com/questions/892811/drawing-isometric-game-worlds
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: isidoro on November 26, 2012, 11:42:24 PM
Quote from: Markohs on November 26, 2012, 01:16:37 AM
[...]
I rewrote vertex arrays objects code, debugged the vertex coordinates, wrote fragment shader programs, looked at OpenGL 4 ,
[...]

Have you considered the people with cards not capable of OpenGL 3+?  For instance, in Linux, with each version of xserver, most over two years old ATI/AMD cards are kept away...  In this computer, I have to go to the free drivers and have OpenGL 2.1 with a 2010 card...

Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Ters on November 27, 2012, 05:34:10 AM
I think it's best to stay at the 2.1 level, though there are a few nice things in 3.x. OpenGL 4.0 is likely too new for the Simutrans target group, based on how I recently had to help out ensuring that the nightlies were able to tun on a pre-Pentium III CPU.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 27, 2012, 11:47:07 AM
I'm just using the primitives described in 3.2 document:

http://www.opengl.org/registry/doc/glspec32.core.20091207.pdf (http://www.opengl.org/registry/doc/glspec32.core.20091207.pdf)

But I think all the code I used so far is compatible to 2.1 (an maybe even older), I don't use any shading language still, but maybe when I have to deal with player colors and night colors I'll have to use some of that. 2.1 supports shading language too, I'll try to stick to 2.0 ofc.

I discarded using the 4.0 language, that required modifying lots of Ters code and I feared of backwards compatibility as isidoro mencioned already. And required vertex and fragment shaders.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 27, 2012, 03:29:23 PM
Advancing here, looks like I'm missing something on height mapping, using get_hoehe(), but not on all tiles maps correctly. Pasting the code hre for the case somebody has any suggestion.

position is filled in ground_t::calc_bild()

const koord3d pos(pos.x,pos.y,this->get_hoehe());


    IMAGE_ATLAS *img = atlas->get_image(image->bild_nr);

    if (img == NULL) {
        return;
    }

    koord3d position = position_in;

    position.x = position_in.x;
    position.y = -position_in.y;
   
    KOORD_VAL w = get_tile_raster_width();

   
    const GLfloat image_w = (GLfloat) image->w;
    const GLfloat image_h = (GLfloat) image->h;
    const GLfloat image_x = (GLfloat) image->x;
    const GLfloat image_y = (GLfloat) image->x;

    const sint16 height = tile_raster_scale_y( 2*TILE_HEIGHT_STEP, w );


    GLfloat x = (GLfloat) (position.y*w/2) + (position.x*w/2);
    GLfloat y = (GLfloat) (position.x*height/2) - (position.y*height/2);

    // elevate acording tile height
    y = y - tile_raster_scale_y(position.z*TILE_HEIGHT_STEP,w);

    x = x+image_x;
    y = y+image_y;

    const GEOM_QUAD quad(
            x,y,
            x + image_w, y + image_h ,
            map_texel(img->u1), map_texel(img->v1),
            map_texel(img->u2), map_texel(img->v2),
            ATLAS_RGBAVAL(255, 255, 255, 255)
    );
    quads.push_back(quad);


(https://dl.dropbox.com/u/30024783/Untitled35.png)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Combuijs on November 27, 2012, 03:36:36 PM
This line:

const GLfloat image_y = (GLfloat) image->x;

does not look too healthy  8)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 27, 2012, 03:47:11 PM
Oh man, that was it, thanks a lot!! :)

four eyes see more than two, that's for sure. ;)
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 29, 2012, 01:31:40 AM
Just storing the landscape on a persistant VBO boosted performance again from my tests:

Old optimized implementation is Ters one,  not resetting texture cache each frame
New one is the same old implementation but drawing the landscape from a persistant VBO and texture, saving CPU and PCI bandwidth.

Max zoom out, removing the outer water tiles.

Frame time    FPS
60 ms            16    Old
35 ms            25 (simutrans capped I think)

The display is still not perfect, misses slopes, sea, rivers and ways (even the number of elements in the VBO seems to not impact performance in a significant way) and it's not perfectly alligned with the rest of elements at all zoom levels. The old code contains lots of optimizations and hard to understand coordinate manipulations, I have to have them another look to fully understand them. If anyone wants to have a look at the code and suggest something I'll be happy to hear your oppinions. I know code is not optimized, and some decisions might be questionable, nothing is written on stone yet. Work in progress.

I tested on comic96 PAK, that pak is a bit special in the way that it loads a savegame instead of generating a new random world on the splash screen, pak128 and others will crash or render unexpected results (the geometry buffer has to be reset, just handled savegame loading so far) . Only initial geometry is displayed, it doesn't keep track of changed tiles yet.

EDIT: A binary here (https://dl.dropbox.com/u/30024783/Simutransgl.exe). Have in mind that at start it will give low fps until the images are cached on the video card, will give small freezes every time a new object appears to get drawn (as it happened before) Pak128.britain works too, just start the game, select the pak, press, "new game" and close the new dialog to be able to move around the map.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: prissi on November 30, 2012, 10:08:11 AM
just put a file names demo.sve into the pak folder will load it on start. Or specify "-load xzy.sve" on the command line.

BTW: It crashed prior to any action and requires to switch of Data execution prevention.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 30, 2012, 11:31:33 AM
Thx. :)

About the data execution prevention, strange, here it runs without that setting on.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: prissi on November 30, 2012, 02:07:36 PM
MAybe this was rather due to crashing. I mean I might have anyway not luck on this very old XP machine.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on November 30, 2012, 03:37:51 PM
Well, thx for trying anyway, soon I'll have a stable version with all the new code.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on December 05, 2012, 06:26:57 PM
I'm trying to find a good place in code where I can add calls to my texture atlas filling routines.

So far I was checking obj_reader_t::read_nodes , but that function is too generic, I thought it whould be a idea to check for their type and just register the ones I'm doing now, obj_way,  but saw that pak file format is not designed that way, and obj_way it's just a descriptor (besch), that might have images as child.

Is way_reader_t::register_obj the bast place to hook this code? examining the descriptor and add the images it might have?

Thanks
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Ters on December 05, 2012, 07:20:40 PM
I thought register_image would be the place for this.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on December 06, 2012, 09:54:08 AM
Yes, and it's the right place, but I need to know wich type of image is to put it on the corresponding atlas so phases can be drawn in the minimum number of passes. Atm I wanted one for land tiles plus slopes and maybe a second for way objects. when register_image is called, that information is lost. Maybe a good idea that comes to my mind with your post is I should add a parameter to register_image with an optional texture atlas id.

register_image is called on each image of the game, I just need to know wich type of image is.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Ters on December 06, 2012, 04:04:47 PM
Thinking out loud: is it possible for an image to be both land tile and something else?
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Dwachs on December 06, 2012, 04:52:34 PM
No. Land tiles are generated.
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: prissi on December 06, 2012, 06:28:52 PM
Thus land tiles a a certain image range. However, soon the landscape code might change. Furthermore, would it no make much more sense for OpenGL to just provide the mesh points and texture(s) and leave the rendering to the hardware?
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on December 06, 2012, 07:42:02 PM
yep, prissi, and that's what I already implemented. the problem comes from the situation uploading the textures each frame consumes too much CPU and PCI bandwidth, so I have to create a texture with all possible tiles and upload it first, and re-use it on all frames. To make this I added some code to calc_water_level anf just uploaded all those images.
This has already been implemented and it works perfect, boosting performance.
the problem is now i want to do the same with slopes and ways, and can't see a good place in code to locate wich are those images. about slopes i was thinking generating them from textures prograatically like climate tilles are now, and do the code for simutrans 2D too, auporting doble heigjt. but how to register just way images?
written from my phone, this post might have errors
Title: Re: Hardware accelerated display, OpenGL back-end & Simutrans 3D
Post by: Markohs on December 06, 2012, 07:48:39 PM
Quote from: Ters on December 06, 2012, 04:04:47 PM
Thinking out loud: is it possible for an image to be both land tile and something else?
land tiles are generaged, yes. but in.  the case one image is used in multiple objects, i'd just add copies to each atlas.