Change Set 8305 / 8307

Dec 8, 2007 at 4:59 AM
New in 8305:
  • Preliminary render queue system. Render queue entries define a material, a geometry provider, and a world matrix. The graphics system will process the queue and perform all the rendering. In the future, this will allow for material-order rendering for efficiency, as well as shadow-map/reflection-map passes without zero client interaction.
  • XML-based material system is mostly implemented. There's still a lot that can be done here and like the render queue, this is just a very preliminary system.
  • Materials can be loaded directly from XML at run-time, or compiled into an XNB file (with effect file automatically referenced/built) and loaded through the content pipeline.

Don't let the lighting fool you. There is no concept of a light coded at the moment, it's just hard-coded into the shaders.

Feel free to experiment with the material system, and let me know what kind of graphics-system provided variables you would like. Currently, only the three matrices (and all combination types) along with a time variable are provided.


Oh, and I should probably take the time to apologize to the person who created the logo that I used. I did a fairly horrible job photoshopping it to include an alpha channel. ;)
Coordinator
Dec 8, 2007 at 5:30 AM
I'm missing 'RenderQueueEntry', that's my only error.
Dec 8, 2007 at 5:41 AM
How are you updating your copy? I just checked out the source tree into a temp folder and everything's there.
Coordinator
Dec 8, 2007 at 5:55 AM
hmmm, cpc update. Although there are conflicts, I bet the conflict is stopping it from finishing. I'll try again, if I have to I'll start a new one, however I updated during some changes of my own as well. :oP
Coordinator
Dec 8, 2007 at 6:01 AM
Really don't know why it refuses to see that file when I try updating. I guess I'll have to merge my stuff manually.
Coordinator
Dec 8, 2007 at 6:03 AM
It did upload it after all, but the merge screwed up the project file so it wasn't in the solution explorer. All is well :oP
Dec 8, 2007 at 6:33 AM
We really need to get a merge utility set up.
Coordinator
Dec 8, 2007 at 6:36 AM
I've added some camera functionality and commented more of the code. I think we should summarize the class itself with comments.

I added a could of empty classes, BaseEntity, and QSInterface. I connected them to CameraInterface, and placed them in folders. I added them empty to see what you guys thought of the folder structure and usage with CameraInterface. I wanted to get your guys take on the structure before I truly commit to something, especially because I'm not sure how the interface system will lay out, or entity hierarchy for that matter.

Feel free to remove any empty classes or restructure if needed for your parts on the engine.

Also, be aware the CameraInterface is not in use at all. It was just a mock up, I tend to be able to picture something once it is prototyped a little bit. I haven't worked with Dictionaries before, so I'll have to see, but apparanetly they have a O of about 1, which is great for searching for any cameras we might request.

Honestly, I think we should commit to spending 5 minutes reviewing other sections of code than our own before starting our own stuff each day. This will make sure we keep things simple, and consistant, and that we're learning from each other. It will also keep us from making dumb mistakes, and will let us learn the other code a little bit, which will make it easier if we ever need to work with other people's code.

Anyhow, I'm half awake the last couple nights as I've been coding, let me know if you guys see any blatant issues.

By the way, good job on the shader/model processor system so far Shaw. Can't wait to see its flexibility in action when we're rendering different models with different shaders, and using different materials and effects, all at once.
Coordinator
Dec 8, 2007 at 6:38 AM


shawmishrak wrote:
We really need to get a merge utility set up.


I agree, not that we're mostly using Visual Studio pro it should be easier. What is free, and decent? I like Beyond Compare, but it isn't free. I use Perforce at work, but I'm not sure if that is free. If it happened to be free I could certainly help us get up and running for it if noone else has used it. There is also Tortoise, which is free, and I believe it is also compatible with CPC, so people using VS Express could use it as well. I can do some research tomorrow.
Dec 8, 2007 at 8:09 AM
Can you explain the QSInterface/CameraInterface classes a bit? What are they used for, and who will hold instances of them? I'm a little confused by them. :)
Dec 8, 2007 at 10:41 AM

LordIkon wrote:

