Scene Manager Design

Coordinator
Feb 12, 2008 at 3:59 AM
Edited Feb 12, 2008 at 4:01 AM
We need a dedicated thread of discussion of a scene manager.

I believe we should allow for multiple "scenes", however, rather than cycling through them like I was thinking earliar, I think we could simply just load them in and out as packets of content, and the only thing we'd be rendering, or checking for physics would be the single scene running in the scene manager.

So imagine this scenario. We have two scenes, A and B.

We start on one side of scene A. When we begin only scene A is loaded. We move in the direction of scene B. Once we are within a certain distance from scene B it would trigger scene B to being loading on the client. This loading would be the terrain, skydome, lighting, and any entities in the scene. This would be at a big enough distance that you wouldn't notice a good portion of the loading on the screen. We could have a priority for the loading, for example, terrain would likely need to be first, then skydome and lighting settings, then individual entities. We could transistion the lighting and skydomes as you move closer to B and away from A.

We'd have to determine what distances to do this loading, or if it'd be purely by distance. We could have a box or sphere that is placed in the editor, when that is collided with you could begin loading.

I'd like a defined way to not only know when to load, but also unload a scene. You could go solely on a single box per scene as long as the stuff in the scene had padding around it so there is distance for loading and unloading.

Here's an image of what I'm trying to describe, http://www.nfostergames.com/images/sceneexample.jpg

Scene A is the yellow box, Scene B is blue box. Where the scenes overlap is the green area. The transparent red boxes are areas where you would want to place your content, although you wouldn't be restricted to even put the content inside the scenes. So now imagine walking from Scene A, towards Scene B, and you hit the green area for the first time, on the scene A side of the green area. This would trigger the content from scene B to start buffering and loading. As you passed out of the right side of the green area that would trigger scene A to started unloading. If the green area is "wide" enough the player would never notice the transisition.
Feb 12, 2008 at 5:37 AM
That's how I imagined it would work, although I have no technical experience in the matter, I was thinking just a sort of radius around an object (which could be for instance a player) is loaded as needed, and unloaded as needed.

Just a question about this approach, the CPU is going to be loading ALOT of data back and forth as a player moves... Maybe there should be a 'dead-zone' where it won't load anything, that way a player can run back and forwards in the same spot, and the CPU won't have to re-load anything.

I'm not really sure though, heh.
Feb 12, 2008 at 6:43 AM
I think that the initial version of our scene manager should just be a basic one, with the traditional loading. Doing what either of you porpose is a lot more complex. Once we get a better understanding on how our entities interact and how we runtime can add remove these I think we should keep it as basic as possible. Also not all games would require this so having a basic scene manager would be a requirement as well.
Feb 12, 2008 at 1:24 PM
A major design consideration is how to handle asynchronous update/draw. We need to reduce the number of order dependencies that exist within the update code.
Coordinator
Feb 12, 2008 at 3:04 PM
Edited Feb 12, 2008 at 3:04 PM
I've never attempted anything asynch before (not in a game at least), so I'm all ears on that one.
Feb 12, 2008 at 3:27 PM
I only have a few minutes before class, so I'll try to explain briefly. This relates to my arguments for a message-centric module interface.

In a nutshell, we need individual module processing to be able to go wide, as well as deep. In other words, instead of calling Scene.Update() on the main thread and just blocking until the call completes, we need a way to take all of the processing that the scene manager needs to do and split it across n threads. This is easier said than done, but I would advocate a task-based approach. Most likely, each entity will contain an Update() method that is called per-frame. The scene manager can assign m entities per logical task, and the tasks are then scheduled on the available threads (n threads for n cores, or 2n threads for n SMT cores). On a single-core processor (and most likely even a dual-core processor, to an extent), the overhead may be significant. Once you get into 4+-core processors, the advantage of spreading this over all available cores outweighs the overhead and you get (if done right) efficient multi-threading.

Similarly, the renderer should be able to asynchronously query the scene for renderables (on another thread), as well as the physics simulator running asynchronous updates. Obviously, there's a huge communication issue here that we need to work out, but if we can pull it off, we'll basically have one of the first true parallel game engines that scale to n cores, instead of just really using 1 or 2 and the rest for background book-keeping.
Feb 12, 2008 at 3:44 PM
Sounds excellent, but I've got a few questions. I assume that this would be done by using thread pool, or something similar to reduce overhead? Also, if it only starts to pay off at 4 core, would a dual core use 2 threads or one? Is there any way to permanently assign objects to an update thread, as that should lead to little overhead?

