QuickStart Engine

Can we change the Update method in BaseEntity so it's using the virtual keyword?

Or is there a different way in place for inherited entities to update and i'm just missing it?

We actually got rid of inherited entities for the time being. Our original structure was going to have different Entity types, for example, we had a camera entity, and static/dynamic entities. It was decided that we would have one basic entity and have the ability to expand upon it through different components.

What exactly are you trying to do?

Ack... I'm not too sure really. I'm just messing around still (still learning!).

I've made a "SkyDome" class which works out the vertices/indices to draw a dome. It inherits from BaseEntity (similar to how that Skyplane one worked).

I'm trying to set the suns position based on the current time and i'm trying to 'do stuff' depending on the position of the camera. (i'm also trying to get the dome to move (on X+Z) with the camera.


Don't waste too much time on this thread because i'm still out of my depth

You need to make the SkyDome Class a component I suppose, and attach it to the entity.

That way when the entity updates it will call the SkyDome update method so you can do your stuff.

Look at RenderComponent, effectively what your doing is creating a specialized RenderComponent.

Ah right, I see.

I was basing it on the terrain class which inherits from baseentity.

I'll have a go at making it a component instead

Yes, but the rendering would ideally still be done through the render component.

Think of it in an Object Oriented way. The sky could be there, but maybe you find a reason not to render it. If you have a SkyDome component then the sky would exist, but if you don't give it a RenderComponent then it wouldn't render.

This is similar to how you make cameras. Any object can become a camera just by giving it that component.

A skydome is really just a model, like any other, it just uses a different shader. I'm not sure how to change the shader as I haven't learned how the graphics system works. But if you figure that out, then all the skydome component would need to do is rotate itself.

The problem with that is that an entity doesn't have any sort of graphical information and its all inside the render component, how would you pass the render information, which would be in the sky component, to the render component?

Perhaps you should just inherit the skydome component from the render component, after all it is renderable and your just changing what it does.

At the moment there is no way to turn off rendering of a render component however, which seems inefficent because otherwise your going to have to remove the render component and recreate it whenever you want to switch its state instead of saving the resources of creating and deletion and just sending a message to a render component that it should no longer render.

I've also noticed that there is no culling of objects and no state batching which is going to make the graphics grind to a halt later as well.

Basic frustum culling is simple to add in although some proper spatial partitioning would work better, perhaps a loose octree.

State batching will be harder to do because currently materials are hard to sort every frame because there is no record of if they were loaded from the same QSM file instead it would have to be done on the effect file and settings during runtime, very inefficent.

Might work best to make a material store its QSM file path it was loaded from and make sure all QSM files have unique names, that would allow for easy sorting of materials and some state batching.

Of course if you want to get into shader and hardware instancing that still wouldn't work because currently a renderchunk doesn't know the model that the vertex buffer was created from either so you can't batch up the vertex information as well.

Hmm, think I went off topic there.

Off-topic is good. It's easier to think about things you're not suppose to think about than thinking about things you are. Possibly.

The materials system is confusing me a bit at the moment. Do all the techniques in the specified effects file run?

On a side note: I see no way to be selective about which meshes of an imported model you wish to load using StaticModel. Am I missing it or is this functionality just not in there yet?

<googles 'octree' />

Oh I see. A bit like quadtree in a way, but.. different. I suppose the name should've given it away a bit.

lordikon wrote:Yes, but the rendering would ideally still be done through the render component.

Think of it in an Object Oriented way. The sky could be there, but maybe you find a reason not to render it. If you have a SkyDome component then the sky would exist, but if you don't give it a RenderComponent then it wouldn't render.

This is similar to how you make cameras. Any object can become a camera just by giving it that component.

A skydome is really just a model, like any other, it just uses a different shader. I'm not sure how to change the shader as I haven't learned how the graphics system works. But if you figure that out, then all the skydome component would need to do is rotate itself.

In which case, the Terrain (which is currently inherited from BaseEntity) should really be made a render component which can be applied to an entity. That way the Sky and Terrain are both render components (it doesnt make sense to me to have one as an entity and one as a component). Same with water, I suppose.

On a side note: I see no way to be selective about which meshes of an imported model you wish to load using StaticModel. Am I missing it or is this functionality just not in there yet?

If you want to load up part of a model on its own then shouldn't it be seperated into its own model?

True, that.

RenderComponent holds all render information, you'd simply give it the skydome's mesh and call it good.

Terrain shouldn't be a render component alone, it also has physics. Terrain should be just another entity, with a render and physics component.

Nothing can 'BE' a component, all objects must be entities. What components something has determines what it will be. So:

- Sky, is an entity, with a render component.
- Terrain, is an entity, with a render and physics component.
- Water, is an entity, with a render component, and if you want any water-based physics, then it would also have a physics component.

Why would you only want to load specific meshes in a model? Wouldn't you just separate an model into separate models when you export it?

Why would you only want to load specific meshes in a model? Wouldn't you just separate an model into separate models when you export it?

Yeah you can/should do that. It's just that XNA offers that functionality so I feel as if QuickStart should allow it too (obviously not an important thing, something for version 3 maybe ).

- Terrain, is an entity, with a render and physics component.

Currently Terrain doesn't have a render component at all. It's just an entity with physics applied to it. This could be converted easily enough I suppose.

From an OO point of view, 'Terrain' (the vertices + indices) is a StaticModel, as is Sky (well, a 'dome').

Perhaps it'd make more sense to change RenderComponent from this:

Code: Select all

public RenderComponent(BaseEntity parent, string modelPath, string materialPath)
    : base(parent)
{
    LoadModel(modelPath);
    LoadMaterial(materialPath);
}


to this...

Code: Select all

public RenderComponent(BaseEntity parent, StaticModel model, string materialPath)
    : base(parent)
{
    LoadModel(modelPath);
    LoadMaterial(materialPath);
}


Then you could have Terrain (or TerrainModel maybe) inherit from StaticModel and pass the model into the RenderComponent, which gets passed into the entity. Then give the material to the StaticModel instead of the RenderComponent.

So loading a model into the scene would change very slightly..

Code: Select all

// create an entity
BaseEntity newEntity = new BaseEntity(this.game, position, Matrix.Identity, 2.0f);

// load the model and material path (or material object?)
StaticModel myCubeModel = this.Game.ModelLoader.LoadStaticModel("Models/unit_cube", myMaterial);

// create a new render component and pass it the entity
RenderComponent newRenderComponent = new RenderComponent(newEntity, myCubeModel);

// create a physics component and pass it the entity, physicsscene, shape and scale
PhysicsComponent newPhysComponent = new PhysicsComponent(newEntity, this.game.SceneManager.PhysicsScene, ShapeType.Box, 10.0f);                   

// add the actor
this.game.SceneManager.AddActor(newPhysComponent.PhysicsActor);

// add the entity
this.game.SceneManager.AddEntity(newEntity);  // Add the entity to the scene manager


And loading a terrain into the scene would be something similar to this:

Code: Select all

// create an entity
BaseEntity newEntity = new BaseEntity(this.game, position, Matrix.Identity, 2.0f);

// create a terrain model. Terrain inherits from StaticModel
Terrain newTerrain = new Terrain(this.game, LOD.High);
newTerrain.ElevationStrength = 25;
newTerrain.InitTerrainTextures("./Textures/grass", "./Textures/rock", "./Textures/sand");
if (this.game.Settings.GraphicsLevel >= GraphicsLevel.High)
{
   newTerrain.InitTerrainNormalsTextures("./Textures/grassNormal", "./Textures/rockNormal", "./Textures/sandNormal");
}
newTerrain.Initialize("./Images/Heightmaps/gcanyon", "./Images/Terrainmaps/gcanyonTerrain", 4, 25, this.game.SceneManager.PhysicsScene);


// create a new render component and pass it the entity, model
RenderComponent newRenderComponent = new RenderComponent(newEntity, newTerrain);

// create a physics component for the terrain
PhysicsComponent terrainPhysicsComp = new PhysicsComponent(newTerrain, this.game.SceneManager.PhysicsScene,
                                                                       newTerrain.heightData, newTerrain.ScaleFactor);
newTerrain.SetupLODS();


// add the actor
this.game.SceneManager.AddActor(terrainPhysicsComp.PhysicsActor);

// add the terrain ENTITY (not model) to the scene
this.game.SceneManager.AddEntity(newEntity);


Would that make more sense? It'd mean that any 'generated' models are just StaticModels, just like any other model. RenderComponent is simpily a component which holds a model and gives you options that you could perform on the model it holds. And an entity is something on which you can apply a render component, physics component..etc..

Or to put it slightly simplified way..

Loading a model from a file would be like this:

Code: Select all

BaseEntity myEntity = new BaseEntity();

Material myMaterial = game.Content.Load<Material>("Material/grass");

StaticModel myCube = game.ModelLoader.LoadStaticModel(modelPath, myMaterial);

RenderComponent myRenderComponent = new RenderComponent(myEntity, myCube);

PhysicsComponent myPhysicsComponent = new PhysicsComponent(myEntity);

SceneMgr.addActor(myPhysicsComponent.PhysicsActor);
SceneMgr.addEntity(myEntity);


Loading a generated model (such as terrain) would be like this

Code: Select all

BaseEntity myEntity = new BaseEntity();

Material myMaterial = game.Content.Load<Material>("Material/grass");

Terrain myTerrain = new Terrain(myMaterial); // terrain extends staticmodel

RenderComponent myRenderComponent = new RenderComponent(myEntity, myTerrain);

PhysicsComponent myPhysicsComponent = new PhysicsComponent(myEntity);

SceneMgr.addActor(myPhysicsComponent.PhysicsActor);
SceneMgr.addEntity(myEntity);