# perrs

Member

51

122 Neutral

• Rank
Member
1. ## Center the object

"I have a problem with nr. 5. How do i know which Z to choose then unprojecting?" The vertex also has a Z value in screenspace (Actually, I meant projectionspace). Just keep this value as you are not interested in moving the object back or forth (correct?). " I can not use bounding sphere since the boundign shpere is of constant size. Because when i rotate the object i might be possible to zoom-in more since the rotation changed objects 2D screen shape (representation)." As I said earlier, this will place the object in the center of the screen. It will not necessary make the same amount of space on all sides on the screen. That's why I suggested the second approach.
2. ## Center the object

One solution I know to be used is where you generate a bounding sphere for the object, and then focus the camera on the center and move the camera back to radius times some constant (depending on how big the object should be one the screen). This will place the center of the object in the center of the screen, like Erik Rufelt suggested. If you, on the other hand, don't want the object centered, but rather make sure that there is the same amount of space on corresponding sides, you need to work in screenspace. Try the following: 1. First, make a good guess using the method mentioned above. 2. Project all vertices to screenspace and isolate the topmost, bottommost, leftmost and rightmost vertex. To position the object correctly over the x-axis: 3. From the leftmost and rightmost vertices, find out how long they must be moved to be placed correctly. 4. Take the leftmost vertex (could also be the rightmost) and translate that (still in screenspace) with the calculated distance. 5. Now, unproject it to find its world position. 6. Compare this world position with the old one to find out how much the camera should be moved. Do step 3-6 for the y-axis too. I haven't tried this so I cannot promise it will work as expected, but I believe so. Hope this helps, Per Rasmussen.
3. ## Point lighting with Deferred Shading

It sounds like you got the right idea. Quote:I am also trying to do point lighting at this stage but the point lights seem to either never be occluded or are never drawn at all (depending on, at this point, fairly random changes to settings). Make sure that you use the same depth buffer as you did when rendering the geometry. Also, make sure that depth buffer writing is disabled during rendering of the lights, and that depth testing is disabled during rendering of the directional light. Now, for rendering of the point lights: if (point light radius + near clip plane < distance from camera to point light) Reverse culling and disable depth testing; else Normal culling and enable depth testing; Hope this helps!
4. ## A pretty good solution to Depth-Bias Problem!

Interesting. But just to clarify; The epsilon you are talking about is used in all kinds of shadow mapping. Not just PCF. Correct? Question: How did you arrive at the formula: d = length (LightPosW - VertexPosW); epsilon = 1 / (d*d - 2*d); On a side note; Another way to avoid the problem all together is to change your polygon culling (eg. from counter-clockwise to clockwise) when rendering your shadow map. This will make sure that you only render the backside of objects which will be shadowed anyway due to the normal (at least if you are using phong or similar). This should yield some proper results in most "normal" cases. It does, of course, depend on that your objects are closest, but that is a requirement for many other things anyway. :) Best regards, Per Rasmussen
5. ## Spajders - new game

Yeah, it is pretty fun. Good game play idea and nice implementation. One thing, though: When the "game over" text appears the frame rate drops to around 1-2 fps. Just wanted to let you know.
6. ## Lighting rendering architecture doubt

ignotion: I've been having the exact same thoughts as you recently. However, I'm not sure you need as many shaders as you may think. To take your example. If you have a shader that can handle 1 omni, 1 directional and 1 spot, you don't need a shader that can handle 1 omni. You can just turn off the two other lights. I realize that this might not be the best solution performance wise, but as long as we are talking simple combinations of primitive lights, I do not believe is problem. You can save alot of shaders at very little cost, as these shaders will not be the bottlenecks anyway. You may still need quite a few shaders, but instead of 64 per special effect (4 omni * 4 directional * 4 spot = 64) you might do with four or five. However, if you plan to start using shadow mapping (or something similar) it is probably a good idea to do a render pass per light from the beginning. Perhaps I hybrid method could be a good idea. If you do one render pass with all the "simple" lights and after that one render pass per light it might not be such a bad idea. Best regards, Per Rasmussen.
7. ## XNA vs MDX, what is your opinion?

