Spoon feed me copy-pasta! DirectX line drawing in-world

[amadmonk]

So, how do I set up the SRT matrix for ID3DXLine:rawTransform?

I've already got primitive drawing working at a given pos by this sequence:

(in render setup)

			D3DXMatrixPerspectiveFovRH(&proj, cam->Fov*0.6f, 1920.0f/1200.0f, 0.0f, 1.00f);

			idVec3 forward;
			cam->Forward(forward);
			idVec3 up;
			cam->Up(up);

			D3DXVECTOR3 vEyePt( cam->vecPosition[0], cam->vecPosition[1], cam->vecPosition[2] );
			D3DXVECTOR3 vLookatPt( cam->vecPosition[0]+forward[0], cam->vecPosition[1]+forward[1], cam->vecPosition[2]+forward[2] );
			D3DXVECTOR3 vUpVec(up[0], up[1], up[2]); //0.0f, 0.0f, 1.0f );

			D3DXMatrixLookAtRH(&view, &vEyePt, &vLookatPt, &vUpVec);

...

(in primitive render)

		D3DXMatrixTranslation(&world, X, Y, Z);
		m_pDevice->SetTransform(D3DTS_WORLD, &world);
		m_pDevice->SetTransform(D3DTS_VIEW, &view);
		m_pDevice->SetTransform(D3DTS_PROJECTION, &proj);

...

		m_pDevice->SetStreamSource(0, m_vb_red, 0, sizeof(CUSTOMVERTEX));		
		m_pDevice->SetIndices(m_ib_red);
		m_pDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST,0,0,5,0,2);

However, a similar sequence for DrawTransform isn't working correctly. I get a strangely foreshortened line, and only when I view the line segments at a particular camera position.

(same render setup)

		D3DXMatrixTranslation(&world, 0, 0, 0);
		m_pDevice->SetTransform(D3DTS_WORLD, &world);
		m_pDevice->SetTransform(D3DTS_VIEW, &view);
		m_pDevice->SetTransform(D3DTS_PROJECTION, &proj);
		m_pDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_FALSE);
		m_pLine->DrawTransform(pVertices, dwVertexCount, &view, dwColor);
		m_pDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_TRUE);

I can't figure out which matrix to use in the DrawTransform call. Supposedly I should use the projection mat, but that doesn't work either.

I turn off the ZENABLE switch because I'd read that there was a Z-buffer issue with DrawTransform.

I know I'm flailing here, but I'm not sure which matrix I should be using.

[Sychotix]

Might wanna say which language.

[amadmonk]

Wow. You can't figure out the C++ aspect?

[adaephon]

According to ID3DXLine:rawTransform - GameDev.net you want a view*proj matrix

[amadmonk]

Hmm, so then in theory if I set the world mat to identity, that should be the same?

Sorry if I'm being a little thick, but I'm just sort of confused; I want to be able to draw a line from X1,Y1,Z1 (world coords) to X2,Y2,Z2. I don't want to have to do a world->screen and draw it 2D.

If I don't set the full world/view/proj to account for the world's coordinate system, the camera, and the 3D/2D projection, I am truly clueless how D3D is going to "know" where to draw a given set of world line-coords. That's why I set the world mat to 0,0,0 above -- thinking that I was "anchoring" world space at the origin.

Obviously I'm D3D clueless. I guess what I'll try next is manually creating the view and proj mats and multiplying them, and using the product in the DrawTransform call.

Thanks!

[DamonT]

Hmm, so then in theory if I set the world mat to identity, that should be the same?

Sorry if I'm being a little thick, but I'm just sort of confused; I want to be able to draw a line from X1,Y1,Z1 (world coords) to X2,Y2,Z2. I don't want to have to do a world->screen and draw it 2D.

If I don't set the full world/view/proj to account for the world's coordinate system, the camera, and the 3D/2D projection, I am truly clueless how D3D is going to "know" where to draw a given set of world line-coords. That's why I set the world mat to 0,0,0 above -- thinking that I was "anchoring" world space at the origin.

