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

[O01eg]

Nice. It starts, loads pak and language but than crashes after "Show banner ... ":

Code Select Expand


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

Code Select Expand


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 Expand


virtual waytype_t get_waytype() const = 0;


[Markohs]

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.

[Ters]

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.

[Markohs]

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.

[Markohs]

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.

[Ters]

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.

[Markohs]

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

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.

[Markohs]

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!

[Ters]

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.

[Markohs]

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.

[Markohs]

By the way, about the fps you are getting now, is there a improvement in fps compared to the current simsys_opengl ?

[Ters]

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.

[Markohs]

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.

[Markohs]

 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.

[Ters]

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.

[Markohs]

ok, perfect.

about the recode blend, might be refered to recolor images to player colors maybe, trains, stations etc?

[Ters]

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.

[kierongreen]

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.

[Markohs]

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.

[Yona-TYT]

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

[Markohs]

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.

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.

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?

I thought of a page on facebook "3D simutrans 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.

[Yona-TYT]

-I think I'm wrong with managers have given a great contribution to this project my apologies

[Ters]

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.

[Markohs]

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.

[Ters]

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

   
• Player colors
• Day/night cycles
• Arbitrary lines and circles
• The scrolling ticker at the bottom
• Generated images like the minimap
• Progress bar
• Some clipping
• Wide characters
• And don't zoom more than a step or two out!

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.

[Markohs]

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!

[IgorEliezer]

My congratulations for the valuable effort.

[Yona-TYT]

I hope this project to proceed
congratulations

[Markohs]

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.

[Ters]

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

[Markohs]

how did you implemented that landscape, with manualobjects? i had lots of problems with ois too

[Ters]

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.

[Markohs]

ok, great. I'll focus on the texture atlas and current "sprite" drawing, we'll need it anyway and it needs to be fast.

[Ters]

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.

[Yona-TYT]

is good to know that the work continues
always attentive. greetings ¡¡¡¡ Yona