Hy. I must create a simple architecture project for visualize and present some internal scene of arredament. The program have a lot of presentation type(wall trasparence,rotate , quote ecc...)of the geometry ,some calculations and a db. I think to use a common graphics engine from the geometric tools(wild magic 4)for the graphics. My problem is how create and manage entities object , for example walls , chair ecc... because they rappresentation are in a scenegraph and not in simple collections and have a lot of members functions and vars(different behavior). How i can separate and linearly manage the entities and their graphics rapresentation? And how i can design the classes structures? Thanks.

Excuse me if I have to ask: So you has a scene graph but want a flat list of objects? And you're asking how to traverse the scene graph to generate geometry from it so that is compatible to a specific graphics API (probably Wild Magic 4)?

thanks heagarr.
But i would hosk how you advice to manage my logic(not geometry)functions and how relate it with the geometry and scene functions.
For example:
If i have a class:


the draw contains the operation for draw the object , but the GetPrice() is not a api specific(opengl or directx)function.
The question is :
Is possible use a scenegraph(and graphics engine) for manage the geometry object and relate it with the non geometry object?
Then your answer is:
traverse the scenegraph then find all your logic object , then iterate it how are flat list of logic object?
I'm understand?
thanks again.

thanks, but the link don't work

very useful Thanks theOcelot.
My question is this :
If i separe the two responsability in two separated classes , is wrong to incapsulate the two classes in a unique classes?
In the link explain how the modem implement two interface in java , is correct to e encapsulate in c++ ?
THanks.

We come into a region of development which may be much too complicated for the OP's purposes. However, you've asked about, so here we go. But be aware also that there are other possibilities.


One concept of separating things like these, especially things that have nearly nothing to with each other except that they belong to the same entity, is named the "component-based entity system". In that concept, different aspects of an entity are implemented as (different) components, and the entity is (in principle) nothing more than a construct to tell what components belong together to build up that entity.

E.g.: The ShapeComponent class contains the mesh, hence being required for graphical rendering. The PlacementComponent class contains the coordinate frame which defines a location and orientation in 3D space, hence also required for rendering but also, e.g., for picking. The TradingComponent class contains the price and perhaps delivery time. The WallpaperComponent contains alternatives, e.g. as textures, for ... wallpapers.

Now you create an entity. Maybe you have an Entity class, maybe not. Let's think you'll have. So you instantiate an Entity that gets a unique identifier. It should become a wall, so you need to add a ShapeComponent with the correct mesh data, a PlacementComponent with the correct frame, and perhaps a WallpaperComponent to let the cutsomer later select different wallpapers when s/he inspects the model. You'll not add a TradingComponent, because the wall cannot be traded as a seperate thing.

Although you may veto my decision that a wall has no price, you should see a fundamental thing from this example: The instantiated entity is not a wall because we've used a derived class WallEntity (we don't have such a class at all), but because we've added components that are typical for a wall!

Please notice that there is absolute no reason why you can't also define a IfcComponent class that provides some special data resulting from ICF import, e.g. the ICF node identifier. It is also possible to define a AnnotationComponent class that allows to add arbitrary text annotations to an entity. The possibilities are virtually endless.

So far, so good. But all that doesn't count until we can use it in some specific way. That is where something comes into play that is called "subsystem" by many people, or "system" for short. A system in this sense is a piece of logic (or program) that is able to work on the data that are provided by the entity components. Typically, a specific system uses only a subset of component types.

E.g. the TradingSystem uses all the TradingComponent instances it can find in the scene. It provides a query like TradingSystem::costs() that returns the sum of all costs as are given by the TradingComponents; or a query like TradingSystem::deliveryTime() that returns the maximum of all delivery times found.

Similarly, the GraphicsSystem is responsible for rendering. It uses the PlacementComponent and ShapeComponent instances for this purpose.

A DecorationSystem looks for the alternatives, e.g. WallpaperComponent instances. If the customer looks at the rendered model, he clicks at the wall right near the entrance door for the purpose of altering the wallpaper. The DecorationSystem grants access to the alternate wallpapers and let the customer pick one. It then alters the ShapeComponent (or something else) top use another texture.


From a theoretical point of view, such a concept is superior to a pure inheritance based concept. You can see the "Single Responsibility Principle" in that an entity just groups belonging data, components contain related data, and especially different systems are responsible for handling different aspects. However, practise may look a bit more odd.


You may ask why the hell such a concept should be implemented. Well, it gives you an ease of maintenance that cannot be yielded by (pure) inheritance. E.g. it is almost no problem to add new component types and/or new systems later on (at least in theory ;)).

[Edited by - haegarr on February 19, 2010 6:45:56 AM]

Quote:Original post by theOcelot
Or you can just put a graphical member object in your entity base class (if you have one), an object which wraps the scenegraph node provided by your library. It's not as flexible, but it's easier to implement and you might not need all the sophistication of haegarr's design.

For sure; for this reason I've introduced components with the wording "which may be much too complicated". However, giugio's example also shows door::GetPrice() and door::UpdateDbRecord(), what indicates that there is more loosely related stuff. Also, AFAIK we speak of a 3D architectural application of unknown functionality, so I would not push away a full featured solution too early. Giugio now knows of the possibilities of a component system for his company's application, and hence may decide better what to choose.