I''ve been looking around at the current crop of landscape engines and non of them are really focused on what I want to do (or they are slow or look ugly). So of course like a doe in a cars headlights I decided that I should just code by own. (Besides it''d be cool ...) Frankly, nothing in the game I''m producing has scared me as much as considering doing my own graphics engine. So I''ve a few questions for anyone who may know better than me. - Is it all really that hard? I mean I''m pretty impressed with some of my other code and am feeling increasing more confident by the day. I, however am sadly lacking in mathematical skills. Basically high school was 10 years ago, and though I''m smart I remember almost nothing of it. -My plans are for an outdoors terrain engine that treats both the hilly terrain and buildings the same way when it comes to visibility culling. So a flat wall should block the hill behind it. My vague idea is to use a combination of a polygon and raytracing engine. The raytracing would determine what is visible and what is not. I was planning on using the DDG toolkit as my guide with portions of flightgear as inspiration. I''ve read the Filpcode tutorial and have read some other basic data on voxel engines, which I think would be the best choice for vis culling. For polygon drawing I was going to use opengl. Does anyone have and information or link they think I should know about before embarking? My goal is to have high terrain + structure integration with an unlimited viewable distance (or at least not a typical fog out, cop out). What things should I know well before hitting the keyboard? Should I develop a bunch of small test apps , if so what should they do? I''m still trying to understand what the important consideration are. I want to do this the right way... Many thanks. Chris ''gimp'' Brodie

The best place for all your terrain programming needs would be at the Logbow Digital Arts message boards.Goto:

http://www.longbowdigitalarts.com/ubb-cgi/Ultimate.cgi

and post your questions there.You''ll get tons of help.

You gotta learn recursion and know it cold.

There are three kinds of programmers. Those who don''t know recusion, those who think they know recursion, but don''t, and those who know recursion.

Make sure you''re not one or two. I suspect quite a few fall into category two.

I hated math in high school. I blew it off. Bite the bullet and learn it.

Errr...

Well... the idea was that as my experince grew the scope of the engine would grow. Initially I just want a nice looking terrain that''ll allow me to drive a tank off in to the distance until it''s just a little blob but still see the blob. Then I''d add trees\domesky. Buildings were going to be added. Initially I was just going to get ddg and add model support and use that but without building a full engine myself I don''t think I''d be able to work out how modify it anyway.

So, yes, eventially I''ll need a portal engine. My background is Q2 mapping so I have quite a good head for how the portal engine should work\be used. I''m not entirely sure of how the two would be integrated however.

I''m not above just ripping of PD code and using that but I''d really have to understand what someones code does before I''d use it. I''m currently playing with SimpleROAM which I found at Longbow. It looks like a fairly simple example to start with...

At some point I''d get to a point where I''ll be wanting to place non heighfield things in my levels like portal based area''s. In these area''s I''ll have to use some kind of interior engine and the ability to simple produce maps(in photoshop) disappears. Rather than waste my time creating my own editor are there any free, open, editors that use some kind of standard for me to confirm to? Or should I just do as everyone else does and just use .map format and use a quake editor(despite the fact that it cant load the actual terrain heightmap)

Thanks

gimp

Kill -
u cannot use BSP trees for a landscape engine.they simply arent very effecient.u would be better of using Quad Trees.BSP trees are for shooters.

shooters can be outside... bsp is for when many obstructions such as walls will be around

Im Always Bored
--Bordem
ICQ: 76947930

I always make my editor first.

The 'engine' for the editor is sort of a try out for the game engine. (At least for the graphical part).

You see, this is my first 3d project I'm working on and I use the editor to try out all the techniques I'm going to use in the game.

Now after a few days of programming I realize I should have done that different or I see that there is a better way of doing something. Only I've come so far in development that it would take ages to fix it.

So I leave the unperfect code alone and write down what should be done better.

This way I'll have an engine that can do what I want it to do.
It just hasn't got the best code.

Then when the editor is finished I'll re-write the whole thing (read: "copy code from the other engine") only it will be better since I'll get all the mistakes out.


I don't know if this is the best way for doing things
(I'm quite sure it isn't).
But I hate writing everything to paper first.

The Rock
-BAD software-


BTW, if you want to see my editor. I've got some screenshots in the current projects section.


Edited by - glROCKs(); on July 20, 2000 3:49:00 PM

Thats actually quite good Rock, how long did it take to learn to write your engine?

Right now I''m flipping between modifying DDG and writing my own engine. The main reason right now I guess is that i''d really want the satisfaction of doing it myself..., of course I don''t want to spend the next year writing something that''ll be totally sub par, so, how long did it take you?

gimp