Cesnavarra 2008-boletín 10

Título Microsoft Innovation Centers

Texto Acortar la brecha digital a través de la difusión desde los
centros de la sociedad digital y constituir auténticos polos de
conocimiento que favorezcan la transferencia tecnológica es el
reto final de los Centros de Innovación de Microsoft. Esto se
consigue generando un interés común por parte de todos
los implicados: por un lado, las empresas, a las que se dan
a conocer los beneficios que conlleva la innovación; por otro,
las administraciones públicas, decididas a promover el
cambio.

Aumentar el nivel de I+D+i, incrementar la penetración de las
TIC en las empresas, mejorar el conocimiento sobre cómo la
tecnología cambia los procesos de negocio de las compañías,
multiplicar el número de empresas innovadoras de una
Comunidad... son los desafíos a los que dan respuesta los
Centros de Innovación.
Así, a través de ellos y de otras iniciativas, intentamos
proporcionar las mejores herramientas a los mejores
equipos humanos, hacer que sean capaces de desplegar
todo su potencial y, gracias a él, ayudar a otros a innovar en
sus negocios y sus proyectos. Por ello, facilitamos el más
rápido acceso a las últimas tecnologías, ayudamos a las
compañías que desarrollan software a definir mejores
arquitecturas, a solucionar problemas. En definitiva, a ser
más competitivas.

Las tecnologías de información son un aliado estratégico para
las organizaciones y las personas. Se dice que la información
es poder. Hemos crecido en una industria emergente que está
posicionada prácticamente en todos los aspectos de la vida
empresarial y personal.

La red de MIC en España está formada por 8 centros, 6 en
funcionamiento y 2 de próxima creación, encargados de
divulgar la filosofía Microsoft entre la comunidad de empresas
y desarrolladores.

1. Walqa MTC (Instituto Tecnológico de
Aragón):
http://aragonmtc.com/cs2/Default.aspx

En la actualidad son MTC (Microsoft Technology Center),
de los cuales hay 12 en el mundo y 4 en Europa. Como
tal es un centro dedicado a dar apoyo a los Fabricantes

de Software (Independent Software Vendors o ISVs),
entendiendo como tal a empresas que desarrollan
software en forma de producto comercializado a través
de canales de distribución. Representa un apoyo
personalizado a sus necesidades concretas en la
fabricación de productos.

Asimismo forman parte de la Plataforma INES:
Plataforma Tecnológica Española de Software y
Servicios http://www.ines.org.es/index.php

2. MIC Movilidad Boecillo:
http://www.micmovilidad.es

En noviembre de 2004, el presidente de la Junta de
Castilla y León, D. Juan Vicente Herrera, firmó en Seattle
un acuerdo de colaboración con Microsoft, para la
creación de un Centro de Innovación que promoviera el
desarrollo de la sociedad de la información y el
conocimiento en la región, y apoyara el crecimiento y
consolidación del sector TIC. El centro se puso en
marcha en Junio de 2005.

El objetivo del Centro de Innovación en Movilidad es
crear en torno al mismo, un polo de conocimiento que
oriente su actividad hacia la innovación en soluciones de
movilidad, de forma que sirva para impulsar el desarrollo
de la Sociedad de la Información y favorecer el progreso
de las empresas TIC (Tecnologías de la Información y las
Comunicaciones).

Su labor de desarrolla en torno a 3 líneas de trabajo:

 Transferencia tecnológica
 Innovación
 Promoción y difusión para la generación de
demanda
Como labor principal desarrollan Masters sobre
movilidad para empresas o grupos de usuarios sobre:

 Metodología
 Desarrollo
Además de esto tienen otra serie de actuaciones:

Cada mes llevan a cabo un seminario público sobre

novedades en movilidad Windows Mobile.Publican
artículos en diversas publicaciones como MSDN,
PCWorld,…

Colaboran con la universidad impartiendo charlas de
Movilidad con valor efectivo en créditos.

Han colaborado en la creación y desarrollo de comunidad
de desarrolladores en Movilidad.NET.

Llevan a cabo la precertificación de aplicaciones con el
calificativo de “Designed for” Windows Mobile.

3. MIC Integración Santander:
http://www.ciin.es

Surge de un acuerdo de colaboración entre el Gobierno
de Cantabria y Microsoft Ibérica, siendo inaugurado de
forma oficial el 16 de enero de 2006.

La actividad de este MIC se realiza alrededor de estos
ejes:

 Capacitación: transmitir a las empresas las
últimas novedades en tecnologías de integración
y desarrollo.
 Innovación: desarrollar pilotos y pruebas de
concepto que permitan un mejor
aprovechamiento de nuevas tecnologías y
metodologías.
 Aumento de la demanda: desarrollar acciones
divulgativas, eventos sectoriales y foros técnicos
que faciliten el interés por las nuevas
tecnologías.
 Herramientas Microsoft: analizar y transmitir
las novedades tecnológicas de sus herramientas
de integración.
Han fomentado la creación de 2 grupos de usuarios con
los cuales colaboran de manera activa:

 Grupo de usuarios .NET de Cantabria:
Nuberos.NET.
 Grupo de usuarios SharePoint de España:
SUGES.

También realizan otras labores como:

 Acciones de Consultoría.
Formación especializada a fabricantes de Software.

Pre certificación de aplicaciones.

Sesiones OneToOne sobre problemáticas concretas.

4. MIC Productividad Manresa:
http://www.productivitycenter.org

El Centro Microsoft de Innovación en Productividad es
una iniciativa conjunta entre Microsoft, el CIDEM, Caixa
Manresa, el Ayuntamiento de Manresa, la Cámara de
Comercio de Manresa y el CTM Centro Tecnológico dónde
se ubican las instalaciones del Centro de Innovación en
Productividad.

El Centro fue constituido a finales de Septiembre del
2006, iniciando su actividad en Enero del 2007.

Es una fundación sin ánimo de lucro cuyo objetivo es
ayudar a las empresas a incrementar la productividad de
sus trabajadores. Para ello, el Centro ayuda a las
empresas a innovar en sus procesos de negocio
mediante el uso de tecnologías que aumentan el
potencial de sus empleados. Por tanto su actividad se
orienta principalmente hacia los niveles de decisión
empresariales: dirección, gerencia, marketing, etc.

El centro facilita las mejores herramientas a los mejores
equipos humanos,colabora con ellos para que sean
capaces de desplegar todo su potencial y ayuda a
innovar en sus negocios .

5. MIC Embedded Technologies Mondragón:
http://www.pologaraia.es/

Nace con el objetivo de impulsar la innovación y el uso
de las Tecnologías de la Información y las

Comunicaciones (TIC) específicamente en soluciones
embebidas en dispositivos o robóticas como vía para
contribuir al crecimiento económico de la región,
comenzando su actividad en julio de 2008.

Esta iniciativa cuenta con el apoyo del Gobierno vasco, la
Diputación Foral de Guipúzcoa, la Asociación de
Industrias de las Tecnologías Electrónicas y de la
Información del País Vasco (GAIA) y firmas y entidades
representativas de Guipúzcoa, como Ikerlan, la
Universidad de Deusto o Mondragón Unibersitatea.

Las áreas de trabajo sobre las que se centra este centro
son:

 Promoción tecnológica
 Formación
 Asesoramiento
 Proyectos de I+D+i.
