Sign in to follow this  

The End-All Be-All Higher Order Surface (bezier, nurbs, etc) Terrain Thread

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, There has been discussion here and there about using higher order surfaces such as bezier patches, NURBS, and other such methods to create detail and shapes in terrain in ways height maps could never hope to achieve. I know there are people, including myself, who are very interested in the subject but have not been able to figure out every aspect of creating a HOS terrain system. I will list several sub topics and questions and hopefully we can turn this into the one thread that people can be pointed to when they need information on the subject. Let's begin: Quick question: What are the differences between Bezier patches and NURBS? Which is more suitable for the job and why? I have read the nehe tutorial on Bezier patches and was able to form in my head how a terrain system made up of them would work, but do NURBS have advantages over Bezier patches? On Texturing: In a previous thread I was reading about how texturing would work on a HOS terrain. It was said that you could use normal texture coords but that could cause stretching, however you could render another layer over the patches that would have unstretched texture coords (this being very slow it was said). Is it possible to just use the texture coords of the patch and just make sure that you don’t stretch it too much? Another question I had was about "painting" textures on a terrain in a world editor of sorts. I want to build a world editor which allows me to editor my terrain in real time using a set of tools to change the size of my terrain, add patches, add textures, etc. One important feature would be doing something along the lines of "selecting the texturing tool, then the brush size, and then applying the grass texture to a small portion of the map." (or something to that effect). How is this kind of "texture painting" achieved, also, how can it be saved later and loaded later on, just save the terrain's texture as one large image, or is there a better way, such as saving the location of where the textures are "painted", then when the map is loaded just load the textures and paint them onto the map and interpolate textures that blend? On Level of Detail When I read the nehe tutorial on Bezier patches and how you can decrease the detail of the patch by lowering the number of divisions, I got the idea that you could set the number of divisions based on how far the camera is from that patch. That seemed like the most logical way of going about it. Added performance would come from frustum culling and not rendering occluded surfaces. Cracking could be handed by making sure that adjacent patches of different LOD levels have their edges connecting (well, duh). On Lighting I'm not sure how I would go about this really... Would I just add the normals to the patch like I would the texture coords? Or is there some better method of doing this? While I'm on the subject, how would I make the normals span the entire terrain? Another thing to keep in mind would be collision detection I hope we can get some discussion going here, this is a very interesting subject and if you have anything to contribute by all means, please do :) (Hopefully we can get Yann up in here)

Share this post


Link to post
Share on other sites
For my terrain, I'm using coarse elevation data (10m spacing). To add extra detail, I interpolate between elevation data points and add procedural noise.

Below are screenshots of the Grand Canyon with linear interpolation (top) and Hermite interpolation (bottom). (For Hermite interpolation, a.k.a. Hermite splines, you specify positions and slopes at two endpoints and you get a cubic curve.) There is no procedural noise in these shots.

As you can see, the Hermite interpolation produces weird artifacts at sharp cliffs, and this is something I'm working on. If anyone has any thoughts or advice on this, feel free to post.




I am only using higher-order surfaces to generate a higher-resolution heightmap from the source elevation data (The surface evaluation is performed on the CPU). As for texturing, lighting, and dynamic LOD, I am basically using Hugues Hoppe's geometry clipmaps technique (look for the paper on his website if you're interested).

Share this post


Link to post
Share on other sites
NURBS rock! Fortunately, I can "enjoy" them on my day job ;)

In real-time simulations, though, evaluating them can be quite intense on the processing units. Tesselation is not that easy. And there are *lots* of cases which need special attention ;)

Bezier splines on the other are way more easy to handle and process. But, of course, they're way more limited, too (compared to NURBS). Dilemma :)

-codeandroid

Share this post


Link to post
Share on other sites
some general points on parametric surfaces....

* always tesselate each patch using linear intervals. deal with a terrain as lots of small patches, then fix the lod differences around the edges of each patch. Geo-mipmapping techniques comes into play here.

* do not calculate surface normals and tangents using some derived high order parametric evaluation. it is too slow. A better method is to use the vertex positions generated to calculate the normals; a couple of vector subtractions and a cross product will always be quicker than any high order parametric evaluation.

* the lower the degree of the curve, the faster it is to calculate.

* the lowest degree required to maintain curve continuity is 3

* a bezier curve is a NURBS curve of degree 3, ie, the simplest possible curve that maintains continuity.

* for terrain, use bezier patches since they are the simplest possible parametric surface that maintains continuity. The simpler they are, the more you can optimise them.

* hermite patches are probably more useful since they take into account the tangents of the surface.

* err, but my artists have modelled evrything using nurbs surfaces?

* dont worry, all nurbs surfaces can be converted into a set of bezier patches. This is how gluNurbs works, first it decomposes the surface into a set of bezier patches and then renders them. The code to do this is handily available in the mesa source....

* pardon? gluNurbs sounds like it's doing a lot of work? .... err, yes - it's very very very very slow.

* GluNurbs, NV-Evaluators, vertex shaders or any other method of dynamic tesselation will ALWAYS be slower than doing something clever in software.

* There are 3 things you must do to handle all parametric surfaces in software :

1- calculate the blending functions when the LOD changes. remember that the u and v blending functions only need to be calculated once in each surface direction. those T to the power of values will always be the same for each step along a given surface direction (thus, any dynaic method is ALWAYS slower)

2- when the cv's change, re-tesselate the surface points. Calculate the surface normals & tangents. Update the vertex buffers / VBO's.

3- when rendering, simply render the VBO's on the graphics card