Final point, have you considered other parts of the engines thread requirements? I believe the physics is running in at least one stand alone thread, and so is the network. Does this affect your choice as to the number of threads we use?
Coordinator
Feb 12, 2008 at 3:58 PM
I'm all for an engine that prefers more cores, and will benefit from them, but I think we should have a way to run efficiently on a minimum of two cores.

Very intriguing though, I'm excited about it.
Feb 12, 2008 at 4:28 PM

I assume that this would be done by using thread pool, or something similar to reduce overhead?


It would use a similar concept. The .NET ThreadPool class would not be used, we need more control than it provides, especially on Xbox.


Also, if it only starts to pay off at 4 core, would a dual core use 2 threads or one?


The 4-core estimate is just that, an estimate. We will want to try to keep 1 thread per core, or 2 threads per core for SMT cores (like the Xbox).


Is there any way to permanently assign objects to an update thread, as that should lead to little overhead?


That's definitely an option. On the other hand, however, tasks may not be static. For instance, object interaction processing will only occur when two objects are touching/in-contact. This is one of those decisions we need to discuss in-depth.


Final point, have you considered other parts of the engines thread requirements? I believe the physics is running in at least one stand alone thread, and so is the network. Does this affect your choice as to the number of threads we use?


Most definitely. Using third-party tools throws a wrench into the works, but it's nothing we can't code around. For instance, the Ageia PhysX library uses just this concept, splitting tasks among cores. You can tell it how many threads to use, and which cores to use for those threads. However, we will want to try to keep away from the idea of "system X runs on thread Y." Instead, think of how you can split the network processing into atomic tasks. Of course you will probably want to keep around a dedicated thread for polling incoming messages, but that will be separate from the task-processing threads.


I'm all for an engine that prefers more cores, and will benefit from them, but I think we should have a way to run efficiently on a minimum of two cores.


This is something we will have to experiment with. It's entirely possible the advantages outweigh the overhead even in the 2-core case.
Coordinator
Feb 12, 2008 at 4:52 PM
So far what we've discussed:
  • As far as scenes go, the scene manager needs to be able to load and unload scenes in a separate thread, through streaming in data.
  • The scene manager should handle any transistions between scenes, such as lighting, skydome changes.
  • Scene manager should run what it can in threads, once we figure out a good way to do that (update/draw?).

What else do we want from a scene manager? I want to get the big picture in view early and then break it down.
Feb 13, 2008 at 4:05 AM

LordIkon wrote:
  • As far as scenes go, the scene manager needs to be able to load and unload scenes in a separate thread, through streaming in data.


This is something we should consider when we get to the point where we will start implementing a dynamic loading scheme. I think that for the initial versions we should just have the scene load as specific load points similar to most games (C&C, FarCry, etc). I really think that the overhead of the complexity in streaming loading (Similar to WoW) is too much for the team at this point.


LordIkon wrote:
  • The scene manager should handle any transistions between scenes, such as lighting, skydome changes.


At the minimum we should be able to present a loading screen when loading the scenes.


LordIkon wrote:
  • Scene manager should run what it can in threads, once we figure out a good way to do that (update/draw?).


You already have a mechanims in Xna which will alow us to run update more frequently than draw, why do we need to expand on this?


LordIkon wrote:
What else do we want from a scene manager? I want to get the big picture in view early and then break it down.


As I see it currently we have the following threads:
  • Networking
  • Game
  • Physics
    • Physics can take up more than one thread if available offloafing the strain

This means that you will use 4 cores (assuming that physics is using 2) and it's possible to run on a 2 core system merging physics into one and Game+Network into one as well . Remember that in .net a thread = HW Thread so you really want to limit the ammount of threads created in order to avoid too much context switching.

