I am considering the Irrlicht Engine for use in a project that I am getting started on whose aim is to integrate a game environment with a cognitive architecture for the purpose of furthering AI research in vision perception. I am interested in understanding if the Irrlicht will provide the scene graph functionality I am interested in. I would like to utilize the scene graph to export information about the visual state of the world (from the player's perspective) to an external application (a cognitive agent). Here is what I have in mind:
On each frame, inspect the scene graph, extract information from it and re-package part of it for export to another application (probably via XML).
I would like to be able to convert the Irrlicht scene graph format to another scene graph format (for example OpenSceneGraph (http://www.openscenegraph.org/projects/osg) which will be the format that the external application consumes. The goal is to make a cognitive agent that can consume scenegraphs in a common format like OpenSceneGraph, and then connect it to several game engines by converting the native game engine scene graph formats to the common format. Don't worry too much about OpenSceneGraph, the common format has not yet been chosen, I give it just as an example to illustrate the idea. To gauge feasibility I am looking to answer questions about the Irrlicht scene graph such as:
-What node types are supported? Examples could include transforms and group nodes.
-What geometry types are supported? Examples could include points, triangles, polygons.
-What traversal features are supported? For example view frustrum culling.
Each frame, I would want to be able to process only the portion of the scenegraph that is currently visible (from the player's perspective). So I will need to be able to identify what part of the scenegraph is currently visible.
I will also want to extract and export a single scene graph object once, and thereafter only pass on differences rather than the whole object. Do Irrlicht scene graph objects have unique identifiers? This would greatly help in identifying which objects have been previously processed. Also, is there any mechanism for knowing when a scene graph object has changed?
Any thoughts on how suitable Irrlicht would be for this application? I have downloaded the SDK and am starting to rifle through it, but thought I'd pose the question to those of you who have experience with it to see if anyone can provide some guidance off the top of their head. I'm looking to understand if Irrlicht is the right tool for the job. Are these things possible? Are there any issues to be aware of that would make my goal especially difficult?
And of course, if I should post this question in a different forum, please point that out=)
Angela
Scene Graph Capabilities?
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
The scene graph of Irrlicht is organized differently. You can query most of the information listed, but you cannot deduce all informations from the scene graph structure.
Irrlicht uses scene nodes other than mesh scene nodes (animated or non-animated) and other basic things such as lights to introduce new render techniques (such as for terrains, particle systems, or OcTrees). But most scene nodes are just meshes of some kind. Transformations are performed by scene node animators, which are not explicit scene graph elements, but stored with the scene nodes they affect. Other affectors can be part of the scene node (e.g. for particle systems). You can query the results of the scene node animator transformations each frame, though, by getting the absolute transformation of the node. Group nodes are simply empty scene nodes, which can be used for several purposes.
Meshes consist of Mesh buffers, which in turn are triangle lists. You can use the explicit draw routines, though, to use other kinds of primitives, which include all types the render driver supports (e.g. tri-strips and line-strips for d3d, quads also for OpenGL).
View frstum culling is applied during rendering, but the scene graph does not reflect this. I think you cannot even query it directly, but you'd have to do another culling to check this on your own.
Irrlicht uses scene nodes other than mesh scene nodes (animated or non-animated) and other basic things such as lights to introduce new render techniques (such as for terrains, particle systems, or OcTrees). But most scene nodes are just meshes of some kind. Transformations are performed by scene node animators, which are not explicit scene graph elements, but stored with the scene nodes they affect. Other affectors can be part of the scene node (e.g. for particle systems). You can query the results of the scene node animator transformations each frame, though, by getting the absolute transformation of the node. Group nodes are simply empty scene nodes, which can be used for several purposes.
Meshes consist of Mesh buffers, which in turn are triangle lists. You can use the explicit draw routines, though, to use other kinds of primitives, which include all types the render driver supports (e.g. tri-strips and line-strips for d3d, quads also for OpenGL).
View frstum culling is applied during rendering, but the scene graph does not reflect this. I think you cannot even query it directly, but you'd have to do another culling to check this on your own.
An engine with a very sophisticated scene graph is VRS. It is free open source software under LGPL, but (very) sparsely documented.
Anyway, it has scene graph visitors with different traversal strategies and it has a serialization interface. Unlike in irrlicht, the graph doesn't have to be a tree, but can be an arbitrary rooted acyclic directed graph. When I read your problem description I immediately thought of VRS. But be warned that the engine is very complex, somewhat over engineered for games.
Anyway, it has scene graph visitors with different traversal strategies and it has a serialization interface. Unlike in irrlicht, the graph doesn't have to be a tree, but can be an arbitrary rooted acyclic directed graph. When I read your problem description I immediately thought of VRS. But be warned that the engine is very complex, somewhat over engineered for games.
Thanks for re-directing to a more appropriate forum. Email notification didn't work for me - I didn't get notified when new posts occured. I checked the "notify me when a reply is posted" box. Do I need to do anything else? Logistics aside, this is great input. Thanks very much.
Saturn - I haven't heard of VRS before, I'll go check it out. I also appreciate you pointing out that Irrlicht's scene graph must be a tree, I wasn't aware of that restriction. I'm not sure if that will present a problem for me, I need to think on that a bit.
Hybrid - your input was very helpful, exactly the sort of information I was looking for. If I am unable to get at the portion of the scenegraph that is currently visible, that would make things difficult. For this first pass, I am looking for an engine that is going to make the translation easy so that I can do a proof of concept. It is interesting that the scene graph doesn't have transforms in it directly, that is very good information to know.
dlangdev - Regarding the irr file format, that would give me only a static view of the world correct? It would not give me a way to inspect any dynamic changes to the world (characters moving, objects animating about etc)? I do need access to both static and dynamic object information.
Thanks!
Angela
Saturn - I haven't heard of VRS before, I'll go check it out. I also appreciate you pointing out that Irrlicht's scene graph must be a tree, I wasn't aware of that restriction. I'm not sure if that will present a problem for me, I need to think on that a bit.
Hybrid - your input was very helpful, exactly the sort of information I was looking for. If I am unable to get at the portion of the scenegraph that is currently visible, that would make things difficult. For this first pass, I am looking for an engine that is going to make the translation easy so that I can do a proof of concept. It is interesting that the scene graph doesn't have transforms in it directly, that is very good information to know.
dlangdev - Regarding the irr file format, that would give me only a static view of the world correct? It would not give me a way to inspect any dynamic changes to the world (characters moving, objects animating about etc)? I do need access to both static and dynamic object information.
Thanks!
Angela
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
The tree restriction is not really a problem, because it simply means that you have one root, but that one can have an arbitrary number of children which form the real starting nodes. Moreover, you can have several scene managers, which might even have common scene nodes (although this might not always work...).
Since empty scene nodes can also impose transformations on their childs, you have the ability to express static transformations as part of the scene node. There is just not such kind of nodes, because it's less efficient than making the transformations explicit.
Due to the concept of a mostly static scene graph (also information about animation states are contained just inside the animated mesh nodes, not explicitly represented by an animation object), you have to traverse the scene graph, decide about the information you need for each type, and query those explicitly. The .irr format is one way of doing this traversal and serialization of scenes, but you'll probably need other information and adapt the way you use the scene representation in Irrlicht. Except for the visibility (which you cannot query from the scene nodes directly) you should get most information by just walking the scene graph and executing some get methods on the nodes.
Since empty scene nodes can also impose transformations on their childs, you have the ability to express static transformations as part of the scene node. There is just not such kind of nodes, because it's less efficient than making the transformations explicit.
Due to the concept of a mostly static scene graph (also information about animation states are contained just inside the animated mesh nodes, not explicitly represented by an animation object), you have to traverse the scene graph, decide about the information you need for each type, and query those explicitly. The .irr format is one way of doing this traversal and serialization of scenes, but you'll probably need other information and adapt the way you use the scene representation in Irrlicht. Except for the visibility (which you cannot query from the scene nodes directly) you should get most information by just walking the scene graph and executing some get methods on the nodes.