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)

«‹›74 »

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

You have to use VAOs if you aren't using a profile that supports legacy stuff. I haven't tested whether they give a performance benefit, but I would assume so since they're basically removing the old way of doing it.

# ? Feb 25, 2012 08:53

Adbot: ADBOT LOVES YOU

# ? Apr 23, 2024 07:04

Spite: Jul 27, 2001; Small chance of that...

Contero posted:

In gl 3.1+, do vertex array objects give a performance benefit over manually binding VBOs? What is the advantage of using them?

You have to use VAO in GL 3+.

In legacy contexts they should ideally provide a performance enhancement. However, most drivers don't implement them so that there's a noticable difference.

# ? Feb 26, 2012 06:51

Presto: Nov 22, 2002; Keep calm and Harry on.

OK, this one is kicking my rear end.

At work we have an Open Inventor app we've had going back to the days when we used SGI hardware. I have to point out that we have always compiled our software into static archives and linked our executables against them. As a science project I'm trying to get them to link against .so versions of the same libraries.

Now this app works perfectly fine linking against the static libraries. But when I link it against the shared objects, it crashes about 40 levels deep in the Inventor SoXt::mainLoop(). I've tracked the reason for the crash to a NULL returned by glGetString(GL_VENDOR). Google tells me that this is usually caused by not having a valid GL context at the point of the call. But I *think* there is one in this case, or at least, glXGetCurrent() returns something that appears reasonable; and as I said, it works fine when using the static libraries.

So what's going on here? In both cases the code is identical, and it's using the same Inventor and GL libraries, but one way crashes and the other doesn't.

# ? Feb 27, 2012 05:52

pseudorandom name: May 6, 2007

Does glGetError() return anything useful after the glGetString() returns 0?

# ? Feb 27, 2012 07:07

Presto: Nov 22, 2002; Keep calm and Harry on.

pseudorandom name posted:

Does glGetError() return anything useful after the glGetString() returns 0?

Nope. glGetError() returns 0.

# ? Feb 27, 2012 22:13

Spite: Jul 27, 2001; Small chance of that...

Firstly, what has changed since it used to work?
What OS, HW, driver, etc?

Do other gl calls work?
Can you clear the screen to a color?
Can you draw a simple quad?
Do other glGet* calls work?
Can you call glGetString(GL_RENDERER) or GL_VERSION or GL_EXTENSIONS?

Also it occurs to me that you may not be creating the context correctly in the dynamically linked case. How is the context created? Are you using glXGetProcAddress, etc? Does that return valid function pointers?

# ? Feb 28, 2012 07:19

Presto: Nov 22, 2002; Keep calm and Harry on.

Spite posted:

Firstly, what has changed since it used to work?
What OS, HW, driver, etc?

Linux (Centos 5.something), Quadro NVS 290, just tried updating the nvidia driver to 290.10.

Nothing has changed. The only difference is linking .so versions of our libraries instead of the .a versions.

quote:

Do other gl calls work?
Can you clear the screen to a color?
Can you draw a simple quad?
Do other glGet* calls work?

I should point out that I have no idea how to do any of this. This app was written back in the Bronze Age. The big chunk of the display is an SoXtRenderArea. If I comment out the show() call for that object, the app no longer crashes; but then of course all I get is a black window.

glGetCurrentContext() works.

quote:

Can you call glGetString(GL_RENDERER) or GL_VERSION or GL_EXTENSIONS?

They all return NULL in the .so link. They all return valid strings in the .a link.

quote:

Also it occurs to me that you may not be creating the context correctly in the dynamically linked case. How is the context created? Are you using glXGetProcAddress, etc? Does that return valid function pointers?

I don't know what any of this means either, sorry

The context is created at the point where the show() method is called on the SoXtRenderArea. Before that point, glGetCurrentContext() returns null. After that it returns what looks like a valid pointer. This behavior is the same for both the crashing and non-crashing cases.

EDIT:

I removed all the children from the render area and replaced it all with a single SoCube object. It still crashes.

