Tag Info

New answers tagged

1

In this line here: Vertices[v] = Vector2.Transform(Vertices[v], rotate); You are overwriting your shape's vertices with the transformed vertices. The transformation you are creating is an absolute rotation, but you are applying it like a relative rotation. If this were simple algebra, you could use a relative rotation instead: Matrix rotate = ...


2

No, it won't work. The transformation of a sphere by a projection into NDC is not a sphere. You pick a single point on the sphere, and then assume you get the whole bounding volume back with just a single distance, but it is incorrect (i tried finding pictures of the resulting volume but failed. While you can see the deformation on how a sphere turns into ...


1

Clip-space does not have the range [-1,1] that you are describing. That is NDC space, which is achieved by dividing the clip-space coordinate by its W component. What is more, depending on the API, NDC may not be [-1,1] in all directions. This is the case in OpenGL, but in D3D the Z component ranges from [0,1] in NDC while X and Y range from [-1,1]. I ...


1

zNear is not really related to field of view. FOV specifies the angle of the frustrum, while zNear describes the distance to the nearest clipping plane. As an example, here are two frustrums with the same FOV, but different near clipping planes. And here is another frustrum with the same zNear as the first, but different FOV. A good approach to ...


1

zNear and zFar are measured in world space, not in anything to do with pixels. Their scale will depend on the scale of the scene you're rendering and how close/far the camera will be to the geometry. For instance, if your scene is modeled in meters, you might set zNear to 0.1 and zFar to 1000 or so. This would let you get the camera as close as 10 cm from ...


1

What you probably want to do is create wrapper around SpriteBatch or create extension methods for SpriteBatch that apply the desired per-sprite inversion to each Draw call. Then you could just do: spriteBatch.DrawWorldSprite(texture, position, color); (You could even create an overload with a scaling parameter, that does appropriate multiplication so you ...


0

To #2: yes, you are doing it wrong. You are trying to change the framework's 2d coordinate system, with its origin at top left (this follows texture coordinates convention in directX). You are allowed to make that change; the trade-off is that you have to do it all the time, with every draw. Since that's what you seem to dislike, you might consider the ...


0

Thank you all but I found an other way to do that. I created (or rather copied form this schema) a rotation matrix RotateMAT[16]: #define OGLToRadian(degre) ((degre) * (M_PI / 180.0f)) //... GLvoid ROT(float x, float y, float z) { const float cosA = cosf(OGLToRadian(GLrotate_y)); const float sinA = sinf(OGLToRadian(GLrotate_y)); float RotateMAT[16] = ...


2

OpenGL 1.x's built-in matrix operations are notoriously slow, and may even cause pipeline flushes in some cases. To gain performance, translate your gl matrix operations to client-side code (there are several solutions, http://glm.g-truc.net/0.9.5/index.html and http://cmldev.net/ being popular ones). If you already have a lot of code, you can easily write ...


2

When measuring performance, use frame times, rather than FPS. In your case: 1000 ms / 80 FPS => 12.5 msec/frame 1000 ms / 100 FPS => 10.0 msec/frame These are very even FPS numbers, which makes me suspect that they are tied to the display vsync. Have you tried disabling vsync (with a call like eglSwapInterval, or setting the Direct3D swap interval? ...


0

I got help in another part of this website on a similar question which answered this one. As such I'm going to answer my own question here and supply the answer I was given just to close this. So what I really needed was a working LookAt function, I'm still not sure what exactly was causing the problem I had before with the weird distortion other than ...


3

Transforming the ray position and direction by the inverse model transformation is correct. However, many ray-intersection routines assume that the ray direction is a unit vector. If the model transformation involves scaling, the ray direction won't be a unit vector afterward, and should likely be renormalized. However, the distance along the ray returned ...



Top 50 recent answers are included