Foro x-plane.es

En primer lugar deciros que no sé exactamente si he ubicado bien el contenido en la web. Como se trataba de una especie de tutorial pues lo he puesto donde están los tutoriales. En otro caso agradezco a los moderadores el trabajo de moverlo a su sitio.

En segundo lugar que lo he hecho lo más rápido posible. Espero no tenga graves errores. De todas formas los mismos pueden corregirse.

Esto, en realidad, más que un tutorial es la forma en la que se me ha ocurrido la incorporación de los objetos 3d. Puede ir perfeccionándose entre todos y buscándosele variantes hasta que consigamos un método perfecto de incorporación de objetos.

LAS LIBRERÍAS DE GOOGLE SKETCHUP Y X-PLANE

En la página de Google sketchup hay miles de objetos 3d maravillosos que pueden ser instalados en el x-plane. Ej: http://sketchup.google.com/3dwarehouse/cldetails?mid=46f3f70fe38d801af6dcb9e43126f21d&prevstart=0 (http://sketchup.google.com/3dwarehouse/cldetails?mid=46f3f70fe38d801af6dcb9e43126f21d&prevstart=0)
 También podemos buscar más objetos por la red tecleando en Google “free 3d models”.

La cuestión de insertar esos objetos en el x-plane en el primer momento parecía imposible o extraordinariamente tedioso. No es ni una cosa ni la otra:

Para ello necesitamos las siguientes herramientas:

1º Sketchup  o Sketchup Pro con su plugin para x-plane.

2º XnView (es un programita free de tratamiento de imágines muy fácil y versátil)

3º Ultraedit (como siempre) o un editor de textos que sea potente.

4º Overlay editor (como siempre)


Empezamos:

1º Nos bajamos un objeto de google sketchup en su formato collada. De forma que contenga el objeto 3d y toda su librería de texturas.

2º Lo primero que tenemos que saber es que x-plane únicamente reconoce una textura por objeto (.obj) y en formato .png 256X256.

Los objetos que nos bajamos no están en formato obj. Asimismo llaman a varias texturas (normalmente jpg) y además estas texturas no tienen formato 256X256. Por tanto de momento imposible para x-plane.

PRIMER PASO

Entonces lo primero que tenemos que hacer es en vez de un objeto con muchas texturas es configurar  muchos (mini)objetos con una textura cada uno.

Como lo hacemos?. Imaginemos que tenemos un objeto que se llama castillo por ejemplo en formato .dae.

Dicho objeto al descomprimirlo tendrá dos directorios:
-   Images: donde se encuentran las texturas
-   Models: donde se encuentra el objeto 3d.

Pues bien vamos a ir configurando un objeto obj por cada textura. Para ello:

a)   Del directorio images o donde se encuentren las texturas las borramos o movemos todas menos una (la primera por ejemplo) supongamos que se llama texture0.

b)   Abrimos el Sketchup e importamos el objeto. 

Difiere la versión de Sketchup  v.8 a la versión 2013 (o Pro) a la hora de importar objetos. Mientras la primera los importa a un punto fijo, la segunda habilita la herramienta de mover para ubicar el objeto en el plano. Esto es peligroso puesto que si vamos a importar varias veces el objeto con diferentes texturas para crear tantos objetos como texturas, si los objetos importados no tienen exactamente la misma ubicación en el plano 3d, después, a la hora de ensamblar, no coincidirán las diversas partes del mismo, con un resultado lamentable.

Para ello hacemos lo siguiente:

-   EN SKETCHUP 2013:

1º) Importamos el objeto por primera vez sin ninguna textura.

2º) Después de ubicarlo o instalarlo en el plano lo guardamos como Plantilla (Barra de Menús - Archivo - Guardar como plantilla).

Esa plantilla se quedará como predeterminada mientras trabajamos con el fin propuesto y cada vez que arranquemos el Sketchup. (Cuando terminemos podemos dejarla como plantilla y usar otra o eliminarla : Barra de menús: Ventana - Preferencias - Plantilla).

3º) Ya con la plantilla operativa cada vez que importemos el objeto con una textura en las siguientes operaciones, lo haremos coincidir minuciosamente con la plantilla girándolo y comprobando que coincide con la misma en sus tres dimensiones.

Una vez coincidente con la plantilla ya podremos llevar a cabo la operaciones que se detallan a continuación y grabar y exportar los diversos objetos con la seguridad de que coincidirán bien en el ensamblado final.

-   EN SKETCHUP 8:

El Sketchup 8, como se dijo, no necesita la plantilla ya que importa siempre al mismo punto sin activar la herramienta de mover. Asi, en este aspecto, podemos decir que es mejor que el Pro.

c)    Al importar el objeto nos dirá que faltan texturas (ya lo sabemos) y lo importará sin texturar menos la parte a la que corresponde la textura que hemos dejado en el directorio que aparecerá texturada. Esa parte es la que vamos a configurar como nuestro primer .obj para después ensamblarlo con los demás con el Overlay Editor

d)   En el Sketchup lo que tenemos que hacer es borrar todo lo no texturado. Para ello

-   Una vez importado el objeto, seleccionamos todo (Editar-Seleccionar todo o CTRl+A). (En la v.2013 se encuentra todo seleccionado por defecto sin necesidad de CTRL+A)

-   Ahora hay que resaltar la superficie no texturada.(Barra de menús: Herramientas-HighLight untextured.

-   Así::

-    EN SKETCHUP 8:

-   Con la opción de menú : Herramientas-HighLight untextured.

§   Con la opción de menú: Herramientas – HighLight untextured se marcarán en rojo las áreas sin textura del objeto.

§   ( Hay que tener en cuenta (normalmente para versiones antiguas del Sketchup) que si con la opción de menú Herramientas-HighLight untextured no obtenemos el resultado apetecido de que nos seleccione exactamente la superficie no texturada, nos vamos a una capa de las no texturadas (rojo fuerte) y con la tecla de selección (space) pulsada vamos clikeando hasta seleccionarla ¡PERO OJO!, QUE QUEDE  SELECCIONADA SOLO LA SUPERFICE DE LA CAPA NO LOS VERTICES O ARISTAS DE LA MISMA, (ya que lo borraría todo) .Cuando la tenemos seleccionada: Boton derecho del raton – Seleccionar – Todo el material (asi veremos que nos ha seleccionado todo lo no texturado, si por cualquier motivo vemos que ha seleccionado zonas txturadas, shift+ratón las excluimos de la selección y ya está.)

§   Le damos en el teclado a SUPR y ya nos habrá borrado todo lo no texturado.

-    EN SKETCHUP 2013:

§   Con la opción  Herramientas-HighLight untextured ya resalta en rojo lo no texturado sin necesidad de ir seleccionando con varias pulsaciones y sin afectar a aristas ni vértices.

§   Le damos en el teclado a SUPR y ya nos habrá borrado todo lo no texturado.

e)   Una vez borrada la totalidad del objeto (menos la superficie texturada) lo grabamos con el sketchup y lo exportamos en formato x-plane dándoles nombre (Ejemplo casa1.obj,casa2.obj etc).

f)   Ya tenemos nuestro primer (semi)objeto con su única textura.

g)   Vamos al directorio de texturas,  borramos la que teníamos (texture0, como dijimos en el ejemplo) y en su lugar añadimos la textura siguiente y repetimos la operación anterior. Asi vamos configurando una a una las diferentes partes del objeto con su única textura que después ensamblaremos con el overlay editor.

SEGUNDO PASO

Una vez hecho lo anterior ya tendremos múltiples .obj ensamblables con su textura cada uno. Pero, normalmente dichas texturas no son .png 256X256 que son las única que quiere el x-plane.

Entonces utilizamos el siguiente programita: El XnView.

1º Abrimos el directorio donde están las texturas o las trasladamos a un directorio ad hoc y las seleccionamos todas en el XnView.

Después – Herramientas – Conversión por lotes (añadimos la carpeta donde están las texturas) – Formato de salida png – y en la solapilla de arriba (Transformaciones) configuramos- cambiar tamaño-añadir-Parámetros:ancho:256:Alto:256 y deshabilitamos las opciones “mantener proporción” y “seguir orientación”.

Ejecutamos en “Proceder” y ya tendremos todas las texturas en .png 256X256.

Atencion a un detalle: Hemos apreciado que algún objeto 3d tiene alguna textura con el mismo nombre pero con distintas extensiones. Es dedir P.ej: texture1.jpg y texture1.png.

Eso no nos serviría a la hora de querer implementar el objeto en x-plane y además, para que el XnView no sobreescriba y perdamos una de las texturas renombraremos una de ellas por ejemplo a texture1b.png

TERCER PASO: Asignacion de texturas.

Sabemos que los .obj del x-plane se pueden editar con un editor de texto y allí vemos la textura que tiene asignada. Como hemos visto en el paso anterior hemos cambiado la extensión de todas las texturas a .png y los obj (salvo excepciones) seguirán llamando a los jpg o texturas originarias.

Para cambiarlo lo hacemos con el Ultraedit. Para ello:

Abrimos el UEdit y –Buscar-Reemplazar en archivos- (le damos el directorio ) y le decimos que nos reemplace .jpg por .png en todos. Asi ya los obj llamarán a sus png.

También podemos hacerlo manualmente editando los obj uno a uno pero el método anterior es más rápido. NO OLVIDAR lo anteriormente expuesto respecto a texturas renombradas (texture0b, p.ej.) de manera que hay que procurar que cada obj. Llame a su textura particular.

