void render(ttnode_t *root)
{
if(!root->c_left){ //if there''s no left child it''s a leaf node...
if((!memcmp(root->va,buffer,12))&& //compare the apex with the first
(!memcmp(root->vl,&buffer[bufidx-1],12)))//vertex in the buffer
memcpy(&buffer[bufidx++],root->vr,12); //and the next CCW vertex
else{ //with the last,if they match append the third to the buffer
glBegin(GL_TRIANGLE_FAN);
//else output the buffer and..
for(i=0;i[X],buffer[Y],buffer[Z]);<br> glEnd();<br> bufidx=0; //…flush the buffer<br> memcpy(&buffer[bufidx++],root->va,12); //copy the vertices<br> memcpy(&buffer[bufidx++],root->vl,12); //of the first tri<br> memcpy(&buffer[bufidx++],root->vr,12); //to the buffer..<br> }<br> return; //…and return<br> }else{ //…else recurse<br> if(!sw){ //switch the order in wich the nodes<br> sw++; //are visited at each level…<br> render(root->c_left);<br> render(root->c_right);<br> }else if(sw){<br> sw–;<br> render(root->c_right);<br> render(root->c_left);<br> }<br> return;<br> }<br>}<br><br>This is the code…I hope it won''t be messed up when I post it.I still don''t get though why you want it.I don''t have a problem with it,it works(although it might need some optimization),I just use the apex vertex as the center vertex of each patch every time wich isn''t very efficient.I need to choose a center vertex based on a test,and I don''t know what this test should be…<br>I''m not intrested in T&L H/W,and vertex arrays aren''t the best way to do it.At least that''s what I understood from reading the various docs and posts.The best way should be stripping but it requires more coding and I think I''ll settle with fanning for now. </i>

I am assuming that you go down the left child first. IIRC, you want to recurse down the tree alternating between L and R children. If I am not mistaken, when sw starts off as 0 the code starts off going down the L-L-R-L-R... children. You want L-R-L-R-L...

quote: Original post by JimmyP
void render(ttnode_t *root)
{
if(!root->c_left){
... Generate Fan ...
}else{ //...else recurse
if(!sw){ //switch the order in wich the nodes
sw++; //are visited at each level...
render(root->c_left);
render(root->c_right);
}else if(sw){
sw--;
render(root->c_right);
render(root->c_left);
}
return;
}
}

I''ll post my pseudo-code for the fan generation when I get home.

Well sw is initially 0 so !sw is 1 so if(!sw) is true so the left node is visited first...but first sw gets inced to 1 so when render(root->c_left is called the right child is visited first.Am I wrong???But then again...what about that best-center-vertex test?I believe thats the whole prob.See I always use va(apex vertex) as the first vertex in the buffer which is also the center vertex...

I need glasses 8| Sorry about that. It looks like you take care of that with one function call instead of my two, render(left), render(right)

Anyhoo, here's how I do the fan generation:

  if (apex  == start &&    left  == last) {   glVertex(right)   last = right   return}if (left  == start &&    right == last) {   glVertex(apex)   last = apex   return}if (right == start &&    apex  == last) {   glVertex(left)   last = left   return}if (start != -1)  {    glEnd();}glBegin(GL_TRIANGLE_FAN)if (onRightSide) {    glVertex(apex)    glVertex(left)    glVertex(right)    start = apex    last  = right} else {     glVertex(left)    glVertex(right)    glVertex(apex)		    start = right    last  = apex}return  

HTH



Edited by - _shawge on November 28, 2000 9:30:08 PM

Allright...first of all:What does this onRightSide mean and how do you decide if it''s true or false.Also..can you enlighten me on your termination condition?This if(start!=-1) when does this happen.Lastly how many tris/fan(average) do you get with this?

Basically the best-vertex-test I''ve been looking for is this onRightSide so that''s the most intresting part...Also the fact that you check all CW combinations(ie a-l-r,l-r-a,r-a-l) is very intresting and I feel pretty stupid for checking just on possibility(ie a-l-r)...

-=Jimmy=-

start and last are global variables that hold vertex info. start is initialized to -1 so that the tri fan can start. Once the fan starts, the start variable is no longer -1 and then there could possibly be a termination condition when the first 3 if statments fail.

onRightSide is a parameter that I pass along with the vertex info. It is true when the code is working on a R child.

I am seeing 3 to 3.7 tris/fan. Depends what kind of terrain I am rendering. There are also some more optimizations that should be added in (frame coherence) and the code should be run through the profilier to show the bottlenecks.

3-3.7 tris/per fan.I''ve tried the exact same thing ie. when I''m rendering a right child storing the apex first then the other is CW order and when rendering a left child the left first then the others and I get a max of about 1.85-1.90 tris/fan.What could e wrong??As for the frame cohernence I''m plannig to add that later.

BTW any idea why we store the vetices in these specific orders depending on wether the lft/right child is beeing rendered?

3-3.7 tris/per fan.I''ve tried the exact same thing ie. when I''m rendering a right child storing the apex first then the other is CW order and when rendering a left child the left first then the others and I get a max of about 1.85-1.90 tris/fan.What could e wrong??As for the frame cohernence I''m plannig to add that later.

BTW any idea why we store the vetices in these specific orders depending on wether the lft/right child is beeing rendered?

Perhaps it is with the buffers? Are you correctly counting the number of tris and fans? I really can''t tell from this side of the screen. You may want to use a small, single patch and render the fans/tris with different colors to see get an idea of what''s being generated. Print statments in certain places should also give more info.

The specific ordering is needed to maintain the correct winding order and to allow near perfect fan ordering.

I noticed something else as well...When you calculte variance tris for the patches,do you do it all the way down(ie for every single node?).I calculate variance down to a 8x8 square(ie until abs(leftx-rightx) or abs(leftz-rightz) gets smaller than 8).I saw that on a roam paper in gamasutra and I''m doing it to save memory(and computation time but this isn''t that important since variance computation is only done once).Now when I get to a node w/o variance info I keep splitting to the lowest level(according to the paper)but this way I often get unneeded tris cause even if the terrain at this point is flat it''ll keep splitting.As a result of all of this I don''t seem to get the best triangulation possible since the unneeded tris seem to use up the triangle budget...Any ideas?(maybe this bad triangulation is responsibe for not getting good tris/fan ratings?)

-=Jimmy=-