pero... debería acotar qué superficie del plano testear para la colisión, no? un triángulo yace en un plano por definición y no significa que aunque mi cámara colisione con su plano lo haya hecho con el triángulo.  :ph34r:  

 eso de los enjambres, el polvo inteligente y la nanotecnología es precisamente el argumento del último libro de Michael Crichton: La Presa  :ph34r:  

 Gracias Vincent, no había caido en que podía descartar un buen ramal de triángulos (aunque sean visibles en pantalla) conociendo los bounds del colisionador.  (uoh)

Me haré un par de métodos que me retornen los triángulos de terreno localizados en base a un bbox o un vector y listo.

Saludos.

 Hola,

estoy echando un vistazo al tema de detección de colisiones sobre mapas de alturas. El caso es que en terrenos renderizados a diferentes niveles de resolución (léase Geomipmapping, ROAM, etc.) imagino que NO realizarán test de colisiones sobre el nivel de mayor resolución por el tema de la velocidad y tal. ¿Es cierto esto?  :ph34r:

el caso es que me parece un poco bestia, para un Tile de unos 512 triángulos (en mi implementación actual de geomipmap) testear un punto contra todos ellos para cada frame...

qué opináis?

 Haddd, gracias por el Doc. Muy buenas tus reflexiones  :D .
Sólo comentarte un detalle: Crees necesario tener que dividir por 2 tanto el FOV como la altura del BoundingBox del objeto? yo creo que esas dos divisiones sobran, dando el mismo resultado sin ellas.  :P

Ya me contarás.

 Hola, alguien sabe qué tipo de cálculos hay que realizar para ajustar la cámara de tal modo que un objeto 3D quede visualizado al tamaño máximo de pantalla?

Le he estado dando vueltas al asunto con la construcción de la matrix de proyección de la cámara pero no sé como hacerlo. Quizá ajustando el FOV al ángulo que forma la posición de la cámara y los mínimos y máximos del objeto?  :ph34r:


Saludos.

 Hola, estoy pensando implementar 'vertex tweening' para realizar 'geomorphing' entre LODs a la implementación de 'Geomipmaps' que desarrollo actualmente (joer con las palabritas técnicas  (asco) ). El problema es que utilizo, para los diferentes niveles de resolución una misma malla de vértices pero cada una con sus índices correspondientes (lo que me da virtualmente mallas diferentes).
Si no me equivoco, el vertex tweening realiza el morph de vértices entre dos mallas (se supone que diferentes pero con el mismo número de vértices) sin tener en cuenta los índices que apuntan a esos vértices.. es cierto ésto?  :blink:

Saludos...

 

¿y porqué no añades tu código al motor ? No tenemos nada de terrenos y puede ser una aportación muy valiosa para ambas partes.

Pues no me importaría. El caso es que estoy desarrollándolo para la empresa en la que trabajo y no puedo publicar código  :ph34r:

De todos modos, si decidís desarrollar sobre el tema de terrenos con Geomipmaps y os puedo echar una mano con posibles optimizaciones o desarrollo del algoritmo, no habría problema. Astat, otro miembro del foro, al parecer también ha desarrollado sobre este tema. Quizá él también os pueda aconsejar como lo hizo conmigo.

Saludos,

 Sí, ya sé que estáis varios coders con el motor, pero así llamaba tu atención en el Post  :P

Estuve utilizando en principio el que trae el FrameWork de DirectX para C# pero éste me parece más logrado. Good Job  ;)

Al fin he podido saber a cuántos 'fps' me rulaba el endemoniado algoritmo Geomipmapping que estoy codificando. Actualmente, con una textura, a unos 220 fps en ventana 1024*768 y con corrección de cracks (Ati Radeon 9200).  (twist)

Saludetes.

 joder Fiero, me has pillao. Eres un FIERA, colega!  (ole)  

 Hola Haddd, he estado probando el Timer que utilizas con el motor en C# para el cálculo de frames por segundo, y no sé qué coño estaré haciendo mal puesto que siempre me retorna en modo Windowed unos 70 frames por segundo, dando igual que renderice mis objetos con tropecientos triángulos o que simplemente haga un clear del Device a cada Frame y muestre la estadística de frames.  (nooo)

