Borrar todas las primitivas gráficas dibujadas en pantalla

Started by Windgate, September 02, 2009, 08:05:06 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Windgate

Hola queridos amigos y amigas (Amigas... pffff... Como si hubiese alguna ::))

El caso es que estoy con el texturizado de mi visor 3D y utilizo draw_pixel() para ir pintando la textura punto a punto.

Con el wireframe lo tenía muy fácil porque memorizaba los ID de las líneas trazadas, y al generar un wireframe distinto me bastaba con borrarlas usando delete_draw(), no son generalmente muchas.

En cambio, en el caso del texturizado, el número de puntos pintados puede ser del orden de 800x600 e incluso más, así que me pregunto si existe alguna forma de borrarlos todos de pantalla sin necesidad de almacenar todos sus ID en una matriz y luego aplicar delete_draw() a cada uno de ellos... Ya que eso resulta ineficiente y el render ya tarda lo suyo como para derrochar ciclos de CPU adicionales.

He probado a dibujar un cuadrado negro, pero luego pinto sobre él y se sigue quedando negro... También he jugado con la profundidad de dibujado, pero me parece demasiada complicación...

Sinceramente, no me había puesto a trabajar "seriamente" con las primitivas de dibujo de Bennu hasta ahora.
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

Drumpi

Podrías probar a dibujar, en lugar de un cuadrado negro, los pixels que vas a poner a continuación directamente, en lugar de borrar y redibujar.
Pero de todas formas, es algo raro eso de que dibujes un cuadrado negro, a continuación otra cosa y aun así permanezca el negro. ¿Has comprobado drawing_map y drawing_color antes de pintar los pixels?
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Windgate

Entonces dices que dibujando el cuadrado negro luego debería poder dibujar sobre él sin problemas... Pues lo probaré otra vez, quizá el problema sea que hoy he entendido por fin el funcionamiento de drawing_color ( rgb (...) ) y tal vez estaba pintando con colores erróneos...

Lo de poner los píxeles nuevos directamente y sin borrar lo anterior no me sirve, porque el texturizado se hace sólamente donde hay polígonos, y donde no hay no pinta nada, entonces al redibujar pueden quedar residuos de la anterior, por ejemplo cuando desplazas el objeto.

clear_screen () es lo primero que probé, pero no sirve tampoco.

drawing_map () es algo que no he usado nunca... :P

Tranki Drumpi, voy a testear un poco más con eso del cuadrado y si sigo con problemas subo un ejemplo de código de los de 20-líneas-máximo ;D

THANKS!
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

Drumpi

Es que si borras la pantalla y vuelves a dibujar, pintas dos veces, por eso, lo que se hace, es usar los "dirty rects", que no es más que guardar información sobre qué zonas de la pantalla se han cambiado y deben redibujarse (no se si recuerdas los problemas que dierno con Fenix 084, porque estaban mal calculados).
Obviamente esto es una mejora que debe hacerse o desde el principio (por si hay que tenerlo en cuenta en el código general) o cuando ya se tiene todo medio hecho. En tu caso, déjalo de momento así.

Por cierto, no te comenté nada en el otro hilo, pero están geniales las texturas.
Hay un método que teóricamente es sencillo de aplicar, y consiste en calcular el ángulo entre la normal de la cara y la dirección del foco: si es 180º incide directamente y la iluminación es máxima, si es de 90º incide tan de refilón que no se ve y la iluminación es mínima, ángulos menores no se tienen en cuenta porque la cara está al reves (salvo que uses caras vistas por los dos lados). Entre medias, una relación cosenoidal.
La pega es que la luz apunta directamente a la cara, una luz omnidireccional no tiene problemas, pero si es un foco, ya tienes que tener en cuenta el radio de iluminación según la distancia y más cosas, pero para algo básico.
Splinter me comentaba anoche que tambien había que tener en cuenta los rebotes de la luz en los objetos, pero es lo que yo le decía: en motores de videojuegos no se suelen usar, sólo en contadas ocasiones (templo de la luz y escudo espejo en Zelda: ocarina of time) o en renderizaciones serias (3d studio, blender...)... A no ser que PS3 y 360 tengan suficiente potencia y programadores con ganas.

Good luck!!
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Windgate

lol lol lol

Nada de rebote de focos para lo que estoy haciendo. ¿Trazado de rayos se llama, no? O radiosidad si partes de superficie a cámara en lugar de partir de cámara a superficie... Se aleja MUY MUCHO de lo que estoy haciendo, para eso tenemos Blender y compañía...

Ciertamente, no quiero meterme en algo tan complejo ni mucho menos, tengo la estructura de datos y las formas de calcular las normales de polígonos... Tengo un pseudocódigo en Pascal de un "motor 3D de los años 80" y con eso espero obtener un render fotorrealista con iluminación por el método de Gouraud, pero ya he comprobado que la eficiencia no sirve ni para llegar a los talones a Bennu3D, OpenGL o algo similar...

A nivel teórico ya sé que en esos "render en tiempo real" que hacen en los vieojuegos en 3D no se utilizan más que aproximaciones  y "apaños" que facilitan el aspecto final... No es lo que pretendo conseguir ni de lejos... Pero como siempre, demos tiempo al tiempo xD

