Jump to content
  • Advertisement

Archived

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

ANSI2000

Possibly a discovery of new terrain rendering technique.

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

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