Han pasado 20 años desde el lanzamiento de la primera versión 3D de KOMPAS - V5.11. Durante este tiempo, nos dimos cuenta de que las necesidades de nuestros usuarios están creciendo en proporción a las capacidades de KOMPAS-3D, así como la funcionalidad de KOMPAS se está expandiendo en proporción a las necesidades de los usuarios. Solo un inconveniente: al construir la parte tecnológica durante muchos años, nos encontramos con el problema de rendimiento cuando trabajamos con proyectos grandes complejos. Ahora esta línea se ha superado, y estamos listos para decir cómo logramos acelerar KOMPAS-3D en más de 30 operaciones básicas.

La paciencia no se puede acelerar.

¿Cómo entendimos que era hora de "acelerar"?

Si hace 12 años había suficiente trabajo con ensamblajes de hasta varios miles de componentes, ahora los usuarios de KOMPAS desean realizar proyectos complejos que involucren 300,000 componentes en un ensamblaje, y algunos millones serán pocos.



La evolución de los proyectos de usuario de KOMPAS-3D: a la izquierda equipos de fresado y rotor quitanieves para los tractores K-700A, K-703MBA , a la derecha la instalación de gas de vapor PGU-410 MW . Si es difícil de ver, haga clic en la imagen.

En ServiceDesk, soporte técnico, recibimos solicitudes al estilo de "No puedo abrir mi fábrica por la mañana" y "el modelo se abrió, pero no gira".

Solo hay una conclusión: COMPAS requirió una revisión seria.

Primeros cambios

La tarea principal es aumentar el rendimiento del sistema cuando se trabaja con ensamblajes grandes. Y aumentar no en un 10-30% condicional, sino varias veces.

Para resolver estos problemas, en 2015 formamos un grupo de trabajo para acelerar KOMPAS-3D. Una especie de escuadrón de respuesta rápida de programadores, probadores y analistas.

Nuestro equipo de velocidad

AYUDA: hemos estado trabajando en la aceleración antes: estas son optimizaciones y nuevas funciones que nos permiten resolver algunos de los problemas cuando trabajamos con ensamblajes grandes. Sin embargo, las tareas no eran tan ambiciosas como lo son ahora, y el trabajo no era tan voluminoso.

¿Cómo elegiste los criterios de aceleración?

Hemos elegido 5 direcciones para la aceleración:

• renderizado (rotación, movimiento y zoom de la imagen del modelo),
• Agregar componentes a un ensamblaje grande
• apertura de montaje
• edición en asambleas,
• proyección

Al elegir estas áreas, confiamos en varias fuentes:

• experiencia propia e investigación,
• análisis de solicitudes de soporte técnico y análisis de la base de errores (en nuestras herramientas hay una etiqueta especial "rendimiento", donde se señalan los problemas críticos para el rendimiento),
• resultados de la encuesta de usuarios (los usuarios suelen completar dichos cuestionarios en los eventos de ASCON),
• poderes superiores

Aquí estamos discutiendo algo.

Junto con la formación del grupo de trabajo, creamos nuestro propio espacio de información, una base de conocimiento, escribimos todas las tareas allí, recopilamos y sistematizamos ideas en posibles áreas de aceleración. Como resultado, los requisitos comenzaron a formarse con escenarios para un trabajo posterior, gracias al cual fue posible controlar el rendimiento.

Otro axioma que adoptamos mientras trabajábamos en la versión: la productividad no puede simplemente ser tomada y mejorada, y luego olvidarse de ella. Se requería medir y registrar el estado actual, desde el cual podríamos repelernos. En ese momento, el punto de partida era la versión V16 (nuestra historia aún está en 2015), que necesitaba ser controlada por scripts de nuestros conocimientos tradicionales. El rendimiento de varios puntos clave se controlaba manualmente, pero ahora este proceso está automatizado gracias al PDI.

Anton Sidyakin, programador, jefe de equipo:

“Automatizamos los procesos gracias al sistema introducido - POI (Puntos de interés). Estas son etiquetas especiales ubicadas en el código fuente. Según ellos, al ejecutar scripts en KOMPAS-3D descritos por el lenguaje del usuario, puede obtener un informe que es comprensible no solo para el programador, sino también para los analistas con probadores y ayuda a descubrir qué hace KOMPAS-3D en un momento determinado y cuánto tiempo se gasta en él. Entonces esta información puede procesarse automáticamente y compararse con los datos de origen ".


Resultados de las pruebas automáticas de rendimiento. Por cierto, quien ha leído en este lugar ahora sabe que la losa KDPV es un símbolo de nuestro equipo acelerador. Consideran el código lento como código lento)

¿Qué modelos se usaron para la comparación?

Decidimos concentrarnos en modelos de usuarios reales que se ajustan a los criterios de "conjuntos grandes".

La base de datos de modelos de la competencia de ases de modelado 3D por computadora fue de gran beneficio.

