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

Printable View

Show 60 post(s) from this thread on one page

Jun 26th, 2004, 10:01 PM
Electroman

Quote:

Posted by NoteMe
OK...will try to remember it now. It is a bit like progressive meshes or using many mipmap levels. If you know what I mean.

Nope its not liek that :(, its like if you think we will be calling a function that does the ROAM stuff and basically the way its structured means that at regular points it checks the time the frame has taken to construct and when a limit is reached it stops the ROAM process and displays the frame (not totally altered competely). Then the next frame it will be starting off from where it left off next time the function is called ;).

Quote:

Posted by NoteMe
Have you read about the diffrent LOD techniques now? This is exactly what all of them does. Like ROAM. It uses more triangles for the terrain close to the camera and the terrain parts that have big hills and stiff. They need it to look nice. Flat land far away from the camera seldom need more triangles.

You've mis understood me here ;). I know the LOD methods create new vertx/triangles but when they do this they create the new vert at the point it is eant to be at. When morphing is used in this way it introduces the new verts position slowly. This way the chnage in deatil isn't that noticable. Let me know in the morning if you don't understand and I'll draw a pic :D.

Quote:

Posted by NoteMe
Maybe we could use a two parted Map Editor. What about using a bitmap (bitmap is a good file format, becuase it is not using any compression, and you can save them over and over again withoug changing any pixels), to store a grey scale (or in colors) picture that we can use as a height map. If we can make height maps with it, we can load the terrain into the engine, and show it without tiles and stuff like sample 6 in the Gaia book.Then we could have an other part of the demo, where we could add small "bitmaps" to that heightmap, for trees, and grass and so on. That could be extended to add houses, and menn and so if we ever need that.

Yea Bitmap is good and i have wrote some tutorials on using it so I am ok with accessing it at a byte level but we wouldn't be stricktly using Bitmap (for the non-dynamic terrain). For things like buildings and trees they would be put in a data lump at the end of the bitmap so really the file wouldn't be able to open in a paint program. Unless we use seperate fiels for that. Mind the dynamic terrain would not be able to use Bitmap structure at all :(. This is because there could be a 20-30 different heights at any point and the way you suggested would mean 20-30 bitmaps to describe that even though maybe only one or two locations had 20-30 heights. The structure would more represent a web kind of layout that simply each node has a pointer to all the other nodes connected to it. Mind the dynamic bit would not be for straight away anyway :(.

Quote:

Posted by NoteMe
Yeah I know it will be some major changes. But if it is ok for you I agree to make it later. If it at least is a bit classed up it won't be that hard to do the changes later on. But since we are so new to this, I think it is better to get the core up first.

Yea I agree it will be better to see the engine work and be easier to test the first parts if we keep the terrain simple. Mind there will need to be a lot of chnages for making it dynamic, the main one being the dataformat :(.
Jun 26th, 2004, 10:06 PM
Electroman

Quote:

Posted by NoteMe
It would definitly be easier to work on this project if we classed everything up since we are two persons, but we can't get to an agreement over how usefull it is over the speed. So it can be very exiting to see how it will work when we get furuther into the project. At least it will be a good experience for both of us.

Its not really a case of classing things up its more just seperating them into seperate files that will help, mind classing things will help in some way but for things that there would only be one instance of (can't rememer its name :() we needn't make it into a class, we can just have it in a seperate file and then it gets encasulated and no speed effect due to a class :D.

Yea I too can't wait to see the first working version :D.
Jun 27th, 2004, 01:23 PM
NoteMe

Quote:

Originally posted by Electroman

Yea I agree we will need some kind of method to get a LOD kinda thing going for our grass effect (remember the wind ;)).

Yeah, we have to remember the wind. Good point. And if it rains, it should probably move a bit too.

Quote:

Originally posted by Electroman

By this do you mean your card does V2.x good or just in general? cos I am still saying we should use V1.x ;)

My card does it good...;)

Yeah agree, lets go for PS and VS 1.X, ant the ASM look alike language.

Quote:

Originally posted by Electroman

Ow and I forgot to mention it just in the other post but I have done before: about the Volumetric Fog things, I think we should really look into that article about using the shaders to allow real modelling or fog volumes :). i think the main problem is the precsion though :(.

Yeah, but maybe we should waith a bit with it. Not in the first implementation. First get the terrain up and going, and then add things like that. BTW, I havn't read so much about it, but will there be fog over us too, or just in the "horrison"?? Becuase it will look weird becuase of a sun or anything in the sky if there is fog all over the place.
Jun 27th, 2004, 01:36 PM
NoteMe

Quote:

Originally posted by Electroman
Nope its not liek that :(, its like if you think we will be calling a function that does the ROAM stuff and basically the way its structured means that at regular points it checks the time the frame has taken to construct and when a limit is reached it stops the ROAM process and displays the frame (not totally altered competely). Then the next frame it will be starting off from where it left off next time the function is called ;).

OK...ehhh...don't understand it completly. Becuase for a frame, you will add everything that you need to the rendering queue. If you only get halfway through this, then you can only see half the terrain, or maybe not the houses, trees what ever that was supposed to be drawn. The user then moves instantly to the right or something, then in the next frame, he will only see the houses, trees, and so on and not anything of what was rendered in the first frame?? ..:confused:

Or are you thinking about not clearing the frame, and then draw them on top of the rest, but then the camera won't move that frame???...:confused:

Quote:

Originally posted by Electroman

You've mis understood me here ;). I know the LOD methods create new vertx/triangles but when they do this they create the new vert at the point it is eant to be at. When morphing is used in this way it introduces the new verts position slowly. This way the chnage in deatil isn't that noticable. Let me know in the morning if you don't understand and I'll draw a pic :D.

Yeah draw a picture..:D

Quote:

Originally posted by Electroman

Yea Bitmap is good and i have wrote some tutorials on using it so I am ok with accessing it at a byte level but we wouldn't be stricktly using Bitmap (for the non-dynamic terrain). For things like buildings and trees they would be put in a data lump at the end of the bitmap so really the file wouldn't be able to open in a paint program. Unless we use seperate fiels for that. Mind the dynamic terrain would not be able to use Bitmap structure at all :(. This is because there could be a 20-30 different heights at any point and the way you suggested would mean 20-30 bitmaps to describe that even though maybe only one or two locations had 20-30 heights. The structure would more represent a web kind of layout that simply each node has a pointer to all the other nodes connected to it. Mind the dynamic bit would not be for straight away anyway :(.

OK, if that is so, then I don't understand what you mean about the dynamic terrain. The way I thought we where going to make dynamic terrain was to make "craters" after bombs and so on...but that will be managed in memory, not on the bitmap it self. The bitmap will only be read in the start of the "game", not when the game is running. Then we will only change the vertex/index buffer or what ever.

Or are you thinking about over hangs? But are you still thinking about making bitmaps with overhangs? Becuase I am pretty sure that you can't make that happen with a 2D image.

And what I thought about placing the houses and trees and so on, will not be done in the same file as the height map. Sure we can make a costum format after we have made them both, but we could also just have trees and house positions and so on in a separate file. But for a working release it will probably better to merge the bmp file and the object file into one costum file.
Jun 27th, 2004, 01:38 PM
NoteMe

Quote:

Originally posted by Electroman
Its not really a case of classing things up its more just seperating them into seperate files that will help, mind classing things will help in some way but for things that there would only be one instance of (can't rememer its name :() we needn't make it into a class, we can just have it in a seperate file and then it gets encasulated and no speed effect due to a class :D.

Yea I too can't wait to see the first working version :D.

How are you thinking about making a rendering queue work if objects on the screen is not classed up?
Jun 27th, 2004, 02:13 PM
Electroman

Quote:

Posted by NoteMe
Yeah, but maybe we should waith a bit with it. Not in the first implementation. First get the terrain up and going, and then add things like that. BTW, I havn't read so much about it, but will there be fog over us too, or just in the "horrison"?? Becuase it will look weird becuase of a sun or anything in the sky if there is fog all over the place.

Yea I meant to say that it wouldn't be the first iteration.

The god is volumetric ;) Its like there is blobs here and there, so it would be like squashed balls (any shape really) moving about so this way the sky and distant stuff can still be seen but we can have little "clouds" rolling along the landscape :D.
Jun 27th, 2004, 02:18 PM
Electroman

Quote:

Originally posted by NoteMe
How are you thinking about making a rendering queue work if objects on the screen is not classed up?

There would be more than one instance of the objects being rendered so I agree these would be in classes. ;)
Jun 27th, 2004, 02:54 PM
Electroman

1 Attachment(s)

Quote:

Posted by NoteMe
OK...ehhh...don't understand it completly. Becuase for a frame, you will add everything that you need to the rendering queue. If you only get halfway through this, then you can only see half the terrain, or maybe not the houses, trees what ever that was supposed to be drawn. The user then moves instantly to the right or something, then in the next frame, he will only see the houses, trees, and so on and not anything of what was rendered in the first frame?? ..:confused:

Or are you thinking about not clearing the frame, and then draw them on top of the rest, but then the camera won't move that frame???...:confused:

Nope, This only happens for the Generating the mesh for the terrain. The process of adding the extra verts and removing distant ones. Say you have a patch of terrain and it has just came into view: The first pass would create the four verts to describe the square (This is purley an example mind), then it goes though on another pass and splits these triangles again. This is repeated several times depending on the distance from the camera.
Each time a pass is completed it will check how much time has been taken on the frame so far and when this time reaches a certain value it will not do anymore passes. There will also be a check to make sure its done a minimum amount of passes though so at least the mesh is a resonable quality.

Quote:

Posted by NoteMe
Yeah draw a picture..:D

Right the top one is not using Morphing and the bottom one is. Basically it shows a distant triangle and between frame 1 and 2 the camera got close enough for it to be split. The one that doesn't use morphing instantly creates the new vert at the position it is required at, creating a considerable change to the overall shape. However the one using morphing creates the new vert in the gap between the new position and the line that was already there. Then the next frame it moves the new vert closer to the required position. The example I gave does it over only 2 frames so wouldn't be as good. The rate at which the morphing occours is normally a tweakable value that is changed during testing D:.

http://www.vbforums.com/attachment.p...postid=1723657

Quote:

Posted by NoteMe
OK, if that is so, then I don't understand what you mean about the dynamic terrain. The way I thought we where going to make dynamic terrain was to make "craters" after bombs and so on...but that will be managed in memory, not on the bitmap it self. The bitmap will only be read in the start of the "game", not when the game is running. Then we will only change the vertex/index buffer or what ever.

Or are you thinking about over hangs? But are you still thinking about making bitmaps with overhangs? Becuase I am pretty sure that you can't make that happen with a 2D image.

And what I thought about placing the houses and trees and so on, will not be done in the same file as the height map. Sure we can make a costum format after we have made them both, but we could also just have trees and house positions and so on in a separate file. But for a working release it will probably better to merge the bmp file and the object file into one costum file.

I think you kind of understood me on the dynamic terrain idea just the thing is it would be better if its possible to save the terrain in the defoamed state. This is becuase if the engine was used for a game then this would be a requirement for save games ;).
Jun 27th, 2004, 03:09 PM
NoteMe

Quote:

Originally posted by Electroman
Yea I meant to say that it wouldn't be the first iteration.

The god is volumetric ;) Its like there is blobs here and there, so it would be like squashed balls (any shape really) moving about so this way the sky and distant stuff can still be seen but we can have little "clouds" rolling along the landscape :D.

