To fix it, just right click on that old project where Build and Rebuild buttons are located, and you should see a “Upgrade” in that menu. This upgrade will fix all of the version problem for you including using the newest version of dll for XNA frame work.

This guy is doing something similar to what I did and how he/she generates road and it looks amazing. My city is a joke compare to this guy. My city is a combination of many street blocks and is very boring and unrealistic.

I am going to look at that guy’s work and see if I can make my city better.

I am going to use occlusion culling to see if this will fix it. However, to better fix the problem, I am planning the modify the 3D models to remove all internal face that won’t render out. Because most of the model is use as static background house and won’t have window and door and don’t allow user to enter, so there is no need to render its internal structure. Manually remove them can reduce the polygon count a lot.

Especially collision detection isn’t enable for them yet, if enable, frame rate drop more.

copy down here:
[Quote]
I’ve found a fix to a common annoyance I’ve had in Visual Studio. I always wanted an option called “Add Existing Folder” to right next to “Add Existing Item” in the “Add” context menu item in the solution explorer. It was always a long drawn out process for me to add a folder that already existed (renaming the folder I wanted to add, creating the an empty folder with the desired name through visual studio, then adding all of the files back into the newly created folder).

Instead what you can do is hit the “Show All Files” tool strip button at the top of the solution explorer, then right click on the folder you want to add and hit “Include In Project”. Pretty trivial. Its amazing how long you can use a product and not know about all of its features. Which reminds me, do you know about the Exceptions Dialog Box?
[/Quote]

Great thank to that guy.

For example, you open the model in directX view, a door facing north and has positive z value. If you press the Z key, it will put camera at positive Z axis so you can see the door facing you. If you render the model at XNA game, you will see the door still facing north, however, the door is facing -Z now. It is because in DirectX viewer, +Z is north, and in XNA, +Z is south, so x file importer will flip the z’s value to make positive z be negative z so it is still facing north which is good.

======================================
From here:

http://social.msdn.microsoft.com/forums/en-US/xnagamestudioexpress/thread/07f6d3b7-e2fe-492b-99b6-d5e4ea03a56e/

It’s only the .x contnet importer provided with XNA that flips the model. The documentation you are quoting is for people who are designing their own importers. The reason why the included .x importer flips the model is because D3D is left handed, most people use left handed coords in D3D and most existing .x exporters only export to left handed coords. So the XNA .x importer assumes any incoming model is left handed and must be flipped.

======================================
Also, in XNA Game Studio 3.1′s “Standard Importers and Processors” page, it said:
X File – XNA Framework
XImporter
Imports game assets specified with the DirectX X file format (.x).
This importer expects the coordinate system to be left-handed.

So I guess “This importer expects the coordinate system to be left-handed.” means it expects the +z is facing north so it will make it -z to make it facing north too.

=====================================
so when you specify door window’s position in your model street block that load 3D models into game to make a city and need to manually put door in 3D model door’s position, be careful. When you use fragmotion or 3ds max to open the 3D model and find out the vertex info of a the door, flip the z value before import into xml spec file.

For example,
ContentManager content = HamsterEngine.Instance.Content1; //where room is HamsterEngineAssets
Texture2D texture1 = content.Load(“file”);
texture1.Tag = “1″;

Texture2D texture2 = content.Load(“HamsterEngineAssets\file”);

then you can compare the tag of texture1 and texture2 to see if they are different and even they are supposed to be the same resource, because asset name is different, so content manager thinks they are 2 different resource and will load it twice.

It is because when content manager load a resource, it stores into a hash table and the key is asset name, so if you try to load the same resource using different asset name, it will think it is a new resource. So if you are getting Texture2D from RoomTexture using texture’s abs path, make sure you always use abs path to avoid loading texture repeatly.

A door is consists of a door frame and the door itself. And depends on what it is for, it may has a portal at the door frame so when the door is opened, player can go into the door frame and go through the portal to go somewhere else.

Portal should be deactivated if door is closed. Also, to make the portal thing works in game logic, the door should be lead to nowhere. So there is a door frame at the wall, and when the door is opened, there is a portal inside and player can go in and touch the portal which will load another level or location and put the player there. If the portal isn’t here, there should be just the wall and nothing else (so without the portal, open the door will only reveal the wall).

So the door will cover up the portal when the door is closed or may be don’t render the portal which is just a 2D image.

The door frame should be big enough to cover the whole door.

Both the door and door frame can be generated at run time and textures can be replaced at anytime. Because we only have few different door size, like 1) normal size single door, 2) big single door that is bigger than the normal size single door and is probably used as the front door, 3) normal double door that may be use in big dinner room in a big luxury house 4) big double door used in big house as front door. There are definitely more than those kinds of doors, but let’s keep it simple and only 4 of them.

So we will have 1 model for each different door, and a struct to store each door’s instance’s textures, location. The size of the model isn’t going to change at all because we need to make sure the door will fit into the frame well and make sure the texture won’t sketch (don’t want to re-calcuate UV every time we render it).

The door should have 3 textures, the front, the back, and the side. Just have the texture pointer for side instead of using a flag to decide whether to use front or back texture for side.

The door frame’s texture is tricky. Because the door is inside of the door frame, so the side texture usually isn’t seem so it doesn’t matter much. But the door frame is always visual from inside of the house or outside of the house. We need to take care of situation that outside of the room has one texture and inside of the room has another texture.

For example, outside is black and inside is white. In reality, the door frame may be yellow color and when they paint the house, they just paint the outside part to be black and inside part to be white. Or may be they don’t paint the door frame and leave it to be yellow color. And because we have 1 model for each different kind of door, so the model need to able to take care of situation that the side of the frame has black outside and white inside and situation that the side of the frame is yellow. So we need to create a model (for door frame) that there are 2 textures for the side and use the middle line of the side as separation to display 2 different textures or colors.

Note, I found it is actually pretty difficult to integrate into the game, so what I am going to do is to put each door as a game object and the portal as game object too, with the Data in GameObject set to null and allow to draw GameState, the door frame will be intergrate into the house as a static mesh so don’t need additional code to render the door frame.

So I create a door physics object and a un-movable physics object in the left of the door to act as the door frame, and connect the door and door frame using a hinge join. Well, this is the easy part. The difficult part is the door will fly out of the door frame. To fix this, (after a week of time to fix the base physics object creation code and many experiement), I can only reduce the mass of the door to 1 kb/lb/unit, so the door won’t fly out from the door frame. To make the door move, I have already using door’s velocity instead of adding force, but because kinetic energy is E=0.5mv^2, so the heavy door has lots of kinetic energy and make the door flies out from the frame. Actually, it doesn’t flies out from the door frame completely, it is like a spring, that it flies out and then spring back.

It is kind of sad that the hinge join doesn’t have some kind of hard limit so no matter how big the kinetic energy is, the object won’t fly out from the hinge join, but they didn’t have this kind of hard limit.

void ProcessGeometry(GeometryContent geometry)
{
…
geometry.Vertices.CreateVertexBuffer(
out vertexBufferContent,
out vertexElements,
context.TargetPlatform);

which throw an exception because animation in geometry’s Vertex (which is VertexContent)’s channel contains weight channel, and weight channel’s data can’t be stored in VertexBufferContent. Is that mean I need to create another thing to store weight in custom model.

I will try to ask question. But I don’t think there is any example other there.

Note: this is fixed. I was able to copy code from the source code from XNA using Reflector and implement those necessary functions to have animation in custom model.