Search Amazon.com:
Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«45 »
  • Post
  • Reply
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.

Adbot
ADBOT LOVES YOU

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.

Presto
Nov 22, 2002


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.

pseudorandom name
May 6, 2007
INSOLENT


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

Presto
Nov 22, 2002


pseudorandom name posted:

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

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?

Presto
Nov 22, 2002


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 Feb 28, 2012 around 18:28

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.

Presto
Nov 22, 2002


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 Mar 1, 2012 around 23:06

Presto
Nov 22, 2002


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.

Spite
Jul 27, 2001

Small chance of that...


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

shodanjr_gr
Nov 20, 2007
Goon from Greece



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...).

shodanjr_gr
Nov 20, 2007
Goon from Greece



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?

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 Mar 20, 2012 around 13:51

shodanjr_gr
Nov 20, 2007
Goon from Greece



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....

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.

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 Mar 20, 2012 around 20:50

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.

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?

Unormal
Nov 16, 2004

Mod sass? This evening?! But the cakes aren't ready! THE CAKES!

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.

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.

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.

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).

shodanjr_gr
Nov 20, 2007
Goon from Greece



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!".

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.

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.

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.

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.

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?

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 Apr 6, 2012 around 15:57

Zilla32167
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?

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.

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.

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 Apr 24, 2012 around 23:42

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.

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.









DefiniteIntegral
Jul 13, 2001



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

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/pap...rker10OptiX.pdf

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/pap...rker10OptiX.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 Apr 27, 2012 around 16:12

Adbot
ADBOT LOVES YOU

Illusive Fuck Man
Jul 5, 2004

i bet your thinking about star wars


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.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«45 »