OK...I can agree on that. We can make it in the same itteration as we look into rain, and lens flare and so on....
Jun 27th, 2004, 03:10 PM
NoteMe

Quote:

Originally posted by Electroman
There would be more than one instance of the objects being rendered so I agree these would be in classes. ;)

OK...then we agree on that...D:
Jun 27th, 2004, 03:24 PM
NoteMe

Quote:

Originally posted by Electroman
Nope, This only happens for the Generating the mesh for the terrain. The process of adding the extra verts and removing distant ones. Say you have a patch of terrain and it has just came into view: The first pass would create the four verts to describe the square (This is purley an example mind), then it goes though on another pass and splits these triangles again. This is repeated several times depending on the distance from the camera.
Each time a pass is completed it will check how much time has been taken on the frame so far and when this time reaches a certain value it will not do anymore passes. There will also be a check to make sure its done a minimum amount of passes though so at least the mesh is a resonable quality.

OK...thats a good idea. But when you talk about mesh, are you talking about the terrain or the objects like trees and stuff. Or both.

I havn't looked into how Gaia is splitting up the triangles, but maybe we can make it so if the user moves the camera fast in X,Y direction, it won't split any thing at all. Becuase he is just changing the looking vector so it is no need to split up those who are soon going to be out of the screen anyway. Like in an FPS there you use your mouse to turn 180 deggrees, there is no need to split up the triangles for the "right or left side, only where he was looking, and where he is looking after the camera has been moved. But I have to look more into this to see if it is possible.

Quote:

Originally posted by Electroman

Right the top one is not using Morphing and the bottom one is. Basically it shows a distant triangle and between frame 1 and 2 the camera got close enough for it to be split. The one that doesn't use morphing instantly creates the new vert at the position it is required at, creating a considerable change to the overall shape. However the one using morphing creates the new vert in the gap between the new position and the line that was already there. Then the next frame it moves the new vert closer to the required position. The example I gave does it over only 2 frames so wouldn't be as good. The rate at which the morphing occours is normally a tweakable value that is changed during testing D:.

http://www.vbforums.com/attachment.p...postid=1723657

It looks good, but it is a bit hard to imagine on that picture to see that there will be no gap between the triangels if we do it that way. If you don't know what kind of gap I am talking about you will see what I mean when you read about the diffrent LOD techniques in the Terrain Engine book. But if we can manage to do it with no gaps, then it sounds like a good idea.

Quote:

Originally posted by Electroman

I think you kind of understood me on the dynamic terrain idea just the thing is it would be better if its possible to save the terrain in the defoamed state. This is becuase if the engine was used for a game then this would be a requirement for save games ;).

Yeah it will, unless we can just save the points where the "bombs" hit the terrain, then the engine, could load the terrain as it is in the map, then change it dynamicaly before the level starts again. What do you think about that? If you like the idea I suggest the bomb points should be saved in the same location and way as houses trees and so on is saved...Men dying in a FPS is just as much dynamical in that way...
Jun 27th, 2004, 05:09 PM
Electroman

Quote:

Posted by NoteMe
OK...thats a good idea. But when you talk about mesh, are you talking about the terrain or the objects like trees and stuff. Or both.

Just the Terrain.

Quote:

Posted by NoteMe
I havn't looked into how Gaia is splitting up the triangles, but maybe we can make it so if the user moves the camera fast in X,Y direction, it won't split any thing at all. Becuase he is just changing the looking vector so it is no need to split up those who are soon going to be out of the screen anyway. Like in an FPS there you use your mouse to turn 180 deggrees, there is no need to split up the triangles for the "right or left side, only where he was looking, and where he is looking after the camera has been moved. But I have to look more into this to see if it is possible.

Hummm, well does the Gaia engine use a render queue? Cos if it doesn't then I think ours should only use it for objects and not the terrain.
I still think the Terrain should have a simple kind of render queue, which I'll explain in a second...

The terrain should be split up into sections, say squares, these patchs would be a way to break up large terrains into smaller chunks.

The simple render queue kinda thing would sort this so the LOD function only gets feed the patchs that will be close to the camera and in the direction its looking in.
It will then after the LOD function is ran it will have the terrain grouped into parts that are the same texture and stuff like renderstates the same. But I don't think its worth doing anything to check which parts of the terrain are visible apart from the simple direction and range check.

Quote:

Posted by NoteMe
It looks good, but it is a bit hard to imagine on that picture to see that there will be no gap between the triangels if we do it that way. If you don't know what kind of gap I am talking about you will see what I mean when you read about the diffrent LOD techniques in the Terrain Engine book. But if we can manage to do it with no gaps, then it sounds like a good idea.

Gaps aren't an issue, we are only moving the verts position, it will still be the same vert being used by any triangles attached to it. We are mearly doing exactly the same as splitting the triangle but we are just moving the new verts position for a couple of frames.

Quote:

Posted by NoteMe
Yeah it will, unless we can just save the points where the "bombs" hit the terrain, then the engine, could load the terrain as it is in the map, then change it dynamicaly before the level starts again. What do you think about that? If you like the idea I suggest the bomb points should be saved in the same location and way as houses trees and so on is saved...Men dying in a FPS is just as much dynamical in that way...

I'm not kean on doing it by saving the explosions because its still possible we might want to create maps that use the dynamic parts and this would mean then the normal map would need to be made in a way that fits into the described explosions.
Jun 28th, 2004, 12:31 AM
NoteMe

[QUOTE]Originally posted by Electroman
[B]Just the Terrain.

Agree.

Quote:

Originally posted by Electroman

Hummm, well does the Gaia engine use a render queue? Cos if it doesn't then I think ours should only use it for objects and not the terrain.
I still think the Terrain should have a simple kind of render queue, which I'll explain in a second...

Yes it uses a Rendering Queue. All big games are too.

Quote:

Originally posted by Electroman

The terrain should be split up into sections, say squares, these patchs would be a way to break up large terrains into smaller chunks.

Thats what you have Quad trees, Oct Trees, BSP trees, KD Trees, AABB trees and so on to do for you. You should realy read about the implementation of the Quad tree in the Terrain book. It is the based on the article in my Game Programming Gems 2 book. It is realy realy nice.

