Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Jul 2006
Offline Last Active Sep 02 2012 12:19 PM

Posts I've Made

In Topic: [Solved] Thick (Constant-Width) Lines Using Quads

30 December 2011 - 01:35 AM


Thanks for the fast reply and the idea! It turns out that the point where the triangles cross will be the W = 0 point, so your thinking was spot-on and a lot more exact than mine Posted Image (I was taking potshots in the dark hoping that the point I picked would keep the perspective--I'm glad I now know the reason).

However, your reply inspired me to try something else, and I managed to solve my problem!

I was solving for the point where the triangles crossed by parametrizing the equations of the 3D lines, not realizing that if I had a line in the pure Z direction (which I did since I'm making a grid), I could not always rely on the X and Y vectors of the line to parametrize it, since I would occasionally get a NaN in (I parametrize and solve for the line intersection point as shown in this link: http://mathforum.org...view/63719.html)

Therefore, I needed to add a bit to my code:

if ((extrudeScale1 < 0) ^ (extrudeScale2 < 0))
    // just assume line direction won't be hurt by using X and Y
    float x1 = line1start.X;
    float x2 = line2start.X;
    float y1 = line1start.Y;
    float y2 = line2start.Y;
    float a1 = line1vec.X;
    float a2 = line2vec.X;
    float b1 = line1vec.Y;
    float b2 = line2vec.Y;
    if ((Math.Abs(lineDirection.Y) < 0.001f) && (Math.Abs(lineDirection.X) < 0.001f))
	    // if the line is purely in the Z direction, however, we need to use Z instead of Y
	    y1 = line1start.Z;
	    y2 = line2start.Z;
	    b1 = line1vec.Z;
	    b2 = line2vec.Z;
    else if ((Math.Abs(lineDirection.X) < 0.001f) && (Math.Abs(lineDirection.Z) < 0.001f))
	    // and similarly, if purely in the Y direction, we need to use Z instead of X
	    x1 = line1start.Z;
	    x2 = line2start.Z;
	    a1 = line1vec.Z;
	    a2 = line2vec.Z;
    float t1 = (y1 - y2 - b2 * ((x1 - x2) / a2)) / (b2 * a1 / a2 - b1);
    float x = line1vec.X * t1 + line1start.X;
    float y = line1vec.Y * t1 + line1start.Y;
    float z = line1vec.Z * t1 + line1start.Z;

Where line1vec and line1start are the starts of the _diagonals_ of the quad, and lineDirection is the direction of the line we are _drawing_. Sorry it's not very clean...and there's probably some optimization to be made too. As usual I don't make any guarantees...Posted Image

I don't completely understand I had to use Z instead of X when drawing a Y-line (I assume it has to do with the extrusion direction being in the pure X-direction when I was sitting along the Z-axis?), but it did work. Now I have thick lines! (I'm wondering if it was worth the effort and hair-pulling for my little project--but hopefully it will be for someone else).

Posted Image

They're not exactly award-winning without a fair amount of AA, and even then they're pretty ugly. There may even still be some artifacts in there...but I think I'm ready to call them good-enough for my game Posted Image

Thanks again, Jason, for your help--without the help and encouragement of the GD community I'd have made far less progress on my project.

Best regards,
-- Steve

In Topic: [Solved] Thick (Constant-Width) Lines Using Quads

28 December 2011 - 06:41 PM

Well, after a little bit of struggling yesterday I've come up with a buggy, but somewhat-working, implementation.

My basic steps are as follows:
  • Get the vector of the line:
    lineDirection = (lineStart - lineEnd)
  • Find our soon-to-be constructed quad's normal as:
    quadNormal = cameraPosition - lineMidpoint
    Where lineMidpoint = ((lineStart + lineEnd) / 2). I reason this should be the quad's normal since the quad will always be facing the camera, like a billboard.
  • Get the direction along which we should extrude vertices from our line, which is the cross product of lineDirection and quadNormal:
    extrudeDirection = Vector3.Cross(lineDirection, quadNormal)
    Normalize extrudeDirection.
  • Get the W of lineStart and lineEnd by transforming them by the viewMatrix * projectionMatrix.
    wStart = (Vector3.Transform(lineStart, viewMatrix * projectionMatrix)).W
    				wEnd = (Vector3.Transform(lineEnd, viewMatrix * projectionMatrix)).W
  • Extrude vertices from the line along the extrudeDirection vector, in some multiple of the W.
    Vector3 startVert1 = lineStart + extrudeDirection * wStart * lineWeight
    				Vector3 startVert2 = lineStart - extrudeDirection * wStart * lineWeight
    				Vector3 endVert1 = lineEnd + extrudeDirection * wEnd * lineWeight
    				Vector3 endVert2 = lineEnd - extrudeDirection * wEnd * lineWeight
  • Connect the vertices to form a quad.
And therein lies the hitch, which took some unraveling for me.

If you are far from the line, both W's will be positive, which is fine, since presumably you connected your four vertices to form a quad with the diagonal of the triangles being shared between them. Un-projected, this quad looks like a trapezoid, with bases on either side, and one base larger than the other to cancel out the W-divide. Everything works well.

However, if you get close to the line and rotate the camera a bit to face one end, one vertex will go off-screen and behind the camera, and thus one of the W's will be negative. This mathematically legit, I've reasoned, but your vertices that you extrude will be created on opposite sides of the line. If you don't change the way your vertices are connected in this situation, your triangle's diagonals will cross, because on one side of the quad the vertices have been flipped over the line. The result is you get an extra "flap" of the triangle either below or above your line, which confused me to no end yesterday. In the below (high-quality rendering) diagram, the red section is what I'm talking about.

Posted Image

To get rid of the red section, I adjusted the vertices of the triangles to the point where the diagonals cross when one of the W's was negative. That way, you'd get just the white part of the two triangles. (To get this point, I solve the equations of the two lines in 3D (since they're coplanar, they will intersect).)

That seemed to solve the problem in one little test I did, but when I scaled up and made a bunch of lines for my in-game grid, problems galore popped up, including some of the same problems the D3DXLine class seems to have (it appears to negate the transforms when you get close), which is not a good sign.

If anyone had the patience to read my essay on drawing lines with quads and has an idea on where in this process I went wrong, please do let me know--I'm very curious. I also don't want to abandon thick lines, but for now I'm just using a LINE_LIST to draw my grid.

I'll keep us updated if I come up with anything else, too.

-- Steve

In Topic: How to tell if triangles enclose a volume

02 March 2011 - 09:28 PM

Emergent, alvaro,

These were two great answers and a great discussion to read--I must admit I'm not following completely on the math, but the methods you've suggested make sense to me.

For the purposes of the game I'm writing, I am not concerned about the fringe case Klein bottle, but that is an interesting point since a Klein bottle doesn't enclose anything :)

I really like the painting solution, though. When I find the time to implement it, I'll give it a shot and [hopefully remember to] post the results.

Much thanks for the ideas--the contents of your posts and the support of this community gives me both the confidence and the willpower to finish what I started...(when I find the time!)

-- Steve.

In Topic: Limit quaternion rotation speed

28 February 2011 - 07:30 PM

So, suppose I want to go from a rotation q1 to a rotation q2 and I don't want to rotate by more than x radians per frame.

I tried this, but for some reason, it seem to introduce some unexpected rotations from time to time, any idea why?

1) Find delta rotation that will transform q1 into q2: delta = q2 * q1.Inverse()
2) Convert delta rotation to axis + angle
3) Clamp the angle to x
4) Reconstruct new (clamped) delta rotation
5) My final, clamped rotaiton should now be: delta * v1

