batch batch batch...

[DraKKaR]

                                el batch es una utopia.. XDD
Me he estado carcomiendo la cabeza para poder agrupar el mayor numero de poligonos en un VB para lanzarlo todo a la tatrjta de sopeton, ke es como dice nvidia como hay ke hacer.. mandar el mayor numero de vertices de golpe... con eso en mente.. me he creado 2 vertex buffers dinamicos.. uno para la geometria del mapa y otro para la geometria de los otros objetos... he creado 2 VB porke contienen FVF diferentes, simplemente por eso. De esta forma.. cuando el engine keria pintar algo.. en realidad no se pintaba.. simplemente se añade al VB ke toca. De esta forma al finalizar de añadir todo, se enviaba a pintar todo junto.

Pero hete aqui el problema... para que todos (o gran parte) de los objetos que se querian renderizar se pudieran renderizar de golpe, tendria ke cumplirse que tuvieran las mismas texturas, matrices de transformacion y demas paramertos de render... pero esto en un juego no es posible! no hay ningun objeto ke tenga ni la misma matriz de transformacion, ni las mismas texturas, etc. Por lo tanto, intentar agruparlo de esta forma, es peor que renderizarlo segun te venga, pq vas a poder renderizar solo la misma cantidad de vertices de golpe (porlo ke he dixo antes) pero perdiendo paralelismo con la CPU porque lo haces todo al final...

Por lo tanto, la forma en que enfocare ahora el problema sera la siguiente:
Me creare un unico VB dinamico para meter ahi toda la geometria. Cuando algo kiera pintarse.. simplemente descarto el contenido del VB, lo meto dentro y pinto.... En un juego lo normal es usar modelos que tengan mas o menos 2000 polis, por lo que cunpliria lo ke dice microsoft de enviar mas de 2000 polis de golpe.
Lo malo es que tb pueden haber objetos de pocos poligonos (como items y cosas asi) que se renderizarian por separado.. pero tampoco podrian renderizarse todos a la vez pq tiene diferentes matrices de transformacion... lo unico que se podria para paliar un poco esto es: antes de descartar el contenido del VB mirar si la geometria que ya hay metida es la misma que la que se quiere pintar, si es asi ya esta en el VB y solo tengo ke pintarla.


Todo esto una reflexion ke se me ha ocurrido mientras estudiaba pa un examen ke no tiene nada ke ver con esto XDD..
Ya me comentareis ke os parece todo esto..                                

[Haddd]

                                Yo pensé mucho con esto incluso puse aquí un post con unas pruebas. El resultado es que NO hay que hacer caso de lo que dice NVidia porque pierdes ese paralelismo del que hablas. Tiene sentido cuando hay pocos polígonos y muchos objetos, pero hoy en día donde el nº de polígonos es bastante grande, no creo que NVidia esté deacuerdo con lo que dijo hace muuucho.

De hecho en mi motor yo optimizaba mucho ordenando por texturas y luego dibujando los objetos. Y el truco estaba en que el tiempo que había entre el render de 2 objetos lo utilizaba para calcular la posición del vértice una vez aplicada la matriz de transformación. Y se notaba una barbaridad el paralelismo. Antes el engine tenía que ser óptimo en cuanto a velocidad, pero hoy en día el engine tiende a ser potente y fácil de utilizar, y todos estos rollos que se hacían para ganar velocidad sólo complican el tema. Yo soy partidario de obviarlos ya hoy en día, porque con los NPatches, Displacement Maps y perpixel lightning,  las cosas cambian mucho!!                                

[chaman]

                                El problema no es tanto el cambio de textura. Es cierto que hoy en día no afecta demasiado a la velocidad... Mucho más importante es por ejemplo, cambiar de vertex o pixel shader o tener que desechar un vertex buffer.

Los problemas venían sobre todo en tarjetas con poca memoria (16 mb, 32 mb) donde las texturas muchas veces residian en memoria AGP y se subian cuando se activavan a la memoria de video.

En cualquier caso lo que dicen tanto nVidia como ATI es que hay que hacer batch no solo por el cambio de texturas sino por el número de llamadas a draw primitive que acabes haciendo.

Hay que tratar de compactar las llamadas. Ya se que es muy complicado, cada cambio de material es una nueva llamada, pero si tienes varios objetos sueltos que usenel mismo material y eres capaz de insertarlos en una sola llamada estás ganando bastante.

Lo que no se puede hacer es como en el quake, pintar tráangulo a triángulo... Pero vamos, que todo esto depende mucho de como te montes las tripas de tu motor...

Yo me acuerdo que cuando salio la gForce4, los tios de nVidia decían que podias aumentar el número de texturas que usabas, los efectos que aplicabas y el número de triángulos finales por frame, pero que el número de llamadas a drawprimitive no se podia cambiar respecto a una gForce3...

