This topic is 2 pages long:   1  2  |
Author Topic:   Anyone have questions/projects to discuss, etc?
Bryan T
Member
posted April 21, 2000 03:10 PM            

Hey, I know I'm not the only one who watches this board. Who else is out there and do you have questions to ask or projects to discuss?

I'm currently working on an object oriented Networking engine similar to Unreal. Should be neat, infinite number of objects, infinite clients, and drop-in compatable to games that are written to support updates unreliably (through UDP).

--Bryan

IP:

Effin Goose
Member
posted April 21, 2000 09:31 PM            
Hi Bryan

Just thought I'd let you know that your not the only one who watches this board While I'm not actually programming anything recreationally at this point (uni and work keep getting in the way what little spare time I have I've been programming a small terrain based game engine. However I've lately been trying different alternatives to heightmaps, such as parametric bezier surfaces and stuff, because of the fact that in a really large landscape, say 20 km by 20km, a height field could take up 400mb. The problem with bezier's however, is its a lot harder to do things like canyons. I dont suppose anyone else has thought of this?

Ryan

------------------
I dont like it, and Im sorry I ever had anything to do with it
- Schrodinger

IP:

CheshireCat
Member
posted April 22, 2000 12:23 AM            
In my spare time I'm working with a few people on the net to make an outdoor puzzleish game. I'm working on the LOD scheme for the arbitrary meshes right now (I'm using a fixed order progressive mesh thingy, and use view distance to pick the number of active vertices. I evalute the error during simplification using the "quadric error metric".), and having a bit of tricky time figuring out how to properly deal with texture coordinates during simplification.

Discovery of the day - don't use the quadric error method on models that have features that come to a long, perfect point - add at least one face to the end of them. They get destroyed pretty quickly otherwise =]

Jason

IP:

CheshireCat
Member
posted April 22, 2000 12:43 AM            
I wouldn't think that for the same amount of detail, bezier patches would take up any less space than the heightfield...

Perhaps, if you're worried about memory problems, you could carve up your terrain into a grid, and use a progressive mesh for each block - using some method to stitch together differing LOD blocks (an interesting idea I saw somewhere was to have some amount of overlap of the edges between the blocks, and just render them without stitching. I haven't had a chance to try it yet though.). That way, all of the distant terrain would have a very small memory footprint. Since the vertices are stored in order of apearance in the increasing levels of detail, you can just load up the additional vertices when you need them, and trash them when you don't.

Jason

IP:

Michael P. Welch
Member
posted April 22, 2000 05:11 PM            
I keep an eye on these programming boards as well.

I'm really more of an artist and designer than I am a programmer, but I seem to write a ton code anyways. For instance, I just added high color support to my 2D game engine. As dull as that sounds, it took 2 weeks worth of free time to handle all the new blitting techniques, asset management changes, and color format recaching issues.

Now my engine is on par with DX-Ball 2's engine, which is a year and a half old.

I'm all finished with the update, so now I'm moving on to mastering Blender and The GIMP. Making art will be a nice change of pace.

If anyone wants to chat about cross-platform game development and coding on Linux/Windows/Mac, I'll be here. I may even need some tips on OpenGL in the near future. Learning to work in the 3rd dimension is my next big step.

-Mike

[This message has been edited by Michael P. Welch (edited April 22, 2000).]

IP:

Chris C
Member
posted April 22, 2000 06:18 PM         
My situation is similar to Effingoose's... too much work at uni - luckily it'll be all over for good soon! Even so, I do still watch this board.

When I grabbed some spare time recently, I implemented a skydome coloured using the realistic sun and sky colour model detailed in the paper "A Practical Analytic Model for Daylight" by A.J. Preetham et al. It produces very impressive sunsets and sunrises even with a quite a low poly skydome.

You can take a look at the paper at http://www.cs.utah.edu/vissim/papers/sunsky/
if you're interested. There are a few gaps, but I managed to track down and work out enough of the details to implement it successfully. If anyone is interested, let me know and I'll pass on the details to save others the pain of trying to get it to work!

Other quick thoughts:

Bezier patches are good for smooth terrain and will take up less space than an equivalent height field (patches will provide infinite smoothness to any level of detail), but having terrain with rough features (such as very steep hills/cliffs) will be difficult to model due to the difficulty in maintaining surface continuity between patches.

'Adaptive' quadtrees seem to make sense for vast terrain - I'm sure it would be possible to modify the ROAM algorithm to work in a similar fashion. With this system 20kmx20km maps become feasible, although the maximum level of detail between areas of the maps will vary - procedural detail may save the day if this is an issue.

Happy coding,

Chris

IP:

Cthulhu
Member
posted April 23, 2000 02:18 PM            
I visit here daily. Not too much messages lately, though. I'm working on a game project with couple of friends. It's something between Close Combats and Jagged Alliance and uses 3d ROAM engine (doesn't fit so well but I don't have time to write quadtree engine).

IP:

MarkBatten
Member
posted April 24, 2000 08:51 AM            
I, too, check this site daily, mostly because of interest in terrain engines. There are two features of ROAM I haven't been able to implement: frame coherence and dual-queue. Seems like most people skip these as well. Anyone done them successfully?

(Also, what happened to most of the old topics?)

IP:

Bryan T
Member
posted April 24, 2000 12:54 PM            
Large Terrain Discussion:
/forums/archive/ubb/Forum3/HTML/000046.html

This was a discussion Seumas had good input on. Because my model has to support a near-infinite landscape, his model differed quite a bit. It was an enlightening discussion and may help with your projects.

That sky paper looks really good, a perfect addition to a terrain engine. How much processing does it take up?

I don't notice any missing topics.. did you do a search? Perhaps they just dropped off your active list (last 30 days, etc).

--Bryan

IP:

Chris C
Member
posted April 25, 2000 04:18 PM         
Regarding the realistic sky algorithm - processing time is proportional to the number of sky sample points, or in more practical terms, the number of vertices used to make up the sky dome. Although the maths is fairly complex, the results are excellent even when using a small number of points so computation time can be reduced simply by using a low-res sky dome. Another bonus is that the sky colour only needs to be recomputed when the sun changes position.

To implement the atmospheric haze (ie. distance based fogging) as defined in the paper, real-time speeds are very unlikely - the colour of distant objects depends on the view direction (so it correctly blends in with the sky) and requires a lot of processing time. Of course, there's probably a way to hack up a simpler model that does a similar thing but a lot faster! That's what graphics coding for games is all about...

Chris

IP:

Kaeto
Member
posted April 25, 2000 04:23 PM            
I come here often, just to look at what others are doing... Right now I don't have any projects because I'm so busy with school and I'm lazy

IP:

Klaus Hartmann
Member
posted April 26, 2000 09:06 AM            
I'm also here, and I check the board about twice a day.

I'm currently working on several projects (in parallel :-(, but unfortunately, I'm not at liberty to discuss them. But I can tell, what I'm doing in my sparetime...

Whenever I find some time, I try to better my knowledge about math and 3D algorithms. This is just stupid, because I learn so much about so many algorithms, but I don't have the time to use them in a real project.

Anyway, I think we need a new thread on this board. A terrain related thread would be nice, because most posts have always been about terrain. On the other hand I'm beginning to become tired of discussing LOD algorithms... it takes more than just a LOD algorithm to create a nice terrain engine. Here are a couple of things I'm particularly interested in:

[1] Grid Tracing
This uses a modified Bresenham algorithm to trace a ray through a height field, and then finds the first intersection. This is useful for many things. For instance, it can be easily used with a ray-tracing algorithm, which allows us to ray trace surface textures. Another obvious use would be collision detection (e.g. missile hits moutainside).

[2] Surface texture synthesis
I'm pretty familiar with this, but I still have some unresolved problems. For example, I'd like to be able to compute "relative elevation effects". The most obvious use of this is to let a river flow through a landscape, because the flowing-direction of the river depends on the relative elevation. This is, as I said, the most obvious use, but you can do much more (and far more interesting) things with relative elevations. For example, you can have "tongues" of snow flowing towards a valley, and such things greatly improve the realism of a surface texture. The only problem here is to compute the relative elevation... a simple "elevataion1 - elevation2" won't work very well.

[3] Real time texture synthesis

[4] Disk paging for height field and texture data

[5] Streets, paths and the like
A network of connected lines (actually thin cones) with certain properties could be used to modify a height field so, that you have streets, mountain paths and whatever.

[6] Sky domes
Using the method Chris Cookson told us about.


... and there's still much more we could discuss.

Niki

IP:

Bryan T
Member
posted April 26, 2000 03:54 PM            
Klaus,

Sounds like a great idea, I'll put up a few topics. If there are some other topics people would like to discuss, please add them. We seem to be a stimulus-response crowd here...

--Bryan

IP:

JamesC
Member
posted April 27, 2000 01:05 PM            
I'm new to this board but not new to Seumas's work... GREAT artical on gamasutra Bryan, I'm just getting into terrain rendering and you can't imagine how much it has helped. I think I have some questions for you 8) but I'm going to check out some of the other posts first and let them sit in my head for a few days and see if anything clicks.