Quote:

Originally posted by Electroman

The simple render queue kinda thing would sort this so the LOD function only gets feed the patchs that will be close to the camera and in the direction its looking in.

That is not a rendering queues job. A rendering queue is just dumb and sorts what it is feed with. It is ROAM or what ever we LOD functions we will use that will fix this.

Quote:

Originally posted by Electroman

It will then after the LOD function is ran it will have the terrain grouped into parts that are the same texture and stuff like renderstates the same. But I don't think its worth doing anything to check which parts of the terrain are visible apart from the simple direction and range check.

How are you thinking about dealing with the "tiles" this way. I have only been reading about one way, and thats the way in the book. And I don't we can do it that way with that method. But lets waith with the tiles anyway. We don't need that to get the terrain up and going.

Quote:

Originally posted by Electroman

Gaps aren't an issue, we are only moving the verts position, it will still be the same vert being used by any triangles attached to it. We are mearly doing exactly the same as splitting the triangle but we are just moving the new verts position for a couple of frames.

But if the vertices are moved, and then ROAM is splitting them up, there will be gaps...

Quote:

Originally posted by Electroman

I'm not kean on doing it by saving the explosions because its still possible we might want to create maps that use the dynamic parts and this would mean then the normal map would need to be made in a way that fits into the described explosions.

I am realy looking forward to see how you plan to implement this. I can't see a simgle way on how to descripe to planes on the same possition on a 2D map....
Jun 28th, 2004, 10:48 AM
Electroman

Yea I realised later last night I was mixing up the render queue and Quad tree.

As for the way I expect us to deal with the tiles and helping the render queue was a bit like this:

Code:

class CVertGroup { CTexture* pTexture1; // The texture used for this Vertex Buffer. CTexture* pTexture2; // The second texture (if used) for this Vertex Buffer. CVertBuffer* pVertBuffer; // A Handled VertexBuffer for the Verts with this texture. CIndixBuffer* pIndexBuffer; // A Handled IndexBuffer for the Verts with this texture. CVertGroup* NextVertGroup; // Points to the next group of textures. } class CVertItem { Vector3D Pos; float TexU; float TexV; ... ... ... int BIndex; // The index this vert is in the vertex buffer. this allows use to modify or move it and alter the Indices Buffer accordingly. CVertItem* pTEquivVert; // Pointer to the equivelent in the pTData for this tile. ... CVertItem* pUVert; // Up Connection. CVertItem* pDVert; // Down Connection. CVertItem* pLVert; // Left Connection. CVertItem* pRVert; // Right Connection. CVertItem* pULVert; // Up Left Connection. CVertItem* pURVert; // Up Right Connection. CVertItem* pDLVert; // Down Left Connection. CVertItem* pDRVert; // Down Right Connection. } class CVertData { CVertItem* pTLVert; // Top Left Vert. CVertItem* pTRVert; // Top Right Vert. CVertItem* pBLVert; // Bottom Left Vert. CVertItem* pBRVert; // Bottom Right Vert. ... ... } class CMorphing { CVertItem* pVert; // Pointer to the vert in the pVData for the tile its in. Vector3D DPos; // Location it is aiming for. ... ... CMorphing* NextVert; } class CTile { CVertGroup* pVertGroups; // CVertData* pVData; // Our Data for the verts in use. CTileData* pTData; // Our Data for the tiles structure (perfect structure). CMorphing* pMorphList; // A list of verts currently being Morphed. ... ... }

You see this way there is a vertex buffer for each of the different textures used in each tile. I'm not sure on how the multiple textures will be handled yet but you should get the idea of how this would be friendly to the render queue.

This is still just an idea I am still working on though but things like the splitting I have worked out how it will happen :D.

BTW how is data stored in a vertex buffer in C++? I know in VB it was an array but does this mean each time its size changes we need to recreate an array becuase you don't have the same kind of dynamic array you do in VB.
The other thing I though was if we calculate a maximum amount of verts per buffer then we can make an array that big and just use the numbers in the draw function to change how many it is actually using.
Jun 28th, 2004, 11:02 AM
Electroman

Quote:

Posted by NoteMe
But if the vertices are moved, and then ROAM is splitting them up, there will be gaps...

The thing is that all the triangles that are near the vert being moved are joined to the vert, not the new position, we will use a index buffer (maybe) so this would mean that the 8 possible triangles connected to the point will all be using the same point even though its moving each frame ;).
Jun 28th, 2004, 12:59 PM
NoteMe

Quote:

Originally posted by Electroman
You see this way there is a vertex buffer for each of the different textures used in each tile. I'm not sure on how the multiple textures will be handled yet but you should get the idea of how this would be friendly to the render queue.

This is still just an idea I am still working on though but things like the splitting I have worked out how it will happen :D.

BTW how is data stored in a vertex buffer in C++? I know in VB it was an array but does this mean each time its size changes we need to recreate an array becuase you don't have the same kind of dynamic array you do in VB.
The other thing I though was if we calculate a maximum amount of verts per buffer then we can make an array that big and just use the numbers in the draw function to change how many it is actually using.

I am not sure how we should change the size of the vertex buffer actualy. I think I will have a look in the Gaia engine, and see what it does. But making a new VB is probably very expensive. NVIDIA prases the BIG VB way. That is: you make a VB that is much bigger then you need (like 10 times the size, then if you have to change some vertices you start to write after the vertices you first used. That way if there is a DMA (what is it called again), at least it won't be interupted. So it is supposed to be faster. Then you only have to ZERO the VB every 10th time. It is supposed to be faster. But if we have a big terrain, it will probably use a LOT of memory to make a VB 10 times the size, but we could try to make it a bit bigger then twize the size, that way we could make it dynamicaly too. But I have to read a bit more on it.,

I know at least that in the Gaia Engine, cTerrain holds the whole terrain, then cTerrainSection, holds the diffrent parts, but I don't think it has the actual geometry, but rather uses cTerrains VB.

So then you only have to send cTerrainSection to the VB. And it is the Quad Tree or waht ever we use that finds out what cTerrainSection objects we have to send, and what other objects we have to send to the RenderingQueue.

The way I am thinking about doing the rendering queue all things visible on the screen has to be derived from the same class. A cRenderObject class or something. That way we can send them to the Queue, and find out what kind of object it is, so we can sort them so we don't need so many rendering state changes. And then all the objects on the screen has a overloaded Render() function, that we can call from the queue.

I think that can work. It is at least a bit easier then the way Gaia is doing it.

What do you think?
Jun 28th, 2004, 01:02 PM
NoteMe

Quote:

Originally posted by Electroman
The thing is that all the triangles that are near the vert being moved are joined to the vert, not the new position, we will use a index buffer (maybe) so this would mean that the 8 possible triangles connected to the point will all be using the same point even though its moving each frame ;).

I hope you are right. I didn't 100% understand why the gaps happend. But at least when you are splitting up triangles no matter what LOD you are using ROAM or what ever it will create some sort of gaps you have to deal with.
Jun 28th, 2004, 01:14 PM
Electroman

Quote:

Posted by NoteMe
I hope you are right. I didn't 100% understand why the gaps happend. But at least when you are splitting up triangles no matter what LOD you are using ROAM or what ever it will create some sort of gaps you have to deal with.

Yea the morphing won't create these gaps but the edge of the tiles will be an issue but a bit of code should be able to sort that out.

As to your post before that one I'm just testing something with Vert Buffers to see if I was thinking the right thing or if I have to revise my method slightly........
Jun 28th, 2004, 01:21 PM
NoteMe

OK...keep me posted on how it goes...and I will try to find out more about the rendering queue.
Jun 28th, 2004, 01:40 PM
Electroman

Cool everything looks fine, in C++ you can lock the vertex buffer and just alter the existing data. Which for some reason I had had a sudden thought you couldn't.

As you see the CTileData* pTData in the CTile class this will hold the maximum detail possible and therefore we have a maximum size for the vert buffer. We needn't make the buffer bigger than the max because I will use a way that just switches the verts positions in the buffer around then it will update the Index buffer so the effect is unseen. This way the Vertex buffer gets shuffled up as the detail changes but the index buffer will be able to make sure the it still works. I can draw a pic of how this will work if you want to know?

