• Advertisement

Archived

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

Possibly a discovery of new terrain rendering technique.

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

This came up a feew weeks ago in the OGL forums... talking about best ways to render a terrain... So a blurted out some stuff and ppl bassically called me crazy and that it wouldn't work or it would work but have no benefits, or would work but not properly... The source and executable This new technique shoudl allow you to render extremly large terrain data, over a low polygon mesh with high detail. Why high details because evry height map pixels is represented by a quad... Bassically... The height map data is loaded within an array... Then the mesh is rendered using sections of the array... So for instance a heightmap of 2048x2048 is loaded. The mesh is 128 x128 quads. Starting at corner 0,0 of the height map data, take a section of 128x128 and displace the mesh with. To get an illusion of movement, you offset within the array and displace the mesh. ppl stated this would cause shimmering I havent noticed none... The camera will be semi static... Since it will require to move the cemera up and down the heights of the terrain... Also rotation will be a problem. How to implement it? Maybe combinantion of displacing the map and trasforming the cam? Or some sort of algorythims that plucks the data out of the array rotated? Also placing the mesh or camera must be tweaked and figured out... Another issues is bounds checks will have to be done to the array, to properly displace the map... So far my implementation has an error when moving forward onto the grid. You can move backwards and side ways no problem and the terrai will wrap around infenently... This is an easy fix I guess for the top boundary... Texturmaping should be quite easy as you either new text coords can be created or the texture can be transformed... At leats i like to hope so... This should be really fast because teh polygon count on the terrain mesh is absolutly negligeable. Also it should get quite faster by using vertex buffers... a plus is also the terrain can be dynamic for deformations etc, just by modifying the height info... [edited by - ANSI2000 on January 22, 2003 2:33:17 AM] [edited by - ANSI2000 on January 22, 2003 2:39:29 AM]

Share this post


Link to post
Share on other sites
Advertisement
I stil don''t know why this is supposed to be better than the standard way of rendering terrains ( say a geomipmapped terrain, rendered in a quadtree ). The same number of triangles are drawn, well, potentially more in you method unless you use some sort of LOD.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
worked alright, however i did get some interesting side effects:



-eldee
;another space monkey;
[ Forced Evolution Studios ]


::evolve::

Do NOT let Dr. Mario touch your genitals. He is not a real doctor!

Share this post


Link to post
Share on other sites
I came up with the same idea myself, but discarded it, since it really uses the same number of triangels as any other system, requires the storage of an additional 2d mesh, and, most importantly, because of the shimmering effect (which does actually happen).

Personally, I think that a modified voxel engine is the best method. Unfortunately, it suffers from the same shimmering problems.

Share this post


Link to post
Share on other sites
Yeah, thoses artifacts happen when you move forward, eventually it will crash if you keep moving up forward from the start point... Am not doing any bounds checks on the array when I ofset within the array... I did this yestrday night. That problem can be fixed easily...

Why I think it will be faster is because, all the other techniques require to load up the entire data and render it all at once then use culling, visibility tests, lod etc...

In the this new way your always showing minimal amount of polys and if you do use LOD or something it might even be fatser... Also it allows you to have high detail, be representing each height from the height map with a quad...

This might be completly a stupid idea.... I don' t know... The only way to find out is by having ppl look at the idea play around with it and then maybe say it's a waste of time...

Terran Furry what shimering effect? You have to explain this to me? Yes your are storing the height map just like any other system, but it's the amount of polygons dispalyed that is reduced... and what additional 2d mesh? I only used one mesh.

So far my test show that with 128x128 mesh I get about 48-50 FPS and this is just using standard quads am sure I can probably maybe up it with tri strips or vertex buffers.

[edited by - ANSI2000 on January 22, 2003 10:52:43 AM]

[edited by - ANSI2000 on January 22, 2003 10:59:56 AM]

Share this post


Link to post
Share on other sites
I am fairly certain I understand what you are saying.

