News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

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

Started by eddielexx, January 02, 2010, 03:38:33 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Markohs

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!

Markohs

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

Markohs

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

Markohs

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!

prissi

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.

Markohs

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?

prissi

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.

Markohs

#147
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*.


Markohs

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.

VS

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.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Markohs

mmm... yea, it will be enough for now, thx a lot! ;)

Markohs

#151
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/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

Ashley

That's pretty good progress :)
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

prissi

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


vilvoh


Escala Real...a blog about Simutrans in Spanish...

Markohs

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

prissi

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.

Markohs

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

Markohs

Tell me when tghe branch is ready plz, ready to upload the data here.

Markohs

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

Markohs

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


Dwachs

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.
Parsley, sage, rosemary, and maggikraut.

prissi

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.

Markohs

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

Markohs

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

TurfIt

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

prissi

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.

Markohs

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.

Dwachs

one should mention that there is now a 3d-branch in the simutrans repositoryat branches/simutrans3d.
Parsley, sage, rosemary, and maggikraut.

Markohs

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

prissi


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

Markohs

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

Markohs

#173
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

Markohs

btw, what does "besch" mean? I've found the meaing ribi, dinge, keine, bild, leer... but dunno what besch is intended to mean. :)