The only problem that will mess this up slightly is that when the terrain is defoamed (a bomb goes off say) then the pTData will change and then we may need to alter the size of the Vertex buffer :(. We could get round this by simply reszinging it when this happens, because it shouldn't happen that often really? Cos to be honest it would be impossible to predict the max number of verts could be used after some explosions. And creating a buffer larger than we need could get very expensive on large terrains ;).
Jun 28th, 2004, 02:23 PM
NoteMe

SO you have now a lot of small VB, that you have to alter some few verts and then push it back to the GPU. That is 2 big mistakes if we should listen to the game developers on line. And all of those that have written all of my books. Not sure if this is a good idea at all....

[Edit] Why shouldn't it be possible to change the vertices...you do it all the time in games. But it is slow as hell.
Jun 28th, 2004, 02:47 PM
Electroman

Well the thing is if we use just one large vertex buffer then it will mean we need to transport the whole data for the entire terrain each frame. I suppose I could easily chnage it so it shares the one buffer and thinking of it I suppose the buffer wouldn't really be that big because the distance tiles would have been reduced.

And you said thats two mistakes :confused:, I only see one there?

Quote:

Posted by NoteMe
[Edit] Why shouldn't it be possible to change the vertices...you do it all the time in games. But it is slow as hell.

Don't know what you mean here :confused:.
Jun 28th, 2004, 03:14 PM
NoteMe

Quote:

Originally posted by Electroman
Well the thing is if we use just one large vertex buffer then it will mean we need to transport the whole data for the entire terrain each frame. I suppose I could easily chnage it so it shares the one buffer and thinking of it I suppose the buffer wouldn't really be that big because the distance tiles would have been reduced.

And you said thats two mistakes :confused:, I only see one there?

Don't know what you mean here :confused:.

- I think Gaia is using one big VB. And why should you need to move it. You don't need to render all vertices in a VB. Like you don't have to change them all.

- The two mistakes is: Having many small VB, in stead of BIG VBs, and the other one is the DMA fault I was talking about.

- And what did you not get? That it is slow, or that games us it? I said that it was common NVIDIA practice to use a big VB, and then don't alter them and just add to the end of the used spaces in the VB. Thats a kind of altering.
Jun 28th, 2004, 04:40 PM
Electroman

Quote:

Posted by NoteMe
- I think Gaia is using one big VB. And why should you need to move it. You don't need to render all vertices in a VB. Like you don't have to change them all.

Yea but to change any of them you will need to lock the whole VBuffer and when you do that doesn't it move the area you lock into Normal memory so the pointer works? It wouldn't be possible to determine a single lockable area to define a Tile because as new ones are created they would be added to the end. If we were to use one big VBuffer then it would need to only contain the current data which would mean more processing. Like having seperate ones per tile would mean if a tile went out of view then it would keep the state it was last in, where as with one VBuffer it would get totally removed :(.

You do realise I wasn't taking about small tiles? Something like 100x100 squares which would mean a max of 10,000 verts.

As for the textures I don't understand how you expect to use one vertex buffer to render multiple textures, like if half the verts are using A grass texture and the other half a stone texture then how would you split this up? Using two IBuffers, one for each texture?

Quote:

Posted by NoteMe
- The two mistakes is: Having many small VB, in stead of BIG VBs, and the other one is the DMA fault I was talking about.

K but my point was that because we know the maximum we wouldn't need to resize (recreate) the VBuffer. Most the time it would be bigger than required but that wouldn't matter.

Quote:

Posted by NoteMe
- And what did you not get? That it is slow, or that games us it? I said that it was common NVIDIA practice to use a big VB, and then don't alter them and just add to the end of the used spaces in the VB. Thats a kind of altering.

I don't get what the sentance was meant to mean :confused:. (And still don't)
Jun 28th, 2004, 05:38 PM
Electroman

Ow and can we agree on a FVF? Well I assume we will be using more than one because some verts will be using more than one texture but for the ones only using one texture what should we use? Like will we use normals or Diffuse? And anything else?
Jun 30th, 2004, 03:06 PM
NoteMe

Quote:

Originally posted by Electroman
Ow and can we agree on a FVF? Well I assume we will be using more than one because some verts will be using more than one texture but for the ones only using one texture what should we use? Like will we use normals or Diffuse? And anything else?

I have read about how Gaia is tiling the terrain. Never thought about that way of doing it. It uses 4 tiles all over the map. And blends them togheter, so some places one tile shows more then an other one. That means that you can use the same vertices for the whole therrain. What do you think about that idea? I can direct you too the page if you want. It is obly one page where he talkes about the theory.

BTW have you found out what kind of FVF Gaia is using? I am trying to look for it now...but can't find it...would have been intresting to too look at....
Jun 30th, 2004, 03:28 PM
NoteMe

Quote:

Originally posted by Electroman
Yea but to change any of them you will need to lock the whole VBuffer and when you do that doesn't it move the area you lock into Normal memory so the pointer works? It wouldn't be possible to determine a single lockable area to define a Tile because as new ones are created they would be added to the end. If we were to use one big VBuffer then it would need to only contain the current data which would mean more processing. Like having seperate ones per tile would mean if a tile went out of view then it would keep the state it was last in, where as with one VBuffer it would get totally removed :(.

You don't need to loock the whole buffer if I have understodd it right. Thats why Gaia has cTerrain, that holds the whole terrain, and cTerrainSection, that is the diffrent sections that can be visible in a quad tree. Then we only need to lock what the "cTerrainSection" objects that the quad tree sends to the rendering queue is pointing to in the VB.

Quote:

Originally posted by Electroman

You do realise I wasn't taking about small tiles? Something like 100x100 squares which would mean a max of 10,000 verts.

Read my last post...

Quote:

Originally posted by Electroman

As for the textures I don't understand how you expect to use one vertex buffer to render multiple textures, like if half the verts are using A grass texture and the other half a stone texture then how would you split this up? Using two IBuffers, one for each texture?

You can pass more then one texture in one pass. I think my GPU supports 8 or 16 or something.

Quote:

Originally posted by Electroman

I don't get what the sentance was meant to mean :confused:. (And still don't)

NVIDIA say: Use big VB, then add to the end, not change the verts in the buffer. Becuase it is slow.

You say: Lets use a small one. Lets change them.

NVIDIA say: Batch up the vertices in a big VB. Better to have one big then many small. DrawPrimitives is soooo slow.

You say: Lets make many small VBs.

Get it now?
Jun 30th, 2004, 03:28 PM
Electroman

Quote:

Posted by NoteMe
I have read about how Gaia is tiling the terrain. Never thought about that way of doing it. It uses 4 tiles all over the map. And blends them togheter, so some places one tile shows more then an other one. That means that you can use the same vertices for the whole therrain. What do you think about that idea? I can direct you too the page if you want. It is obly one page where he talkes about the theory.

Well the Gaia terrains aren't really big though, in fact i'd say they are quite small :(. So that must mean it doesn't approach any issues for joining together tiles either :(.

Yea which page does it say this though :).
Jun 30th, 2004, 03:31 PM
NoteMe

Quote:

Originally posted by Electroman
Well the Gaia terrains aren't really big though, in fact i'd say they are quite small :(. So that must mean it doesn't approach any issues for joining together tiles either :(.

Yea which page does it say this though :).

Page 201, and drawing 202.

Yeah it isn't that big. But the problem with big terrains is the memory usage. We need a whole new approach if we want a bigger terrain. Becuase we need to push things in and out of memory.

Think that Gaia 2.0 might be handeling that problem. But not sure. It was at least requested in a poll a long time ago..
Jun 30th, 2004, 03:45 PM
Electroman

Quote:

Posted by NoteMe
You don't need to loock the whole buffer if I have understodd it right. Thats why Gaia has cTerrain, that holds the whole terrain, and cTerrainSection, that is the diffrent sections that can be visible in a quad tree. Then we only need to lock what the "cTerrainSection" objects that the quad tree sends to the rendering queue is pointing to in the VB.

Gaia must be using the VBuffer in blocks, I don't see how its adding Verts if its doing that though, unless there are gaps in between these blocks.

Quote:

Posted by NoteMe
You can pass more then one texture in one pass. I think my GPU supports 8 or 16 or something.

I think 8 is the max :unsure:. However the point was if the FVF is set to have verts with 2 texture coords then what do we do with the second one when we want that vert to only use one texture? Is this a case of chnaging the renderstates to ignore the second Text coords?.

Quote:

Posted by NoteMe
NVIDIA say: Use big VB, then add to the end, not change the verts in the buffer. Becuase it is slow.

You say: Lets use a small one. Lets change them.

NVIDIA say: Batch up the vertices in a big VB. Better to have one big then many small. DrawPrimitives is soooo slow.

You say: Lets make many small VBs.

Get it now?

I wasn't talking about small VBuffers though, I was saying rater large ones which making them too big would mean it wouldn't be possible to render, whats the max primitives you can render at a time?

Quote:

Posted by NoteMe
Yeah it isn't that big. But the problem with big terrains is the memory usage. We need a whole new approach if we want a bigger terrain. Becuase we need to push things in and out of memory.

Think that Gaia 2.0 might be handeling that problem. But not sure. It was at least requested in a poll a long time ago..

Well I suppose to cope with the amount of data I suggest we only use one VBuffer but its kinda like a view VBuffer. It won't represent any tile or even the whole terrain but just the verts in view. This would bring the frame coherance in quite well too. This will mean we use Local memory to sore the structure then when the display chnages we just access this single VBuffer to edit it to include more of the verts because they have just came into view, and remove the ones that just left view.
Jun 30th, 2004, 04:03 PM
NoteMe

Quote:

Originally posted by Electroman
Gaia must be using the VBuffer in blocks, I don't see how its adding Verts if its doing that though, unless there are gaps in between these blocks.

I am not sure about this either. But why worry about that now anyway. Like in demo 6 it is not using any LOD algorithms at all. And I can't see why we should think about it soo soon either. I havn't looke at the code, but for me (just by reading the book) it stores the whole terrain in one VB, then the cTerrainSection, knows what section is using what index in the VB for each section.

Quote:

Originally posted by Electroman

I think 8 is the max :unsure:. However the point was if the FVF is set to have verts with 2 texture coords then what do we do with the second one when we want that vert to only use one texture? Is this a case of chnaging the renderstates to ignore the second Text coords?.

It depends on HW. And if we need more then the max supported by the HW, it just means that we have to do it in to stages. It is the simplest multi texturing PS ever. So it shouldn't be hard.

Lets take your example (did you read that page BTW) if we have 2 textures, and we only want one of the textures to be possible in a area, then we will use 1.0 blend factor in the PS for that texture and 0.0 for the other one. Then one of them will be showing 100% and the other one 0% on the vertex.

Quote:

Originally posted by Electroman

I wasn't talking about small VBuffers though, I was saying rater large ones which making them too big would mean it wouldn't be possible to render, whats the max primitives you can render at a time?

I think that DrawPrimitives can handle 65K, but I am not 100% sure about that. Thats why we should have one big VB, and then render them in the sections, like cTerrainSection does. Then we just have to make sure it doesn't contain more then 65k vertices. And that should not be a problem.

Quote:

Originally posted by Electroman

Well I suppose to cope with the amount of data I suggest we only use one VBuffer but its kinda like a view VBuffer. It won't represent any tile or even the whole terrain but just the verts in view. This would bring the frame coherance in quite well too. This will mean we use Local memory to sore the structure then when the display chnages we just access this single VBuffer to edit it to include more of the verts because they have just came into view, and remove the ones that just left view.

So where will you store the whole terrain, and how will you split it up so the quad tree can find out what vertices are on the screen?
Jun 30th, 2004, 04:49 PM
Electroman

Quote:

Posted by NoteMe
It depends on HW. And if we need more then the max supported by the HW, it just means that we have to do it in to stages. It is the simplest multi texturing PS ever. So it shouldn't be hard.

Lets take your example (did you read that page BTW) if we have 2 textures, and we only want one of the textures to be possible in a area, then we will use 1.0 blend factor in the PS for that texture and 0.0 for the other one. Then one of them will be showing 100% and the other one 0% on the vertex.

K, wasn't sure about the blend thing, mind the method he uses means we are limited in the amount of different textures possible? Yea we could increase the amount of them but what if we want a small area 3x3 of snow on the whole map, this method would mean making a blend image the size of the whole terrain just to use 3x3. So we will probably need to adapt this a bit :).
And I was meaning I thought the max hardware was 8 :unsure:
(D3DFVF_TEX8 was the highest I can see).

Quote:

Posted by NoteMe
I think that DrawPrimitives can handle 65K, but I am not 100% sure about that. Thats why we should have one big VB, and then render them in the sections, like cTerrainSection does. Then we just have to make sure it doesn't contain more then 65k vertices. And that should not be a problem.

K, understand that now.

Quote:

Posted by NoteMe
So where will you store the whole terrain, and how will you split it up so the quad tree can find out what vertices are on the screen?

The whole terrain data will still be stored in tiles (64x64 or 128x128) and this will be in standard memory.

If you think of how I had in the structure before about the PureData then this will be in standard memory for each of the tiles. Then instead of each tile having another set of Data for the ones in the VBuffer they will all share one which represents only the visible verts and ignores the tile borders.

Each frame the changes in the Viewable Data structure will be reflected onto the VBuffer before rendering.
Jun 30th, 2004, 06:30 PM
NoteMe

Quote:

Originally posted by Electroman
K, wasn't sure about the blend thing, mind the method he uses means we are limited in the amount of different textures possible? Yea we could increase the amount of them but what if we want a small area 3x3 of snow on the whole map, this method would mean making a blend image the size of the whole terrain just to use 3x3. So we will probably need to adapt this a bit :).
And I was meaning I thought the max hardware was 8 :unsure:
(D3DFVF_TEX8 was the highest I can see).

Yeah, we probably have to adapt it a bit. But it still looks like a nice way to do it.

Quote:

Originally posted by Electroman

K, understand that now.

I am sooooo good..:D

Quote:

Originally posted by Electroman

The whole terrain data will still be stored in tiles (64x64 or 128x128) and this will be in standard memory.

If you think of how I had in the structure before about the PureData then this will be in standard memory for each of the tiles. Then instead of each tile having another set of Data for the ones in the VBuffer they will all share one which represents only the visible verts and ignores the tile borders.

Each frame the changes in the Viewable Data structure will be reflected onto the VBuffer before rendering.

Still a bit unclear on this one....Maybe you should draw up the classes and where the VB are located. Maybe I understand it better that way. But if I understand you right, you still want many small bufffers and not one big one. And you want to copy from the small buffers to a bug "view" buffer before rendering?

What about storing the whole terrain in one big buffer in a "cTerrain" class, then we have the terrain devided in "cTerrainSection" that only shows us where in the VB these vertices are store, then we can use that to copy from the big VB to the "view" VB. Or would that be very slow?

And in the "cTerrainSection" object we could also store what kind of textures we needed for the terrain, so if there was only one section that had the snow texture, it would only be blended for this section, and not for all of the other sections. What do you think about that?

BTW when I talk about section I am thinking about deviding the whole terrain up in a grid and then we have the sections. When you are talking about tiles. Are you talking about the same thing then or is tiles when you speak 2 triangels next to each other forming a quad?
Jun 30th, 2004, 06:59 PM
Electroman

Quote:

Posted by NoteMe
Still a bit unclear on this one....Maybe you should draw up the classes and where the VB are located. Maybe I understand it better that way. But if I understand you right, you still want many small bufffers and not one big one. And you want to copy from the small buffers to a bug "view" buffer before rendering?

Nope, there is only one VBuffer. All the data is stored in a format similar to the method used by the classes I posted before. I will do the classes for those in a minute.....

Quote:

Posted by NoteMe
What about storing the whole terrain in one big buffer in a "cTerrain" class, then we have the terrain devided in "cTerrainSection" that only shows us where in the VB these vertices are store, then we can use that to copy from the big VB to the "view" VB. Or would that be very slow?

We will have a CTerrain class but really it will be more of a 2D array of CTerrainSections and then the sections will be holding the data for all the vertices in that tile.

Quote:

Posted by NoteMe
And in the "cTerrainSection" object we could also store what kind of textures we needed for the terrain, so if there was only one section that had the snow texture, it would only be blended for this section, and not for all of the other sections. What do you think about that?

Ok, but what would the maximum number of textures possible we can blend? say a tile has alot of textures on it (after all these tiles aren't that small, or will they?). For this approch it still could be an idea to split up the section into groups of textures or mixtures of textures, like:
all the Grass ones get rendered together,
all the Stone ones get rendered together,
all the Sand ones get rendered together,
all the Grass & Stone together,
all the Sand & Grass together,
ect...

Quote:

Posted by NoteMe
BTW when I talk about section I am thinking about deviding the whole terrain up in a grid and then we have the sections. When you are talking about tiles. Are you talking about the same thing then or is tiles when you speak 2 triangels next to each other forming a quad?

No I'm on about the same thing.
Jun 30th, 2004, 07:15 PM
NoteMe

Quote:

Originally posted by Electroman
Nope, there is only one VBuffer. All the data is stored in a format similar to the method used by the classes I posted before. I will do the classes for those in a minute.....

Here you say one..

Quote:

Originally posted by Electroman

We will have a CTerrain class but really it will be more of a 2D array of CTerrainSections and then the sections will be holding the data for all the vertices in that tile.

And here you say there will be many...??:confused:

I still don't get this.

What about that picture.

Will cTerrain have the VB with all the terrain code, or will cTerrainSection, have one small portion of the terrain in all their VBs...thats what I am asking about. Thats where I don't think we two agree..

Quote:

Originally posted by Electroman

Ok, but what would the maximum number of textures possible we can blend? say a tile has alot of textures on it (after all these tiles aren't that small, or will they?). For this approch it still could be an idea to split up the section into groups of textures or mixtures of textures, like:
all the Grass ones get rendered together,
all the Stone ones get rendered together,
all the Sand ones get rendered together,
all the Grass & Stone together,
all the Sand & Grass together,
ect...

Thats what we have the rendering queue for. It is supposed to sort them, so we don't have to change render states and so on so often.

And that is why I wan't all the "objects" we are going to draw on the screen to be derived from one "cOnScreen" class, so I can sort them, and call the render function for all the diffrent objects. Like one cTerrainSection, or one cThree, or what ever.

Quote:

Originally posted by Electroman

No I'm on about the same thing.

OK.

BTW you never answered the question I had about the Datatypes he is using. and the Data Pool he is using.

Should we use anything like it. Would we benefit from it?
Jul 1st, 2004, 06:09 AM
Electroman

Quote:

Posted by NoteMe

[QUOTE]
Here you say one..

[QUOTE]
And here you say there will be many...??

I still don't get this.

Well there is only one VBuffer and this is in the CTerrain. But the data used to fill it is stored in CTerrainSection but its not stored in VBuffers because its the raw data.

Quote:

Posted by NoteMe
What about that picture.

Yea I'm still getting round to it, I'm still thinking how the LOD will work with it.

Quote:

Posted by NoteMe
Will cTerrain have the VB with all the terrain code, or will cTerrainSection, have one small portion of the terrain in all their VBs...thats what I am asking about. Thats where I don't think we two agree..

Answered this further up ^ ^ ^ :D.

Quote:

Posted by NoteMe
Thats what we have the rendering queue for. It is supposed to sort them, so we don't have to change render states and so on so often.

k, so are you agreeing we should store them seperate? Otherwise I don't see how your gonna be able to sort them when its all megred as one.

Can we agree on how many textures should be used for our FVF? I suggest 8 seen as though we are already aiming at higher end cards, and if a card only supports 4 we can still just use two passes. What you think?

The main thing is though if a Vert only uses 2 textures then we are still storing it in a VBuffer that is holding 8 texture coords, is this a problem? Like say we have a card that supports a max of 4 will it be still making two passes just not doing anything on the second pass? I was wondering if we should be making seperate VBuffers for this, mind I suppose it would be bad to keep chnaging the VBuffer :(.

Quote:

Posted by NoteMe
And that is why I wan't all the "objects" we are going to draw on the screen to be derived from one "cOnScreen" class, so I can sort them, and call the render function for all the diffrent objects. Like one cTerrainSection, or one cThree, or what ever.

Is this including the terrain? If so I guess it would be the CTerrainSection's or maybe even at the level of these individual texture groups?

Quote:

Posted by NoteMe
BTW you never answered the question I had about the Datatypes he is using. and the Data Pool he is using.

Should we use anything like it. Would we benefit from it?

I rea in the book about the data pool but don't know if I understood it write. By the sonds of it when he was making allocations he made the allocation 4-5 times biger then next time just used one of those extra ones and if they had ran out made another 4-5 allocations at once. Is that right?
Jul 1st, 2004, 06:39 AM
NoteMe

Quote:

Originally posted by Electroman
Well there is only one VBuffer and this is in the CTerrain. But the data used to fill it is stored in CTerrainSection but its not stored in VBuffers because its the raw data

Answered this further up ^ ^ ^ :D.

k, so are you agreeing we should store them seperate? Otherwise I don't see how your gonna be able to sort them when its all megred as one.

OK. Lets agree on that. So we can get furuther into our project. I am starting to think it is better to leave the diffrent parts of the engine to each other. Like one is responsible for that. One for the Render Queue, one for the quad tree, one for the Sky Doom, and so on. That way we just have to agree on how they are going to work togheter. It's harder then I thought to agree on things over the internet when we can't talk and draw on big black/white boards and show each other..:D

PS: But the picture is still welcome..:)

Quote:

Originally posted by Electroman

Can we agree on how many textures should be used for our FVF? I suggest 8 seen as though we are already aiming at higher end cards, and if a card only supports 4 we can still just use two passes. What you think?

8 Is fine for a level. I can't see for me many leveles that have more then 8 textures for the ground in ONE section anyway. And there should still be no problem having more textures for trees, houses etc.

And yeah we can use 2 passes so older HW can support it too. Starting to think that DX effect files is a good thing. They can be coded so if the GPU can handle 8 textures per pass, then it will use it. If not then try 4, if not then try 2 and so on.

Quote:

Originally posted by Electroman

The main thing is though if a Vert only uses 2 textures then we are still storing it in a VBuffer that is holding 8 texture coords, is this a problem? Like say we have a card that supports a max of 4 will it be still making two passes just not doing anything on the second pass? I was wondering if we should be making seperate VBuffers for this, mind I suppose it would be bad to keep chnaging the VBuffer :(.

Not sure about this one. What do you think. Maybe we should ask someone else???..:ehh:

Quote:

Originally posted by Electroman

Is this including the terrain? If so I guess it would be the CTerrainSection's or maybe even at the level of these individual texture groups?

I have to think about this a bit more. but I think it is the cTerrainSections that have to be derived from "cOnScreen", becuase if it is cTerrainSection that will hold what textures it is using, then it is cTerrainSection that have the render function isn't it?

At least it is all those classes that has a render function. But it won't be that big changes to do afterwards anyway. It is just a ": public cOnScreen" and some small changes to the constructor I guess. So let me have some more time to "fiddle" (hehe..funny word. is it a word or did I just make a new one..:D) with the thought.

Quote:

Originally posted by Electroman

I rea in the book about the data pool but don't know if I understood it write. By the sonds of it when he was making allocations he made the allocation 4-5 times biger then next time just used one of those extra ones and if they had ran out made another 4-5 allocations at once. Is that right?

Yeah something like that. But isn't all the allocations made in the beginning of the level? Or at least if the terrain isn't bigger then the memory. If it is bigger then the memory, you have to load some later on I guess. But the Data pool holds all kind of things. But I can't see how that works even if they are derived from the same class...:(

OK wrap up:

Code:

LoadTerrain (Need to find a dataformat) cTerrain [Electroman] cTerrainSection [Electroman] Frame Coherency (SP?) LOD techinque (ROAM?) Rendering Queue [NoteMe] Sky Dome/box [NoteMe] Space Partitioning (quad tree?) Volumetric Fog cTexture

What do you think about this. Did I miss anything? And do you think it is a good idea to not work on the same thing. Or do you want us to work on the same thing?

BTW have you seen that Gaia has a VB class and a IB class? They also have functions to restore the buffers if the device is lost. We should probably have some functions like that too.
Jul 1st, 2004, 07:44 AM
Electroman

Quote:

Posted by NoteMe
OK. Lets agree on that. So we can get furuther into our project. I am starting to think it is better to leave the diffrent parts of the engine to each other. Like one is responsible for that. One for the Render Queue, one for the quad tree, one for the Sky Doom, and so on. That way we just have to agree on how they are going to work togheter. It's harder then I thought to agree on things over the internet when we can't talk and draw on big black/white boards and show each other..:D

PS: But the picture is still welcome..:)

Yea I'm still getting round to the class definition but I've not had a chance yet :(. As for the working on seperate parts I thought we had already agreed that? ;)

Quote:

Posted by NoteMe
8 Is fine for a level. I can't see for me many leveles that have more then 8 textures for the ground in ONE section anyway. And there should still be no problem having more textures for trees, houses etc.

And yeah we can use 2 passes so older HW can support it too. Starting to think that DX effect files is a good thing. They can be coded so if the GPU can handle 8 textures per pass, then it will use it. If not then try 4, if not then try 2 and so on.

Yea looking at the effect files from waht it says in the book looks good idea, it says you can even put PS & VS in them too :D.

Quote:

Posted by NoteMe
Not sure about this one. What do you think. Maybe we should ask someone else???..:ehh:

Yea I'll try and word it for the mailing list maybe?

Quote:

Posted by NoteMe
At least it is all those classes that has a render function. But it won't be that big changes to do afterwards anyway. It is just a ": public cOnScreen" and some small changes to the constructor I guess. So let me have some more time to "fiddle" (hehe..funny word. is it a word or did I just make a new one..:D) with the thought.

Yes its a real word :rolleyes: :D.

Quote:

Posted by NoteMe
Yeah something like that. But isn't all the allocations made in the beginning of the level? Or at least if the terrain isn't bigger then the memory. If it is bigger then the memory, you have to load some later on I guess. But the Data pool holds all kind of things. But I can't see how that works even if they are derived from the same class...:(

Quote:

Posted by NoteMe
OK wrap up:

Code:

LoadTerrain (Need to find a dataformat) cTerrain [Electroman] cTerrainSection [Electroman] Frame Coherency (SP?) LOD techinque (ROAM?) Rendering Queue [NoteMe] Sky Dome/box [NoteMe] Space Partitioning (quad tree?) Volumetric Fog cTexture

What do you think about this. Did I miss anything? And do you think it is a good idea to not work on the same thing. Or do you want us to work on the same thing?

BTW have you seen that Gaia has a VB class and a IB class? They also have functions to restore the buffers if the device is lost. We should probably have some functions like that too.

As I said further up I think we agreed on this before and I think it was along these lines:

Code:

LoadTerrain [I could do this?] cTerrain [Electroman] cTerrainSection [Electroman] Frame Coherency (SP?) [Electroman] LOD techinque (ROAM?) [Electroman] Rendering Queue [NoteMe] Sky Dome/box [NoteMe] Space Partitioning (quad tree?) [NoteMe] Volumetric Fog cTexture

As for the LoadTerrain I will be coming up with the data format so it might be easier if I do the load function? Seen as though I will be making the classes that the data will go in too then it would kinda make sense :D.

Volumetric Fog: Well I thought we weren't putting this in the first iteration? So it might be better to figure out who will do it when the tiem comes. That way we can see if one of us has lots of stuff to do then the other can. I have read the articles on it and it doesn't seem too hard so either of us could do it if you read the article too :D.

cTexture: I'm not sure what needs doing here so i think I will let you do that if you want to?
Jul 1st, 2004, 07:56 AM
NoteMe

Quote:

Originally posted by Electroman
Yea I'm still getting round to the class definition but I've not had a chance yet :(. As for the working on seperate parts I thought we had already agreed that? ;)

Yeah we kind of did...but this is like working on diffrent aspects of the engine. Not only the classes. I think it is a good idea. And like it when we agree to it...;)

Quote:

Originally posted by Electroman

Yea looking at the effect files from waht it says in the book looks good idea, it says you can even put PS & VS in them too :D.

Yeah encapsulation without overhead..:D..I will borrow the DX effect book from my friend in the weekend.

Quote:

Originally posted by Electroman

Yea I'll try and word it for the mailing list maybe?

Yeah that is a good idea. Then we can both be behind the scene and ask. Good idea. Just be strict on the terminolgy so we dare to ask more questions in the future..:D

Quote:

Originally posted by Electroman

Yes its a real word :rolleyes: :D.

Ohh...****...I thought I made that one up..:(..:D

Quote:

Originally posted by Electroman

As I said further up I think we agreed on this before and I think it was along these lines:

Code:

LoadTerrain [I could do this?] cTerrain [Electroman] cTerrainSection [Electroman] Frame Coherency (SP?) [Electroman] LOD techinque (ROAM?) [Electroman] Rendering Queue [NoteMe] Sky Dome/box [NoteMe] Space Partitioning (quad tree?) [NoteMe] Volumetric Fog cTexture

As for the LoadTerrain I will be coming up with the data format so it might be easier if I do the load function? Seen as though I will be making the classes that the data will go in too then it would kinda make sense :D.

Volumetric Fog: Well I thought we weren't putting this in the first iteration? So it might be better to figure out who will do it when the tiem comes. That way we can see if one of us has lots of stuff to do then the other can. I have read the articles on it and it doesn't seem too hard so either of us could do it if you read the article too :D.

cTexture: I'm not sure what needs doing here so i think I will let you do that if you want to?

Not sure why I added cTexture, but we need to have them stored some where so more then one cTerrainSection can use a Texture. No need to have them double stored in all cTerrainSections. And not sure (do you know it) but they might be lost if the device is lost. If so we need functions to restore them.

And yeah Sky Dome and volumetric fog and eather and so on is later on. Just added them. And the rest of the work looks nicly devided between us.

You can make the loader if you want. But I would be glad if you kept me updated on the file format. Becuase the changes and how it will work will have great impacts on the whole terrain engine, and I would like to have a word here and there too. But you can be the XO on it..:D If you keep me updated I can help you make the Map editors later on too you know..;)

I am affraid I don't have any time to work on it before I get home from work on Sat, but will try to borrow that book then.

Good job. Finaly we are getting somewhere.
Jul 2nd, 2004, 03:37 PM
NoteMe

I found a great new Game Programming page today.

http://www.devmaster.net/

And I found an intresting article about algorithms for indoor and outdoor game engines.
http://www.devmaster.net/articles/graphics_alg/

I have found 4-5 new pages lately about game and DX programming. Soon feeling ready to start off that DX post in the FAQ...;)
Jul 2nd, 2004, 03:41 PM
NoteMe

Ohhh....and look here...since we have had so many nice talks about Vertex Buffers. Here is even an article about good and bad programming practices reagarding VB uses..:D

http://www.gamedev.net/reference/art...rticle1946.asp
Jul 8th, 2004, 08:25 AM
Electroman

Quote:

Posted by NoteMe
Not sure why I added cTexture, but we need to have them stored some where so more then one cTerrainSection can use a Texture. No need to have them double stored in all cTerrainSections. And not sure (do you know it) but they might be lost if the device is lost. If so we need functions to restore them.

And yeah Sky Dome and volumetric fog and eather and so on is later on. Just added them. And the rest of the work looks nicly devided between us.

You can make the loader if you want. But I would be glad if you kept me updated on the file format. Becuase the changes and how it will work will have great impacts on the whole terrain engine, and I would like to have a word here and there too. But you can be the XO on it..:D If you keep me updated I can help you make the Map editors later on too you know..;)

