[Nico]

Looking cool

[KARMA]

btw, will HT&L work fine even with non convex faces and faces with co-linear verts? and I suppose that faces should be also flat, right?

[phreak]

the engine will interpret them as triangles since

1: they are always convex
2: they are always coplanar

the only disadvantage to trangulating such a mesh would be to increase file size.  loading time is pretty fast as it is and we still have a limit of 25000 polies per subobject.  even though you can make a 20000 poly ship thats untriangulated, once it is triangluated it can exceed that limit and bad stuff will happen

on the other hand, this is an extremely nice model and i'm looking forward to it toasting ships in style

[KARMA]

Originally posted by PhReAk
the engine will interpret them as triangles since

1: they are always convex
2: they are always coplanar

the only disadvantage to trangulating such a mesh would be to increase file size.  loading time is pretty fast as it is and we still have a limit of 25000 polies per subobject.  even though you can make a 20000 poly ship thats untriangulated, once it is triangluated it can exceed that limit and bad stuff will happen

then what's the difference with retail fs2, except the polylimits??

[mikhael]

The conversion process, most likely.

[karajorma]

I think Phreak was talking about HT&L. Non HT&L has always had a problem with linear verts etc.

HT&L automatically triangulates the model so you should always leave as many quads and higher order polys in as possible as this will speed up loading time. Before you do make the model you should triangulate it and check that non of the subobjects have more than 25,000 polys though. Then convert the untriangulated version.

[mikhael]

With HT&L, you're passing your geometry to the card and letting it determine how to convert it to triangles for rendering. With non HTT&L, you'd have to triangulate the model in the conversion or modelling processes.

[KARMA]

mikhael, I may be wrong, but I think this was already happening before.
The gpus work with triangles, and they always triangulate the nontriangulated faces.
In fs2 retail, you don't have necessarily to triangulate your model at the end of the modelling process, nor I think was happening during conversion (elseway you should see a pof triangulated in modelview).
I made many untriangulated models for fs2 retail, in order to  go over the polylimits x subobject, you just had to don't go over 20 vertices for face, don't use convex faces, don't use colinear verts, don't use nonflat faces.
If I correctly understood, those limits are already present, except obviously the new huge polylimit ....then again, what's the difference?
I mean, you still have to stabilize the mesh if you don't want to triangulate
stabilize= manually subdivide non flat faces -if present-, convex faces, faces with colinear verts, faces with more than 20 verts..and let me say that this was bothering on 1000 polys ships, with 10000 polys ships it will be.....painful, to say the less

[Taristin]

Good to know.

[karajorma]

Originally posted by KARMA
I made many untriangulated models for fs2 retail, in order to  go over the polylimits x subobject, you just had to don't go over 20 vertices for face, don't use convex faces, don't use colinear verts, don't use nonflat faces.
If I correctly understood, those limits are already present, except obviously the new huge polylimit ....then again, what's the difference?  

With HT&L you only need to worry about the first of those problems. The way I understand it you don't have to worry about stabilsing the model at all because the way the HT&L build triangulates the model takes care of them for you.

You don't have to triangulate for either retail or HT&L Mikhael. It's just that many people do because either they are too lazy, inexperienced or use Max and have no other choice.

[StratComm]

You should still avoid faces that are blatently curved (mostly because UV mapping tends to **** itself if it can't resolve a normal) and cases where you've got either polygons inset in other polygons without any connecting edges (max won't let you do this, but TS does it like it was going out of style, especially when you boolean) or having faces which have inner angles greater than 180 degrees are generaly things to be avoided.

[KARMA]

ahhh ok, this changes things a bit
so you have only to get rid of nonflat faces (wich is easy) and of convex faces (wich still remain painful on ships with so many polys)
Well, I think that without a real polylimit to be aware of, I will go for an intermediate solution, just detriangulating the faces that I'm sure don't need to be splitted in triangles, but things may change after I'll try different strategies with the first HT&L ships

[mikhael]

Originally posted by KARMA

I made many untriangulated models for fs2 retail, in order to  go over the polylimits x subobject, you just had to don't go over 20 vertices for face, don't use convex faces, don't use colinear verts, don't use nonflat faces.

I think these problems (particularly non-convex polys and degenerate polys) were a consequence of the conversion process, or a just-in-time triangulation process in the game engine. Either way, these things would be solved because the game engine now passes off raw geometry to the GPU (before GPUs the game engine had to pass triangles only. triangle setup was done in software) and lets it figure out the proper triangulation.

[phreak]

actually the code is very hacked as it is.  in a perfect world we'd do tri-strips and use index arrays (hella fast).  we actually have it kinda go off the old code and just interpret each polygon as a triangle fan.  we then stuff the verts into a giant array and send that off verts are repeated unfortunately.  as long as the number of triangles after triangulation is under 25000 or something you should be ok.  i think bob remembers all the limits

Code: [Select]


opengl_vertex_buffer *vbp=&vertex_buffers[idx];

glEnableClientState(GL_VERTEX_ARRAY);
if (vbp->vbo_vert)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbp->vbo_vert);
glVertexPointer(3,GL_FLOAT,0, (void*)NULL);
}
else
{
glVertexPointer(3,GL_FLOAT,0,vbp->vertex_array);
}

