Hello all RoR fans.
Late as usual, I bring you an overview of development done during May.
I'm happy to state RoR has a healthy pulse. The GitHub repository is greatly helping our development. The issue tracker is receiving a lot of submissions from users testing our latest builds, and the dev team does their best to attend to and resolve them. We're also receiving stars and attracting new contributors.
Hiradur worked hard to set up Travis CI for RoR. It's a continuous integration service - it builts RoR regularily under linux to see if build passes OK. This is very important for us since we maintain both windows and linux compatibility, and from time to time, some windows contributions (ahem, mine...) break linux build.
Max98 had a great idea to set up Gitter discussion board for RoR. Gitter is a browser based chat service directly linked to our repository. Great place for developers to meet each other and other community members to talk about technical aspects of RoR. And, it's already attracting new people who may contribute important knowledge to the project.
It's still in development, there's still no release date and the purpose has slowly and silently changed. Original plan was to only make RoR stable, content-compatible and crash-free while ignoring performance and not adding any features. However, volunteer-based development progresses slowly and players are equally concerned about performance, stability, graphics, performance and gameplay experience as a whole. And yes, I know I wrote "performance" twice. So, the new motto of 0.4.5 is "All kinds of improvements, as long as nothing gets broken and it runs at least a little faster than before".
The fix of the month are definitely FlexBodies. Somewhere between 0.39 and 0.4.0x they became malformed, as reported in this issue. In test build 3, they are corrrect again and faster than before, thanks to Max98.
Another improvement is speed of vehicle loading. During testing, I got angry about vehicles taking too long to load, so I incorporated a tiny profiler into the codebase and started investigating. The major bottleneck were verbose logs I added to the spawn process. I added config options for them and made them disabled by default. Next, it got interesting - the bottleneck were FlexBodies, but curiously, not their generation, but finding LOD files in OGRE's resource system (which is super slow and targeted for elimination by OGRE team, btw). Since nobody seems to use the feature, I added config option to disable it by default. Next bottleneck was flexbody generation itself and I found a way to bypass even that - I added a cache support to flexbodies, so they are only generated once and saved as binary file to cache, subseqent spawns load it from the cache. Right now the feature is disabled by default, see file /resources/skeleton/conf/README.txt for instructions how to enable and test it. I have to say I'm quite proud of this improvement and I'm planning to use it in more areas of RoR to speed up loading even further.
I've done enough dreaming in the last devblog post. Now I'm back to the boring but necessary fixing of vehicle/map compatibility. Current work: fixed objects on maps. But I can't resist the urge to slowly enhance the rig editor as well. Current work: flares. And finally, I also began attending to performance issues. Current work: adding a performance graph window to help pinpoint the bottleneck on various player hardware. This makes the development somewhat fuzzy and unfocused, but it's the best answer to the requests from the community.
Have fun playing RoR!
Hello RoR fans.
Another 2 months have passed and 1 new progress report is here. It turned out everyone (including me) was so busy in march that barely any development happenned and I had no time to write a blog post (plus, nothing new to write about, really ). Fortunately, April has been much more relaxed and I've been able to do some very important progress. All of my latest changes are incorportated in 0.4.5.0-dev test build 2 - I encourage everyone to test!
Vehicle compatibility status
... has improved! I tested with many more vehicles and I re-thought my approach to parser design. For one thing, I began loosening the very strict syntax checking which was causing vehicles to spawn crippled and littered the "spawner report" window with loads of warning messages. Very common mistakes, such as extra commas at the ends of lines, trailing comments (yes, they weren't legit), invalid flags and bad lettercase of keywords is now tolerated, often silently without warning message. Further, I began adding "fallback" method of parsing for lines which don't make it through the syntax check - in this case, parser will emit a warning and process the line by means of RoR v0.38/v0.4.0.7 - unsafe, but mostly workable. So far, "nodes/nodes2" were augumented this way.
But most importantly, I changed my philosophical approach to processing the .truck format. From the very start, I knew that the parsing process used in 0.4.0.7 has to change, both to clear the way for further development of RoR's physics (the old parser was seriously blocking it), and also because I wanted to equip RoR with a built-in rig editor. However, at the same time, I needed to maintain compatibility with existing content. Until now, I've been trying to write a parser which would satisfy both requirements. It didn't really work, most vehicles got broken and I wasted a lot of words rambling about how bad was both the code and the truckfiles. But about a week ago, I finally concluded the parser I wrote suits my needs, but it will never fit together with existing content. After realizing this, it was obvious what I have to do: Declare a new fileformatversion for future content, and write an importer component for content with lower fileformatversion. For the new fileformatversion number, I chose "450", to resemble version number 0.4.5.0 and also to signify it works differently than older numbers (1,2,3) - those were just informational and the parser ignored them. My fileformatversion actually makes a big difference.
Nonetheless, I began bumping into prevailing v0.38 -> v0.4.0.7 incompatibilities, such as this one. Those will be harder to tackle because the code of version 0.38 is 4 years old and uses outdated dependencies, so it'll take some time to create a working dev version for testing and investigation. I'll try my best, but no promises at this point.
Again, I encourage everyone to download a test build and check his favourite vehicles. They should work a lot better now.
Rig editor status
The editor is still not usable, but it's progressing steadily. This time, I added support for wheels (meshwheels2 + flexbodywheels so far). There's a selection menu in the top menubar and panels which can alter wheel parameters. Changes to wheel size or number of rays are displayed immediately and you can select + edit multiple wheels at the same time. There's also an option to create a new rig from scratch and the "engine" panel was equipped with [add engine]/[remove engine] buttons which were missing before. The N/B editing controls are still not complete (you can delete beams, but you can't add them yet), but work is being done. Further, the wheel-subsystem components (selection menu, highlight boxes, panels) were created as generic, so there will soon be similarly implemented support for flares, props, wings and more features.
Anyway, at this point, some of you may legitimately question my efforts to create the rig editor. Although it's a nice thing to have, it doesn't seem to be really needed, modders have been happily creating content using existing methods and without any apparent issues, as this forum thread shows. So, do I have good reason to burn a lot of time working on the editor when there are much more serious flaws to tackle? I believe so, and you deserve to know it.
Physics of the future
Currently, RoR can handle roughly 500 nodes + 3000 beams per vehicle. With so few elements, it's reasonable to do this work manually. However, this system leaves a lot to be desired - the soft body physics model (with weighted nodes acting like joints + weightless beams + stability requirements) is very hard and unnatural for a human to work with. Also, the RoR handles only enough N/B to create a grid-like chassis where 3d models can be attached (props, flexbodies).
Now imagine I created a completely new physics engine which could handle roughly 10x more N/B than the current engine (think 5,000 nodes and 30,000 beams). These numbers must sound insane to RoR veterans, but I have good technical reasons to believe such performance can be archieved. Further details aside, you'll agree with me that creating so detailed N/B by hand (or in Blender, or Editorizer, or any other similar method) will become humanly impossible. Further, such performance increase will deserve new approach to N/B architecture - instead of modelling a vehicle as a whole, it will be possible to model individual components (rigid frame, soft interior, heavy rigid engine, outer chassis components, possibly a rollcage) and then join them to create more reallistic deformation behavior.
There is only one way to deal with such a modding challenge - using a CAD-like editor where the vehicle can be modelled the way technical engineers do - by defining real-world shapes of components, materials and means of joining components together. The editor would then compute the best fit N/B to simulate such vehicle. And THAT is precisely where I'm headed in my rig-editor efforts. Currently, the editor has only partial support for hand-editing the N/B, but that's just something to start with and an utility for current modders + current content. But I'm really looking into the future, and the future is CAD.
Naturally, this is only an enthusiast project done in people's free time. It may not succeed. But I'll incorporate enough scripting support to spread the implementation complexity among members of the comunnity, so everything will be archievable. I'm optimistic.
Until then, please bear with me.
Updated 05-02-15 at 10:51 PM by only_a_ptr
Hi all RoR fans!
Another month has passed and it's time for me to write a progress report. In fact, the report is already slightly overdue because I've been really busy lately and I could only hardly follow RoR development. However, there are several other active developers and a growing number of testers and bug-reporters, so the project is steadily improving.
To shortly iterate what's been hapenning:
I've been working on rig editor, specifically adding panels to edit properties of nodes/beams and other beam types. Currently I'm adding support for all types of wheels, including the possibility to add/edit/delete wheels. I've also started several experimental dev branches oriented on performance and more maintainable code.Hiradur continues to improve linux compatibility and maintains the multitude of RoR dependencies.Aperion has returned to what he's good at - improving the very core of the gameplay, the physics simulation. So far, he's only been doing careful cleanups not to disrupt the upcoming stable release, but there seems to be a lot to look forward to.Max98 is simultaneously improving many player-oriented aspects of the game, ranging from UI and HUD through enviromental improvements like skies and water to signifficant gameplay fixes.
Status of planned 0.4.5 release
Current development effort aims towards a stable release with version number 0.4.5. This long-awaited release will fix many long-standing bugs, bring UI improvements and generally enhance player experience.
The major development problem regarding this project is vehicle support. In the past, version 0.4.0.x broke compatibility with older vehicles and forced modders to double-release their new content. Then I came and broke things further, despite I claimed to improve it. Up to now I wasn't able to completely restore all broken features, although situation is improving. Recently, RoR got a new window which displays all errors and warnings about about loaded vehicles. Thanks to Max98, the messages are also colored. This window will inform players what's wrong with their favorite vehicles and also help modders to avoid risky or unsupported practices.
I'd like to explain the cause of the current situation. When I analyzed RoR's vehicle loading code back in 2013, I discovered that the problem is in the design of the format - modders can define various parts of the vehicle (beams, nodes, wheels, cinecam, rotators, triggers, more wheels, more beams) in an arbitrary order, possibly interleaving things, and the parser will process all of it in the exact order. A software like this is a programmer's inferno because it's impossible to tell how exactly things are going depend on each other, how they will interact and what side effects may arise. Since RoR's vehicles were quite feature rich and features were built on top of one another, the amout of possible scenarios was astronomic. To name a few cases, I've seen vehicles defining some nodes, then defining wheels (which generate nodes) and then define more nodes. But hey, nodes have numbers, and if you auto-generate nodes in between, are you sure your numbering will continue correctly? Further, some modders attached beams to nodes before those were defined, or to nodes which were auto-generated by different sections (or possibly never generated). How is a programmer supposed to check if the connection is correct? To make things worse, there's the half-baked 'named nodes' feature (nodes2). More than half of truckfile sections don't support them, but at the same time, named nodes can still be reffered to with numbers, so modders did it that way. As a result, a programmer sees code trying to look for node 123 and he has no idea where that node will come from. Impossible to work with. Despite all these alarming facts, RoR vehicles have been working happily... until original authors left, along with the knowledge of all quirks and obscure mechanisms of the vehicle support. Un-involved coder didn't stand a chance. That's why 0.4.0x became incompatible with 0.38, and only problems followed.
My solution to this issue was developing new vehicle parser: one that would read all data first and only then process them, in a given order, to avoid all unexpected results. From software design standpoint, this is an only plausible solution. Unfortunately, this approach broke all vehicles which relied on the quirky nature of the old parser. In addition of that, many bugs were introducted in the process, because RoR's vehicle format is very feature-rich and I was a new coder to the project. So far, I've been able to track and fix many of those bugs and also detect and work-around many legacy requirements of older vehicles. I had been hoping to work around everything, however, I've arrived to a point where some vehicles directly conflict with my parser's architecture. And even thoug I'd really love to make everything work, I'm not willing to compromise future development by making compatibility hacks into my code. Some content will just have to go.
In a near future, I'll publish a new test build of NextStable, along with all latest fixes and compatibility enhancements, and I'll begin to sort out supported vs. unsupported content. I'll be in touch with modders, discussing the do's and dont's which 0.4.5 will impose.
Updated 03-08-15 at 12:15 AM by only_a_ptr
I was just bored, decided to post few little screenshots of what's upcoming with RoR 0.4.5 (Aka 0.4.0.7 NextStable)
The change log is being updated but it is visible here: Changelog
Something new here, the Main menu!
The rig editor:
(loading a vehicle)
(ingame key mapping)
Pause menu: (And possibility to change maps/go back to menu without exiting the game)
Updated 02-21-15 at 12:05 AM by max98
Hello all RoR fans!
My name is Petr Ohlidal (a.k.a only_a_ptr) and I'd like to give you an update on RoR development in the past month. I'll also sum up all activity which has been going on since I joined the project - and there is a lot to sum up, RoR has changed signifficantly since then.
I joined the project in fall of 2013. At the time, RoR was a dying project - the original authors left to develop a commercial BeamNG project and community had been inactive for more than 6 months or so. The last stable release was 2 years old and the new version was half-baked. I evaluated the state of the project, decided my priorities and started coding. For the first months, my effort had no visible outcome as I decided to rewrite some very internal logic, but finally I released several test builds and today, they're consolidated into a single development version which aspires for a new stable release.
To my great cheer, my enthusiasm has sparkled a new wave of collaborative development, and today, RoR has 4 active developers:
Me ~ Self-invited lead coder, a code greasemonkey focused on internals and software architecture.Max98 ~ Cheerful enthusiast with focus on GUI and graphics. Fixed some long standing graphic bugs.Hiradur ~ Valuable compiler specialist and analyst. Keeps RoR running on Linux and inspects it with Valgrind for memory issues.Aperion ~ Old community member and contributor who came back to help.
At the moment, the development is aimed towards delivering a new stable release. This is very important to shake off the "dead project" feeling. RoR hasn't had a stable release in years and with new similarily-themed projects, BeamNG and SpinTires, it seemed that RoR will become history. That is, however, not going to happen. Not only RoR lives on, but it also stays unique among all competition. The planned release is dubbed NextStable and has a version number 0.4.5, which displays the signifficant leap from last available build 0.4.0.7. This leap is well deserved, RoR has undergone a signifficant facelift and got rid of some long standing bugs which annoyed and discouraged players for too long. Also, major refactoring was done on the inside, to serve as groundwork for future enhancements and stability. This is a list of the most important archievements:
RoR got main menu! Until now, RoR worked in a straightforward scenario "start - select track - select vehicle - play - exit game", which wasn't really player-friendly. Also, the internal startup logic was over-complicated and slow, so it received a lot of fixes. Courtesy of Max98RoR got new GUI skin. The previous "orange with bright orange" was really lame. New one comes in orange+black and really feels like a vehicle-driving game. Kudos to Max98RoR got in-game configuration panels. Previously, all the configuration had to be done in external configurator, which works, but it's not very appealing to players. Thanks goes to Max98RoR got a built-in editor for vehicles. Until now, modding had to be done with variety of external tools and a lot of hand-writing. However, this approach will soon be history. The editor is not fully featured yet, but it's architecture allows it to fully load/save the vehicle format and perform any modifications, with mouse and hotkeys, in an interactive environment. A primary inspiration for controls and workflow is Blender.Rig definition file format (.truck) was completely re-coded. The old logic was flawed, bloated and effectively blocked any future enhancements. The new one is a separate component designed for stability and extensibility. It also allowed creating the rig editor. However, a lot of content stopped working in the process, sometimes due to bugs in new code, but often because of syntax flaws or inconsistencies and bad practices in .truck files themselves. Work is being done to fix the situation.Max98 fixed two inflamous graphics bugs - shadows and skidmarks. He's also putting a lot of attention into sky, water and environment in general.
Following is a list of things to definitely expect in NextStable:
It will provide a list of errors and warnings every time a vehicle spawned. This is mainly to help modders, but also to inform players of possible incompatibility of older content.It will support most of the vehicles which are currently broken. Sadly, some of them will not be compatible due to legacy flaws or bad practices of mod authors.Not much else to change. This is actually a good feature, because more changes would mean more waiting and I know everyone is already tired of waiting.
Actually, if you feel like NextStable is coming out pretty slowly, it's not just you. I've been putting off the work for a long time because, honestly, bugfixing is boring and there is a lot of juicy redesign waiting to be done in the simulation code. So, instead of delivering what everybody is waiting for, I've been fiddling with the internals in my private development branches. Sorry guys. However, no more slacking off, I've published my experiments in my GitHub forks, consolidated my changes and I'm back to bugfixing.
From now on, I'll be publishing a progress report blog post every month. This idea came from Max98, big thanks to him, a dev blog is a big step forward in presenting the project. Expect future posts to be a lot more detailed and to the point, this post is somewhat bland because it just has too much to sum up.
With the blog section now being back alive I though I'd give it a shot and write about my personal goals for Rigs of Rods. Every developer working on an open source project usually has his own vision for what the project could become and works on things that bring it closer to that vision.
So here it is, my vision of Rigs of Rods:
I would like to see RoR going much faster than it currently does. RoR is usually limited by the CPU as it has to do a lot of floating point math to simulate the behaviour of beams and nodes. Other limiting factors probably are memory latency and bandwidth since structures for beams and nodes are quite large in size and there are hundreds of them per vehicle. Besides the fact that the whole phsyics core could use a cleanup it is also required that we increase accuracy (discussion: Discussion-Moving-to-double-precision-for-physics) to improve the quality of the simulation. When we do that a major overhaul of the physics core is needed which would be a great chance to improve performance as well. I believe that there is more room for parallelization and that we should use it whenever possible. In the best case RoR should be able to max out any number of CPU cores while still running significantly faster on a single core than it does now.
Besides a speedup in performance I would also like to see the physics calculations being moved to the server. The details are unclear yet because it would suddenly increase server hardware requirements a lot. Maybe we will have an option to toggle serverside physics on and off.
The major benefit of serverside physics calculation is that multiplayer collisions are possible, something that many have asked for and I want to see happening myself. It would also lead to a clear separation between client and server, potentially putting less stress on the client than before. We will have to see how much that could be since some calculations will probably still be needed clientside for movement predicition to reduce perceived lag. It would certainly seperate rendering and physics though, already increasing performance.
I got access to an 80-core cluster computer. My ultimate goal is that the RoR server (with physics calculations being serverside) is able to take advantage of such a system. I would like to see it being able to make use of all cluster nodes using OpenMPI to spread physics calculations across all cores so we can potentially have many people spawning many vehicles in one multiplayer session. In case this becomes possible I may host a community event, hosting a RoR server on said cluster for an evening to have a big wreck fest. It's still uncertain if this is possible at all. The possible degree of parallelization for the physics core has yet to be determined. When working with clusters additional problems arise like latency and bandwidth for communication between nodes. The latency could be large enough to make this whole project fail but since a similar project probably has never been done before we can't know for certain until we tried.
So, to summarize:
- large performance increase
- ability to make use of any number of CPU cores, if possible
- serverside physics calculations
- OpenMPI support for use on clusters
Keep in mind though that this is just a vision of mine yet. Work hasn't even started and it will probably take a while until it does since we would like to provide a solid new stable build first. Some of these things may not even possible or won't ever come to life. We'll have to see what the future holds.
Man, time sure flies, Rigs of Rods is nearly 10 years old!
I just updated some things: The-future-of-the-RoR-forums-I-don-t-know-what-to-title-this
Updated 01-15-15 at 01:49 AM by tdev
Just having some awesome fun with greate FPS.
Yes it is leopard print.