I am affraid I don't have any time to work on it before I get home from work on Sat, but will try to borrow that book then.

Good job. Finaly we are getting somewhere.

Yea the cTexture is a good idea cos we do need to manage it in some way and it will also be good for the render queue and more than one section using it.

I've not had much time lately but I'll try and get some more stuff done as soon as I get time.

BTW those links looked good, I read one of them and glanced through the others but will read them properly when I get a chance. :D
Jul 8th, 2004, 10:02 AM
NoteMe

Yeah, I read through one of them...havn't had the time for the other one...

I havn't had much time either. But it is pretty intresting reading in the C++ Game book I have bought. I will do some speed test this weekend I hope on some diffrent implementations of the rendering queue. And see how it goes..
Jul 12th, 2004, 05:16 PM
NoteMe

OK...so how many times do you think a render function will be called each frame? So lets say that for one terrain section a terrain part of n*n "tiles" are drawn, and then you call render again and then a tree is drawn. And so on. How many objects do you think will be on screen at the same time?

At top 100? 300? 500? 1000?
Jul 12th, 2004, 05:31 PM
Electroman

Well if we break that up:

I think there will be about 15-20 at most terrain sections in view.

Then as for objects then it all depends on the map. Lets think though, a section is gonna have trees, grass clusters, small plants, & maybe some other stuff. A section that is jam packed will probably have about 20-30 different objects on it but obviously we can't have every tile like that and if the player can see 15-20 tiles then most of these will be in the distance and be areas without these objects on. To even thoings out lets assume 10 tiles in view have 25 different objects on and the others are empty, this should take care of half full tiles. So this gives us about This gives us about 270 so if we round that up to about 300. Sound good? Haha thats strange I just noticed 300 was one of your suggestions :D.
Jul 12th, 2004, 05:34 PM
NoteMe