If this model isn't suffient then we can start working out a async schema for the Game to spawn multiple threads, but initially we shouldn't do that.
Coordinator
Feb 13, 2008 at 7:14 AM
Buffering in a scene in a seperate thread shouldn't be too difficult I would think. You just start sending information to a scene loader, which begins initializing objects through the scene manager. At the end of each frame, the scene manager can register any objects that have been loaded in so that they're processed like everything else. We'd just have to limit the buffering speed so that it is fast enough that you don't need loading times so long that scenes don't load by the time the player gets to them, but load in slow enough to not hurt framerate too much.

I'd think the hardest part would be storing the data in the scene and loading that in properly, not the buffering part, or even the async part. Buffering of data from scene files means having content processors for ALL of our data I'm assuming. Terrain, models, physics meshes, etc....

I do agree that getting a single scene running non-async is the first goal, but isn't that basically what we have? The scene manager just needs to be re-written is all.
Feb 13, 2008 at 3:03 PM

You already have a mechanims in Xna which will alow us to run update more frequently than draw, why do we need to expand on this?


The issue isn't running update more frequently, it is running the update processing concurrently.


As I see it currently we have the following threads:

  • Networking
  • Game
  • Physics
**Physics can take up more than one thread if available offloafing the strain
This means that you will use 4 cores (assuming that physics is using 2) and it's possible to run on a 2 core system merging physics into one and Game+Network into one as well.


This is neither scalable nor balanced. Networking processing is not an intense as physics processing, and what happens when you run this on 8 cores? Going wide on physics processing only is not the answer. We need a solution that can be load-balanced across cores and scale to n cores. This isn't just a scene manager issue, it's an engine architecture issue.


Remember that in .net a thread = HW Thread so you really want to limit the ammount of threads created in order to avoid too much context switching.


That's why I suggest having 1 thread per core (or 2 per SMT core) for the workloads. On top of this, we can add background threads for loading. If you have one thread per core running, there is no additional context switch overhead besides the already present OS CPU scheduling overhead.


If this model isn't suffient then we can start working out a async schema for the Game to spawn multiple threads, but initially we shouldn't do that.


Why not? We already know we need to go wide; not only to get good Xbox performance now, but also for future scalability. Good threading isn't something that you just add when you need it. It's like networking. In order to work well, it has to be a part of the design from the start.
Feb 13, 2008 at 5:37 PM

shawmishrak wrote:
The issue isn't running update more frequently, it is running the update processing concurrently.


The real question I believe is if it's a real issue. Until now we have no real understanding of the code and how many threads are needed in order to run the game. We could even move the script engine in it's own thread which would also relieve the game thread.


shawmishrak wrote:
This is neither scalable nor balanced. Networking processing is not an intense as physics processing, and what happens when you run this on 8 cores? Going wide on physics processing only is not the answer. We need a solution that can be load-balanced across cores and scale to n cores. This isn't just a scene manager issue, it's an engine architecture issue.


I'm not sure about networking which is why I put it into a seperate thread. I problem here is that there is going to be a lot of message handling, extracting and packing on one side and unpacking and instantiation of data of messages on the other. I have no answer on what's going to be the right solution on 8 cores, I haven't got a clue where the real performance gain will be.


shawmishrak wrote:
Why not? We already know we need to go wide; not only to get good Xbox performance now, but also for future scalability. Good threading isn't something that you just add when you need it. It's like networking. In order to work well, it has to be a part of the design from the start.


Just as good performance is, but you can easily implement a module which is single threaded and then later rework the module to be multi-threaded, it really depends on implementation, since we are aware of it we should make so that the different modules can be multithreaded but make them single threaded. We might later even discover that the performance gain would be in different modules.

I just question the value of adding threadding throughout the whole engine, when we do not even know if it will perform. The thing about threading is that it's really a double edged sword, sometimes you end up cutting yourself.
Feb 13, 2008 at 8:10 PM
It sounds like you're in favor of giving each module some x number of threads, and letting each module decide how to thread itself. I'm not sure this is a good approach to take for future scalability. I'm advocating a central thread pool (of sorts) that manages tasks for all modules, and dynamically load balances the tasks among the available cores. Is it easy to implement such a system? No, I believe it would perform and scale better than the current "standard" game engine threading approaches.
Feb 14, 2008 at 10:02 AM
I was more thinking of a thread pool as well, but you need more resposibility in the modules, as we can not anticipate the customers needs, so in order to be flexsible the modules need to be able to queue for threads.

