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

[Sergio Blanco]

No tienes al alcance ninguna libreria tipo clanlib que te haga la
abstraccion del 3d a 2d? Las librerias que he usado de este estilo me han
dado muy buen resultado (en plan 3000 o 4000 objetos con transparencia,
rotación, escalado y tintado en cualquier ordenata con una tarjeta antigua y
en plan 15000 en PCs un poco más cañeros ;-))

2008/5/1 Jon Valdés <juanval en gmail.com>:

> 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
>
> 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, 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 ;)
>
> taluegooo
>
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
>



-- 
divisionentrecero.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://listas.deusto.es/mailman/private/eside-ghost/attachments/20080501/28bf9380/attachment.htm