Hehe...ok...lets say that first...so I can do some speed testings on the vtables....then I will let you know if we have a winner on the Rendering Queue..:D
Jul 12th, 2004, 06:21 PM
NoteMe

1 Attachment(s)

I hate this...this is not making any sense...that the order I do the tests has anything to say...I hate this..:D

If you want to play with it here you go..:D
Jul 13th, 2004, 07:49 AM
NoteMe

What the hell was ai Thinking about yesterday...I just realised that it wasn't 1 second every 1E6 call...it is a bit less then 0.01sec, that is 10ms in 1E6 calls...:D
Jul 13th, 2004, 05:44 PM
Electroman

1 Attachment(s)

Just wondering but how are we gonna texture the terrain? I had the thought because I was thinking, when the triangles are bigger (less detail, further away) then wouldn't they be spanning more than one texture? I drew a picture:
http://www.vbforums.com/attachment.p...postid=1735540

Take each of the boxes as if they are sections. The one on the left is in the lowest level of detail and the one on the right has had the detail increased in the bottom right corner. Now the orange square is meant to show the size of the texture, however you should be able to see the problem of how to set the texture coords for the left section. Also some of the tiangles in the right section would also come across problems.

A solution I can think of is that the textures are of the size of the sectiosn but in that situation is means that we won't have to worry about blending more than one texture. However it introduces a few other problems too, the amount of textures and size of them will be hurge and verticle (or near verticle) areas will suffer from distortion :(.