I agree, not that we're mostly using Visual Studio pro it should be easier.


Bear in mind that very few hobbyist dev will have pro. I for one don't as I get on fine with express,and cant afford the full version out of my own pocket. As such we dont want to discourage new dev by using stuff only compatiblie with pro.
Dec 8, 2007 at 1:01 PM
In the next checkin from me, which I hope will be this weekend (thought no promise) I'm adding merge capabilities to the build environment, it uses SourceGear DiffMerge a free and decent tool, which can diff and merge (hence the name I guess). So if you use the BE and cpc status you can easily see and merge changes.

A warning from here, do not check in files with 0 length, as it will crash cpc.
Coordinator
Dec 8, 2007 at 5:29 PM


shawmishrak wrote:
Can you explain the QSInterface/CameraInterface classes a bit? What are they used for, and who will hold instances of them? I'm a little confused by them. :)


Well they're only a thought at this point. My theory, off of what Sturm has said about the messaging system, is that when you send a message, you specify which interface to send the message to. In the message I could specify the message was of type CameraInterface, or something along those lines. Then all messages could go through an InterfaceManager, or a messaging system, that is really up to Sturm. But either way, the main messaging system could route the message to the proper interface.
Jan 8, 2008 at 9:38 PM
Ok I've been looking at QSInterface and it's use. It's only used for CameraInterface and in reality I can't see why this is needed. Having a list of cameras at the SceneManager and a ActiveCamera property would do just as well, having this would also remove quite a few passing of camera, as Game is available and you would always be able to write:

    if (this.Game.ActiveCamera.Frustum.Intersects(this.BoundingBox) == true) ... 
This way we would save the reference passing of the active camera.
Coordinator
Jan 14, 2008 at 3:35 PM
QSinterface isn't important, yet. We just need a common class to derive all interfaces from, and IUpdatable may work, but we may not always update all interfaces each frame.

Having an active camera inside Scene manager isn't really the issue, it is that we need a camera manager to handle all camera messages. We don't want to have to put all camera logic in the scene manager. I can begin to name around 100 different messages that the camera system may eventually have, we certainly do not want all of those inside the scene manager. Also, I though we agreed that cameras attached to Entities. If the camera is part of an entity, why would give a list of them to the Scene Manager as well?

As far as an active camera, we're not really passing it around much, once per frame the render interface gets that camera for the view and projection matrices. This has to be done no matter where we place the camera.
Jan 14, 2008 at 7:02 PM

LordIkon wrote:
QSinterface isn't important, yet. We just need a common class to derive all interfaces from, and IUpdatable may work, but we may not always update all interfaces each frame.


Not every updateable entity updates, it's up to the entity/system itself and the game. If you pause a game only the keyboard system should be update, where as all drawable entities should still draw. So even if a system only updates once event sec it still implements IUpdateable, as it still updates


LordIkon wrote:
Having an active camera inside Scene manager isn't really the issue, it is that we need a camera manager to handle all camera messages. We don't want to have to put all camera logic in the scene manager. I can begin to name around 100 different messages that the camera system may eventually have, we certainly do not want all of those inside the scene manager. Also, I though we agreed that cameras attached to Entities. If the camera is part of an entity, why would give a list of them to the Scene Manager as well?


There is no logic inside the SceneManager retained to the camera, except update order, all messages are processed by the camera itself. The current model is a good example of how it can go wrong. Because some cameras can Move/Pitch/Yaw/Strafe, the base class has these as virtual members. These are empty as the base camera does not know what this means, instead the FreeCamera and ArcBallCamera implement some of these methods. If I would introduce yet another movement type "Spin" I would need to create a virtual on the Camera class (Which means touching the Engine code, something gamedevs should refrain from doing) and create my own class (inside my game code). I would also need to change the CameraInterface class to handle the Spin

Using the model in my patch you would just need to implement the Spin on the camera in the game code and listen to the message which should make it spin, without touching the engine code.


LordIkon wrote:
As far as an active camera, we're not really passing it around much, once per frame the render interface gets that camera for the view and projection matrices. This has to be done no matter where we place the camera.