Presto fucked around with this message at 19:28 on Feb 28, 2012

# ? Feb 28, 2012 17:59

Spite: Jul 27, 2001; Small chance of that...

Sounds like you don't have a context. I'm not sure why that would occur and I don't have much experience with xwin.

Try calling glXGetProcAddress and seeing if it returns valid pointers. Where does the code create your context and how does it do so? Look for glCreateContext or glXCreateContext.

# ? Mar 1, 2012 07:46

Presto: Nov 22, 2002; Keep calm and Harry on.

Spite posted:

Sounds like you don't have a context. I'm not sure why that would occur and I don't have much experience with xwin.

Try calling glXGetProcAddress and seeing if it returns valid pointers. Where does the code create your context and how does it do so? Look for glCreateContext or glXCreateContext.

glXGetProcAddress("glGetString") returns a pointer to something.

The context is created in the Open Inventor code. I've put the glGetString call at that point, immediately after the context is created and made current, and it still returns NULL. I also found out that glGetIntegerv also doesn't work properly in the shared link case. For instance glGetIntegerv(GL_MAX_LIGHTS) returns a big negative number (something like -272716322) instead of the 8 it returns when it works.

It's almost like some static memory in libGL.so isn't being initialized or something. I've also run the whole thing in valgrind and Insure++ and didn't turn up any smoking guns.

Edit:
What the poo poo? If I call the function through the pointer returned by glXGetProcAddress it works.

Presto fucked around with this message at 00:06 on Mar 2, 2012

# ? Mar 1, 2012 23:39

Presto: Nov 22, 2002; Keep calm and Harry on.

Got the fucker.

In the static link case, glXGetProcAddress("glGetString") and the address of the bare glGetString symbol returned the same pointer, but in the shared object care they didn't. I added a '-y glGetString' option to the link command, and it turned out that one of our local libraries requires OSMesa, and libOSMesa.so also defines a bunch of gl calls, and the symbols were being linked from there instead of from libGL.

I moved the OSMesa library to the end of the link line and it's all good now. Thanks for the suggestions.

# ? Mar 2, 2012 01:43

Spite: Jul 27, 2001; Small chance of that...

That makes sense, the Mesa lib has its own GL implementation. Fun stuff.

# ? Mar 2, 2012 01:51

shodanjr_gr: Nov 20, 2007

I got a question about GLSL Tesselation Shaders.

I got some geometry that I'm rendering either as GL_Quads (through a vertex shader) or GL_PATCHES (through a vertex->tess control->tess eval shader chain). The VBO is exactly the same (same vertex definitions and indices).

When I look at the wireframe of the GL_QUADS version of the geometry, it shows, as expected, quads.

When I look at the wireframe of the GL_PATCHES version however, each quad is subdivided into two triangles. My tesselation control shader has layout(vertices=4) out, set at the top and my tesselation evaluation shader is set to layout(quads) in. Is there some way to work around this issue or am I stuck with looking at my quads with a line in the middle (I'm asking cause I want to make figures for a paper I'm writing and having to explain that "I swear I'm issuing 4-vertex patches to teh GPU instead of two triangles" might not jive very well...).

# ? Mar 11, 2012 18:46

shodanjr_gr: Nov 20, 2007

Are const arrays inside shader code supposed to be blatantly slow?

I have a tessellation control shader that needs to index the vertices of the input primitive based on the invocation ID (so gl_InvocationID == 0 means that the TCS operates on the edge of gl_in[0] and gl_in[1], etc).

