3D graphics questions that do not deserve their own thread (OpenGL / Dx10)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 3D graphics questions that do not deserve their own thread (OpenGL / Dx10)

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

This shouldn't be an issue at all. Reinstall your device driver.

# ¿ Dec 11, 2008 17:49

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 21:52

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

Mithaldu posted:

Wavefront .obj is what you're looking for. With a tiny bit of understanding of what the abbreviations mean it is even human-readable for smaller models.

obj is like the bmp of 3d. dead simple to read / write.

# ¿ Dec 15, 2008 01:50

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

dimebag dinkman posted:

I'll try to clarify what I mean:

I want the one on the left. (Yes, really).

Sample the buffer and when you call glTexParameter, use gl_Nearest?

# ¿ Jan 12, 2009 00:18

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

zzz posted:

Plus, you need to call glEnable(GL_TEXTURE_2D) separately for each texture unit you want to use (after glActiveTexture)

I don't think thats right, you should only need to turn on the texture state once.

# ¿ Apr 1, 2009 09:44

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

I imagine most of the changes in 3.0 have to do with GLSL rather than the core API. ex, implementation of geometry shaders.

The only real change left to the core API is to remove the fixed pipeline functionality. That's never going to happen though, since the CAD developers would poo poo bricks.

# ¿ Jun 6, 2009 04:18

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

Dijkstracula posted:

Great, this is exactly what I wanted to know. It sounds like until the Red Book is updated for 3.2, ES is the way to go.

I wish everybody else would follow that example. I fear NeHe won't be going away any time soon. It would be pretty cool if somebody did a GLES on top of the Windows OpenGL libs.

# ¿ Jul 3, 2009 03:32

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 21:52

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

Flashdance posted:

I never took linear algebra and so, while I'm teaching myself the relevant parts now, I'm having trouble with a ray-triangle intersection test. I'm also not that great at OpenGL yet, but it's coming along. The task is simple enough: given a click on the screen, and a ray using the x- and y-coordinates of the click cast from the near plane to the far plane, find the closest triangle intersected and the point of intersection.

Here's how I'm going about it currently:
I use gluUnProject with mouse_x and mouse_y at the z-axis points -1.f and 1.f to get the model coordinates of the click at each plane, which creates my ray's origin and destination. Then I use the following code to calculate the intersection point.
code:
        // editor's note: tr is a triangle object containing 
        // (x, y, z) coords as well as its normal vector

	// First, calculate the distance of the plane from the origin.
	
	float distance = distance_3d(tr->normal_vector->x, tr->normal_vector->y, 
			 	     tr->normal_vector->z, 0.f, 0.f, 0.f);

	// Next, using calculate the value of t for the line's intersection
        // with the triangle's plane.

	float t1 = 	(ray_origin[0] * tr->normal_vector->x) + 
			(ray_origin[1] * tr->normal_vector->y) +
			(ray_origin[2] * tr->normal_vector->z) +
			distance;

	float t2 =	(tr->normal_vector->x * (ray_destination[0] - ray_origin[0])) + 
			(tr->normal_vector->y * (ray_destination[1] - ray_origin[1])) + 
			(tr->normal_vector->z * (ray_destination[2] - ray_origin[2]));

	float t = -(t1 / t2);

	// Using the value of t above, calculate the coordinates of the point of
	// intersection with the plane.

	intersection_point[0] = ray_origin[0] + ((ray_destination[0] - ray_origin[0]) * t);
	intersection_point[1] = ray_origin[1] + ((ray_destination[1] - ray_origin[1]) * t);
	intersection_point[2] = ray_origin[2] + ((ray_destination[2] - ray_origin[2]) * t);
The math sort of works, and my intersection calculations aren't wildly off, but the points end up being too high, e.g. they're maybe 30 pixels above my actual click location. Accuracy improves as I zoom in, but something isn't quite right. My guess is that I'm using gluUnProject improperly, but I'm not sure. Does anyone see anything wildly off?

Also, a second question: if I use OpenGL to pick the triangles nearest the click and sort for the closest triangle to the click by z-value, could I guarantee that the click passes through this triangle? That would save some work if I could know that for sure.

Why not just use Picking if you are trying to find what polygon your mouse is hovering over? Basically, it's a Pre-Pass. Draw just the shapes you are going to use, no lighting, no texturing, just a different color for each object, find the color of the pixel your mouse is hovering over, then redraw the scene properly.

# ¿ Sep 11, 2010 23:21

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 3D graphics questions that do not deserve their own thread (OpenGL / Dx10)