Certificación-Homologación de sistemas
embebidos.

6. Bizkaia European Center for Citizen Services:
MIC de próxima creación, nace de un convenio entre
Diputación Bizkaia, Lantik/Biskaytik y Microsoft Ibérica y
su inicio de actividad se planea para Noviembre 2008.

Su foco será lo que Microsoft denomina Citizen Services
Platform.

7. MIC for Tourism Services Mallorca:
MIC creado mediante un convenio de reciente firma
entre Microsoft, Govern Balear y Clúster Turistec, que
comenzará su actividad en 2009.

El Centro de Innovación en Turismo permitirá a las
empresas del sector turístico mejorar su productividad y
lanzar nuevos servicios innovadores con los que puedan
crear experiencias enriquecedoras para sus clientes,
aprovechando las últimas tecnologías disponibles: el
nuevo mundo de la Web 2.0, sistemas de información en
entorno móviles, nuevos dispositivos táctiles como el
revolucionario Microsoft Surface, etc.

8. Centro de Excelencia Software Microsoft de
Navarra(CESNAVARRA):
http://www.cesnavarra.net

El Centro de Excelencia Software Microsoft.Net de
Navarra, tiene como origen un acuerdo de colaboración
entre el Gobierno de Navarra y Microsoft Ibérica SRL.
Para llevar a cabo este acuerdo, el Gobierno de Navarra
designó como gestor del Centro de Excelencia al Centro
Europeo de Empresas e Innovación de Navarra
(CEIN,SA) instrumento del Gobierno de Navarra al
servicio de las pymes y emprendedores/as, que
promueve la mejora competitiva de las empresas de la
Comunidad. Este MIC comienza su actividad en Enero de
2007.

Las líneas de actividad del Centro de Excelencia Software
Microsoft se centran en la divulgación y difusión de
herramientas y tecnologías de software Microsoft dentro
del entorno de la comunidad foral, con el objetivo de
mejorar el conocimiento y la calidad de desarrollo de los
profesionales y compañías TIC de Navarra.

Dentro de estas líneas de actividad, el Centro de
Excelencia Software Microsoft actúa como un impulsor
dentro de la Comunidad Foral de las últimas tecnologías
Microsoft para posibilitar el acceso de los profesionales y
empresas TIC a estas, facilitando su uso en la
generación de negocio.

Los servicios que actualmente centran la actividad de
este MIC son:

 Formación y difusión de tecnología Microsoft
de última generación
 Proyectos piloto.
 Como complemento a estos se desarrollarán
otra serie de servicios que completarán el arco
de las necesidades de las empresas y
profesionales TIC:
 Consultoría especializada y asesoramiento.
 Plataforma de Prueba y Rendimiento de
soluciones Microsoft.
 Pre-certificación de aplicaciones.
 Librería de software y desarrollos.

Categorías CES Microsoft

Tema Varios

Autor Raul Mayo Gonzalez

Mes Octubre

Año 2008

Boletín 10

Título S + S <> SaaS
Texto En este mundo de ensalada de siglas que son las TIC, este mes quiero
intentar explicar la ecuación arriba presentada. Aunque puede parecer
evidente que S+S no es lo mismo que SaaS creo que merece la pena
comentarlo un poco, porque esas “S” se parecen bastante en ambos
casos.

¿De qué estamos hablando? Del futuro de la programación (o presente,
en las empresas TIC innovadoras). El software y los servicios. O los
servicios de software. Y el concepto que Microsoft y otros fabricantes de
software tienen del mismo.

El concepto “SaaS”, o “Software as a Service”, se basa en la idea de que
dado que las comunicaciones entre sistemas (básicamente nuestro acceso
a Internet “urbi et orbi”) son cada día más rápidas y frecuentes, el futuro
del software ya no reside en las aplicaciones “dedicadas” tradicionales (es
decir aquellas que instalamos en nuestro PC y por tanto consumen
recursos del mismo: ocupan espacio en disco, necesitan memoria y CPU
para ejecutarse, etc.) sino en aplicaciones conectadas a uno o varios
servicios simultáneamente por ejemplo, a través de un navegador web (en
este caso casi no tienen “footprint” o huella en cuanto a espacio de disco
y su consumo de recursos es menor).

Por su parte, Microsoft cree que el modelo más adecuado en cambio se
trata del “S + S” o “Software más Servicios”, donde el software dedicado
se complementa de manera efectiva con unos servicios que residen en la
“nube” de Internet o nuestras intranets empresariales. Este modelo
defiende que así aprovecha lo mejor de ambos mundos, donde a la
potencia de las aplicaciones de escritorio la añade la flexibilidad que
aporta el uso de los servicios. El mensaje en este caso es que las
denominadas Productivity Applications, o aplicaciones que los usuarios
emplean en su trabajo diario como Microsoft Excel, Word, Outlook, etc.
necesitan tener unas características de usabilidad, capacidades, riqueza,
etc. que sólo son posibles si estas aplicaciones son un software específico.

Por poner algunos ejemplos concretos, podemos nombrar a Google Docs
como aplicación SaaS o a Microsoft Word como aplicación S+S. ¿Mejores
o peores? Lo cierto es que cada una tiene su caso de aplicación concreto.
Pero también que si a una aplicación rica como Microsoft Word (con
capacidades por ejemplo para aplicar formatos y temas diversos con 1
click, revisión ortográfica completa, gestión de enlaces y TOCs, flexibilidad
completa para incorporar tablas, excels, gráficos, smart art, etc.) la
añadimos la potencia en servicios que le aporta SharePoint… es como si S
+ S fuera “SaaS con hormonas”.

Además de todo esto, tenemos el hecho de que los mismos servicios que
soportan estas Productivity Applications pueden apoyar múltiples
aplicaciones, de manera que también a nivel servidor vemos que S+S se
presenta como una solución más completa que SaaS.

Una vez vista y explicada a grandes rasgos la arquitectura S+S, pasemos a
un ejemplo práctico de desarrollo. En este caso vamos a desarrollar un
pequeño complemento para Word 2007 con el que desarrollaremos un
nuevo elemento de la cinta (o “ribbon”) de aplicaciones al que dotaremos
de un botón con el que recuperaremos información de nuestro sitio
Microsoft Office SharePoint Server via Web Services y que tendremos a
nuestra disposición en Word. Vamos a emplear para ello Microsoft Visual
Studio 2008 Professional y Visual Studio Tools for Office (VSTO).

Lo primero que hemos de hacer es crear nuestro proyecto. En este caso se
trata de un proyecto de C#, para Office 2007 de tipo “Complemento de
Word 2007”

Una vez se ha creado el proyecto, añadimos un nuevo elemento de tipo
Cinta al mismo.

Esto nos abre la ventana de diseño de la cinta. Añadimos una nueva ficha
que llamamos CES en nuestro caso (hay que hacer click con el botón
derecho del ratón sobre una zona limpia y seleccionar “Agregar ficha de la

cinta de opciones”) y a esta le adjuntamos un Grupo y unos Botones,
mediante los que accederemos a nuestra funcionalidad específica. Los
ponemos bonitos (nombre, textos, iconos y demás) e iremos haciendo
doble click en cada uno de ellos para escribir el código que ejecutarán.

Como ejemplo sencillo vamos a crear un código que automáticamente
inserte en el documento un texto (que será nuestra firma) al pulsar el
botón. El código será el siguiente:
private void btnFirma_Click(object sender, RibbonControlEven
tArgs e)
{
Firma();
}

private void Firma()
{
// Seleccionamos el rango activo
Microsoft.Office.Interop.Word.Range range =
Globals.ThisAddIn.Application.Selection.Range;
// Insertamos nuestro texto
range.Text = "Rafael Floresn";
range.Text += "CES Microsoft .NET Navarra";
}

El resultado es este:

Bien, funciona, pero si nos quedamos en esto no tenemos esa utilidad de
S+S de la que hemos venido hablando, ¿no? Entonces vamos al siguiente
paso, conectar con nuestro SharePoint y traer a nuestro documento Office
información que podamos usar. Vamos a hacer dos ejemplos sencillos que
valen para mostrar la técnica pero hay que destacar que con algo más de
trabajo podemos hacer que nuestros Word, Excel, Powerpoint, Outlook,
etc. recuperen información de nuestros sistemas

Lo primero que vamos a hacer es agregar una referencia a los servicios
Web de Sharepoint que nos interesan (hablamos sobre esto en un artículo
anterior que está disponible aquí). Por simplicidad usaremos un servicio
Web, que se basa en el .NET Framework 2.0, pero si esto fuera un
desarrollo para producción recomendaríamos usar WCF de .NET
Framework 3.5 ;)

Para definir este servicio, pulsamos con el botón derecho del ratón sobre
el nombre de proyecto y elegimos “Agregar referencia de servicio”. Ahora
tenemos que “escarbar” un poco para añadir nuestro servicio Web: pulsar
“Avanzadas…” en la pantalla que se nos muestra y en la siguiente
“Agregar referencia Web”.

Llegamos por fin a la pantalla que nos interesa, donde debemos indicar la
Dirección URL del servicio Web al que nos conectaremos y darle un
nombre ya que el nombre por defecto ayuda poco. Pulsamos “Agregar
referencia” y listo, ya podemos usar ese servicio Web en nuestro
proyecto.

Para probarlo vamos a programar el código del segundo botón “Listas
SharePoint”. Este botón simplemente se conectará a nuestro SharePoint y
recuperará los nombres de todas las listas que tiene definidas. Con eso
veremos que todo funciona como esperamos. El código que usamos es
este:
private void EncuentraListas()
{
String listName;
XmlNode listNodes;
XmlAttributeCollection nodeAttribs;

ListsCESWS.Lists listService = new ListsCESWS.Lists();
// Creamos las credenciales que nos permiten conectarnos a
// SharePoint y las asignamos al servicios
System.Net.NetworkCredential myCred
= new System.Net.NetworkCredential(USUARIO, PASSWORD);
listService.Credentials = myCred;
// Invocamos el método GetListCollection del servicio Web
listNodes = listService.GetListCollection();
// Para cada nodo XML recuperado obtenemos el valor del
elemento
// Title y lo volvemos a nuestro documento
foreach (XmlNode node in listNodes)
{
nodeAttribs = node.Attributes;
listName = nodeAttribs.GetNamedItem("Title").Value;
Microsoft.Office.Interop.Word.Range range =
Globals.ThisAddIn.Application.Selection.
Range;
range.Text = listName + "n";
};
}

En este caso vemos que ya hay que hacer uso de unas credenciales de

autenticación para acceder a los contenidos de SharePoint. Aquí lo que se
usa es una configuración seguridad basada en Usuario y Password, pero
que en casos reales podrá ser más complicada.

Como resultado tenemos una lista de “nombres de listas SharePoint” en
nuestro documento Word, lo cual prueba que el funcionamiento es
correcto.

Vamos a continuación a complicar un poco el proceso. Lo que queremos
es seleccionar de la lista “Eventos” el título de aquellos que se enmarcan
en el área del CES Microsoft. Para esto hemos de usar un documento XML
compuesto de diversos nodos XML que nos servirán para codificar una
consulta que será la que filtrará los elementos que recuperamos.

También hemos de tener en cuenta la estructura de la información que
nos devuelve SharePoint, en formato XML.
private void EncuentraEventos()
{
XmlNode listNode, eventNode;
XmlAttributeCollection nodeAttribs;
String eventName;

ListsCESWS.Lists listService = new ListsCESWS.Lists();

// Creamos las credenciales que nos permiten conectarnos a
// SharePoint y las asignamos al servicios
System.Net.NetworkCredential myCred
= new System.Net.NetworkCredential(USUARIO, PASSWORD);
listService.Credentials = myCred;
// Recuperamos
listNode = listService.GetList("Eventos");

// Creamos las estructuras XML necesarias

XmlDocument xmlDoc = new System.Xml.XmlDocument();
XmlNode ndQuery =
xmlDoc.CreateNode(XmlNodeType.Element, "Query", "");
XmlNode ndViewFields =
xmlDoc.CreateNode(XmlNodeType.Element, "ViewFields", "");
XmlNode ndQueryOptions =
xmlDoc.CreateNode(XmlNodeType.Element, "QueryOptions", "");
// Cargamos la información que buscamos en las estructuras
ndQueryOptions.InnerXml
= "<IncludeMandatoryColumns>FALSE</IncludeM
andatoryColumns>" +
"<DateInUtc>TRUE</DateInUtc>";
// Recuperamos Título y Fecha OJO:Nombres en original
INGLES
ndViewFields.InnerXml = "<FieldRef Name='Title'
/><FieldRef Name='Date'/>";
// Filtramos con la condición de la query que Origen
// sea igual (Eq) a Microsoft
ndQuery.InnerXml = "<Where><Eq><FieldRef
Name='Origen'/>" +
"<Value
Type='String'>Microsoft</Value></Eq></Where>";
try
{
// Recuperamos los elementos de la lista Eventos
// filtrados con nuestras condiciones
XmlNode ndListItems =
listService.GetListItems("Eventos", null, ndQuery,
ndViewFields, null, ndQueryOptions, null);
// Procesamos cada elemento recuperado buscando el
título
foreach (XmlNode node in ndListItems.ChildNodes)
{
// El contenido va en los subnodos que nos devuelve
SharePoint
foreach (XmlNode subnode in node.ChildNodes)
{
// Buscamos valores de los atributos del nodo
nodeAttribs = subnode.Attributes;
if (nodeAttribs != null)
{
// Preguntamos por el título del evento
eventNode = nodeAttribs.GetNamedItem("ows_Title");
if (eventNode != null)
{
// Si es título, escribimos en el documento su
valor
eventName = eventNode.Value;
Microsoft.Office.Interop.Word.Range range
= Globals.ThisAddIn.Application.S
election.Range;
range.Text = eventName + "n";
};
}
};
};
}
catch (System.Web.Services.Protocols.SoapException ex)
{
MessageBox.Show("Message:n" + ex.Message
+ "nDetail:n" + ex.Detail.InnerText + "nStackTrace:n" +
ex.StackTrace);
}
}

En este caso, el resultado son los títulos de los Eventos
del área de “CES Microsoft” que tenemos registrados en
nuestro SharePoint.