Initially, my code had an if-statement (which I would assume GPUs don't like that much when it diverges inside the same execution unit) to make this determination. I figured that I could flatten the vertex indices out into a single const int[8] and index them based on the invocation ID (so I could say indices[glInvocationID * 2] and indices[glInvocationID * 2 + 1] and get the stuff that I need).

However, doing this seems to hit me with a 66% performance drop when compared to using if-statements! Would passing the index array as a uniform yield a performance benefit?

# ? Mar 19, 2012 22:55

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

shodanjr_gr posted:

Are const arrays inside shader code supposed to be blatantly slow?

I have a tessellation control shader that needs to index the vertices of the input primitive based on the invocation ID (so gl_InvocationID == 0 means that the TCS operates on the edge of gl_in[0] and gl_in[1], etc).

Initially, my code had an if-statement (which I would assume GPUs don't like that much when it diverges inside the same execution unit) to make this determination. I figured that I could flatten the vertex indices out into a single const int[8] and index them based on the invocation ID (so I could say indices[glInvocationID * 2] and indices[glInvocationID * 2 + 1] and get the stuff that I need).

However, doing this seems to hit me with a 66% performance drop when compared to using if-statements! Would passing the index array as a uniform yield a performance benefit?

What graphics card are you seeing this with? Depending on the hardware, the problem probably isn't the const array, but the fact that you are using dynamic indexing into the array. Some GPUs don't really support base+offset indexing, instead mimicing it using registers. Unfortunately, if you index the arrays dynamically, this requires all the accesses to be expanded (either by unrolling loops, or expanding into a giant nasty set of branches). So you could actually be gaining MORE branches, instead of eliminating them.

Why do you need to index the edges like you are doing? Your best bet would be to structure the input to your shader so that it doesn't need to branch at all, even if that means just adding extra interpolants. I'm not sure if that would work for you here, though.

e: There's no way to see intermediate assembly with GLSL, right? For DirectX, you could use FXC to dump the shader which might show you if that were happening at the high-level level (though not if it's being introduced at the machine-code translation stage).

Hubis fucked around with this message at 14:51 on Mar 20, 2012

# ? Mar 20, 2012 11:54

shodanjr_gr: Nov 20, 2007

Hubis posted:

What graphics card are you seeing this with? Depending on the hardware, the problem probably isn't the const array, but the fact that you are using dynamic indexing into the array. Some GPUs don't really support base+offset indexing, instead mimicing it using registers. Unfortunately, if you index the arrays dynamically, this requires all the accesses to be expanded (either by unrolling loops, or expanding into a giant nasty set of branches). So you could actually be gaining MORE branches, instead of eliminating them.

This is on a Quadro 5000.

quote:

Why do you need to index the edges like you are doing? Your best bet would be to structure the input to your shader so that it doesn't need to branch at all, even if that means just adding extra interpolants. I'm not sure if that would work for you here, though.

This is happening inside a tessellation control shader. For each vertex of the input primitive, you get one invocation of the TCS. All invocations of the TCS for each primitive have access to a gl_in[numVertices] array of structs that contains the per-vertex attributes of the primitive as they are passed by the vertex shader. I want each invocation of the TCS to do stuff for each EDGE of the input primitive and thusly i need to index the vertex positions that define the edge from gl_in. Since the per-edge operations are kind of expensive, I can not have each invocation of the TCS do the operations for ALL edges unfortunately (I am taking this approach for other, cheaper per-primitive operations).

quote:

e: There's no way to see intermediate assembly with GLSL, right? For DirectX, you could use FXC to dump the shader which might show you if that were happening at the high-level level (though not if it's being introduced at the machine-code translation stage).

I believe there are utilities released by AMD/NVIDIA that will compile GLSL down to the machine-level assembly for you....

# ? Mar 20, 2012 15:16

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

AMD has ShaderAnalyzer, which shows you the assembly dump and cycles for any card they make.

NVIDIA, I'm not sure, I've heard there's a way to make CGC do something like that.

# ? Mar 20, 2012 15:23

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

shodanjr_gr posted:

This is on a Quadro 5000.

This is happening inside a tessellation control shader. For each vertex of the input primitive, you get one invocation of the TCS. All invocations of the TCS for each primitive have access to a gl_in[numVertices] array of structs that contains the per-vertex attributes of the primitive as they are passed by the vertex shader. I want each invocation of the TCS to do stuff for each EDGE of the input primitive and thusly i need to index the vertex positions that define the edge from gl_in. Since the per-edge operations are kind of expensive, I can not have each invocation of the TCS do the operations for ALL edges unfortunately (I am taking this approach for other, cheaper per-primitive operations).

