|
Mithaldu posted:Disabling the depth buffer is not an option, as the z-culling needs to be kept functional for each z-layer. Sounds like a pretty neat approach though. (Although i'm confused by what you mean with shading work.) It's a dwarf fortress clone, by chance? By shading cost, I meant the cost of doing all the texture lookups, combinations, and copying/blending to the framebuffer. If you're rendering 20 overlapping objects, your GPU is basically doing 20x more work than it has to ("overshading"). Of course, I just remembered that you're doing this in Perl, so it's almost certainly CPU limited OK, so you've got this world-space box enveloping the entire scene, and a camera position (which is either external or possibly internal, if you're zoomed in). You've also got Z-Near and Z-Far, which you say you're clamping to max(1.0f, <nearest point in the scene>) and <furthest point in the scene>, respectively. Do I understand correctly? This seems to be what I'd advise. What I find strange is that the Z-sorting issues get worse the closer you get to the objects. Usually, problems arise when you get further away from the camera, and the distance between overlapping objects becomes smaller than the preceision at that distance (which, in turn, gets better closer to the camera). It almost seems like the scene is doing the opposite of what it should be doing...
|
# ? Oct 25, 2008 20:36 |
|
|
# ? May 15, 2024 04:26 |
|
It's not a clone, it's this: http://code.google.com/p/dwarvis/ If you have the game and a decently complex map you can try it out for yourself with the version that's for download there. And thanks for explaining the shading thing, yeah, OpenGL-wise i have massive amounts of performance left, even on my rather dinky quadro 140 mobile. CPU is the big bottle-neck, which is why i don't bother to cut out invisible stuff. Regarding your understanding of what i'm doing: Exactly, thanks for summarizing it so well. As for your last paragraph: You're suddenly disregarding your previous understanding there. The traditional "it get's worse in the distance" is only true if the clip planes are fixed at, for example, 1 and 1000. However in my case the clip planes are mobile and can wander from "1-150" to "1001-1150", which makes the distance thing irrelevant. My theory on why it happens when zoomed in is that OpenGL has an easier time mapping objects between "1001-1150" than between "1-150", which is why i tried to fix it with zooming by adjusting FoV. On the other hand, it might simply be that the problems are universal, but too small to show up when viewed from a normal distance.
|
# ? Oct 25, 2008 20:53 |
|
Are those "blue things" as well as the rocks spites (as in textures rendered on billboards)? If so, maybe you are rendering them right on top of each other (which would explain the z-fighting)... To improve performance, you can look into lots of things, including geometry instancing (you have TONS of similar looking geometry in those pictures) and various occlusion-culling techniques. Furthermore, you could easily save lots of display-list calls, if you created lists for larger block sizes as well (for instance, instead of just keeping 1x1 block size lists, make some 2x2, 3x3, etc etc lists and call them, based on the size of your areas). I think that the Z accuracy of opengl only depends on the Zfar - Znear value, but i could be wrong...When you create your frame buffer, try using a larger accuracy depth component (32 bits for instance) to rule out Z-issues.
|
# ? Oct 25, 2008 22:02 |
|
shodanjr_gr posted:Are those "blue things" as well as the rocks spites (as in textures rendered on billboards)? If so, maybe you are rendering them right on top of each other (which would explain the z-fighting)... shodanjr_gr posted:To improve performance, you can look into lots of things, including geometry instancing (you have TONS of similar looking geometry in those pictures) and various occlusion-culling techniques. Furthermore, you could easily save lots of display-list calls, if you created lists for larger block sizes as well (for instance, instead of just keeping 1x1 block size lists, make some 2x2, 3x3, etc etc lists and call them, based on the size of your areas). shodanjr_gr posted:I think that the Z accuracy of opengl only depends on the Zfar - Znear value, but i could be wrong...When you create your frame buffer, try using a larger accuracy depth component (32 bits for instance) to rule out Z-issues. Relevant code is here if that'd help you point it out: http://code.google.com/p/dwarvis/source/browse/trunk/lifevis/Lifevis/Viewer.pm
|
# ? Oct 25, 2008 22:24 |
|
Mithaldu posted:It's not a clone, it's this: http://code.google.com/p/dwarvis/ If you have the game and a decently complex map you can try it out for yourself with the version that's for download there. Very interesting! I'll have to give it a whirl From what I've been seeing, you're taking a very naive (though valid) approach to rendering -- I presume that each tile is a separate draw call, along with each creature, object etc? You're definitely going to introduce a lot of overhead, just in driver command stream alone, not even considering the function call overhead of perl. The way many games address these sorts of issues is by 'batching' draw calls together, wherever possible. Once you get to a place where you've got enough functionality to worry about performance, I can give some more advice if you'd like. quote:Regarding your understanding of what i'm doing: Exactly, thanks for summarizing it so well. Nonsense The Z-near and Z-far coordinates help you place the positions of the near and far planes of the view frustum, respectively, and in turn determine components of your projection transform matrix. This matrix is used to transform your vertices from "view coordinates" (which the Modelview matrix produces) to "clipping coordinates", which are in the range [0, 1] on all axes. The X- and Y-coordinates represent the screen position from (left, bottom) to (right, top), while the Z-coordinate represents the vertex's position between the near and far clip planes as a value between 0 and 1. You can think of the View-to-Clip transform as warping and re-scaling the dimensions of the pyramidal Frustum to a unit-cube. These "clip" coordinates are what the hardware uses to do clipping to the edge of the screen, and what is fed to the Z-test unit as depth coordinates. Thus, [1, 150] and [1001, 1150] should be the same to the hardware, since they both get converted to [0, 1] in the vertex shader. Furthermore, if we're actually talking about being "outside" the scene versus being "inside" the scene, then the numbers would be more like outside=[1000, 1150] and inside=[1, 75] because your camera will by definition be closer to the far plane than the boundery of the scene is. This means that not only will these offending objects (like the blue item in the near field) be moving from the low precision far end of the depth buffer to the higher precision near-end, but that there will be more precision per unit in general! Of course, it's been a while since I worked with OpenGL, so I might be mis-thinking about something. The OpenGL FAQ on Depth has some interesting things to say on the subject. In particular, they suggest doing something along the lines of your "Clear the depth between layers" approach for very large depth distances; however, I still think something else is going awry in your code, because again this seems like the opposite problem you should be having. Can you try just clamping your planes to something like [1, 1000] and moving around the world to see if you're still having issues? Hubis fucked around with this message at 22:36 on Oct 25, 2008 |
# ? Oct 25, 2008 22:33 |
|
quote:How would i do that in OpenGL? I've never seen an explicit option for that and from what i remember from older games (Giants: Citizen Kabuto) that pretty much depends on the display bit-depth. I think OpenGL actually uses the alpha channel for each pixel to store the depth value. No, opengl uses a separate render-target sized buffer to store the depth information. The precision of that buffer is adjustable. Besides, imagine if OGL used the alpha channel to store depth info, how would you do alpha blending AND depth testing at the same time? I only code in C, so im not sure if you can do this in perl, but in C, when you create your Frame Buffer Object, you can do something like this: glGenTexture(blah, blah, blah, GL_DEPTH_COMPONENT_32, blah, blah, blah); before attaching your texture to the color attachment point and your depth buffer is assigned a higher precision value. If you arent using FBOs, use FBOs. Its one of the features of OpenGL that ive grown to ADORE ever since i learned about it. Also, why are you using Perl? fakedit: but as its been said already, i find it unlikely that these are depth precision issues. Its more likely that you have forgotten some sort of Z-test flag off at a point inside your rendering code... shodanjr_gr fucked around with this message at 22:53 on Oct 25, 2008 |
# ? Oct 25, 2008 22:49 |
|
I'm taking a naive approach, in a manner, yes. The script is built by iterative design in such a manner i got one thing working, then multiplied its application, then figured out ways to optimize it properly. Simply helps me keep the whole thing straight in my mind and also helps me when i need to refactor things. (Going from immediate mode to vertex arrays was pretty painless.) However, as the post above yours shows, i'm not entirely clueless in how to leverage basic OpenGL features. Back to the z-planes. I guess i expressed myself badly. Let me quote the article you linked to make it more clear: quote:The OpenGL Reference Manual description for glFrustum() relates depth precision to the zNear and zFar clipping planes by saying that roughly log2(zFar/zNear) bits of precision are lost. code:
I should maybe mention that due to the high density of objects i'm rendering combined with the uniform distribution, i'm thinking that a more evenly distributed z-buffer would be advantageous, as compared to one that's logarithmically skewed to the front. I'm thinking this mostly because i never had much of a problem with z-clipping in the distance. If and when it clipped, it did so uniformly and affected everything i'm drawing equally. I also want to say thanks for taking the time to help me think about this, i appreciate that very much as it's kinda hard to find people to throw these concepts at. As for clamping to [1, 1000], it produces hilarious results: as compared to: That's the whole reason i started looking into this in the first place.
|
# ? Oct 25, 2008 22:58 |
|
shodanjr_gr posted:No, opengl uses a separate render-target sized buffer to store the depth information. The precision of that buffer is adjustable. Besides, imagine if OGL used the alpha channel to store depth info, how would you do alpha blending AND depth testing at the same time? shodanjr_gr posted:If you arent using FBOs, use FBOs. Its one of the features of OpenGL that ive grown to ADORE ever since i learned about it. shodanjr_gr posted:Also, why are you using Perl? shodanjr_gr posted:fakedit: but as its been said already, i find it unlikely that these are depth precision issues. Its more likely that you have forgotten some sort of Z-test flag off at a point inside your rendering code... code:
|
# ? Oct 25, 2008 23:14 |
|
Mithaldu posted:I'm not, since I have no idea what they are and what they do. I mentioned it earlier in the thread, but this is the first OpenGL app i'm doing and everything i'm using i'm literally learning as i go along. Could you maybe explain in plain english and shortly what they are and why i should be using them? Framebuffer objects are basically off-screen framebuffers. You can render to them as you could render to your screen, but nothing shows up on your screen, everything is stored in textures. When you create a framebuffer objects, you "attach" textures to its "attachment points". You can have many "color attachments" (so you can do something that's called Multiple Render-target rendering), one "depth attachment" (a depth buffer, of varying precision), and an accumulation buffer (i think). So you generate your FBO, generate your textures, bind them to your FBO, then use your FBO in the same way you would normaly. This is really useful if you want to do post processing, or use a render pass' output as input in a shader, etc etc. Also its pretty easy to do. A goon made a tutorial at some point, its either in here or in the Game Development thread, so you should check it out. quote:For the above reason. Hilariously fast prototyping that allows me to concentrate on learning what i'm dealing with instead of worrying about arcane intricacies of C++ memory handling. Aside from that it also allows me to keep everything Public Domain and increases the chance of someone coming after me and picking it up in case i ever decide to drop it. Oh well, whatever floats yer boat :P. I am terrible with C, but i havent had issues with coding OpenGL for it (although i mainly focus on shader development, so my C code rarely changes). quote:Well, as far as i'm aware these are all relevant bits: Post your render_models(); code as well.
|
# ? Oct 25, 2008 23:22 |
|
shodanjr_gr posted:Framebuffers shodanjr_gr posted:Oh well, whatever floats yer boat :P. I am terrible with C, but i havent had issues with coding OpenGL for it (although i mainly focus on shader development, so my C code rarely changes). shodanjr_gr posted:Out of curiousity, change the GL_LESS to GL_LEQUAL (i doubt it will change much though). shodanjr_gr posted:Post your render_models(); code as well. quote:
One thing i noticed: Is it normal that when z problems occur that one polygon that is orthogonal to another one pokes partly through it? When playing around with the clamped z-buffer i noticed that it sometimes looks as if the landscape-slices are not just drawing in the wrong order, but being shifted downwards by 0.1 units entirely.
|
# ? Oct 25, 2008 23:51 |
|
Mithaldu posted:Got a question about z-fighting issues. I'm rendering layers of roughly 80*80 objects, with roughly 20-40 layers stacked atop each other at any time. There is no computationally non-expensive way to cut out invisible geometry that i am aware of, so i pretty much have to render everything at all times. This leads to the z-buffer getting filled up pretty fast, resulting in rather ugly occasions of polys clipping through other polys. As for a computationally-inexpensive way to occlude objects, try zoning them using occlusion queries. An occlusion query lets you know if and how much of some geometry is visible. Draw the world (occluders), then disable color/depth write and "draw" the bounding of a zone a bunch of objects could be contained in. Repeat for all zones. If the zone isn't visible, don't draw any objects fully contained in it. For voxel-based stuff there's also octree occlusion, but I'm less familiar with that.
|
# ? Oct 27, 2008 03:29 |
|
OneEightHundred posted:What are you using for the z-buffer that you're only getting 40 layers of precision? Make sure your nearplane isn't too close in particular. OneEightHundred posted:As for a computationally-inexpensive way to occlude objects, try zoning them using occlusion queries. An occlusion query lets you know if and how much of some geometry is visible. Draw the world (occluders), then disable color/depth write and "draw" the bounding of a zone a bunch of objects could be contained in. Repeat for all zones. If the zone isn't visible, don't draw any objects fully contained in it. OneEightHundred posted:For voxel-based stuff there's also octree occlusion, but I'm less familiar with that.
|
# ? Oct 27, 2008 14:43 |
|
Mithaldu posted:Try scrolling up the page to see screenshots. If you're creating a complete 3D voxel grid, then you can draw it in order by just using the view axis. i.e. take the sign of each component of the view direction of the camera, and use that to determine which order to iterate through those components in the voxel array. You can also squeeze more precision out by segmenting the world and doing multiple draw calls. This means that you'd chop your near/far range up into segments, draw anything visible in the farthest segment, clear your depth buffer, draw anything visible in the next-closest segment, repeat. quote:That might actually work ... Do you maybe have some kind of example code for that? You don't want to check each item, you want to check zones, and if the zone hull is culled, then everything in the zone is considered not visible. A zone would be a room, for example, and what you'd "draw" is a box for the bounds of the room. I don't have example code, but it's asynchronous, it works by creating an occlusion query, drawing some stuff, ending the occlusion query, and then later when the card has the query finished, you can check how much it drew. You don't want to check immediately if you have other queries you can run. By disabling depth/color write, it won't actually draw anything, but it will check the visibility of the polygons you're sending. There's some trivial sample code here: http://oss.sgi.com/projects/ogl-sample/registry/ARB/occlusion_query.txt
|
# ? Oct 28, 2008 03:22 |
|
OneEightHundred posted:Still not sure I understand where it's breaking down. What precision are you creating the depth buffer at? OneEightHundred posted:If you're creating a complete 3D voxel grid, then you can draw it in order by just using the view axis. i.e. take the sign of each component of the view direction of the camera, and use that to determine which order to iterate through those components in the voxel array. All in all i'm probably rendering ~20000 distinct objects with roughly 2-100 polys each, using display lists When looking at that from some distance and clipping range settings [46.5098639640652, 145.702191155173] everything looks fine. When zooming in a bit, causing the clipping settings to change to [1, 107.441455160607] it all goes to hell. OneEightHundred posted:You can also squeeze more precision out by segmenting the world and doing multiple draw calls. This means that you'd chop your near/far range up into segments, draw anything visible in the farthest segment, clear your depth buffer, draw anything visible in the next-closest segment, repeat. OneEightHundred posted:You don't want to check each item, you want to check zones, and if the zone hull is culled, then everything in the zone is considered not visible. A zone would be a room, for example, and what you'd "draw" is a box for the bounds of the room.
|
# ? Oct 28, 2008 22:02 |
|
Mithaldu posted:I'm not sure why you're talking about voxels now. I've never mentioned them and am rendering a 3d grid of even-sized objects which are either cubes or more complex objects that can fit inside cubes. He's talking about how visibility techniques intended for voxel objects could also be applied to a dense 3D grid of anything in general. A voxel world is just a 3D grid of objects where the objects all happen to be cubes.
|
# ? Oct 28, 2008 22:18 |
|
Ah, i see. He's suggesting i do the job of the z-buffer in-code. Sadly that's not an option although i'll need to do it later on for objects with transparency. Reason for that not being an option is that it would massively increase the amount of work that Perl needs to do, which is what i'm trying to avoid.
|
# ? Oct 29, 2008 12:24 |
|
Mithaldu posted:Ah, i see. He's suggesting i do the job of the z-buffer in-code. Sadly that's not an option although i'll need to do it later on for objects with transparency. Reason for that not being an option is that it would massively increase the amount of work that Perl needs to do, which is what i'm trying to avoid.
|
# ? Oct 29, 2008 16:17 |
|
I was tempted to post an image of a golf ball bucket here. But to be serious, I do not know what "range buckets" are. I can make vague guesses, which lead me to believe two things: Either you are talking about some technique that is completely unknown to me, or you're ignoring the display list structures i described in earlier posts around which i cannot work around. Color me confused.
|
# ? Oct 29, 2008 17:43 |
|
Mithaldu posted:I was tempted to post an image of a golf ball bucket here. But to be serious, I do not know what "range buckets" are. I can make vague guesses, which lead me to believe two things: Either you are talking about some technique that is completely unknown to me, or you're ignoring the display list structures i described in earlier posts around which i cannot work around. Color me confused. Although you're right, it won't work with display lists. (Stuff like this is why I don't like display lists!)
|
# ? Oct 29, 2008 18:26 |
|
Pretty much a ghetto depth filter for pre-sorting then. Would actualls also work with my display lists, but i don't think it'd give me the granularity i'm aiming for. I also jsut tried to get the occlusion stuff implemented, but ran into a few roadblocks, so i have a few questions: Is it possible to do the occlusion query stuff in another way than using glBeginQueryARB, etc? I know it's not very likely, but better to ask than to stay ignorant. Secondly, there's a similar HP extension for that. Does it only work on special gfx cards or why would glGetBooleanv(GL_OCCLUSION_TEST_RESULT_HP, &result) return the error "Unknown param"?
|
# ? Oct 31, 2008 23:56 |
|
Mithaldu posted:but i don't think it'd give me the granularity i'm aiming for. quote:I also jsut tried to get the occlusion stuff implemented, but ran into a few roadblocks, so i have a few questions: Is it possible to do the occlusion query stuff in another way than using glBeginQueryARB, etc? I know it's not very likely, but better to ask than to stay ignorant. quote:Secondly, there's a similar HP extension for that. Does it only work on special gfx cards or why would glGetBooleanv(GL_OCCLUSION_TEST_RESULT_HP, &result) return the error "Unknown param"? OneEightHundred fucked around with this message at 02:53 on Nov 1, 2008 |
# ? Nov 1, 2008 02:48 |
|
OneEightHundred posted:The point is that it'll let you get more resolution out of the depth buffer since you can adjust the near/farplane for each bucket. OneEightHundred posted:No. What roadblocks are you running into? OneEightHundred posted:The HP extension stalls if you're running multiple queries and occlusion is all-or-nothing, and beyond that the only thing you need to do is create/destroy query objects once in a while so I'd recommend using the ARB one instead.
|
# ? Nov 1, 2008 04:45 |
|
Mithaldu posted:glBeginQueryARB and associated commands are not yet implemented in the Perl OpenGL library. quote:I know it's pretty horrible in comparison, but if i can get it to work, it just may suffice. Since it only relies on commands that are actually implemented already, it might work; unless it's hardware-specific.
|
# ? Nov 1, 2008 11:08 |
|
OneEightHundred posted:I'm pretty sure POGL will let you make core OpenGL 1.5 contexts, OneEightHundred posted:in which case everything will work the same except the occlusion query ARB functions are core, meaning they don't have "ARB" at the end. I'm thinking about trying to see if they're easy enough to implement in the .xs and compile my own version, as well as mailing graphcomp about it, but i want to exhaust my options first. OneEightHundred posted:I see no reason it shouldn't, are you sure you're getting a context from the ICD and not the lovely stock Windows OpenGL implementation?
|
# ? Nov 1, 2008 21:18 |
|
Ive got an Screen Space Ambient Occlusion related question (far more about graphics "theory" than OpenGL technicalities). Ive written my first SSAO shader, and am quite pleased with the initial results. However, the results get less pronounced the further the object is inside the view frustrum. This is a result of the farther objects recieving less precision, and thus the difference between adjacent Z-values being almost zero. Can anyone suggest ways to "counter" this, other than expanding the sampling kernel (which i am already doing)?
|
# ? Nov 2, 2008 05:05 |
|
Mithaldu posted:As far as i am aware i can only use the functions that are defined in the .xs, compiled into the .dll and exported in the .pm. The only function with the word "query" in the name for which this is true is glpXQueryPointer. quote:Again, i don't know what that means. Sorry. :/
|
# ? Nov 2, 2008 06:57 |
|
OneEightHundred posted:POGL definitely has a glBeginQuery binding in everything starting from the OpenGL 1.5 bindings and up. OneEightHundred posted:If you link against opengl32.lib then for whatever reason, the entry points (read: functions) you get are from the lovely stock Windows OpenGL library. You need to make sure that the project is set up to dynamically load the DLL and get the entrypoints with GetProcAddress, which will use the ICD version (a.k.a. the one that comes with your video drivers, which is fully-featured) instead. Edit: Looked into it. It loads "C:\Programme\Microsoft SDKs\Windows\v6.0A\Lib\OpenGL32.Lib". Tried removing that file to see if Makefile.PL can cope with that, but that only resulted in a broken build. Definitely thinking about trying to add the missing commands manually now. Is there a good way to check whether glBeginQuery was executed correctly or am i gonna have to fly blind? Mithaldu fucked around with this message at 07:29 on Nov 2, 2008 |
# ? Nov 2, 2008 07:12 |
|
I'm just going off what I see in the package and I really don't know what the gently caress, so the best I can do is tell you where I see things that look like what you want.Mithaldu posted:Can you point out where you get that information from so i at least have a clue where to start looking? I mean, i'm looking at the source code for the module here, straight from CPAN, BEFORE compiling etc., and the only mentions of these functions are in the opengl includes files, but NOT in the perl files themselves. quote:Is there a good way to check whether glBeginQuery was executed correctly or am i gonna have to fly blind? Although realistically, if your program doesn't instantly crash from calling a bad entry point, it probably executed correctly.
|
# ? Nov 2, 2008 07:47 |
|
Ah, i see what's going wrong now. You're looking at an older release. This is the most current and has a bunch of cruft removed: http://search.cpan.org/CPAN/authors/id/B/BF/BFREE/OpenGL-0.57.tar.gz As for the file you were looking at there, i believe they weren't meant to reflect POGL, but only serve as documentation for the maintainer. Also, Perl doesn't quite work that way. If you have visual studio express installed as well as ActivePerl, you can use the "Visual Studio 2008 Command Prompt" to run "perl Makefile.PL", which then generates the makefile like so: http://rafb.net/p/0x8xHQ38.html After that you do "nmake" and it generates the OpenGL.c file from the .xs file, which is then used to compile the dll. The .c file looks like this: http://www.mediafire.com/download.php?mttmnzzkto1 OneEightHundred posted:Although realistically, if your program doesn't instantly crash from calling a bad entry point, it probably executed correctly. Edit: Narrowed it down a bit by inserting debug statements in the .c file. It crashes exactly when trying to call glGenQueries in the c part. Also, poking at the perl process with Process Explorer shows it's using OpenGL32.DLL from the system32 directory. Would maybe replacing that with a more capable version work? Edit2: Apparently i'd need to convince it to load nvoglnt.dll somehow. As i'm not too firm in c (beyond basic syntax and compiling stuff in visual studio), is there a simple way to edit the makefile/c file to make that happen? Edit3: Nvm, got it. They apparently do both, link against the windows opengl library AND automatically load from the driver. Adding the following before the actual code section of the function in the .xs file made it work properly for this one function: code:
Also, thanks a lot for all the information you've given me. I doubt i would've gotten this far stumbling along on my own. Edit4: I found out what the "Unknown param" i mentioned earlier means. In order to feed back data that is given by creating arrays, the xs code needs to allocate the memory for that. In order to allocate said memory it checks a function which has the size of the feedback array for different possible parameters stored. The HP occlusion testing feedback parameter was simply not listed there, so it doesn't know how much memory to allocate and bails out. Edit5: All functions implemented and the occlusion queries are working now in the test implementation. I hope with that the hard part is over ... Mithaldu fucked around with this message at 11:05 on Nov 2, 2008 |
# ? Nov 2, 2008 08:29 |
|
Mithaldu posted:Edit2: Apparently i'd need to convince it to load nvoglnt.dll somehow. As i'm not too firm in c (beyond basic syntax and compiling stuff in visual studio), is there a simple way to edit the makefile/c file to make that happen? quote:Edit3: Nvm, got it. They apparently do both, link against the windows opengl library AND automatically load from the driver. quote:Edit5: All functions implemented and the occlusion queries are working now in the test implementation. I hope with that the hard part is over ...
|
# ? Nov 2, 2008 12:02 |
|
OneEightHundred posted:Using LoadLibrary on opengl32.dll should do this automatically. I don't know why it works this way, all I know is that static-linking opengl32.lib is bad for your health. I actually think it's meant to be that way, since, uh, if you do it manually with LoadLibrary, you'd need to try for all possible driver dlls, and keep your code up-to-date as drivers change, right? If i'm wrong there, do you have example code for what's the "right way"? OneEightHundred posted:code:
Oh, and thanks again. The endorphine rush when you look at your code and realize "gently caress, it works" is always great. Mithaldu fucked around with this message at 12:27 on Nov 2, 2008 |
# ? Nov 2, 2008 12:25 |
|
Mithaldu posted:I actually think it's meant to be that way, since, uh, if you do it manually with LoadLibrary, you'd need to try for all possible driver dlls, and keep your code up-to-date as drivers change, right? I may be wrong on this whole thing too. quote:Also, while i'm looking at it. What's the glFlush there good for? It's not a terrible idea to flush if you're going to do other things before you request the query results though. OneEightHundred fucked around with this message at 20:12 on Nov 2, 2008 |
# ? Nov 2, 2008 19:58 |
|
OneEightHundred posted:Loading opengl32.dll will get the appropriate DLLs. Apparently you'd want to use vanilla GetProcAddress for the regular entry points and wglGetProcAddress for everything else, but I really don't know how well that behaves with various OpenGL versions. Best practice is to use GPA for the whole interface. Unless i'm missing something, i'd only be doing lots of work to duplicate something that's already there. OneEightHundred posted:It's redundant, checking query availability automatically flushes. NV_occlusion_query didn't do that so it's probably a leftover from that. OneEightHundred posted:It's not a terrible idea to flush if you're going to do other things before you request the query results though.
|
# ? Nov 2, 2008 20:39 |
|
Sorry if this has been asked before, but I have problems with precision using the depth buffer. First I'm rendering stuff to several depth buffers, and afterwards I want to merge them by drawing them on top of each other with depth testing enabled. And afterwards I am using the depth test GL_EQUAL in order to shade everything. However it does not work very well. I do find that by using buffers with the same precision I get better results, but I have yet to find a combination that works. Any ideas?
|
# ? Nov 3, 2008 15:50 |
|
BernieLomax posted:Sorry if this has been asked before, but I have problems with precision using the depth buffer. First I'm rendering stuff to several depth buffers, and afterwards I want to merge them by drawing them on top of each other with depth testing enabled. And afterwards I am using the depth test GL_EQUAL in order to shade everything. However it does not work very well. I do find that by using buffers with the same precision I get better results, but I have yet to find a combination that works. Any ideas? Camera --> N[----A----B----]F ... and chop it into two depth slices... Camera --> N[----A--]F N[--B----]F ... then you need to clear the depth buffer after after you draw the distant slice anyway, otherwise you can get out-of-order objects like this crap: Camera --> N[--B-A--]F The drawback of course is that by clearing the depth buffer, you are eliminating B from the depth buffer. What you need to do is make sure that any objects that are in a depth slice (even partially) get drawn in that slice. .... Alternately, make sure you're creating the depth buffer with a reasonable precision and try adjusting your nearplane/farplane values. OneEightHundred fucked around with this message at 21:36 on Nov 3, 2008 |
# ? Nov 3, 2008 21:20 |
|
OneEightHundred posted:You can't really do this because the depth buffer values range from 0-1, the projection matrix remaps distances between the nearplane and farplane to that range. That means if have, say, one depth range... I'm trying to work around this, but still would love if there was a way. edit: Solved. I made a fragments-shader that reads from a depth texture and compares the fragment-z and draws with a threshold. Works extremely well. BernieLomax fucked around with this message at 09:40 on Nov 5, 2008 |
# ? Nov 4, 2008 22:07 |
|
Just a random note to anyone following the occlusion query stuff above: Don't forget to delete the queries once you're done with 'em. Edit: Also, question: How would i go about making a polygon render visibly from both sides without rendering it twice? Mithaldu fucked around with this message at 13:10 on Nov 11, 2008 |
# ? Nov 11, 2008 12:04 |
|
Mithaldu posted:Edit: Also, question: How would i go about making a polygon render visibly from both sides without rendering it twice? If you want the two sides to render differently, you either need to render twice or use two-sided rendering pixel shaders which I haven't dealt with yet.
|
# ? Nov 11, 2008 18:40 |
|
OneEightHundred posted:glDisable(GL_CULL_FACE) Thanks. I needed it to make the occlusion check shapes also render when the camera is inside them. Now i only need to make the shapes a bit more fine-grained with the help of the stuff from the gamedev thread and then i can get back to the fun stuff.
|
# ? Nov 11, 2008 19:49 |
|
|
# ? May 15, 2024 04:26 |
|
I've recently been inspired to start game programming as a hobby, but I know virtually nothing about the subject. Do you guys have any literature you'd recommend for a beginner? I'd like to get started with basic stuff like vertexes and pixel shading, etc.. I have an idea for a game I'd like to create for the iPhone, so I opened the PDF for the OpenGL ES v1.1 spec and most of it was foreign to me. The first page they stated "We assume that the reader has at least a rudimentary understanding of computer graphics." So I'd like to get to that level within the next year or so.
|
# ? Nov 11, 2008 20:04 |