glEnableClientState(GL_NORMAL_ARRAY);
if (vbp->vbo_norm)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbp->vbo_norm);
glNormalPointer(GL_FLOAT,0, (void*)NULL);
}
else
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
glNormalPointer(GL_FLOAT,0,vbp->normal_array);
}

glClientActiveTextureARB(GL_TEXTURE0_ARB);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
if (vbp->vbo_tex)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbp->vbo_tex);
glTexCoordPointer(2,GL_FLOAT,0,(void*)NULL);
}
else
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
glTexCoordPointer(2,GL_FLOAT,0,vbp->texcoord_array);
}

if (GLOWMAP > -1)
{
glClientActiveTextureARB(GL_TEXTURE1_ARB);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
if (vbp->vbo_tex)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbp->vbo_tex);
glTexCoordPointer(2,GL_FLOAT,0,(void*)NULL);
}
else
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
glTexCoordPointer(2,GL_FLOAT,0,vbp->texcoord_array);
}
}

if ((Interp_multitex_cloakmap>0) && (max_multitex > 2))
{
glClientActiveTextureARB(GL_TEXTURE2_ARB);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
if (vbp->vbo_tex)
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbp->vbo_tex);
glTexCoordPointer(2,GL_FLOAT,0,(void*)NULL);
}
else
{
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
glTexCoordPointer(2,GL_FLOAT,0,vbp->texcoord_array);
}
}


int r,g,b,a,tmap_type;

opengl_setup_render_states(r,g,b,a,tmap_type,TMAP_FLAG_TEXTURED,0);

if (gr_screen.current_bitmap==CLOAKMAP)
{
glBlendFunc(GL_ONE,GL_ONE);
r=g=b=Interp_cloakmap_alpha;
a=255;
}

gr_tcache_set(gr_screen.current_bitmap, tmap_type, &u_scale, &v_scale, 0, gr_screen.current_bitmap_sx, gr_screen.current_bitmap_sy, 0);

glLockArraysEXT(0,vbp->n_poly*3);

glDrawArrays(GL_TRIANGLES,0,vbp->n_poly*3);

glUnlockArraysEXT();


this code may interest mik as i think he does some OGL

[StratComm]

The only reason to prevent convex faces is that the GPU may decide to triangulate the model by connecting two verts between which the polygon does not exist.  What you then get is a funky squared-off poly on the end and a backfacing (not rendered) poly recovering the now-filled outside of the convex face.  Some ascii art to try to explain:

Code: [Select]


 _______
|\      \
| \      \
| /      /
|/      /
 -------

Ok, that looks right.

Anyway, what you'd get is this:

Code: [Select]


 _______
|       \
|        \
|        /
|       /
 -------

rather than this:

Code: [Select]


 _______
 \      \
  \      \
  /      /
 /      /
 -------


I've run into this rendering bug in Max before, so I know Freespace can't be any smarter about how it triangulates.  It's a computer after all, it has no way of knowing it's done it wrong when it screws up.

[mikhael]

The last time I looked at OpenGL was months ago, and the last time I looked at C++ was in May. I've been doign Python with SDL and not GL stuff at all of late. I'll take a look later when I'm at home though.

[phreak]

yes mik, i'm doing some VBO work and that may interest you.  I've seen terrain engines that use that push about 50 million tris/sec using them with a bunch of huge textures and lots of lights. on GF4s of course

[Sandwich]

Will someone move half the posts in this thread to the SCP forum? I gotta run.

[Turnsky]

it's the SCP ART thread

[Beowulf]

Woah.

Talk about gorgeous!