Como estos sencillos ejemplos pretendían demostrar, el uso de Visual
Studio junto con las Visual Studio Tools for Office nos permiten de una
manera fácil llevar a la práctica el concepto de S+S de Microsoft. Y no nos
tenemos que limitar sólo a consultas, todo el conjunto de operaciones de
actualización, inserción y borrado está a nuestra disposición. Adecuar o
adaptar las aplicaciones de escritorio más usadas en las organizaciones
(caso de Microsoft Office) para la interrelación con las aplicaciones de
negocio (SharePoint, Exchange, Dynamics, etc.), se convierte en un
sencillo proceso de programación que las herramientas de Visual Studio
nos simplifican enormemente.

Categor CES Microsoft
ías
Tema Desarrollo
Autor Rafael Flores Yoldi
Mes Octubre
Año 2008
Boletín 10

Títu Proyecto piloto TDT: parte 2: fase 1
lo
Tex Inicialmente este segundo artículo ocupaba unas 22 páginas. Para
to

favorecer la lectura he decidido dividirlo en 2 partes.

Esta, la primera parte de la fase 1, contempla los siguientes
apartados:

 Gestión de la primera fase.
 Descripción de la arquitectura TDT
 Infraestructura necesaria para el desarrollo del proyecto.
 Incorporación y formación del equipo local.
 Identificación de otros servicios.
La segunda parte completará el periplo por la fase 1 describiendo lo
que fueron los procesos de desarrollo de los siguientes módulos:

 Lanzadera
 Servicios de Hacienda.
Así pues, comenzamos con el artículo:

Continuo con la línea iniciada en el artículo anterior “Proyecto piloto
TDT: parte 1: definición”, en el que dejé planteadas un amplio
número de tareas a realizar durante esta primera fase.

Comenzaré describiendo lo que fue la gestión de esta fase y después
comentaré más profundamente los detalles de cada tarea y actuación.

Se empezó elaborando el borrador de un plan de acción para esta
primera fase con la planificación de tareas, asignación de recursos y
descripción de necesidades (necesidades técnicas, necesidades de
información, etc). Este borrador debía abarcar finalmente los
siguientes trabajos:

 Infraestructura necesaria para el desarrollo del proyecto.
 Identificación de otros servicios.
 Incorporación y formación del equipo local.
 Desarrollo de una lanzadera (tal y como se adelantó en el
artículo anterior, esta es una aplicación que da acceso a los
servicios en TDT)
 Desarrollo de los servicios de Hacienda para la campaña de la
Renta.
 Desarrollo de un posible servicio informativo adicional.
Esto es:

Cat CES OpenSouce/Java
ego
rías
Te Varios
ma
Aut Raúl Sanz de Acedo
or
Mes Octubre

Año 2008

Bol 10
etín

Título Sincronización de aplicaciones MHP (Parte 1)

Texto Cuando trabajamos con aplicaciones MHP, a menudo es necesario
que estas estén sincronizadas con los contenidos audiovisuales para
los que han sido creadas. Por ejemplo si hacemos una aplicación
para un concurso de preguntas y respuestas, nos interesa que el
usuario pueda contestar a dichas preguntas a la vez que estas son
formuladas en el programa original. Por ejemplo, en el minuto 7 del
programa debe presentar la pregunta 3. Pero el problema es,
¿como sabe el receptor cuando se ha llegado al minuto 7 del
programa? En muchos sistemas multimedia esto se hace
considerando cuando empieza el programa, y a partir de entonces
se cuentan los 7 minutos. Cuando se trata de servicios de televisión
digital, enviar una indicación de cuando empieza un programa no es
una solución válida. En televisión no existe un concepto real de
tiempo, ya que el usuario puede incorporarse al flujo en cualquier
punto, si se selecciona el programa una vez empezado no hay
forma de saber cuanto tiempo ha transcurrido desde que empezó el
programa, o si se cambia de canal en mitad de un programa
también se pierde la referencia de tiempos, aunque luego volvamos
al mismo canal. Pero si no podemos usar el tiempo como
mecanismo para la sincronización de las aplicaciones, ¿cómo
podemos obtener un tiempo de referencia que nos permita
determinar el momento en que debemos activar un evento? Para
solucionar esto DSM-CC (Digital Storage Media Command and
Control) define el NPT (Normal Play Time).

NPT (Normal Play Time)

Se trata de un código de tiempos asociados a un flujo. Se envía en
el flujo de transporte mediante descriptores especiales que viajan
en secciones privadas de MPEG. Aunque este código de tiempos va
completamente separado de los DSM-CC Stream Events (ambos
viajan en flujos distintos) y se carga en su propio descriptor, los
DSM-CC pueden usar estos códigos para ayudarles a decidir cuando
activar los eventos. Como veremos más adelante los Stream Events
transportan en uno de sus campos el valor NPT al que debe
ejecutarse el evento, de este modo el receptor se encargara de
lanzar el evento cuando el NPT llegue a este valor indicado por el
Stream Event. Es decir, utilizan el NPT para indicarle al receptor
cuando se debe producir un evento.

Un código de tiempo NPT puede comenzar en cualquier valor y
normalmente se va incrementando a lo largo de un programa
(como si fuera un reloj que cuenta su duración), aunque pueden
tener discontinuidades que reflejen ediciones del contenido. Es

decir, que incluso si un flujo que contiene referencias NPT es
editado (ya sea porque el distribuidor ha decidido acortar el
programa, o que se le hayan introducido anuncios y por lo tanto se
haya alargado en el tiempo), el valor del NPT para un determinado
punto del flujo no necesita actualización y puede seguir siendo el
mismo para ese segmento de contenidos. Esto se ilustra en los
siguientes diagramas:

Diagrama 1: El difusor ha reducido la duración del programa, pero
la referencia NPT (marcada con una X) se mantiene.

Diagrama 2: También te permite anidar NPTs. Se ha insertado un
bloque de anuncios y la referencia NPT se mantiene en el mismo
minuto de la aplicación.

A pesar de la edición, los NPTs de la versión editada son los mismos
que se encontraban en la versión original. Esta es una gran ventaja

que nos ofrece el uso de NPTs.

A diferencia de la sincronización con impulsos de reloj, en este caso
no se envían descriptores NPT de forma periódica a modo de reloj
ya que esto consumiría mucho ancho de banda. Sólo se envían
descriptores para indicar cambios que afecten al NPT. El receptor se
encarga de calcular el NPT.

Los descriptores “NPT reference descriptor” informan al receptor
acerca de los valores del NPT en un punto específico del flujo,
mientras que los “NPT endpoint descriptor” le informan sobre el
inicio y el final de los tiempos para un evento en particular. Cada
descriptor “NPT reference descriptor” consta de tres partes
principales;

- Valor NPT: es el valor exacto del NPT en ese punto del
flujo.

- Tasa de NPT: las tasas son valores fraccionarios y se
almacenan como un numerador y un denominador. Esto
permite al receptor del NPT interpolar entre los valores de
referencia de un NPT de un descriptor y el próximo.

- ID del contenido: nos permite identificar las partes
anidadas de los contenidos.

Con la información recibida del valor y del ID podemos manejar
casos específicos del medio televisivo como puede ser la inserción
de anuncios. Si nos fijamos en esto desde el punto de vista del
receptor, un cambio en la identificación del contenido nos permite
distinguir entre varios casos:

- Si llega un descriptor NPT con un nuevo valor NPT y el
mismo ID de contenido que el anterior: discontinuidad de
edición.

