Contents
⏱️Overview
The continuation of our Stunt Rally game using latest Ogre-Next rendering engine.
Available here.
Forum topic with key progress steps and few screenshots.
SR website has Videos, Gallery, Download, etc.
Well it’s probably time I write something about how this goes, it’s been months already.
I took about 5 years break from old Stunt Rally. I was occasionally playing and enjoying it, but also ignoring any flaws, and thinking hard not to get into developing it again more (well that’s also the way for any commercial software).
In January 2022, I started thinking of checking out the new rendering engine Ogre-Next and posted on Ogre forum my topic with many questions to get more knowledge about it’s state.
I has been developed (and used) since years (probably 2015 or so) but I haven’t seen few key features like: Gui, fog, old plugin for grass, no demos for particles or water etc. Old Ogre had plenty. Ogre-Next had many, but not the very broad palette of game related components.
Shortly after I gave it a try and started a small demo (sources here) with nature scene. I was quite surprised by performance, how high and smooth Fps was with lots of vegetation. Contrary to old vegetation plugin we still use in old SR, which was also the worst thing, causing lags and delays while driving. But back then even fog wasn’t part of engine and had to be added with some knowledge. Luckily new Atmosphere component for fog and sun was made not long after.
Since there was no working MyGui fork (was earlier) and all else was difficult, I didn’t move much further.
Even though Ogre-Next is still technically Ogre, about half of everything in code changed. Even using terrain was completely different as the system was new. It was good since it has better performance but it also meant a lot more trouble to use it and later port Stunt Rally stuff into it, and we have an editor for it too and own custom blendmap I made with noise.
Half a year later in October 2022 I got back to my terrain demo, which was based on Ogre-Next terrain sample.
Sources for it are there and I even made a gallery, it looked cool.
I also managed to build MyGui with Ogre-Next (forum topic) and with some help continued its fork, after some trouble later, it was fixed and started working well. This was likely the key point to start porting SR, while also knowing particles work, and my demo works smooth with better Fps and no lags for vegetation.
I then started porting SR still in Oct 2022 and calling it SR3 (3.0 was also latest Ogre-Next version). First by disabling almost everything in old SR code and making it build with Ogre-Next. Then by slowly restoring stuff one at a time and I mean really slowly.
It took months and literally almost everything was causing trouble or not working at first in Ogre-Next. It’s like normal developing, I mean I code then test and fix it to work (yeah the old way, no unit tests, seriously). On top of that, there were few annoying new bugs due to how Ogre-Next works and needed something extra to fix, what was already working normally in Ogre before.
In Feb 2023 MyGui started working and could be used in SR3.
Worse still, during my endless forum topic we found many bugs in Ogre-Next too. It’s like half of my problems end in one. A bit disappointing TBH, but that’s the way with software nowadays. It’s buggy and needs updates constantly. Which brings me to support aspect. If it was great I wouldn’t mind. And mostly it was, but lately I’m waiting 1-3 weeks for response and have many ongoing issues and unanswered questions. It’s a pity that it’s just (putting all contributors aside) mostly a one man’s project. Kind of like with SR too, especially after that one year when there were more programmers.
Last major features were: water and effects (like SSAO), probably the biggest thing. Worse still, it wasn’t developed by me, but mostly by scrawl (and others) back in 2013 or so. So I had to redo another thing in Ogre-Next by myself now. It was difficult but good learning experience. HLMS shaders, are big, complicated, have lots of code and variations, and yeah it’s much more difficult than just using a shader editor and putting together blocks or just installing a water add-on.
We still are missing a few essential ones like: soft particles and HDR with bloom, that old SR had around 2013 already.
Well this section might be of use and have some info. Not just SR3 history like above.
Meanwhile I did think about other engines and shortly looked at 3 of them. There is a big list on wiki too. And I did recently write a tutorial page on CG graphics its Engines section could be better too.
This is my personal view, and let’s keep in mind that I did look at them after SR was already made (took 5 years) and it has its own track / map editor made by me. It is FOSS too.
Bit older than UE I guess but also a huge hub for commercial stuff. Even the tutorial mini game had paid crap one could buy for it. That’s really the first thing that pops out instantly for me. I do hate commercial stuff. I guess you could find something “free” but its like looking for free money in city, roughly for me. It will only be a free commercial for paid stuff.
Sure you can find stuff made already like rivers, vegetation and what not but given that this has a price, it’s instantly not for me. And it never has any other license than “you can only use it for Unity”.
This thing certainly got on my nerves. Turns out I don’t even have a PC for it.
I started by trying to download. Nope, you need to get full sources with deps and then build them on Linux. I tried few times before I realized this needs over 100GB to complete IIRC. Yeah my SDD with OS is still just 128GB and the one new I got has just 512GB and doesn’t really have that much free space.
Whatever, the next thing was a real killer for me. When it finally started (after building for hours) it showed a tiny logo with a tiny text showing that it needs to build shaders, over 4000 of them. I can’t even. And it did compile them on like 6 CPU cores for 30 minutes. Seriously WTF.. and I don’t even use this term. I don’t know for sure, but it wasn’t just once that it had to do this. I remember few times that “building all shaders” time waste, possibly even on each new project created or so.
Well then I realized my PC (with 12 year old CPU) isn’t even in same era, UE5 would need you to first spend a lot of money for PC with latest hardware.. to probably still take a long to even start.
Needless to say it is also a huge hub for commercial add-ons etc.
If we look at SR which has over 200 tracks already and on average 1 of them is just 5MB, not GB we can see the huge gap. One demo in UE5 was 100GB.
I was pleasantly surprised to find waterways plugin for rivers and also seeing it’s MIT license. Feels like the proper way of doing stuff for FLOSS software and games like SR3. Would be nice to have it in SR for sure, but at least I can learn from it and even use sources if I ever find the time for this.
Well, getting back to Godot, it’s big, I don’t have much of experience. It has its way of doing things and may be even extended. But let me sum this all up next.
So let’s end this quick look around. Each game engine has lots of stuff. And I can’t even judge how long would I need to learn it, to estimate how long it would need, to port SR to it (any engine). And how would loading tracks look in it, or how much more complicated editing them would be. I’m pretty sure it’d be a waste of time and effort.
As for game simulation, I guess I could build as a DLL or something to run in it, but that just doesn’t feel right at all. I mean what for, so that I could use engine’s features sure, but I’d need to waste a lot of time (in total) for starting it, clicking everywhere, etc. Lastly learning its issues and their solutions. Every big engine has something specific to it and problems with some things for sure.
Meanwhile I already had a lot of code written to do what and exactly how I wanted it to be, e.g. editor for creating SR tracks.
Obviously it depends. It is a rendering (by rasterization) engine only. So contrary to the game engines listed above, you don’t get anything beside rendering, i.e. no physics (e.g. bullet), no sound (e.g. openal), GUI, scripting, network etc.
It is for advanced users / programmers.
This means you need advanced programming skills to use it fully. Right now I also believe it means you need to find bugs in it yourself too. Surely there are some still and the more I use it the more I find. And I’d expect it to have none OFC, sadly that’s not possible.
There is documentation for it, but I can’t say it is covering all topics you might need. Some features I needed later had solutions that needed to be found in older forum topics. This wasn’t easy since they’re old and I don’t know if it’s still valid and there is also plenty of unneeded text in posts.
And support? Yeah it’s nice and great when it happens but otherwise you’re left alone with it.
I also can’t say it’s popular. Seems it was much more earlier around 2010 and also the Ogre 1.x version is still more popular.
Good things last, it surely has many features, modern ones too like few types of GI, HLMS shaders, etc. It is low level, meaning it can give you more control and optimization. But I don’t have any comparison here, I haven’t used any other just older Ogre.
Surely there are others, eg. bgfx.
The biggest reason is really simple. I made SR in Ogre so moving to Ogre-Next sounded like least effort. Surely old Ogre changed and I got myself stuck to shiny material generator which again scrawl wrote back in 2013 or so. Meanwhile RTSS shaders got better in Ogre, and lately even got auto instancing.
I decided to skip all that and make a bigger step, biggest possible for better hardware and that was using latest Ogre-Next. Even with few things or components missing. It also featured auto instancing by itself which I liked most, secondly the new terrain has less batches too (more performance).