Ogre Forums

Smack me - that will teach me
I just had a look at the OpenDDL/OpenGEX code. That makes sense. And, as can be expected from Mr. Lengyel, the code looks well written.
That's actually better than I had imagined.

The only thing I'm not totally understanding with OpenGEX is what about the case where I have a scene composed of several separate scenes? It looks like in this case I would still have to define my own scene format which would reference OpenGEX files. Not a big problem though, but I feel like I might have missed something in the format that would allow that, maybe.

A scene composed of several scenes sounds out of the scope of what OpenGEX was supposed to solve.
Anyway, AFAICT ogex supports an arbitrary number of root nodes and may be workarounded.

Alternatively, you can indeed use OpenDDL to define multiple OpenGEX files within one file.

This is great news!
I've always wanted to contribute my own bits to Ogitor, but never really quite found the time for it. Perhaps this is a good opportunity to change that. I'll keep eyeballing this project for sure

One thing stealth977, only i want to ask how you did get an "Object/Component based" system, specially multi-threaded, some advice?.
I'm using my own C++ Artemis Entity/Component System implementation but doesn't feature any multi-threading feature...

@hydexon:
I would suggest checking Intel's smoke demo. I got inspired by it (though their implementation has some bugs)

stealth977 wrote:@hydexon:
I would suggest checking Intel's smoke demo. I got inspired by it (though their implementation has some bugs)

I downloaded the demo sources (Whoa, 147MB in .SDF files) but i'm pretty sure that system goes from here: Designing the Framework of a Parallel Game Engine from the Intel's Website.

hydexon wrote: I downloaded the demo sources (Whoa, 147MB in .SDF files) but i'm pretty sure that system goes from here: Designing the Framework of a Parallel Game Engine from the Intel's Website.

Yup, its the implementation of that article, and so is Ogitor with some differences:

- Intel's implementation executes Event Messages per MessageSender on multiple threads, which means multiple components of same object may receive messages at the same time, which WILL cause concurrency issues (especially since those components read data from the sender which maybe updating itself at the same time due to another message), Instead Ogitor re-Orders messages and send messages per receiver, so all messages that will be received by same receiver are cached and sent to receiver in 1 call (multiple receivers are notified in parallel), second safety guard is that the messages CONTAIN the data, so receiving object does not need to read data from another object that may be updating itself concurrently.

- Intel's Implementation uses 32bit mask to match sender's potential messages to receiver's desired message list. 32bit means only 32 different types of messages which is quite limited, instead Ogitor uses a message id list on both potential and desired sides, and check for intersecting messages, meaning 2^32 different message types can be matched, of course with more overhead

So far, overhead is not noticeable (not causing any bottleneck, if it does in the future, there are lots of possible optimizations)

