Re: Suggestion regarding the recent changes to dtEntity

[Peter C.]

Well, that is both odd and a relief. I used the wrong email in posting that (also had some issues in actually posting it too). I did some further thinking and I think it may not be as easy as I first thought with said idea, and the level of abstraction needed to swap between Ogre and OSG may not exactly be worth it (I was in the heat of the moment right after waking up and seeing the commitlog, not exactly thinking clearly), however still, the OSG abstraction from the core is probably for the best. Still however, good call on abstracting OSG out of the absolute core functionality.

[Martin Scheffler]

Hi Peter,
welcome to the group!

I am planning to do these changes:
* create abstract interfaces WindowInterface, DebugDrawInterface,
InputInterface and move engine-specific stuff in there
* create library dtEntityOSG and move all implementations of these
interfaces there
* Also move most concrete entity systems from dtEntity core to that
lib. Only some entity systems will remain in the core, probably
MapSystem, TransformSystem, some others.

Entity systems like camera, light, mesh will have to be rewritten for
each engine. If they share a common set of properties then the engines
can be used interchangeably, although I am not sure on how far to take
that.

Any suggestions?

Cheers,
Martin

2012/7/22 Peter C. <th3f...@gmail.com>:

[Luca Vezzadini]

Hi all,
While abstracting functionality is in general a great thing, I'd like to
understand a bit better what's the real goal behind doing it for the 3D
engine. While for a project like Rocket it makes sense not to be tied to a
given 3D engine (because that's a commodity), is that true for dtEntity as
well?
On one side it would be cool to have a game engine that can swap the
underlying renderer. But what is the cost for that? Are we sure the
cost/benefit ratio is worth it?
In my humble opinion, the closer a game engine is the renderer (and the GPU)
the better the performance can be. Also, choosing an engine will of course
drive the whole engine design (think for example of all your components that
map directly to OSG nodes now). Abstracting low-level things may imply a lot
of abstraction layers which will cost both in terms of performance and of
dev effort.

If the goal behind this transition is to target platforms where OSG is not
available yet, maybe it's easier to build something dedicated to that,
reusing code but as a second project. Same probably for things like WebGL.

As a side note, internally Ricky and myself have thought about that for a
long time while building out platform; we came to the conclusion that
assuming OSG as a mandatory dependency is the best approach, considering
performance and available dev resources. This does not necessarily apply to
dtEntity also of course, so I'd like to hear from Martin.

My 2 cents,

Luca

[Peter C.]

On Sunday, July 22, 2012 2:48:17 AM UTC-4, choco wrote:

Hi Peter,
welcome to the group!

I am planning to do these changes:
* create abstract interfaces WindowInterface, DebugDrawInterface,
InputInterface and move engine-specific stuff in there
* create library dtEntityOSG and move all implementations of these
interfaces there
* Also move most concrete entity systems from dtEntity core to that
lib. Only some entity systems will remain in the core, probably
MapSystem, TransformSystem, some others.

Entity systems like camera, light, mesh will have to be rewritten for
each engine. If they share a common set of properties then the engines
can be used interchangeably, although I am not sure on how far to take
that.

Any suggestions?

Cheers,
Martin

Yeah, that's actually a good idea overall. My initial thoughts were the same, however I then thought about something similar to what Luca said below.

On one hand, you're completely right, on the other hand, I don't think that absolute performance is needed as much as flexibility. I was initially thinking about exactly what Choco is thinking, and the reason is a combination of the lack of support for some platforms using OSG, and also the fact that OSG has a *ton* of static analysis errors, over 9000 on my last compile alone.

The big fear I have with separating it out, in addition to Luca's comments, is that it becomes too fragmented, and to fractured.

[Martin Scheffler]

Hi all,

I would like to clarify the steps I want to take with the redesign.

I am using dtEntity at work for several projects. My company has done
a huge push to make everybody use a single commercial game engine.
While I have some projects that won't switch away from OSG because of
data workflow issues and other reasons, I will definitely have to make
the jump soon. I could now completely start over on all those projects
rewriting them with the tools of the new game engine, or I could
simply swap out the graphics part of dtEntity, keeping the "business
logic" of the applications. My projects are not graphics-heavy (more
like pushing around meshes in space), so replacing the graphics part
is the easier way for me to go.

I have just done some more commits, abstracting the interfaces to
debug draw, window and input system.
What still needs to be done is create dtEntityOSG and push all osg
relevant entity systems there.
I plan to keep map, layer, layer attach point, audio systems in core dtEntity.

And that's about all I will have to do. I don't plan to rewrite the
camera and light systems to somehow abstract away the game engine,
they also won't implement abstract interfaces. I will simply write a
new set of entity systems for the new game engine. And if the new
camera component also has position, up and eye direction properties
then it is even compatible on a map level to the OSG camera component.

Then I can use the map storage system, the Qt widgets, the javascript
bindings and all the other stuff for the new game engine, while being
completely free in the set of graphics features I want to support.

About performance: Using virtual interfaces adds some overhead, but I
think the methods of the abstract interfaces won't be called hundreds
of times per frame, so it won't cost that much.

Also maybe it is possible to make the compiler optimize away the
virtual function calls:
http://fabiensanglard.net/doom3/index.php - search for "idTech4 high
level objects are all abstract classes with virtual methods".

This will probably only work for code in the main lib, but still.

Cheers,
Martin


2012/7/23 Peter C. <th3f...@gmail.com>:

[Peter C.]

If I may make a suggestion from looking at the current progress, what do you think about using the Bitsquid method? http://bitsquid.blogspot.com/2012/03/pimpl-vs-pure-virtual-interfaces.html

[Martin Scheffler]

Hi Peter,
I read the article and didn't find what you referred to as the
bitsquid method. Do you mean PIMPL? Or having create() / destroy for
virtual interfaces?

Cheers,
Martin

2012/7/24 Peter C. <th3f...@gmail.com>:

[Peter C.]

Basically I was referring to the virtual interfaces being fairly barebones, and allowing the implementation to handle the rest. I realized a little bit in that may not be the best idea completely.

[Peter C.]

I figure I may as well clarify what I said. My initial thoughts were that the abstract interfaces should be just destructors and constructors. The problem I saw was that the implementation would become hard to work with when dealing with things where you want something common as a way of referring to something across systems. The bitsquid method from my understanding would have something where you register a type of object, like a mesh, and then you have a component, such as a osg mesh, be say "hey, I'm a mesh type object", and then you can have various implementations working together easier. For example with one thing I was looking at, I was looking at implementing OIS and OISb ( https://code.google.com/p/oisb/ ) as a method to work with inputs. With the bitsquid method, you register something as a button press, and you can just say "was this button pressed?" and it disregards the implementation specifics, only looking for the fact that the button was pressed, and the plugin handles the implementation level stuff.

[Martin Scheffler]

You can simply implement the InputInterface and have your
implementation use OIS to query the buttons. Then in your app you can
call dtEntity::SetInputInterface(new OISInputInterface()). And if you
want to access methods specific to OIS you can just static_cast to the
OISInputInterface class.

2012/7/25 Peter C. <th3f...@gmail.com>: