Hola, pues me hallo toqueteando y probando las Direct3D y resulta que tengo el siguiente problema: Cargo un modelo y se me ve bien, lo roto y demás y entonces es cuando empiezan a desaparecer triangulillos, giro un poco más y vuelve a aparecer. Lo mismo ocurre si tengo un objeto detrás de otro, en determinados giros parte del de atrás se ve por delante del que realmente está delante. Tengo el zbuffer activado y el backface culling, el backface culling lo he probado de todas las formas (NONE, CW, CCW) y nunca se ve bien... alguna idea de que puede ser (porque ya está empezando a fastidiarme)?? Gracias.
Dices que tienes el zbuffer activado, ¿ no ? Vale, pero ¿ lo has creado ? :sonriendo:
Al llamar a CreateDevice, en los parametros asegurate de poner
EnableAutoDepthStencil = true;
AutoDepthStencilFormat = D3DFMT_D16; // por ejemplo
Tambien podria ser que no limpias el zbuffer en cada frame;
D3DDEV8->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0xFF800000, 1.0, 0);
Creo que sera alguna de esas dos cosas... :ojo:
(NOTA: no se si he escrito bien el codigo, pq de C no controlo.)
Holap, si hago las dos cosas que indicas (crear el zbuffer y borrarlo en cada tick) y de esto no es... en fin, gracias.
Si el problema lo tienes al rotar los objetos...¿no debe estar ahí el error? A lo mejor las matrices son incorrectas...
¿Porqué no pones el código y así lo vemos todos más claros?
Asegúrate de que los índices de tus triángulos están dispuestos de forma correcta, o sea que todos los triángulos se definen en el mismo sentido (clock-wise o counter clock-wise)...
Saludos
Hola de nuevo. El problema no creo que esté a la hora de girar ya que simplemente uso las funciones de d3d y en algunos modelos ya desde el principio desaparecen triangulos. En cuando al sentido de los vertices, lo he comprobado y todos son de la misma forma (CW). Ahora mismo no tengo el código aquí, mañana lo posteo. Saludos.
Hola! yo creo que las aceleradoras de ahora van tan rápido que se les pierden algunos triángulos sin querer, especialmente si no llevan textura al pesar menos... a veces se resuelve poniendo todos los triángulos en fila india y contándolos a mano a ver si están todos, si alguien tiene una solución menos engorrosa por favor que lo diga!! gracias!
:loco:
Hola, la 'desaparición' de poligonos también ocurre con modelos de 1000 y pico caras y 10 texturas, por lo que echarle la culpa a la tarjeta creo que puede descartarse. Saludos.
Creo que BeRSeRKeR puede tener razón, recuerdo muy bien los primeros problemas que tuve en el momento de renderizar triangulos, Bueno solamente escribo esto para que te asegures que realmente todos se encuentran definidos en el mismo sentido
Saludos
Citar
Hola! yo creo que las aceleradoras de ahora van tan rápido que se les pierden algunos triángulos sin querer, especialmente si no llevan textura al pesar menos... a veces se resuelve poniendo todos los triángulos en fila india y contándolos a mano a ver si están todos, si alguien tiene una solución menos engorrosa por favor que lo diga!! gracias!
:agh: ¿lo cualooooo?
¿Tarjetas que pierden poligonos por pesar poco? ¿poligonos en fila india para contarlos a mano? ¿Mama pato pierde a sus patitos si no los lleva en fila india?
:loco: No se los demas, pero yo no se por donde coger tu mensaje...
Al ricooooo, al ricoooo polígonoooo:
A ver, 3/4 de kilo de poligónos pero que esten fresquitos. Y no me los des sin textura, que estan muy sosos. No, ese no, que pesa mucho y luego se cae.
[ Este Mensaje fue editado por: Loover el 2002-05-22 12:53 ]
Yo tengo un primo que tiene un colega que una vez perdió un polígono.
Revisa los rangos near y far para ver si estas exagerándolos demasiado y pierdes precisión de z-buffer.
Seguramente sera eso, que no has definido bien el Frustum. Yo tengo algo asi:
// Proyeccion (fov, pantalla, plano cercano, plano lejano)
D3DXMatrixPerspectiveFovLH (&mat, D3DX_PI/6, float(width/height), 1.0, 100.0);
g_pDevice->SetTransform (D3DTS_PROJECTION, &(D3DMATRIX)mat);
Prueba a cambiar el plano lejano, dandole valores más altos. Puede que sea este el problema.
Al revés, el plano far cerca.
El near siempre debe estar lo más lejano posible y el far lo más cercano.
No hay valores near y far 'recomendables', depende de cada escena, pero siempre se tiene que hacer lo posible por acotar los rangos que vamos a necesitar.
Pues que raro, porque en Opengl utilizo:
gluPerspective(90.0f, (GLfloat)width/(GLfloat)height, 5.0f, 3000.0f);
Que es la equivalente a la de direct 3D (los dos últimos valores son el near y el far) y de esta manera visualizo correctamente el mapa de quake 3 que cargo. Si pongo de far 5 y de near 3000... pues se ve un churro.
Aún no he cargado ninguna mapa con direct 3D, puede que en este se comporten de manera diferente los planos far y near... pero lo veo ilógico.
¿Estas seguro Ithaqua?
Lo que dices va contra la definición de frustum... imagina un cubo que corta la zona que se va a representar... la cara cercana (el plano cercano) debe estar más cerca que la lejana... sino los póligonos más lejanos, se renderizan por encima de los más cercanos (por eso digo que al cambiarlo se veía un churro).
[ Este Mensaje fue editado por: Loover el 2002-05-22 17:19 ]
Creo que Ithaqua se referia a que hay que apurar al máximo los valores. Es decir, poner el near plane todo lo lejos posible y el far todo lo cerca posible, PERO por supuesto siempre siendo NEAR < FAR.
Hola, pos más o menos hago esto:
//Para iniciar el 3d3:
m_pD3D = Direct3DCreate8(D3D_SDK_VERSION);
m_pD3D-> GetAdapterDisplayModeD3DADAPTER_DEFAULT, &d3ddm)
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = true;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = d3ddm.Format;
d3dpp.EnableAutoDepthStencil = true;
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
m_pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, d3dpp, &m_pD3DDevice);
//Lo del renderstate
SetRenderState(D3DRS_CULLMODE, D3DCULL_CW);
SetRenderState(D3DRS_ZENABLE, TRUE);
SetRenderState(D3DRS_LIGHTING, FALSE);
// Al dibujar
Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(255,255,255), 1.0f, 0);
BeginScene();
// Origen camara vale (0.f, 0.f, -2000.f) y
// destino camara vale (0.f, 0.f, 0.f)
D3DXMatrixLookAtLH(&matView, &m_vec3OrigenCamara, &m_vec3DestinoCamara, &D3DXVECTOR3(0.0f, 1.0f, 0.0f));
SetTransform(D3DTS_VIEW, &matView);
// Pongo 1000.f pal far, pero he probao con
// valores mas cercanos y mas lejanos
D3DXMatrixPerspectiveFovLH(&matProj, D3DX_PI/4, 1.0f, 0.f, 1000.0f);
SetTransform(D3DTS_PROJECTION, &matProj);
EndScene();
Present(NULL, NULL, NULL, NULL);
Los modelos los cargo de un fichero generado por un plugin del max que va bien. Todos las caras llevan sentido CW. No desaparecen siempre las mismas caras, es decir en el momento 0 se ve la cara frontal (p.e.), giro un poco la camara y ya desaparece este cara.
Ufff, q coñazo que he metido... un saludo y gracias.!
P.D.: Por cierto, cual es la mejor forma de tener almacenado un modelo? yo ahora tengo un array con los vertices, otro con las texturas y por cada textura un array con las caras de esas texturas, luego al dibujar voy componiendo y dibujando triangulo a triangulo (¿una forma estúpida?). Lo he hecho de esta manera para no duplicar los vertices cuando sus valores U,V son distintos... por ello repregunto otra vez: cual es la forma más rapida para hacer todo esto?? (pintar modelos:). Gracias otra vez.
Citar
D3DXMatrixPerspectiveFovLH(&matProj, D3DX_PI/4, 1.0f, 0.f, 1000.0f);
no estoy seguro pq no tengo el sdk a mano, pero yo diria que tienes el near plane a 0! :agh:
Ponle por lo menos un 1 o 0,5 ...
D3DXMatrixPerspectiveFovLH(&matProj, D3DX_PI/4, 1.0f, 1.f, 1000.0f);
En cuanto a la mejor forma de dibujar modelos, no existe una unica forma. Depende de lo que quieras hacer, como sea el modelo, etc.... se suele decir que lo mejor es usar primitivas indexeadas con triangle-strips (si no recuerdo mal)... pero esto no es siempre posible o recomendable...
Intenta evitar siempre el enviar los poligonos de 1 en 1.... lo mejor es enviarlos por lotes, evita los cambios de estado (render states) y si usas TnL HAL evita tambien cambiar de Stream Source (VB switching)
Ademas, existen bastantes diferencias entre HAL y TnL HAL de modo que lo que en el primero puede ser un metodo optimo, en el segundo puede ser una barbaridad.... (como el uso de ProcessVertices por el que yo preguntaba en otro hilo)
_________________
SaludoteZ de Lord Trancos!
www.dxlab.tk - programación de DirectX con Delphi.[ Este Mensaje fue editado por: Lord Trancos el 2002-05-22 18:36 ]
Loover: me refería a apurarlos lo más posible, pero siendo near < far claro.
Malandrín: pon el near a 1.0f
Iujujuuuuuuuiiiii... pues si, esa era la solución, cambiar el near a 1.f, ahora ya va bien, gracias a todos!!.