Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Captian Goatse

Triangle reduction in LODs (in practice).

This topic is 5545 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

I have started to play around with different kind of triangle reduction techniques and read a megaton of material concerning the topic. Papers are all great, however, they fail to tell me how to reduce triangles in practice. The common method around is to start from previous implementations and "modify" the code to suit your own purposes. Threads I've seen in past tend to go like this: "I want to implement level of detal x?" followed by answer "Yeah, clod is working really great for me, go for it d00d". "O wait what the papers don't give enough information..." Now, as far as I undestand, a method similiar to binary triangle trees is one of the best way to reduce the terrain. I understand how it works in theory, but in practice it is little bit harder especially when in implementation. BinTriTrees: -Should I calculate multiple levels of bintritrees for the terrain? -How do I incorporate them with the indices, so that there is an actual visible difference? -How do I make the keypoints of the terrain, such as hills to show, so that when I build my indices based on the reduced level data I know what points are truly visible? I'd still like to maintain a global array of vertices and only adjust the indices, since it seems to be the simplest way to go around. Indices: -Should I generate unique set of them for every "patch, or quadtree node"? Doesn't this turn into overkill memory wise? -Should I calculate them on the fly? I can't see this working. -Now the easiest and way to reduce triangles would be through adjusting the indices. This also seems to be the simplest so I will venture into this direction. I think I have the error adjustment down pretty well, after all thats 90% of the papers talk about. I'll now start to manually reduce the triangles of a small heightmap 20 x 20 and see what happens. The main way I'll adjust the triangles will be through the distance from the patch center to the viewers position. I see, I seem to be talking about some sort of clod algo. I guess I have to build indices only once for each subdivision level. [edited by - Captian Goatse on August 16, 2003 11:15:43 AM]

Share this post


Link to post
Share on other sites
Advertisement
If i remember correct, ROAM uses Binary triangle trees.
There is an article on Gamasutra about ROAM, and it has a simple implementation with it. If you haven''t looked at it yet, then it might help you a little. It isn''t as great as it should but it''s a start!

I''m new to terrain rendering and lod algos. For start, i''m trying to implement Monstrous''s terrain rendering article. I think it''s easy. For more advance techniques, i''m sorry i can''t help you.

If the above didn''t help at all, at least this post hasn''t gone to the bottom!!! I''m interested in this kind of info too, you know.

HellRaiZer

Share this post


Link to post
Share on other sites
My biggest problem right now is that I can''t decide whether I should do unique indices for each nodes or go for general indices that are common to all nodes sort of like

unsigned int[maxLod][maxIndices];
int numIndices[maxLod];

Chunked lod also grants the possibility to render with parent nodes if for example there is water or something so there would be absolutely zero overhead for doing that.

I think I will try with common indices. Even if it doesn''t work it is worth of shot.

Share this post


Link to post
Share on other sites
Sorry for disturbing your peace, but i have a little question!

If i understand correct, your lod implementation has an update function which decides which indices must be rendered, by storing them in an array, and a render function which renders them. My question is, why you want to store the indeces in an array?? I mean, Rottger''s matrix, can be used to setup a quad tree, and then, without storing the indices to an array, you can render the quad tree. With no memory limitations! Just walk the tree, and render the fans or strips.

Your implementation (Binary Triangle Trees) can''t do that?? (I said i''m new to these stuff, so the question is real!!!) Why do you have to store the indices in an array???

And something more. I see that you are familiar with the demo i said earlier. What is wrong with it?? Why terrain''s resolution changes, despite the fact the camera stands still?

Thanks for the attention, and forgive me for posting my questions to your thread! I tried to ask those things in the past but nobody answered!!!

HellRaiZer

Share this post


Link to post
Share on other sites
quote:
Original post by HellRaiZer
Sorry for disturbing your peace, but i have a little question!

If i understand correct, your lod implementation has an update function which decides which indices must be rendered, by storing them in an array, and a render function which renders them. My question is, why you want to store the indeces in an array?? I mean, Rottger''s matrix, can be used to setup a quad tree, and then, without storing the indices to an array, you can render the quad tree. With no memory limitations! Just walk the tree, and render the fans or strips.

Your implementation (Binary Triangle Trees) can''t do that?? (I said i''m new to these stuff, so the question is real!!!) Why do you have to store the indices in an array???

And something more. I see that you are familiar with the demo i said earlier. What is wrong with it?? Why terrain''s resolution changes, despite the fact the camera stands still?


If you mean building quadtree run time then I msut say that it is hard to make an implementation with it that isn''t slow. I''m not saying that it isn''t possible, but I''ve found it easier this way.

The indices are for vertex arrays/vertex buffers so I don''t have to mess around with calls like glVertex3f also it is supposed to be a lot faster this way if extensions are supported.

In the demo I think the adaptation changes because the spinning triangle is supposed to demonstrate a position or something like that.

Anyone got ideas on the Rötger quadtree? I''m not sure if I fully understand what hell is saying.

Share this post


Link to post
Share on other sites
You are right! I haven''t thought of vertex arrays so far, because i''m trying to make it run first. Then i''ll try to make it run fast!

About Rottger''s algo, the tutorial i mentioned earlier by Monstrous (i don''t remember author''s name!) is a good start for understanding it. Give it a try. With his source, and Rottger''s paper i''m close to good results. If you really want to know more (at least what i understood from it) i''ll try to post some code. The main idea is based on the above source, but i don''t keep the array for the fans (see tut.). It is working fine for now, even with a 512x512 terrain and a 1024x1024 texture applied to it, the frame is around 250. And my machine isn''t the best around. Duron 700MHz with GeForce DDR!!!

HellRaiZer

Share this post


Link to post
Share on other sites
Going with one set of indices seems to be the way to go. At least for now. This way I''m able to make more levels, I will probably use 8 so that really close is
10 per 10
10 per 14
10 per 18
10 per 22
10 per 26
10 per 30
10 per 34
10 per 38 and when really far away.

The way I''m building indices now is really flexible and Good since once it is far enough, it will build almost two dimensional horizon with the highpoints and lowpoints. With textured shading I''ll hopefully make the resolution drop seem less obvious.

Basically it just fetches the hight/low points of the bounding box and then builds the horizon based on them.

Share this post


Link to post
Share on other sites
Are you using occlusion culling?? Can you describe your algorithm, in general lines?? I''m way to far from reaching you i think, and all my previous postings are crap!!!

If you can, then describe the steps in your algorithm. No code, if it is not needed!

Thanks!

HellRaiZer

Share this post


Link to post
Share on other sites
Sorry if I gave the wrong impression. I''m not using occlusion culling and I''m not going to implement one any time soon. I''m building a third person shooter and I''m afraid occlusion culling would be overkill.


I''m using brute force frustum culling thats all.

Find paper Zhang[98] He has really fine technique, which I''ve seen implemented at the digital dawn engine(???) correct me if I''m wrong.


I''m pretty sure you can start from there.

Share this post


Link to post
Share on other sites

  • 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!