CUARTO Y ULTIMO PASO: Inserción del objeto en una librería. No he querido detenerme mirando si hay algo en el foro sobre creación de librerías. La forma de crearlas se encuentra en http://marginal.org.uk/x-planescenery/library_tutorial/ (http://marginal.org.uk/x-planescenery/library_tutorial/) . De todas formas si alguien tiene problemas me comprometo a hacer otro dia una guía rápida sobre creación de librerías.

Seguimos. Para insertar nuestro nuevo objeto en una librería creamos un directorio de librería o creamos un nuevo directorio en el directorio donde tengamos nuestra librería de x-plane, con el nombre del objeto y en el mismo meteremos todos los obj y todos los png y lo pondremos en el fichero índice de objetos de la librería “library.txt”. Asi ya lo tendremos para poder usarlo en cualquier escenario..

Ya finalmente sólo nos queda ensamblar el objeto parte a parte en el escenario que queramos mediante el OVERLAY EDITOR de forma que establecemos el punto donde va a ir el objeto. Y ya sin mover para nada ese punto inicial, seleccionamos en la librería el objeto y vamos añadiendo mediante el botón + del overlay o pulsando enter las distintas partes del objeto hasta que quede incorporado al escenario.

That’s all.

Gracias  ^-^

No se me había ocurrido el hecho de eliminar las texturas para separar los objetos eliminando su correspondiente geometría, muy buena idea ;)

Sólo dos apuntes,

- X-Plane 9 admite texturas hasta 2048x2048 y X-Plane 10 hasta 4096x4096, y en cualquier relación de aspecto siempre que las medidas de X y Y sean potencia de 2 (256,512,1024, etc...).
Dicho esto, si fuera el caso que nos encontramos con texturas con unas medidas no estándares siempre las podemos redimensionar a las medidas apropiadas aunque la textura acabe deformada, el mapeado se calcula mediante fracciones del tamaño relativo, que siempre equivale a 1.

- No es necesario el uso de librerías (library.txt) siempre que metamos los objetos resultantes dentro de la misma carpeta del escenario (o subcarpetas que estén dentro). Los paths (rutas) virtuales siempre parten de la raiz (carpeta del escenario). Las librerías son útiles en otros casos como para referenciar un único objeto y que de éste se deriven objetos distintos para dar variedad, por ejemplo los coches (tanto estáticos como dinámicos), dentro del library.txt podemos definir un "objeto virtual" que se llame cars.obj y que este apunte -por ejemplo - a car01.obj, car02.obj, car03.obj etc donde cada uno de estos objetos sería un modelo de coche distinto. De este modo al crear un parking de coches en un escenario sólo debemos utilizar el objeto cars.obj, y X-Plane ya se encargará de aleatorizar los modelos al que hace referencia dicho objeto, y por si no fuera poco cada vez que se arranque el XP variará (no se si me explico...).
Las librerías también pueden ser útiles en otros casos (objetos backup, como el "placeholder" de opensceneryx), pero para un escenario que contenga objetos exclusivos no es necesario en absoluto.

Si me funciona todo bien ya colgaré algunas capturas.

De nada. Un placer compartir ideas con entendidos e interesados que al momento captan la esencia del tema.

Fíjate, ya he aprendido dos detalles más con tu respuesta: la dimensión de las texturas (creo que el 256x256 lo ví en algún sitio allá por la versión 8 y no volví sobre el tema) y el tema de las librerias. Yo lo utilizo porque hace tiempo empecé a elaborar una librería propia que siempre llevo de comodín con los objetos más atractivos que voy encontrando y cuando convierto un escenario o lo veo deficiente suelo tirar de la librería estándar en vez de incluir los objetos en los diversos escenarios.

Respecto a lo que comentabas en el otro post sobre la posibilidad de trabajar con comandos, por ahí van los tiros, se trataría de la elaboración de ficheros por lotes aunque desde dichos ficheros por lotes se requiriera la ejecución de aplicaciones externas en bucles o rutinas de ida y vuelta. No obstante, no sé por qué, siempre le tuve aversión al Blender y lo esquivé con el AC3D o incluso el SketchUp y respecto al Python igual; si no habia más remedio aguantaba Python, si no, déjalo por ahí.

El esbozo de la elaboración de un script o ejecutable para la ejecución del tema que nos ocupa (algunos objetos 3d tienen muchas texturas) no es, de momento, más que una idea y he de confesar que  me da un poco de miedo. He comprobado que cuando sólo eres aficionado, meterte en temas de programación es cuando más te absorbe la máquina en todos los aspectos.

Sería estupendo que los entendidos en la materia, como comentabas, se tomasen interés y analizasen la viabilidad del tema.

Lo importante es que la idea del spanish landmarks, que comentabas, fuera, con el granito de arena de todos, tomando forma y avanzando poco a poco... Y después el Europe landmarks... Y después el world landmarks... And so on...

Ok, acabo de hacer las primeras pruebas con un par de objetos de Barcelona, los mas sencillos que he encontrado (6 texturas cada modelo).

Torres Trade
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/ttrade_zps46f073ec.jpg)

Plaza España (torres venecianas)
(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/tvenecianas_zps03043e98.jpg)

Mola  ;D

La verdad, los objetos no son para nada óptimos para X-Plane, el segundo modelo tiene 20000 triángulos en total, pero almenos mi máquina ni se entera. Pero lo bueno es que el trabajo duro ya está hecho, y la conversión es facil mediante el tutorial, aunque repetitiva y monótona (he visto objetos con 400 texturas!!) pero es que nadie regala nada, y aunque aburrido a mas no poder merece muchísimo la pena. Os recuerdo a los que no habéis estado al caso, que me tiré un mes en modelar y texturizar la twr de LERS (sin hacer el vago y el gandul, no como ahora...), y esos dos objetos me han llevado sólo una hora convertirlos.

No me gusta el tema de automatizar el procesamiento de las texturas, he visto que te vienen en cualquier medida, relación de aspecto, etc... sin tener en cuenta estándares ni ná. Lo que he hecho -lo mas duro del proceso- ha sido abrir cada una en photoshop para redimensionar a las medidas habituales (potencia de 2) intentando mantener una relación de aspecto aproximada y siempre redimensionando a la baja (primer valor potencia de 2 mas bajo a partir del valor original).

También me he encontrado con algunos modelos que tienen caras sin texturizar (la Torre de Collserola por ejemplo, en cada uno de los cuatro modelos disponibles...) y estos requieren edición manual sí o sí. Pero ya puestos también se le pueden añadir las balizas luminosas, o si hay algún rascacielos con una helisuperficie en el tejado asignarle el atributo hard para que sea funcional, etc...


Y ahora la pregunta del millón... ya se que soy muy pesao con esto...
¿Cómo va el tema copyright con el contenido del Warehouse?

El ToS o EULA de google, al igual que casi todos está escrito en un idioma o mas bien con una jerga que no entiendo en absoluto.

http://www.google.com/intl/es/sketchup/3dwh/tos.html (http://www.google.com/intl/es/sketchup/3dwh/tos.html)

En lo que al contenido de Warehouse se refiere, dice:

(c) By publicly posting or displaying the content you give other end users of the Services a perpetual, sublicensable, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute (subject to the restrictions set forth in Sections 11.4 and 20.3 of these Terms) any Content or derivative works thereof which you publicly post or display on or through the Services.

Los usuarios finales (¿sólo los de warehouse o todos?) pueden adaptar, modificar y distribuir cualquier contenido o derivado.
Sujeto a las restricciones definidas en el párrafo 11.4 (el 20.3 no nos afecta)

11.4 Notwithstanding anything to the contrary, without Google’s prior authorization, you may not: (i) aggregate Content obtained from Google Services for redistribution, or (ii) use or distribute Content obtained from Google Services in a mapping or geographic application or service.

...Ahora ya me he perdido, no he entendido nada.

También he visto en foros que se permite el uso libre del contenido, pero ya sabemos que en internet no hay credidiblidad y menos cuando los participantes de dichos foros no tienen absolutamente nada que ver ni con Google, ni Trimble ni nada, son End Users al igual que nosotros...

¿Alguien que sepa de la materia puede arrojar algo de luz sobre este tema?
Claro que todo eso lo digo por si hay intención de publicar un escenario. Como siempre si se lo hace uno mismo y es para uso -exclusivo- privado no hay ningún problema.

EDITO
Tremendo!! 30 texturas  ;D

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/screus1_zps1d7878c9.jpg)

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/screus2_zpsa509ed50.jpg)

That's right!.

Con el hecho de que te entusiasme la idea (los resultados son fabulosos) ya me doy por casi satisfecho.

Respecto al tema que comentas de la redimensión de las texturas, el tema que señalabas del Photoshop me parece demasiado trabajo. Vale para un edificio concreto o que le tengas muchas ganas. Para el resto, la utilización del programita XnView (al que conocí exclusivamente por el tema de la redimensión de las texturas Google Sketchup), como indica el tutorial te permite la redimensión y la resolución de la textura por directorios enteros en cuestión de segundos. Échale un vistazo a la rutina de redimensión porque es bastante completa y si el resultado te es suficiente, fíjate el trabajo que te ahorras.

Sigo dándole vueltas al tema de suavizar el trabajo. Igual no hace falta tanta profundidad de programas externos. Quizá nos sobre con plugins internos que realicen el trabajo duro. Lo más duro es el importar - modificar - exportar que es la tarea repetitiva.

