"Tiki's Garden" (Real-Time Outdoor Terrain Engine) [NoteMe, Electroman]

[NoteMe]

I just had to use that thread title...

- So have you got the book now?
- How should we do it?
- Should we write some kind of game design docs first, tech docs?
- Should we find out what we should add to the project now?
- Or do you want to read the book first?
- Should we make an iteration plan? Should we ...ehh...I forgot what I was supposed to write..


Sorry for making this thread. But I can't get a hold of you....


- Got it now...are we going to make a web page about it?

ØØ

[manavo11]

What? You are making something and thinking of leaving me out of it?

[NoteMe]

You can probably join if you want...If Electroman like your C++ and DX9 skills you are probably free to join...

[manavo11]

Excellent I don't know sh*t

[NoteMe]

Then you are out...and keep away from this thread...

[DiGiTaIErRoR]

DX9?! WHY WOULD YOU USE THAT?!

Now... OpenGL

[manavo11]

Originally posted by NoteMe
Then you are out...and keep away from this thread...

[Electroman]

lol, I think I've lost count of the amount of threads with my name in them in this forum. (I shoudl be the mod in here to brad )

As for plannign it I was thinking of documenting it all first, class diagrams and stuff. We will probably need to read some of the book at least first so we know what we're doing.

I haven't got my copy yet, its estimated to arrive about the 25th so about a week and a bit.

I choose the free delivery and 5 year witing list . I think its the book I got with it thats holding the order up .

Couldn't get ahold of me: tut tut , I've been at work. Stuck in an office for the last 10hours staring out the window and the nice sunshine .

This is going to get mighty confussion for me soon. In september I have to learn how to use the GameCube graphics system (which is similar to OpenGL) and I am still tryign to get Dx9 round my head, well it seems a lot similar to older version of Dx so doesn't seem too bad.

[cyborg]

What are you making? A game? What type of game?

[Electroman]

Its a 3D terrain Engine, I don't know if you've noticed but Note posted a few threads a few weeks ago (about the time of the giant BSP tree thread )

[cyborg]

Yeah...I noticed that thread...

Are you going to use it for a game or is it just for educational purpose?

[Electroman]

Posted by cyborg
Yeah...I noticed that thread...

Are you going to use it for a game or is it just for educational purpose?

I have ideas for possible game uses (and I think Note does too) but we will be making it to be just a general Terrian engine which people with games ideas can just include it in as a module. I suppose it will be rather a lot for educational purposes mainly though.

[NoteMe]

Originally posted by DiGiTaIErRoR
DX9?! WHY WOULD YOU USE THAT?!

Now... OpenGL

Give me ONE good reason for using OGL...

[NoteMe]

Originally posted by Electroman

As for plannign it I was thinking of documenting it all first, class diagrams and stuff. We will probably need to read some of the book at least first so we know what we're doing.

I am in on documenting it all first. And if you don't mind I think it is a good idea to make an itteration plan. So we don't get 10000000 million lines to write before we can see something done.

And yeah we should probably waith to we get the book to write all the docs. But I know at least some things we can plan before it.

- Like if we are going to have a rendering quee.
- If we are going to have diffrent camera views, and in that case, what kind of camera views.
- If we are just going to add the terrain, or if we are going to add trees and rocks.
- What about wather?
- And what about a typical DX skybox or skydoom (SP?) or what it was called again.
- If we are going to have a menu, or just go straight to the terrain
- And one thing we have talked a bit about...are we going to have fixed terrains, or random, and in that case, how can we switch between them.
- How can we move in the terrain, are we using DI if we can move
- Are we adding moving things to the terrain, like a walking man?


A lot of ideas here...

- Things like what algorithm to use for the terrain can be hard to deside before we read more about it, but I guess we will land on some sort of ROAMing anyway...
- How we are going to render the tiles is also hard to know in the begining. But we figgure out things like that in some weeks/months/years...D:D:


What do you think?

[NoteMe]

Originally posted by cyborg
Yeah...I noticed that thread...

