Yepa otra vez
Pues si, el LiSPSM tiene buena pinta y en su web tienen una demo (un poco cutrillo, creo yo  :() y un video que creo yo tiene buena pinta. Es mas, se comparan 3 tecnicas: shadow maps uniformes u homogeneos (creo que es el shadow map "pelao"), el PSM y el LiSPSM.
Estaria muy bien implementarlo en el juego (genial). Lo malo es que necesita de Geforce 3 para arriba (lo de siempre, pixel shaders), y no se si con eso se hace una criba demasiado estricta.

Hombre, el SM lo veo muy eficiente a partir de tarjetas con shaders, ya que puedes aprovechar mucho las posibilidades que te da. Si no tienes una GF3 (incluso GF4 Ti) deberias olvidarte de los shadow maps y esperar que tu CPU sea suficiente potente para extraer (y extruir) los shadow volumes. O sino te conformas con un circulo proyectado a modo de sombra (twist)
Las sombras de calidad necesitan hardware un poco decente (las GeForce 4 o FX deberian ser un estandar ya, valen cuatro duros... lo mismo digo con ATi).

Supongo que al final implementare TSM o LiSPSM, aunque antes tendre que estudiarme los papers a ver si encajan bien en mi proyecto. Segun he visto por los videos de TSM (son 2 ficheros comprimidos de 60MB cada uno), da buenisimos resultados. Se ven comparativas entre varios algoritmos (BB, PSM, TSM) de los mismos walkthroughs por distintos escenarios y la verdad que TSM machaca al resto. Me hubiese gustado ver una comparativa de TSM vs LiSPSM.

 Si, es nvidia la que recomienda no usarla. De hecho hay una frase que dice "friends don't let friends use PSM" o algo asi :lol:
Es que si os mirais el paper es un jaleo entenderlo y mas aun implementarlo, ademas que tiene fallos de concepto que aun hacen que sea mas dificil. Por eso decia que lo mejor es implementar TSM (conozco mas casos que lo han implementado satisfactoriamente) o LiSPSM (de este ultimo creo recordar que hay una demo en su web).

Haddd, ¿tu crees que hacer sombras por raytracing en al GPU sera una buena opcion? creo que se comeria demasiados recursos como para usarlo en juegos (creo que el relief mapping con siluetas usa algun tipo de raytracing y es costosisimo, aunque queda impresionante).

 Haddd, si esta patentado el TSM, o al menos pendiente de patentar, pero diria que solo en EEUU (al menos no en Europa aun) se pueden patentar metodos o algoritmos, y que aqui no se reconocen dichas patentes. Es el mismo caso que con la patente del Carmack's Reverse para sombras.
Ademas, si no vas a hacer algo para el mercado multinacional de millones de dolares no creo que tengas problemas con dichas patentes :)

He estado mirando el capitulo de nVIDIA GPU Gems 2 sobre PSM. Han hecho varias modificaciones para que corra en la GPU y subsanar algunos fallos que habia en el paper original. Da buenos resultados a juzgar por los screenshots.
A ver si me miro otras implementaciones, como TSM (creo que es el mas facil de todos y el que da mejores resultados) o LiSPSM (aun no he visto comentarios en ningun sitio, pese a que tiene muy buena pinta y no parece tan dificil de implementar).

Una de las desventajas que yo le veo, aparte del aliasing, es el tener que utilizar un offset para que las sombras salgan bien, me refiero al "z bias". Nosotros lo resolvemos renderizando las caras posteriores en vez de las frontales en el depth map. De esta forma podemos utilizar un zbias de 0. Pero hace poco he leído una técnica que se utilizó en una película utilizando RenderMan, que lo que hace es renderizar en el depth map las caras frontales, las caras posteriores y luego hace una media entre ambas y ese depth map es el que se utiliza. Evidentemente tiene la desventaja de que son dos pasadas. La media se podría calcular en el pixel shader.

