Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Задаюсь вопросом, почему все крупные разработки в России имеют префикс «Российский»? Российское 3D ядро, Российская Операционная Система…
Чтобы подчеркнуть важность события. И тут хоть какой-то креатив просматривается — «3D-ядро». В отличие от «БСЛ-110 ЧК» — большая сапёрная лопата длиной 110 см черенок крашенный. Любимое ранее занятие называть продукты и разработки аббревиатурами.
Ага, на мой вопрос о криволинейных границах ответили, но легче от этого ответа не стало.
Если пользоваться англоязычной терминологией, то гораздо понятнее и общеупотребительнее термин mesh graph: «у куба 6 квадратных граней, каждая из которых состоит из 4 отрезков, а у отрезка — по две граничных точки», то есть построение графа «геометрический объект размерности n состоит из этих геометрических объектов размерности n-1».
Я подразумевал задачи не CAD-моделирования, а т.н. high order (h/p) finite element methods. То есть моделирование физических процессов сетками, внутри каждого элемента которой приближение ищут в виде полинома высокого порядка, как правило это полиномы Лежандра, Лагранжа, Якоби. Причем важно уметь поддерживать полиномы нужного вида. Связь моделирования и расчетных методов же очевидна, какой смысл решать только одну из этих задач.
Ответ
Авторы пользуются терминологией, принятой в какой-то очень уж узкой среде. Вы бы говорили проще, вычислительная геометрия — она для всех. Кто такие геометрические элементы граничного представления? Подразумеваются двумерные грани? Или одномерные? Или вообще, границы двумерных граней? Кто такие канонические объекты? Выпуклые многогранники? И в любом случае, смешивается геометрическое место точек и аналитический способ его задать рациональной функцией (я правильно понял идею NURBS?).Поддержка трехмерных сеток (meshes) в новом движке подразумевает геометрические элементы с кривыми границами (полиномы высоких порядков)?Представление трехмерной модели в ядре основано на B-Rep (граничном представлении), где геометрическими элементами являются канонические объекты или NURBS. Полиномы высоких порядков — это один из частных случаев NURBS.
Однако когда речь идет о трехмерных сетках с криволинейными границами, то, скорее всего, имеются в виду задачи CAE. В этом случае построение выполняется по B-Rep модели специальными модулями и выходит за рамки функциональности геометрического ядра. Если в будущем будет потребность включить такие модули непосредственно в ядро, это можно будет сделать.
Если пользоваться англоязычной терминологией, то гораздо понятнее и общеупотребительнее термин mesh graph: «у куба 6 квадратных граней, каждая из которых состоит из 4 отрезков, а у отрезка — по две граничных точки», то есть построение графа «геометрический объект размерности n состоит из этих геометрических объектов размерности n-1».
Я подразумевал задачи не CAD-моделирования, а т.н. high order (h/p) finite element methods. То есть моделирование физических процессов сетками, внутри каждого элемента которой приближение ищут в виде полинома высокого порядка, как правило это полиномы Лежандра, Лагранжа, Якоби. Причем важно уметь поддерживать полиномы нужного вида. Связь моделирования и расчетных методов же очевидна, какой смысл решать только одну из этих задач.
Ответ
В этом случае построение выполняется по B-Rep модели специальными модулями и выходит за рамки функциональности геометрического ядра. Если в будущем будет потребность включить такие модули непосредственно в ядро, это можно будет сделать.честно говоря ничего не объясняет: есть ли возможность визуализации трехмерной сетки со, скажем, призмой с искривленным основанием?
Попытаюсь пояснить, основываясь на своих небольших познаниях. Как я понял, вас интересует построение сетки для конечно-элементного анализа. Я предположил по этой фразе: «high order (h/p) finite element methods». Такие расчеты выполняются в программах другого класса (CAE). В них заложены, так называемые, генераторы сеток на 3D модели, построенной в CAD системе. Или для построения сетки используется третий специализированный софт. CAD системы не используют описание модели сеткой (mesh). О чем и пишут разработчики, говоря: «В этом случае построение выполняется по B-Rep модели специальными модулями и выходит за рамки функциональности геометрического ядра.»
Например, для конечно-элементного анализа. Но может и для других методов, способных работать с неструктурированными сетками с кривыми границами. Нет, меня интересует не построение сетки, хотя и это интересно. В первую очередь меня интересует возможность визуализации готовых сеток, идеально — вместе с посчитанными данными.
Повторюсь, вы (и особенно Снытников, если вы и он — не одно лицо) используете какую-то «герметичную» терминологию из узкой среды. «Геометрическое ядро трёхмерного моделирования», в общем случае, не отсылает только к CAD, как бы специалистам по CAD этого ни хотелось. Термин «моделирование» можно понять не только как «построение промышленной модели», но и как «моделирование физических процессов». Причем мне искренне не ясно, что принципиально ограничивает в решении этих двух задач сразу, по крайней мере в построении и визуализации трехметрых моделей. При этом я не предлагаю вам писать код для расчета этих моделей (метод Галеркина, Навье-Стокс etc), это пусть подключаемые модули делают. Но задача визуализации-то одна!
Повторюсь, вы (и особенно Снытников, если вы и он — не одно лицо) используете какую-то «герметичную» терминологию из узкой среды. «Геометрическое ядро трёхмерного моделирования», в общем случае, не отсылает только к CAD, как бы специалистам по CAD этого ни хотелось. Термин «моделирование» можно понять не только как «построение промышленной модели», но и как «моделирование физических процессов». Причем мне искренне не ясно, что принципиально ограничивает в решении этих двух задач сразу, по крайней мере в построении и визуализации трехметрых моделей. При этом я не предлагаю вам писать код для расчета этих моделей (метод Галеркина, Навье-Стокс etc), это пусть подключаемые модули делают. Но задача визуализации-то одна!
ну вам же ответили, что представление 3D-объектов основано на описании их границ, о каких 3D-сетках тут можно говорить? Разве что только в рамках теории тонких оболочек… Более того, там же ответили, что визуализацией они не занимаются. С чем тут можно спорить, решительно не понимаю!
P.S. В методе Галеркина, базис конечномерного пространства, в котором ищется элемент наилучшего приближения к решению исходной задачи, не обязан порождаться какой-то там сеткой. Второе, методом Навье-Стокса, вы, наверное, называете одноименную систему дифференциальных уравнений? Если да, то какое это имеет отношение к озвученной вами проблеме визуализации? Если нет, то что за метод имеется в виду?
P.S. В методе Галеркина, базис конечномерного пространства, в котором ищется элемент наилучшего приближения к решению исходной задачи, не обязан порождаться какой-то там сеткой. Второе, методом Навье-Стокса, вы, наверное, называете одноименную систему дифференциальных уравнений? Если да, то какое это имеет отношение к озвученной вами проблеме визуализации? Если нет, то что за метод имеется в виду?
Неструктурированную 3d сетку можно задавать как коллекцию многогранников, а вместо указания их смежности описать как они получены из общих вершин, ребер и двумерных граней — прекрасно сетка таким образом задается. Погуглите «mesh graph', станет яснее. Зачем такое может быть надо — например для т.н. discontinuous Galerkin схем, там граница между элементами нужна в явном виде. Что такое теория тонких оболочек — не имею ни малейшего понятия.
Что визуализацией не занимаются, сказали не скажу, не явно и не объясняя почему. Собственно я не спорю, я пытаюсь задавать вопросы, но пока ответы выглядят как заклинания для посвященных, вы вот тоже какую-то теорию тонких оболочек упоминаете. И еще, по поводу моей мотивации к беседе — см. мой камент ниже о несовпадение подачи новости задаче, которую фактически собираются решать.
Видимо, я тоже недостаточно ясно выражаюсь. Мат. методы (галеркин, уравнение навье-стокса) тут вот к чему: когда вы спроектировали деталь, казалось бы естественно тут же запустить процесс проверки конструкции и материалов на прочность и тому подобное. Поэтому я и упоминаю мат. методы. Далее, положим вы запустили моделирование процесса деформации для определенного куска конструкции. Надо же увидеть результат? Значит, нужно решить задачу визуализации результата счета в объеме — том же самом объеме, который вы незадолго до того проектировали. Геометрия одна и та же, разве что детализация (на уровне сетки) может отличаться.
Сетка не имеет отношения к базису в методе галеркина. Не знаю, к чему вы рассуждаете о связи этих двух.
Что визуализацией не занимаются, сказали не скажу, не явно и не объясняя почему. Собственно я не спорю, я пытаюсь задавать вопросы, но пока ответы выглядят как заклинания для посвященных, вы вот тоже какую-то теорию тонких оболочек упоминаете. И еще, по поводу моей мотивации к беседе — см. мой камент ниже о несовпадение подачи новости задаче, которую фактически собираются решать.
Видимо, я тоже недостаточно ясно выражаюсь. Мат. методы (галеркин, уравнение навье-стокса) тут вот к чему: когда вы спроектировали деталь, казалось бы естественно тут же запустить процесс проверки конструкции и материалов на прочность и тому подобное. Поэтому я и упоминаю мат. методы. Далее, положим вы запустили моделирование процесса деформации для определенного куска конструкции. Надо же увидеть результат? Значит, нужно решить задачу визуализации результата счета в объеме — том же самом объеме, который вы незадолго до того проектировали. Геометрия одна и та же, разве что детализация (на уровне сетки) может отличаться.
Сетка не имеет отношения к базису в методе галеркина. Не знаю, к чему вы рассуждаете о связи этих двух.
1) К mesh-grid: что за сетка получится, если указанные многоугольники расположены только на границе области?
2) В инженерных проектах, предполагающих численное моделирование каких-либо физических процессов часто выделяются следующие основные задачи:
а) математическая модель физических процессов с теми или иными допущениями
б) численная модель — вся совокупность методик, позволяющих получить приближенное решение п. (а)
в) программная реализация п. (б) Или привлечение готового специализированного пакета.
г) если решение основано на том или ином сеточном методе (РС, МКЭ, МКО, МГ и пр.), необходимо построить эти самые сетки, обладающие нужными свойствами. Для этого сначала
д) строится 3D модель области, если у нее достаточно сложная геометрическая форма. При этом чаще всего необходима лишь информация о границах. Затем
е) программно или вручную строится нужная сетка по модели из п. д). Решается задача и, наконец,
ё) визуализация тех или иных полей в том или ином виде. При этом вовсе не обязательно в 3D.
Теперь, внимание, вопрос. С какой стати программный продукт, используемый в п. (д) должен решать задачу из п. (ё)?
2) В инженерных проектах, предполагающих численное моделирование каких-либо физических процессов часто выделяются следующие основные задачи:
а) математическая модель физических процессов с теми или иными допущениями
б) численная модель — вся совокупность методик, позволяющих получить приближенное решение п. (а)
в) программная реализация п. (б) Или привлечение готового специализированного пакета.
г) если решение основано на том или ином сеточном методе (РС, МКЭ, МКО, МГ и пр.), необходимо построить эти самые сетки, обладающие нужными свойствами. Для этого сначала
д) строится 3D модель области, если у нее достаточно сложная геометрическая форма. При этом чаще всего необходима лишь информация о границах. Затем
е) программно или вручную строится нужная сетка по модели из п. д). Решается задача и, наконец,
ё) визуализация тех или иных полей в том или ином виде. При этом вовсе не обязательно в 3D.
Теперь, внимание, вопрос. С какой стати программный продукт, используемый в п. (д) должен решать задачу из п. (ё)?
1) мы с вами похоже на разных языках разговариваем. Сетка по определению должна покрывать всю область. Возможно, на границе быть более мелкой, чем внутри, но это уже от задачи зависит. В такой ситуации описание сетки иерархией элементов разных размерностей — хорошо поставленная задача. И есть ряд продуктов для сеточного моделирования, которые область представляют именно так, как я описал.
2) со списком а)-ё) согласен (это я говорю чтоб не было недоразумений), только хотел бы дополнить: не обязательно ограничиваться сеточными методами, можно и какие-нибудь задачи на механику решать. На вопрос «с какой стати» ответ: вы мне, конечно, ничего не должны. Что характерно я от вас ничего и не требую. Исходно я задавался вопросом: «такую-то задачу решает?» На что мне был сформулирован ответ «а с какой стати должен?» Ну, не решает и ладно — ваше же дело, но можно же ж и вежливее.
Теперь, почему продукту из пункта д) было бы неплохо решить задачу из пункта ё). А потому, что это задачи связанные и разделение их на разные продукты априори выглядит как создание дополнительной бюрократической работы, наподобие переноса распечатанного документа в соседнюю комнату, чтоб там его вручную опять стали набивать. При этом: я осознаю масштаб задач и сложность/неавтоматизируемость подгонки сеток под вычислительную задачу и точность входных/выходных данных. Но все же было бы здорово не разносить эти связанные задачи в качественно разные программные среды. Ну, или по крайней мере не писать несколько различных графических движков для каждого из звеньев конструкторской разработки, под предлогом того, что каждый этап требует ПО разных классов. Чтоб не приходилось сетку, составленную одной программой конвертировать в принципиально другой формат, чтоб другая программа там что-то посчитала. Чтобы workflow разработки (в смысле — конструкторской работы) сложного продукта можно было контролировать в одной программной среде — для улучшения т.н. data provenance.
Например, я себе это вижу так: занимаемся CAD-моделированием, хотим проверить скажем, прочность стыковки вон тех трех деталей. Выгружаем эти три конкретных детали (информацию об их границах и данные о материалах) в отдельный подпроект, там занимаемся построением сеточной/whatever модели, расчетом, результат тут же визуализируем и как-то сохраняем мета-информацию «годится/не годится, прочность составляет 5 попугаев, etc» о связке этих трех деталей — в общем проекте.
На разных этапах участвовать могут разные люди, но иметь общую документацию в одном месте, с прямой привязкой к общей картинке — a priori кажется здравой идеей. Но я, конечно, не специалист по CAD-моделированию, возможно это утопия. Графический движок при этом — один. С какими угодно там подключаемыми модулями, если так удобно. Но он один. И вычислительные пакеты тоже подключаемые извне.
2) со списком а)-ё) согласен (это я говорю чтоб не было недоразумений), только хотел бы дополнить: не обязательно ограничиваться сеточными методами, можно и какие-нибудь задачи на механику решать. На вопрос «с какой стати» ответ: вы мне, конечно, ничего не должны. Что характерно я от вас ничего и не требую. Исходно я задавался вопросом: «такую-то задачу решает?» На что мне был сформулирован ответ «а с какой стати должен?» Ну, не решает и ладно — ваше же дело, но можно же ж и вежливее.
Теперь, почему продукту из пункта д) было бы неплохо решить задачу из пункта ё). А потому, что это задачи связанные и разделение их на разные продукты априори выглядит как создание дополнительной бюрократической работы, наподобие переноса распечатанного документа в соседнюю комнату, чтоб там его вручную опять стали набивать. При этом: я осознаю масштаб задач и сложность/неавтоматизируемость подгонки сеток под вычислительную задачу и точность входных/выходных данных. Но все же было бы здорово не разносить эти связанные задачи в качественно разные программные среды. Ну, или по крайней мере не писать несколько различных графических движков для каждого из звеньев конструкторской разработки, под предлогом того, что каждый этап требует ПО разных классов. Чтоб не приходилось сетку, составленную одной программой конвертировать в принципиально другой формат, чтоб другая программа там что-то посчитала. Чтобы workflow разработки (в смысле — конструкторской работы) сложного продукта можно было контролировать в одной программной среде — для улучшения т.н. data provenance.
Например, я себе это вижу так: занимаемся CAD-моделированием, хотим проверить скажем, прочность стыковки вон тех трех деталей. Выгружаем эти три конкретных детали (информацию об их границах и данные о материалах) в отдельный подпроект, там занимаемся построением сеточной/whatever модели, расчетом, результат тут же визуализируем и как-то сохраняем мета-информацию «годится/не годится, прочность составляет 5 попугаев, etc» о связке этих трех деталей — в общем проекте.
На разных этапах участвовать могут разные люди, но иметь общую документацию в одном месте, с прямой привязкой к общей картинке — a priori кажется здравой идеей. Но я, конечно, не специалист по CAD-моделированию, возможно это утопия. Графический движок при этом — один. С какими угодно там подключаемыми модулями, если так удобно. Но он один. И вычислительные пакеты тоже подключаемые извне.
В свою очередь (чтобы не было недоразумений), я никакого отношения к указанному «ядру» не имею. Собрался с духом и прочел вторую из статей, приведенных вот тут (http://habrahabr.ru/post/180455/). И на странице с «QA». Строгого описания алгоритмов там нет, но, прочитав хотя бы по диагонали вы бы не задавали вопросы про трехмерные сетки. Их там нет. Тела описываются границей (если тело не из набора канонических) и обладают свойствами «полый» и «твердый». Это если совсем уж грубо. Я вам на это уже несколько раз намекал говоря про сетку на границе и про тонкие оболочки.
И еще. Честное слово, не вижу, где я вам грубил (и в мыслях такого не было), но, если вы считаете иначе, мне искренне жаль и я извиняюсь!
И еще. Честное слово, не вижу, где я вам грубил (и в мыслях такого не было), но, если вы считаете иначе, мне искренне жаль и я извиняюсь!
Штука простая: точность численного приближения в методах, использующих граничные условия, зависят от качества приближения непрерывной границы дискретной сеткой. Ошибка приближения границы потом распространяется вглубь объема, как бы хороша ни была сетка внутри объема. Криволинейные приближения границы — относительно простой и дешевый способ резко повысить точность расчета без измельчения сетки.
Теперь, если программа моделирования не позволяет такую кривую границу задать/показать, то информация уже потерялась; и когда вы модель границы скормите разбивателю сетки, будет уже поздно. Поэтому хочется, чтоб новый программный продукт был потенциально готов справляться с такой задачей, особенно если гордо рекламируется как аж Российский и с претензией на универсальность (не «3D-ядро САПР пакета», а «3D-ядро»).
Теперь, если программа моделирования не позволяет такую кривую границу задать/показать, то информация уже потерялась; и когда вы модель границы скормите разбивателю сетки, будет уже поздно. Поэтому хочется, чтоб новый программный продукт был потенциально готов справляться с такой задачей, особенно если гордо рекламируется как аж Российский и с претензией на универсальность (не «3D-ядро САПР пакета», а «3D-ядро»).
Кажется я понял вашу позицию и вопрос. Да, действительно было бы удобнее использовать некий сквозной процесс: смоделировали деталь и в этой же программе провели расчеты. Такая возможность существует в некоторых CAD программах. Но ядро это еще не CAD программа. Это один из «кубиков», который отвечает именно за геометрическое построение 3D модели, просчет различных ограничений (перпендикулярность, параллельность и т.д.). Другой «кубик» отвечает за визуализацию и например за отрисовку сетки, о которой вы говорите. Другими словами задача визуализации вообще не входит в рамки ядра.
Судя по этому комментарию расчет и построение сетки в данный момент тоже не входит в возможности ядра.
В этом случае построение выполняется по B-Rep модели специальными модулями и выходит за рамки функциональности геометрического ядра. Если в будущем будет потребность включить такие модули непосредственно в ядро, это можно будет сделать.
Судя по этому комментарию расчет и построение сетки в данный момент тоже не входит в возможности ядра.
Причина удивления в следующем: заявляется «мы пишем универсальное 3D-ядро», но аргументируете что какая-то функциональность невозможна под предлогом «мы используем это ядро в такой-то программе». Значит, «3D-ядро» не универсально? В общем, хотелось бы исходно четких объяснений, что пишут и какую задачу решают.
Судя по размаху комментирования в этом посте, в сравнении с первым, обсуждать детали технической реализации проекта и его нужность, может значительно меньше пользователей, чем кричать о том, что опять все украли и все плохо=)
Я тоже, не компетентен на таком техническом уровне, как авторы статьи по ссылке, но со своей колокольни, могу посмотреть под другим углом — этот проект (как ГЛОНАСС, при всех его скандалах) это инвестиции в технологическую и военную инфраструктуру страны.
Это как дороги или аэропорты — их кто-то должен строить, чтобы начали работать перевозчики и транспортные компании. Все это можно построить и в частном порядке, но это все выльется в сроки 15-30 лет. Конкретная софтовая компани, и конкретное предприятие ВПК не потянет такую разработку, а нужную оболочку под себя написать и надстроить — вполне.
Я тоже, не компетентен на таком техническом уровне, как авторы статьи по ссылке, но со своей колокольни, могу посмотреть под другим углом — этот проект (как ГЛОНАСС, при всех его скандалах) это инвестиции в технологическую и военную инфраструктуру страны.
Это как дороги или аэропорты — их кто-то должен строить, чтобы начали работать перевозчики и транспортные компании. Все это можно построить и в частном порядке, но это все выльется в сроки 15-30 лет. Конкретная софтовая компани, и конкретное предприятие ВПК не потянет такую разработку, а нужную оболочку под себя написать и надстроить — вполне.
Мне не понравилось только заявление о том что исходный код скорее всего открыт не будет во избежание некого утекания технологий куда-то на запад. Ситуацию я вижу так: деньги налоплательщиков потрачены на общественно полезное дело, и каждый должен пользоваться результатом в полном объеме, в том числе и исходным кодом, а если кто за границей почитает исходники — ничего страшного, милиард долларов они на этом не заработают! А то скорее всего получится так: на деньги налоплательщиков разработано, и теперь нам же еще и продаваться будет за деньги!
Тут, я думаю, больше не боязнь за утечку. Скорее всего будет коммерческий продукт. Со свой ценой, каналами распространения и схемами поддержки и обслуживания.
На мой взгляд, поскольку деньги выделяло государство, то государственные структуры (предприятия, ВУЗы или какие-то научные сообщества) должны иметь возможность использовать это ядро без оплаты или на сильно льготный условиях.
На мой взгляд, поскольку деньги выделяло государство, то государственные структуры (предприятия, ВУЗы или какие-то научные сообщества) должны иметь возможность использовать это ядро без оплаты или на сильно льготный условиях.
Вот разработка истребителя пятого поколения, тоже ведется на гос.деньги — вы предлагаете выложить всю документацию в открытые источники? Никто ведь миллиард не заработает на сборке и продаже собранных по нашим технологиям истребителей.
Не нужно перегибать палку с открытостью, лучше дать простой и понятный механизм доступа к использованнию этого ядра.
Не нужно перегибать палку с открытостью, лучше дать простой и понятный механизм доступа к использованнию этого ядра.
Поскольку ответы в виде небольшой статьи были опубликованы на другом ресурсе и дабы не навлечь гнев НЛО
Сообщество задало вопросы на Хабре. При чем тут НЛО и ответы на собственном ресурсе, забитом банерами и маркетинговым булщитом по самое горло?
Теперь по перлам из статьи.
Геометрическое ядро не является графической программой, в его функции не входит задача визуализации модели.
Это логично, ведь графической программой в современном понимании, являются только программы для GPU, в простонародье, шейдеры и вычисления с OpenCL.
Собственно, на этом логика и заканчивается. Далее следует бред из реферата 11-классника.
Одна из многочисленных функций ядра — это тесселляция, построение полигонального сеточного представления модели, которое затем передается компоненте, ответственной за визуализацию. С точки зрения набора математических методов эти задачи имеют много общего. Поэтому неудивительно, что сторонний наблюдатель их путает.
Однако ни одна из задач, связанных конкретно с графикой (кроме упомянутой тесселяции), в рамках проекта RGK не решалась.
Перепутана ли тут тесселяция (сечение плоскости без образования пересечений и промежутков) с триангуляцией? Действительно ли считают авторы работу с матрицами и кватернионами, расчеты отсечений, пересечений, трассировки лучей и пр., не связанными с графикой? Я сомневаюсь — обычно такой код пишут люди, отдавшие треть или более своей жизни математике и CG, они понимают, что грань между САПР и визуализацией очень тонка. В нашем же случае ответи писал менджер, юниор, либо глубоко погруженный в свое дело, но отвлеченный на бумагомарание сеньор.
Далее следует загадочный бред о том, что QT выглядит именно так, как мы видели на скринах и это совсем не Wine:
Все скриншоты, которые показаны в статье, сделаны в специальном тестовом демо-приложении, сконструированном на основе геометрического ядра, библиотеки Qt и сторонней графической подсистемы (на скриншоте можно увидеть стандартный многодокументный интерфейс Qt, запущенный на Linux).
Окончательно нас «убеждает», что это Linux приложение, упомнинание, что надо правильно работать с ФС (навериное, напрямую обращаться к журалам и самим кодировать отложенную запись?):
Кроссплатформенность самого ядра (написанного на С++) обеспечивается использованием соответствующих библиотек (OpenMP и OpenCL), правильной работой с системными функциями (прежде всего – с файловой системой) и грамотным кодированием.
В целом, я за начинание, за российские (или русские) проекты с мировым именем. Но и при этом я был бы рад нормальному диалогу между разработчиками и авторами, отстаиванию своих позиций, а не «документированию обоснования распила», как мы видим сейчас.
Под конец, пару перлов, которые стоит просто записать в цитаты, но не обсуждать:
Мы – исполнители проекта и не беремся отвечать от имени заказчика – государства. Но два замечания сделать можем.
одно из очевидных решений – это создание велосипеда, автомобиля, самолета или геометрического ядра с нуля.
Наивно полагать, что существующие ядра (сложные наукоемкие программные продукты, разрабатывавшиеся в течение 15-30 лет и активно использующиеся в индустрии), могут быть легко улучшены.
Жаль не могу плюсик поставить вашему каменту.
Сообщество задало вопросы на Хабре. При чем тут НЛО и ответы на собственном ресурсе, забитом банерами и маркетинговым булщитом по самое горло?
Поскольку про НЛО написал я, то и вопрос видимо ко мне. Повторюсь, я никак не связан с разработчиками и авторами тех статей. Упомянув на хабре о разработке 3D-ядра я действительно хотел увидеть мнения других людей по этому вопросу. И надеялся, что кто-то из команды разработчиков присутствует на Хабре и сможет дать комментарии. Видимо нет.
Я отправил ссылку авторам статей и они посчитали нужным ответить, написав новую статью на собственном ресурсе, на котором они имеют возможность опубликовать ее. Я тоже считаю, что лучше было проводить дискуссию в одном месте. Но мне никто не предлагал опубликовать эксклюзив (дабы не получился копипаст) ответов на вопросы на Хабрахабр. Поэтому получилось так, как есть. Это я попытался объяснить, написав про НЛО.
Триангуляция вроде как частный случай тесселяции. Так что никакого противоречия нет.
Существенная разница в том, что триангуляция не создает новые вершины. Тесселляция для отображения может использоваться только в случае использования поверхностей второго порядка вместо первого (плоскостей). Судя по обсуждениям NURBS чуть выше, это возможно для этого движка, т.е. поддерживается не-полигональная геометрия, но качество и содержание статьи наводит на мысль, что это была опечатка или оперирование подслушанным «популярным» термином а-ля «нанотехнологии».
мы обнаружили, что читатели habrahabr.ru (с которого на обсуждаемые статьи вышло несколько тысяч человек) смогли уделить чтению 25-ти страничной технологической статьи в среднем не более 2 минут – наверняка, из-за чрезвычайной занятости в своих проектах.
Но и при этом я был бы рад нормальному диалогу между разработчиками и авторами, отстаиванию своих позиций, а не ..., как мы видим сейчас.
За 10 лет ситуация точно не изменилась к лучшему.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Российское 3D-ядро захабрено. Ответы на ваши вопросы