Oh, i see the Intel's demo uses OGRE (an very old version) what a coincidence, this may help me A LOT. But anyway i'm very interested in your project Stealth!, (i'm hoping to release the 'Core' part of Ogitor, to compare which differences which has, and fix it, unless you give me clues where i should patch first).

Intel's Implementation uses 32bit mask to match sender's potential messages to receiver's desired message list. 32bit means only 32 different types of messages which is quite limited, instead Ogitor uses a message id list on both potential and desired sides, and check for intersecting messages, meaning 2^32 different message types can be matched, of course with more overhead

Intel Sacrificed variety for performance i guess?.

EDIT: Intel Smoke demo is cool, but has too Windows-Specific code, and is the threading part making for me some difficult, since i don't like touch the Win32 API.

Since we moved all Ogitor v2 discussion from our General Discussion sub forum to Team Talk, it does not seem to be any new updates on Ogitor v2, but actually Team Talk is quite busy and we doing a lot of progress each day. Since we are waiting for a usable beta of OGRE 2.0 to implement shiny visual components, there is not much improvement on graphics side. Instead we are working on improving core design, editor functionality and various OGF Systems.

So, I wanted to share an update so that you can see we are up and running...
Here you can see that one of the objects have Scripting::ObjectController component (check properties view). Also that component is using "player.as" script. You can see the script in the Text Editor. It defines a class derived from IObjectController interface and has its own variables and OnUpdate and OnMessage functions. That is how we gonna define object controller scripts (of course user can add whatever functions and variables and global functions, this is just a basic controller)

The result is, script Prints "hello world" + total_update_time every 2 seconds... (Print(...) function is a global test function that currently outputs to LOG)

You can also see that we are changing Ogitor User Interface:
- It is now fully skin-able through simple custom skin configuration files and custom icons
- Al windows inside editor are dock widgets, that can either float as a separate window or dock anywhere inside the main window.
- In the future, it will be possible to spawn new main windows for extra monitors, and move your docking windows between monitors.
- We are also exposing the UI to custom plugins, so user can add his own windows/toolbars/menus and tools to the interface through custom plugins...

Cheers,
Ismail TARIM

stealth977 wrote:Since we moved all Ogitor v2 discussion from our General Discussion sub forum to Team Talk, it does not seem to be any new updates on Ogitor v2, but actually Team Talk is quite busy and we doing a lot of progress each day. Since we are waiting for a usable beta of OGRE 2.0 to implement shiny visual components, there is not much improvement on graphics side. Instead we are working on improving core design, editor functionality and various OGF Systems.

So, I wanted to share an update so that you can see we are up and running...

OGF_ScriptTest.png

Here you can see that one of the objects have Scripting::ObjectController component (check properties view). Also that component is using "player.as" script. You can see the script in the Text Editor. It defines a class derived from IObjectController interface and has its own variables and OnUpdate and OnMessage functions. That is how we gonna define object controller scripts (of course user can add whatever functions and variables and global functions, this is just a basic controller)

The result is, script Prints "hello world" + total_update_time every 2 seconds... (Print(...) function is a global test function that currently outputs to LOG)

You can also see that we are changing Ogitor User Interface:
- It is now fully skin-able through simple custom skin configuration files and custom icons
- Al windows inside editor are dock widgets, that can either float as a separate window or dock anywhere inside the main window.
- In the future, it will be possible to spawn new main windows for extra monitors, and move your docking windows between monitors.
- We are also exposing the UI to custom plugins, so user can add his own windows/toolbars/menus and tools to the interface through custom plugins...

Cheers,
Ismail TARIM

Looks cool, but i have something to say, you would to change the color scheme of the script editor? (Like an Obsidian or Monokai?), just to fit with the whole theme and consistent...

Color schemes for the editor definitely sounds like a very good idea.

Great stuff!
But when you guys already starting a rework - any plans on changing the property grid to be more like in unity?

jacmoe wrote:/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

Funny guy
You make it sound like some sort of unwelcome medicine
"code suppository"

mmixLinus wrote:You make it sound like some sort of unwelcome medicine
"code suppository"

Code suppository is an homage to John Ratcliff.
But if it sounds too weird, or unwelcome, perhaps I should change it ?
<edit>
Just in case Google doesn't work for you: https://code.google.com/p/codesuppository/
</edit>

Wolfmanfx wrote:But when you guys already starting a rework - any plans on changing the property grid to be more like in unity?

I guess I really should download Unity.
We are open to anything that might help Ogitor look cool work efficiently.

Some update on Scripting in new Ogitor:

ScriptSystem IObjectController is now close to final. As you can see in the example script above:

1 - It has OnUpdate(...) function for regular updates, in which you can call sleep(...) to stop wasting CPU cyles for a while, or yield() to pause execution at a point till next frame and continue from there next thread...
2 - It has OnMessage(...) function to receive messages sent to this object.
3- You can also use self.PostMessage(...) to send messages

The message receiving and sending is based on subscription so the script provides 2 Message Map definitions:

array<int> <class_name>_MSG_MAP_RECEIVE and
array<int> <class_name>_MSG_MAP_SEND

application reads those MESSAGE MAPS during compilation of script and auto registers the component to listen to RECEIVE type messages and auto configures other components to subscribe to its SEND messages...

Wolfmanfx wrote:Great stuff!
But when you guys already starting a rework - any plans on changing the property grid to be more like in unity?

What exactly do you mean?

It won't be now, but I am thinking of implementing something like this: It's from https://code.google.com/p/braingl/ and with some additional styling/tweaking it could be extremely slick. Like live-coding

As i remember, QtPropertyBrowser component is able to do so, with individual controls instead of grids (Ye olde VS2005-style)

One annoyance with OpenGEX, there's no reference scene/model viewer to test with.
Apparently there's code to validate an opengex file (I think it's part of the import template package on their web site), but the only way to tell if an opengex file actually LOOKS correct is to buy C4.
I was going to add opengex support to my sketchup exporter (about time I did something with that), but if I export I have no idea if it is correct, until we get something like Ogitor supporting it.
I would have thought it would be simple to make a stand alone little C4 app that loads an OpenGex file and lets you move a camera around, for testing exporters.