I believe there are utilities released by AMD/NVIDIA that will compile GLSL down to the machine-level assembly for you....

E: Nevermind, thanks!

Hubis fucked around with this message at 21:50 on Mar 20, 2012

# ? Mar 20, 2012 20:44

Spite: Jul 27, 2001; Small chance of that...

Also are you sure the Quadro actually implements the Tesselation Shaders in hardware? Sometimes they don't have full implementations. Or they fall back to software for stupid reasons.

# ? Mar 21, 2012 01:59

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Remind me what the Quadro and Fire are better at doing than the consumer cards again?

# ? Mar 21, 2012 15:49

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

OneEightHundred posted:

Remind me what the Quadro and Fire are better at doing than the consumer cards again?

Increasing profit margins?

They used to be better at line and other base primitive drawing, for wireframe cad application; not sure if that's true anymore.

# ? Mar 21, 2012 15:52

Paniolo: Oct 9, 2007; Heads will roll.

OneEightHundred posted:

Remind me what the Quadro and Fire are better at doing than the consumer cards again?

OpenGL 1.0, mostly. And antialiased line rendering.

# ? Mar 21, 2012 16:01

Zhentar: Sep 28, 2003; Brilliant Master Genius

Unormal posted:

They used to be better at line and other base primitive drawing, for wireframe cad application; not sure if that's true anymore.

I think they generally are. It's all in the drivers though, with similar if not identical hardware behind them (possibly with huge gobs of RAM added).

Basically, you're paying for a support agreement, and driver optimizations for non-consumer tasks. The payment just gets tacked onto the hardware purchase instead a driver subscription fee or however else it might be done.

# ? Mar 21, 2012 16:32

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

OneEightHundred posted:

Remind me what the Quadro and Fire are better at doing than the consumer cards again?