I am considering whether to use XNA or MDX for my next project. But I am having a hard time deciding. Reasons to use XNA: -- XNA seems to have better integration with the .net way of doing things. On several occasions it uses generics to ease certain tasks. -- XNA is newer and cleaner and I suspect it is going to be used a lot in the future. -- XNA has Xbox 360 support. (This isn't really that important to me though) Reasons to use managed DirectX: -- the XNA framework seems to be missing a lot of the functionalities of DirectX. -- XNA doesn't work in the Visual Studio 2005, for example meaning that I can't use the built-in shader debugger Visual Studio offers. -- XNA still seems to be a bit immature. (Even for a Beta 2) Anyway, these are just some of my views. I would like to here what you guys think.
8. ## [.net] Moving model with mouse

I am assuming that you are talking about moving a 3d model around in a 3d enviroment viewed from arbitrary angles. Actually this is more of a 3d graphics question but what the heck.... To do this properly you first must calculate a ray in 3d space from your mouse coordinates. This can be a bit tricky but you can find an example of it in the "Pick" sample of the MS DirectX SDK. It is in C++ though, but it is very easy to translate. The code for generating the ray is this: const D3DXMATRIX *pmatProj = g_Camera.GetProjMatrix(); POINT ptCursor; GetCursorPos( &ptCursor ); ScreenToClient( DXUTGetHWND(), &ptCursor ); // Compute the vector of the Pick ray in screen space D3DXVECTOR3 v; v.x = ( ( ( 2.0f * ptCursor.x ) / pd3dsdBackBuffer->Width ) - 1 ) / pmatProj->_11; v.y = -( ( ( 2.0f * ptCursor.y ) / pd3dsdBackBuffer->Height ) - 1 ) / pmatProj->_22; v.z = 1.0f; // Get the inverse view matrix const D3DXMATRIX matView = *g_Camera.GetViewMatrix(); const D3DXMATRIX matWorld = *g_Camera.GetWorldMatrix(); D3DXMATRIX mWorldView = matWorld * matView; D3DXMATRIX m; D3DXMatrixInverse( &m, NULL, &mWorldView ); // Transform the screen space Pick ray into 3D space vPickRayDir.x = v.x*m._11 + v.y*m._21 + v.z*m._31; vPickRayDir.y = v.x*m._12 + v.y*m._22 + v.z*m._32; vPickRayDir.z = v.x*m._13 + v.y*m._23 + v.z*m._33; vPickRayOrig.x = m._41; vPickRayOrig.y = m._42; vPickRayOrig.z = m._43; Once you can calculate this ray the rest is not too hard. Here is some pseudo code explaining the process: Vector3 mouseStartingPoint; Vector3 modelStartingPoint; Plane modelPlane; onMouseDown() { modelPlane = new Plane(myModel.position, camera.foreward); Ray r = calculateMouseRay(); modelStartingPoint = myModel.position; mouseStartingPoint = modelPlane.intersect(r); } OnMouseMove() { if (mouseDown) { Ray r = calculateMouseRay(); Vector3 mouseCurrentPoint = modelPlane.intersect(r); myModel.position = modelStartingPoint + (modelStartingPoint - mouseCurrentPoint); } } Here I make a plane that goes through the model and is parallel to the camera. I then find out where the mouse is pointing on this plane. I then use the starting position and the current position to calculate where to the model should be moved. Hope this make any sense. If not, please say so and I will try to explain further. Best Regards, Per Rasmussen.
9. ## transparent

Color keying works like this: You first choose a color that is your transparent color. This means that whenever the texture is rendered it will be transparent in the areas that has this color. Note that it is only this EXACT color, meaning that if your transparent color is pure green (R=0 G=255 B=0) an almost pure green (fx. R=1 G=255 B=0) will not be invisible but simple green. This is why Endurion warns against using jpeg as it compresses the image in blocks and will typically "blur" the colors in a block a little. Take his advice and use png. If you have problems with that you can simple use bmp (the native format of MS Paint) though they grow quite large in size. So what you should do is that you load the texture using D3DXCreateTextureFromFileEx as Endurion suggested and you parse the exact color you want transparent as the ColorKey argument. Note that you should set the alpha component of this color to ff (255). In the ol' days they had a load texture function that could set your color key to the color of the top left pixel in the texture. Not the most robust way but it made it alot easier to quickly make something transparent. Did this answer your question?
10. ## [.net] A .NET network SDK

SiCrane and u235: I know the framework quite well. What I am looking for is something a bit more advanced and feature rich. For example, something that automatically can "mirror" objects over a network. AP: Not a bad idea, but I don't believe remoting is suited for games.
11. ## [.net] A .NET network SDK

Can anyone point me to some network SDKs for .NET. What I am really looking for is some kind of library that can "mirror" (or "ghost") objects between server and client. Thanks in advance, Per Rasmussen.

14. ## What is the Proper Way

Well, I don't know the answer but I know that if that is wrong it will not be the first time. Last time I checked (about a year ago) there was no erreta made, but you could try to find out if there is now. Best Regards, Per Rasmussen.