[eside-ghost] extensiones C/C++ para Python

[altern]

Jon Valdés(e)k dio:
> 2008/5/1 Alberto M. S. <nohadonja en hotmail.com>:
>>  *Creo* que tu solución son las display lists. Las display lists son lotes
>> de comandos de dibujo que se compilan en la tarjeta gráfica y se quedan allí
>> para que los llames.
> 
> El asunto es que llamar a una display list, al igual que renderizar
> usando vertex buffers, o vertex buffer objects, tiene un pequeño
> overhead inicial, que aunque se puede despreciar cuando quieres
> renderizar objetos con muchos polígonos, para objetos pequeños no
> resulta en absoluto trivial.
> 
> Y el caso es que altern está hablando de objetos de 1 quad de tamaño
> cada uno, para los cuales deberías hacer para cada objeto, usando
> display lists:
> 
> glPushMatrix();
> glTranslate(posicionObjeto);
> glRotate(posicionObjeto);
> glCallList(listaObjeto);
> glPopMatrix();
> 
> Esto, teniendo en cuenta que cada glCallList dibujaría un único quad,
> probablemente supondría un rendimiento todavía peor que usar 4
> llamadas a glVertex :S

efectivamente en este caso no me sirve de nada pq los objetos pueden de 
posicion en cuaquier momento. Yo entiendo que lo de las listas tiene 
sentido en un mundo 3D donde estas moviendo la camara y puede que un 
objeto pero el mundo en si no se mueve. Pero no estoy seguro. en este 
caso todo puede moverse asi que no hay ninguna ventaja en usar esto.

> Por lo que comenta altern, y si no ha hecho alguna cosa un poco rara
> en el render, efectivamente tiene pinta de que el overhead de las
> llamadas de python a la librería de OpenGL es muy grande, y es lo que
> está comiendose la CPU. Así que, tal y como se temía él en un
> principio, probablemente tenga que reimplementar parte de la librería
> en C, de forma que minimice la cantidad de llamadas que haga entre
> código python y C.
> 
> Aun así altern, si puedes postear la parte del código que se encarga
> del render, se puede echar un vistazo a ver si estás haciendo alguna
> llamada de forma poco óptima.

bueno el codigo es medianamente complicado pq es parte de una libreria 
que gestiona los eventos, abre la ventana ... Os adjunto la parte donde 
se concentra las funciones OpenGL y la lista del render. Como vereis las 
funciones son bastante abstractas, puede servir para muchos casos, esto 
supongo que no es muy adecuado pero la cuestion es que las uso mientras 
desarollo protopipos y luego una vez tengo todo claro sobre escribo la 
funcion render de los objetos haciendo las llamadas OpenGL a pelo para 
sacar mas rendimiento. Creo que este modulo es el que tendria que pasar 
a C. Por cierto que antes era una clase dentro del modulo graphics.py 
pero despues de los emails de esta semana se me ocurrio que era mas 
sencillo tenerlo como un modulo con funciones. Siempre ayuda hablar con 
otra gente de los problemas de uno, se te ocurren soluciones.

Si quereis ver el resto del codigo esta en
devel.goto10.org dentro de ixi > python > mirra > mirra

en graphics estan las clases de los objetos graficos. hay una Base que 
es la que define todos los metodos de eventos, propiedades que necesito 
y tal y se añade automaticamente a la stack del engine. Las demas clases 
extienden esta.

si teneis alguna pregunta no os corteis que esto me ayuda.

> Bueno, y también puedes usar algún profiler de OpenGL, a ver si hay
> alguna llamada a OpenGL que se está comiendo cantidades ingentes de
> CPU. Los de Apple tienen uno cojonudo, y he usado también algún otro
> por ahi (el gdebugger por ejemplo) que no estaba nada mal. Google es
> tu amigo ;)

no sabia que esto existia, voy a mirar a ver. muchas gracias por la ayuda!

enrike
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : engine.py
Tipo       : text/x-python
Tamaño     : 19339 bytes
Descripción: no disponible
Url        : https://listas.deusto.es/mailman/private/eside-ghost/attachments/20080502/9dec7e60/engine-0001.py