I agree on that doing multithreaded work isn't easy at all, and we will really need to think this through.
Feb 19, 2008 at 6:16 AM
So moving ahead I think that we need to layout the Scene at this time. I've already suggested a layout before (Scene Manager Design) We have two options either wide or deep, either just have a few nodes, ie renderable and non renderable nodes or have different types of nodes.

I perfer the latter as it's conceptually easier to grasp, as it's easy to scetionalize your game entities.

public class Scene : IDisposeable, IXmlSerializeable, IDrawable, IUpdateable
{
    public Entity Terrain;
    public List<Entity> Lights;
    public Entity Sky;
    public List<Entity> Sounds;
    public List<Entity> Cameras;
    public List<Entity> Particles;
    public List<Entity> Dynamics;
    public List<Entity> Statics;
}

The node instamces do not have to be on the same thread, the scene just holds a reference to all entities inside the current scene. Any comments?
Coordinator
Feb 19, 2008 at 2:05 PM
I pictured it as us having different entity types, but only a single list. This way when you want to update you don't have to say:

foreach Light in Lights update()
foreach Sounds in Sounds update()
etc....

You just say
foreach Entity in Entities, update()
Feb 19, 2008 at 2:49 PM
The issue here I think is that you can't really control the order of the update. for one you would like to update the terrain before the entities, and sounds after entities as they might obscure the sound source.
Coordinator
Feb 19, 2008 at 4:00 PM
I agree to a degree. The original engine has terrain, sky, water, and fog as separate entities that were called on their own. Particle emitters could probably be standard updatable entities, but the particles themselves I'm not so sure, as it would be a lot of overhead to throw 3000 entities into the update. Again, with sounds, I see the sound emitters as an entity, and sounds themselves as events (which I think XNA does anyway). I haven't thought much about when sounds should be updated yet.
Feb 19, 2008 at 5:47 PM
I wouldn't have the paricles themself as entities, I would most likely have them on the GPU this should leave them out of the scene.

There is also a problem when you need to look for a specific entity as you would have to search through the full entity list.
Feb 19, 2008 at 6:21 PM
I'm still not sold on this. It seems unnecessarily restricting, like singletons.

For instance, why do we need to treat lights, sounds, and cameras differently? And why are the terrain and sky components separate? Is there a reason for this distinction? If we absolutely must enforce update ordering on some entities, then I would recommend trying to come up with a more generic way of doing it, like keeping the global entity list sorted in update order.

Specifically, which entities need specific update ordering, and why?

Even dynamics and statics. What's the difference to the scene manager? What's the conceptual difference? If you're talking about animating vs. non-animating, then this is completely moot. Entities should not care what their physical representation is, or if they even have one. An entity may have a graphical representation in the form of an attached StaticModel/SkeletalModel/etc. object, but that's it. To the scene manager, every entity is potentially drawable. It is up to the entity to send a graphical representation to the renderer when it queries for render data, or nothing if the entity has no graphical representation.

I agree with LordIkon that sounds don't deserve to be separate entities. You can have sound emitters, and individual entities can trigger certain sounds to play. But I recommend against spawning a "Gunfire Sound" entity whenever you fire a gun.
Coordinator
Feb 19, 2008 at 9:00 PM
The sky needed to be drawn with a special culling distance, or no culling would've been fine. This meant a different projection matrix when drawing it. Could this have been solved with a shader that would've ignored the farplane? I had terrain separate for different reasons than we may care about anyway. For example when you hit backspace you'd remove all the entities from the scene. I didn't want to remove the sky and terrain though.

I could've implemented something more specific, like have all entities in a single list, and rather than clear the list, I could've iterated through it, removing only certain types.

I believe we should try to get as many things into a single entity list as we can. But now is the perfect time to decide if there are any candidates that simply cannot be in a list like the others.
Feb 20, 2008 at 2:00 AM

The sky needed to be drawn with a special culling distance, or no culling would've been fine. This meant a different projection matrix when drawing it. Could this have been solved with a shader that would've ignored the farplane?


That's purely a renderer issue, not a scene manager issue.


I had terrain separate for different reasons than we may care about anyway.


Care to share?



For example when you hit backspace you'd remove all the entities from the scene. I didn't want to remove the sky and terrain though.


That just sounds dangerous. Removing entities should be done with some kind of filter attached.