El Sketchup sólo lo he utilizado para el presente tema, para otras cuestiones 3d relacionadas con X-Plane siempre utilicé el AC3D. No tengo mucha idea más allá de la básica en el manejo del Sketchup. Pero recordé que siempre trabajé sobre los DSF a través del Ultraedit y de sus scripts elaborados en regular expresions con la herramienta que el mismo te suministra a través de lo que llama Macros.

Buscando a ver si había algo parecido en Sketchup he conocido que trabaja también, desde dentro, con programación de scripts con lo que él llama lenguaje Ruby.

http://www.sketchup.com/intl/es/download/rubyscripts.html (http://www.sketchup.com/intl/es/download/rubyscripts.html)

Eso podía salvarnos la vida: Un plugin interno o un par de ellos que: dándole un path con el directorio de las texturas: 1º Seleccionara primera textura. 2º Importara objeto 3º Seleccionara geometría texturada 4º Borrase el resto 5º Exportase obj 6º Pasase a la siguiente textura. Return.

Fíjate en esta página http://rhin.crai.archi.fr/rld/plugins_sections.php (http://rhin.crai.archi.fr/rld/plugins_sections.php) en la zona de Files/Misc hay algunos plugins que apuntan hacia nuestras intenciones. Así que por favor, !!alguien que conozca ruby!!!. No pedimos tanto.

Creo que merece la pena, porque el trabajo no es tan ingrato y los resultados son espectaculares. 

We keep trying...

Han quedado muy bien esos edificios.
Este tema se ha abordado ya algunas veces.

En el punto 11.4 viene a decir:

No se permite la distribución sin la autorización de Google en estos casos:

1- Agregar contenido de los servicios de Google para la redistribución.
ó
2- Utilizar o distribuir contenido a partir de los servicios de Google para programas de mapas o servicios geográficos.

Es sobre todo en el punto 2 donde Google incide especialmente, ya que algunos desarrolladores utilizaron estos recursos para utilizarlos en aplicaciones de navegación GPS en dispositivos móviles.

Por el tipo de contenido traslado el hilo como tema fijo a la sección WorldEditor (WED) & Overlay Editor
Sección para comentar dudas sobre la creación de escenarios, aeropuertos y objetos para x-plane.

Si, creo que yo he estado presente algunas de las veces que se ha abordado :D
Pero ahora ya es un hecho  ;D

Na, esto está solucionao ya.

He encontrado un script para Gimp que hace exactamente lo mismo que yo con PS, escalar las texturas a potencia de 2, tanto X como Y al valor mas bajo.
Bueno de hecho el script lo hace a la alta pero me "he iluminao" y mi modificación funciona.

http://gamedev.stackexchange.com/questions/12997/tool-to-convert-textures-to-power-of-two (http://gamedev.stackexchange.com/questions/12997/tool-to-convert-textures-to-power-of-two) (último post)

Corre desde línea de comandos y procesa por lotes, todos los jpg de dentro de la carpeta.
No me preguntes porqué pero dentro del script he visto la palabra "ceiling" y la he sustituido por "floor" (lógica aplastante, notése la ironia...) y al ver que el NP++ me ha pintado la palabreja de color azul he pensado, ¡no si hasta será un comando válido y todo! y cierto... he invertido el funcionamiento del script y el cálculo lo hace a la baja. En serio, ha sido un "por probar que no quede..." ya que apenas sabía lo que hacía.

El script original con mi modificación (he cambiado el comentario también)

No me convencía el Xnv por el hecho de que escale a unos valores fijos y por ejemplo, el objeto de la última captura tenía entre otras, una textura de 352x1106 y con este script queda reducida a 256x1024, si ahora le sumamos que se ejecuta desde línea de comandos y procesa por lotes, creo que lo convierte en "cuasi-perfecto" para este cometido.

Los scripts de SU me los tengo que mirar aún, a ver si mañana cuando salga del curro puedo echarle un vistazo.

Estupendo!.

Ya sabía yo que la semilla caía en buena tierra...

Si pudiéramos conseguir algo respecto a la cuestión de atenuar el trabajo repetitivo, sería genial!.

We keep trying.

Acabo de encontrar este plugin de SU
http://rhin.crai.archi.fr/rld/plugin_details.php?id=744 (http://rhin.crai.archi.fr/rld/plugin_details.php?id=744)

Select by material - el nombre lo dice todo.

Básicamente con esto te ahorras todo el peñazo de ir eliminando las texturas e importar el modelo constantemente para separar los objetos.
Consta de dos partes; Selección de las entidades POR MATERIAL y ocultar entidades no seleccionadas.

Con el modelo ya importado:

-Seleccionar el material (textura) desde la ventana de materiales
-Llamar "Material Selection" (desde el menú complementos)
-Llamar "Hide All Un-Selected (menú complementos)
-Guardar modelo (tal y como se dice en el tutorial, dándole un nombre distinto cada vez)
-Exportar a X-Plane.
-Deshacer última acción (Menú edición / tecla Alt+Retroceso)
-Repetir desde el primer paso, para cada textura que tenga el modelo.


No sólo quita trabajo a la hora de hacerlo manualmente, creo también que el script para automatizarlo sería mucho mas simple; a partir de la lista de materiales del modelo se van llamando las funciones de este plugin y que repita el proceso hasta terminar con la lista, sin tener que lidiar con archivos externos ni nada...
 
:-u- :-u- :-u-

Y yo sin poder perderme, bueno, solo con la lectura  :D :D, para cuendo disponga de los medios ya habreis creado media España, (la otra media va bien  :P )

Venga compañeros, todas las manos son pocas. Es un tema complicado, pero como salga más o menos bien, !vaya pelotazo!.

Grrr05, en el tema gráfico eres un crack. Cuesta trabajo seguirte.

He estado probando el plugin que comentabas referente a material select. Podría ser una solución intermedia mientras se consigue otra más elaborada. Pero me está volviendo loco. Con algunas texturas funciona y con otras no, dentro del mismo objeto. Tiene problema a la hora de fijar la selección, de forma que no selecciona y, lógicamente al ejecutar el hide unselected borra la totalidad del objeto.

Lo he probado en Sketchup 7 (ya que la página dice que se hizo para el 7) y en Sketchup 8, 32 y 64 y hace lo mismo: Con algunas texturas no da problemas, con otra no las fija, no las selecciona. Y la cuestión es que no encuentro el criterio por el que actúa de esa manera cuando analizando las texturas son prácticamente iguales. Las he redimensionado e incluso cambiado de formato y nada. Ya no sé si pudiera ser su ubicación en el objeto por cuestión de grupos, aristas o vértices, pero tampoco debiera ser. La verdad es que me tiene desconcertado.

Por favor, échale un vistazo a ver que te parece.

Yo ayer le heche un vistazo a este tema, la verdad que hay objetos muy chulos que quedarian de lujo en los escenarios de xplane, de hecho me baje 2 de ellos muy chulos, una palmera en 3d  y un hangar con una torre de la 2 guerra mundial o asi, y me tire hasta las 2 de la  madrugada con la dichosa palmera y nada que no habia manera de hacerla funcionar en xplane, y eso despues de aver seguido el tutorial paso por paso.

El problema es el largo proceso que hay que hacer, pero si funcionara de una manera mas sencilla seria la leche, hay miles y miles de objetos que harian que nuestro simulador fuera perfecto, si a eso le añades que para mover un programa de diseño 3d como sketchup hace falta un ordenador potente la cosas enmpeoran, solo para cargarme la dichosa palmera el ordenador tardaba lo suyo...

La idea es muy buena, a ver si con el tiempo se pule y logramos que el proceso de conversion a xplane sea mas facil, solo de pensar como quedaria la palmera y el hangar en el aeropuerto de mundana, en un estilo parecido al creado por khamsin, se me hace la boca agua......

En fin 1 cordial saludo.

Pásame el enlace, yo no he encontrado ningún problema acerca de esto con los modelos que tengo. Si que es cierto que la selección por materiales sólo es efectiva dentro de un grupo, pero todos los collada que he importado siempre me han aparecido como un único grupo. El otro problema que vi es que algunos modelos utilizan texturas png para las transparencias, en sí no es un problema pero el nombre del archivo puede dar mucho por saco, ya que los png siguen su propia numeración con lo que nos podemos encontrar con un texture5.jpg y otra texture5.png, distintas entre ellas y que forman parte de distinto material.

De hecho ayer por la tarde estuve recordando mis primeras clases de programación en basic (que abandoné por completo), buscando ejemplos de ruby y mirando la documentación de las API...
Fué mi primer intento de script para SU, al que copié las dos rutinas del Select by Material para automatizar el este paso.

La cosa acabó con que teniendo el modelo importado y el material seleccionado, se ejecuta el script desde el menú complementos y hace automáticamente todos los pasos hasta la exportación del obj.
Es decir, seleccionar material -> ejecutar script, seleccionar material -> ejecutar script and go on... y van apareciendo los obj exportados.

La cosa es muy preliminar y estoy buscando la manera de contabilizar los materiales para crear un bucle "FOR iteracion = 0 TO num_materiales" (o como sea...) para seleccionar un material cada vez y que cada objeto resultante contuviera un nombre de archivo como un texto fijo seguido del número referente a la textura del material (así relacionamos OBJETO24.obj con TEXTURE24.png, mas que nada para mantener un poco de orden).
Por ahora no he logrado que el nombre del archivo pueda contener el valor de una variable juntamente con el texto pero sigo probando (actualmente el nombre del archivo lo tengo hard-coded dentro del script, lo que requiere renombrarlo manualmente).