¿No teneis problemas cuando mirais el modelo desde atras? Es decir, si dibujas las caras de atras, cuando mires el modelo desde atras (en sombra) esa zona tiene la misma profundidad que la guardada en el depth map, asi que puedes tener tambien flickering en la sombra que hace sobre si mismo, con lo cual deberias usar un bias, ¿no? Sino, ¿que ventaja tiene dibujar las caras de delante? todo el mundo dibujaria las de atras :huh:

[QUOTE]

 

QUOTE (zupervaca)

A mi lo que me gustaria saber es como tienen pensado los gurus hacer las sombras cuando se creen vertices en el propio shader.[/quote] Ya lo hacen, mediante shadow mapping. Hace un tiempo vi un tio en los foros de OpenGL que habia hecho un shader de relief mapping dibujando los contornos. Sencillamente genial, pero muy costoso, claro. De una esfera de menos de 100 caras saco detalle como si tuviese varios miles, incluyendo la sombra. Si el algoritmo es en image-space, lo que cuenta es que pillas los datos de la imagen final, y eso incluye la geometria añadida en la pipeline. EDIT: Aqui y aqui se habla de la tecnica que te digo, aunque los screenshots no funcionan (una pena, eran muy buenos para ilustrar el caso) #36 General Programadores / Scene Graphs 03 de Enero de 2006, 07:23:45 PM  Bueno, siguiendo con mis threads sobre diseño, aqui va uno sobre grafos de escena (SG). Primero un poco de introduccion siguiendo el patron MVC. Por un lado tenemos una lista con los objetos de la escena, nuestro modelo. Luego tenemos los SG que son nuestras diferentes vistas. Nuestra vista base es un SG que guarda relaciones de dependencia entre objetos (referenciados de la lista), nada de transformaciones ni bounding volumes. Ahora hay que definir las vistas que vamos a usar. En mi opinion antes hay que definir que operaciones vamos a realizar sobre las vistas. Esto ya depende de cada motor. En mi ultimo proyecto tenia una unica vista que me guardaba la transformacion y el bounding volume en cada nodo. Este SG lo usaba para actualizar la transformacion y la jerarquia de bounding volumes (BVH) cada vez que movia un objeto. Tambien lo usaba para el culling, obteniendo una cola de objetos a dibujar que se pasa al renderer. No habia ni colisiones, ni fisica, ni animacion, asi que no lo tuve en cuenta. Despues de leer un poco sobre el tema, he visto que se puede hacer mucho mas eficiente. Actualizacion de la escena. Utilizaria un arbol n-ario normal y corriente, una vista basica que guarde en cada nodo la transformacion. Simplemente cuando se modifica un nodo, su transformacion se pasa hacia las hojas y se va actualizando la transformacion global de cada nodo. Rendering. Podemos tener un arbol con prioridades en cada nivel para ordenar los objetos que se van a dibujar en funcion del material (algo como lo que se habla en delphi3d sobre ordenacion por estados). Culling. Habria que ver que estructuras espaciales van mejor en funcion del tipo de escena. He leido que algunas van muy bien para geometria estatica (octree/quadtree/abt), y otras para mantener geometria dinamica. Colisiones. Seguramente con usar las mismas vistas que para culling seria suficiente, aunque teniendo en cuenta que solo colisionan objetos dinamicos contra dinamicos o estaticos. Habria que usar el patron Observer para notificar a las vistas de los cambios en la lista de objetos (adicion/eliminacion de objetos) y viceversa, si cambia algo en una de las vistas, hay que hacerselo saber a la lista para que actue convenientemente (notificando a otras vistas implicadas p.e.). Y bien, ¿que opinais? A parte de que el sistema pueda ser demasiado complejo y todas eso, el caso es que se usa y es muy flexible. Siempre puedes tener una simple vista como hice en mi anterior proyecto, pero si defines un sistema abstracto te da pie a reusar del codigo (lo mas importante) y futuras ampliaciones. ¿Como organizais vosotros las escenas? #37 Programación gráfica / Sombras En Engines Modernos 03 de Enero de 2006, 06:41:58 PM  Bueno, estaba pensando en que metodo usar para hacer sombras en el motor que estoy diseñando. Supongo que utilizare shadow mapping, ya que puedo reutilizar mucho codigo de mi ultimo proyecto (aunque habria que refactorizarlo un poco). Despues de pensar un rato, me he dado cuenta de que las cosas han cambiado mucho. La mayoria de documentacion sobre algoritmos de sombras o iluminacion es bastante vieja, y no suele tener muy en cuenta los grandes (enormes) avances a los que se ha llegado con las GPUs actuales. Vamos a discutir un poco sobre los metodos para hacer sombras, con sus ventajas e inconvenientes. Shadow mapping. - Es un algoritmo rapido, ya que solo requiere una pasada extra por cada luz y puede hacer sombras de modelos muy teselados sin demasiada sobrecarga. - Self-shadowing automatico. - Sufre de aliasing, que puede ser subsanado con una transformacion de perspectiva. Hay varias implementaciones: PSM, LiSPSM, TSM. Suelen ser un poco complicadas de implementar, aunque dan buenos resultados. - Con el uso de un pixel shader se puede acelerar la construccion del depth map. - Las nuevas tarjetas con sus extensiones (como FBO en OpenGL) permiten evitar la copia a memoria del render para tener un depth map en una textura. Se puede compartir directamente, disminuyendo el coste de los renders extra para los depth maps. Shadow volumes. - Depende mas de la geometria que proyecta la sombra, ya que hay que calcular el contorno y luego extruirlo. - El self-shadowing creo que no funciona tan bien como con los shadow maps. - No sufre de aliasing - Puede acelerarse la extrusion (y busqueda) del contorno para proyectar la sombra. (No se mucho mas sobre shadow volumes, asi que alguien mas podria ir completando la lista con lo que falte). Pues bien, en mi opinion creo que los shadow maps son un algoritmo genial, ya que de cada dia los modelos estan mas teselados, aunque no se hasta que punto beneficia la GPU en la extrusion del contorno. Eso si, hay que implementar algun tipo de correccion de la perspectiva (LiSPSM y TrapezoidSM parecen dar muy buen resultado, aunque la ultima diria que quieren patentarla). Ademas, ahora casi todas las tarjetas graficas (al menos dentro de 6 meses a 1 año) tienen las extensiones/caracteristicas necesarias. #38 General / Ingenieria Informatica: Masificacion 24 de Diciembre de 2005, 05:51:02 PM  Claro que no lleva a nada la discusion, nada cambiara despues de que este post pase de pagina, pero me gusta tener otras visiones de los temas que me preocupan. Y este me preocupa simplemente porque las carreras masificadas implican muchos alumnos por profesor, ademas que ya de por si los profesores no se matan mucho por la organizacion de sus asignaturas (desde la perspectiva de mi facultad). Al final acabo por no ir a clase y currarme las cosas mas por mi cuenta, eso si, pagando los 1000 euros de matricula cada año (pasao mañana :ph34r: ). Lo único que tengo claro es que da igual como hayas hecho la carrera, lo que importa es como sepas buscartelas cuando termines (y donde pongo carrera se puede poner cualquier cosa). Muchas veces los más mediocres en sus estudios son los más brillantes en su vida laboral. Nada mas que añadir. #39 General / Ingenieria Informatica: Masificacion 24 de Diciembre de 2005, 11:28:24 AM  El problema viene cuando llegues a 4º o 5º y vayas a hacer una practica o proyecto con esa chica y veas que ya no tiene ni idea de programar. Yo al final he optado por sudar y usar mis conocimientos como moneda de cambio: ya que yo pringo diseñando e implementando la mayor parte de los proyectos de programacion, los demas me dan apuntes, entregan ejercicios y cosas asi de las asignaturas q no me atraen. Total, seguro q luego en muchos curros me encontrare con gente asi, mejor acostumbrarse ahora a tratar con ellos.  (nooo)   #40 General / Ingenieria Informatica: Masificacion 24 de Diciembre de 2005, 01:52:20 AM  Sip, mas o menos a ese punto queria llegar. Un ingeniero es apto para plantear soluciones a problemas y resolverlos (programar, entre otras cosas). Claro que programar no tiene porque ser el punto fuerte del ingeniero, pero si tiene que tener esa habilidad desarrollada hasta cierto punto, ya que tiene que comunicarse con un sequito de coders hambrientos de documentos de diseño y toneladas de diagramas.   #41 General Programadores / Collision Tridimensional Tri-tri 23 de Diciembre de 2005, 11:26:34 PM  Personalmente no te recomiendo mucho la colision tri-tri porque ademas de ser costosa, suele ser innecesaria, ya que hay otros muchos tipos de deteccion de colision que suelen ser precisos y mas rapidos (de programar y al ejecutar). Por ejemplo arboles de esferas o de cajas (alineadas u orientadas). Si lo quieres hacer para aprender, vale, pero si lo haces para algo en concreto quizas si lo comentas te podemos decir algo que sea mas eficiente. De todos modos en la web del motor Wild Magic hay codigo fuente que puedes mirar. Supongo que sabras que la colision tri-tri tiene varios resultados. Bien puede colisionar una arista o uno de los vertices, asi que has de probar ambas posibilidades, cada una conlleva un algoritmo diferente. Asi que puede devolverte un punto si chocan vertice-triangulo, vertice-arista, vertice-vertice (improbable) o arista-arista, y un segmento si chocan arista triangulo o si hay interpenetracion entre ambos triangulos. #42 General / Ingenieria Informatica: Masificacion 23 de Diciembre de 2005, 11:03:13 PM  Pero sigo pensando que para programar o ser DBA no hace falta ser ingeniero informatico. Me parece como matar mosquitos a cañonazos. Luego encuentro mucha gente que dice "bah, al final terminas la carrera y todo lo que te han enseñado no lo usas para nada" y me quedo flipando, ¿sere el unico que usa lo que aprende en la carrera? Vale que en muchos casos quizas la titulitis influya, ya que piden demasiados titulos para trabajos que se pueden hacer con cursos u otras vias que no sean universitarias (y menos titulaciones de 5 años). #43 General / Ingenieria Informatica: Masificacion 23 de Diciembre de 2005, 10:21:07 PM  Ultimamente hay un tema que me ronda mucho la cabeza: ¿saben realmente los que estudian ingenieria informatica lo que estan haciendo? Hablando desde lo que veo en mi universidad, creo que es una carrera que esta demasiado masificada. Mucha gente la hace porque dicen que tiene mucha salida y chorradas de esas. Otros simplemente piensan que la informatica es reinstalar windows o picar codigo para programas de gestion, cosas que puedes hacer con el titulo de analista o tecnico. Mi principal frustracion es cuando llego a asignaturas de 4º curso y veo que mucha gente sigue sin tener ni idea de programar, que hace 3 años que no programan en c++ y no saben hacer una clase ni que es polimorfismo. Pero no es que sean los tipicos vagos, no, estudian como el que mas. Todo esto me lleva a pensar que sigue siendo como en el cole: estudiar a piñon para sacarse la asignatura en cuestion y luego olvidarlo todo. Si les interesa tan poco la carrera, ¿por que la estudian? Nadie les obliga como en el cole, y pasarse de 5 a 8 años pagando de 2 a 7k euros por año (segun donde vivan) para estudiar algo que simplemente escogieron por sus supuestas salidas no me entra en la cabeza. La pregunta es, ¿es normal que un ingeniero informatico no sepa programar a falta de un año para titularse? ¿Que salidas ofrece esta carrera que no requieran de esta habilidad? Claro que puedes investigar, administrar una base de datos, montar un proyecto, dar clases, etc.; aunque diria que es mas que recomendable saber programar a algun nivel incluso para eso. #44 General / Propuesta: Apartado Shareware 05 de Diciembre de 2005, 10:20:41 PM  Tal como lo pintais, lo mejor es irse a otro pais o cortarse las venas. #45 Programación gráfica / Ayuda Acerca De Sombreado 05 de Diciembre de 2005, 10:17:13 PM  Deberias aprender a preguntar en un foro. Se mas concreto sobre lo que buscas, ya que si preguntas algo tan general lo mas seguro es que no se te responda (como ha pasado hasta ahora). ¿Que entiendes por sombreado? ¿shading o shadowing? De todos modos, google te respondera mejor, y cuando tengas dudas concretas, postea en un foro. Sobre lo de la presentacion: proyector, diapositivas o pizarra. Páginas 1 2 3 4 5 ... 17 Ayuda | Ir Arriba ▲ SMF 2.1.4 | SMF © 2013, Simple Machines Síguenos en Aviso legal Tratamiento de datos Seguridad Cookies © 2024 Stratos Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad. Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante. Muchísimas gracias.

 Bueno, siguiendo con mis threads sobre diseño, aqui va uno sobre grafos de escena (SG).