Higher quality bins of chips, much better handling of geometry-heavy scenes (not just lots of triangles, but lots of small triangles), and the driver and technical support commensurate with a workstation-level GPU (not just perf, but some weird/edge-case features that don't matter much for consumers but might for a professional system).

# ? Mar 21, 2012 16:52

shodanjr_gr: Nov 20, 2007

Hubis posted:

Higher quality bins of chips, much better handling of geometry-heavy scenes (not just lots of triangles, but lots of small triangles), and the driver and technical support commensurate with a workstation-level GPU (not just perf, but some weird/edge-case features that don't matter much for consumers but might for a professional system).

That's very true. I work at a research University and I've been able to ping both NVIDIA and AMD engineers regarding weird behaviors/driver issues/optimizations with their professional level cards. I assume that if you are buying geforce/radeon you can't really call em up and say "Why do the textures in Rage look like crap? send me a custom driver that fixes this!".

# ? Mar 21, 2012 23:25

Zhentar: Sep 28, 2003; Brilliant Master Genius

Pretty much. Margins on the consumer products are enough to pay for someone to recite a script to you, and not much more. It's going to cost a lot more if you want to talk to someone who even understands what you're saying, much less getting engineer time.

# ? Mar 21, 2012 23:46

HauntedRobot: Jun 22, 2002; an excellent mod
a simple map to my heart
now give me tilt shift

I have a world defined as a bunch of polygon meshes and I'm using VBOs at the moment to render them. Currently the setup is

code:

        glBindBufferARB  ( GL_ARRAY_BUFFER_ARB, (*mi).vbo );
        glVertexPointer  ( 3, GL_FLOAT, 32, (char *)NULL + 0 );
        glTexCoordPointer( 2, GL_FLOAT, 32, (char *)NULL + 12 );
        glColorPointer   ( 3, GL_FLOAT, 32, (char *)NULL + 20 );

and then I go through with DrawArrays... this gives me 3d textured geometry with really basic vertex lighting. (I know this is way behind the curve but I've been out of the loop so I'm relearning from the naive glBegin, glEnd stuff forward here, and diving right in to shaders was too much to take in at once)

The thing with that is that the lighting is baked in and static, and I want to move on to dynamic lighting. Is there a way to accomplish that through loading the vbo -> *doing something where dynamic light values get added* -> DrawArrays? Or have I hit the limitation of rendering that way there?

If so, where would I go next from there? Is the next thing to do it all in shaders or is there some kind of intermediate step? Something with a deferred lighting pass maybe? I've learnt a ton of stuff doing things this way that I'd sort of handwaved over before.

# ? Mar 26, 2012 11:37

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

HauntedRobot posted:

I have a world defined as a bunch of polygon meshes and I'm using VBOs at the moment to render them. Currently the setup is
code:
        glBindBufferARB  ( GL_ARRAY_BUFFER_ARB, (*mi).vbo );
        glVertexPointer  ( 3, GL_FLOAT, 32, (char *)NULL + 0 );
        glTexCoordPointer( 2, GL_FLOAT, 32, (char *)NULL + 12 );
        glColorPointer   ( 3, GL_FLOAT, 32, (char *)NULL + 20 );
and then I go through with DrawArrays... this gives me 3d textured geometry with really basic vertex lighting. (I know this is way behind the curve but I've been out of the loop so I'm relearning from the naive glBegin, glEnd stuff forward here, and diving right in to shaders was too much to take in at once)

The thing with that is that the lighting is baked in and static, and I want to move on to dynamic lighting. Is there a way to accomplish that through loading the vbo -> *doing something where dynamic light values get added* -> DrawArrays? Or have I hit the limitation of rendering that way there?

If so, where would I go next from there? Is the next thing to do it all in shaders or is there some kind of intermediate step? Something with a deferred lighting pass maybe? I've learnt a ton of stuff doing things this way that I'd sort of handwaved over before.

If you want to still use VBOs with dynamic lighting instead of shaders, you could put the color values into another VBO and modify them each frame:

code:

// Prepare the color VBO each frame:
glBindBufferARB(GL_ARRAY_BUFFER_ARB, (*mi).colorVbo);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, vertexCount * sizeof(GLfloat) * 3, NULL, GL_DYNAMIC_DRAW_ARB);
glBufferSubDataARB(GL_ARRAY_BUFFER_ARB, 0, vertexCount * sizeof(GLfloat) * 3, (GLvoid*)colorData);

// Ready the color VBO for drawing:
glBindBufferARB(GL_ARRAY_BUFFER_ARB, (*mi).colorVbo);
glColorPointer(3, GL_FLOAT, 12, NULL);

You'll have to remove the color data from your interleaved vertex information of course.

# ? Mar 26, 2012 14:44

HauntedRobot: Jun 22, 2002; an excellent mod
a simple map to my heart
now give me tilt shift

HiriseSoftware posted:

If you want to still use VBOs with dynamic lighting instead of shaders, you could put the color values into another VBO and modify them each frame:

You'll have to remove the color data from your interleaved vertex information of course.

Oh, that's a pretty good idea. Disentangling them from the other vertex info isn't ideal, but I already have a similar thing in the loader for generating a simplified collision mesh for the physics.

# ? Mar 26, 2012 16:09

FlyingDodo: Jan 22, 2005; Not Extinct

I know that binding things in opengl is fairly expensive thing to do and you should try to minimise the amount of times it is called per frame. If something such as a buffer, texture, shader etc is already bound then how much is the performance hit if it is bound again? Is there a way to check what is currently bound, and if so how expensive is that compared to blindly rebinding something?

# ? Apr 6, 2012 16:37

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

FlyingDodo posted:

I know that binding things in opengl is fairly expensive thing to do and you should try to minimise the amount of times it is called per frame. If something such as a buffer, texture, shader etc is already bound then how much is the performance hit if it is bound again? Is there a way to check what is currently bound, and if so how expensive is that compared to blindly rebinding something?

You can use the glGet* functions to get the currently bound object for a particular type, for example:

code:

// Get the buffer ID currently bound using glBindBuffer(GL_ARRAY_BUFFER, id);
GLint id;
glGetIntegerv(GL_ARRAY_BUFFER_BINDING, &id);

But that can be an expensive operation in itself. The best way to deal with the bindings (and other OpenGL states) is to create an array of states of your own and keep track of bindings there. That way, you have a function that first checks what your array thinks is the currently bound ID, and if the ID you're trying to bind isn't the same, call the GL function and set your state array accordingly. If the ID matches, then leave it alone. Make sure for textures that you keep track of the binding per texture unit.

Edit: Make sure you do an initial "OpenGL state reset" to get the GL state machine to match up to your initial state array values.

HiriseSoftware fucked around with this message at 16:57 on Apr 6, 2012

# ? Apr 6, 2012 16:54

CommunityEdition: May 1, 2009

How do OpenGL versions map to DirectX versions in terms of hardware requirements? For example, if I can target DirectX 9.0c, what OpenGL versions do I have to work with?

# ? Apr 22, 2012 20:46

Scaevolus: Apr 16, 2007

Zilla32167 posted:

How do OpenGL versions map to DirectX versions in terms of hardware requirements? For example, if I can target DirectX 9.0c, what OpenGL versions do I have to work with?

Probably OpenGL 2.0.

DirectX 9.0c came out in August 2004, and OpenGL 2.0 came out in September 2004. Cards that came out late 2004 and early 2005 might have support for one but not the other, though.

# ? Apr 22, 2012 21:47

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

It depends what features you're looking for, a lot of the time some chunk of them will make it in early and others later. Geometry shaders are a 3.2 standard feature but were an extension before that for example. 9.0c should work with pretty much anything that has GLSL support since gl_FrontFacing has existed since day one and the rest of the SM3.0 features are compiler-level.

# ? Apr 23, 2012 20:45

a slime: Apr 11, 2005

I have a bunch of concave contours whose vertices rest on the surface of a sphere. I want to draw them, filled with color, on that sphere. I was thinking that I could take points from a tessellation of the sphere, calculate the Delaunay triangulation over all of these points and the vertices of my contours, and render that. Is there a simpler way to do this?

Sorry if this is a silly question, I haven't worked much in 3D

edit: I guess I also need to determine which of the points from the tessellation are inside which contours (for coloring purposes), but it seems like I could do some spherical analogue of a point in polygon test?

a slime fucked around with this message at 00:42 on Apr 25, 2012

# ? Apr 25, 2012 00:35

DefiniteIntegral: Jul 13, 2001

Getting away from DirectX/OpenGL for a moment, does anyone have experience with Nvidia's Optix realtime raycasting?

I have used it to create simple tests and it seemed to perform OK at low resolution, eg 1024x768 on some average hardware (GTX 560 Ti & Intel i7 Bloomfield 2.9 Ghz).

But I wonder how it performs in real world applications? Youtube has dozens of tech demo's but almost nothing in the way of real applications using the library.

It would be nice to know I am not wasting my time before I invest heaps of it coding the CUDA programs and a scene graph and managing GPU paging and all the other related parts. All that is necessary as Optix is just a raycasting library only, it is not a complete scene management solution like Nvidia's SceniX which I do not wish to use for various reasons.

Any experiences people can share about Optix would be helpful.

# ? Apr 27, 2012 02:22

That Turkey Story: Mar 30, 2003

Stragen posted:

Getting away from DirectX/OpenGL for a moment, does anyone have experience with Nvidia's Optix realtime raycasting?

I have used it to create simple tests and it seemed to perform OK at low resolution, eg 1024x768 on some average hardware (GTX 560 Ti & Intel i7 Bloomfield 2.9 Ghz).

But I wonder how it performs in real world applications? Youtube has dozens of tech demo's but almost nothing in the way of real applications using the library.

It would be nice to know I am not wasting my time before I invest heaps of it coding the CUDA programs and a scene graph and managing GPU paging and all the other related parts. All that is necessary as Optix is just a raycasting library only, it is not a complete scene management solution like Nvidia's SceniX which I do not wish to use for various reasons.

Any experiences people can share about Optix would be helpful.

I don't know anything about it, but I'm going to be that guy that points out smugly that ray casting != ray tracing.

:smug:

# ? Apr 27, 2012 04:10

DefiniteIntegral: Jul 13, 2001

Heh yeah, I always get them the wrong way around. I meant ray tracing.

# ? Apr 27, 2012 06:07

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

Stragen posted:

Getting away from DirectX/OpenGL for a moment, does anyone have experience with Nvidia's Optix realtime raycasting?

I have used it to create simple tests and it seemed to perform OK at low resolution, eg 1024x768 on some average hardware (GTX 560 Ti & Intel i7 Bloomfield 2.9 Ghz).

But I wonder how it performs in real world applications? Youtube has dozens of tech demo's but almost nothing in the way of real applications using the library.

It would be nice to know I am not wasting my time before I invest heaps of it coding the CUDA programs and a scene graph and managing GPU paging and all the other related parts. All that is necessary as Optix is just a raycasting library only, it is not a complete scene management solution like Nvidia's SceniX which I do not wish to use for various reasons.

Any experiences people can share about Optix would be helpful.

It depends a lot on your ultimate use-case. How dynamic is your scene? What's your scene complexity? What light transport/shading technique are you using -- Primary + Shadow, or full path tracing? For a 560 Ti, I wouldn't expect to be ray-tracing Crysis or anything. Since performance depends a lot on acceleration structures (which have to be updated when the scene changes) which structures you use for which objects in the hierarchy and how often they need to change will end up impacting your performance a lot.

There's more information here, although it's obviously based on somewhat older hardware: http://graphics.cs.williams.edu/papers/OptiXSIGGRAPH10/Parker10OptiX.pdf

# ? Apr 27, 2012 16:16

DefiniteIntegral: Jul 13, 2001

Hubis posted:

It depends a lot on your ultimate use-case. How dynamic is your scene? What's your scene complexity? What light transport/shading technique are you using -- Primary + Shadow, or full path tracing? For a 560 Ti, I wouldn't expect to be ray-tracing Crysis or anything. Since performance depends a lot on acceleration structures (which have to be updated when the scene changes) which structures you use for which objects in the hierarchy and how often they need to change will end up impacting your performance a lot.

There's more information here, although it's obviously based on somewhat older hardware: http://graphics.cs.williams.edu/papers/OptiXSIGGRAPH10/Parker10OptiX.pdf

I'd like to use static, semi-dynamic and full-dynamic geometry using Sbvh, Bvh and Lbvh accel structures respectively. I only plan to use simple Whitted raytracing, so just usual radiance + shadow casts and probably some limited use of reflection/refraction.

My plan is to divide the scene into sections which will contain a static hull and be connected via portals. So attached to the Optix root node would be a series of Selector nodes which only continue traversing if the section ID stored in the ray payload & selector node match. Portals would just alter the payload section ID and re-cast from root. I am hoping that keeping the scene divided into small sections will make calculating Bvh and Lbvh fast enough to be done in real-time, but haven't tested it yet. Also this should make paging fairly easy.

I am just worried that checking N selector nodes each time casting from a portal might lower the framerate, not to mention the recursive casting required for portals. If Optix 2.5 GPU-side calculation of Lbvh is fast enough, I am wondering if I would get a better framerate just using a single volume hierarchy for the entire scene instead of sections & portals. That is to say, 3 volume hierarchies, one for each geometry type. I guess it will depend a lot how many sections there are in the scene and positioning of the portals themselves.

I have only tested Optix using Bvh accel on a very small fully dynamic scene, so I am not certain how well portals would work.

DefiniteIntegral fucked around with this message at 17:12 on Apr 27, 2012

# ? Apr 27, 2012 17:07

Adbot: ADBOT LOVES YOU

# ? Apr 23, 2024 07:04

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

I need to implement shadow mapping for the last part of a class project, and I totally understand it except for one thing. How do you create the frustum / projection+view matrices for the light source so that it covers everything in the camera's frustum? Everything I read seems to just skip over this.

# ? May 3, 2012 16:10

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)

«‹›74 »