Por ahora lo que hace el script es

-ejecutar material_selection
-ejecutar hide_all_unselected
-guardar archivo
-cargar archivo guardado (paso necesario porque el comando model.save sólo guarda un archivo pero no lo deja activo en SU, y el SU2XPlane lo requiere.
-llamada al módulo XPlaneExport (obviamente requiere el SU2XPlane instalado)

Mis conocimientos de programación som limitadísimos y eso habría que pulirlo mogollón, pero antes tendríamos que averiguar esos fallos de selección o buscar otro método para la separación de objetos, sin descartar la propuesta inicial de ir borrando texturas, que por ahora parece lo mas fiable.

En fin, si tengo un rato esta tarde seguiré rompiéndome los cuernos, que esto promete jeje.

Enhorabuena por el método. Hasta ahora yo también he usado algún objeto "libre" del sketchup pero lo de convertir varias texturas en una sola era un coñazo..........

Y sobre el tema de "libre", nada es libre en el círculo todopoderoso de Google. Hay que tener cuidado con eso.

Ahora bien, no sé si sería producente o contraproducente (levantar la liebre) hacer escenarios con objetos convertidos del sketchup (objetos "libres") y poner la referencia al autor en el archivo de autoría correspondiente. Desde luego, desde nuestros agradecidos ojos, sería lo más lógico pero, eso... la liebre...

Bueno a ver si no explota nada...

El intento de script "semi-automático" para exportar los modelos.
https://dl.dropboxusercontent.com/u/59143574/WH2XP.7z

Debido a mi torpeza, etc, lo primero que hay que hacer es importar el modelo en formato Collada y guardarlo en formato SKP en cualquier sitio (de este modo asignamos el directorio de trabajo, no he encontrado otra manera de hacerlo).

Seleccionar el material (desde el primero) y ejecutar el plugin desde el menú Complementos -> WH2XP y repetir para cada material. No hay que hacer absolutamente nada mas (aparte de darle a Aceptar cuando aparezca la ventana del SU2XPlane)
Cada objeto exportado tiene el nombre "obj_WH2XP#.obj" además de conservar una copia del skp con el mismo nombre.

Alberto prueba y me cuentas. No he tenido en cuenta los fallos de selección (está basado en el mismo plugin Select By Material), hasta que no me tope con un modelo de estos no lo podré mirar.

Grrr05, el plugin va perfecto. La verdad es que estoy impresionado. Resuelve perfectamente el núcleo de la cuestión.

El único problema es el que te comentaba antes. No sé por qué hay texturas que el Select Material no fija. No selecciona.

Entonces, como te apuntaba en el anterior post al ocultar no seleccionadas borra la totalidad del modelo y entonce el script lógicamente dice "Nothing to export" con ausencia de ese obj.

Prueba con este "maldito" a ver por qué.

http://sketchup.google.com/3dwarehouse/details?mid=24be3b23f40bf7acaee554f9566360dd&prevstart=0 (http://sketchup.google.com/3dwarehouse/details?mid=24be3b23f40bf7acaee554f9566360dd&prevstart=0)

Por lo demás, es script va de fábula.

Bien, me alegro aunque como dije, es muy preliminar. La idea es -intentar- que él mismo se vaya ejecutando conforme la lista de materiales, hasta que termine con todos, de este modo sería mas "a prueba de errores humanos" ya que siempre nos podemos equivocar al seleccionar el material y el script sacaría un obj duplicado pero con distinto nombre. Aunque tampoco nos eximirá de darle al "Aceptar" del SU2XPlane cada vez... pero cuanto menos trabajo y mas libre de errores mejor.

Sobre el modelo maldito, parece ser que tiene materiales que no están mapeados. Eliminándolos de la lista no observo ningún cambio aparente en el modelo dentro de SU, de todas maneras lo probaré como obj a ver que tal dentro de X-Plane.
Tengo que mirármelo con mas detenimiento pero creo que el "Nothing to export" del XPlaneExporter es debido a que realmente no existe geometría al que haga referencia tal material, con lo que el Select by material está cumpliendo perfectamente su cometido. Además he visto que los materiales que fallan están repetidos junto con las texturas, salvo por ligeras diferencias de tamaño, eso apunta bastante a la causa, fallo del creador supongo.

Ah, se me olvidaba!
Cuando se termine de procesar un modelo con el script, es necesario reiniciar el SU siempre y cuando haya intención de procesar otro modelo, ya que la numeración incluida en el nombre de los objetos segurá aumentando. Otra opción supongo que sería recargar el script desde la consola de ruby.

He seguido peleando un buen rato con "el maldito" y de la siguiente

http://sketchucation.com/forums/viewtopic.php?f=323&t=28782#thomthom (http://sketchucation.com/forums/viewtopic.php?f=323&t=28782#thomthom)

descargué el Materials Tools. No recuerdo si para instalarlos son .rbz o .rb.

El caso es que ejecutando el plugin en la opción Remove Backface materials  te dirá de golpe el material que se puede seleccionar y el que no de todo el modelo.

Creo que va por aquí la cosa:

http://cad-3d.blogspot.com.es/2010/11/fix-reversed-faces-in-sketchup.html (http://cad-3d.blogspot.com.es/2010/11/fix-reversed-faces-in-sketchup.html)

respecto a lo que apuntabas de fallo del creador.

http://sketchucation.com/forums/viewtopic.php?t=30107 (http://sketchucation.com/forums/viewtopic.php?t=30107)

Entonces me asalta la duda y la preocupación de si el hecho de encontrarse un modelo así daría al traste con el actual proyecto de exportación por seleccion de materiales. Es decir, que por la antigua "cuenta de la vieja" de ir borrando texturas del directorio, que originariamente teníamos, sí podríamos obtener "el maldito" para x-plane, Pero si descargamos un modelo que adolezca de estos defectos no sé si haría inviable todo el método de obtención del obj por selección de materiales (texturas). No lo sé. Tampoco sé si pudiera tener otra solución ya que sería una pena con lo avanzado que va el plugin.

Si realmente la causa es que no existe geometría que contenga esos materiales no debería haber ningún problema, pues no se exportará el obj y quedará una textura perdida que luego se puede borrar si la identificamos, no creo que eso sea un mal mayor, y para nada tendría que afectar al funcionamiento del script ni al obj final.

De todas maneras me estudiaré este plugin y ya de paso también mirar si existen otros que se puedan aprovechar como por ejemplo optimización de meshes y cosas por el estilo (de verdad que las torres venecianas no sé de donde sacan los 20000 triángulos, me parece una burrada de marca mayor).

Voy a estar fuera todo el finde y hasta el lunes no podré mirar nada, pero si vas encontrando ideas y mas plugins útiles deja constancia aquí mismo ;)

Ok.  :)

Uf acabo de probar a fondo con el objeto ese y estaba yo eqivocado. Sólo se exporta una pequeña parte del objeto, el resto del cuerpo del edificio no, que casualmente tiene un único material mapeado en todas las caras internas (y este si que se selecciona correctamente)...
 
Eso se complica por momentos. Habría que averiguar que pasos y condiciones se necesitan para arreglarlo. Si todo ese embrollo sigue algún tipo de lógica no debería haber problema para "scriptearlo".
:-u-

Diana!
Es correcto, el problema son la caras mapeadas por el reverso y he visto en un hilo sobre el Select by Material que efectivamente sólo funciona con el anverso. Puede que sea un fallo del autor o puede que no, ya que en SU invirtiendo las caras se consigue voltear la textura (yo lo he hecho en varias ocasiones). No es manera de hacer las cosas pero las herramientas que lleva SU para texturizar son pésimas y no tienen nada que ver con las de Blender, donde se realiza un UVmap puro y duro. He mirado el plugin Fix Reversed Face Materials y aunque modificando a mano las caras afectadas la selección funciona perfectamente, es imposible automatizarlo ya que por sí sólo -obviamente- es incapaz de determinar si la cara mapeada por el reverso está hecho a propósito o ha sido un error del autor.

Entonces se me ocurren tres soluciones:

-Sólo ocurre con modelos exportados (collada), con el formato nativo no hay problemas -> Trabajar directamente sobre el SKP descargado de Warehouse y que el script exporte las embedded textures a archivos jpg o png, reasignando los materiales a dichas texturas y siguiendo el procedimiento actual.

-Modificar de alguna manera el Select by Materials para que también seleccione los reversos de las caras (intentado y por el momento un fracaso, pero no me rindo)

-La idea original de eliminar la geometría no texturizada, pero en vez de borrar las texturas directamente, hacerlo con los materiales, así nos ahorramos los mensajes de error de la importación debido a las texturas ausentes y sus correspondientes [Aceptar]. Quizás esta sea la mejor, menos cálculos, menos algoritmos, menor coste computacional (...), ¿a prueba de errores?

Yo opto por la última.

!Perfecto!. El núcleo del plugin WH2XP, con el primer método y actuando directamente sobre el .skp va perfecto.

Exporta el .obj y la textura correspondiente y ya solo queda operar sobre la textura para hacerla compatible.

Exportado sin problemas "el maldito" mediante: 1º Selección de material. 2º Aplicación del plugin. Sólo dio problemas una textura que se solucionó desde el propio SU seleccionando como material la correspondiente textura de collada y aplicando el plugin.