I believe we should try to get as many things into a single entity list as we can. But now is the perfect time to decide if there are any candidates that simply cannot be in a list like the others.


That should definitely be the goal. We should try to keep one entity container (may not be a list, could be a binary tree or whatever else), and only deviate if absolutely necessary.
Feb 20, 2008 at 4:10 AM
As I see it there is a difference between dynamic and static entities. Satic entities aren't updated in the same way, for one environmental lightning shouldn't be updated, it's static. Also there are prob material and other resources which can be shared without concerns as they are used statically.

I agree that rendering isn't part of the graph.

We could have a single list and simply implement it all there or inside the entities themself. I just wanted a more structured layout which would easily integrate into the editor.

But I'm in on way pushing for this. Just opening up for discussions
Coordinator
Feb 20, 2008 at 5:30 AM
Maybe we should decide the different types of Entities we will need, and any major groups we'll need from them, like Static, Dynamic, etc...

If we can figure out all the major types we need, and their differences, we can decide if these will work fine in a single list.

We should layout something simple for each, like....

Static Entity:
Update does.....
Draw does....
Special considerations: .....
Feb 21, 2008 at 2:51 PM
Hi, what you think about DotScene format? http://www.ogre3d.org/wiki/index.php/DotScene.
Coordinator
Feb 21, 2008 at 2:55 PM
As far as scene loading goes, I imagine we'll be doing something very similar to that. I believe we already determined we'd be loading from XML.
Feb 21, 2008 at 7:22 PM
We are going to use xml serialization in order to have entities serialized across appdomains and threads.
Coordinator
Feb 23, 2008 at 9:42 PM
We should get this figured out so we can get on with things.

So far I can't think of anything that needs separation, as long as we have the ability to let each entity type update/render how it specifically needs to.
Feb 24, 2008 at 3:10 AM
At this point, I see no reason to separate the entities into separate lists.

What's important at this stage is how to represent entity hierarchies. We are going to need parent/child relationships, so we need to decide how to handle those. For instance, a sword entity could be placed as a child of another node, instead of in the root list. Now, the question is, does the child's position/orientation represent relative offsets to the parent, or absolute positions/orientations that are adjusted whenever the parent is updated.
Coordinator
Feb 24, 2008 at 9:29 PM
I think we might want to give the option of having parent rotation/position changes affect the child. It should be optional in my opinion. But I agree, this would allow us to do things like not drawing the sword, or even updating it, if the character holding the sword isn't being updated.
Feb 26, 2008 at 9:37 AM
It is a common thing to just use the offset values.
If a given entity is the root-entity of a hierarchy then it's offset values equal world (or absolute) values. And knowing them one can reconstruct the absolute values for any child of that entity.
Means more calculations I guess, because one hast to iterate through each "bone" and sum up their position/rotation values until one finally reaches the desired child. But this shouldn't be that hard an impact given today's hardware, should it?
Well, just my two cents. But then I'm no programmer either.
Feb 26, 2008 at 2:09 PM
That's definitely an option.

Another way to handle it would be always store absolute transforms, and build your hierarchy with joints. Then, it's up to the physics component to maintain the hierarchy by honoring the joints. This works quite well with ragdolls, and I would imagine it works well in general, too. It guarantees consistency in the hierarchy between collision events.
Coordinator
Feb 26, 2008 at 4:19 PM
Yes, I just don't know if we should force child entities to rotate or move according to their parents. I think it should be the default for sure, but there are cases when you may want a child/parent relationship without a direct attachment like that.
Feb 26, 2008 at 4:44 PM
That's one of the reasons why joints are nice. If you want binding, you create the joint. Otherwise, you don't create it.
Coordinator
Feb 26, 2008 at 5:06 PM
So assuming we use parent/child associations, that leaves us with the entity hierarchy to design before we can really get down to business with the scene manager.
Feb 26, 2008 at 5:36 PM
Yes and no. Conceptually, the entity hierarchy does not have much of an effect on scene manager design. Game code is free to use whatever hierarchy makes sense for that particular game. All the scene manager reallys needs to know is the following:

  • Entites have zero or more children.
  • Entities must have a mechanism for renderer interaction.
  • Entities must have an update mechanism.
  • Entities must have an associated unique name (for queries)
  • Entities should have a unique integer identifier (for efficient dispatching)

