Scene Graph Questions

#1 This could be tricky, without actually looking thru the implementation you might be mislead by someone who does not already posses alot of OpenSceneGraph knowledge.

I would probably describe the most important constructs you are looking for.

Each Frame Question:
the last time I reviewed it, it fits this perfectly. an updated ghost list is prepared based on view frustum.

Extract and Export:
there will be no problem retreiving the update information on a per unique object basis.

#2 Thanks for your input. In general I have heard that the requirement of using a client/server architecture even for a single player game can be a hassle. But it sounds like the client/server architecture may be to my advantage in this case if it is already culling the scene graph based on the view frustrum. Does the ghost list contain the scene graph information directly? Or is it a special format of the scene graph information (that is has the scenegraph information been translated in some way to become the ghost list, or is it simply a pared down version of the scenegraph)?

Regarding OpenSceneGraph, I do not want people to focus on the OpenSceneGraph specifics, since I would not expect anyone here to necessarily know its intricacies. I named it more to be able to convey what I am trying to accomplish. Basically, scene graphs are in general rather similar. They all have ways to arrange object information related to rendering such as location, scale, polygons (sometimes textures) etc. What would be really helpful to me is if those familiar with Torque's scene graph could provide input on what Torque's scene graph supports and if they have found it to radically differ from other scene graphs out there (not necessarily OpenSceneGraph) those comments would be welcome too. I have been pawing through the documentation I can find online trying to answer questions 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.