I think its possible to change the magnification or something on the textures or something that means the texture coords are like the textures are bigger and just tiled however thats would mean each terrain couldn't be rendered in on call as we'd need to keep rendering a few then switch the magnification and render more verts. What do you think? Which one do you think is best?

I think we could render the sections is multiple parts changing the magnification (if I'm using the right term :rolleyes:) but that would mean your render queue would need to deal with that over different terrains so that we can chnage the magnification only a couple of times for the whole thing?

Also as for the size of these sections I was thinking in the area of a section being 10m x 10m. And the maximum level of detail would make each section have 100 squares, so each square would be 1m x 1m. I'm not too sure whether we should make that 0.5m x 0.5m for the highest deatil though? Ow and the size of the textures (if we don't decide on them being the size of the sections) would be 1m x 1m.

Any thoughts?
Jul 13th, 2004, 05:54 PM
Electroman

Quote:

Posted by NoteMe
I hate this...this is not making any sense...that the order I do the tests has anything to say...I hate this..:D

If you want to play with it here you go..:D

BTW if you remove the cout or something like i++ then the results make sense ;). I meant to mention it to you last night but I wouldn't you agree that cout does ratehr a lot of stuff ;). each time you call it it access the console and prints the text, not to mention all the under code needed for that :D.

I changed your example to do just i++ and I get times like:

