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

[prissi]

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.

[isidoro]

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

[Markohs]

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.

[sdog]

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)

[Markohs]

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

[Markohs]

 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

[isidoro]

  That's a big step 

[missingpiece]

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 ?

[Fabio]

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

[Markohs]

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.

[Spike]

Very good, seems you are on a good track there!

[jamespetts]

Very good, seems you are on a good track there!

Pun intended?

[Spike]

Totally 

[Markohs]

 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:

Code Select Expand


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


with:

Code Select Expand


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


[Ters]

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.

[Markohs]

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();
      }
}

[Ters]

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.

[Markohs]

I uploaded a compiled Win32 version here, 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!

[jamespetts]

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

[Markohs]

I think you miss directX9 on your computer, don't have it?

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)

[HDomos]

It asked for msvcp100.dll and msvcr100.dll, but when i put them into the simutrans folder, it worked perfectly (except the known issues)

[Markohs]

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 , but didn't really tested it

[HDomos]

I have NVIDIA GeForce 9600 GT

[jamespetts]

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.

[Markohs]

thank you both for your tests! Wich is your video card, jamespetts?

[jamespetts]

Radeon HD 5800 series.

[HDomos]

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

[Markohs]

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.

[Markohs]

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!

[jamespetts]

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.

[Markohs]

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!

[jamespetts]

I was wondering about animation, actually - that might involve quite a lot of extra work for vehicles, might it not?

[Markohs]

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

[jamespetts]

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?

[Ters]

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