ChangeSet 8351

Coordinator
Dec 9, 2007 at 9:44 PM
Ok, there a few decent sized changes in this change set, review if you'd like.

Changes:
  • Engine now runs entirely on a right-handed coordinate system. This more closely aligns the engine with the XNA framework, XNA samples, and what XNA users will likely expect. Although it is still worth noting the engine remains a Z-up coordinate system.
  • All render calls are now being done within the scene manager.
  • The camera is now located within the scene manager.
  • Cameras are now initialized through the CameraInterface.
  • Entities now have ability to have mounted/attached cameras. This will allow me to create many nice camera features soon. :)
  • Other minor code cleanups and added comments in some places.

Not all changes are final, as usual, but it is a start.
Dec 10, 2007 at 8:42 AM
namespace Interfaces
  • I really dislike the use of the word interface. In C# interface has a specific meaning and this gets very confusing. I think that in most cases when you say interface you mean manger or handler.

In QSInterface
  • I don't see the difference between this and BaseEntity, shouldn't BaseEntity have these entries, or where are you expecting to use the class?

In CameraInterface:
  • I'm not sure I understand what this class is surposed to be doing.
  • AttachCamera, why do you have this, If I already have the entity and the camera, why do I need to invoke a method on this interface.
  • GetCamera, even more strange, I would use the Camera dictionary (well it should be a dictionary) on the entity to get the camera I want.
  • CameraType isn't a good choise, you should use a integer as users will not be able to extend enums.

