News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

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 1 Guest are viewing this topic.

eddielexx

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.

Spike

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

eddielexx

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

Václav

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.

Chybami se člověk učí - ale někteří lidé jsou nepoučitelní

skreyola

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.
--Skreyola
You can also help translate for your language with SimuTranslator.

eddielexx

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

greenling

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
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

Spike

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

eddielexx

#113
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?

Spike

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.

inkelyad

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.

Spike

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.

Banter

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

neroden

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.

prissi

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

Václav

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.

Chybami se člověk učí - ale někteří lidé jsou nepoučitelní

lukesleftleg

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

Banter

@lukesleftleg what is the possible file format for 3D models in your engine? 3ds, obj, other?

lukesleftleg

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


vilvoh

That 3D engine looks great, lukesleftleg!

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

lukesleftleg

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.

Ashley

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

lukesleftleg

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



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.


prissi

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.

lukesleftleg

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

Ashley

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

neroden

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.

lukesleftleg

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

Václav

Quote from: Timothy on March 09, 2011, 07:49:26 PM
and here... http://archive.forum.simutrans.com/topic/04061.0/index.html
...

Locomotion bridge chaos ... it is something why I have played it for quite short time (in comparison with Simutrans and TTD).

Chybami se člověk učí - ale někteří lidé jsou nepoučitelní

skreyola

What about diagonal crossings? I know those have been requested in ST main, so it might be worth considering.
--Skreyola
You can also help translate for your language with SimuTranslator.

Markohs

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.

Markohs

 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.

Dwachs

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

Markohs

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.

Banter

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.