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.
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:.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.
- 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.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:.
- 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.
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 :(.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.
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?
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
- 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.
I don't get what the sentance was meant to mean :confused:. (And still don't)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.
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?
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....
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
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 :(.
Read my last post...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.
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
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?
NVIDIA say: Use big VB, then add to the end, not change the verts in the buffer. Becuase it is slow.Quote:
Originally posted by Electroman
I don't get what the sentance was meant to mean :confused:. (And still don't)
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?
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 :(.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.
Yea which page does it say this though :).
Page 201, and drawing 202.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 :).
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..
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 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.
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
You can pass more then one texture in one pass. I think my GPU supports 8 or 16 or something.
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
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?
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.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..
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
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.
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.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?.
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.
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
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?
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?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.
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 :).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.
And I was meaning I thought the max hardware was 8 :unsure:
(D3DFVF_TEX8 was the highest I can see).
K, understand that now.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.
The whole terrain data will still be stored in tiles (64x64 or 128x128) and this will be in standard memory.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?
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.
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, 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).
I am sooooo good..:DQuote:
Originally posted by Electroman
K, understand that now.
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?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.
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?
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
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?
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
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?
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: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?
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...
No I'm on about the same thing.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?
Here you say one..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.....
And here you say there will be many...??:confused: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.
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..
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.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...
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.
OK.Quote:
Originally posted by Electroman
No I'm on about the same thing.
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?
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
[QUOTE]
Here you say one..
[QUOTE]
And here you say there will be many...??
I still don't get this.
Yea I'm still getting round to it, I'm still thinking how the LOD will work with it.Quote:
Posted by NoteMe
What about that picture.
Answered this further up ^ ^ ^ :D.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..
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.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.
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 :(.
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
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.
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?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?
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..:DQuote:
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.
PS: But the picture is still welcome..:)
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.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?
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.
Not sure about this one. What do you think. Maybe we should ask someone else???..:ehh: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 :(.
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?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?
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.
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:
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?
OK wrap up:
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?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
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.
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
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 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
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 I'll try and word it for the mailing list maybe?Quote:
Posted by NoteMe
Not sure about this one. What do you think. Maybe we should ask someone else???..:ehh:
Yes its a real word :rolleyes: :D.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.
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...:(
As I said further up I think we agreed on this before and I think it was along these lines:Quote:
Posted by NoteMe
OK wrap up:
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?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
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 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.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
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?
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 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 encapsulation without overhead..:D..I will borrow the DX effect book from my friend in the weekend.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 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..:DQuote:
Originally posted by Electroman
Yea I'll try and word it for the mailing list maybe?
Ohh...****...I thought I made that one up..:(..:DQuote:
Originally posted by Electroman
Yes its a real word :rolleyes: :D.
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.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: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.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
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?
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.
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...;)
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
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.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.
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
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..
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?
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.
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
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
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
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?
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.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
I changed your example to do just i++ and I get times like:
Which seem alot more reasonable ;).Code:Time Parent: 6.65046e-006
Time Child: 6.32935e-006
Time Normal: 4.97855e-006
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:.
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).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:
Which seem alot more reasonable ;).Code:Time Parent: 6.65046e-006
Time Child: 6.32935e-006
Time Normal: 4.97855e-006
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?
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?
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 ;).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?
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?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?
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...
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....:)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 ;).
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?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.
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?
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...ØØ