Primero un poco de introduccion siguiendo el patron MVC. Por un lado tenemos una lista con los objetos de la escena, nuestro modelo. Luego tenemos los SG que son nuestras diferentes vistas.
Nuestra vista base es un SG que guarda relaciones de dependencia entre objetos (referenciados de la lista), nada de transformaciones ni bounding volumes.
Ahora hay que definir las vistas que vamos a usar. En mi opinion antes hay que definir que operaciones vamos a realizar sobre las vistas.
Esto ya depende de cada motor. En mi ultimo proyecto tenia una unica vista que me guardaba la transformacion y el bounding volume en cada nodo. Este SG lo usaba para actualizar la transformacion y la jerarquia de bounding volumes (BVH) cada vez que movia un objeto. Tambien lo usaba para el culling, obteniendo una cola de objetos a dibujar que se pasa al renderer. No habia ni colisiones, ni fisica, ni animacion, asi que no lo tuve en cuenta.

Despues de leer un poco sobre el tema, he visto que se puede hacer mucho mas eficiente.
Actualizacion de la escena. Utilizaria un arbol n-ario normal y corriente, una vista basica que guarde en cada nodo la transformacion. Simplemente cuando se modifica un nodo, su transformacion se pasa hacia las hojas y se va actualizando la transformacion global de cada nodo.
Rendering. Podemos tener un arbol con prioridades en cada nivel para ordenar los objetos que se van a dibujar en funcion del material (algo como lo que se habla en delphi3d sobre ordenacion por estados).
Culling. Habria que ver que estructuras espaciales van mejor en funcion del tipo de escena. He leido que algunas van muy bien para geometria estatica (octree/quadtree/abt), y otras para mantener geometria dinamica.
Colisiones. Seguramente con usar las mismas vistas que para culling seria suficiente, aunque teniendo en cuenta que solo colisionan objetos dinamicos contra dinamicos o estaticos.