Obviously I'm D3D clueless. I guess what I'll try next is manually creating the view and proj mats and multiplying them, and using the product in the DrawTransform call.

Thanks!

I once tried to draw lines with the d3dline api too, however it's simply not working.
The lines were correctly drew, but you could always see random lines through your screen and lines on the opposite direction too. It seems that the DrawTransform function of it somehow bugged... (well that's what i read, and i really couldn't find any reason for that strange behaviour!)
Just stick to the DrawIndexedPrimitives, it's simply better and working.

[amadmonk]

Ah, that would explain why DIP works flawlessly and DT doesn't work at all. Thanks!

---------- Post added at 10:21 AM ---------- Previous post was at 09:33 AM ----------

So close, but so far...



(Obviously, my Z-clipping is off, but that's fixable)

However, as soon as you move to where one or more of the points is behind the view...



And yes, this appears to be a known ID3DXLine bug.

---------- Post added at 10:54 AM ---------- Previous post was at 10:21 AM ----------

I tried one more thing. This post (ID3DXLine Clipping Problem - App Hub Forums) indicated that the poster "fixed" the problem by creating a clipping plane at the view and telling D3D to clip the lines. Sadly, that didn't appear to help; I still got points behind the view bouncing to infinity.

[Robske]

I've experienced the same behaviour with ID3DXLine's managed sibling. (go figure)

DrawIndexedUserPrimitives using the LineList type however does work flawlessly but you lose some properties of the Line type (such as thickness).

[amadmonk]

Hmm, thanks for the LineList tip. I may give that a try; my code is more set up for DrawIndexedPrimitive anyway; I'll just have to change the translation matrix since I will be (hopefully) supplying the line vertex info in worldspace (I define my primitives in model space and translate world space to their coords).

[MaiN]

I think I had the same problem once, but Kynox had the solution; lines behind the camera get drawn like that. You need to manually test if the lines lie behind the camera.

[amadmonk]

Actually I fixed it using the DrawPrimitive suggestion. It's a little slow, but since I'm just using it to visualize/debug my pathfinding connections/path, it works okay.



Now I just need to figure out why my A* implementation is returning nonoptimal paths. And I'm even using the expensive-but-perfect (Djikstra) estimater function! Clearly, there's a bug...

[narfman0]

Future reference, using the draw line method, might want to clip the line at the frustum.

1) get intersects of line -> frustum planes
2) draw using in frustum coords/on plane coords instead of in frustum/out of frustum
3) out of frustum should never be drawn

This is nice because you should be wanting to clip far points/offscreen already, riiight? heh. Nonetheless looks good with indexed primitives!

[MaiN]

Actually I fixed it using the DrawPrimitive suggestion. It's a little slow, but since I'm just using it to visualize/debug my pathfinding connections/path, it works okay.



Now I just need to figure out why my A* implementation is returning nonoptimal paths. And I'm even using the expensive-but-perfect (Djikstra) estimater function! Clearly, there's a bug...

What do you mean with perfect estimater function? Dijkstra is not a heuristic function, but another algorithm entirely. Dijkstra is only more useful than A* when you just need to find the closest "vendor" something like that, not when you have a specific end point.

[Robske]

What do you mean with perfect estimater function? Dijkstra is not a heuristic function, but another algorithm entirely. Dijkstra is only more useful than A* when you just need to find the closest "vendor" something like that, not when you have a specific end point.

An implementation of A* where the estimater/heuristic returns 0 is in essention Dijkstra's algorithm.

[MaiN]

An implementation of A* where the estimater/heuristic returns 0 is in essention Dijkstra's algorithm.

Ah, of course. But how is a heuristic that returns 0 perfect? Dijkstra is only useful in few cases (like I mentioned). Removing the heuristic from A* is pretty much removing all of its awesomeness.