You wouldn't need to pass it around by ref all the time, that not a big deal at the moment as we only have one renderable item (terrain) but later when there are 1000's of different renderable items that's a lot of unneeded passing. Moving it up to a higher level clears up the interface a lot, which makes it easier for users to understand.
Coordinator
Jan 14, 2008 at 9:02 PM
What if there are 10 cameras of the same type all active at one time, but only 2 are handling messages for input at the moment. How would something like that be done?

I don't like the idea of camera's handling everything on their own. What was the point of even creating a camera system in the first place? This logic is like saying we should just have the camera contain the gamepad handling, because there is no point in going through a central authority like the gamepad handler. On the contrary however, I'd expect anything I wanted to know about the gamepad to handled in a gamepad handler, just I would expect all information I'd like about any camera to be able to be accessed through a camera manager/handler/interface.

This is the same thing we ran into with the graphics system. Why let all entities choose the logic on how to draw themselves if we can have one rendering system that can handle it?

This, from the beginning, was designed as a component based system, in which components are the authorities of as much as is possible from a design, and performance standpoint.

I have no problem with virtual calls to cameras that don't have them, the only time that will happen is if someone is sending the wrong message to a camera, like a spin message to a camera that doesn't spin. Camera's are only recieving a small handful of messages each frame probably.
Coordinator
Jan 14, 2008 at 9:04 PM


Sturm wrote:
You wouldn't need to pass it around by ref all the time, that not a big deal at the moment as we only have one renderable item (terrain) but later when there are 1000's of different renderable items that's a lot of unneeded passing. Moving it up to a higher level clears up the interface a lot, which makes it easier for users to understand.


Ahh, I see what you're saying. In that case, we're already doing that, or I thought we were. Once each frame the scene manager gets the latest camera from the camera interface. It then updates each scene using that camera. This means each scene is passed the camera only once. So if we have 1 scene manager and 3 scenes, we are passing the camera 4 times. Each thing from a scene that needs the current camera can get it from its parent scene.
Jan 14, 2008 at 9:46 PM

LordIkon wrote:
Ahh, I see what you're saying. In that case, we're already doing that, or I thought we were. Once each frame the scene manager gets the latest camera from the camera interface. It then updates each scene using that camera. This means each scene is passed the camera only once. So if we have 1 scene manager and 3 scenes, we are passing the camera 4 times. Each thing from a scene that needs the current camera can get it from its parent scene.


No the current camera is passed around using the RenderPassDesc class, which currently only contains the Camera. I'm not sure if there are going to be more contained inside that class, maybe Shaw can elaborate on it? If not, then having ActiveCamera available at a higher level makes even more sense.
Jan 14, 2008 at 10:08 PM
In the future, the chances are very high that this struct will contain more fields. Also, RenderPassDesc.RenderCamera != ActiveCamera. The active camera will be used for some rendering, but not all. For instance, the camera described by a light source may be referenced in this field.
Jan 14, 2008 at 10:46 PM
Thanks for clearing that up. ActiveCamera wasn't meant as the currently player camera, but the current rendering camera. But having it inside renderpassdesc will serve the same purpose. Instead of passing it to all subsystems would it be benefitial to have the desc on the scene node and simply access it using something like

this.Scene.RenderDescription.RenderCamera ??
Jan 14, 2008 at 11:53 PM
That would mean that the rendering system would have to know about the scene. With the current way of doing things, the renderer has no idea what it's rendering, or who is supplying the data. It just has a list of IRenderChunkProvider implementers that provide render data, using a RenderPassDesc structure describing the rendering pass.

My main concern is that this ties the renderer and scene together inseparably. Currently, there is nothing stopping the physics system from registering itself as a render data provider and issuing debug drawing geometry to the renderer, for example. This would be things like internal AABBs, force vectors, etc. I don't see the scene as being the central authority on everything that is rendered. It just manages everything in the logical game world.
Jan 15, 2008 at 3:25 AM
My aksing is simply if it would make sense to put it on a higher level, as bacially any rendering entity would need the information in the description, instead of passign around by ref is there any place you could put it in order to make it available within the same scope (or broader)?