Habria que usar el patron Observer para notificar a las vistas de los cambios en la lista de objetos (adicion/eliminacion de objetos) y viceversa, si cambia algo en una de las vistas, hay que hacerselo saber a la lista para que actue convenientemente (notificando a otras vistas implicadas p.e.).


Y bien, ¿que opinais? A parte de que el sistema pueda ser demasiado complejo y todas eso, el caso es que se usa y es muy flexible. Siempre puedes tener una simple vista como hice en mi anterior proyecto, pero si defines un sistema abstracto te da pie a reusar del codigo (lo mas importante) y futuras ampliaciones.

¿Como organizais vosotros las escenas?

[Shadow mapping.]

 Bueno, estaba pensando en que metodo usar para hacer sombras en el motor que estoy diseñando. Supongo que utilizare shadow mapping, ya que puedo reutilizar mucho codigo de mi ultimo proyecto (aunque habria que refactorizarlo un poco).

Despues de pensar un rato, me he dado cuenta de que las cosas han cambiado mucho. La mayoria de documentacion sobre algoritmos de sombras o iluminacion es bastante vieja, y no suele tener muy en cuenta los grandes (enormes) avances a los que se ha llegado con las GPUs actuales.
Vamos a discutir un poco sobre los metodos para hacer sombras, con sus ventajas e inconvenientes.