That's all I'm seeing off the top of my head.

Something we may want to consider is a scene having only one top-level entity, the root scene node. Every independent object in the scene can be a child of this node. This could allow us to build some very efficient data structures for scene graph traversal.
Feb 26, 2008 at 6:58 PM
This structure is very similar of Axiom SceneManager.

very good.
Mar 17, 2008 at 8:39 PM
What are the differences between Screens and Scenes in the last QS release code design (0.19)? I'm trying to integrate Game State Sample code in QS but i'm not sure if Scene class and Scene Manager is the right place where to put this functionality.

Currently i've modified the SceneManager class (and Scene class) so i can switch from a previous scene to a next scene with In/Out Transitions (only Fade Transition for now) and it works quite fine but is it the right solution or is better to put it in Screen and Compositor classes?

I'm considering a "scene" entity like a connected set of contents and game logic (a menu, a simple level, an intro scene, etc) and a "screen" entity like a "layer" of a scene (GUI, 3D View, Debug information, etc), is it right?

Obviously, in this idea, a big level required to be splitted in different scenes...

Please, help me to understand... :)
Mar 17, 2008 at 9:09 PM
You're very close. A "scene" is essentially a scene graph. It's a tree of entities that make up the game world. Rendering is just one use for the scene graph. A "screen" is a 2D overlay. A "scene" is rendered into a "screen", and additional layers are composed on top of this screen, like the debug overlay, logo, UI, etc. Menus, intro screens, and other components will be rendered as screens and overlaid on top of whatever other rendering is done. Game logic is separate. You can write logic to influence the scene graph (scripted animation, gun fire, in-game cut scenes, etc.) or a particular screen (menu logic, debug output, etc.).

As an example, think of the following composition chain, which is what currently happens in the 0.19 demo:

    Blank Screen -->
    Scene Rendering -->
    Debug UI screen/overlay -->
    QS Logo screen/overlay -->
    Monitor/TV

Starting from a blank screen, the scene is rendered into the compositor. Then, the Debug UI is rendered on top of the scene rendering. The QS logo is then rendered on top of the scene rendering/debug UI. The resulting image is then presented to the monitor/TV.

One thing to keep in mind is that the multiple-scene interface is going away. SceneManager and Scene will merge into one class, and maintain an entity hierarchy. For large levels, you can use several terrain/world chunks that get paged in and out.
Mar 18, 2008 at 1:34 AM
Edited Mar 18, 2008 at 1:37 AM

adribeiro wrote:
Hi, what you think about DotScene format? http://www.ogre3d.org/wiki/index.php/DotScene.


Let's not make it too verbose, keeping numeric values in attributes, and elements for real parent/child relation ships.
A single scene doc may be very large, and if we use XML intelligently, we will fasten the parsing process.

For example, rather than :
<node name="Robot" id="3">
            <position x="10.0" y="5" z="10.5" />
            <scale x="1" y="1" z="1" />
            <entity name="Robot" meshFile="robot.mesh" static="false" />
</node>

I'd rather go :
<node name="Robot" id="3" x="10.0" y="5" z="10.5"sx="1" sy="1" sz="1" />
            <entity name="Robot" meshFile="robot.mesh" static="false" />
 </node>
Mar 18, 2008 at 1:41 AM


Sturm wrote:
We are going to use xml serialization in order to have entities serialized across appdomains and threads.


I had very bad performance issues with the default XML and binary serializers. We need to customize the serialization process.

We could have those XML scene files compiled using the content pipeline, too
Mar 18, 2008 at 1:47 AM


Suzume wrote:
But then I'm no programmer either.


Ah ? What's your job Suzume ?
Mar 18, 2008 at 1:52 AM
I'm all for highly optimized binary file formats, provided the tools are adequate.

Remember: On Xbox, binary serializer is not available and only a subset of XML serializer is available.

Originally, I wanted to have a each scene node provide its own (inherited) Serialize and Deserialize method, given a serialization context.
Mar 18, 2008 at 1:57 AM
Ok to keep xml serialization but manually handled :)

On another hand , while working on my Ldraw file format content pipeline, I came across the Lego Digital Designer's scene file format.

I invite you to look at it on the following Lugnet forum post :
http://news.lugnet.com/cad/ldd/?n=140