- Si llega un descriptor NPT con un nuevo ID de contenido :

o Si también llega un descriptor de tipo “NPT
endpoint descriptor”: cambio de programa.

o En caso contrario: anidamiento (por ejemplo,
anuncios)

En el siguiente ejemplo se ilustran los tres casos, con los
descriptores asociados a cada discontinuidad:

Una vez que conocemos el funcionamiento del NPT nos surge otra
duda, ¿cómo accedemos desde las aplicaciones al NPT de un
determinado flujo?

Para ello usaremos los Stream Events, que son marcas que se
difunden y permiten al receptor (y, por tanto a las aplicaciones)
sincronizarse con puntos específicos de los flujos de contenidos.
Estos puntos específicos son los valores NPT.

Desde la perspectiva de DSM-CC, los Stream Events se dividen en
dos partes: los objetos DSM-CC Stream Events y los descriptores
de Stream Event. Los objetos DSM-CC Stream Events se almacenan
en un objeto carrusel y son como cualquier otro objeto DSM-CC. Un
objeto Stream Event describe los eventos permitidos en el servicio
correspondiente a ese carrusel, para ello incluye un identificador de
evento (que debe ser único dentro de ese carrusel) y el nombre del
Stream Event.

Por otro lado tenemos los descriptores, estos se insertan en el flujo
MPEG como un marcador y le informan al receptor de que un
evento ha sido creado. Cada descriptor de Stream Event tiene tres
partes:

- ID del Stream Event

- Valor NPT

- Datos específicos para la aplicación

La ID informa al receptor de cual de los objetos Stream Event esta
asociado a ese descriptor. Cada aplicación se suscribe al tipo de
evento que le interesa con la ID, el midleware ( la interfaz MHP que
hace de intermediario entre las aplicaciones y la red de difusión)
sólo avisa a las aplicaciones que están suscritas.

Existen dos tipos de descriptores de Stream Event:

- Do-it-now Stream Events

- Scheduled Stream Events

Do-it-now Stream Event

Si un terminal MHP recibe un Do-it-now Stream Event, entregará el
Stream Event y su carga útil (los datos específicos para la
aplicación que viajan el descriptor) de inmediato a la aplicación
MHP. Este tipo de descriptores sólo se envían una vez, por lo que si
el receptor lo pierde no hay forma de recuperarlo, por este motivo
el receptor debe adoptar las medidas necesarias para asegurarse de
que se recibe correctamente. Uno de los beneficios de estos
descriptores es que pueden utilizarse para sincronizar programas en
vivo, donde no sabemos de antemano en que instante vamos a
necesitar enviar un evento. Por ejemplo, durante un partido de
fútbol podemos mostrar la ficha del jugador que acaba de marcar el
gol. En este caso a priori no sabemos en que minuto del partido se
va a marcar un gol ni quién va a ser el autor, lo que haríamos sería
enviar un Stream Event cuando se marque el gol con el nombre del
jugador que ha marcado en el campo de datos del Stream Event.

Los Do-it-now Stream Events deben tener un identificador que esté
comprendido en el rango que va entre 0x0001 y 0x3fff.

Scheduled Stream Events

En este caso cada descriptor tiene asociado un valor de NPT que
informa de cuando debe ser activado el evento (para los Do-it-now
este campo es siempre -1). Esto permite al receptor conocer con
cierta antelación que tiene que activar un evento cuando el NPT
alcance un valor determinado. Además este tipo de descriptores
también añaden un poco más de fiabilidad ya que se pueden enviar
varios descriptores con los mismos valores con el fin de asegurarse
de que al menos uno de ellos es decodificado correctamente. Las

especificaciones de MHP nos dicen que es obligatorio reenviarlo al
menos 5 veces en los 5 segundos previos a su ejecución.

El problema de estos descriptores es que sólo se pueden usar en
programas pre-grabados, ya que se debe conocer con anterioridad
el momento en que debe ser ejecutado el evento para poder
incluirlo en el descriptor. Para la programación en directo, el
momento exacto de ejecución no se conoce y, por lo tanto, no es
posible especificar una fecha y hora en el descriptor. Por otro lado
la transmisión de la información por adelantado puede resultar
problemática. Si, por ejemplo, estamos generando eventos para un
concurso de preguntas y respuestas, la información acerca de la
respuesta correcta es enviada en el descriptor, y está disponible en
el receptor antes incluso de que se formule la pregunta. De este
modo, un jugador podría manipular el receptor y extraer la solución
a las preguntas antes de que estas se formulen y así ganar el
concurso más fácilmente. Para evitar estos problemas la mejor
opción es utilizar los descriptores Do-it-now.

El identificador de los Scheduled Stream Event debe pertenecer al
rango comprendido entre 0x8000 y 0xbfff.

Procesamiento de los Stream Events

Cuando llega un descriptor de evento de flujo:

1. Se comprueba si existe el ID del evento en los objetos
Stream Event del carrusel de objetos por defecto del
servicio. Si no existe se ignora el descriptor de evento.

2. Si es un descriptor Do-it-now se dispara el evento de
forma inmediata.

3. Si no es Do-it-now, se comprueba su NPT asociado: si ya
existe un evento con el mismo ID y NPT (es un reenvío) o
si el NPT ya ha pasado se ignora el descriptor de evento.

4. Si no estamos en el caso anterior, cuando el valor de NPT
correspondiente alcanza el valor especificado en el
descriptor de evento, se dispara el evento.

Una de las ventajas que ofrece la separación de los Stream Events
en objetos y descriptores es que nos permite reutilizar los eventos.
Varios descriptores pueden contener el mismo identificador de
evento, incluso si se activan en momentos diferentes pueden
contener distintos datos. Esto permite a una aplicación usar el
identificador de evento para definir distintos tipos de eventos. Por
ejemplo, siguiendo con el ejemplo del fútbol, los descriptores que

tengan el identificador 1 pueden indicar que se ha marcado un gol,
los que lleven el identificador 2 que se ha cometido una falta o el
identificador 3 puede indicar el final del partido. Por lo tanto, una
aplicación puede iniciar la tramitación de un evento conociendo
únicamente el identificador de evento.

Una vez que hemos visto como el receptor utiliza los Stream
Events, en el próximo artículo investigaremos sobre como una
aplicación puede hacer uso de ellos. Además ilustraremos esto con
un ejemplo de código donde explicaremos como hacer uso de los
distintos métodos.

ENLACES DE INTERES:

 http://www.interactivetvweb.org/tutorials/mhp

 http://es.wikipedia.org/wiki/Multimedia_Home_Platform

 http://mhpkdbwiki.s3.uni-
due.de/mhpkdbwiki/index.php/Synchronization

 http://mhpkdbwiki.s3.uni-
due.de/mhpkdbwiki/index.php/DSM-CC

 http://es.wikipedia.org/wiki/DSM-CC

 http://www.mhp.org/

 http://tvdi.det.uvigo.es/es/index.html

 http://www.mhpkdb.org/publ/mhp-guide.pdf

Categ CES OpenSouce/Java
orías
Tema Desarrollo

Autor Elena Gadea

Mes Octubre

Año 2008

Boletí 10
n