* lazy evaluation is the key to speed.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
For a terrain editor that deals with this kind of terrain, would it be best for it to work like this?:

New patch -> Move patch where you want it -> Snap it's edges to the adjacent patches -> Reshape patch accordingly

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by unsigned int
Hello everyone,

There has been discussion here and there about using higher order surfaces such as bezier patches, NURBS, and other such methods to create detail and shapes in terrain in ways height maps could never hope to achieve. I know there are people, including myself, who are very interested in the subject but have not been able to figure out every aspect of creating a HOS terrain system. I will list several sub topics and questions and hopefully we can turn this into the one thread that people can be pointed to when they need information on the subject. Let's begin:



Well, I think I'd compare whatever you do against this:

http://research.microsoft.com/~hoppe/geomclipmap.pdf

This demo allows a fly through of the entire United States at 60 fps. The sample Grid is 20 billion or there in abouts. IIRC, that is 1 sample point per meter.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by unsigned int
Hello everyone,

There has been discussion here and there about using higher order surfaces such as bezier patches, NURBS, and other such methods to create detail and shapes in terrain in ways height maps could never hope to achieve. I know there are people, including myself, who are very interested in the subject but have not been able to figure out every aspect of creating a HOS terrain system. I will list several sub topics and questions and hopefully we can turn this into the one thread that people can be pointed to when they need information on the subject. Let's begin:



Well, I think I'd compare whatever you do against this:

http://research.microsoft.com/~hoppe/geomclipmap.pdf

This demo allows a fly through of the entire United States at 60 fps. The sample Grid is 20 billion or there in abouts. IIRC, that is 1 sample point per meter.


didn't mean to be anonymous...

Additionally, if you are interested in NURBS, then check out last years T-Spline paper http://cagd.cs.byu.edu/~tom/papers/tspline2.pdf

These appear to be vastly superior in terms of compression to geometry ratios then NURBs since they don't place such strict topolgy requirements.

Share this post


Link to post
Share on other sites
"Dynamic Level of Detail Terrain Rendering with Bézier Patches"
The terrain system used in SSX.
http://www.gamasutra.com/gdc2002/features/rayner/rayner_pfv.htm

Share this post


Link to post
Share on other sites
I'm giving a crack at Catmull-Clark subdivision surfaces (and Blender supports them). I'm just implementing it now so I don't know how well or if it works. It's a quad-based control mesh of arbitrary topology. The subdivision rules are simple and relatively efficient.

Quote:

On Texturing:

The texture coords are generated using the same subdivision rules used to generate the positions and normals (ie takes the uv coords at the control points and subdivide to get the uv at the tessellated points). This makes them nice and continuous.
In my case the terrain subdivision mesh is edited in Blender and the terrain will be painted in a custom tool by giving each patch (base quad in control mesh) a fixed-resolution square chart in a surface-type map (in my case each quad is 4x4metres and the surface-map resolution is .25metre so each chart is 16x16texels). Initially the whole terrain is unpainted (or has a default surface type). When the brush covers a previously unpainted base quad it allocates a square chart from the associated surface map (there's just one big 4096x4096 surface map) and assigns it to the control mesh base quad being painted on (in my case this is done by encoding the chart index into the vertex colours of the blender file since they're unused by Blender - and each control quad has its own 4 vertex colours - they're not shared with adjacent quads). The tool then writes the current surface-type into the chart as the user paints across it. Whenever artist wants to paint terrain a Blender python export script writes the control mesh positions and vertex colours to a file and kicks off the custom texture tool which reads the positions and converts the vertex colours to chart indices. When finished painting the tool writes any changes to the chart parameterization to a file and returns control to the python script which reads the changes and stores them in the control mesh vertex colours - so painting and mesh editing can be done incrementally with respect to each other. Only when a patch is deleted in Blender does it lose its chart - so you can extrude a patch, move it, etc, and it retains its painted chart. When custom tool is next run it can detect deleted charts and put them back into the free list.

Quote:

On Level of Detail

I'm going to use the xvox technique (extended from heightfields to arbitrary quad mesh). It has crack-fixing and lod built in the vertex shader - with some patch management from the CPU. An ABT tree (from YannL's threads) instead of quad-tree is used since the terrain is arbitrary topology.

Quote:

On Lighting
While I'm on the subject, how would I make the normals span the entire terrain?

If offline-generated DXT5 compressed normal textures use too much VRAM then a texture caching scheme could be used where normals are generated on the fly and placed in RGB8 textures. The resolution starts off full-detail (ie at highest patch tessellation) near the viewer and at a certain distance the full-detail normals will be 1 texel per screen pixel - after that can generate progressively lower-res normals with distance (keeping 1 texel per screen pixel) until far enough away where one patch is one pixel on screen - this would be the lowest res since generating lower-res normals gets difficult unless using a heightfield. This could still use a fair bit of memory. At some point might make sense to switch to low-res pre-generated DXT5 normal map (depends on size of terrain - for mine 1024x1024metres a pre-generated low-res 4texel/sq.metre - roughly ~5.5Mb with mipmaps - is used for everything >~200metres from viewer).

Quote:

Another thing to keep in mind would be collision detection

I plan on run-time tessellating the geometry near each player and caching it for collision detection. Things like fast projectiles could cause problems here. I have client/server multiplayer so the client just tests against the LOD'ed mesh for client-side prediction and the authoritative server uses extra memory to store the full-detail cached geometry a certain distance around each player.

[Edited by - Soiled on October 10, 2004 6:40:41 PM]

Share this post


Link to post
Share on other sites

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this