A ver si encuentro una presentación que tenian en la web de nVidia explicando el tema...                                

[_Grey]

                                [Contestando a DraKKaR]

TEXTURAS.
Si ordenas por textura conseguiras velocidad, y recuerda, que nada te impide que en una misma textura, esten varias imagenes independientes, todo el decorado podria tener la misma textura, y en esta podria haber tanto la imagen de paredes como de suelo como puertas , incluso si te viene en gana la de algun objeto independiente comun en el decorado.

GEOMETRIA.
Vale que cada objeto tiene una matriz de transformacion independiente, pero tienes otras soluciones, si se trata de muchos objetos calcula TU su posicion en coordenadas del mundo y pasalo al vertex buffer general, luego lo podras pasar sin cambiar la matriz de mundo, y si usa la misma textura de una sola llamada a drawPrimitive(¿Index?)();, si usas muchos objetos con matrices distintas mejor esto que llamar 40 veces a drawPrimitive(¿Index?)();, aunque pierdas la aceleracion por Hardware, ahora bien si tienes un objeto de miles y miles de vertices "staticos" te recomendaria que lo pusieras en un vertex buffer STATIC, si todos los poligonos usan la misma textura, fenomenal! un solo drawPrimitive(¿Index?)(); !!!!

Para finalizar, eso que dices de:
"no hay ningun objeto ke tenga ni la misma matriz de transformacion"

Tendriamos que ponerlo en comillas (huy! si es lo que he hecho), por que ? pues por los "vertex shaders", muchos de nosotros no los podemos usar por que las pelas no llegan a una targeta ultimo modelo, pero con ellos podrias tratar un vertex buffer como si tubiera varias matrizes, solo tendrias que poner estas en las constantes del vertex shader, y dentro del FVF un datos indicando que matriz le toca, de esto te tendras que informar tu, por que no tengo el Hardware suficiente para estas cosas.....

PARA FINALIZAR.
Si usas un mismo FVF para tus vertex buffer mejor y a menos vertex buffer a usar mejor, por ejemplo uno STATIC con objetos grandotes staticos, y otro DINAMIC para hacer las guarrerias!
Si tienes una targeta con vertex shaders por hardware, aprobecha y usa vertex buffer STATIC.

Pero esto de los vertex shaders........ que alguien con experiencias nos cuente.....

Saludos.                                

[DraKKaR]

                                Haddd, recuerdo aquel post que pusiste el verano pasado. Tu sostenias que es mejor renderizar las cosas en cachos pequeños segun te vaya viniendo, que es lo mismo que dices ahora, para aumentar el paralelismo. Tambien me aceurdo que mucha gente del foro estaba en desacuerdo contigo y decia que es mejor todo lo contrario, enviar los paquetes lo mas gordos posibles. Lo mismo ocurre ahora con _Grey, el contradice tu posicion y dice que cuantas menos llamadas a DrawIndexzedPrimitive mejor.
A mi me hace gracia que este tema, que deberia ser algo estandar, que todo el mundo dijera lo mismo, pero cada uno parece ke tenga su propia teoria sobre le tema.
Hadd, hacerlo de la manera que tu dices me atrae pq creo que es mas sencilla que la de las demas, ademas dices que asi se aumenta el paralelismo entre la CPU y la GPU y eso suena bien.
Por otra parte, chaman y Grey, yo ordeno toda la geometria del mapa por texturas, y hago tantas llamadas como texturas tiene el mapa.Sobre todo lo demas, tomo nota de todo lo ke habeis dicho.. supongo que para elegir la mejor manera de hacerlo tendre que escribir varios renderers y ver los resultados.

Sobre lo de usar un Vertex Buffer estatico y otro dinamico, esa era mi idea inicial. USar uno estatico para dejar ahi toda la geometria del mapa, y otro dinamico para subir los objetos y todo lo demas. Aunque ultimamente estaba pensando en usar un unico VB dinamico para meter ahi todo, asi me evito cambiar de VB pq es costoso, pero tb pierdo mas tiempo con locks y rellenar VBs. Que lio... si es que en cada sitio dicen una cosa! v.V


Gracias a todos por las respuestas.

PD: HAddd como llevas el motor? a ke te dedicas ahora? hace tiempo ke no se nada de a ke te dedicas.. soy un seguidor oculto XD                                

[Haddd]

                                ¡Lo mejor es hacer pruebas y probar los dos sistemas!

Pues ahora estoy aprendiendo los shaders. Intento utilizar NPatches,adaptative tesellation, displacement mapping para la geometría y pixel shaders para las luces, es decir, 100% DX9 compatible, aunque yo no tengo tarjeta y utilizo el rasterizador por software!!

Pero es muy complejo y hay poca información, no creo que tenga algo mínimamente visible hasta dentro de unos meses.