You are incorrect though, it is not a new technique as I've been doing that on my terrain engine for 2 years. There is not necessarily any shimmering either and I've got rotation all taken care of as well.

go here to see screenshots of it and download it if you want
http://www.planetquake.com/tdk/BlueIsle/

If you want to discuss the benefits and pitfalls I can do that as well.

[edited by - Xanthen on January 22, 2003 11:08:07 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by ANSI2000
Why I think it will be faster is because, all the other techniques require to load up the entire data and render it all at once then use culling, visibility tests, lod etc...



Huh? You need to load the heightmap for your method aswell. Also, you are quite simply wrong in your order of doing things. You test for visibility, then render. You won''t actually be rendering any more triangles at all. You never *ever* render the entire heightmap at once, well, unless it''s all inside the viewing frustum.

Can you give figures of how the system performs, with comparison against standard quadtree+geomipmapping systems?



Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Well maybe it's not a new technique, but it looks like it works...

Personally I dont have big experience with terrains... It's just an idea that cam up in my head that all...

At least xanthen got something to say. So please enlighten us on this method xanthen...

[edited by - ANSI2000 on January 22, 2003 12:58:37 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
These are the types of post I like seeing. People talking about techniques that they "discovered" and discussing the pros and cons. Yes, this is Gamedev at its finest.

BTW, no need for flames for my use of "discovered". I only meant that he discovered it for himself.

Share this post


Link to post
Share on other sites
Well it seems like it is an effecient method for culling out most of the terrain. I have not made a terrain engine based on any of the other popular methods, so I can''t say what its advantages are over other methods are. I can only say what I found troublesome and what was not.

The biggest problem I''ve found going this route is when the camara is tilted up towards the horizon, you need a very large sub mesh in order to get a good viewing distance. If you are looking down you need a much smaller mesh. So despite the fact that you can cull out 4 million quads instantaneously, you still have to cull the 16384 quads remaining to get down to what you actually need to render. If your angle of view is fixed ala warcraft 3 style, then you can get by even better off because you know where you need to render more triangles.

The second problem is you are somewhat limiting yourself to a heightmap only, and not some derivative, unless you program in multiple methods of culling out large numbers of triangles.

I guess I should say that this method seems to work well on top down games such as my demo, and rts''s where you scroll around the world quickly.

Share this post


Link to post
Share on other sites
What do you mean limited to a height map?

Uisng this way shoudl allow to stream data to the mesh... Maybe the texture will become a problem though...

Share this post


Link to post
Share on other sites
Well, you can''t have a cliff overhang without rewriting the whole engine, whereas other methods will adapt better to this sort of thing. If you know in advance you are going to only be doing a height map, then it wouldn''t be a problem.

Share this post


Link to post
Share on other sites
Arent over hangs done better by adding an additional mesh model in a 3d tool to the terrain mesh?

Well I tink I discovered what Terran Furry ment by shimer... Do you mean when you move the cameras height according to the height of the terrain it lookslike it''s shaking all over the place?

How did you Xanthen getrid of the shimmer?

Share this post


Link to post
Share on other sites
I need convincing. Personally, I see alot more cons than pros here. For instance:

- Harder to implement overhangs ( at least how I''m going to do it, using 3 heightmaps )
- Harder to implement a viable LOD
- Calculating the mesh will become a pain when rotations are concerned. Will eat up CPU time.

None of these are present in other systems ( I know I keep harping on about it - but a quadtree+geomipmapping ).

What is better in this system than others that would warrent me spending time implementing it? From my standpoint, it doesn''t seem faster, and would only bring forth adding complications and limitations.

I don''t want to sound harsh, it''s just my opinion

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
actually I use two heightmaps myself, but I didn't find overhangs any easier to implement. Like you said, I think the only way to do overhangs well is to have it modeled and placed on the landscape.

And as far as LOD is concerned it wouldn't be any more difficult than any other method. You'd simply have a second array with an LOD heightmap.

edit
now that I think about it, perhaps it would be a little more difficult than I originally thought. When you set up the world with the 128x128 mesh, you are basically saying thats all you are going to look at. If you are going to be doing lod then you are going to be looking at a potentially much larger area than that anyway, and you just threw it all out when you selected the 128x128 area.
/edit

actually rotation is completly insignificant. You just have to think about it differently.

I originally didn't have rotation in either, and thought it would be difficult to accomplish, but then I realized otherwise.

Don't think of the camara as being the location that you index into the array, but instead the focal point of the camara. To do that then, all you have to do is rotate the camara around the origin, and render the terrain around the origin

If your doing a first person point of view, I suppose that wouldn't work so well, because then you have a large amount of terrain behind you. Then again, that could be easily taken into account.


As far as how you benefit from it. Its easier to implement, so if you want to try something in a hurry, it doesn't really take much of a data structure to do. It loads quickly, as your loading an absolute minimum of data. The terrain is easily deformed, just change the value in the array and your done. And it seems quick enough to me.

But then it all depends on what you are doing it for. If your going for educational experience, you would definatly learn more from the other methods. But there are an inumerable number of things to learn, perhaps something else tickles your fancy more than bsp trees and geomipmapping, like pathfinding or terrain texturing.


As far as the shimmering you are talking about ansi2000, I ran into that too, the problem is you are tying the camara directly to a single point of a very bumpy terrain. Try averaging the terrain to come up with a height for your camara. And from there make that the destination height of your floating camara, and have it approach that height with time.

[edited by - Xanthen on January 22, 2003 5:09:23 PM]

Share this post


Link to post
Share on other sites
One more point.

If your doing it to get a job, you should know that companies don''t care how you do it. They only want to see results, and considering the amount of results you have to show before they even bat an eye, whatever works well enough and takes the least amount of time to do gives you more time to do other things.

Share this post


Link to post
Share on other sites
quote:
Original post by Xanthen
actually I use two heightmaps myself, but I didn''t find overhangs any easier to implement. Like you said, I think the only way to do overhangs well is to have it modeled and placed on the landscape.


There are many other ways of doing overhangs, some fitting far better into modern LOD solutions. For instance, using the 3 heightmap approach is easily integrated into geomipmapping.

quote:

Don''t think of the camara as being the location that you index into the array, but instead the focal point of the camara. To do that then, all you have to do is rotate the camara around the origin, and render the terrain around the origin


Ok, so you rotate your little patch around the viewpoint, making the terrain rotate. This would mean you would need a much larger patch covering a much larger area of the terrain, this is more apparent if using a first person camera, and would potentially increase the rendered geometry by 4 times.

quote:

If your doing a first person point of view, I suppose that wouldn''t work so well, because then you have a large amount of terrain behind you. Then again, that could be easily taken into account.


Basically what I said, but you can''t really take account for it, unless you split the patch up into a hierarchical structure and perform frustum tests on it, which would basically destroy the whole point of it in the first place, as you might as well put the whole terrain in it.

quote:

As far as how you benefit from it. Its easier to implement, so if you want to try something in a hurry, it doesn''t really take much of a data structure to do


I disagree, it never took me long at all to get a quadtree+geomipmapping system up and running.

quote:

It loads quickly, as your loading an absolute minimum of data


Surely, you still need to load in the heightmap, so it takes the same time as any other system. If you are dynamically streaming data from the HD, that can be done in other systems too.

quote:

The terrain is easily deformed, just change the value in the array and your done.


In a standard quadtree system without LOD thats all you''d have to do aswell. Some LOD''s complicate this, for instance in geomipmapping you''d have to recalculate geomipmaps. Since your method uses no LOD for the time being, it can be related to the standard quadtree system.

quote:

And it seems quick enough to me.



How quick is quick enough? That means nothing, reletive speeds the key. How well does this system perform reletive to others?

quote:

But there are an inumerable number of things to learn, perhaps something else tickles your fancy more than bsp trees and geomipmapping, like pathfinding or terrain texturing


Indeed, so if you were learning about pathfinding or terrain texturing, you wouldn''t bother researching on new terrain rendering techniques. I don''t see how stating that strengthens your argument...

Still not convinced. Sorry.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
no reason to be sorry.

where can I read about this 3 layer cliff thing you are talking about. I''d like to see what the results look like. I thought of this myself but I thought it would look lousy after some quick tests I did on my own, and decided to just go with two layers so I could make an underground cave.

Share this post


Link to post
Share on other sites
I haven''t actually seen any papers on it, myself and a collegue talked about the concept for a while. Basically, you have a primary heightmap that defines the world. You can then, optionally, have two other heightmaps ( lets call them B and C ) that define complexities ( overhangs, caves etc ). You calculate the... Intersection IIRC of B and C, then render it ontop of A. The intersection of B and C will produce the profile of the overhang you desire. If B and C are chosen correctly, then you can produce decent overhangs and caves. I haven''t implemented this yet, but it''s soon on my things-to-do list. Once I have, and if it works well, I think I might write and article on it, as I haven''t seen any around.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Yeah. But you can make it look better than that. That looks... Too... Hollow if you know what I mean. Using 3 heightmaps gives you a thickness to the ceiling of caves and such.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
Well, I decided it wasn't worth putting the effort into it.

There are a couple problems I see with this approach, which is why I gave up with it and went with just a hole in the ground and then modelling a cave entrance and putting a "cap" on it.

The first is it takes an enormous amount of effort to model a cave entrace using heightmap editing techniques. This cave entrance alone took me probably 30 minutes to an hour. Granted it could be made easier, using a tool more tailored to it, it would still be clumsy compared to modelling it in a modelling package.

The second is how would it be textured. If you are going to use the technique you use for the rest of your ground its going to look bad, if you are going to have some other texturing method, then, once again, it sounds more like a model then part of the terrain and would probably look better with a cap.

Third heightmapping usually has a uniform spaced mesh. And even if you make it deformable (which mine is), in order to get the required polygons you would have to pull the terrain from all around to the cave entrance. And this requires a lot of work.

I wish you the best if you want to try it, but I really doubt what you are thinking will work, and thought I would maybe save you the trouble of finding out on your own. Especially since I thought of what I think is basically the same idea and have already attempted to make it work, and realize the difficulties with it.

[edited by - Xanthen on January 22, 2003 6:34:06 PM]

Share this post


Link to post
Share on other sites
Xan you wouldnt happen to have a source sample of your terrain engine or at least of the techniques we talked baout so far? Would yeah?

Thanks

Share this post


Link to post
Share on other sites
Hmmm.... I feel I can resolve the other issues. Stitching the two heightmaps to the terrain is easy enough, thats barely a problem at all. The texturing... I don''t feel is that much of a problem to be honest, nothing I couldn''t sort out. The generating of the heightmaps themselves... Now, that is more differcult. You have a good point there. Still, with a few tools, I reckon I could make it a passable chore.

Ok, I''m going to start this pretty soon, say within the next couple of weeks. I''ll let you know how I get on ( You''ve got me interested in it again! ).

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
quote:

Ok, I''m going to start this pretty soon, say within the next couple of weeks. I''ll let you know how I get on ( You''ve got me interested in it again! ).



I''m sorry cause thats the exact opposite of what I was trying to do. Ultimatly its a crappy idea. No need to feel like I''m flaming because I had the exact same idea and had to try it myself.


Ansi2000 I would but I''m still looking for a job, and until then I want to keep my source to myself. If you want to ask a question I''ll answer but beyond that, I''m going to have to say no. Hopefully I''ll be hired in a month or 2, I know things are looking good right now.


Share this post


Link to post
Share on other sites

  • Advertisement