Título Buenas prácticas con Xlets
Texto La Televisión Digital Terrestre (TDT), no sólo permite ver la
televisión con mejor calidad, con subtítulos o en diferentes
idiomas, si se tiene un receptor adecuado, permite que se
ejecuten aplicaciones interactivas. Estas pueden ser de dos
tipos, aplicaciones ejecutivas o DVB-J (los llamados xlets) y
declarativas o DVB-HTML cuyo objetivo es crear un súper-
teletexto, pero que debido a la falta de recursos en los
descodificadores actuales este último tipo no está extendido.

En el diseño de cualquiera de ellas hay que tener en cuenta
sobre todo requerimientos de usuario:

 Que tenga una baja latencia, es decir, que no tarde en
cargarse, responder, …

 Que el telespectador pueda ponerlo en estado de
inactividad o destruirlo en cualquier momento (para que
no le moleste)

Teniendo esto en mente, se puede pasar a aspectos más
prácticos, ya que a pesar de basarse en Java, un xlet no
implementa todos los métodos y clases básicas de este
lenguaje. Se apoya en la versión 1.1 de Personal Java en sus
primeras implementaciones de la norma MHP (MHP 1.0.x),
aunque en la implementación 1.1.2 ya se basa en J2ME y
ofrece más funcionalidades que las primeras versiones,
también es cierto que necesita descodificadores con más
recursos. Además de Personal Java (su implementación es
similar a la de la versión 1.1.8 de Java) también usa partes de
las especificaciones JavaTV,HAVi (Home Audio Video
Interoperability), DAVIC (Digital Audio Video
Council), JMF (Java Media Framework), Java AWT y DVB.

Una vez que se tienen todas las librerías necesarias para crear
las aplicaciones hay que tener en cuenta que no todo lo que se
haga será correcto o funcionará. No basta sólo con definir que
la clase principal del programa implementa la interfaz Xlet y
reescribir los 4 métodos de la misma. Además de todo esto, el
desarrollador tendrá que recordar que:

 Se puede ejecutar más de un xlet simultáneamente.

 Las aplicaciones pueden no “verse” (no tener Interfaz de
Usuario, un interfaz gráfico que las muestre en la
pantalla del televisor).

 La máquina virtual de Java no termina cuando termina la
aplicación

 Su ejecución es controlada en todo momento por una
entidad llamada Gestor de Aplicaciones.

En cuanto a requisitos de programación se debe tener en
cuenta para escribir aplicaciones que se basan en la
implementación MHP 1.0.x que:

 Se basa en Personal Java 1.1

 Los ficheros class (es decir, las clases compiladas) deben
tener un número de versión entre 45.3 y 45.65535 (es
decir, deben estar compiladas con una máquina virtual
de java que no supere la versión 1.3), aunque el target
de la compilación se haga con la 1.1.

 No obliga a incluir entidades deprecated.

 No se puede confiar en la ejecución de los finalizers (es
decir, no tiene por qué ejecutarse el finally que sigue a
un try/catch).

 El uso de clases o métodos no incluidos sólo debe causar
error si se llega a ese punto en la ejecución.

 Cada aplicación usa su propio cargador de
clases lógico. Por tanto, habrá copias distintas de las
variables estáticas definidas por las aplicaciones.

Por otra parte hay que considerar que:

 Los Xlet no deben realizar acciones que afecten
globalmente a la máquina Virtual de Java, como por
ejemplo, las aplicaciones no deben llamar al método
System.exit().

 El método destroyXlet() debe recordar matar todos
los hilos de ejecución de la aplicación y cancelar
cualquier petición asíncrona que esté solicitando
información de servicio o de filtrado de secciones.

 El método destroyXlet(), e idealmente el pauseXlet(),
deberían liberar cualquier contexto gráfico que la
aplicación haya creado. La implementación MHP del
decodificador mantendrá referencias a estos salvo que
hayan sido eliminados correctamente con una llamada a
java.awt.Graphics.dispose().

 La aplicación debería recordar que puede ser pausada o

destruida en cualquier momento, y debería asegurarse
de que siempre puede liberar los recursos utilizados y
limpiar las variables.

 La aplicación debería respetar las restricciones que
pueden ser impuestas en las APIs básicas de Java. MHP
define un número de restricciones en clases que están
en java.lang y en otros paquetes que los desarrolladores
de aplicaciones deberían conocer.

 Las cuestiones relativas a los recursos son especialmente
importantes en un entorno de Televisión digital. Una
aplicación debería cooperar con otras donde sea posible
en cuestiones de recursos, y especialmente no debería
mantener recursos escasos más tiempo del que los
necesite. Se entenderá por recurso todos aquellos
elementos Hardware o Software que la aplicación
necesite y que sean ofrecidos por el descodificador. Los
recursos escasos son:

o Control de gráficos

o Cambiar de transport stream

o Acceso canal retorno

o Interaccionar con el usuario

o Acceso a módulos CA (Acceso condicional)

o Acceso a secciones MPEG2

 Una aplicación debe ser tan fiable como sea posible. Si
un método lanza una excepción, se debe recoger. Las
excepciones se lanzan por alguna razón.

 Se deberá hacer uso de hilos de ejecución para que no
se generen excepciones por que a los métodos
principales les cuesta terminar. El gestor de aplicaciones
espera que los métodos initXlet, startXlet, pauseXlet y
destroyXlet terminen en un tiempo razonable. Si esto no
se produce así, se generará una excepción.

RESTRICCIONES:

Teniendo en cuenta lo comentado anteriormente, que un Xlet
no podrá alterar la máquina virtual de java globalmente,
entonces no se pueden emplear los siguientes métodos:

 Runtime.exec, Runtime.load, Runtime.loadLibrary

 System.exit, System.load, System.loadLibrary,

System.in

 java.lang.Process

 System.setProperties, System.setSecurityManager

Además no se garantiza el funcionamiento de:

 Runtime.gc(), System.gc()

Dependiendo del descodificador, además estará implementado
o no:

 Runtime.runFinalizersOnExit, System.runFinalizersOnExit

 Thread.destroy, Thread.stop, Thread.suspend,
Thread.resume

 ThreadGroup.stop, ThreadGroup.suspend,
ThreadGroup.resume.

Por otra parte, todas las aplicaciones podrán utilizar
“file.separator”, “path.separator” y “line.separator” de
System.getProperty() y System.getProperties(), pero sólo las
aplicaciones autorizadas podrán emplear “dvb.persistent.root”

Dentro del paquete java.util.zip, se excluyen las clases
Deflater, DeflaterOutputStream, GZipOutputStream y
ZIPOutputStream, porque no se va a comprimir nada.

En el paquete java.awt, sólo se implementan las clases que no
son elementos gráficos. Es decir, se implementará todo en
java.awt.image y java.awt.event (de este paquete se
requieren como eventos mínimos: flechas, colores, números,
ENTER, TLXT).

La norma DVB que define las características de MHP sólo
contempla un tipo de fuente como obligatoria para las
aplicaciones, la “Tiresias” y en cuatro tamaños 36, 31, 26 y 24
puntos, a esta fuente se la considerará como residente. Si se
quiere que la aplicación tenga otras fuentes, se tendrán que
incluir con la aplicación, a estas fuentes se les denominará
fuentes descargables. El paquete java.awt.Font sólo es para
fuentes residentes y el paquete org.dvb.io.FontFactory es para
descargables.

Del Toolkit sólo es obligatorio el subconjunto:

 getDefaultToolkit, getFontList, getFontMetrics, sync,
