Posts Tagged ‘News’

Skyline Game Engine reaches public beta

Saturday, March 7th, 2015

With all the crazy news about many high-profile game engines either dropping their prices or getting rid of them completely (with a royalty catch of course), we want to highlight one new game engine that uses Ogre as its rendering component: Skyline by Aurasoft.

The just entered the public beta stadium and published their new website.

Thanks to your awesome Ogre3D rending solution we can focus on leveraging superb visuals and cannot wait to see what we can do with Ogre V2.0.

Skyline has now been released as a public beta with both a free and retail version. The retail version is fully commercial with no royalties or earning restrictions and is a low cost game development solution. We have a new website and forums complete with an asset store (which still under dev): http://www.chi-ad.com/Skyline/Site/

Below a few screenshots of their editor and some sample scenes. More can be viewed directly on the engine’s website.

They were also featured some weeks ago in the IGM. Check out the article here.

Skyline main site: http://www.chi-ad.com/Skyline/Site/

Skyline forums: http://www.chi-ad.com/Skyline/Forum/

Skyline asset store: http://www.chi-ad.com/Skyline/AssetStore/index.php?route=common/home

 

Ogre Progress Report: February 2015

Thursday, March 5th, 2015

This is dark_sylinc writing again…and: Oh boy! We’ve been busy!

1. Light list generation for forward lighting was threaded. Turns out, we were spending a lot of time building the light list when there are tons of objects on screen. Frame time was reduced from 10 ms to 4.5 ms on my Intel i5-4460 for 50k draws (AMD Radeon HD 7770).

2. Ported DX11! It’s not as thoroughly tested as the GL3+ RenderSystem, so I’d stick with GL3+ if you want stability. But it’s booting up, it can take advantage of most of the AZDO enhancements, and all the samples are running. Performance benchmarks against GL3+ are inconsistent: It highly depends on the driver (different cards, different bench results) and some samples run better on GL3+ others on D3D11, but often only by a slight margin.

Since the samples are GPU bottlenecked, my theory is that it depends on how well the driver compiles and optimizes the GLSL shader versus how well the driver optimizes and reinterprets the HLSL IL that the D3D runtime throws at the driver.

Now cards that are supposed to be supported but were not due to driver issues (i. e. Radeon HD 2000 through Radeon HD 4000) are now being supported! Intel cards weren’t tested, but in theory they should be supported too. Feedback is appreciated in this area (both Windows, Linux, and D3D vs. OpenGL).

GL to the left, D3D to the right. The FPS difference isn't relevant and can go either way.

GL to the left, D3D to the right. The FPS difference isn’t relevant and can go either way.

 

3. We’ve been working on an experimental branch with a new technique called “Forward3D“. Sounds exciting but it’s not really ground breaking.

I don’t want to use deferred shading as default because it causes a lot of problems (transparency, antialiasing, multiple BDRF). Besides, it uses a lot of bandwidth. Forward+/Forward2.5 is great, but requires DX11 HW (needs UAV) and a Z-Prepass. This Z-prepass is often a turn off for many (even though in some cases it may improve performance, i.e. if you’re heavily pixel shader or ROP [= raster operation] bound).

I came up with an original idea for a new algorithm I call “Forward3D“. It’s not superior on all accounts, but it can work on DX10 hardware and doesn’t require a Z-prepass. The light list generation algorithm is now being generated in the CPU, however I think it should be able to run on Compute Shaders on DX10 hardware just fine (though, I don’t know yet if generating the light list is expensive enough; it may not even be worth doing on CS or perhaps it will).

The result is a nice generic algorithm that can run on a lot of hardware and can handle a lot of lights. Whether it performs better or worse than Deferred or Forward+ depends on the scene.

These are early screenshots. The algorithm has actually improved since then (particularly for bigger lights, it can handle a lot more lights now):

Forward3D in action. Many small lights = OK. Few big lights = OK. Many bigger lights = Not ok.

With bigger lights they start getting LOD’ed as a side effect of how the algorithm works

 

4. The community seems to be eager to compare how Ogre 2.1 fares against commercial engines. Remember that Ogre is a rendering engine while most of these engines are game engines (which means they provide much more than graphics, like physics, sounds, logic, scripting and level editors). Nonetheless Ogre seems to be doing very well!

We highly appreciate the faith you put in us!