Are you going to use it for a game or is it just for educational purpose?

Yup, as Electroman said, we are aiming at a terrain engine first. I suggest that will be Version 1.0. And then if that was easy...something I don't think it is. Then we can see if we are going to add more things too it.

[Electroman]

Posted by NoteMe
But I know at least some things we can plan before it.

- Like if we are going to have a rendering quee.
- If we are going to have diffrent camera views, and in that case, what kind of camera views.
- If we are just going to add the terrain, or if we are going to add trees and rocks.
- What about wather?
- And what about a typical DX skybox or skydoom (SP?) or what it was called again.
- If we are going to have a menu, or just go straight to the terrain
- And one thing we have talked a bit about...are we going to have fixed terrains, or random, and in that case, how can we switch between them.
- How can we move in the terrain, are we using DI if we can move
- Are we adding moving things to the terrain, like a walking man?

I'll try and answer as most of these to what I think would be good:

For the randomly generated I think if we build the terrian engine so it accepts a certian format (maybe a highmap, or a more sophisticaed type) and the enigne doesn't know how it was created. Then the program that we write to demonstrate the engine could have a menu system and one option would be whether the terrian is random or from a file.
This would lead to some of the engines main functions being:
- LoadTerrianFile()
- LoadTerrianData()
- ClearTerrianData()
- CreateFlatLand() - This I'm not too sure about but would be good for debugging. Would just fill our terrian data with a constant height.
- SaveTerrianFile()

I think the terrian should be dynamic at run-time though. There should be a data-structure that can define what the land should look like but this should be editable to like take chunks out (explosions, or possibly add land as well).

I don't think the lightmap (using the 3 seprate colour channels) would be enough to describe the shapes we might be after.

For the weather system I recon thats a great idea but will probably be better for the demo project then part of the engine. But the more I think of it the more it might work better being part of the engine. Like if theres rain then if its in the engien itself it would be easier to create slashes as they hit the ground. Or even snow, we could alter the textures grandually as snow falls? What you think?

As for the shybox I guess we may aswell just include it in the engine, makes it easier for any user

The walking man and Billboards would be managed by the demo project.

The moving thing: Yeah we would use DInput but that would be in the demo project, The engine would have functions like:
- SetCamera()

Some other functions we will probably want:
- Process()
- GetHeight(X,Y) - This might be harder than I can think at the moment if there is multiple heights at any point.
- IsInsideTerrian(X,Y,Z) - Given a 3D coordinate the engine should be able to work out if this is inside the land or not.

Not sure what you meant by different camera views? was it like multiple cameras? If so that could be a good idea and we could have an option to turn off the landscape culling on them. This way you can see how the detail is only put into where the camera is pointing, this is more of a debug option I suppose.

And for the render queues I think your better at that cos I havn't read anything on it yet .

Let me know what you think of these .

[NoteMe]

Originally posted by Electroman
I'll try and answer as most of these to what I think would be good:

For the randomly generated I think if we build the terrian engine so it accepts a certian format (maybe a highmap, or a more sophisticaed type) and the enigne doesn't know how it was created. Then the program that we write to demonstrate the engine could have a menu system and one option would be whether the terrian is random or from a file.