De todas formas, de los tres métodos apuntados, lo dejo a tu elección. Yo sólo puedo decirte que estoy alucinando con la efectividad y la rapidez del desarrollo que estás llevando a cabo.

Lástima que tengas que hacer el paréntesis del fin de semana. Pero así se cogen más fuerzas. Los fines de semana son sagrados. Ya lo decía Obama en el slogan de su campaña a la presiedencia de los EEUU: "!YES, WEEK END!".  ;)

 

En otro orden de cosas, me gustaría dar mi opinión a todos acerca de una cuestión que ha salido de forma reiterada y que veo que está siendo o pudiera ser fuente de preocupación: el tema copyright con relación al contenido del Warehouse.

Con referencia a la cuestión de los derechos de propiedad intelectual y su relación con Internet, todos sabemos que hay que distinguir lo que es contenido protegido (“copyrighted”) y free software en sus diversas modalidades.
El primero es "intocable" por decirlo de alguna manera y sin más extensiones interpretativas que dieran lugar a confusión o discusión. En España viene protegido, fundamentalmente, por las Leyes de Servicios de la Sociedad de la Información, De impulso de la Sociedad de la Información y los criterios generales de protección de la propiedad intelectual contenidos en la Ley de Propiedad Intelectual y, respecto a las infracciones más graves, el Código Penal.
En cuanto al segundo, dentro del género denominado "software libre" tenemos varias modalidades: Véase http://es.wikipedia.org/wiki/Software_libre (http://es.wikipedia.org/wiki/Software_libre) aunque los conceptos, en muchos casos no están perfectamente delimitados.

Visto lo visto y teniendo en cuenta que los modelos descargables de WareHouse han sido puestos por sus autores con evidente dicha finalidad; es decir que todo el mundo los conozca y puedan descargarlos para su propio uso y disfrute, yo incluiría los mismos dentro de la categoria de "dominio público".
Si así fuera, entiendo que la relación con el autor más que un carácter legal tiene un carácter moral.

Pero a ese oscurantismo de conceptos hay que añadir aún mas: las pretensiones del hosting o titular del alojamiento. Asi Google expresa, como señalaba grrr05 más arriba que

c) By publicly posting or displaying the content you give other end users of the Services a perpetual, sublicensable, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute (subject to the restrictions set forth in Sections 11.4 and 20.3 of these Terms) any Content or derivative works thereof which you publicly post or display on or through the Services.
Y a continuación:
11.4 Notwithstanding anything to the contrary, without Google’s prior authorization, you may not: (i) aggregate Content obtained from Google Services for redistribution, or (ii) use or distribute Content obtained from Google Services in a mapping or geographic application or service.

Es decir, la cuadratura del círculo. El oscurantismo. Lo imposible. Donde antes dije digo, ahora digo Diego.

Más claro parece el nuevo TOS http://sketchup.google.com/3dwarehouse/preview_tos.html (http://sketchup.google.com/3dwarehouse/preview_tos.html) que dispone:

"Rights granted to other end users of the Services. You give other end users of the Services a perpetual, sublicensable, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute Existing Geolocated Models, Existing Non-Geolocated Models, New Models and related content and derivative works thereof which you submit, post or display on or through, the Services."

Parece claro, ¿verdad?. Pues ahora leedlo en español desde el punto de vista de Google:
http://www.google.com/policies/terms/update/ (http://www.google.com/policies/terms/update/)

"Al subir contenido o al enviarlo por otros medios a nuestros Servicios, concedes a Google (y a sus colaboradores) una licencia mundial para usar, alojar, almacenar, reproducir, modificar, crear obras derivadas (por ejemplo, las que resulten de la traducción, la adaptación u otros cambios que realicemos para que tu contenido se adapte mejor a nuestros Servicios), comunicar, publicar, ejecutar o mostrar públicamente y distribuir dicho contenido."

Y la pregunta del millón: Por el hecho de subir un modelo a los Servicios se entiende ¿que el autor concede (a quien sea) licencia? o ¿que muestra su disposición a conceder licencia?.

Toda la cuestión está, al menos de momento, construida sobre sutilezas de este tipo

En fin, sobre este tema en la red y fuera de ella corren ríos de tinta.

Opiniones: todas las imaginables.

Respuesta única, cierta y con garantía de éxito: absolutamente ninguna.

Independientemente de las vinculaciones contractuales que pretenden por el alojamiento de los contenidos, que son meramente contratos de adhesión (el “I agree”) y con manifiestas claúsulas oscuras que en doctrina de interpretación de contratos nunca deben favorecer a los que las imponen y muy castigadas por la legislación referente a la defensa de los consumidores y usuarios, habría también que analizar la vigencia espacial y temporal de las leyes reguladoras de tales términos.

Pero lo que sí os puedo asegurar es que todas estas cuestiones no son ciencia exacta. Aquí, llegado el momento, nada es verdad ni mentira sino que todo “depende del color del cristal con se mira”. Y de la posición del intérprete.

Aunque desde el más delicado punto de vista de la distribución comercial, habla gente coherente en el siguiente hilo con el denominador común de “Be practical about it, cover your backside…”
http://sketchucation.com/forums/viewtopic.php?f=79&t=38857 (http://sketchucation.com/forums/viewtopic.php?f=79&t=38857)

Asi las cosas yo propongo (al menos, es lo que yo pienso hacer) que una conducta coherente sería la siguiente:

Los modelos descargables de carácter free, entiendo son de dominio público y son libremente de uso y disfrute de los usuarios, sin mayor complicación ni más historias, para uso particular.

Si el problema, o la preocupación, o el origen de las suspicacias puede venir por el tema de la publicación o redistribución, pues no se redistribuye y ya está.

Siempre consideré al X-Plane como una inmensa maqueta. El X-plane no es un juego. Ni solamente un simulador. Es un hobby en toda la extensión de la palabra.

Por tanto, que cada uno se haga su maqueta a su gusto. Lo importante es que los materiales están disponibles para cada uno gracias a la liberalidad de sus autores que los ponen a disposición del público.

Y con el magnífico trabajo que está realizando grrr05, la implantación de los edificios en el universo x-plane es un auténtico gustazo. Ya no es tan necesaria la colaboración de varios como antes, que el trabajo podía resultar monótono y aburrido.

Por eso es tan importante la obtención de un buen método: para que uno solo pueda hacer el trabajo de diez. Digamos que, como va el tema, si hace una semana se podía implementar un edificio, con algún esfuerzo, en una hora, hoy se pueden hacer 10 en el mismo tiempo y sin esfuerzo. Y sigue perfeccionando el método.

Hoy, por lo expuesto, ya no es necesario distribuir sea lícito o no. El “hágaselo usted mismo” es un auténtico gustazo. Para no tener ningún tipo de preocupación sea motivada o paranoia, sí se pueden publicar screenshots con los trabajos de cada uno en su propia maqueta o links a los contenidos usados y que todos tienen ya a su disposición en las numerosas webs de Google SketchUp.

Un hobby es para disfrutar y pasarlo bien, no para crear suspicacias o preocupaciones y menos aún problemas.

Y lo que nunca se me ocurriría es realizar una redistribución del contenido de Google SketchUp, aunque sea free, con ánimo de lucro o fines comerciales. Eso lo veo de sentido común.

Pero, en fin, que cada uno use su propio sentido común.

Perdonad la parrafada, pero creo que la cuestión lo exigía.

Gracias por tanta información, Alberto.  ;)

Estoy de acuerdo contigo, aunque yo añadiría que: en el caso de querer distribuir una librería/escenario con algún objeto cogido del warehouse, es muy sencillo enviarle un email al autor solicitando su uso para lo dicho (escenario/librería) añadiéndole que se le citará como autor del mismo.

Yo dudo que nadie se niegue (ya que lo han subido libremente al warehouse).

Con este acto, se podría considerar que el autor del objeto te lo ha dejado libremente, bajo esas condiciones, a parte de subirlo al warehouse. Es decir, ¿qué fue antes, el huevo o la gallina? Google no se podría quejar pues ellos han recibido dicho objeto al igual que lo has recibido tú.

Un ejemplo: los edificios de la terminal de GCHI. Los he hecho con el sketchup y alguno de ellos lo subí al warehouse. Al mismo tiempo, una persona me pidió permiso para usar dichos objetos para un proyecto personal (que no tenía que ver con x-plane) y se los di encantado. En este caso, no veo de ninguna manera que Google pueda "poner una querella" a esta persona por hacer uso de un objeto que le he cedido yo personalmente.

Totalmente de acuerdo contigo Cestomano.

Esa actitud arrojaría toda la luz sobre el tema y nadie podría replicar nada en contrario.

Imagino que alguna posición más concreta tendrán que adoptar porque se van a poner muchos ojos en la librerías cuando bajen los precios y se hagan asequibles al gran público las impresoras 3D.

Aprovecho la ocasión para agradecerte tu magnífico escenario. Desde el primer momento se quedó clavado en mi maqueta.

Me alegro que te guste. Más agradezco el esfuerzo tuyo y de Albert con este script.

Ay cuando estemos al alcance de una impresora 3D...  ;D

Grrr05, antes de tomar una decisión sobre el método a seguir, ya que hay que evaluar todas las posibilidades que se puedan presentar, échale un vistazo a este otro toro:

