Jump to content
  • Advertisement

averisk

Member
  • Content count

    114
  • Joined

  • Last visited

Community Reputation

146 Neutral

About averisk

  • Rank
    Member
  1. averisk

    Marching Cubes Terrain: Result

    It's certainly an interesting idea. You would have to be really clever about reducing redundancies in your tables to make it feasible though. For the simplest case where only one side has a finer resolution, you have 9+4=13 voxels like you said (2^13 possible configurations). Of course, you'd only want to store this once for the six possible rotations for which this could occur. I worked out the rest of the cases below, I might not have got all of them right: one face: 2^13 configurations, 6 rotations two adjacent faces: 2^17 configurations, 12 rotations two opposite faces: 2^18 configurations, 3 rotations three lateral adjacent faces: 2^21 configurations, 12 rotations three non-lateral faces: 2^20 configurations, 8 rotations four lateral faces: 2^24 configurations, 3 rotations four non-lateral faces: 2^23 configurations, 12 rotations five faces: 2^25 configurations, 6 rotations In the worst case, where all but one side has a finer resolution, we need to define around 33 million polygonal configurations... Is this what you had in mind? There's probably ways to reduce this further but I'm drawing a blank right now. I think a better way of achieving this would be to split up nodes on a level boundary into six pyramids (based off of the center point) and use "marching pyramids". You'd generate a lot of extra polys but since most nodes won't be on a level boundary this might be ok, since you'd be using marching cubes most of the time
  2. averisk

    Marching Cubes Terrain: Result

    Quote:Original post by Basiror How do you join triangles of chunks with different resolution together? That's what I was explaining in my last post. Let's assume that the resolutions only change by one level across neighbouring nodes, then in most cases you can stitch the triangles of the two chunks together by adding more polygons on the courser side. For every triangle on the courser side that has at least one edge along a finer-level neighbour, we add a new vertex in the center of the triangle and 'fan out' to include all the extra vertices. Some cases require special attention because it's not as simple as the above but hopefully you get the general idea
  3. averisk

    Marching Cubes Terrain: Result

    Quote:Original post by PolyVox Quote:Original post by averisk For my undergraduate project a few years ago I wrote a paper and accompanying demo showing one approach to a continuous LOD scheme for voxel-based terrain. It was reasonably fast, scaleable, did not involve touching the vertex buffer, and worked on arbitrary topology. It was possible to define metrics in such a way so as not to collapse bridges or fill in tunnels, and as a nice result it also allowed for flat areas to be tesselated at a lower resolution, avoiding the usual problem of marching cubes generating too many triangles. If there's any interest I can post some more details, I'll just need a few days to dig it up Hi averisk, I would be very interested in this - could you post back when you have more details? I've currently using the approach of LODing the volume and I agree it has drawbacks. My approach is essentially mip-maps with the cracks between levels sewn together. This is done by adding a new vertex in the center of the triangle on the courser side and fanning it out to include all the extra vertices on the finer side. There are cases where this doesn't make sense, for example when the finer-side has its center point 'inside' and all the corner points are 'outside'. The courser side would just be empty space. This is handled by changing the value for the center point to lie exactly on the surface and other cases are handled similarly.
  4. averisk

    Marching Cubes Terrain: Result

    Quote:Original post by swiftcoder The real problem is LOD. I haven't found a good scheme to handle LOD for voxel terrain - naive approaches such as mipmapping the voxel field cause a lot of artefacts (disappearing tunnels, shifting walls, etc.). Height fields are trivial to perform LOD on, which is what I was primarily commenting on. For my undergraduate project a few years ago I wrote a paper and accompanying demo showing one approach to a continuous LOD scheme for voxel-based terrain. It was reasonably fast, scaleable, did not involve touching the vertex buffer, and worked on arbitrary topology. It was possible to define metrics in such a way so as not to collapse bridges or fill in tunnels, and as a nice result it also allowed for flat areas to be tesselated at a lower resolution, avoiding the usual problem of marching cubes generating too many triangles. If there's any interest I can post some more details, I'll just need a few days to dig it up
  5. Quote:Original post by JeffNiko I cannot seem to find a configuration that allows me to have two projects referencing the same classes so don't have to have a separate copy of the files in each project folder. Create a library project for common classes that compiles to DLL. Then you can reference it by both client and server projects
  6. Thanks, Mr E *cough* shameless bump *cough*
  7. I did a redesign of a site I made awhile ago: http://www.3delement.com It's basically a database of game development tutorials. It's grown to be pretty big over the years, thanks to user-submissions. You can add your own categories and links by clicking on 'add link/category' at the bottom of each directory. Any changes to the database immediately take effect, but only for the IP address that submitted them. It usually takes a day or two before they can be vetted by an admin. Hopefully you'll find it useful. Comments/suggestions/criticisms are welcome. [Edited by - averisk on April 21, 2007 9:19:10 PM]
  8. averisk

    Ask It a different way

    If I were you, I'd construct the 4x4 matrix necessary to scale/translate/rotate the unit cylinder to get what you want. You could calculate the three matrices seperately and then multiply them together. Then it would just be a matter of calling glMultMatrix and rendering the unit cylinder, maybe by using gluCylinder.
  9. averisk

    Spline Roads

    Quote:Original post by paulbird I will need to calculate the inbetween points as well for collision detection purposes? I'd say so. If it's 3d, you're better off tesselating all the points and just doing per-poly collision detection. The math gets really ugly really quickly otherwise and you're usually forced to use a numerical solution anyway.
  10. Quote:Original post by thallish I got to wonder though about how to make caves/overhangs in the terrain. I know I just read about it a week ago and I cant seem to find the information about it now. It was something about using a second heightmap. Does somebody have an idea on how to do this? I spent the last year researching how to model caves and overhangs in terrain as part of an undergrad project. I've been aching to post screenshots and information about the algorithm but I can't right now (I'm in the middle of a move and starting a new job). I'll PM you when I do manage to do it though, in a month or something. It doesn't use multiple heightmaps. It's actually an iso-surface renderer, but as soon as you define the terrain as an iso-surface it becomes a terrain engine. (and this can be done more easily than you might think) It supports totally arbitrary geometry, continuous LOD to any degree of fineness or courseness desired, a decimation scheme that is compatible with the continuous LOD, as well as some other nice benefits (such as a resulting mesh that perfectly fits into an octree without the need to split any polys). The LOD scheme is also scalable, so if brute force is really the way to go the renderer can choose to use it.
  11. Quote:Original post by Niwak What I would expect from a modern terrain engine is to support the following features : - support huge area of landscape with great level of detail - look good with very high level of detail and react to lighting - let my game engine interact easily with it - don't eat all my processing power. To add a few more: - support overhangs/caves - no popping with lod scheme (ie. geomorphing) - realistic static and dynamic lighting - constant FPS (using things like occlusion culling and CLOD) - scalable between brute force rendering and highly optimized CLOD - arbitrary view distance (!)
  12. Quote:Original post by Mike2343 I don't know if its been mentioned but you don't really need LOD on todays hardware (unless you want it to run on a GF3 or something). Or if you want large enough scenes... Of course it's less necessary these days but I mean, unless you're doing UT 2k3 or something you'll need some kind of LOD scheme, won't you?
  13. Thanks Doggan, you're right. I guess in my frustration I missed the part of the site that explained that. Your demo project is exactly what I was looking for. rating++ :) Quote:Original post by Dave Hunt I'm curious as to what problems you had with the Tao framework. There are a lot of people using it without any trouble, so I don't think I would give up on it too quickly. Well since I first posted I figured out the problem... Somehow it had to do with the fact that I was using the .NET framework 2.0 I downgraded to 1.1 and it worked fine
  14. Hello I've been trying to get C# and opengl working in the way I want for the last few days with little success... I've tried csgl and the tao framework, but couldn't get either one working I could find lots of sample code that was supposed to do what I need but nothing that would actually compile under VS.NET 2005 and install with the .net framework 2.0 All I want is a simple C# example with a windows form that contains a control that renders some 3d geometry using opengl. The closest I found is this but it appears to cost a lot of money... Surely lots of people have done something like this. Can anyone help? Thanks
  15. Thanks again everyone I've decided to take Tom's advice and stick it out here for a year until I have enough financial security.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!