Hemos descubierto un fabricante que fabrica un monitor estereoscópico con polarización activa. Eso significa que las gafas son pasivas (son gafas polarizadas como las que usas para conducir el coche o como las que compras para ver películas 3D en el cine) que no pesan absolutamente nada.
La tecnología de polarización está en el propio monitor. Este tiene un filtro que cambia la polarización a toda velocidad en el propio monitor, pasando de una polarización circular horaria a anti-horaria.
Este sistema es una pasada, pues no tienes unas gafas obturando tu visión (y estropeando tu vista)
Yo he tenido muy mala suerte y no se lo he comprado al fabricante original, sino que se lo he comprado a un intermediario que a parte de estropearlo con una pegatina horrible le han incrementado la módica cantidad del 100% del precio, así que lo he comprado por 1200$ 😢 pero bueno, al menos gracias a esta compra hemos descubierto el fabricante original.
En el siguiente vídeo puedes ver mi alegría al comenzar con el unboxing y cómo descubro que me han vendido un producto rebranding.
Si lo quieres comprar y prefieres probarlo primero, ponte en contacto con nosotros y te lo prestamos.
Si has actualizado una versión de Digi3D.NET es posible que haya desaparecido del listado de archivos de dibujo al cargar archivo de referencia la opción de cargar archivos de MDTopX.
Esto es debido a que la extensión de Digi3D.NET que carga archivos MDTopX antes se instalaba en una carpeta de Windows (denominada WinSxS) y en las últimas versiones no se instala ahí, sino que se instala en Archivos de programa.
Si instalas Digi3D.NET en un equipo nuevo, se configura todo correctamente, pero si actualizas de una versión anterior en la que dicha extensión se ubicaba en WinSxS, el instalador no va a modificar la configuración que le indica a Digi3D.NET dónde localizar dicha extensión y por lo tanto las versiones modernas de Digi3D.NET van a pensar que hay que cargarla de WinSxS y ahí no van a encontrar nada.
Para solucionarlo, tan solo tenemos que cambiar la configuración que le dice a Digi3D.NET donde encontrar esa extensión en particular.
Esta es una configuración que no tiene ningún sentido añadir en el cuadro de diálogo de Configuración del programa, porque es algo de muy bajo nivel, y para hacer cambios de este tipo tenemos la opción del menú: Herramientas/Configuración avanzada…
Esto abre el un cuadro de diálogo que permite introducir una sentencia SQL para modificar el archivo de configuración de Digi3D.NET que está ubicado en la ruta c:\ProgramData\Digi3D.NET\Digi3DNET.db. Este es un archivo SQLite.
Tan sólo tenemos que introducir la siguiente sentencia en ese cuadro de diálogo y pulsar el botón Enviar:
UPDATE Ints SET Data=0 WHERE Key=(SELECT Id FROM Keys WHERE Path LIKE '%Digi21.IO.Mdt%') AND Value='WinSxS'
Y ya está solucionado: Cerramos Digi3D.NET y lo volvemos a abrir y ya podemos cargar archivos de MDTopX con la orden CARGA_F.
La semana pasada una empresa que tenía una estación fotogramétrica Delta (de la empresa ucraniana Geosystems que ahora se llaman Analytica Ltd) adquirieron una licencia de Digi3D.NET.
La idea era aprovechar al 100% el hardware que tenían (manivelas y estereóscopo).
El estereóscopo se aprovecha trivialmente, en Digi3D.NET tan solo tienes que configurar como sistema de visión estereoscópica la opción de estereóscopo tal y como puedes ver en la siguiente captura de pantalla:
y Digi3D.NET se encarga de mostrar en la ventana fotogramétrica la pantalla partida para un estereóscopo.
El problema era aprovechar las manivelas, ya que las manivelas de esa estación están conectadas a una tarjeta PCI v1.0 que se pincha directamente en la placa base del ordenador:
Esta tarjeta tiene dos problemas:
Las placas base modernas no suelen disponer de conector PCI v1.0, pero eso se puede solventar comprando un adaptador de PCI v1.0 a PCI express que puedes encontrar en Amazon por muy poco dinero.
Esta tarjeta necesita un controlador para que Windows la reconozca, y no hay controladores de 64 bits para esta tarjeta, y no puedes instalar un controlador de 32 bits en un sistema operativo de 64 bits, así que no podemos conectar esta tarjeta en el mismo equipo en el que está Digi3D.NET
La única solución que se nos ha ocurrido consiste en utilizar dos ordenadores: Hemos instalado un Windows 10 de 32 bits (porque la máquina original tenía un XP) en la máquina que tenía conectada la tarjeta y hemos creado un servicio de Windows (de 32 bits) que se ejecuta en dicho ordenador.
Este servicio lo único que hace es leer coordenadas de la tarjeta de codificadores. Cuando detecta algún movimiento de manivelas o que se ha pulsado un pedal, envía coordenadas por UDP/IP a la dirección IP y al puerto configurados al instalar el servicio.
Hemos hecho este servicio Open Source, y lo hemos alojado en el siguiente repositorio:
En ese repositorio puedes ver cómo se leen coordenadas de esa tarjeta, la lógica para convertir los pedales a un formato compatible con Digi3D.NET, cómo enviar por UDP/IP un paquete de datos y cómo crear un servicio de Windows.
Por otro lado, hemos añadido en Digi3D.NET un nuevo tipo de dispositivo de entrada (UDP/IP) en la opción del menú Herramientas/Configuración de dispositivos de entrada…
Puedes configurar tanto el puerto en el que escucha la ventana fotogramétrica coordenadas de codificadores como los tensores (para asignar velocidades o cambiar sentido de movimiento).
Puedes ver en acción el nuevo servicio y cómo recibe en tiempo real Digi3D.NET coordenadas en el siguiente vídeo:
Acabamos de publicar en la Microsoft Store la aplicación gratuita Lot Of Points 🙌
Es un visor de nubes de puntos fluido e intuitivo, que de puede controlar con el ratón o con un SpaceMouse de 3DConnexion. Muestra además imágenes esféricas en caso de que la nube de puntos las incluya.
Tan solo tienes que buscar Lot Of Points en la aplicación Microsoft Store que tienes tanto en Windows 10 como Windows 11.
Comparte esta publicación con tus clientes para que puedan cargar sus nubes de puntos.
Esta mañana nos han preguntado en el soporte técnico de Digi21 si existía alguna orden en Digi3D.NET que transformase geometrías de tipo complejo en geometrías de tipo punto.
Esta orden no existe, pero como Digi3D.NET es programable en Python, hemos creado un pequeño guion para que lo ejecuten en el panel de guiones de Python.
La versión 2024 de Digi3D.NET añade dos herramientas en el menú Topología que nos van a ayudar en escenarios en los que las topologías no pueden tener dos polígonos vecinos (con un lado común) y que tengan un centroide común.
Puedes ver estas dos herramientas en acción en el siguiente vídeo:
Hoy día 8 de enero de 2024 hemos publicado la versión 2024 de Digi3D.NET.
Esta versión viene cargada de novedades, y si eres desarrollador hay una que te va a afectar: El programa hora no es compatible con .NET Framework, sino que lo hemos portado a .NET 8.0.
Si has desarrollado alguna extensión para el programa o si has desarrollado algún programa de consola utilizando los ensamblados de Digi3D.NET, tendrás que portarlos de .NET Framework a .NET 8.0.
Para portar tus aplicaciones tan sólo tienes que instalar en Visual Studio 2022 la extensión .NET Upgrade Assistant, cargar tu proyecto y en el explorador de soluciones pulsar el botón derecho del ratón y seleccionar la opción de Upgrade. Aparecerá un asistente que migrará tanto los archivos de proyecto (actualizando paquetes NuGet, moviendo información que antes estaba en el archivo AssemblyInfo.cs al propio archivo de proyecto, etc.
Una de las diferencias más importantes entre .NET Framework y .NET es que ya no existe el Global Area Cache.
Cuando instalas en tu aplicación cualquiera de los paquetes NuGet que proporcionamos para desarrollar extensiones o aplicaciones:
Lo que instalas realmente es un Ensamblado De Referencia, es decir: un ensamblado que no tiene código ejecutable, únicamente tiene declaraciones de tipos, con sus propiedades, métodos, etc., pero sin código.
Cuando se instala una versión anterior de Digi3D.NET, el instalador almacena en el Global Area Cache los ensamblados de runtime (estos sí que tienen código) equivalentes.
Cuando ejecutas tu aplicación compilada con los ensamblados de referencia, el cargador de CLR de .NET Framework ve que tu aplicación depende de un ensamblado, por ejemplo: Digi21.DigiNG, versión 23.0.0.0, lo busca en el Global Area Cache y sabe que este está implementado por una DLL denominada Digi21.DigiNG.dll y la carga en memoria.
En Digi3D 2024 hemos seguido con la misma lógica: Los paquetes NuGet publican ensamblados de referencia y únicamente actualizamos estos paquetes NuGet cuando ha cambiado algo en la superficie pública de estos ensamblados. Si se modifica el programa por cualquier motivo (en el año 2023 hemos publicado en el canal BETA más de 140 versiones del programa) y dicha modificación no realiza ninguna modificación en la superficie pública de estos ensamblados, no es necesario actualizar los paquetes NuGet: el usuario actualiza la aplicación y tus herramientas siguen funcionando.
Pero conseguir que todo esto funcione de una forma transparente como con las versiones de .NET Framework no ha sido nada sencillo y te lo explico a continuación. Si no quieres entrar en detalles, mira el vídeo de abajo del todo y porque a partir de ahora me pondo un poquito más técnico:
.NET está pensado para que cargues en tus proyectos paquetes NuGet, que idealmente tienen o un único ensamblado de runtime o un ensamblado de referencia y múltiples ensamblados runtime (que implementan lo indicado en dicho ensamblado de referencia, como, por ejemplo, una versión específica para .NET Core 3.0, otra para .NET 5, otra para .NET 6, otra para Linux, otra para Mac, otra para Windows 10…).
Cuando el compilador se encuentra con un paquete NuGet de alguno de los dos casos indicados en el párrafo anterior (es decir que tienen al menos un ensamblado de runtime), almacena en el archivo .deps.json de la aplicación compilada una entrada denominada «runtime» en la que indica el nombre de la DLL a cargar.
El 100% de los paquetes que he visto en NuGet.org son así. Como todos tienen ensamblados de runtime, el compilador de manera automática rellena esa información en el archivo .deps.json.
Pero nuestros paquetes no tienen ensamblados de runtime, de manera que cuando se compilaba con las versiones alpha de nuestros paquetes NuGet para .NET 8.0, las aplicaciones no incluían en el archivo .deps.json información de runtime y el cargador del CLR no sabía qué DLL cargar.
Para solucionar esto, ahora todos los nuestros paquetes NuGet añaden un PostBuildEvent que modifica el archivo .deps.json de la aplicación compilada, añadiendo en caso de que no exista ya, una entrada runtime en la que se indica el nombre de la DLL que implementa el ensamblado.
Y por último: si lo que has hecho no es una extensión para Digi3D.NET sino que es una aplicación que utiliza los ensamblados publicados por Digi3D.NET, como por ejemplo el ensamblado Digi21.DigiNG.IO.BinDouble, si no copias tu programa en el mismo directorio que la aplicación principal, no se va a localizar la DLL: Digi21.DigiNG.IO.BinDouble.dll, que es la que implementa dicho ensamblado.
Para solucionar esto, podemos añadir un nodo additionalProbingPaths en el archivo .runtimeconfig.json de tu programa indicando la ruta de instalación de la aplicación principal.
Para evitar tener que hacer esto manualmente, hemos creado el paquete NuGet: Digi21.Digi3D.App que lo único que hace es añadir un PostBuildEvent que añade al archivo .runtimeconfig.json de la aplicación compilada, en el nodo additionalProbingPaths una entrada al directorio de instalación de Digi3D.NET, y con esta entrada ya sí que podemos ejecutar nuestro programa desde cualquier directorio. Tienes publicado el código de este paquete NuGet en el siguiente repositorio: https://github.com/digi21/Digi21.Digi3D.App
A continuación, un vídeo explicando todo esto de una manera sencilla:
Históricamente, al ordenar a Digi3D.NET crear una topología, la creaba con las geometrías del archivo de dibujo. No se calculaba ninguna topología con los archivos de referencia.
En Digi3D.NET 2023 podemos crear también topologías de los archivos de referencia. Gracias a esto, hemos podido crear la orden CONTROL_TOPOLOGICO_CASES que permite detectar polígonos vecinos pertenecientes a distintos archivos de dibujo, y marcar como error aquellos en los que se detecta que el centroide cambia (o su código, o sus atributos de BBDD o el texto asociado al centroide), porque en determinados escenarios es posible que sea un error.
Ej: Un polígono de en un modelo tiene un centroide de Monte Alto y el polígono de al lado, que pertenece a otro archivo de dibujo es un polígono de Monte Bajo. Quizás no sea un error, pero conviene repasarlo, porque es posible que si que lo sea.
En el siguiente vídeo puedes ver esta orden en acción:
Digi3D.NET 2023 dispone de una herramienta que te va a permitir detectar automáticamente líneas de un archivo de dibujo que continúan en otro archivo de dibujo, pero con otro código o con otros atributos de BBDD o con otros atributos de geometría.
Esto no tiene por qué ser un error, pero suele serlo. Si una línea tiene código de eje de camino y en el archivo de al lado continua como borde de camino, tiene pinta de que ha habido un error a la hora de seleccionar el código en uno de los dos archivos.
Si estamos trabajando con bases de datos, es posible que ambas líneas tengan el mismo código, pero que sus atributos de base de datos sean distintos. Si por ejemplo una línea de eje de carretera tiene el atributo «Número de carriles» con el valor 2 y en el siguiente archivo tiene 4, quizás no sea un error, pero estaría bien tener una herramienta para detectarlo.
Para solucionar todo esto, hemos desarrollado la orden: DETECTAR_ERRORES_CONTINUIDAD_LINEAS_CASES que puedes ver en acción en el vídeo de a continuación.
Blog de Digi21 