# averisk

Member

114

146 Neutral

• Rank
Member
1. ## 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. ## 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. ## 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. ## 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. ## VS2008: Multi-Project Solution Setup

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. ## 3Delement.com - Database of game development resources

Thanks, Mr E *cough* shameless bump *cough*
7. ## 3Delement.com - Database of game development resources

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

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. ## Making a terrain engine (master thesis)

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. ## Making a terrain engine (master thesis)

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. ## Making a terrain engine (master thesis)

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. ## OpenGL in C# as a control on a windows form for VS.NET 2005

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. ## OpenGL in C# as a control on a windows form for VS.NET 2005

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. ## The importance of location for game industry applicants

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.