The official blender plugin is export only, so I can't load an opengex file into it for testing either.

BTW, Yesterday I was going to make a Stress test of Ogitor v2 (actually the engine part: OGF) so I decided to create some random 250 objects in visible range (all are visible at camera position, not paged out) and all are animated using their own IObjectController scripts (that is not a normal case though, in a real scene not too many objects will be dynamic, here dynamic meaning using active scripting to control themselves).

So, I decided to code an internal function to auto replicate the selected object and create 250 copies of it, but GOD, I was sleepy I guess and did it wrong : the idea was to use 2 loops each 50 iterations to create those 250 objects (dont laugh I was sleepy when I was doing it)...So...Ummm...It created 50x50 = 2500 fully dynamic objects instead (ok now I know 50x50 is not 250!!)

Anyway, my little Stress Test became a real Stress Test

It was fun to see OGF running 2500 dynamic objects realtime (well it was 35 fps but not bad for a yet unoptimized engine)... I could clearly see where the bottlenecks are etc... And for the first time GraphicsSystem was not the bottleneck LoL

Considering Old Ogitor's design, it would never be possible to run even 1/10th of the objects in it...

NOTE:
The above test showed that OGF (Ogitor v2's engine) can make use of 3.1 full Cores processing power (I have 4 x 2.4ghz Cores on my laptop), which means we still have room for minimizing serially executed code to increase concurrency and CPU usage...

Thanks guys for the effort.
OGF sounds awesome.
[Actually this is one reason I did stop using Ogitor, because from the repositories it was clear that something component based was in the making so it made no sense to build on the old one.]

The new engine architecture inherited from Intel's Smoke demo is good, but very Win32 API threading API makes me stay away for now, but Right now i'm creating my engine in base of the Smoke demo, but i'll keep to use TBB because i like it and compiled OGRE 2.0 with TBB too, but i want to get rid of SpinWait class and the bitmask messaging system and Win32-specific API calls with another more flexible i see yours and creating every EventId seems no so viable for me i was thinking an "Category"-shorted event system which works with function pointers like this:

Why TBB?
I've always been into the POCO libraries - it's been a while since I visited the project:

[2014-12-22] Release 1.6.0 is the culmination of the work done on GitHub over the last two years, including five development releases. It includes major new features from new contributors, like the JSON and MongoDB libraries, much improved Data library, CMake support, as well as numerous other new features and fixes. A big Thank You to everyone who contributed to this release.

Sounds like music to my eyes. CMake!
It has all the useful things from Boost, and is not quirky and intrusive.
They have extensive multithreading, process management, networking .. http://pocoproject.org/features.html
However, Stealth977 loves to re-invent all the things - and that's probably why I am sticking to Ogitor.