In SceneManager.cs
  • Why do you expose all those fields, most of these shouldn't be assignable from child types
  • Who can a SceneManager have a root entity? Either it is the root entity (obviously I can't) or it contains all the root entities (such as terrain, models, light etc)
  • I don't think that this is all too intuitive, if I have a entity I would expect to be able to write this.Scene.Lights.Add("MySpecialAmbientLight", new AmbientLight(...));
  • Remember to use "this" prefix for instance members

In Scene.cs
  • Again do not expose all fields most of these aren't meant to be assigned to by child types.
  • Consider creating a class for Environment which would contain Gravity/Wind/Weather/Etc
  • There is no reason to have Add/RemoveEntity methods, this should be handled by the Entity collection directly
  • Why have Activate/Deactive, you could just set the Active property (If you do this you will most likely end up with many similar for each property)?
  • Activate/Deactive, if they should stay, have to be virtual.
  • Run should be virtual, What is run supposed to do? wouldn't implmenting IUpdateable and IDrawable be more intuitive, it is a updateable and drawable thingy?

In BaseEntity.cs
  • I think this should implement IDrawable and IUpdateable
  • Do not expose fields, do create properties
  • I do not understand why cameras are there, I thought you would add a Mount collection?
  • The two extended constructors are missing QSGame property
Coordinator
Dec 10, 2007 at 1:20 PM
I'm working on most of these issues, and have address many of them already in a version I'm working on, unfortunately the right-handed system conversion is going to take some time. I may try and get the changeset in first.
Dec 10, 2007 at 1:51 PM
Then I think that next time you have code like that you should wait, If anyone bases something of that code they would need to rework it later. I think a patch would have been a better solution, or simply waiting till you were more finished.
Coordinator
Dec 10, 2007 at 2:24 PM
I think that is a good point. My next upload may be a patch, because it will be fairly large.
Dec 10, 2007 at 5:25 PM
If the pack is fixing the issues above you might as well check them in.
Coordinator
Dec 10, 2007 at 5:54 PM
Tonights patch is features, the next one will be the fixes/conversions to standard right-handed coord system.
Coordinator
Dec 12, 2007 at 5:27 AM

Sturm wrote:

In SceneManager.cs

Why do you expose all those fields, most of these shouldn't be assignable from child types


What if the user of our engine wants to create their own type of scene manager, without changing the code of our original? They wouldn't have access to many of the things they would need, like the game, or the entities, unless they used accessors. Accessors aren't a big deal for reference types I guess, but by making things private we're basically saying "Don't try and make your own class from this...".


Sturm wrote:

Who can a SceneManager have a root entity? Either it is the root entity (obviously I can't) or it contains all the root entities (such as terrain, models, light etc).


I'm not sure I understand the question. SceneManager needs a camera, which requires an entity. If I don't give it to SceneManager then I'd be giving it to a scene, and if we had multiple scenes then we'd have multiple default cameras, unless we made it static (which I'd rather not do). I may just need a more appropriate name for the sceneRootEntity. I really don't care what we decide to call it, I just need a blank entity to attach a camera to, and I'm assuming later we may need it for other things. The scene manager probably won't have terrain, models, or lighting, instead the scene will have those. For example, if the lighting in one scene was dark, and the adjacent scene was light, we'd have to be able to fade the lighting between scenes. Each scene will have its own terrain as well. So while scenes may have many cameras (or entities w/cameras), the scene manager has its own default camera that you can always switch back to, and because it is controlled through the camera interface, all you have to do to switch to the default camera is send a message requesting the camera from the scene's default entity.


Sturm wrote:

I don't think that this is all too intuitive, if I have a entity I would expect to be able to write this.Scene.Lights.Add("MySpecialAmbientLight", new AmbientLight(...));


Why won't you be able to do this? Camera's are a special case because we basically have a camera manager. If we force new cameras to be created through the interface we can enforce any other logic that goes with adding a camera. Currently there is no extra process when adding a camera, but if we don't enforce it requiring the manager and decide all cameras need to go through an extra step that requires the manager, they'll be forced to send another message to the camera, or we'd have to go into the base camera constructor and send a message from there, or some other ugly way of doing things.

As for lighting I don't believe we'll need a lighting manager, so we could simply have a function that is part of scene called something like AddLight( Light newLight ) . Of course, we still have an authority for scene, which is scene manager. We could theoretically do something in SceneManager like AddLight( Scene targetScene, Light newLight ) . But again, only if we needed some special action to occur during light creation that only the SceneManager could handle.


Sturm wrote:

Consider creating a class for Environment which would contain Gravity/Wind/Weather/Etc


In the template I had thought about doing this and at the time I thought to myself "Isn't environment another way of saying scene", and at the time it made sense to me. But I wasn't considering the fact that scenes can be indoors. So it seems more intuitive to have environment now that scene can be many things. I'll get an environment class going soon.


Sturm wrote:

There is no reason to have Add/RemoveEntity methods, this should be handled by the Entity collection directly


Agreed. I'll have to put a flag in entity that will be set to let the collector know to remove them from the list. This collector, however, will need to traverse through the list, in the scene, which is in a list in SceneManager, so I'd say the Entity collector should be run by the sceneManager directly.
Coordinator
Dec 12, 2007 at 5:35 AM

Sturm wrote:

In BaseEntity.cs

  • I think this should implement IDrawable and IUpdateable
  • Do not expose fields, do create properties
  • I do not understand why cameras are there, I thought you would add a Mount collection?



I will look into IDrawable and IUpdateable, however I currently don't know exactly how the graphics system will end up, I don't know if a scene will draw, or merely decide what to draw, or ??. Currently the scene manager is just calling draw and it renders whatever is in the queue. If I were to make 5 scenes will 4 models each, at this point, I'd still only have to call draw once in the sceneManager to draw the queue. I'm not sure if this is how it will stay, I'm just not sure how the scenes will manage this yet. I am fairly certain however, the scenes will be updatable.

Most of the exposed fields are for performance reasons, notice most are Vector3 and Matrix fields. However there are a couple that could be properties, just for the sake of being properties I guess.


  • The two extended constructors are missing QSGame property


Are we sure we want every entity in the game to have direct access to the game. Any issues that could arise due to access to the QSGame would could potentially be a debugging nightmare. I still believe that it would be more beneficial to have the managers/interfaces have game access and have full control over the respective entities.
Dec 12, 2007 at 5:38 AM
I'm not sure I understand the "SceneManager needs a Camera" relationship. A camera should just be a viewer into the scene, not necessarily an active participant. The scene manager should be perfectly capable of all normal functionality without a camera. Sure, a camera can be attached to an entity or target an entity, but why require a scene manager to have at least one camera defined? (Ignoring the quantum mechanics postulate that the mere act of observing an event changes it's outcome, of course!)
Coordinator
Dec 12, 2007 at 5:40 AM
Edited Dec 12, 2007 at 5:54 AM

Sturm wrote:

In CameraInterface:

  • I'm not sure I understand what this class is surposed to be doing.
  • AttachCamera, why do you have this, If I already have the entity and the camera, why do I need to invoke a method on this interface.
  • GetCamera, even more strange, I would use the Camera dictionary (well it should be a dictionary) on the entity to get the camera I want.
  • CameraType isn't a good choise, you should use a integer as users will not be able to extend enums.


The camera interface is the authority for all cameras. It will have access to any camera in the game, and because of that it is the perfect place to send messages requesting camera information. In fact, it will be the only place handling camera messages. I'm working on a camera interface for work, and I can vouch that this system works well. However, that doesn't mean it is perfect, so I'm always open to new ideas.

AttachCamera, as described earliar, will let us do any extra actions we need to the camera or entity when attaching, that only a CameraManager could do, because we're going through the manager. If we want the cameraManager to truly manage all the cameras then it should be aware of any major changes going on with cameras. For instance if we wanted to collect data on cameras, it would be a central place to do that. What if that data was keeping track of how many cameras were created, or how many of which type of cameras were created. We could certain create static variables in our camera class, but if we have a camera manager I find it a better place to keep information like that. I'm just throwing out examples, I don't know if camera data is something we'd care about, but a central system like this facilitates all kinds of things we could think of later on.

Using a dictionary is dangerous. What if an entity is removed? Will we be going through the dictionary and removing references? We'd have to have the entity system send a message to the camera system every time it deleted an entity, just to make sure it wasn't in the dictionary.
What if camera's get removed but the entity remains? We might be able to account for this, but again, only if we enforce the camera manager as the only place to remove cameras.
What if I want Player3's FPS Camera? I could certain say, Player3.Cameras.List.Find(FPScamera), or something along those lines, but what if, as a player on the opposite team, I shouldn't have access to player 3's camera, how do I code for this, should every player class have methods to check, or should I simply go through the authority (camera manager), and have the camera manager decide which cameras I have access to? This is especially important because we'll be using networking and messages. A user's system on one end may not know what it has access to, so the camera manager has to determine that.

I'm not sure what you mean by extending enums. Using ints is like using a magic number, unless you know about all the other ints scattered throughout the code you have no idea how high the ints go, or if somebody skipped over 3 and it is open for use. Using an enum lets the user know which types are available through intellisense.
Coordinator
Dec 12, 2007 at 5:42 AM


shawmishrak wrote:
I'm not sure I understand the "SceneManager needs a Camera" relationship. A camera should just be a viewer into the scene, not necessarily an active participant. The scene manager should be perfectly capable of all normal functionality without a camera. Sure, a camera can be attached to an entity or target an entity, but why require a scene manager to have at least one camera defined? (Ignoring the quantum mechanics postulate that the mere act of observing an event changes it's outcome, of course!)


Technically it doesn't. But something does, and if its not the scene manager then it would have to be a scene. So then we're required to have a scene, rather than required to have a camera. Ok, no big deal yet. But what if we set the initial camera in SceneA, and then go to SceneB, and unload SceneA. We need to make sure to bring the game's default camera over with us or we lose it. It is much easier to manage in a place where it will never be accidentally deleted, or need to be copied across scenes.
Dec 12, 2007 at 5:49 AM
To me, it just makes more sense to assign cameras to players, or more generally, to individual entities. For instance, the entity representing player A would have a camera attached to its head mount for a FPS game. A security camera entity could have have an attached camera with a named render target. Then, for any given frame, scripts will tell you what camera(s) to render to the back buffer, whether they be player cameras, cinematic cameras, or whatever other kind of camera.
Coordinator
Dec 12, 2007 at 5:53 AM
We are attaching cameras to entities. But how many engines require you to have entities like players to render something? But think about it, we do have an entity by default, its in scene manager. The way we're attaching cameras will absolutely allow us to have something like your security camera situation. We could also use scripting through the camera manager to pick which cameras to render, I made a comment to that effect.
Dec 12, 2007 at 1:57 PM


LordIkon wrote:
We are attaching cameras to entities. But how many engines require you to have entities like players to render something? But think about it, we do have an entity by default, its in scene manager. The way we're attaching cameras will absolutely allow us to have something like your security camera situation. We could also use scripting through the camera manager to pick which cameras to render, I made a comment to that effect.


Out of interst, how will we handle things like vehicles? A camera tied to it would allow us to switch, but what about input? This is assuming we will support this in the engine of course. If not, bearin mind many games (even some rts) have vehicles as well as normal player control.
Coordinator
Dec 12, 2007 at 4:26 PM
You may have to ask Sturm, he's creating the input manager. I think the vehicle entity would have to determine how it handled input messages. Whenever you make new vehicle classes each could handle input message in its own way. When you switched input to a new entity you could also switch cameras. That is really up to the people making the game, we just have to make it possible.
Dec 13, 2007 at 8:49 AM

LordIkon wrote:
What if the user of our engine wants to create their own type of scene manager, without changing the code of our original? They wouldn't have access to many of the things they would need, like the game, or the entities, unless they used accessors. Accessors aren't a big deal for reference types I guess, but by making things private we're basically saying "Don't try and make your own class from this...".


No PIMPL doesn't in any way say "don't ...." Just have a look at Xna.Game (or Windows.Forms.Form) class it doesn't expose fields only properties, and I wouldn't say that they aren't extensible frameworks. Imagine what would happen if someone suddently set the entity collection to null or event worse created a new instance of the list and assigned it. every time you expose properties you have to consider what would happen if someone chages these at any time. We also have special requirements when assigning most of these properties, which might not be enforced when inheriting.


LordIkon wrote:
I'm not sure I understand the question. SceneManager needs a camera, which requires an entity. If I don't give it to SceneManager then I'd be giving it to a scene, and if we had multiple scenes then we'd have multiple default cameras, unless we made it static (which I'd rather not do). I may just need a more appropriate name for the sceneRootEntity. I really don't care what we decide to call it, I just need a blank entity to attach a camera to, and I'm assuming later we may need it for other things. The scene manager probably won't have terrain, models, or lighting, instead the scene will have those. For example, if the lighting in one scene was dark, and the adjacent scene was light, we'd have to be able to fade the lighting between scenes. Each scene will have its own terrain as well. So while scenes may have many cameras (or entities w/cameras), the scene manager has its own default camera that you can always switch back to, and because it is controlled through the camera interface, all you have to do to switch to the default camera is send a message requesting the camera from the scene's default entity.


Having multiple scenes is a big challenge, as you say lighting is just one, bacially this means that you will need to process the current and all adjancent scenes to make sure everything is ok. What confused me here was the term SceneManager, for me that usually implies the one responsible for the scene, but it's the manager of all scenes. So yes scenes will have all those items.


LordIkon wrote:
Why won't you be able to do this? Camera's are a special case because we basically have a camera manager. If we force new cameras to be created through the interface we can enforce any other logic that goes with adding a camera. Currently there is no extra process when adding a camera, but if we don't enforce it requiring the manager and decide all cameras need to go through an extra step that requires the manager, they'll be forced to send another message to the camera, or we'd have to go into the base camera constructor and send a message from there, or some other ugly way of doing things.


Exactly this is bothering me. All entities are simply created, but a camera has to go though a special camera thingy in order to be created. This breaks consistency, either we should drop the camera thing or force a similar approach for all entities.


LordIkon wrote:
As for lighting I don't believe we'll need a lighting manager, so we could simply have a function that is part of scene called something like AddLight( Light newLight ) . Of course, we still have an authority for scene, which is scene manager. We could theoretically do something in SceneManager like AddLight( Scene targetScene, Light newLight ) . But again, only if we needed some special action to occur during light creation that only the SceneManager could handle.


This just gets ugly, having Add.... for every possible entity type will just explode the surface on the scenes. A property which is a list (or some type of collection) would make the interface look so much cleaner.


LordIkon wrote:
Agreed. I'll have to put a flag in entity that will be set to let the collector know to remove them from the list. This collector, however, will need to traverse through the list, in the scene, which is in a list in SceneManager, so I'd say the Entity collector should be run by the sceneManager directly.


No a collector isn't really needed for this. when the flag is set the entity is automatically added to the collector list and then removed when needed. Running though all lists just to remove a single entity is way to expensive.


LordIkon wrote:
Most of the exposed fields are for performance reasons, notice most are Vector3 and Matrix fields. However there are a couple that could be properties, just for the sake of being properties I guess.


The only performance bottleneck I'm aware of is regarding the Physics Engine, but as detailed in other posts there a ways to implement this without sacrificing PIMPL.

More coming up when I get the time
Dec 13, 2007 at 9:02 AM
Edited Dec 13, 2007 at 9:04 AM

mikelid109 wrote:
Out of interst, how will we handle things like vehicles? A camera tied to it would allow us to switch, but what about input? This is assuming we will support this in the engine of course. If not, bearin mind many games (even some rts) have vehicles as well as normal player control.


Well this fully depends on the game implementation, the input system just provides the information, not who is processing it. So you could have a overhead camera which just follows the car, and then the car was the one responsible for reacting on user input. Then it you wanted a view from inside the car you would just switch camera, since the car had a mount point inside at the driver seat and when initialized the car entity added a camera to that mount point. The input controls would be the same.

In a RTS type of game only the selected unit would be the one listening for keyboard input.
Dec 13, 2007 at 9:08 AM

LordIkon wrote:
We are attaching cameras to entities. But how many engines require you to have entities like players to render something? But think about it, we do have an entity by default, its in scene manager. The way we're attaching cameras will absolutely allow us to have something like your security camera situation. We could also use scripting through the camera manager to pick which cameras to render, I made a comment to that effect.

Well the scene manager isn't actually an entity, a scene might have been, though it's not suited either.

But I can easily imagine that we would always have a null entity as a minimum on a screen at any time. We could then add a camera to this null entity.
Dec 13, 2007 at 11:54 AM
How about having a default scene manager camera that is used if no other is present?
Dec 13, 2007 at 12:08 PM
Edited Dec 13, 2007 at 12:08 PM
Having a default camera on the SceneManager will not really be a good solution as not all scene's might allow all cameras.

Also my main issue here is consistency. I should just be able to say
    this.SceneManager.ActiveCamera.Position = Vector3.Lerp(initialPosition, shakeVector, timeIndex);
 
or in case of multiple cameras
 
    foreach (Camera camera in this.Scene.Cameras)
    {
        camera.Position = Vector3.Lerp(camera.Position, ShareVector, timeIndex)
    }
The latter could be used in any case even if there is only active camera.
Coordinator
Dec 13, 2007 at 2:01 PM


Sturm wrote:
Well the scene manager isn't actually an entity, a scene might have been, though it's not suited either.

But I can easily imagine that we would always have a null entity as a minimum on a screen at any time. We could then add a camera to this null entity.


That is exactly what we're doing right now.
Coordinator
Dec 13, 2007 at 2:02 PM


mikelid109 wrote:
How about having a default scene manager camera that is used if no other is present?


That is exactly what we're doing right now. The default camera is the one we're using because we haven't had a need to switch cameras yet. As soon as we create the game's first camera, like for a player, or for a terrain, or whatever, then the default rendering camera in the manager can switch over to whatever we'd like.
Coordinator
Dec 13, 2007 at 2:07 PM


Sturm wrote:
Having a default camera on the SceneManager will not really be a good solution as not all scene's might allow all cameras.

Also my main issue here is consistency. I should just be able to say
    this.SceneManager.ActiveCamera.Position = Vector3.Lerp(initialPosition, shakeVector, timeIndex);
 
or in case of multiple cameras
 
    foreach (Camera camera in this.Scene.Cameras)
    {
        camera.Position = Vector3.Lerp(camera.Position, ShareVector, timeIndex)
    }
The latter could be used in any case even if there is only active camera.


You'll be able to do just that, of course I imagined you changing the position through a message. A message that goes directly the camera interface, and is processed instantly, not a message that waits in a queue. Messages should allow us to do whatever we want with cameras, at any time, from any other place. Otherwise you're allowing anything in the game to access cameras directly. I'm not implying this is how the entire game should be setup for other things, surely physics changes should happen directly, not through thousands of messages per frame, but cameras usually only get a few changes per frame. The exception to requiring messages if for cameras changing themselves. If a camera update() method finds the camera is under the terrain, the camera should be able to correct itself directly, not having to send a message to change itself.
Dec 14, 2007 at 8:27 AM
Edited Dec 14, 2007 at 8:29 AM

LordIkon wrote:
I'm not implying this is how the entire game should be setup for other things, surely physics changes should happen directly, not through thousands of messages per frame, but cameras usually only get a few changes per frame. The exception to requiring messages if for cameras changing themselves. If a camera update() method finds the camera is under the terrain, the camera should be able to correct itself directly, not having to send a message to change itself.

The real question here is if you want two different ways of doing that. How do you explain to devs that when they are using a camera they have to send messages for updating position, but when they are using other entities they should use:

    this.SceneManger.CurrentScene.Entities[ENTITYID].Position
Furthermore this gets complicated by the fact that the camera position in most cases isn't actually updated, since the camera is mounted on a entity you would simply modify the entitys position and rotation.


shawmishrak wrote:
(Ignoring the quantum mechanics postulate that the mere act of observing an event changes it's outcome, of course!)

I wonder if quantum mechanics was invented by gnomes; "Does a falling tree make a sound if noone is there to hear it", which almost lead to a civil war :) (Dragonlance)
Coordinator
Dec 14, 2007 at 2:36 PM
I agree it does need some more thought.

I don't think we can have entity position and rotation automatically affect the camera, because many cameras position and/or rotation aren't affected by the entity.
Dec 14, 2007 at 2:54 PM

LordIkon wrote:

I don't think we can have entity position and rotation automatically affect the camera, because many cameras position and/or rotation aren't affected by the entity.


If a camera has a mount entity and a target entity, why can't it implement logic that says: "When my Update() is called, I'm going to update my position based on my mounted entity and update my rotation based on my target entity?"
Coordinator
Dec 14, 2007 at 3:36 PM
It can, but only if it is supposed to. A free roaming camera is unaffected by almost everything, but certainly the fixed camera could. The fixed camera already updates based on these things, but it updates when the camera updates, I'm not sure if we want all the camera's updating in the middle of other entities updating. Also, the arc-ball camera is affected by an entity's position, but not rotation.
Dec 14, 2007 at 4:04 PM
That's why the camera update logic is in the camera itself.
Coordinator
Dec 14, 2007 at 4:51 PM
Exactly, that is what is currently happening already.

If I have a fixed camera, and I rotate the attached entity, the camera will rotate to match. If the entity changes position, the camera will move to match.

Because your patch wasn't meant to be merge I never really tested it, but if the fixed camera is working properly you should be able to attach it to your rotating ship and see the effects.