Shadow mapping.
- Es un algoritmo rapido, ya que solo requiere una pasada extra por cada luz y puede hacer sombras de modelos muy teselados sin demasiada sobrecarga.
- Self-shadowing automatico.
- Sufre de aliasing, que puede ser subsanado con una transformacion de perspectiva. Hay varias implementaciones: PSM, LiSPSM, TSM. Suelen ser un poco complicadas de implementar, aunque dan buenos resultados.
- Con el uso de un pixel shader se puede acelerar la construccion del depth map.
- Las nuevas tarjetas con sus extensiones (como FBO en OpenGL) permiten evitar la copia a memoria del render para tener un depth map en una textura. Se puede compartir directamente, disminuyendo el coste de los renders extra para los depth maps.

Shadow volumes.
- Depende mas de la geometria que proyecta la sombra, ya que hay que calcular el contorno y luego extruirlo.
- El self-shadowing creo que no funciona tan bien como con los shadow maps.
- No sufre de aliasing
- Puede acelerarse la extrusion (y busqueda) del contorno para proyectar la sombra.
(No se mucho mas sobre shadow volumes, asi que alguien mas podria ir completando la lista con lo que falte).

Pues bien, en mi opinion creo que los shadow maps son un algoritmo genial, ya que de cada dia los modelos estan mas teselados, aunque no se hasta que punto beneficia la GPU en la extrusion del contorno. Eso si, hay que implementar algun tipo de correccion de la perspectiva (LiSPSM y TrapezoidSM parecen dar muy buen resultado, aunque la ultima diria que quieren patentarla).
Ademas, ahora casi todas las tarjetas graficas (al menos dentro de 6 meses a 1 año) tienen las extensiones/caracteristicas necesarias.

 Claro que no lleva a nada la discusion, nada cambiara despues de que este post pase de pagina, pero me gusta tener otras visiones de los temas que me preocupan. Y este me preocupa simplemente porque las carreras masificadas implican muchos alumnos por profesor, ademas que ya de por si los profesores no se matan mucho por la organizacion de sus asignaturas (desde la perspectiva de mi facultad).
