Gouraud vs Normal maps for dinamic terrains

Member
Posts: 72
Joined: 2006.10
Post: #1
Hello all! I am in need of wisdom.

First a bit of context: I am rendering a terrain using dynamic LOD (based on ROAM, using pixel distances as the priority function).

The terrain is generated using continous functions. For the moment, it's bicubic splines from a heightmap. Wich means that there is no limit to the theoretical level of detail.

I have to decide how the lighting is going to be applied to the map. I retained two options: Gouraud lighting, or a static normal map.

The problem is, Gouraud lighting intensifies the popping when complexity is added or removed from the mesh, also, from far away, the quality of lighting is a bit... lacking, since only a few vertices are used to render the terrain.

On the other hand, a normal map, applied to the terrain, would become quickly linear, while the terrain follows the generating function. On top of that, it would require me to do an additional pass on my terrain. And I'm already doing plenty of them. However, I save CPU time, as normals would not be needed when generating vertices. But that does not matter that much as I'm pretty much GPU bound already because of the multi-pass rendering needed to do splats.

So, Idevgames, from your point of view, wich is the best tradeoff?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Skip ROAM, it was designed for the days when CPUs were fast and GPUs were slow. Maybe it's appropriate for the GMA 950, but it's almost certainly not for any other graphics card that's appeared in a Mac since the Rage 128...

Make a few big, uniform, static meshes, stick them and their index buffers in VBOs, and call glDrawElements() a few times. Then light it however is easiest.
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #3
Whoa whoa whoa, first of all, I never said I use ROAM, that's pointless. I have a DLOD sceme with a custom algo that is inspired from ROAM.

Also, I'll have to politely disagree with you here, there is a role for DLOD algorithms. Maybe not in your application, but until you know what I am doing, I hardly see how you can judge my needs...Wacko

Secondly, I used to do exactly what you are saying, but it does not allow for what I want to do.

That said, would you have a suggestion on wich compromise you would rather see, or another way to solve the problem without rewriting my whole renderer please?Rasp
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #4
I would personally generate normals, since they don't take that much processor time to create, and you know it will follow the geometry exactly.

That said, 99.9% of the time you can be sure OSC knows what he's talking about. Unless you're terrain has massive numbers of polygons, the ability to cache the vertices on the video card outweighs the slowdown from the number of polygons. It gets to the point where it's slower to do your DLOD algorithm on the processor and send the new points rather than just drawing them all. What exactly do you do that doesn't allow the use of patches?
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #5
That's the thing, my terrain (actually, it may not necessarily be a terrain) has a continuous function, so it has limitless polygons, on top of that, it is absolutely huge, we are talking 10s of kilometres here, with most of the info kept on hard drive until it is needed.

Also, I only upload the vertices that change in a given frame to the VRAM. And that number is kept low, as the DLOD algorithm works gradually over a number of frames. I know what I'm doing here, choosing to build this algorithm was a very carefully planned decision in my engineering process.

I have absolutely no doubt that OSC knows his stuff. However, he does not know mine, and while I have no problem with him having doubts that my approach might not be the best, his certainty sounds a bit pretentious here. On the other hand, I know that every other person who posts here has no clue whatsoever on how stuff works, and giving the benefit of the doubt to everyone gets old pretty fast. For that reason, I understand his position.

As for the use of patches, I need transitions from very far up in the sky to low on the ground. From far away, there would be too many patches, so some LOD is necessary. At that point, seams become a ***** to deal with, since you need the geometry of the patches to match. That's why I went for a ROAM-like algorithm, that manages all the T-vertex avoidance, while optimally placing a given number of triangle in the whole scene. The patch notion is relegated to the generating function.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
If static VBOs aren't best, the question becomes *how* many million vertices you have?

If you're dead-set on the dynamic terrain, you've rightly assessed that you've screwed yourself to the wall with respect to normals.

If you're using a mathematical function to generate your terrain, you could potentially generate an accurate normal at each pixel in your fragment shader.
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #7
OneSadCookie Wrote:If static VBOs aren't best, the question becomes *how* many million vertices you have?

lots, and 32Mb of VRAM to work with. It has to at least work on my powerbook, and it does Grin

OneSadCookie Wrote:If you're using a mathematical function to generate your terrain, you could potentially generate an accurate normal at each pixel in your fragment shader.

I was afraid it would come down to that, it would not even be that hard anyway. I am working on a GForce4MX right now, so it's a bit of a no-no for the moment. I guess it'll look a bit iffy on older macs then, I'll stay with the classic normals in that case.

Thanks a bunch for the advice
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Normal Mapping Precision on iOS OptimisticMonkey 6 20,422 Apr 13, 2011 11:35 PM
Last Post: OptimisticMonkey
  Irrlicht Gouraud/Smooth Shading merrill541 4 5,799 Feb 3, 2010 01:13 PM
Last Post: merrill541
  Getting the Normal for a polygon. Jaden 3 5,814 May 1, 2009 01:47 PM
Last Post: Nosredna
  Vector (Normal) Map blending operations? kelvin 10 6,742 Mar 16, 2007 04:31 PM
Last Post: OneSadCookie
  drawing or displaying vertex normal shru_ani 3 3,588 Oct 29, 2006 06:04 AM
Last Post: shru_ani