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)

Entheogen: Aug 30, 2004; by Fragmaster

I looked through this forum and could not find a graphics specific thread dedicated to questions. So let us use this one to ask any sort of 3D graphics questions that we might have.

To start it off, I would like to ask how would i go about querying GPU memory in OpenGL? I would also like to measure sizes of display lists once i generate them. The reason why I want to do this, is because it seems display lists, when compiled, do not cache repeated vertices, the way vertex arrays / VBO's can. However, they do seem to run faster with large geometric objects than VBOs.

Is there also a way to minimize the size of display list that generates same geometric object, by somehow not repeating same vertices, the way you can do using vertex arrays?

Also another question, does anybody have any success using Geometry shader in OGL? I believe NVidia made some extension for them, but I am not quite sure how to use them. Does it still use GLSL?

vvvvvvvvvvvvvvv
no, man, im cool, i got them working. It wasn't hard after getting my program to work with vertex arrays. If you have any interesting tricks to share about using them, then I would like to see it. Thanks anyway.

Entheogen fucked around with this message at 22:22 on Jul 8, 2008

# ¿ Jul 8, 2008 22:11

Adbot: ADBOT LOVES YOU

# ¿ Apr 25, 2024 09:49

Entheogen: Aug 30, 2004; by Fragmaster

Thug Bonnet posted:

I got hammered at work and I didn't get a chance to email you the VBO examples yet. Do you still need them? I thought I saw in the gamedev thread that you had got it working.

My question: Is there any reason to ever use immediate mode in OpenGL for anything but toy programs?

I think that if you wanted to make a program that was not real-time but rendered complex images to files, then you could use immediate mode because speed is not much of a concern. I think if you used OpenGL that way then it would still be faster than using software renderer. ALthough you would be moving poo poo-ton of data between CPU and GPU.

# ¿ Jul 15, 2008 20:47

Entheogen: Aug 30, 2004; by Fragmaster

is there a way to compile display list, but store it as perhaps a string in client's memory and then move it at your own discretion to GPU when you actually need to draw it?

What I would like to do is generate a lot of huge display lists that in no way would fit at once in my GPU memory, but I only need to render one of them at a time.

# ¿ Jul 24, 2008 01:44

Entheogen: Aug 30, 2004; by Fragmaster

StickGuy posted:

What are these huge display lists going to be used for?

Its for the same project that I posted screen shots on page 6 of post your stuff thread. It is for volume visualization. Right now I generate a display list of subdivided volume and draw that. I would like to have an array of volumes that the user can switch between, but only one volume will ever be needed to be displayed at one time. I think that by pre-generating all display lists and then just loading and offloading them from video card I can cut down on the time it takes to switch from one volume to the other.

# ¿ Jul 24, 2008 09:22

Entheogen: Aug 30, 2004; by Fragmaster

StickGuy posted:

I'm still puzzled by your thousands of triangles approach. In any case, I don't know if you'd really gain a lot of speed by caching the display lists in main memory over recompiling them as necessary.

It works pretty well for me so far. I just normalize scalar field to be between 0 and 1 and use that as alpha values for vertices I create. I use some simple normal distribution and linear shaders to tweak how they come out too. I also made a simple recursive subdivision function that divides cube into 8 subcubes if it detects that it is not uniform. That greatly boosted my FPS and memory requirement on the GPU.

I will try raycasting next, but that looks a lot harder than what I am doing now. What would you suggest other than raycasting that I could also give a try?

Entheogen fucked around with this message at 09:45 on Jul 24, 2008

# ¿ Jul 24, 2008 09:32

Entheogen: Aug 30, 2004; by Fragmaster

StickGuy posted:

I've put together a demo program illustrating the slice-based technique I was telling you about in the other threads. It's not the best approach and there's a number of ways to improve it, but it doesn't require drawing thousands and thousands of triangles. You'll need GLUT, GLEW and your favorite C++ compiler to get it to work.

So it doesn't draw view oriented quads. They remain constant in their position, but the 3d texture coordinates is what changes based on view?

How exactly does 3d texturing work. If I define 3d texture for a flat polygon, then that polygon sort of slices through that 3d texture and gets a 2d slice of it and maps it on polygon? Is that kind of how this works?

You do some matrix and vector calculations in client side. Do you think there is an easy way to make that happen in vertex shader? that is compute 3d tex coordinates there? Could I just compute eye vector and use that to generate tex coords?

Also is it possible to talk to you on AIM or ICQ?

Shazzner posted:

When is OpenGL 3.0 going to be released and will it be the next big thing?

Probably not. As far as I understand all of the new cool technologies like geometry shaders are already supported in OpenGL via extensions. OpenGL3.0 will just make them standard, which I guess will make using those new technologies easier for everybody. Also game makers will probably stick with DX10.

Entheogen fucked around with this message at 15:52 on Jul 27, 2008

# ¿ Jul 27, 2008 15:15

Entheogen: Aug 30, 2004; by Fragmaster

StickGuy posted:

The idea is that the quads are always perpendicular to the eye vector (essentially a billboard). The quads slice through the volume so each pixel on a quad gets a tri-linearly interpolated texture value. The tricky thing about this approach is that you must compute a matrix that maps points on the quads into points in the volume space. Once you have this matrix, you can compute the actual texture coordinates in a shader. I put my AIM name in my profile so we can discuss it more there.

Dear StickGuy, I finally got this working in my own project. I didn't at first because I was stupidly moving my quads, but then I read through your code again and realized you were not rotating them, but just the texture coordinates. I think from now on I can figure out how to make rotation matrix and just send the angles and translation offset to shader and let it construct the inverse rotation/translation matrix and then multiply the tex coordinates.

