Hardware accelerated display, OpenGL back-end & Simutrans 3D

[Roads]

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?

[Ters]

I'll tell what I'm thinking, which may or may not be what Markohs is thinking.

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.

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.

[Roads]

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 

[Markohs]

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). 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.

[Roads]

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.

[Markohs]

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.

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.

[Markohs]

Ters, why not using > 1024 textures? Just curious. renderqueue.cc

   texture_size = min(dr_get_max_texture_size() / 2, 1024); // Avoid too large texture

[Ters]

It was slower.

[Markohs]

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.

[Ters]

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.

[Markohs]

If somebody wants to try Ters version, I compiled a version, you can get here. I activated linear filtering of textures, so on zoom levels all graphics are a bit anti-aliased. You might need to install C++ redistributable too.

We know it has rendering problems and works too slow very far zoom levels.

[Roads]

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. 

[Markohs]

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?

[Lmallet]

Woah, the zooming is quite something.  Pak64 looks pretty good in this version.

[Roads]

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! 

[Fabio]

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...

[Ters]

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.

[Fabio]

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.

[Markohs]

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.

[Fabio]

yeah, the current goal is displaying the game using OpenGL, wich means mostly hw-accelerated. it will prolly include new visual effects.

Great!

full 3d will come later.

I hope it won't

[Roads]

Perhaps 3D doesn't have to replace 2D anymore than pak128 replaced pak64...

[Markohs]

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.

[Ters]

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.

[Markohs]

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.

[Ters]

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.

[Markohs]

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

[Ters]

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.

[Markohs]

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?

[Fabio]

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.

[ӔO]

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.

[Ters]

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.

[Markohs]

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

[Ters]

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.

[Markohs]

 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.

[Markohs]

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.