Al final acabo por no ir a clase y currarme las cosas mas por mi cuenta, eso si, pagando los 1000 euros de matricula cada año (pasao mañana :ph34r: ).

Lo único que tengo claro es que da igual como hayas hecho la carrera, lo que importa es como sepas buscartelas cuando termines (y donde pongo carrera se puede poner cualquier cosa). Muchas veces los más mediocres en sus estudios son los más brillantes en su vida laboral.

Nada mas que añadir.

 El problema viene cuando llegues a 4º o 5º y vayas a hacer una practica o proyecto con esa chica y veas que ya no tiene ni idea de programar.
Yo al final he optado por sudar y usar mis conocimientos como moneda de cambio: ya que yo pringo diseñando e implementando la mayor parte de los proyectos de programacion, los demas me dan apuntes, entregan ejercicios y cosas asi de las asignaturas q no me atraen.

Total, seguro q luego en muchos curros me encontrare con gente asi, mejor acostumbrarse ahora a tratar con ellos.  (nooo)  

 Sip, mas o menos a ese punto queria llegar. Un ingeniero es apto para plantear soluciones a problemas y resolverlos (programar, entre otras cosas). Claro que programar no tiene porque ser el punto fuerte del ingeniero, pero si tiene que tener esa habilidad desarrollada hasta cierto punto, ya que tiene que comunicarse con un sequito de coders hambrientos de documentos de diseño y toneladas de diagramas.  

 Personalmente no te recomiendo mucho la colision tri-tri porque ademas de ser costosa, suele ser innecesaria, ya que hay otros muchos tipos de deteccion de colision que suelen ser precisos y mas rapidos (de programar y al ejecutar). Por ejemplo arboles de esferas o de cajas (alineadas u orientadas).