getColorModel, todos los métodos de imágenes,
getScreenResolution, getScreenSize, …

 Además de PersonalJava se
añade: Toolkit.createImage(file) y
Toolkit.creataImage(URL).

Hay una parte del paquete java.net que es obligatoria para
todos los perfiles, puesto que se exigen ciertos identificadores
que están relacionados con las URLs. Así pues, todos los
perfiles deberán implementar:

 java.net.URL, java.net.InetAddress

 MalformedURLException, UnknownHostException

Además, algunos perfiles pueden añadir cosas, por ejemplo,
para hacer multicast sobre el canal de difusión, se emplearán:

 MulticastSocket, DatagramPacket

 DatagramSocketBindException, SocketException,
ProtocolException

Para hacer uso del canal de retorno mediante IP, se necesitará
casi todo el paquete java.net.

Así una vez que se tienen en cuenta todos estos elementos, se
podrá escribir un xlet más o menos fiable y que responda de
manera adecuada al usuario. Para obtener más información se
pueden consultar los siguientes enlaces:

ENLACES DE INTERÉS:

Xlets y MHP

 http://en.wikipedia.org/wiki/Xlet

 http://www.interactivetvweb.org/tutorials/mhp/xlet_intr
oduction

 http://www.interactivetvweb.org/tutorials/mhp/your_firs
t_xlet

 http://svn.collab.net/repos/svn/trunk/INSTALL

 http://es.wikipedia.org/wiki/Multimedia_Home_Platform

 http://www.mhp.org/fullspeclist.htm

 http://www.havi.org/

 http://www.davic.org/

 http://java.sun.com/javase/technologies/desktop/media

/jmf/

 http://java.sun.com/products/javatv/

 http://java.sun.com/products/jdk/awt/

 http://www.dvb.org/

 Descarga de clases necesarias para programación de
xlets http://www.interactivetvweb.org/content/code/mh
pstubs.jar

 http://www.mhproject.org/index.php/mhpenlaces/2007/
03/10/recursos_escasos_en_mhp

DVB-HTML

 http://homepages.cwi.nl/~garcia/material/DVB-
HTML.pdf

 http://digitv.ortikon.com/browser/dvb_html.html

 http://en.wikipedia.org/wiki/DVB-HTML

Categ CES OpenSouce/Java
orías
Tema Desarrollo
Autor Blanca Cubas Cruz
Mes Octubre
Año 2008
Boletí 10
n

Título Técnicas de mapeado de texturas. Parte 2

Texto Siguiendo con el tema del artículo anterior, en esta ocasión
vamos a ver otras 2 técnicas muy interesantes de mapeado
de texturas.

Displacement Mapping

Consiste en desplazar la posición de los puntos 3D de un
objeto, sobre su vector normal en función del valor que
obtenemos de nuestro mapa de desplazamiento. Recordemos
que el vector normal es aquel que señala hacia donde “mira”

o está orientado un objeto, y que el mapa de desplazamiento
(Displacement Map), es un mapa de valores que contiene la
información de la altura que vamos a aplicar en cada punto.
Este mapa de desplazamiento se puede generar
dinámicamente en el Vertex Shader o Pixel Shader de la
aplicación o, lo que es más cómodo, podemos utilizar un
mapa de alturas (Height Map), para que funcione como tal.
En el siguiente gráfico se puede ver el funcionamiento básico
del Displacement Mapping.

+

=
Estructura inicial Desplazamiento Estructura final

Como podemos ver en esta gráfica, en este caso, se modifica
la geometría de nuestro objeto. Esta es la principal diferencia
que existe con las técnicas vistas en el artículo anterior.

Este efecto, acompañado de alguna técnica de animación, se
utiliza bastante para simular el movimiento del viento sobre
hierba, ramas de árboles, etc… A continuación, podemos ver
como se modifica la dirección del vector normal de la hierba,
en función de la dirección del vector viento.

Parallax Mapping

Consiste en desplazar las coordenadas de textura de un punto
en función del ángulo existente entre el punto de vista y el
valor del mapa de altura en dicho punto. Cuando el ángulo de
vista es más abrupto, las coordenadas de textura se

desplazan más, y generan mayor sensación de profundidad.

Parallax Mapping

* Donde (u,v) son las coordenadas de textura originales, (u’,v’) son las coordenadas
finales y h(u, v) es el desplazamiento.

Este espacio 3D en el que trabajamos, es un sistema
generado por los vectores normal, binormal y tangente, que
son 3 vectores unitarios, perpendiculares entre sí. En la
siguiente gráfica se puede ver la transformación de las
coordenadas de texturas al espacio 3D:

* Donde, p (u,v) = p0+ (u-u0)T +(v-v0)B

Está técnica, también conocida, como Offset Mapping, es una
mejora del Normal y Bump Mapping. La diferencia se puede
observar a través de las siguientes imágenes:

De todas formas, al igual que en el anterior artículo, lo mejor
es ver un ejemplo. Debido a la extensión que supondría
mostrar ambos códigos, el implementado en este caso es el
correspondiente al Parallax Mapping.

//Lo primero que hacemos es definir las matrices de transformación y los
parámetros a //utilizar por defecto en nuestro efecto. Teniendo en
cuenta que en este caso estamos //trabajando con FX Composer.

float4x4 WorldITXf : WorldInverseTranspose < string UIWidget="None"; >;

float4x4 WvpXf : WorldViewProjection < string UIWidget="None"; >;

float4x4 WorldXf : World < string UIWidget="None"; >;

float4x4 ViewIXf : ViewInverse < string UIWidget="None"; >;

float4x4 WorldViewXf : WorldView < string UIWidget="None"; >;

float3 AmbiColor = {0.07f, 0.07f, 0.07f};

float3 SurfaceColor = {1,1,1};

float PhongExp = 128.0;

//A continuación definimos las texturas que vamos a utilizar. En este
caso muestreamos //las texturas de forma sencilla, pero si queremos
obtener una resolución mejor //deberíamos aplicar algunas técnicas de
filtrado.

texture WallTexture <

string ResourceName = "rockwall.jpg";

string ResourceType = "2D";

>;

sampler2D WallSampler = sampler_state {

Texture = <WallTexture>;

};

texture NormalTexture <

string ResourceName = "rockwall.tga";

string ResourceType = "2D";

>;

sampler2D NormalSampler = sampler_state {

Texture = <NormalTexture>;

};

//Vertex Shader

// Como ya hemos visto anteriormente necesitamos la normal, binormal y
tangente para //poder situar la textura en el espacio 3D.

//El VertexShader funciona de manera similar al del artículo anterior

void DisplacementVS (float4 Position : POSITION,

float4 color : COLOR0,

float3 normal : NORMAL,

float2 TexCoord: TEXCOORD,

float3 tangent : TANGENT,

float3 binormal : BINORMAL,

out float4 ohpos : POSITION,

out float2 oTexCoord : TEXCOORD0,

out float3 ovpos : TEXCOORD1,

out float3 otangent : TEXCOORD2,

out float3 obinormal : TEXCOORD3,

out float3 onormal : TEXCOORD4

)

