Jump to content
  • Advertisement

Ben Foppa

Member
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

109 Neutral

About Ben Foppa

  • Rank
    Member
  1. Ben Foppa

    Triangle mesh generation from a heightmap?

    Yup, that's right. I already have cubes, but I want to get rid of the blocky look and produce a smooth triangle mesh. I'll still be taking inspiration from Minecraft, though, as well as Voxel Farm. The renderer isn't specialized for voxels (anymore), it's just rendering triangles. I just want those triangles to be more smooth, instead of staircasing everywhere.   I haven't tried this out, but my current plan is to keep the uniform grid (for terrain generation), and sample the heightmap at the center of each xz-square, as well as at each corner, then create a "square-based pyramid", but making the height of each vertex correspond to the heightmap at that xz coordinate.
  2. So far, I've been generating cubes (well, variable-height "cubes") from a straightforward perlin noise heightmap, but I'm getting a little stuck at producing a smooth triangle mesh instead of the "blocky" look. The obvious algorithms I can come up with to make a triangle mesh show obvious patterns in how the triangles are constructed. Does anybody have any good resources for this?   Thanks!
  3. Ben Foppa

    Wireframe rendering (how to?)

      The flickering still happens even when standing still. The screenshots I posted are taken from the same camera angle but have noticeable differences.   To clarify: texturing is a cause, but it's not the cause - anything I do that causes different vertices to be different colors (even just coloring them red or green based on gl_VertexID) makes flickering happen when standing completely still.   Edit: Looks like it's probably a driver bug - turning off DRI fixes the problem. So glPolygonMode set to GL_LINE should work great! Thanks for all your help!
  4. Ben Foppa

    Wireframe rendering (how to?)

      My geometry is all boxes right now, but it seems to happen fairly universally. As I mentioned earlier, it only happens when vertices of lines have different colors; if I set all connected vertices to have the same colors, the flickering stops.   But if different vertices have different colors (e.g. because of texturing or lighting) then the flickering is very noticeable, even when standing still.       album for easier side-by-side comparison   Adding to this, try to set z function to glALWAYS and see if flickering stops. If not, it is not coused by depth fighting, if it goes away, then post your projection matrix setup.     Good point! Yup, it's definitely not depth fighting.   Could it possibly be a driver bug?
  5. Ben Foppa

    Wireframe rendering (how to?)

    Are you using LEQUAL as I suggested? You're using EQUAL in the code you posted.     Yup, here's the new render function:         gl::Clear(gl::COLOR_BUFFER_BIT | gl::DEPTH_BUFFER_BIT);                              gl::DepthFunc(gl::LEQUAL);       gl::PolygonMode(gl::FRONT_AND_BACK, gl::LINE);                                              draw();   I notice that everything works if I give things constant colors, though. If the shader is drawing textured faces or using lighting, then I get flickering with glPolygonMode set to GL_LINE..
  6. Ben Foppa

    Wireframe rendering (how to?)

    Taking a rough guess, but I imagine this is because you can achieve the same effect with just shaders? (just make sure to do it after the transformations though so they affect the transformed Z value)   EDIT: er I was thinking about the function that lets you offset the Z value, sorry >_< But that idea still should work I suppose. Just modify the Z value a bit after you transform it.     Modify it in what way? Won't two vertices in the same position still produce the same output Z values..?
  7. Ben Foppa

    Wireframe rendering (how to?)

    A z-prepass with polygon fill mode will set depth values for the entire faces. So a sub-sequent GL_EQUAL depth test will not let pass fragments of triangles behind.   EDIT: Or did you mean it plays nice with rendering some feature edges like intern ones?     BTW: In a z-prepass it is better (performace-wise) to disable rendering to color buffer(s); this also saves you the need to clear the color buffer(s) a 2nd time.     GOOD point. Clearly I didn't think that one through..   Is there a performant way to do that besides just re-writing all my shaders without outputting/calculating fragment colors? I kind of assume if I just use glColorMask, the fragment shader will still run for everything anyway..   Then just disable face culling (ie, glDisable(GL_CULL_FACE) ) and draw like regular geometry with LEQUAL depth test and GL_LINE for polygon mode. That's how my wireframe pass is set up.     I'm still getting "flickering", which I assume is because lines that intersect will still be fighting for the same pixels. Although.. maybe it has to do with the fact that I'm rendering textures with a GL_LINE polygon mode?   Edit: Okay, it's not because of texturing.. It might have to do with the lighting though - I'm noticing the polygons with flat lighting don't seem to be flickering..
  8. Ben Foppa

    Wireframe rendering (how to?)

    I'm not sure, but I think a double-post is appropriate for a "report back" sort of scenario?   I changed my render function to this:       gl::Clear(gl::COLOR_BUFFER_BIT | gl::DEPTH_BUFFER_BIT);       gl::DepthFunc(gl::LESS);       gl::PolygonMode(gl::FRONT_AND_BACK, gl::FILL);       draw();       gl::Clear(gl::COLOR_BUFFER_BIT);       gl::DepthFunc(gl::EQUAL);       gl::PolygonMode(gl::FRONT_AND_BACK, gl::LINE);       draw(); Some scattered pixels render (particularly far-away ones), but definitely not anywhere near the expected result. It's worth noting that draw() binds all the normal shaders and whatnot; I'm not sure if that might cause issues. Also, I'm pretty sure this will cause some Z-fighting still, since lines that touch one another would fight over that pixel, no? (assuming I'm not drawing them all in the same color, which I'm not - I'd like to be able to distinguish things somewhat based on their color).
  9. Ben Foppa

    Wireframe rendering (how to?)

      Z pre-pass will probably help though. I'll try and report back.     I'm not rendering overtop of existing geometry (because I also want to display "hidden" triangles), but I suspect this will combine nicely with the Z pre-pass mentioned above!   And thanks for the note about GL_FRONT, I was about to ask, since I get a GL_INVALID_ENUM error using GL_FRONT, and https://www.opengl.org/sdk/docs/man3/xhtml/glPolygonMode.xml says GL_FRONT_AND_BACK is the only valid value.   Thanks for your help!
  10. I've tried a few different methods of wireframe rendering, and I can't seem to find one that works nicely, even just for debugging purposes.   Simply setting glPolygonMode causes Z-fighting like nobody's business (and as a bonus point against it, it's not OpenGLES-compatible).   In general, I've just had issues using "built-in" lines because of Z-fighting; I haven't specifically tried creating a separate "wireframe bufer" here, but at the very least, there would be a lot of duplication in the buffer (or lots and lots of calls to glDraw*).   Trying to use clever shaders and discarding fragments in the middle of triangles can work, but only the triangles that would be visible in non-wireframe are rendered, because of the depth buffer. It's also annoying because geometry shaders aren't very well-supported, either in OpenGLES or even just by my own graphics drivers.   I'm currently looking into writing wireframe rendering using OpenCL, but I'm not really hopeful about this.   Any other ideas out there?   Thanks!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!