Si lo quieres hacer para aprender, vale, pero si lo haces para algo en concreto quizas si lo comentas te podemos decir algo que sea mas eficiente.

De todos modos en la web del motor Wild Magic hay codigo fuente que puedes mirar.
Supongo que sabras que la colision tri-tri tiene varios resultados. Bien puede colisionar una arista o uno de los vertices, asi que has de probar ambas posibilidades, cada una conlleva un algoritmo diferente. Asi que puede devolverte un punto si chocan vertice-triangulo, vertice-arista, vertice-vertice (improbable) o arista-arista, y un segmento si chocan arista triangulo o si hay interpenetracion entre ambos triangulos.

 Pero sigo pensando que para programar o ser DBA no hace falta ser ingeniero informatico. Me parece como matar mosquitos a cañonazos.
Luego encuentro mucha gente que dice "bah, al final terminas la carrera y todo lo que te han enseñado no lo usas para nada" y me quedo flipando, ¿sere el unico que usa lo que aprende en la carrera?
Vale que en muchos casos quizas la titulitis influya, ya que piden demasiados titulos para trabajos que se pueden hacer con cursos u otras vias que no sean universitarias (y menos titulaciones de 5 años).

 Ultimamente hay un tema que me ronda mucho la cabeza: ¿saben realmente los que estudian ingenieria informatica lo que estan haciendo?
Hablando desde lo que veo en mi universidad, creo que es una carrera que esta demasiado masificada. Mucha gente la hace porque dicen que tiene mucha salida y chorradas de esas. Otros simplemente piensan que la informatica es reinstalar windows o picar codigo para programas de gestion, cosas que puedes hacer con el titulo de analista o tecnico.

Mi principal frustracion es cuando llego a asignaturas de 4º curso y veo que mucha gente sigue sin tener ni idea de programar, que hace 3 años que no programan en c++ y no saben hacer una clase ni que es polimorfismo. Pero no es que sean los tipicos vagos, no, estudian como el que mas. Todo esto me lleva a pensar que sigue siendo como en el cole: estudiar a piñon para sacarse la asignatura en cuestion y luego olvidarlo todo.
Si les interesa tan poco la carrera, ¿por que la estudian? Nadie les obliga como en el cole, y pasarse de 5 a 8 años pagando de 2 a 7k euros por año (segun donde vivan) para estudiar algo que simplemente escogieron por sus supuestas salidas no me entra en la cabeza.

La pregunta es, ¿es normal que un ingeniero informatico no sepa programar a falta de un año para titularse? ¿Que salidas ofrece esta carrera que no requieran de esta habilidad? Claro que puedes investigar, administrar una base de datos, montar un proyecto, dar clases, etc.; aunque diria que es mas que recomendable saber programar a algun nivel incluso para eso.

 Tal como lo pintais, lo mejor es irse a otro pais o cortarse las venas.

 Deberias aprender a preguntar en un foro. Se mas concreto sobre lo que buscas, ya que si preguntas algo tan general lo mas seguro es que no se te responda (como ha pasado hasta ahora).

¿Que entiendes por sombreado? ¿shading o shadowing? De todos modos, google te respondera mejor, y cuando tengas dudas concretas, postea en un foro.


Sobre lo de la presentacion: proyector, diapositivas o pizarra.