{

float3x3 modelViewRotXf; //Definimos la matriz que utilizaremos para
generar el sistema 3D con la normal, binormal y tangente

modelViewRotXf[0] = WorldViewXf[0].xyz;



float4 Po = float4(Position.xyz,1.0);

ohpos = mul(Po,WvpXf); //Transformamos las posiciones al espacio 3D

ovpos = mul(Po,WorldViewXf).xyz;

otangent = mul(tangent,modelViewRotXf); //Obtenemos la tangente en
el espacio 3D

obinormal = mul(binormal,modelViewRotXf); //Obtenemos la binormal en
el espacio 3D

onormal = mul(normal,modelViewRotXf); //Obtenemos la normal en el
espacio 3D

oTexCoord =TexCoord.xy; //Obtenemos las coordenadas de textura

}

void DisplacementPS( float4 ohpos : POSITION,

float2 oTexCoord : TEXCOORD0,

float3 ovpos : TEXCOORD1,

float3 otangent : TEXCOORD2,

float3 obinormal : TEXCOORD3,

float3 onormal : TEXCOORD4,

out float4 finalcolor : COLOR0

)

{

float3 Vn = normalize(ovpos);

float2 uv = oTexCoord;

//Aquí es donde se crea el parallax map

float3x3 tbnXf = float3x3(otangent,obinormal,onormal); //Generamos
la matriz que nos permitirá transformar la posición al espacio de
coordenadas.

float4 relTex = tex2D(NormalSampler,uv); //Obtenemos el mapa de
normales de la textura

float height = relTex.w * 0.06 - 0.03; //Definimos el valor de
desplazamiento de los puntos de la textura a partir los valores del mapa
de normales.

uv += height * mul(tbnXf,Vn).xy; //Aplicamos el desplazamiento a la
textura

float3 tNorm = relTex.xyz - float3(0.5,0.5,0.5);

tNorm = normalize(tNorm.x*otangent - tNorm.y*obinormal +
tNorm.z*onormal);

float3 texCol = tex2D(WallSampler,uv).xyz; //Mapeamos nuestra
textura

//Computamos todos los valores de luz

float att = saturate(dot(Vn,onormal));//

float diff = saturate(dot(Vn,tNorm));

float spec = saturate(dot(normalize(Vn),tNorm));

spec = pow(spec,PhongExp);

//Computamos todos los valores del color

float3 col = AmbiColor*texCol + att*(texCol*SurfaceColor.xyz*diff +
spec);

finalcolor = float4(col,1.0);

}

//Aplicamos la técnica deseada

technique Displacement

{

pass p0

{

//Aquí compilamos y establecemos el Vertex Shader y elPixel
Shader que vamos a implementar

VertexShader = compile vs_3_0 DisplacementVS();

PixelShader = compile ps_3_0 DisplacementPS();

}

}

Las texturas que hemos utilizado son las mismas que en él
artículo anterior, para poder realizar comparaciones de
resultados.

A continuación se puede ver las diferencias obtenidas entre el
Normal Mapping (del artículo anterior), a la izquierda, y el
Parallax Mapping.

Sin tener en cuenta las diferencias de luz (debidas a los
parámetros utilizados), se puede observar mayor detalle de
relieve en la imagen de la derecha, y la sensación de realismo
es por tanto mayor.

Categorías CES Microsoft

Tema Desarrollo

Autor Goretti Ortigosa Rada

Mes Octubre

Año 2008

Boletín 10

Título Atando cabos.
Texto Cabo nº 1: en el último número de la revista "La Clave",
dirigida por José Luis Balbín, aparecía un articulo firmado por
Pedro Muñoz titulado "Las tecnologías, sin profesionales

especializados". En el mismo se citaban las declaraciones
que en octubre de 2006 realizó Rosa García, presidenta de
Micosoft Ibérica: "Para 2010 y por falta de formación, en
Microsoft Europa habrá 10000 puestos sin cubrir".
Y en un resaltado de dicho artículo se indica:
"35000 profesionales de la informática y de las
telecomunicaciones harán falta en nuestro país en 2010". En
términos proporcionales de población eso indicaría que en
Navarra harán falta unos 455.

Cabo nº 2: solicité a la empresa Adecco su "Guía Salarial
2008" acerca de las retribuciones de los profesionales del
área de IT en España, y muy amablemente me la enviaron
por correo.
En ella, entre otras cosas, detectan 25 perfiles clave en el
sector e indican su retribución por dimensión de la empresa,
sector económico, comunidad autónoma, edad y experiencia.
Los perfiles eran más o menos éstos:
Administrador de base de datos
Administrador de red
Administrador de sistemas
Administrativo
Analista de sitemas
Analista funcional
Analista orgánico
Analista programador
Comercial
Consultor ERP
Coordinador de help desk
Director
Diseñador web
Empleado de help desk
Experto en CRM
Jefe de proyecto
Jefe de sistemas
Operador
Operador de red
Profesor
Programador
Técnico de redes
Técnico de sistemas
Tester
Webmaster
Para Navarra estimaban unas retribuciones que iban desde los
14500 euros de un Empleado de help desk hasta los 43100 de
un Jefe de proyecto (quien, curiosamente, percibe más que
un Director de informática). Las cifras reflejan la Retribución
Total Anual Bruta.

Cabo nº 3: acudí en septiembre a un estudio de fotografía
para realizar unas fotos de carnet. Mientras eseperaba turno,
vi allí enmarcada la orla de la última promoción de titulados

superiores en Informática por la Universidad Pública de
Navarra. Pude contarlos: no era difícil. Dos filas de nueve
personas cada una de ellas: dieciocho ingenieros superiores
en informática acaban sus estudios en Navarra cada año.

Atando cabos: los puntos anteriores me hicieron pensar
sobre la situación del sector TIC. Un sector que,
tradicionalmente (si es que este adjetivo se le puede ya
aplicar), se consideraba atractivo a la hora de captar
empleados de diferente cualificación. Y que parece ser que no
los encuentra. A pesar de la cantidad de perfiles y
retribuciones que pueden acogerse bajo el apelativo de
'informático': "Habla con el informático." es una frase muy
alta en el ránking de cualquier tipo de empresa.
Por otro lado cada año se titulan en Navarra menos personas
que perfiles existen en el sector aunque es bien cierto que
algunos de esos perfiles, posiblemente, no necesiten esa
cualificación. Pero a un ritmo de 18 personas por año,
necesitaríamos un cuarto de siglo para paliar el déficit que
ocurrirá ¡en 2010!
De acuerdo que hay profesionales que pueden surgir de otras
ramas o de otros lugares (se habla mucho de Iberoamérica o
de la India). En todo caso todos estas personas deberán suplir
sus carencias (técnicas o idiomáticas) mediante formación,
algo que en tiempos de crisis chirría aún más que en los de
bonanza.

No sé si finalmente he conseguido enmarañar los cabos que
tenía pero si espero haberos hecho reflexionar sobre el
recurso más difícil de conseguir: el humano.

Si quieres enviar algún comentario o sugerir temas a tratar en otros artículos, escribe a:
curtasun[simboloArroba]cein.es

Categorías General
Tema Varios
Autor Carlos Urtasun
Mes Octubre
Año 2008
Boletín 10

Cesnavarra 2008-boletín 10

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Destacado

Destacado (20)

Similar a Cesnavarra 2008-boletín 10

Similar a Cesnavarra 2008-boletín 10 (20)

Más de Cein

Más de Cein (20)

Cesnavarra 2008-boletín 10