"Orion's Gate" - a MMO-RTS [In development]
Community Forums/Showcase/"Orion's Gate" - a MMO-RTS [In development]
| ||
| Hi all, I am currently developing an MMO-RTS named "Orion's Gate". Set about 500 years into the future, and it takes place in the fictional Orion galaxy. There are three races in that galaxy, and the idea is that players themselves shape the galaxy.  As it stands, this is what's working: - Client/Server connection - MySQL backend holding account information, and later on practically all data of the game - Themable user interface - An XML API for out-of-game access to in-game data - A theme development tool named "Corona Viewer" - 3D Rendering - Shadow rendering depending on position of light source - NOTE: This mechanism has changed from a geometry-based approach to a dynamic ray tracing algorithm - Model decompression and their appropriate textures - Models/meshes can be "multi-mode", depending on the state of operation - Smooth glow/bloom effects, rendered in real-time Mar. 24, 2012 Video DevBlog 5: RT^2 - Real Time Ray Tracing concept A first look at a new way to generate shadows through a simplified ray tracing technique Written version, outlining the inner workings of the technique Mar. 15, 2012 Video DevBlog 4: Bring Me To Life A look into the new animation effects for the engine, giving the elements in the game a touch of life Mar. 10, 2012 Video DevBlog 3: Let it glow, let it glow, let it glow Written version, explaining the effect in detail Mar. 8, 2012 VIDEO - Orion's Gate: Genesis - Logon V1.1 Current logon screen, showing the entrance to New Tokyo, on Terra Nova - the home world of the humans and the Orion Federation in the Orion galaxy. Also visible are geothermal power plants and Ion Artillery Turrets. Apart from that it plays the current musical score for the logon. Feb. 19, 2012 Video DevBlog 2.5: The Geometry Of Shadows Written version Short update to previous DevBlog, showing realistic shadows. Feb. 18, 2012 Video DevBlog 2: Shadow Dancing Jan. 26, 2012 Video DevBlog 1: In The Beginning Written version As I progress in development, I'll update this thread with screenshots and/or links to DevBlogs. Comments are appreciated! Cheers Marcus Last edited 2012 Last edited 2012 |
| ||
| I like the look of the login screen |
| ||
| Yeah, all very professional looking! |
| ||
| Thanks very much you both :) -- Marcus |
| ||
| i like the in game screen. |
| ||
| The login screen has been radically revised, when comparing to the video I posted. It now shows the Orion Relay (-> "Orion's Gate") lit up at night, on Terra Nova.  Last edited 2012 |
| ||
| Nice BG! Is it going to be a 3D game? |
| ||
| SICK GFX! B) |
| ||
| Kryzon, it'll look 3D but it's 2D for now. Maybe at some other time in the future it'll be full 3D. Thundros, thanks :) |
| ||
| Uw! :) |
| ||
| A little update - I am in the process of implementing a character creation mechanism that allows you to choose from a variety of base models, expressions, and poses. On top of that, many aspects are customizable - such as clothing, skin color, lighting, hair styles, as well as the camera position (yes, it's full 3D). A little sneak peek:  This is using MiniB3D as engine. |
| ||
| Updated initial post with link to DevBlog 2 |
| ||
The Reticulum Engine, as I like to call it, is starting to take shape. One of the things it is able to do, is casting realistic real-time shadows. |
| ||
| Very nice to see it taking shape! In your video I can see the shadows are not aligned to the light source. They seem a bit off. Did you notice this too? |
| ||
| Yes, I noticed that (but only now that you said it) - you know how it is in coding: there are always 5 bugs :) It's also possible that the "light cube" is not aligned to the light source. I'll have to check into that. |
| ||
| After building and tearing down entire cities, planning, testing, and having fun with texture tricks, I think I'm getting somewhere now. The below is a screenshot of the current logon screen. It shows the ominous Orion relay, and the entrance to New Tokyo leading from the gate. You can also see three small geothermal power plants used to power the relay mostly, and two Ion Artillery Turrets guarding the relay. Their business end rotates when they sit idle. The bloom effect is a bit experimental as you can see. It's a learning experience after all. Comments are welcome.  Also: the logon with its score and animation as it is right now. Orion's Gate: Genesis - Logon V1.1 Last edited 2012 |
| ||
| I would say the buildings are a too repetitive texture and have too many lights on :) |
| ||
| Thanks for the feedback, I'll change that :) |
| ||
OMG its paul oakenfold lol Last edited 2012 |
| ||
| OMG it's really him! :D haha |
| ||
Since I had received feedback that the textures were to repetitive, I sat down and changed the design a little. Also as another milestone in development, the bloom effect of the engine has been revised and optimized, to produce a richer, smoother glow effect at little expense to the graphic card.  I updated the initial post with the link to my latest dev-blog, showing the new bloom effect a bit more in detail. |
| ||
| Nice glow effect :) Can you give me more info about the glow routine you use ? Do you have a link to learn about how this routine works ? For now i use the Blur routine from Fastext but maybe the routine you use is faster. Thanks, |
| ||
| much better :D |
| ||
| Hi EdzUp, thanks :) Hi RemCoder, The way it works is relatively simple. I have a normal camera, and a camera for bloom to begin with. Both cameras are in the same location and move the same way (when real cam moves on x-axis, the bloom cam moves with it). For bloom calculation, the normal camera is hidden, bloom cam resized to a quarter of the screensize. You turn off all light sources. You also hide the meshes that cannot glow, such as the terrain and the skydome/skybox. Render the world. All that should be left are the meshes that have self-illuminating textures. You grab a pixmap and set 0,0,0 as the mask color. You use a blur routine on that pixmap and then load it as image. Set blend to LIGHTBLEND and alpha to 0.2 Use DrawImageRect 0,0,yourScrenWidth,yourScreenHeight to draw the blurred image on top of what you see. That's how it works, in a nutshell. |
| ||
| Ok, i use a similar method, and i use the blur routine of Fastext. I'm curious, what kind of blur routine do you use ? An external dll or your own routine ? Thanks, |
| ||
| I'm using my own routine for it. |
| ||
| Heya SystemError51 good work but those textures are stretched and not that great. Do you plan on working on that or are you satisfied with what you have? |
| ||
| Hi stayne, I will work on that. For now it's more testing and figuring how something works. The final thing will look much different - or only somewhat resembling the things I now have. |
| ||
| I have received quite some feedback, asking how the glow effect was done. In this DevBlog post, I'm taking the process apart bit by bit and explain the steps done. I'm even re-creating the glow with the GIMP to show how it works. DevBlog: Let it glow |
| ||
| Interesting article :) Since the blurred image is only a quarter of the screen, the image is resized to full screen and rendered 8 times on top of what you see – in a clockwise manner – with an offset of, say, 6 pixels. I have tried this technique and when the camera was far from the mesh that glows, the 8 parts with the offset were visible. So after that i have decided to simply scale the size of the mesh and then use the blur routine. Edit : oh you mean the offset of the image not the offset of the quads, i understand now. And i guess that if i decide to do several passes, for each pass i have to decrease the alpha value of the image ? Or the blur routine takes care of this ? Last edited 2012 |
| ||
| Hi RemCoder, If you switch to LIGHTBLEND and do a SetAlpha to 0.2, you should be good. Last edited 2012 |
| ||
| Wow, this is really looking slick! I was a little skeptical when I saw the words "MMO" and "in-development" to be honest, but it seems you really have done a lot of legwork on important aspects such as the database, network capabilities as well as the graphics engine! Best of luck with this :) |
| ||
| Wow _PJ_, thanks :) I have updated the initial post with a new video devblog, showing the all-new animation effects. Last edited 2012 |
| ||
| When attempting to finalize my logon scene and other things that have to do with lighting, I saw a pretty fatal flaw in my shadow generation, so I had to scrap the one I implemented and started over. The result of that rework is something I'd like to call RT² - Real Time Ray Tracing. Before you scream "WHAT?!" - it only traces rays of light that fall on a defined plane, or part of the scene. To be more precise, this mechanism tracks beams of light and knows what is in shade, and was it not, and creates shadows according to a coordinate-based shadow map (that is not a texture). The concept in itself works. The shadows look a bit blocky in the moment, I have to see how detailed it can get without performance hits. This technique elevates the game's requirements to dual-core. One thread evaluates the ray tracing, the second renders the shadows. Example of what I have gotten:  This screen shows the rays that were tracked and marked as being in shade:  I have recorded a video, explaining the concept a bit further, also demonstrating it in real-time: Real Time Ray Tracing concept Please let me know what you think :) Cheers M. |
| ||
| While it is a cool idea, wouldn't it be faster and easier to implement if you used shadow maps? They work with arbitrary geometry and are easily scalable in terms of performance (size of the texture dictates computational effort). What's also important is that shadow maps are GPU bound, perfectly exploiting the massive parallel computational abilities of the GPU. The graphics card will also work in parallel to your application - you only have to setup the calls and can continue happily with your code while the GPU starts working. Nowadays it's a good idea to have the GPU handle as much of your graphics as possible, since the CPU is always going to be the bottleneck if you start processing geometry with it. Keeping the GPU busy while the CPU handles vital features (collision detection, networking, etc.) should improve performance. |
| ||
| To cut down your load couldnt you just trace the 'vertices' than create a polygon from that that represents the shadow? |
| ||
| Cool technique, reminds me of Stencil Shadowing. Last edited 2012 |
| ||
| Hi Noobody, EdzUp and Kryzon, thanks for your feedback :) The way it works right now, is, that at each coordinate a shadow was found, a GL_QUAD is rendered (can have its own alpha, etc). It all works relatively well (as you may have seen in the video), but it could get rather bad for more shadow detail or larger "planes". I'm trying to implement rendering into a pixmap (of the coordinates that were found to be in shadow), and use it as a texture to be rendered (much faster). However all my approaches result in memory leaks. Last approach was to use GLTextFromPixmap constantly run in a loop, which eats up memory. It's weird. Maybe someone knows how to circumvent that. Imagine this running in the main loop (shadowmap is the Pixmap containing the shadow map, obviously): shadowTexInt = GLTexFromPixmap(shadowmap) glEnable(GL_BLEND) glEnable(GL_TEXTURE_2D) glBlendFunc(GL_SRC_COLOR, GL_SRC_ALPHA) glBindTexture(GL_TEXTURE_2D, shadowTexInt) glBegin(GL_QUADS) glTexCoord2f(0.0, 0.0); glVertex2i(-10, -10)' top left glTexCoord2f(1.0, 0.0); glVertex2i( 10, -10)' top right glTexCoord2f(1.0, 1.0); glVertex2i( 10, 10)' bottom right glTexCoord2f(0.0, 1.0); glVertex2i(-10, 10)' bottom left glEnd() ... Release shadowTexInt ??? I don't see why this causes memory leaks. |
| ||
| Release is for BMax integer handles to Types - GLTexFromPixmap returns an opengl texture name. Two different concepts :) glDeleteTextures is probably what you're looking for, although I would not recommend creating and deleting a texture every frame. Just replace the contents using glTexImage2D. It should also be noted that the performance increase with a texture probably won't be that great, since you're still doing most of the work on the CPU (and you have to do an additional texture transfer per frame). But if it is fast enough for your application, go for it :) |
| ||
| Hi Noobody, all these approaches don't work so well. The "ray-tracing" does work, but seems to eat up a lot of CPU and won't be usable in the game. Guess it's time to go back to the drawing board. |
   |