Ideas? Suggestions? Thanks!



I'm not sure where the unexpected rotations come from--are you using Euler angles at any point? They might be because of a phenomenon known as gimbal lock--see this wiki article: http://en.wikipedia....ki/Gimbal_lock. This happens when you go to Euler angles from quaternions (quaternions avoid the problem), because you have a series of rotations, and depending on which order you apply them (e.g., X-Y-Z, Z-X-Y), it may change things. That shouldn't affect axis-angle, though, but my hunch is the way to get around it is just keep everything as quaternions.

I know that you can simply add two quaternions and divide them to "average" them out, resulting in a smoother transition. I had an application where there was a tank rolling over a heightmap--I noticed the tank "snapped" to the normals of each triangle it rolled over, so I averaged the normals between frames and smoothed the transitions a lot.

Quaternion approach (Quaternion initialRotation, Quaternion finalRotation)
	return (initialRotation + finalRotation)/2;

If you keep feeding that back into itself after each frame, you'll get a fast movement at first and a slow movement toward the end, which looks nice.

Using the same principle, you can get a quaternion somewhere between your initial and final:
Quaternion approach (Quaternion initialRotation, Quaternion finalRotation, float position)
	// position between 0 and 1
	return (1 - position) * initialRotation + position * finalRotation;

Correct me if I'm wrong, or let me know if that helps.

Best of luck,
-- Steve.

In Topic: [slimDX] textures on the simpletriangle

02 January 2011 - 12:54 PM

Your HLSL shader that you posted -- is that the complete shader? You never defined "txDiffuse," so it'll tell you that it doesn't exist when it tries to compile the shader.

You're going to want to take a look at Riemer's XNA or Managed DirectX tutorials for this problem; it's explained nicely.

This has exactly what you're looking for:

The basics as I understand them in DirectX 9 are this: You need to set up a shader with a texture sampler (tells the graphics card how to pick/generate pixels from the texture). You then set the texture in the shader in your C++ program, and the sampler figures out how to color the pixels from the texture you fed it and your pixel shader code. I don't know if it's exactly the same for Direct3D 11, but something tells me the HLSL interaction part should be similar.

- Steve.