IP:

Bryan T
Member
posted April 27, 2000 09:08 PM            
JamesC,

Glad you liked it. I've gotten some really positive feedback and some fascinating discussions. Please don't hesitate to ask questions, although a quick search of this forum may yield you an answer faster.

--Bryan

PS: Doh! Can't spell without a spell checker!

[This message has been edited by Bryan T (edited April 27, 2000).]

IP:

JamesC
Member
posted May 08, 2000 01:58 PM            
I'll start with a basic question for ya Bryan... I figure it would be smart for me to post questions here so other newbies terrain questions might get answered in the process... What is the purpose of loading an extra row above and below the map? Its commented as an optimization but I don't see where its any use... but of course I'm not familiar with the .raw format either.

IP:

Bryan T
Member
posted May 08, 2000 02:23 PM            
JamesC,

Hehe.. That's a cheesy way of getting rid of the need for bounds checking. In the code, the first row of the .RAW file is copied into the empty extra row at the bottom of the map. Then the last row of the .RAW file is copied into the empty row at the beginning of the map. Thus rows 1 through LastRow contain the data in the .RAW file, while row 0 and row LastRow+1 contain copies of the last and first rows.

This allows the code to use y+1 and y-1 indexes to access the Height Map without needing to check for y==0 and y==LastRow each time. A significant optimization considering the number of times this check is applied.