http://sketchup.google.com/3dwarehouse/details?mid=d7b4e832925e9715bf86b1df48dc2d65&prevstart=0 (http://sketchup.google.com/3dwarehouse/details?mid=d7b4e832925e9715bf86b1df48dc2d65&prevstart=0)

La duplicidad en el nombre de las texturas no tiene mayor inconveniente. Se puede arreglar sin problema.

Pero se empeña en recordarnos que no es lo mismo trabajar con materiales que directamente con texturas. Así:

Si trabajas directamente sobre el .skp te ofrece 64 materiales. Y si importas el collada te ofrece 124 materiales. Si trabajas sobre el collada, presenta, como el otro modelo, el problema de las Backfaces.

Pero si trabajas directamente sobre el .skp acaba exportando unos 60 objetos a los que pretende satisfacer con unas 15 texturas y, además, a las texturas le da unos nombres largos que después los .obj no pueden asimilar.

Es curioso, el modelo anterior ("el maldito" por el tema de las backfaces) no dio ningún problema de éstos.

El método de "la cuenta de la vieja" sigue funcionando sin problemas. Por ello creo que debemos apartarnos lo menos posible de la idea original. El plugin de Select Material nos abrió una puerta de esperanzas que, a lo mejor, eran demasiado precipitadas. Quizá fuera mejor trabajar directamente sobre las texturas. No sé. Tú eres el jefe.

Ya no te digo más cosas durante el fin de semana, no vaya a ser que no puedas resistir la tentación de echarle un vistazo de reojo al foro aunque sea desde un móvil y empieces a darle vueltas al "tarro".  :-X

Cayó, Cayó. Aunque sin plugin hay que tener paciencia. Pero quería verlo domado.

Tiene alrededor de unas 120 texturas aplicadas. Impresiona acercarse desde lejos.

(http://s19.postimg.cc/zd7kjoxoz/Car_Bonanza_v10_1.jpg)

Impresionante¡¡¡¡¡ Eso es el capitolio de ee.uu no??

Alucinante !!!

Pero... cómo va de frames y consumo de memoria?  ???

De momento, a espera de mejores indicaciones de grrr05, las texturas las he puesto a 256X256 a 24 bits.

Los frames y la memoria NI SE ENTERAN.

Ya, ya he vuelto... de hecho he estado siguiendo el hilo pero me niego a escribir desde un movil.

Bien, sobre el tema del copyright ya ha quedado claro que es una chufa. Los uploaders aceptan las licencias de google a la hora de compartir su contenido y google cambia dichas licencias cuando le da la gana.
OpenStreetMaps quería implementar algo similar al warehouse pero siendo completamente libre (al igual que el contenido que hay actualmente), pero al final no se que pasó, quedando el proyecto a dos velas.

Sobre lo de pedir autorización al autor original, mientras que podría ser una solución hay que tener en cuenta que si el contenido ha sido descargado de un servicio de google (3dwarehouse) ya se aplica la licencia de google. Otra cosa sería que el autor te diera "en mano" el modelo. Además, dependiendo de la extensión del escenario, puede ser un coñazo por la cantidad de autores. Yo no se vosotros, pero si logro automatizar completamente esto voy a crearme un escenario por la zona de donde vuelo habitualmente, y los objetos que tengo localizados se pueden contar por miles, sólo con ver colecciones enteras ya me da un patatús, y lo que no esté incluido en colecciones pues a tirar de buscador por modelos...

DIY sería la idea, al igual que el OSM2XP, G2XPL, WMS2POL, etc... Herramientas sencillas que te generan un escenario a partir de contenido descargable, libre o protegido, con una mínima intervención del usuario.

De hecho, todo el contenido geo-localizado de warehouse incorpora un kml con las coordenadas y se me ocurrió que si metemos en una carpeta todos los archivos del modelo junto con el kml, separando cada modelo en subcarpetas, nombradas por ejemplo con el nombre real del modelo (ej. \USCapitol) y que el script busque en la carpeta principal todos los modelos disponibles y que él mismo genere los DSF en función del contenido y ubicando cada modelo en las coordenadas del kml. Cada modelo exportado podría guardarse en su propio subdirectorio con el mismo nombre, siendo "\Objetos\" el directorio padre. Lo digo así porqué a la hora de exportar, los objetos y sus texturas tienen nombres fijos pero con una numeración. Por ejemplo; \Custom Scenery\Escenario 3DWH\Objetos\MODELO\obj3DWH_XX.obj, textureXX*.png\

No se, son ideas que me venían ya que al estar esos días apartado de cualquier cosa que se pareciera a un ordenador con teclado (con teclas de verdad...), poco podía pensar en los métodos del script para la exportación. Sabiendo que exite este modelo mas cabroncete ya hay una base mas sólida sobre la que trabajar, para contemplar todas las posibilidades a la hora de automatizarlo todo. No tengo aún muy claro que método usar o inventar, pero el Capitolio me parece un buen campo de pruebas, y cuantos mas errores se encuentren con los modelos disponibles en warehouse, mejor. Lo de autogenerar los escenarios y el tratamiento de texturas, para lo último. En el primer caso ya me guiaré con los scripts de Cestomano para escribir los DSF (no entiendo de python... ni de ruby -porqué engañarnos- pero aún puedo distinguir las funciones dentro de un código...) y en el caso de las texturas los dos métodos (xnv o script de gimp) son igual de válidos. En lo que hay que concentrarse ahora es en automatizar o almenos facilitar la exportación de los .obj exclusivamente, dejándolo lo mas libre de errores posible.

Me esperan tardes ocupadas con eso, seguiré informando.
De todas maneras, cualquier idea sobre el método para el aislamiento de objetos es bien recibida ;)

Uuuuffffff!. Bienvenido de nuevo!  :-j- . !Vaya fin de semana largo!. Asi como solo ante el peligro ¡y sin saber!.

Y encima me encuentro con el Capitolio...


Exactamente; eso es lo primordial: reducir el trabajo y aliviar el procedimiento. Después ya vendrán las virguerías y los adornos.

Después de haber visto como funcionaba y lo rápido que lograste el WH2XPL estoy seguro que lo conseguirás rápido. De todas formas si en cualquier momento te ofuscas, ten en cuenta siempre que "la cuenta de la vieja" puede con todo. Es el punto a donde retornar.

1º Selección de textura individualizada - 2º Exclusión de todo lo demás - 3º Exportación.

Y ello, desde dentro, desde fuera o entrando y saliendo en el SU. (había por ahí un script que arrancaba el SU ejecutando un plugin desde línea de comandos). Si me fuera a servir para otras cosas, me ponía a estudiar código. Pero no manejo código desde los tiempos del Clipper 5.2 y ya ni me acuerdo...

En fin, we keep trying...

Bueno, una vez convertido el objeto a formato XP nadie tiene que saber si fue descargado o pedido en mano a su autor...  ;)

Albert, si necesitas ayuda con algún script o que haga algo, dímelo. No puedo encargarme ahora mismo de grandes proyectos pero si pequeñas cosas puntuales.  :)

Esto es el paraguas donde siempre nos podemos refugiar, y si es cierto que SU puede arrancarse y correr plugins desde línea de comandos, mejor que mejor. Pero lo que quiero intentar es que la intervención del usuario sea mínima, mas que nada por el tema de los mensajes de error que suelta durante la importación debido a la ausencia de las texturas. El módulo XPlaneExport también requiere intervención pero creo que está bajo licencia GPL así que imagino que se podría modificar y redistribuir dicho módulo (legalmente, pero siempre hablándolo antes con Marginal) para que se pase por el forro el mensaje del número de triángulos exportados correctamente y dejando los posibles mensajes de error, permitiendo procesar consecutivamente varios modelos. Una opción sería correr un script "externo", de Python por ejemplo y él que se encarge de eliminar las texturas y llame al SU con este plugin para la importación, eliminación de geometría y exportación. Una vez terminado con esto se procedería a tratar las texturas mediante un script de Gimp o Imagemagick (a no ser que SU tenga funciones de tratamiento de imágenes y se puedan llamar desde plugin) y por último la generación de DSF. Todo procesado por lotes.

En menudo freago me he metío...  :D :D

Gracias por el ofrecimiento, de momento me voy apañando con las API de Ruby, pero si desde aquí es imposible generar los escenarios en sí (sobre la generación de los dsf en formato txt y lectura de los kml - no tengo ni idea de hasta donde pueden llegar esas API) creo que Python sería ideal ya que gran parte de los usuarios de X-Plane tenemos esas librerías casi por obligación. Lo tendré en cuenta ;)

Le eché un vistazo a este plugin:

http://foro.sketchando.net/viewtopic.php?f=34&t=1326 (http://foro.sketchando.net/viewtopic.php?f=34&t=1326)

Parecía atractivo porque cogía todo el directorio de texturas y las convertia en librería de materiales para aplicarle el WH2XPL.