5. Reported two Linux driver bugs to AMD. AMD has already confirmed that they will be including a fix for one of their bugs in the next Linux release. Their engineers are still working on the second bug, which has been much harder to isolate.

6. Merged all changes from:

  • 1.9 → 1.10
  • 1.9 & 1.10 → 2.0
  • 1.9 & 1.10 & 2.0 → 2.1

Now, all enhancements that were made to 1.10 (particular to RenderSystems) are available in 2.0 as well. We still recommend that on 2.0 you stick to D3D9 though, since it’s the fastest and most stable one. On 2.1 we recommend GL3+, but you’re now encouraged to also try out the D3D11 RS as well.

7. Fixed tons of bugs as they’ve been reported or been found.

Well. There’s a lot of work that remains to be done. Ogre3D is well and alive! I’m /signing off for now.

HLMS / PBS + Online Editor sponsored by CodeRabbit GmbH

Tuesday, February 10th, 2015

Hello everybody, Murat (wolfmanfx) here:

Last year at CodeRabbit GmbH (my own company), we started a project called “Distributed Viewer”.

Distributed Viewer is an editor where users can upload models and edit materials in real time from any browser and instantly preview the changes not only in the browser, but also in all connected devices such as desktop PCs, Android and iOS devices at the same time.

Early in the development cycle we have realized that the current Ogre material system was too limiting and too complicated to do something like this. So after many discussions we came to the point where we decided to fund the initial development of the Ogre HLMS “High Level Material System”. More details about the HLMS can be found in this post from Matias.

With HLMS in our bag we have created PBS (Physically Based Shading) materials for the uploaded models. Our PBS shader is based on this moving-frostbite-to-pbr (the HLMS files will be released with the upcoming backport). The following image shows a screenshot from the material designer.

(more…)

Ogre 2.1 now publicly available (previously dubbed AZDO branch)

Monday, February 9th, 2015

Hi everybody! It’s me, Matias aka dark_sylinc!

Time to give a progress report:
At the time that I  am writing these lines, I am making the final preparations for publicly releasing the AZDO branch aka “Ogre 2.1″ (still unnamed as of yet). This doesn’t mean it’s ready / finished, but rather that it becomes public, as there has been a lot of development that has been done behind closed doors.

The relevant pull-request and merge can be found here: Ogre v2-1 branch creation / pull-request
The new branch itself is here: Ogre v2-1 branch

You can also follow my current ToDo list on my trello board.

(more…)

Ogre 2.0 RC1 announcement

Friday, February 6th, 2015

Good news! We have officially added the v2-0-0RC1 tag to the Ogre repository (commit) indicating that we reached our first Release Candidate milestone for Ogre 2.0!

Our original plan was to tag this release as “CTP” (Community Technology Preview) and the upcoming AZDO (Approaching Zero Driver Overhead) improvements as “final”. However this proved to be very confusing for the community and in fact presented two practical concerns:

  1. v2-0-0RC1 is actually very stable and relatively easy to port to when coming from Ogre 1.9 or Ogre 1.10 (= current unstable default branch). The external API interface is quite similar, with performance benefits from efficient frustum culling and scene graph management (plus it’s multi-threaded). Several users in the community had already started porting to it.
  2. The AZDO branch was going to be labelled as “final”. Even though being quite impressive feature- and performance-wise, it is not complete, cannot be considered stable, and is far from actually being final. Furthermore, porting from Ogre 1.9 or even from Ogre 2.0-RC1 to the AZDO branch is not a trivial task as the external API changes are considerable.

Therefore we concluded that:

  1. The “CTP” branch will be released as Ogre 2.0 and is a good stepping stone for projects that require better performance without the high risk associated with porting when there are big engine changes.
  2. The “AZDO” branch will be released as Ogre 2.1 at some point in the future. External interface changes are quite significant and porting to this version requires more work and inherently results in more risk.

Our main focus of development will be on Ogre 2.1. We will only be providing basic bug fixes for Ogre 2.0 to be able to dedicate more resources to Ogre 2.1.

Note: While more and more focus will shift to Ogre 2.x, we will not immediately abandon Ogre 1.x. In fact, there is still at least one release in the making (Ogre 1.10). Once we have a more concrete timeline for it, we will announce the details.

(more…)

Ogre’s GSoC 2015 season kicked off!

Wednesday, February 4th, 2015

GSoC_2015_logo