Download the file attached, rename it to .zip and look at the format specifications but more important, the sample .lxfml file.

It gives us another view on how others have responded to this issue.
Mar 18, 2008 at 1:58 AM
Edited Mar 18, 2008 at 1:59 AM


shawmishrak wrote:
Another way to handle it would be always store absolute transforms, and build your hierarchy with joints.


That is exactly what they did for the lego scene format.
By the way I guess they are probably using similar scene format for the upcoming Lego Universe mmorpg.
Mar 18, 2008 at 2:16 AM
Creating your hierarchy with joints seems to be the most intuitive way to do it when you consider a physics-based scene. That's the main reason I proposed it, I want as deep of an integration with a physics engine as possible for this project. I am the physics programmer, after all (who also does graphics and touches on just about everything else). :)
Mar 18, 2008 at 2:27 AM


shawmishrak wrote:
I am the physics programmer, after all (who also does graphics and touches on just about everything else). :)


Good idea we should start putting skills/labels/roles in front of our names in the members area.
On my side, I fluently talk C# .net , whereas im a beginner in graphics/3D, just enough to write content pipelines :p
Mar 18, 2008 at 2:31 AM
Actually we could have leader developer by areas, and welcoming juniors/less experienced in the areas that they want or are more adapted to their skills, while having their work supervised by the lead dev.

That would be really productive
Mar 18, 2008 at 2:43 AM
Are you bingomouche on the XNA forums? Your comment about Ldraw didn't register until just now.

Brief History:
I've only been using C# on-and-off for about a year and a half now. I picked it up around the time XNA 1.0 beta came out, and XNA coding is the only time I use C#, to be honest. I'm a C++ programmer at heart, and my background is in graphics and high-performance computing. My original interest in this project was to see how far I could push C#/XNA, especially on Xbox, before reaching technical limits. I've definitely found several limits that I'm not happy with, and if you search on the XNA forums for my user name (ShawMishrak), you'll pull up several interesting threads, but that's a topic for another day. I'm pretty sure Shawn Hargreaves hates me. :)

I'm still interested in XNA, though, despite my sometimes vocal complaints. It's an interesting technology, and I can definitely see it evolve into something great, especially with the Community Games platform.

I joined this project as a physics developer and general performance consultant. However, I quickly realized we didn't have the manpower for me to specialize like that, so I gradually took on a project-lead role and stuck my hand into everything. My physics responsibilities fell from implementing a physics engine to hooking up a middleware solution and then spending my time with graphics/architecture.
Mar 18, 2008 at 2:45 AM

clertem wrote:
Actually we could have leader developer by areas, and welcoming juniors/less experienced in the areas that they want or are more adapted to their skills, while having their work supervised by the lead dev.

That would be really productive


I like that idea. The problem is, again, manpower. We barely have enough people to tackle engine architecture, let alone actually design/implement all of the individual systems.

If we could pull that off, I would be all for that idea.
Mar 18, 2008 at 3:52 AM
Ok so easy, we need to ( in order ) :
- define the areas of development
- populated our pool of lead developers with experienced guys
- then start "recruiting" (in a white room, no 250lb guy ;) ) other devs including juniors

The project will not only be helpful to the community for the reasons we know already but also and more importantly, because we would provide the opportunity to anyone to come and learn "at our place and at their own pace" about XNA, other .NET sides, and most of all our engine !!! (which means that those guys will advertise the engine on their side and advise people on making games on it etc... etc...)
Mar 18, 2008 at 4:06 AM
It's a good idea in theory. I'm a little concerned with being able to manage it all though.
Apr 3, 2008 at 2:33 AM
Now lets go back to the original subject, scene manager design.

The following thread , started by Chris, is somewhat bound to this one :
"QSE_ED (QuickStartEngine Editor) Dev Team Roster / Guidelines, Roadmap"
http://www.codeplex.com/QuickStartEngine/Thread/View.aspx?ThreadId=24690

The XML Scene file format understoopd and parsed by QS should be identical to the one generated from the Editor (of course but I prefer to say it) .

What should it contain exactly ? Any game level information ?
Apr 3, 2008 at 10:47 PM
Please send further posts to the new forums :
http://xnaquickstart.freeforums.org/scene-manager-f7.html