I think it would be a great idea to have a menu actually. If we are not going to have a random terrain, then we could make a simple terrain editor in VB or something, where we can "draw" some kind of heightmap (have to get back to how it should be done, but I think that the over hang might be a little bit out of our league. Becuase you can't show it in a 2D model that easy.). And then we can load the desired map we want. And it can be easy to make levels for a game using the engine.

Originally posted by Electroman

This would lead to some of the engines main functions being:
- LoadTerrianFile()
- LoadTerrianData()
- ClearTerrianData()
- CreateFlatLand() - This I'm not too sure about but would be good for debugging. Would just fill our terrian data with a constant height.
- SaveTerrianFile()

Yeah most of these functions have to be in the engine. What else, and what we don't have to add, is easier when we find out what we are going to add.

Originally posted by Electroman

I think the terrian should be dynamic at run-time though. There should be a data-structure that can define what the land should look like but this should be editable to like take chunks out (explosions, or possibly add land as well).

It sounds really nice, never thought about that before. I am afraid that it will use a lot of time to edit a big buffer like that. But if the book provides us with some solutions to split up the terrain in a grid like system, then it might not take that much time to perform. Keep this idea in your head.

Originally posted by Electroman

For the weather system I recon thats a great idea but will probably be better for the demo project then part of the engine. But the more I think of it the more it might work better being part of the engine. Like if theres rain then if its in the engien itself it would be easier to create slashes as they hit the ground. Or even snow, we could alter the textures grandually as snow falls? What you think?

Never thought abou that either...just wanted to add a sun in the skybox, and maybe add a lens flare using VS and PS to the camera...

Originally posted by Electroman

As for the shybox I guess we may aswell just include it in the engine, makes it easier for any user

Thanks...and BTW it's a SKYBOX...

Originally posted by Electroman

The walking man and Billboards would be managed by the demo project.

Sounds good.

Originally posted by Electroman

The moving thing: Yeah we would use DInput but that would be in the demo project, The engine would have functions like:
- SetCamera()

.......

Not sure what you meant by different camera views? was it like multiple cameras?

I was more thinking about diffrent angles, and types. Like in a FPS you want a camera, that "IS" the person, and in a Toomr Raider kind of game, maybe you want it to follow that persons back. And maybe we could add a type of camere that we can use to fly over the objects, like in some FPS, when you get shot you can see from where and where your arestanding....(Vietcong is an example on that).

Originally posted by Electroman

And for the render queues I think your better at that cos I havn't read anything on it yet .

I want at render quee...no matter what you ever will say....I will find my algoriths from the back of my head, and make a nice little rendering queue for us...

Originally posted by Electroman


Let me know what you think of these .

Was that good enough.....I had an other idea too when I was answering you....but I forgot it....will get back to it...

[Electroman]

lol, can't believe I wrote ShyBox
Tomb raider by anychance

I will give a better reply when I get back from work (bout 12hours) I'm actually late as it is So I'll speak to you then.

Posted By NoteMe
I had an other idea too when I was answering you....but I forgot it

[NoteMe]

OK...thats fine...I can waith... ...


YEah probably Tomb Raider....that game is BTW using quaternion rotaions on the camera....are you proud of everything I know in thory..and not how to implement...

[Electroman]

Weeheyy I'm home, the Birds won't shut up and I probabl;y aint gonna get to sleep cos its now starting to get light again (Its 4:30 and its getting quite bright ).

Posted By NoteMe
It sounds really nice, never thought about that before. I am afraid that it will use a lot of time to edit a big buffer like that. But if the book provides us with some solutions to split up the terrain in a grid like system, then it might not take that much time to perform. Keep this idea in your head.

I recon the book will definitly have solutions for splitting up the terrian into sections, if not I have some Ideas that may work too. The terrian being editable would probably be best dont though some simple functions like sphere, rectangle, ect.. so if a chunk wants removing you can use simple basic shapes to do the alter and this shouldn't be too hard to alter the data we will have stored.

Posted By NoteMe
...maybe add a lens flare using VS and PS to the camera...

That sound liek a good idea, wasn't thinking about that but it would be good if we can do a good one, a lot of games have really tacky lens flares :d.

Posted By NoteMe
I was more thinking about diffrent angles, and types. Like in a FPS you want a camera, that "IS" the person, and in a Toomr Raider kind of game, maybe you want it to follow that persons back. And maybe we could add a type of camere that we can use to fly over the objects, like in some FPS, when you get shot you can see from where and where your arestanding....

I think this is really for the demo project rather than the engine itself because if the engine just lets the user set the camera position then the program using the engine can do different tricks like the multiple views, Roaming (not ROAMing ) camera or FPS camera.

Posted By NoteMe
I want at render quee...no matter what you ever will say....I will find my algoriths from the back of my head, and make a nice little rendering queue for us ...

The render queue won't really be working on whats obscured though, because its not totally the same as the demos I saw with walls and stuff. Mind I'm sure you can cope with that.

As for the DataStructure for letting the terran be dynamic I'm sure if I spend some time really thinking about it I will be able to come up with something that will work well .

Another thing I wanted to raise was wether this will be open source or closed, it would make sense not to hide the source from fellow VBF members but apart from that will be keeping the source rather close do you think. Its not very important at the moment and I suppose it will probably get figured out later on if we end up spending loads and loads of hours on it.

After writting this reply its got even lighter I'm never going to get any sleep. Going to a BBQ tomorrow (will be online at some point still though) .

BTW yes I am very proud of you

[abcdefg]

Well good luck guys writing a software 3d engine from scratch takes a hell of a lot of time and while direct3d does make it easier and much faster, its still gonna be one long big ass project. Depending on what features u plan on throwing in, it is gonna be hard or wicked hard. Good luck.

[NoteMe]

Originally posted by abcdefg
Well good luck guys writing a software 3d engine from scratch takes a hell of a lot of time and while direct3d does make it easier and much faster, its still gonna be one long big ass project. Depending on what features u plan on throwing in, it is gonna be hard or wicked hard. Good luck.

Off course it will take a lot of time. But it is a natural way to go, when you have been programming that many years, then you finaly want to do something big, and hard, not sit around and tell people how to make Pong and Snake all day long...

[NoteMe]

Originally posted by Electroman


That sound liek a good idea, wasn't thinking about that but it would be good if we can do a good one, a lot of games have really tacky lens flares :d.

Yeah, they do, I found a real good tutorial in one of my books. So maybe we can manage to implement it in some way into the project. Lets remember that idea.

Originally posted by Electroman

I think this is really for the demo project rather than the engine itself because if the engine just lets the user set the camera position then the program using the engine can do different tricks like the multiple views, Roaming (not ROAMing ) camera or FPS camera.

Why isn't it ROAMing? ROAM stands for "Real-Time Optimal Adapting Mesh, shouldn't it be with big letters? And the ING is just becuase we are "useING" ROAM.

But does that mean that you don't want us to implement any way to move through the terrain at all in the engine. Or just not add diffrent ways to do it. I will be pretty hard to see if the Quad tree is working if we don't implement it at all...

Originally posted by Electroman

The render queue won't really be working on whats obscured though, because its not totally the same as the demos I saw with walls and stuff. Mind I'm sure you can cope with that.

The thing with a rendering quee is that you have a "key" in the diffrent classes. Like models will have a class that have a key that say i they are a costly operation then all of them have a key that says that, and then the Effect files have an other key, and then what we put into them have a key, and all togheter every object have a "long" key that we can sort them on, and then we canrender them in the order that makes us do fewest state changes and so on. Needs a lot of planning, but I think we can pull that off...

Originally posted by Electroman

As for the DataStructure for letting the terran be dynamic I'm sure if I spend some time really thinking about it I will be able to come up with something that will work well .

Yeah, I think so too, because if we are all readu using ROAMing () then the terrain are all ready dynamical, becuase it splits up the triangels in the front, but the problem is that there will be a gap between them when you do that...but if we read some more about that, we will probbaly figgure out how to do that...

Originally posted by Electroman

Another thing I wanted to raise was wether this will be open source or closed, it would make sense not to hide the source from fellow VBF members but apart from that will be keeping the source rather close do you think. Its not very important at the moment and I suppose it will probably get figured out later on if we end up spending loads and loads of hours on it.

If it was only me that made this, Iwould try to keep it as secret as I could in the start, so I could alter the code and make it better all the time. But when I was more or less finished, or maybe with ever iteration I want people to test it. And I know we can't get many to test it here without giving them the source. And if we have questions we need to show them code here too anyway. So maybe we should think it over when we have done something.

Originally posted by Electroman

BTW yes I am very proud of you

Hehe...I am proud of you too...

[Electroman]

Posted by abcdefg
Well good luck guys writing a software 3d engine from scratch takes a hell of a lot of time and while direct3d does make it easier and much faster, its still gonna be one long big ass project. Depending on what features u plan on throwing in, it is gonna be hard or wicked hard. Good luck.

The engine wont be a graphics engine that the rest of the program can use, it will simpily have a draw function and that will draw just the terrian. We will still need to build a graphics unit for that but we won't have the extra work of managing all the other graphics objects in the game.

[NoteMe]

Ohhh...sure we will...we will have whistels (sp?) and bells all over it....

No no...serious...it will generate a terrain from a bitmap or something and then display it as fast as possible, and so nice as possible....

[Electroman]

Posted By NoteMe
Why isn't it ROAMing? ROAM stands for "Real-Time Optimal Adapting Mesh, shouldn't it be with big letters? And the ING is just becuase we are "useING" ROAM.

I was trying to say roaming as in not ROAMing, because its also a word, but I've just noticed I didn't mean that word either, I meant to say Roving. Its when the camera floats behind the play (in a third person view) but when the player turns roudn the camera will rotate slower so its not always fixed solidly behind the player. All third person views do it nowadays, like in car games it means you get to see the side of the car while your turning.

Posted By NoteMe
But does that mean that you don't want us to implement any way to move through the terrain at all in the engine. Or just not add diffrent ways to do it. I will be pretty hard to see if the Quad tree is working if we don't implement it at all

Well I would say the engine only needs to work with a camera, it doesn't need to know how the camera moves. We will be implementing a camera, its just we would be giving the engine a position and a direction. Then from that we should be able to do all the calcualations needed to render and minimise the detail on the terrian not in sight.

Posted By NoteMe
Yeah, I think so too, because if we are all readu using ROAMing () then the terrain are all ready dynamical, becuase it splits up the triangels in the front, but the problem is that there will be a gap between them when you do that...but if we read some more about that, we will probbaly figgure out how to do that...

The gap between the sections wont be a problem, we just have the two sections open at the same time then makesure the two match.
The point I was trying to get at by dynamic was that we would be able to make the terrian in almost any shape, so overhangs, and cavens would be possible. Possibly even caves Mind not sure if that would be optimised.

Posted By NoteMe
If it was only me that made this, Iwould try to keep it as secret as I could in the start, so I could alter the code and make it better all the time. But when I was more or less finished, or maybe with ever iteration I want people to test it. And I know we can't get many to test it here without giving them the source. And if we have questions we need to show them code here too anyway. So maybe we should think it over when we have done something

Yeah sounds like I was thinking, I wasn't fussed about it being open source. Should be a rather good resource when finished .

[Electroman]

Posted by NoteMe
No no...serious...it will generate a terrain from a bitmap or something and then display it as fast as possible, and so nice as possible....

but my format will be little more complex than a bitmap, will be optimised to be work fast though .
If we do make an editer we should allow the editor to load a height map in but the save format won't be a bitmap. .

[Electroman]

Posted by NoteMe
Ohhh...sure we will...we will have whistels (sp?) and bells all over it....

No no...serious...it will generate a terrain from a bitmap or something and then display it as fast as possible, and so nice as possible....

Ow yeah I meant to say, where did that come from? I didn't even mention the generating terrian in that post

BTW its Bells & Whistles .

[NoteMe]

Originally posted by Electroman
I was trying to say roaming as in not ROAMing, because its also a word, but I've just noticed I didn't mean that word either, I meant to say Roving. Its when the camera floats behind the play (in a third person view) but when the player turns roudn the camera will rotate slower so its not always fixed solidly behind the player. All third person views do it nowadays, like in car games it means you get to see the side of the car while your turning.

Never heard that word before...so you know a bit too...

Originally posted by Electroman

Well I would say the engine only needs to work with a camera, it doesn't need to know how the camera moves. We will be implementing a camera, its just we would be giving the engine a position and a direction. Then from that we should be able to do all the calcualations needed to render and minimise the detail on the terrian not in sight.

A little corection there...the terrainnot in sight will not be drawn at all. Will not be added to the rendering quee. Or at least not so much of it, becuase of the Quad three. Some of it will always be added, becuae it's not perfect. But we will try to have so little as possible of over writing as possible. And the terrain far away will not be that detailed, and the terrain near us, will be better looking. BTW have you ever worked with FOG? I have never done it. Is it to optimise the rendering, or is it so that you can't see that the terrain far away suddenly dissapear becuase we don't render it because of the Quad tree?

Originally posted by Electroman

The gap between the sections wont be a problem, we just have the two sections open at the same time then makesure the two match.
The point I was trying to get at by dynamic was that we would be able to make the terrian in almost any shape, so overhangs, and cavens would be possible. Possibly even caves Mind not sure if that would be optimised.

I think we should waith a bit with that, becuase it is probbaly very hard to do. but we can try it if you want, but remember that if we enter a cavem then we should probably use a diffrent approach then a quad tree to determin what to render inside it...

Originally posted by Electroman

Yeah sounds like I was thinking, I wasn't fussed about it being open source. Should be a rather good resource when finished .

Yeah probably, but I hate when people are complaining about my "hacks" when I am trying to make things work, when they don't.....thats usually things I make better after a while, but just leave them there as long as they work and move on untill I find a good solution...

[NoteMe]

Originally posted by Electroman
but my format will be little more complex than a bitmap, will be optimised to be work fast though .
If we do make an editer we should allow the editor to load a height map in but the save format won't be a bitmap. .

You have to fill me in on that one...:d...BTW should we make a simple web page, where we add the ideas, and solution, and where we can upload the files we have made, and the version of them. It is rather hard to read through this thread to find our ideas after a while...

[NoteMe]

Originally posted by Electroman
Ow yeah I meant to say, where did that come from? I didn't even mention the generating terrian in that post

BTW its Bells & Whistles .

It sounds better with Whistles and bells.......yeah and I forogt abou the sky box...

[Electroman]

Posted By NoteMe
so you know a bit too

Posted By NoteMe
A little corection there...the terrainnot in sight will not be drawn at all. Will not be added to the rendering quee. Or at least not so much of it, becuase of the Quad three. Some of it will always be added, becuae it's not perfect. But we will try to have so little as possible of over writing as possible. And the terrain far away will not be that detailed, and the terrain near us, will be better looking. BTW have you ever worked with FOG? I have never done it. Is it to optimise the rendering, or is it so that you can't see that the terrain far away suddenly dissapear becuase we don't render it because of the Quad tree?

Good point. As far as the FOG goes I've not heard of it before, I have heard of some methods for when things go out of range but not much.

Posted By NoteMe
I think we should waith a bit with that, becuase it is probbaly very hard to do. but we can try it if you want, but remember that if we enter a cavem then we should probably use a diffrent approach then a quad tree to determin what to render inside it

I agree the cave thing definitly wouldn't be optimised but the data structure would be able to describe it if we wanted.

Posted By NoteMe
You have to fill me in on that one...:d...BTW should we make a simple web page, where we add the ideas, and solution, and where we can upload the files we have made, and the version of them. It is rather hard to read through this thread to find our ideas after a while...

Thats really wierd I was just thinking that .
If you visit this link and tell me what the cookie ID it tells you is I can get workingon it <Link Removed>


BTW do you agree with the camera thing now?

[NoteMe]

Originally posted by Electroman



Good point. As far as the FOG goes I've not heard of it before, I have heard of some methods for when things go out of range but not much.

There is an example on it in the SDK...look at it...And I will try to find some reading about it...

Originally posted by Electroman

I agree the cave thing definitly wouldn't be optimised but the data structure would be able to describe it if we wanted.

OK...let me know how it goes with that data structure...

Originally posted by Electroman

Thats really wierd I was just thinking that .
If you visit this link and tell me what the cookie ID it tells you is I can get workingon it http://www.electromanuk.com/Cookie.php

ehhhh.....

Your Cookie ID for this site is:

Am I not using cookies in FireFox?

Should we have that site on your server or on mine. At least I think we should be able of uplaoding the files, and write the version number on them. I can have it on mine if you want. But I don't have the time to make more then just a simple simple idea page before my exams...

Originally posted by Electroman

BTW do you agree with the camera thing now?

Did we agree on something..??? So are we going to be able to move or not. It is ok for me that we don't add more then one view, but are we going to add that one?

[Electroman]

Not using cookies, that really messes up my web counter when people have cookies disabled I send ages goign through deleting duplicate entries because cookies are off. I do really need to redo it so it uses IP addresses too but I can't get round to it .


A program that has your engine included in it will do the moving, it will call a SetCameraPos() function everyframe and this way the program can be any type of game. It could be a FPS, action game, racing game.


As for who's server to put this site thing on I'm ok with using yours if you want. On mine I can create you and FTP account and if we need put it in a password protected area (if we need that ).
If we use yours is it possible to give me an FTP account?


BTW I got an email this morning sayign my Book has been dispatched .

[NoteMe]

Originally posted by Electroman
Not using cookies, that really messes up my web counter when people have cookies disabled I send ages goign through deleting duplicate entries because cookies are off. I do really need to redo it so it uses IP addresses too but I can't get round to it .

I can't understand it, becuase it looks like they are enabled in the settings menue...and I get cookies all the time in the cookie folder in windows...

Originally posted by Electroman

A program that has your engine included in it will do the moving, it will call a SetCameraPos() function everyframe and this way the program can be any type of game. It could be a FPS, action game, racing game.

So we have to develope a demo app too, to check if the engine works...?? Ok..fine by me...I don't care..

Originally posted by Electroman

As for who's server to put this site thing on I'm ok with using yours if you want. On mine I can create you and FTP account and if we need put it in a password protected area (if we need that ).
If we use yours is it possible to give me an FTP account?

It probably is a setting for it in cpanel, but never used it before...I just wanted to say that we could use mine, so you don't have to use all the space on you server for this project. But if we make an account for the other person too, then it actually don't matter what server we are using. Just the space on the server. You can choose...

Originally posted by Electroman

BTW I got an email this morning sayign my Book has been dispatched .

What book...and what is dispatched???

[Electroman]

Don't worry about the space, I get 1.5GB and 70GB/month bandwidth. The Terrian Book, and dispatched is sent basically .

Posted By NoteMe
So we have to develope a demo app too, to check if the engine works...?? Ok..fine by me...I don't care..

Yeah it shouldn't be a problem . You dont care

[NoteMe]

Originally posted by Electroman
Don't worry about the space, I get 1.5GB and 70GB/month bandwidth. The Terrian Book, and dispatched is sent basically .

Wow...ok..thats more then me......ok...if you can make me a FTP account, then it's fine by me....I won't screw anything up on your server anyway....I am to kind for that..

Originally posted by Electroman

Yeah it shouldn't be a problem . You dont care

Of course I care. But then we have to do that all ready from iteration 1, so we can test it...

[NoteMe]

Havn't read them yet. But I am adding some FOG links, so I can get back to them and read about it...


BTW: If you don't have an account at gamasutra you should realy get it..it's so incredible many good articles and tutorials there..

http://www.gamasutra.com/features/20011003/boyd_01.htm
http://www.gamasutra.com/features/20.../baeza_pfv.htm

[NoteMe]

And here is one about skyboxes....I did read the first part...maybe we don't need fog when we are using a skybox???

http://www.gamasutra.com/features/19981023/bell_01.htm

[Electroman]

Yeah I have an account at gamasutra but I haven't used it that much.
Yeah I know what you mean about the fog thing now, thought your were saying F.O.G. (which I didn't have a clue what it stood for). I agree though a Skybox would be alot better and if we have different detail levels for anything that might be at a distance because we'll be needing to render that bit more for the distance.