With this year’s Google Summer of Code already slightly being visible at the horizon it was time for us to get things started again: We are hoping to find a group of capable and motivated students that will help us move Ogre even further. In order to guide this effort, we created a list of potential GSoC projects that we deem most relevant for this year and consider manageable in the given GSoC time frame: GSoC 2015 Project Ideas. There is also a dedicated idea discussion thread that might yield further insights and ideas.

We also collected all the relevant information about how to apply, where to find additional Ogre related information for this year’s GSoC, etc. in this forum thread. Additionally, we have a GSoC wiki section with a dedicated page for this year that we will update as new information becomes available.

We welcome everyone to chime in either with additional ideas or comments regarding potential projects and join the combined efforts to make this one important cornerstone for a successful Ogre year 2015.

On a related note: The so far private Ogre Hlms/AZDO branch will most likely be made publicly available around the end of this week. This of course is needed for the related GSoC idea to be possible.

 

Game highlight: “Shadows: Heretic Kingdoms”

Monday, February 2nd, 2015

Once again, we want to highlight one of the many games based on Ogre3D that have come out recently. This time: “Shadows: Heretic Kingdoms“.

Shadows Heretic Kingdoms PackageAs usual we asked the team behind the game if they could share some insights into the Ogre3D usage and how the game was built in general, and the guys from bitComposer were kind enough to provide those:

  1. The game was developed on an older Ogre version, but continually upgraded to the most recent versions (currently 1.10). We are thrilled to get the game to Ogre 2.0 though as there are some limits which we are not able to overcome with the 1.x versions (mostly related to hyper-threading and slow scene management).
  2. Apart of a few bugs fixes we have not made any modifications to Ogre core. However, we are using some extensions of shader rendering pipeline. To be more specific, we have modified deferred shading with cubemaps projected lights, added off-screen particles, outlines glow and color correction to name the biggest changes.
  3. We are supporting both DirectX 9 and DirectX 11 renderers. DX11 was included because of the improper detection of graphics cards on some computer with multiple graphics cards with DX9 version.
  4. For 3D modelling, animation and export we are using Maya. Some outsources create their models in 3D Studio and we import those into Maya environment and export into the games.
  5. We have developed our own editor which we are using for scene assembling which includes ragdoll editors, lightning.
  6. For particle effects we are using Particle Universe with in-game editor for seamless implementation of particles to the game environments.
  7. For physics simulation in Shadows we have used the Bullet library (mostly for collisions and ragdolls).
  8. Scripting is done using LUA language. A lot of external files are XML formatted.
  9. For text content handling (there is a lot of text content as you can imagine) we are using our own proprietary tool Locedit which is also available for 3rd parties if someone may be interested in. It features multiple languages, Unicode, subtitler for movies, XLS export/import, voice check and direction, etc.
  10. Game content is encrypted and packed to improve loading times.
  11. User generated content is planned to be distributed using Steamworks.
  12. The entire toolset will be released for the community together with the game sometimes in the near future. We believe that Ogre community may benefit from our tools even for their own projects… It certainly will lack the polish and proper documentation of Unreal but it likely may be the most complex tool for Ogre and available for all Shadows owners without any additional fee.
  13. We are currently starting porting of Shadows to Ogre 2.0 together with the Ogre team, so I hope our work will contribute to early availability of complete 2.0 version of Ogre.

You can see more videos and screenshots on Steam where you of course can also purchase the game: Shadows Heretic Kingdoms @ Steam

 

Below a first look at the editor that was used for the game and is planned to be released to the public in the near future:

“Void Destroyer” officially released + new trailers

Wednesday, January 21st, 2015

Good news: The Ogre3D powered game “Void Destroyer” has left the Early Alpha stage and is now officially released.

Until the 27th of January you can profit from the introduction promotion (25% off) on Steam. Give it a try!

 

Review of 2014 & Outlook on 2015

Sunday, January 4th, 2015

First off: Happy New Year to everyone!

As the old year starts to slowly fade away in our rear view mirror, we want to look back on what 2014 had in store for Ogre3D and at the same time look ahead what 2015 might bring. So strap in for this ride back to the beginning of last year…

Review of 2014

It all started off with one key event early in 2014 when one well-known (at least in Ogre3D circles) Argentinian fellow joined the team: Matias Goldberg. In the last few months he was (and still is) the driving force behind the efforts to develop the revamped Ogre 2.0 version. Without him that would not have been possible in its current form…or more accurately: It would not have been possible…full stop.