En resumen, he visto que lo que hago no servirá para motor 3D, es una simple "demostración" del "cómo se hizo..."

El borrado "eficiente" de pantalla antes de volver a escribir lo tengo como pendiente aún, sigo probando a ver si descubro algo, por ahora me preocupa la iluminación, que aún tiene mucho que descubrir :P
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

laghengar

Sois espléndidos tios, que os lanceis con estas cosas, mucha suerte, que vaya genial en ese proyecto.
!!!Blender Blender Blender yuhuuuuuuu¡¡¡ novato o_O

syous

Quote from: Windgate on September 03, 2009, 08:20:29 PM
lol lol lol

Nada de rebote de focos para lo que estoy haciendo. ¿Trazado de rayos se llama, no? O radiosidad si partes de superficie a cámara en lugar de partir de cámara a superficie... Se aleja MUY MUCHO de lo que estoy haciendo, para eso tenemos Blender y compañía...

Ciertamente, no quiero meterme en algo tan complejo ni mucho menos, tengo la estructura de datos y las formas de calcular las normales de polígonos... Tengo un pseudocódigo en Pascal de un "motor 3D de los años 80" y con eso espero obtener un render fotorrealista con iluminación por el método de Gouraud, pero ya he comprobado que la eficiencia no sirve ni para llegar a los talones a Bennu3D, OpenGL o algo similar...

A nivel teórico ya sé que en esos "render en tiempo real" que hacen en los vieojuegos en 3D no se utilizan más que aproximaciones  y "apaños" que facilitan el aspecto final... No es lo que pretendo conseguir ni de lejos... Pero como siempre, demos tiempo al tiempo xD

En resumen, he visto que lo que hago no servirá para motor 3D, es una simple "demostración" del "cómo se hizo..."

El borrado "eficiente" de pantalla antes de volver a escribir lo tengo como pendiente aún, sigo probando a ver si descubro algo, por ahora me preocupa la iluminación, que aún tiene mucho que descubrir :P

eso es raytracing  mira http://www.povray.org
Un Saludo
EL dia que la humanidad aprenda a mirar y sentir con los ojos del alma, recuperara su humanidad
http://sodonline.net/
http://darknessage.ayudaprogramacion.net/
http://www.ayudaprogramacion.net/

Proyecto: MMORPG
Completado: 2%
Estado: En Desarrollo...

Windgate

El visor este es para un trabajo que tengo que hacer en una asignatura que nos habla de todas esas cosas, pero a nivel teórico. Con el raytracing no me voy a meter, sólo Gouraud, ahora estoy empezando con el módulo :P

Todas las movidas estas de Raytracing y modelos de iluminación son muy interesantes, pero ya están todas programadas... Poco podemos aportar nosotros.

Por cierto syous, nos estamos saliendo del tema del borrado de las primitivas gráficas, el hilo del Visor 3D es el otro ;)

EDIT: Y gracias por los ánimos Laghengar! La verdad es que me estoy cogiendo un buen empacho de programar, espero que quede bonito :-X
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

Drumpi

Pues no te compliques: determina el ángulo de la luz (supuestamente colocada en el infinito y con todos los rayos paralelos en cualquier punto del render), compara con las normales y dale luminosidad según el ángulo y san sacabó :D

Respecto al hilo, se me ocurre que tengas una lista enlazada con todos los pixels no vacíos, y cuando vayas a dibujar la nueva figura compares los que tienes que dibujar con los que ya tenías: si están en la anterior y no en la nueva, se pone el pixel en negro y se borra de la lista, si es al revés sólo se añade, y si están en ambas sólo modificas el color.
Aunque también podrías representar la pantalla mediante 800x600 bits que indiquen si está usado o no ese pixel y actuar en consecuencia.
Yo suelto ideas, a lo mejor alguna te inspira XD
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Windgate

Es que eso no es el modelo de Gouraud y el trabajo lo exige... Tranki, ya he ido haciendo unas cosillas, de momento obtengo la iluminación de cada vértice, ahora falta interpolar entre la iluminación de los vértices para obtener la iluminación de cada punto de la textura xD

Eso de la matriz de 800x600 será la solución final que adopte... Gracias por todas las ideas.
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es

La momia que fuma

Para cargarse todas las primitivas de un plumazo se usa delete_draw(0). Con 0 como parametro te puedes referir a "todo" con otras funciones, como las de texto o los signals ;)

(Creo que hay definidas constantes (de valor 0 obviamente) para que el codigo sea mas entendible, en plan "all" o algo así, pero no estoy seguro ahora)

Windgate

Sí momia, creo recordar que al final tomé esa decisión... No tengo a mano ahora el visor 3D (Y créeme que después del empache de programar que me pegué me dolería volver a mirarlo :S), terminé consiguiendo borrar todo con una opción de menú implementada en 2 minutos así que sin duda usaría eso.
Iván García Subero. Programador, profesor de informática, monitor de actividades culturales y presidente de TRINIT Asociación de Informáticos de Zaragoza. http://trinit.es