What is your email? Send it to me over aim, and I will include it in my source code to credit you for your help. I did not copy your code, since I use java, but it definitely helped me out a lot. Thank you so much for your help.

# ¿ Jul 29, 2008 08:30

Entheogen: Aug 30, 2004; by Fragmaster

I have successfully implemented the 3d slicing technique, however it appears to be rather slow. The way I calculate the inverse matrix also doesn't appear to be much of a factor here, as I only do it once, and then send it to vertex shader which actually multiplies it to tex coordinates. I think the limit here is imposed by my cards texture fill rate and the blending that it has to do between all slices. Also there appear to be some artifacts due to slicing. They appear as these lines that criss cross the volume.

I was wondering, however, do you think if I combine this with a technique I was doing earlier could help both the quality and the speed? What I am thinking about, is to generate space filling cubes again, but this time instead of giving them colors I could give them 3d texture coordinates. I am not sure how much faster it could be than what I am doing now, but it could possibly increase the visual quality. I will try this and report back.

Here is the screen shot:

There are 1000 slices here, and I am using my gaussian filter do isolate a certain data range as well as provide false coloring. You can see the artifact lines criss crossing the volume thou.

ok. it seems to be that these artifact lines only appear in gaussian shader, and not linear one. Here is source code for my linear fragment shader:

code:

uniform float scale_factor;
uniform sampler3D tex3D;

void main(void)
{
   float v = texture3D(tex3D, gl_TexCoord[0].stp).r;
   gl_FragColor = vec4( scale_factor,1,1,v*scale_factor);
}

and here is gaussian one:

code:


uniform sampler3D tex3D;

uniform float scale_factor; 
uniform float gauss_a; 
uniform float gauss_b; 
uniform float gauss_c; 

void main(void)
{
   float v = texture3D(tex3D, gl_TexCoord[0].stp).r;
   float exponent = v - gauss_b;
   exponent *= exponent;
   exponent /= -2 *( gauss_c * gauss_c );
   float nv = scale_factor * gauss_a * exp( exponent );
   gl_FragColor = vec4( 1-v, v,1, nv);
}

How could I still use normal distribution function but avoid these artifact lines?

Entheogen fucked around with this message at 08:07 on Jul 30, 2008

# ¿ Jul 30, 2008 07:58

Entheogen: Aug 30, 2004; by Fragmaster

StickGuy posted:

The slicing technique is definitely fill-rate limited. There are some optimizations you can do such as clipping the quads to the data volume, but it's still limited by the number of slices through the data volume itself that you draw. You can experiment with the number of slices that you need to get a reasonable appearance. A reasonable rule of thumb is to have at least one slice pass through each voxel. You can also probably combine it with your previous technique to do some sort of subdivision to produce more partial slices in parts of the volume where things are visible and few or no slices where nothing is visible.

As far as your lines, they look a bit strange, but it's hard to tell what should and shouldn't be there. Can you post a screen shot of the linear shader where the lines are absent for comparison? Also, what are the dimensions of the volume you're visualizing? Are you using a floating point texture?

The volume is 128^3 data set of 4 byte floating point numbers. After reading it from file i normalize it to be between [0,1]. I think I know why the lines are there. Perhaps it is because the inside of some sub volume is a lot more transparent than its contours. The normal distribution function makes the inside look very empty, while the contours are made into glowy lines because they fall in the standard deviation.

Here is picture of results of linear shader at work:

Here is gaussian one at work from same perspective:

in each case there are 128 slices drawn.

I will play around more with fragment shader and some other techniques. Perhaps I could do away with fewer slices by shading each pixel according to what texels are between it and the next slice?

# ¿ Aug 1, 2008 00:50

Entheogen: Aug 30, 2004; by Fragmaster

what is a good OpenGL way to have transcluency for multiple objects? Perhaps I can turn off depth test and set this blend function?

code:

glBlendFunc( GL.GL_SRC_ALPHA, GL.GL_ONE_MINUS_SRC_ALPHA);

I use this and it works somewhat well for many objects, but there are certain artifacts produced. Should I also render from back to front? The problem with that is that I would like to use display lists, and how would I render from back to front while also having rotating camera?

# ¿ Aug 20, 2008 05:45

Entheogen: Aug 30, 2004; by Fragmaster

sex offendin Link posted:

Yes, you usually need to render from back to front for 100% correct blending. There's no easy way around this, you need to depth-sort your transparent objects every frame (if you're worried about polygons within display lists drawing in the wrong order, turning on backface culling will get rid of 99% of that).

I am actually rendering this using custom shaders. For that should i just discard a fragment that is not front facing?

^^^^^^^^^^^^^^^^^^^^ How do I reject by polygon? Am I just missing some simple OpenGL call?

# ¿ Aug 20, 2008 05:49

Adbot: ADBOT LOVES YOU

# ¿ Apr 25, 2024 09:49

Entheogen: Aug 30, 2004; by Fragmaster

Mithaldu posted:

I'm guessing i'm being dumb about something here. These cubes are all flush to each other:

Click here for the full 1271x936 image.

How can i stop the borders there from loving up?

Source code here if anyone wants to look: http://code.google.com/p/dwarvis/source/browse/trunk/livevis/dwarvis.pl
Relevant functions: cbRenderScene ourDrawCube ourInit

turn on GL_BACK culling is one thing that fixed it in my program, but i was also using tansperency.

# ¿ Sep 5, 2008 19:26

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)