The 'correct' method of fixing this would be to create a border for the map of at least one pixel. Then the displayed part of the map would simply ignore the border.

Did that make sense?
--Bryan

IP:

JamesC
Member
posted May 08, 2000 02:41 PM            
yup, all is now clear.. as for the rest... more questions to follow as they come up. Thanks for the help.

IP:

JamesC
Member
posted May 09, 2000 04:07 PM            
Now some questions on variance for ya Bryan. I have read over all the posts on the subject but I'm still lost... I'm sure this will make me look stupid and I'll go duh! since everyone else here seems to just "get it" but I'll post anyway. BACKGROUND: I understand how variance is calculated (midpoint of the hypotenuse of the tritreenode). I understand from back in the data structures days how to make a binary tree out of a sequential array... What I'm getting is that if the variance is over a certain amount (and that the amount changes based on how close to the camera you are) then that node needs to be split. Now, as for where I'm lost... how does the variance tree get used in deciding what the variance for the current tritreenode is? Is each level of the variance tree used for a different LOD level?

IP:

Bryan T
Member
posted May 09, 2000 07:56 PM            
Excellent question. I glossed over a lot of details about Variance in the article (ran out of space). Let me see if I can clarify it for you.

The ComputeVariance() function follows the same Binary Triangle Tree splitting that would be done if the full mesh were to be rendered. When it reaches the bottom of the tree, it calculates the 'error' or 'variance' of all those little triangles.

Then it steps back one level, picks the biggest 'error' of its children or itself. Each step back, it also stores this data in the Variance Tree - just a Binary Tree that doesn't have the triangle concept attached to it.

Each level in the Variance Tree is equal to one level of the Binary Triangle Tree, each node in the Variance Tree equals one node of the Binary Triangle Tree.

Now, during Tessellate(), the distance to the eye and the variance are taken into consideration in an equation. This is the Split Decision, a very important part of the Level Of Detail for ROAM.

Now add some complexity to it: The bottom few levels of the Variance Tree are simply chopped off to save space. This means that when tessellating, the algorithm will follow the Variance Tree down to a point, then if it splits again, it will continue to split all the way down to the lowest allowed detail level.

Did the answer to your question fall out of any of that?
--Bryan

IP:

jester
New Member
posted May 10, 2000 09:31 AM            
Bryan,

I thought that while the subject of variance has been raised I'd add my 2 cents worth.
In your code you say that the method for calculating variance was very slow and that better ways were required. What are these methods? or is this still an area of debate?

Cheers,

Ben

IP:

Bryan T
Member
posted May 10, 2000 10:20 AM            
Jester,

This is still an area of debate. If you come up with any good ideas, I'm all ears!

I'm currently in the process of learning Jonathan Blow's Hierarchical Sphere splitting system. This is based on the idea that when you enter a three-dimensional volume (a sphere) around a piece of terrain, it needs to be split. When exiting that sphere, you need to merge.

Additionally, spheres embedded in spheres would not have to be checked unless you move within the 'bounding' sphere of that level. This eliminates a lot of the Split Decision processing being performed by split/merge ROAM.

Beyond that, it would be nice to deform the terrain in real-time without any major frame hits for recalculating the variance. I'm not sure how fast it is to recalculate the sphere tree, but it could probably be made efficient.

Check out his paper at http://www.bolt-action.com in the downloads section.

--Bryan

IP:

JamesC
Member
posted May 10, 2000 11:02 AM            
Yea I *think* it answered my question. Well I at least now know pseudo-wise how the roam algo works... now I'm just going to pick the little details of your code apart, convert it to d3d and expand on what you have already done. Time for frustration level 2! Textures!

IP:

jester
New Member
posted May 11, 2000 08:48 AM            
Ported Bryan's ROAM to Java. http://thor.cam.ac.uk/~jbgh2
Shows how it works quite nicely (unfortunately at present in 2D)

Any comments/suggestions/ideas please mail me.

IP:

Bryan T
Member
posted May 11, 2000 03:18 PM            
Muahahaha! My master plan is working, soon everyone will know the ways of LOD Terrain rendering - and then I'll actually get to PLAY some outdoor games!

Nice demo Jester. Toss in that 3rd Dimension and let's see an update.

--Bryan

IP:

This topic is 2 pages long:   1  2