En d3d

Point sprites no me convencen mucho, pq tienen limitaciones de tamanyo (64 pixels en la GF3)


Tener una lista enlazada decente (con amortizacion de alocaciones). Hacer la fisica y escribir linealmente a un VB dinamico quads ya orientados a camara. La orientacion puedes probarla a hacer por vshader, aunque no creo que ahorres mucho, 3 o 4 sumas de vectores 3d por particula. Si la particula no esta animada con una pagina de texturas, tb puedes pintar cada particula con un triangulo, aunque chupa algo mas de fillrate:

|
|*
|--

donde * es la textura.

El IB puede ser estatico y ser prealocado.                                

                                hay muchas maneras de hacer toon,

- la que comenta ithaqua
- usar la normal del vertice para indexar en un cubemap
- pintar un modelo un pelin escalado y negro con las normales invertidos
- usar pixel shaders para hacer diferencias en zbuffer (analogo a un metodo para hacerlo por software)
- etc...

Cada una tiene sus ventajas e inconvenientes                                

                                yf = yo*resy/2 + resy/2

quiero decir                                

                                te falta la transformacion de viewport que es la que mapea de coordenas proyectivas a pantalla

xf = xo*resx/2 + resx/2
yf = xo*resy/2 + resy/2                                

                                lo tipico es hacerte tu exportador e importador o usar un exportador a modo texto y hacerte el importador.

Alternativamente D3DX tiene la funcionalidad que necesitas

mac^threepixels                                

                                para cada vertice
 vertice.normal = 0, 0, 0

para cada cara
 calcular normal
 para cada vertice en cara
      vertice.normal += normal de cara
     
para cada vertice
   vertice.normaliza normal


Puedes modificar esto para tener en cuenta el area de triangulos para el peso de la normal, usar smoothing groups, etc... O(N), asi que no vas a poder hacerlo mucho mas rapido                                

                                Se llama subpixel (o subtexel para las texturas) y solo tienes que hacer lo que tu mismo decias, desplazar las coordenadas de textura desde el vertice hasta el punto de sampleo

Por ej

|
|
|  
|*
|__

Donde * es a donde 'redondeas' el vertice, tendras que interpolar las coordenadas de textura de los 3 vertices para saber cuanto valen en *.

Para las posiciones igual, si usas un DDA para rasterizar el triangulo, tendras que anyadirle al DDA los offsets que usas para redondear                                

                                Esa es la diferencia entre las opciones por defecto del IDE del visual C.

Si miras las opciones, puedes generar optimizaciones independientemente de la informacion de debug. Y si no te lo crees mira el output en assembly del compilador.

Te recomiendo que anyadas una configuracion mas aparte de debug y release donde tengas optimizaciones y informacion de debug

mac^threepixels                                

                                Primero, puedes debugar en release, sin ningun problema, dile al compilador que genere informacion de debug y ya esta.

Segundo, si subes el warning level a 4 te dara warnings cuando tengas variables no inicializadas                                

                                Generar los planos a partir de la matriz es bastante mas rapido.
                               

                                Tendrias que chequear las caps del dispositivo, para saber si lo soportan.

Pero te ahorrare el esfuerzo, no conozco ninguna tarjeta que rote sprites.                                

                                trabajar a nivel de poligono es mal en general trabajando con tarjetas graficas, no solo GPUs, aunque en GPUs se nota mucho mas.                                

                                El coste de transformacion es nulo en cuanto a que si dibujas vertices transformados no te va a ir mas rapido.

El octree lo deberias usar como descarte espacial.

Todas las caras que mandes cuestan, si no se dibujan, ha costado el que la tarjeta se traiga los vertices, los indices, y los clipee.

El descarte no lo hagas a nivel de poligono, sino a un nivel mas alto (objeto, por ejemplo).

Una cosa tipica es hacer un octree de objetos, no de poligonos.
                               

                                Si, las tarjetas T&L transforman bajo demanda. Eso quiere decir que si, que pueden transformar mas de 1 vez un vertice. De todas maneras tienen una pequenya cache (<20 vertices) donde pueden guardar los vertices ya listos para rasterizar.

De todas maneras, esto no es problema, ya que la transformacion es practicamente gratis (una gforce tira el mismo numero de polis/s transformando o sin transformar + o -), la cache ahorra principalmente ancho de banda y ahorra calculos de iluminacion
                               

                                Te procesara el rango que indiques en el DrawIndexedPrimitive.

Para un device software transformara todo ese rango.

Para un device T&L normalmente (GForce y ATI) da igual pq solo transformara bajo demanda.