Atomic Game Engine (MIT Urho3D Fork)

Announcements and news updates to your projects using Urho3D.
Forum rules
If you have images or videos, you can attach them in the showcase post. Please use small thumbnail as link to original media resources.
When you post in this forum, you have to agree that Urho3D main website as well as the Facebook page have the permission to republish your post with all the related images or videos. The original images must have width larger than 890px for best viewing result in all the supported viewports by main website.

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by gawag » 19 Mar 2016, 06:27

cadaver wrote:Urho does the same as Unity which allows to put script / logic hooks to physics update substeps (FixedUpdate), which makes it rather hard to implement physics in a separate thread. If we disallowed that, then it could be threaded, provided there's added synchronization, but again it's a performance <-> usability tradeoff.

That hooking vs. threaded physics and AI option could be switched with a CMake option and defines for 0 runtime cost and proper compiler errors (non existing functions). Or those functions are actually called in separate threads... I still would suggest an optional option as one has to pay more attention when working asynchronously.

cadaver wrote:When you program in C++ you can go crazy with your own background-threaded algorithms
...


I've also been thinking about what options there are.
Someone on the IRC posted this technique: http://www.panda3d.org/blog/triple-your-frame-rate/
I've seen that technique before somewhere else, it splits the independent rendering steps into different threads to have three "slices".
Could that be done with Urho as well?

About other ways to multi thread stuff: I came up with two possible ways.
One solution is the job scheduling that you mentioned the Unreal engine uses. Such a job queue sounds rather complicated and like having a real overhead.
The other possible solution I came up with is to partly synchronize threads with mutexes and/or conditional variables. All the stuff that can only be done at a specific moment (when no one else is modifying the scene for example) is done in serial and not parallel. I would have to look into mutexes and conditional variables again but it's kinda like this:
Code: Select all
void NonMainThread()   // multiple threads do this, like for AI, physics or whatever
{
    // plan all operations like pathfinding and the actions to do
    ...
    MutexGuard mg=MutextMainThread.GetMutexGuard();    // wait until the MainThread is ready and lock a mutex via a RAII mutex guard
    // execute all planned actions in this serial part (AKA "synchronized part")
    ...
}   // the mutex guard is destroyed and automatically unlocks the mutex to get back into parallel mode
...
void Update()   // main thread
{
    ...
    MutexMainThread.unlock();  // let every waiting "worker thread" do his planned actions in serial. Every worker thread should
                               // do only one "set" of actions (not unlock, replan and lock again -> possible deadlock).
    MutexMainThread.lock();    // go back into parallel mode
}

I assume the non-main threads can do stuff like scene manipulations if it is synchronized like that with the main thread? Or is there some weird thread ownership like Qt has?

The second method is pretty manual and avoids a possible giant and slow job queue. Also it is more flexible as it can do everything and doesn't have to rely on special actions queued (depending on the implementation).

All variants I can think of are not that easy/"idiot safe" as a scene change (or another non-thread-safe action) may still be tried in the parallelized part and not the serial part where it is actually safe.

EDIT: for those interested, I looked a bit more in detail how UE4 does things:

Hehe :P
This interesting "problem" occupied me as well since the multi threading idea came up. Had a partly written reply lying here since then and kept thinking about it.

Is it safe to read from the scene (like node positions or doing raytraces) when the main thread is rendering? The parallel mode has to be entered for every non-tread-safe operation of course. Usually most machines do also have atomic operations where expensive mutexes can be avoided but I doubt we can really use that as most stuff requires multiple operation without someone getting inbetween. BTW: on x86 every read is atomic even without using the special atomic instructions (manually or via C++11 std::atomic).

Edit: I think the synchronizing has to be done with a mutex for every thread that is unlocked by the main thread when it can do one "set". Has been quite a while since writing my last thread pool or something similar. But unconditional variables had been also required for something in that direction...
Edit2: Oh! I thing the conditional variables are required when one doesn't want to lock the main thread and just lock or unlock worker threads. Which is not the case here so it should work with simple mutexes. If I'm not mistaken.
Old Unofficial Urho3D Wiki: http://urho3d.wikia.com/
"Newer" Unofficial Urho3D Wiki: https://urho3d.miraheze.org/
My GitHub: https://github.com/damu (changed my name recently from gawag to damu there)
User avatar
gawag
Active user
Active user
 
Posts: 192
Joined: 12 Feb 2015, 03:48
Location: Germany

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by cadaver » 19 Mar 2016, 10:46

We already have a simple job system in Urho which is used by the rendering and animation, and you can also use it for your own tasks. There is no dependency tracking for them though.

In general it should be safe to read the scene, at least if you're sure that the main thread logic isn't simultaneously destroying the scene nodes or components you're accessing. Just be aware the reading a node's world position can actually trigger modifications when it has to refresh the position from the node hierarchy, but that should converge to the same result even if being called from multiple threads.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by boberfly » 23 Mar 2016, 21:00

Hey cadaver,

You might know of this one already, but I always found this engine's concept of making everything a task (and the YaTS taskpool) to be really interesting:
http://bouliiii.blogspot.ca/2011/11/point-frag-distributed-game-engine.html
https://github.com/bsegovia/point-frag/blob/master/src/sys/tasking.hpp