Code:

Time Parent: 6.65046e-006 Time Child: 6.32935e-006 Time Normal: 4.97855e-006

Which seem alot more reasonable ;).
Jul 13th, 2004, 06:10 PM
Electroman

1 Attachment(s)

Right I have another problem, mind I solved it while I was making the picture. Not sure about it though....

Right using the image in my other post I though well you can't just use the magnification thing becuase lets say its not all the same texture then how you meant to make it stick a different texture in half way though. Heres the pic:
http://www.vbforums.com/attachment.p...postid=1735545

Well my thought was to have a low res texture with them all in, after all it is far away when this happens. But Now there is the problem of these textures would need to be generated then :(. Which I'm not sure how this will work.

You should really get Morrowind and see there editor for the terrain, it has the whole terrain as a web and then you can lift and drop it and paint the textures onto it. It doesn't even distort the textures when you make the terrain really step :confused:.
Jul 14th, 2004, 01:59 AM
NoteMe

Quote:

Originally posted by Electroman
BTW if you remove the cout or something like i++ then the results make sense ;). I meant to mention it to you last night but I wouldn't you agree that cout does ratehr a lot of stuff ;). each time you call it it access the console and prints the text, not to mention all the under code needed for that :D.

I changed your example to do just i++ and I get times like:

Code:

Time Parent: 6.65046e-006 Time Child: 6.32935e-006 Time Normal: 4.97855e-006

Which seem alot more reasonable ;).

Yeah but the problem is that if you don't do anything in the loop, you can never be sure that the function is actualy called. I had that problem when I was testing Sqrt() functions. I just calculated them and didn't do anything with the results, and some times I got very weird durations of the functions. And a guy over at beyond3d.com told me that the compile some times skips a function (optimizes the code) becuae it is not used for anything. And the call to cin will take just as much time if it is a viritual function or a normal function. So the time diffrence will be the overhead of calling a viritual function (as long as we know it is called every time).

I tested it again, and noticed that for 10.000.000 calls we loose one frame. So if we have 300 calls per frame, then we will lose one frame per 33333 frame. And I don't think that is so much. I can do some testing for you, but I am pretty sure we will lose more if we ignore all the diffrent render state changes. Do you want me to test that too?
Jul 14th, 2004, 02:04 AM
NoteMe

About the tiles:

If you consider ROAM, then you know that near the camerea all the triangles will be divided as much as they can. So if the texture is that small, you know it will fit all the smallest squares.

Far from the camera they will be much bigger. Because they don't need so much details. And if they don't need so much details, then our textures probably don't need so much details. So then you can stretch the tile across the smallest square possible. People won't see on sutch a distance that you get less pixels per tile compared to per pixels on screen, on sutch a big distance, becuase it is so flat out there. And if it is some hill going upwards, then ROAM will split up the triangles there too, so then you don't need to strech the tiles so much either.

Did you get that? Or should I draw you a picture when I get home from work?
Jul 14th, 2004, 07:47 AM
Electroman

Quote:

Posted by NoteMe
Yeah but the problem is that if you don't do anything in the loop, you can never be sure that the function is actualy called. I had that problem when I was testing Sqrt() functions. I just calculated them and didn't do anything with the results, and some times I got very weird durations of the functions. And a guy over at beyond3d.com told me that the compile some times skips a function (optimizes the code) becuae it is not used for anything. And the call to cin will take just as much time if it is a viritual function or a normal function. So the time diffrence will be the overhead of calling a viritual function (as long as we know it is called every time).

I tested it again, and noticed that for 10.000.000 calls we loose one frame. So if we have 300 calls per frame, then we will lose one frame per 33333 frame. And I don't think that is so much. I can do some testing for you, but I am pretty sure we will lose more if we ignore all the diffrent render state changes. Do you want me to test that too?

Yea I guess but using i++ shows that the cout was doing alot of work, so I'd ignore the actual numbers with the cout test and focus of the differance between them ;).
Jul 14th, 2004, 07:53 AM
Electroman

Quote:

Posted by NoteMe
About the tiles:

If you consider ROAM, then you know that near the camerea all the triangles will be divided as much as they can. So if the texture is that small, you know it will fit all the smallest squares.

Far from the camera they will be much bigger. Because they don't need so much details. And if they don't need so much details, then our textures probably don't need so much details. So then you can stretch the tile across the smallest square possible. People won't see on sutch a distance that you get less pixels per tile compared to per pixels on screen, on sutch a big distance, becuase it is so flat out there. And if it is some hill going upwards, then ROAM will split up the triangles there too, so then you don't need to strech the tiles so much either.

Did you get that? Or should I draw you a picture when I get home from work?

I kind of get it but the problem is what texture should be streched across the distant triangles? Like say the distant triangle is far away and flatish and uses two textures, one stone & one grass. Which one would be used or would we be then needing to split the triangle to deal with that? Or does it just take the averages and which ever there is most of?
Jul 14th, 2004, 12:06 PM
NoteMe

If there is is two textures, then there is many solutions. You can deside for your self. But I can narrow it down a bit.

Lets say that the quad we are going to strech the tile over is now four times the tile size. Then there might be more then one visible tile. If we use the technique from the book, then actualy all of the tiles for that TerrainSection are stectched over that area. And uses the blend values to let one of them "shine" through more then the others. You could pick one of the four sqares and just strech it over the whol thing with the blend value. Or you could compute the average blend value for the four sqares. The last one will probably give the best visual appearence near texture changes.

Thats at least my 2 cents...
Jul 14th, 2004, 12:09 PM
NoteMe

Quote:

Originally posted by Electroman
Yea I guess but using i++ shows that the cout was doing alot of work, so I'd ignore the actual numbers with the cout test and focus of the differance between them ;).

Yeah, I am still aware that the cout uses a lot of time. But that is no problem, becuase it is using the same amount on time anyway. It is the diffrence of the two time results that counts. And I don't think loosing 1 frame for ever 33333 frame is that much when you think about it, at least not if we can gain on the texture stage changes and other render stages. Thats at least the idea. But there might be a small drop in the speed when we don't render more then just the terrain, but I hope we can see some improvements when objects are on the screen too....:)
Jul 17th, 2004, 10:05 AM
Electroman

Quote:

Posted by NoteMe
Lets say that the quad we are going to strech the tile over is now four times the tile size. Then there might be more then one visible tile. If we use the technique from the book, then actualy all of the tiles for that TerrainSection are stectched over that area. And uses the blend values to let one of them "shine" through more then the others. You could pick one of the four sqares and just strech it over the whol thing with the blend value. Or you could compute the average blend value for the four sqares. The last one will probably give the best visual appearence near texture changes.

So thats going back to the whole idea of there being textures that are the size of the tiles i.e. 10mx10m? But that way its saying there is a texture for each type of texture which all of them are 10m x10m. Or have I understood it wrong?
Jul 18th, 2004, 02:28 PM
NoteMe

I am not sure if I got you there. The way I ment is that all textures are the same width and height like 150px * 150px and then you tile them, and all the diffrent textures for a cTerrainSection are blended togheter and tiled ontop of each other. So a cTerrain section will have like e.g 4 textures that are tiled all over the section, on top of each other. If there is too few triangles far away from the camera, then we have to strech the tiles a bit. Does it sound good?
Jul 19th, 2004, 03:59 AM
NoteMe

BTW, will you soon provife me with a small drawing or something where you show me where what classes you are thinking about making, where the VB and IB are supposed to be, and what their relations are, and if you are going to use any inheritanse, and so on for the terrain? And of course where the Render() functions are supposed to be? ANd what classes you will have one instanse off and what classes you will have more then one instance of....thanks...ØØ

Show 60 post(s) from this thread on one page

All times are GMT -5. The time now is 05:04 AM.