The work on Ogre 2.0 was one of the cornerstones in last year’s efforts, but of course the rest of the team was not sitting around idly, but instead focused on Ogre 1.10. The DirectX11 and GL3+ render systems in particular received a lot of attention and will be among the highlights of this upcoming release. More on that later once we arrive back in the present time on our journey through the last 365 days.

Two other notable technical points are the addition of WebGL support to Ogre3D as well as AZDO work:

WebGL / Javascript (Emscripten): From Ogre version 1.10 on, we officially support WebGL. The respective code has already been pushed to the repository. An online demo can be viewed at http://coderabbit.at/webgl/viewer (with an downloadable offline copy being available on our Sourceforge site) and build instruction can be found under the following link: http://coderabbit.at/webgl/viewer/OgreEmscripten.txt.

AZDO: As part of his Ogre 2.0 efforts Matias has been working on optimizing Ogre3D from an AZDO (Almost Zero Driver Overhead) point of view. For now this only covers the GL3+ render system, but will be extended in the future. A dedicated post from Matias will follow, outlining the changes and improvements in more detail.

Of course all that work on the engine itself only makes sense if there is an active community and eco-system actually making use of it. Some projects to showcase are listed below:

So all in all it was another pretty good year for Ogre3D, but we got quite a few things to optimize and change for 2015…and that is where we are back in the present and “put the pedal to the metal” to jump-start into 2015 and all we have planned for it:

Outlook for 2015

One of the first things we want to finish is the go-live of the new Ogre3D website we have planned. This basically entails a face-lift and getting rid of the slightly annoying ad banners. So stay tuned for that.

Another major step will be the release of two new Ogre versions, namely Ogre 1.10 as well as the first Ogre 2.0 CTP (Community Technology Preview). Once we have set the final dates we will let you know via a blog post as well as where to find further details. This especially pertains to Ogre 2.0 for which we want to set up some dedicated sources of information to help with the upcoming transition once 2.x nears its first stable release.

At the same time, the regular development efforts will continue and as always we encourage everyone to chime in wherever possible, by providing feedback and input in the forums, reporting issues on our JIRA tracker and ideally also help solving those by submitting pull-requests for our official source code repository. Additionally, donations are always welcome as well to help managing the infrastructure costs.

This last point nicely leads to another thing we want to tackle this 2015. Go-live of our CI server (Continuous Integration) for automated testing of Ogre3D. Once this is ready to use, we will announce it here as well in a dedicated post.

We of course also hope to participate again in this year’s GSoC after we did not make the cut last year. The preparation for it will begin soon by opening up the discussion in our GSoC forum section regarding interesting potential projects ideas. If you have one, note it down and join in the upcoming idea discussion.

Lastly, we also plan to do another Ogre User Survey to get some insights into the user base along with its priorities and wishes and some information about the usage of our engine in general. As you already guessed: This will also be covered in a dedicated announcement once we survey is open. Prior to it, we will trigger a public discussion in the forums regarding the questions we want to ask. Feel free to join in if you have questions that might be of interested and that you would like to see included in the survey.

That’s about it in terms of what we have planned right now, but as usual we will have to see how things pan out. As usual let us know what you think in the forums…and then let’s get cracking.

Ogre3D based “NeoAxis” game engine now free

Thursday, December 11th, 2014

This time we have something new from the Ogre3D eco system: The Ogre3d based game engine “NeoAxis” has just been released for free.

neoaxis_3d_engine_is_now_fully_free_1400

NeoAxis Group Ltd is glad to announce that the universal 3D development framework NeoAxis 3D Engine is now completely free, as the community has been asking for it. You can freely download the recently published SDK 3.0, which includes all the features previously reserved to Unlimited and Source licences. From now, the engine will developed as free tool. Paid licenses will still give customers access to a bigger part of the engine’s source code.

Licensing Changes

NeoAxis 3D Engine is available in 3 editions, each providing a different level of access to the engine’s source code.

  • Free Edition — free development environment, which includes all features of the engine and tools. Includes the ability to expand the engine by creating add-ons.
  • Professional Edition — includes the full source code of the engine’s tools and bigger access to the source code of the engine components.
  • Source Edition — includes full source code of the engine.

Read the full announcement on the NeoAxis blog.