Stealing the thread here, but I thought I'd mention it as we're comparing other engines and their approaches...
User avatar
boberfly
Active user
Active user
 
Posts: 107
Joined: 27 Mar 2014, 01:14
Location: Australia

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by cadaver » 24 Mar 2016, 10:37

Thanks for posting! I've been searching for "next-gen" open source engines having e.g. an advanced threading setup, this may well be worth a look.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by boberfly » 24 Mar 2016, 19:45

Raytracing occlusion culling is also interesting, it might be faster in a small buffer with a fast BVH structure than software raster occlusion culling, like his blog suggests and more threadable and more tolerant to higher poly-count occluders. Maybe throwing something like Embree at it might do the trick... :)
User avatar
boberfly
Active user
Active user
 
Posts: 107
Joined: 27 Mar 2014, 01:14
Location: Australia

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by jenge » 08 Jun 2016, 21:35

Image

Hey all, lots of good stuff going on with Atomic. There have been significant updates to the Atomic Editor under Linux over the last couple months. It is still a work in progress, though is getting closer to having a binary distribution :)

We have improved TypeScript project support, including compilation of TS in the Atomic Editor!

Image

There has also been work on better API docs, http://docs.atomicgameengine.com/api/modules/atomic.html as well as a bunch of other updates and bug fixes.

There is now a "Master Builds" section on the download page for recent editor builds with Windows, OSX, Android, iOS, and WebGL deployment, with Linux being in progress. This will be automated, however for now it is still best to strategically select a commit :) http://atomicgameengine.com/download/

I really want to apply some focused work on getting the Atomic and Urho source trees closer together, as to facilitate easier code migration between them. This is a pretty big task at this point and probably needs to be broken up into stages.

- Josh
User avatar
jenge
Some active
Some active
 
Posts: 72
Joined: 27 Apr 2014, 15:42
Location: United States

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by jenge » 15 Jul 2016, 21:20

Hey all,

I've been putting a lot of work into C# scripting, here's a look at realtime C# inspector fields with the Monaco code editor from VSCode, which is integrated via the Chromium WebView :)

Image

The editor also integrates with Visual Studio and VSCode and the tooling is capable of generating solutions, here's the same project in VS:

Image

Atomic supports JavaScript, TypeScript, C#, and languages that ride on JavaScript and C#, like Haxe/CoffeeScript/Etc. This is a look at the TypeScript project support with full intellisense provided by Monaco:

Image

There has also been work on better Android deployment from the editor with support for release apk's:

Image

Whew! I am looking forward to merging Urho master soon here, it has been some months and a goal is to get the codebases closer together. The graphics agnostic headers will be a huge win as well :) :) :)

- Josh
User avatar
jenge
Some active
Some active
 
Posts: 72
Joined: 27 Apr 2014, 15:42
Location: United States

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by rku » 16 Jul 2016, 06:22

I usually say that integrating with existing IDEs instead of reinventing the wheel is better but wow.. this does blow away your mind.. Not many engines can boast script editor with full autocompletion, syntax highlighting etc.. Even if it is made in javascript ;) Truly amazing work.

I really want to apply some focused work on getting the Atomic and Urho source trees closer together, as to facilitate easier code migration between them. This is a pretty big task at this point and probably needs to be broken up into stages.


As reiterated multiple times in this thread - urho3d could benefit from c++ editor immensely. Since you atomic engine has such thing and engines are basically brothers maybe it would be in the realm of possibility for engines to share at least that part? I bet cadaver would be very happy if that happened especially since atomic editor has way more features and is written in c++.
User avatar
rku
Active user
Active user
 
Posts: 103
Joined: 06 May 2015, 08:24

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by cadaver » 17 Jul 2016, 10:32

If the editor code comes from Atomic it still doesn't change the fact that it would need a (mostly) steadily contributing developer to handle updates, required Atomic -> Urho changes and editor issues. I assume it will be less work than writing an editor from scratch, though.

However what makes greatly sense to me is to think of Atomic as the IDE and project management built on top of Urho, instead of reimplementing those in Urho. It isn't exactly a reality right now since Atomic has grown so different and has a different featureset in some respects, but it could be that way if the codebases are brought closer.
User avatar
cadaver
Urho3D author
Urho3D author
 
Posts: 1802
Joined: 16 Jan 2014, 14:52
Location: Finland

Re: Atomic Game Engine (MIT Urho3D Fork)

PostPosted by jenge » 17 Jul 2016, 16:28

The first version of the editor was solely in C++, though as soon as we had mature UI script bindings and especially TypeScript support, the UI was rewritten in TS. Atomic has a "ToolCore" library which is shared by command line tooling and the Atomic Editor. So, asset handling, etc are in C++ and steered by script.

Atomic is geared to be a production tool for shipping apps and games. This means we have deadlines that Urho does not and I don't foresee Atomic and Urho merging. Though, it should definitely be easier to move code between the two, or other forks of them.

Urho has proven a great base to build on and even after all this crunch, I still love working with the code. I am so going to make a game with all this stuff! :D
User avatar
jenge
Some active
Some active
 
Posts: 72
Joined: 27 Apr 2014, 15:42
Location: United States

PreviousNext

Return to Showcase

Who is online

Users browsing this forum: No registered users and 0 guests

cron