A continuación se muestran capturas de pantalla de nuestros modelos favoritos. Por supuesto, esto no es todo y, además, estamos seguros de que los mejores modelos de los últimos años pronto se familiarizarán y KOMPAS trabajará con ellos no en el límite, sino en su modo regular de alta velocidad.

Trolebús	Unidad de gas de vapor CCP-410 MW
Caja de cambios de planta de energía marina	Instalación tecnológica al vacío

Cuando era necesario cargar el sistema aún más, además de estos modelos, también se usaba un peculiar "batiburrillo prefabricado", por ejemplo:



También utilizamos modelos sintéticos: en algunos casos, ciertos problemas son más pronunciados en ellos y son más convenientes de usar para depurar y probar.

Sobre el desarrollo y los resultados alcanzados

Dibujo

En primer lugar, intentaron acelerar el procesamiento (esto también fue solicitado por la mayoría de los usuarios que participaron en la encuesta).

La velocidad de renderizado es crítica en todos los procesos donde el modelo se posiciona o su pantalla cambia. Y esto no es solo la rotación, el movimiento o el zoom del modelo. La velocidad de representación también es importante en aquellos procesos en los que se actualiza la imagen del modelo:

• Agregar un componente a un ensamblaje
• selección de objetos básicos para compañeros (caras, aristas, etc.),
• resaltado de partes seleccionadas del modelo (componentes, caras),
• cambiar la visibilidad de los objetos (ocultar / mostrar el componente).

Y estos están lejos de todos los casos en los que se utiliza el subsistema de visualización. Por lo tanto, está claro por qué la aceleración de procesamiento se ha convertido en una prioridad para nosotros.

Al mismo tiempo, era importante no solo utilizar las capacidades de las tarjetas de video modernas productivas, sino también no olvidar a aquellos que usan hardware no tan fuerte y moderno.

El resultado del trabajo fue la implementación de dos opciones de renderizado:

• Básico: habilita las extensiones Open GL 2.0. Menos exigente en el rendimiento de la tarjeta de video. Da buena aceleración de renderizado,
• "Mejorado": utiliza las extensiones modernas de OpenGL 4.5. Exigiendo las características de la tarjeta de video. Da máxima aceleración de renderizado en mapas modernos

Yuri Korchagin, programador:

“En el problema del rendimiento de mostrar escenas grandes, está claro que se gastan muchos recursos en recorrer la escena y calcular los parámetros con los que se debe mostrar la primitiva.

Otro problema está asociado con una gran cantidad de llamadas de extracción (llamadas a la API de OpenGL, que conducen a la salida de la geometría al búfer de trama).

El estado inicial también asumió la transferencia de todos los datos a la tarjeta de video desde la RAM. Y estos son millones de triángulos en el caso de una gran asamblea.

Las correcciones cosméticas no se podían prescindir aquí, ya que se requería un aumento múltiple en la productividad. Por lo tanto, se decidió reescribir en gran medida el módulo de visualización.

El primer paso fue utilizar la memoria de video para almacenar en caché los datos de dibujo (triangulación, estructura alámbrica, caras). Al trasladar estos datos a la GPU, logramos un aumento de 2-3 veces en FPS.

Esto fue seguido por la creación de un modelo de datos adaptado para visualización. Es decir, nos deshicimos de las solicitudes de un modelo 3D, que puede requerir muchos recursos, lo que también dio un efecto positivo.

El siguiente paso fue estudiar la calidad y el volumen de la triangulación. A menudo, se mostraban pequeños detalles con una precisión excesiva, y viceversa: en ciertas situaciones, en lugar de superficies lisas, el usuario vio un modelo "cortado" en la pantalla.

Decidimos usar varios niveles de detalle y aplicar la aproximación de primitivas teniendo en cuenta la desviación angular. De esta manera, se mataron dos pájaros de un tiro: mejoraron la calidad y eliminaron la carga excesiva en la GPU ".

Yuri Korchagin, programador:

“Bueno, mostrar el modelo se ha vuelto más rápido, pero no tanto como nos gustaría. En esta etapa, nos dimos cuenta de que no podíamos sacar más provecho de este enfoque.

Por otro lado, el uso de los últimos enfoques requerirá las tarjetas de video más actualizadas, lo que contradice los requisitos de compatibilidad y a algunos usuarios claramente no les gustará. Por lo tanto, las mejoras descritas anteriormente están disponibles como una opción de representación "Básica".

Y entonces comenzó la diversión ... "

En la siguiente parte, continuamos nuestra historia sobre el renderizado, y también mostramos los resultados de medir la velocidad de renderizado durante la rotación del ensamblaje, los cálculos de MTC, agregar componentes al ensamblaje y contar sobre la apariencia de un tipo de carga parcial.

Y para el postre, le dejaron un video para que compare la velocidad de renderizado durante la rotación, el escalado y el cambio del reductor de una planta de energía marina.



El final de la primera parte. Continuará