Lo probé con el Capitol una a una pero no exportaba los objetos individualizados y sólo exportó una textura. Lo que no acabo de entender es por qué el WH2XPL funcionaba perfectamene con el modelo anterior y éste ni lo huele. :(

Command line:


http://sketchucation.com/forums/viewtopic.php?f=180&t=30000 (http://sketchucation.com/forums/viewtopic.php?f=180&t=30000)

Debido seguramente a que cuando se elimina un material se usa el "by default", que siempre es el primero de la lista. Encontré otro plugin que se encargaba de eliminar materiales, pero mas de lo mismo, cuando hay geometría que depende de un material eliminado, el SU automáticamente le asigna el primer material de la lista y no he visto manera de poder eliminarlo de una forma efectiva, es decir que las caras queden como "Untextured" y se pueda hacer la selección correctamente.

Mañana buscaré si existe alguna manera de poder importar los modelos sin los mensajes de error y que el script manipule directamente los archivos de textura. Si lo de las texturas no consigo hacerlo con las API de Ruby, lo intentaré desde Python, y que éste arranque el SU con el -RubyStartup que ya lo he probado y parece ser que ejecuta los plugins correctamente.

Por fin he podido modificar el script para que el select by material pueda seleccionar las back-faces.

https://dl.dropboxusercontent.com/u/59143574/WH2XP.7z (https://dl.dropboxusercontent.com/u/59143574/WH2XP.7z)

Después de darle no se cuantas vueltas he visto que por alguna razón los back-faces no se pueden seleccionar estando dentro de grupos o componentes (todo lo contrario que las front-faces).
Eso ha implicado hacer que el script explote el modelo completamente antes de empezar el proceso de selección. Pero se mantienen tanto el modelo original como la copia SKP intacta, como en el script anterior.
No he tenido tiempo para probarlo con el "toro", sólo con el primer maldito, con sus texturas reescaladas con el script de gimp y con las texturas png con alpha renombradas a textureX_A.png.

Todo correcto por ahora, salvo que es conveniente eliminar los materiales sin textura (colores planos), ya que a la hora de seleccionar las back-faces al script se le va un poco la pinza, almenos con el modelo probado. No sale ningún error y la exportación es correcta, pero sale un objeto con geometría que pertenece a otros materiales y dado que el SU2XPlane le asigna una única textura, dentro de X-Plane se solaparían debido al z-trashing.

(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/3dwh2xp/Cessna_172SP_5_zps9cb00294.jpg)

Si las pruebas mas a fondo tienen éxito, lo siguiente -que intentaré- será eliminar los materiales sin textura asociada y el bucle para iterar con cada uno de los materiales.

hmmm... ¿soy el único que se acaba de enterar que el gmaps genera automáticamente escenarios con estos modelos? Hay algunos escenarios en el .org - raro que aún estén alli siendo google la fuente...

Hace tiempo que no uso el Gmaps (pero lo he usado) y no sabía que tuviera ese añadido. ¿Convierte modelos del warehouse a XP?

Estupenda noticia!. El problema de las backfaces fue un handicap importante. Todos o casi todos los modelos que he visto llevan ese gravamen.

El modelo luce en todo su esplendor, perfectamente implementado.

Lo que me preocupa en que "el toro" hace un desprecio absoluto del tema de materiales. De momento, sólo quiere texturas. No me gustaría que te agotaras buceando en el tema de los materiales y la apertura de .skps cuando, de momento, sólo obedece a la fuerza bruta del collada.

Por aquí ando yo torpemente rebuscando en rutinas ruby de manejo de ficheros y directorios, por si acaso... :(

http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-working-with-directories-and-files/ (http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-working-with-directories-and-files/)

 https://www.ruby-forum.com/topic/130295 (https://www.ruby-forum.com/topic/130295)

http://sketchucation.com/forums/viewtopic.php?f=323&t=45005 (http://sketchucation.com/forums/viewtopic.php?f=323&t=45005)

http://jalvarez.lacoctelera.net/post/2007/08/19/ruby-leer-contenido-un-directorio-y-seleccionar-un (http://jalvarez.lacoctelera.net/post/2007/08/19/ruby-leer-contenido-un-directorio-y-seleccionar-un)

No he podido resistir la tentación de verlo terminado.

267 texturas. 1 hora 40 minutos. Con un par de scripts de directorios y el resto manual. Si consiguiéramos meter el trabajo manual que queda en scripts sería de lo más fácil

Ésto es volar para hacer fotos.

(http://s19.postimg.cc/ph6hk1rwz/Car_Bonanza_v10_8.jpg)

(http://s19.postimg.cc/z5oj0xc43/Car_Bonanza_v10_15.jpg)

(http://s19.postimg.cc/7h1vtep3n/Car_Bonanza_v10_17.jpg)

Perdonad que me responda a mí mismo pero

(http://s19.postimg.cc/vd50l6wlv/Car_Bonanza_v10_21.jpg)

(http://s19.postimg.cc/86p9jif0z/Car_Bonanza_v10_9.jpg)

creo que he cargado demasiada resolución y me daba problemas de previsualización y publicación en la web y no quería dejar de poner un par de fotos más porque creo que el modelo lo merece.

(http://s19.postimg.cc/kp19mcmmr/Car_Bonanza_v10_19.jpg)

(http://s19.postimg.cc/rzs6kqdn7/Car_Bonanza_v10_10.jpg)

(http://s19.postimg.cc/7h1vtep3n/Car_Bonanza_v10_17.jpg)

Espectacular... sólo falta Franciscus y la plaza un poco abarrotá :D

Bueno a lo que íbamos, este finde he estado desaparecido y no he avanzado nada, pero hoy me ha dado por probar el Gmaps con la opción de descargar los modelos de warehouse para crear escenarios. No puedo decir nada aún puesto que estoy procesando un área relativamente pequeña en la que hay 52 objetos, pero la cosa va para largo. Si esta noche termina ya comentaré los resultados y con capturas.

Esto me ha inducido a un alto en el camino, puesto que no hay ningún problema con ejecutarlo bajo windows (desde le terminal cygwin) y esta es la única plataforma que uso.

Ahora me sabe mal por todo el esfuerzo y dolores de cabeza invertidos en esto, pero mirado desde un punto de vista objetivo, estamos reinventando la rueda.

Si es necesario, no tengo ningún problema para escribir una miniguia para hacer funcionar el gmaps bajo windows, sólo hay que descargarse el cygwin y habilitar las librerías necesarias que són bc, unzip, imagemagick, wget y openssh (creo recordar que cuando instalé cygwin hace ya tiempo lo hice con las opciones por defecto y todas estas librerías están).
Con esto instalado sólo hay que ejectuar el gmaps desde la consola con los parámetros correspondientes al área a procesar (definida en un kml desde google earth) y la carpeta destino para el escenario, mas la opcion "-bonly" para que descargue y procese los modelos de 3dwarehouse.

Viendo el funcionamiento del gmaps, procesa los modelos del mismo modo que la idea original, separando los objetos según texturas, pero sin dependencias externas (como sketchup, gimp, etc...), el gmaps lo hace todo el solito. El único soft necesario es la terminal cygwin, ni sketchup, ni gimp, ni xnv, ni ultraedit (o np++), etc...

Nada mas. Game Over.

¿Que opinas Alberto?


(http://i1048.photobucket.com/albums/s370/xgrrr05/xplane/misc/3dwh2xp/gmaps_zpsebf7926f.jpg)

Mastodóntica idea!. Eso sería el rien ne va plus en materia de escenarios!. Simplemente no haría falta nada más en el simulador en cuanto a escenarios se refiere.

No obstante no puedo evitar que me abrume al principio, ya que también es mastodóntico el volumen de datos e información a procesar y a manejar. Habría que ver ratios de zoom y las consecuentes implicaciones en espacio, memorias y frames.

Ni que decir tiene que el simple hecho de asomarse a esos abismos ya merece la pena. Aunque no sepas qué te espera en el fondo. Eso es lo principal. No dejes de tenernos puntualmente informados de esa escalada al Nirvana.

De todas formas me gustaría ultimar un poco más el proyecto que traíamos entre manos. Y necesito que me eches un pequeño cable.

El problema de la importación de texturas a procesar lo he solucionado con el siguiente script en Batch:

@echo off
setlocal ENABLEDELAYEDEXPANSION
FOR /f %%a IN ('dir /b') DO (
   CALL SET /a x = !x! +1
   if !x! == 1 (
      REM Instrucciones Basílica SaintPeter
      DEL d:\downloads_x-plane_downloads\SAINTPETER_04\SAINTPETER_04\*.* /Q
           MOVE %%a d:\downloads_x-plane_downloads\SAINTPETER_04\SAINTPETER_04\
   CALL ECHO se ha movido %%a
   )
)

(Tengo que perfeccionarlo un poco para que opere desde el directorio destino para no tener que tocar código con cada escenario). Convertido a EXE e implantado en la barra de tareas de windows me permite con una sola pulsación eliminar la textura procesada y colocarme en su lugar la siguiente textura a procesar sin tener que manipular directorios ni ficheros.

El problema de la exportación también solucionado gracias a una modificación de tu magnífico script WH2XPL al que suprimí la gestión de materiales dejando sólo la exportación de ficheros con el siguiente contenido:

require 'SU2XPlane.rb'

module Warehouse2XPlane

$numarchivo = 0
$primeraejecucion = true
   
   UI.menu("Plugins").add_item("EXPORTAME") do
         guardar_modelo
   end
   
   
   
# Asignación de nombre de archivo, exportación a OBJ de X-Plane
   
   def self.guardar_modelo
      
      # Genera el nombre del archivo
      nombrearchivo = 'obj_' + $numarchivo.to_s + '.skp'
      
      # Guardado y cargado del modelo para su exportación.
      model = Sketchup.active_model
      status = model.save(nombrearchivo)
      Sketchup.open_file(nombrearchivo)
      
      # Exportación a OBJ de X-Plane
      XPlaneExport()
      
      # Cada vez que se guarde el archivo se suma 1 al número del nombre del objeto exportado.
      $numarchivo = $numarchivo + 1
      

   end


#Explotar componentes y grupos

   def self.explotar
      model = Sketchup.active_model
      defs = model.definitions
      defs.each do |d|
         d.instances.each do |e|
            e.explode
         end
      end
   end
   
end


#Sketchup.send_action "showRubyPanel:"


Por tanto, solucionados los problemas de importación de texturas y exportación de objetos sólo nos queda el proceso manual del SU. Entonces, viendo las maravillas que hiciste con el anterior script ha pensado que quizá fuera más elemental y no te resultara muy tedioso terminarme el script con las siguientes elementales funciones de menú del SU antes de llegar a la exportación:

1º File -> New  (o Close o como sea a fin de limpiarnos el SU de la anterior textura procesada y que, de momento tengo que hacer con la barra de menús)

2º File-> Import (para instalar en SU la siguiente textura que ya nos tiene preparada el script Batch y que también tengo que ejecutar desde menús. No te preocupes por el error de missing textures)

3º HighLight Untextured (que ya viene implementado en SU8 y que también ejecuto desde menús)

4º Delete (o Erase o Cut o Purge untextured) para dejar el objeto listo para la exportación.

Si son instrucciones sin mayor complicación te agradecería mucho las implementaras en el plugin, lo cual dejaba el desarrollo de la idea casi finalizado y ya me encargaría yo de ensamblar ambos scripts (o al menos intentarlo) para dejar una casi ultimada herramienta de ejecución.

De todas formas, si es demasiado laborioso o complicado, no te preocupes, ya intentaremos algo...

Ya me comentas. Y, por favor, comenta el Nirvana, sea para bien o para mal...

We keep trying.

No deberían tener complicación alguna, ya que son funciones nativas de sketchup.

De todas maneras la idea de poder tratar los objetos individualmente también es atractiva, pues el gmaps se descarga todos los modelos geolocalizados que estén en el perímetro sí o sí.

Por lo pronto también se me ocurre que el batch llame al sketchup con los correspondientes argumentos para importar el modelo y correr el script.
Una vez terminada la exportación el mismo script podría cerrar el sketchup (acabo de mirar cómo) y repetir el proceso siguiendo el bucle del proceso de las texturas del batch.

Corriendo el batch con argumentos para especificar la ruta del modelo (que sería el directorio de trabajo), y que ejecute sketchup.exe  -Rubystartup "\Plugins\WH2XP.rb"  ["%path%"\model.dae] después de tratar cada textura.
Eso implicaría también decirle al batch dónde está instalado el sketchup (ya sea mediante una búsqueda automática o especificado como argumento), o hacer que el usuario lo incluya en el PATH.

Y si vamos mas lejos, incluso se podría llamar al imagemagick para tratar las texturas dentro del mismo bucle, el gmaps utiliza dicho soft para tratar las texturas así que se puede mirar dentro del código que funciones y parámetros utiliza.

Peroooo, he visto otra cosa muy interesante sobre el collada (y la manera de trabajar del gmaps). El archivo model.dae es texto plano, y dentro los meshes ya están separados por texturas, así que realmente lo que hace el sketchup es "arrejuntar" todos los meshes texturizados en un único modelo a la hora de importarlo - quizás sea un paso que nos podamos ahorrar, aunque desconozco como hace la exportación a obj. La verdad es que no he mirado nada del código del gmaps, pero ahí está, es un script de bash. Otra cosa que hace el gmaps es "transformar" los materiales que son colores planos en texturas, otra cosa de la que se encarga el imagemagick. Imagino que busca los valores RGB del material y el imagemagick "pinta" una textura nueva a partir de esos valores.

Si no lo has hecho ya descárgate el gmaps y échale un vistazo al código, se pueden sacar muchas ideas de esto, no es el mismo lenguaje pero se ven claramente las funciones y el flujo de trabajo del script.

Mañana me meto a ello ;)

Por cierto, el gmaps aún sigue bajando y convirtiendo, sólo lleva 15 modelos procesados de los 52 (la Caterdral de Sta María de Tarragona está dando guerra), pero he probado el escenario pasándolo por el xgrinder y a pesar de lo poco que lleva hecho, los resultados son muy satisfactorios. La verdad es que es muy útil para hacer las cosas rápido (y cuando digo rápido me refiero a "con el mínimo esfuerzo..." porqué es lento de narices jeje)

Exacto!. Esa es la idea. Parece que me lees el pensamiento.  Es el mismo método que utilicé en su dia para un tema de exclusiones en OSM y en otro tema de llenar el x-plane de objetos con sólo ejecutar un script mediante tratamiento masivo de los DSFs. Funcionaba bien, el único problema que tenía es que al llenar el x-plane en plan brute force, también aparecían objetos en el agua. Como X-plane sólo permite exclusiones en el agua a los forest por polígonos (o al menos así era cuando tenía entre manos esta cuestión) estuve un tiempo "e-mailando" con Ben y con Andreas Fabian (por cierto amabilísimo Andreas, no regateaba nada al dar explicaciones y consejos) a ver si me implementaban en el simulador una instrucción algo asi como "exclude_objects FROM WATER"  :D pero no pudo ser, me dijo Ben, al menos, de momento.

Daba gusto ver como saltaba el UltraEdit y corrían las lineas de código y manipulación de los DSFs mientras te fumabas un cigarro. Puse algo por aquí respecto al tema OSM

http://www.x-plane.es/modules/smf/index.php?topic=2697.30 (http://www.x-plane.es/modules/smf/index.php?topic=2697.30)

En fin, a lo que vamos:

Ya tengo terminado el script de batch. Ya se ejecuta desde el directorio destino sin más complicaciones y sin tener que tocar códiigo con cada modelo. A ver si podemos conseguir que no te dé muchas complicaciones la finalización del script de ruby en los términos que expusimos ayer y te lo paso para ver si conseguimos dar el impulso (de momento) final: el ensamblado de los dos plugins.

Otra cosa que he podido comprobar y creo que es importante: La totalidad de las texturas digamos "libres" se obtienen mediante una exportación a collada del fichero .skp. Es decir, en vez de descargarse el .zip con el modelo collada, hay que descargar el .skp y proceder a la exportación de texturas.

¿Qué tal va el proyecto mastodóntico?. Me gustaría que antes de verte zambullido totalmente en él, pudiéramos terminar el par de pasos que nos quedan para dejar ultimado este proyecto y dejarlo como recurso para el caso de que el otro, más interesante, no resultara viable por cualquier motivo.

Ok aquí tienes. Lo he hecho con un poco de prisas porque en un rato tengo que irme y hay algunos asuntos pendientes a arreglar.

-Completamente incapaz de importar el modelo... Mediante la instrucción de importación que se supone admite tanto .dae como .kmz me suelta un error de que el archivo es incorrecto... así que no está implementado. Raro porque desde la función "importar" del menú de SU, con el mismo archivo, ningún problema. Tampoco es posible importar desde línea de comandos, sólo admite archivos skp.

Tampoco se que diantres le pasa al Sketchup con el -RubyStartup, no hay forma de que arranque ningún plugin, cuando hace unos días lo hacía perfectamente ¿se habrá puesto en huelga? El único cambio respecto al SU que le he hecho al windows ha sido añadir la carpeta de SU al PATH, así que como no sea esto, ni idea de que puede estar pasando...

https://dl.dropboxusercontent.com/u/59143574/WH2XP_test.7z

Éste hace exactamente lo que me dijiste, salvo la importación claro... a ver si entre esta noche y mañana lo puedo mirar (esta semana voy un poco de culo)
Me da rabia lo de la importación ya que existe una variable que si le definimos el estado como falso no suelta ningún mensaje referente a la importación (por el tema de las texturas ausentes) pero ni idea de porqué no "lee" correctamente el model.dae...

Con el modelo importado hace la llamada al Highlight Untextured (me acabo de enterar que esto forma parte del SU2XPlane :D) y oculta la selección, la exportación es igual que en el script anterior.

Dentro del bucle principal he añadido una instrucción para que cierre el SU al acabar el proceso por si quieres hacer pruebas con el batch, la instrucción está comentada y deshabilitada, sólo tienes que quitarle el primer "#".


Sobre el gmaps... aún sigue en ello, pero no te preocupes que no requiere zambullirse en absoluto :D, sólo hay que ejecutar el comando y dejar que el ordenador vaya haciendo, lo único que hay que hacer cuando termine es volcar la carpeta resultante dentro de \Custom Scenery. Completamente automatizado (añadir las exclusiones ya es otra cosa, pero hasta que el gmaps no termine con la celda, le quedan días...) Además me he visto obligado a trasladar la producción a otro ordenador menos ruidoso y con menor gasto energético, necesita quedarse encendido 24/7 ya que quiero hacer las pruebas de rendimiento con celdas enteras, la actual cuenta sólo con 150 objetos, pero en la adyacente (Barcelona) los objetos se cuentan a miles.

Muchas gracias. El tema de selección y eliminación de untextured perfecto. En cuanto al tema de la importación, es curioso como muchas veces las cosas que parecen más fáciles son las que dan mayores problemas.

No te preocupes. No hay prisa. Ya hemos avanzado bastante en una cuestión que, al principio, parecía poco menos que imposible. Siempre existe la posibilidad de retomar el tema en el punto de ejecución semiautomática en que se halla.

Voy a seguir intentándolo aunque sé que si te ha resultado difícil, a mí me va a resultar muy difícil. Pero bueno, no hay prisa ninguna.  ;)