Part of what I am trying to understand is if this information is documented, or if I need access to the source code to find the answers. I have looked over the 3D rendering documentation page (http://www.garagegames.com/docs/tge/general/ch06s10.php) and it was a helpful start, but does not provide answers to the questions above.

Angela

#3 The ghost list, correct me if I am wrong someone,
is simply a binary stream serialized, this binary stream is then passed along the living objects and updates are parsed from the stream on a per object basis.

realize, this is a Game Engine, not a scene graph so there are some dirty tricks applied.

Node Types:
all the nodes derive from a base type and implement like behaviour.

Geometry:
this is a soupline renderer, so.. have fun it's mostly wide open.

Traversal:
there are some interesting traversal techniques included I believe bounding volume and clipping view frustum as well as .. a couple others I cannot remember.


the documentation is coming up to an implementor level.
all the tools are doc'd and some class's n stuff.
but when it comes to the guts, you wont find any doc for real on the scene graph area, bsp terrain and other such lovely stuff.

if you have already looked at ogre, and are into OSG, and you are still here.
simply drop the 100$ and grab it up.

its like using vb to accelerate a project along.
as long as you can put up with the pitfalls it will do the job just fine.

#4 Thanks, this is helpful. I am currently trying to resolve if I can work under an indie license, and it seems unlikely - hence the lots of questions up front=)

My background is in game development (c++ level) but rarely at this low level. Mostly I've worked on things like player mechanics. I'm not sure I know what "soupline renderer" means - can you elaborate?

And I suppose it is the "dirty tricks" that I'm on the lookout for. Trying to figure out if there are any very game specific anomalies that are going to trip me up. The serialized binary stream seems kind of strange, and I think fits under the category of "not a scene graph" but some sort of structure that contains similar information. Do you concur? So the question I would have is: can I extract out the scene graph information from the ghost stream? If not, then can I get at the scene graph itself directly? And would that have to happen on the server side? I presume it would.

Since you mentioned OGRE, which is also on my investigation list, any pros/cons for choosing Torque vs. OGRE for this application?

#5 Lets start from the bottom up here.

Ogre is awesome.

the biggest PRO I can see for torque in this case, is networking.

and likewise for Ogre its a CON as it has no networking.

however, for everything else Ogre wins. (sorry Torque)

the binary stream is definately a Object system, and you would not want to setup hooks there.
being serialized and using byte stops would be no fun to parse external.

I am sure you can crack into the SceneGraph and get your info easily.

But I am not sure if it can be done, its been a long while since I have played with Torque.
someone will be along who knows better I am sure.

Soupline renderer IMHO is something who access the api directly and makes calls into the context for rendering on a per object basis.

so you see stuff like:
Building->Render();
Player->Render();

instead of something like:
Container->Render();
and the container iterates its sifted data drawing from a dynamic pool of data.
so then anyone outside the renderer knows nothing of the API thus does not make calls into the api


I think the indie license will work fine for you, unless you or your company make more than 500k a year, or the product will.. something like that.
I am sure the indie license is what you want.
if only for investigation it will be fine.

#6 Thanks for the info on the ghost stream, that is very helpful. I also appreciate the description of "soupline renderer". I would have expected the second, of rendering a container rather than the first. This level of information is quite useful.

I am waiting to hear back about the licensing, the primary sticking point is that I will not be making an entertainment based product. According to the latest post from Brett, the indie license cannot be used for a non-entertainment product...

Regarding OGRE, I find your summary very helpful. I have no need for networking, so one of my concerns about Torque is that the built in networking support will complicate things unnecessarily. However, Torque does have the advantage of having a lot of art content available cheaply, as well as the mission editor. My company is strictly programmers, so to populate our world with art we either need to have free/cheap art that can be obtained, or we will be relegated to producing programmer art to just get by with for our research purposes. I'd prefer the first, although I do have a fair amount of Maya & Photoshop experience. How does OGRE stack up in that respect? Is it easy to obtain content? I'm needing only simple things, maybe one interior and one exterior and 1-2 characters. Not particularily picky about the specifics of the content. I have heard good things about OGRE, but been warned that it is a rendering engine only and may not be as full featured as I would want in terms of content creation tools etc. Opinions? I will likely be posting soon on the forums there too to obtain some more detailed information.

Thanks,

Angela

#7 Hmm there are alot of tools for Ogre, from exporters to plugins.

I would venture to say there are more tools for Ogre than Torque.
there is a certain amount of content available already with Ogre as well.
they have a few different characters, some simple textures and the like.

for the "interior" stuff, it is different than torque or anyone running BSP.
they have alot of stuff available outside the actual renderer, from physics plugins to a large terrain managing system.

it is more than a renderer when you include all the external components that are truly ready to plugin and use.

you will find enough content to get you by with those requirements.
there are 3dmax, blender, maya, softimage exporters
so whatever you wanna build your world in will be fine.
you can always download some free one somewhere.

I recommend you have a look at Ogre, it is free and pretty easy to use and get into.
nice code base. good community there as well.

#8 Thank you for the input. Sounds like Ogre is more than just a renderer. I will be having a look at Ogre today, and will post questions on their forums as needed to get the details I am looking for. Thanks for your help!

Angela

#9 Hi Angela,

From what I gather some of the employee's who could answer this kind of in-depth question are really busy and may only have time to check the private forums. This is a specific question about a pretty complicated part of Torque - I recommend you try e-mailing an employee directly. Especially since you will be going for a non-indie license.

Torque is a very powerful and professional engine, it has been used in shipped titles by lots of developers, as well as for many non-game applications.

If you are involved with an academic institution you may be able to get an educational license for less cost.

Best of luck,
- Drew

#10 Hi Drew. Thanks for the input. I had hoped I could talk with an employee, since this is a very detailed sort of question and I have some unusual requirements, since I am doing research. Unfortunately in response to my request for a direct audience I received an email from Brett Seyler asking that I post my questions on the forums. I did find this disappointing for an engine that requires a license fee. I can get forum level support from a free engine. I have also not received any response to my direct inquiry to their licensing email regarding my particular needs. So we'll see where this goes. This forum has been helpful, but I had hoped for more support in a licensed engine. But I do understand that this is one of the tradeoffs for keeping costs down, and I am not in a position to license one of the more expensive engines that come with full tech support.

#11 Howdy Angela,

First off, while I'm sure its probably possible to do what you are asking in your original post - I say with nearly 100% accurately that it would be very far from the best way to do things.

How about you say exactly what you want the end-result to be, as that will help myself and others be more able to help you.

Note: Please leave almost all technical jargon out and any specific methods of achieving the end result - this will remove all unneeded info an leave us with simply what you desire to be done.

If you are uncomfortable discussing it in public I'm available either via email at BenV@brainfluidgames.com or msn at brainfluidgames@yahoo.com - as an experienced programmer that has shipped two successful AI middle-ware solutions, if I can't at least point you in the right direction I would be ashamed.

#12 Ben,
she has already left ample information.

she wants to extract scene data to use for visual analysis.
basically she wants AI to "see" the scene and process it.

Correct me if I am wrong Angela.

#13 Yes, Badguy's description is accurate. Ben, let me try to elaborate a bit further:

I am working on a project whose goals is to create a framework that allows plugging research level AI software into multiple game engines. The goal of the AI research is to further the "vision problem". To define the "vision problem" consider that people can see the rendered image of a game and interpret it just fine. For a computer, however, this is an unsolved problem. The current research is experimenting with augmenting the rendered image with extra data that helps identify objects like "house", "car", "person", "sidewalk" to help the AI software know what it is "seeing" in the rendered image.

The premise of our endeavor is that we can use the scenegraph as a source of the hints about what the rendered image is showing. We intend to choose a common scenegraph format (OpenSceneGraph is an example of what a common scengraph is) as the hints that the AI software will digest. To connect the AI software to a particular game engine, I then need to translate the game's native scene graph into the common scene graph format. The intent is to be able to re-use the AI and the common scenegraph format.

Ben, your comment indicated that you felt this was not a good approach. I am interested in hearing your reasoning (and what you might suggest instead). In addition, if you have input on whether or not Torque is a good engine for attempting such a connection that would be appreciated as well. The project I am working on already has the AI software that will be processing the visual information, the current task is to choose a game environment as a source of information to feed to the AI. So my basic question is: Is Torque a good engine choice for this purpose? Does it have a scene graph format that will allow a straightforward translation to another scene graph format of my choice?

Thanks,

Angela

#14 Bolded to provide for easy skimming.

"I am working on a project whose goals is to create a framework that allows plugging research level AI software into multiple game engines."

For research, correct? Don't get me wrong research AI is great, but they are best left out of games for a variety of reasons.

Well I have to say though that your solution really isn't solving the "vision problem" at all then. It's cheating to provide an illusion of solving the problem. To -truly- solve the problem you would have to grab the image being rendered on the screen and AI would have to figure out what is being displayed.

Solving that problem is something that no amount of digging into the scene graph will help you, and lies deep inside the area of academic AI - something that is beyond my area of expertise as merely a game AI programmer.

However, yes, you can most certainly generate a Torque Scene Graph from anything - even OpenSceneGraph - as long as you add c++ code to TGE engine and if you are determined on going this route TGE is just as good as any other engine.

In addition, since we have already established that you are cheating with this method. There are much better ways to cheat, for example the AI could examine the texture of an object or the object may even be named "Road" or "Cat". The AI might even examine the shape of the object or the context it is in. However, by far the easiest method is for the object to simply have a name identifying what it is.

AI can already "see" (aka pick up clues from the environment), and are very very good at it. They do this by using clues from their environment to recognize what objects are (aka the very same thing you are trying to achieve), so I fail to see how any of what you are describing is research or solving the "vision problem" which is my main concern here.

If you are truly just wanting to give the illusion of solving the problem there are several well-known ways to do just that, but I am that is not your goal.

#15 Hi Ben. Yes, this is a research project, and it is not a one man effort. I work for Soar Technology (www.soartech.com) and we specialize in heavy weight AI, expert systems etc, usually for military applications. My personal background is in game development, and I am relatively familiar with the usual cheats that game AI uses. For this effort, the military is sponsoring research into applying the type of AI that Soar Technology develops to game environments. While academic AI may not belong in commercial games, I believe that the military is not wrong to be investigating uses of game technology for non-entertainment purposes. For this particular research request, Soar Technology is in turn partnering with the University of Michigan for this project, where they are actively researching solutions to the vision problem. The University's goal is to solve that problem ultimately. My goals here is yes, to cheat, but with a very directed approach. By providing a framework where you can get cheat information as well as the rendered information allows the researchers to experiment and work to solve their ultimate problem. They will be starting with a rendered image + scene graph derived cheats and working to remove each of those cheats one by one to end up with an AI capable of analyzing the rendered image. However, that solution is probably years away. In the mean time, there are some practical applications of some of this research that can take advantage of this same framework (which is where the military's interest is). One of the issues is how to effectively provide our AI cheats? The usual game AI runs in process and can easily use a marked up world. My goal is something more general. My AI must run out of process (and likely on a separate machine to get good enough performance), so what I need to do is derive a way to export useful cheats to the out of process AI. The scene graph seems to me a generic way to do this that does not depend on the specific cheats any particular game engine uses which can vary wildly as you know. I need to create a game engine independant way of feeding these cheats to the AI. As far as I know, no such thing exists, but if you are aware of one please point me in that direction.


Regarding your comment that you can build a Torque Scene Graph from an OpenSceneGraph, that is good. But I am looking to go the other direction. How hard would it be to build an OpenSceneGraph from a Torque engine. Is there any particular disadvantage to using Torque to do this instead of some other engine?

#16 Well if you truly believe that is the best way to solve the problem good luck to you.

"How hard would it be to build an OpenSceneGraph from a Torque engine."

It should be relatively easy as you could just write an exporter within the engine to generate the desired OpenSceneGraph.

"Is there any particular disadvantage to using Torque to do this instead of some other engine?"

Not really, any engine with a scene graph should do as the exporting is just a matter of converting data into another form - which any reasonable skilled programmer should be able to manage.

#17 No from what I can tell, at this point in the game, a SceneGraph is a SceneGraph and they are all going to provide and consume the same data elements.

the only difference will be how long it takes you to deploy a solution within a given engine.
some are easier to insert code into, some are easier to add dynamics to, others are more complex.

Also, I do not completely disagree with this approach myself.

unless you provide the appropriate hardware, examining runtime images is not going to be an option for sometime yet.

the next best option for doing something like this "out of process" is to use the telemetry data like you plan to do. and generate a like scenario for the AI to peruse.

of course there are complexities regarding resolving object types dynamically, but this would not solve itself by providing the rendered images either.

Just my 2 cents.

#18 Thanks, this is great input. One of the cool things about doing research is we get to postulate an idea, and the ones we get funding for we get to put to the test. This is one of those cases. I think using the scene graph will fulfill the needs the cognitive architecture has, but the aim of a prototype is to prove it=) It sounds like as far as scene graph compatability goes, I should be able to extract the necessary data from the Torques interface for doing a conversion. And although the ghost stream does provide a culled set of data, it is probably not in a format I want to work with. But it sounds like I should be able to do my own culling traversal of the scenegraph to be able to identify the currently visible parts of the scene graph.

All the input is appreciated!

Angela