El caso es que aunque aumente el tamaño de la ventana no se aprecian diferencias significativas en el cálculo de frames. Sabes a qué puede ser debido?

yo inicio el timer tal que así:

Código [Seleccionar] Expand


[STAThread]
static void Main()
{
using (Form1 frm = new Form1())
{
 frm.Show();
 Timer.Start();
 while(frm.Created)
 {
  frm.Render();
  Application.DoEvents();
 }
 Timer.Stop();
}
}


y actualizo estadísticas después de cada Device.Present()

Código [Seleccionar] Expand


//inicio de la escena
DXManager.device.BeginScene();

//dibujo frames por segundo mediante un Font y DrawText
myFont.DrawText(null, "FPS: "+estadisticas.stringFps, new Rectangle(20,10,140,30), DrawTextFormat.Left, Color.Red);


//fin de la escena
DXManager.device.EndScene();

//mostramos resultado
DXManager.device.Present();

estadisticas.Actualizar();



Sabes qué demonios puede estar ocurriendo?

PD: No utilizo el FrameWork de tu motor sino que he adaptado la clase Timer del mismo y la struct Estadísticas a mi programa de testeo.

Saludos y gracias.

 Astat,  gracias por la captura. Me ha sido muy clarificadora.  (ole)
Quería comentarte si has necesitado implementar Geomorphing para evitar el "poping" entre cambios de LOD. He estado haciendo pruebas y algunas veces noto dicho efecto en el render de la malla texturada, por lo que quizá tenga que implementar esta característica mediante 'vertex tweening', lo que me obligaría a doblar la memoria para los datos de la malla que conforma el terreno.
También es posible que no haga los precálculos de distancia para cada cambio de LOD correctamente.  (nooo)

Cuando tenga algo runneable ya postearé una demo pa que la echéis un vistazo.

Saludos.

 Astat, una consulta. En la implementación que hiciste era posible que salieran dos patch o más que sean adyacentes a un nivel de LOD mayor que una unidad?

Me explico, uno con nivel de LOD 0 y el de al lado (da igual que lado) con nivel de LOD 4.

Te lo comento porque eso es lo que me está pasando y no sé si es correcto. Se que entre diferentes niveles de LOD tengo que ajustar el de mayor geometría al otro, pero me parece un poco extraño que haya lugares en el mapa donde se difiera más de una unidad entre uno y otro Patch.

Eché un vistazo al paper que me comentaste y está de p.. m..

 por cada nivel de lod, calculo la distancia en object space de cada vértice del lod contra el que supuestamente debería estar en el siguiente nivel para la misma posición XZ. De echo, ese supuesto vértice no existe en el siguiente nivel y se debe hallar la posición media entre dos vértices adyacentes al que estás testeando.  Para los que me hayan dado mayor distancia en object space de los vértices del lod que estoy testeando, cojo el mayor y su correspondiente del siguiente nivel (ese del que calculo la media).

Luego, a cada frame, proyecto estos dos vértices a screen space y calculo la distancia para ver si es menor que el máximo error que permita en la aplicación (usualmente 4 pixels de error).

No sé si éste es un método correcto para hacerlo  :blink:

Si no se me entiende... no me extraña!  (twist) Pregunta e intentaré aclarar los puntos.

Saludos,

 Buenas. Estoy realizando una implementación de Geomipmaps y no tengo claro algunos puntos.. Ahí van, por si alguno sabe del tema:   :ph34r:

- Es posible que dos patches conectados entre sí difieran en más de un nivel de resolución? por ejemplo, uno con nivel 0 (máxima resolución y otro con nivel 4 (muy poca geometría)

- A la hora de seleccionar un nivel de Lod, debo ir incrementando la suma de los errores entre uno y otro nivel de resolución de un Patch hasta llegar, como máximo, al límite definido en la aplicación?

Actualmente, para seleccionar un nivel de LOD, empiezo por el de mayor resolución, proyecto sus dos vértices que mayor distancia de error dan a screen space y acumulo la distancia obtenida en screen space para pasar al siguiente nivel de LOD. así hasta que llegue al tope permitido o al nivel de menor geometría.

Gracias de antemano.

Saludos.