Перейти к публикации

Корректировка элемента построения Cproj


tALEX

Рекомендованные сообщения

Здравствуйте уважаемые.

Понадобилось мне в программном режиме покорректировать элемент постр CPROJ

Надо поменять кривые прроецирования, а остальное оставить неизменным.

Функция для этого есть известная

extern int UF_CURVE_edit_proj_curves (

tag_t proj_curve_feature,

int n_curve_refs,

tag_t * curve_refs,

int n_face_refs,

tag_t * face_refs,

UF_CURVE_proj_p_t proj_data );

И вот проблема.

Для чтения кривых и граней функции есть

это , например

--------------------------------------------

UF_CURVE_ask_proj_curve_parents (

tag_t proj_curve,

tag_t * defining_feature,

tag_t * defining_target,

tag_t * defining_curve );

---------------------------------------------

а для чтения UF_CURVE_proj_p_t proj_data таковой не обнаружмлось.

Поможите, чем можете

(Особенно niki или nut)

Ссылка на сообщение
Поделиться на других сайтах


Если заменить кривые, то можно конечно попробовать и через replace ....

Но тут есть проблемы -

1. если заменяемая кривая (или точка) используется и в других фичерах (там она тоже попытается подменится)

2. если заменяемая кривая принадлежит фиче (т/е параметризирована) - например проецировались кривые со скетча, экстракт и тд. - то это будет глюк

Ну а если надо добавить или убрать кривые в фичу (CPROJ)?

Насколько я понимаю, вопрос здесь в определении метода проецирования (и дополнительных тагов в зависимости от метода). В v15 мне надо было написать прогу, которая выдает инфу по фиче CPROJ, где главное - метод проецирования. Скоко я тогда не бился - ничо не вышло. В C на NX4 добавили новые ф-ции, типа UF_CURVE_edit_proj_curves1 и тд, но и там вопрос остался.

Может в API С++ или Jave что-то в в этом вопросе решено лучше.

Ссылка на сообщение
Поделиться на других сайтах

Инфа о проецировании кривой - это секретная ф-я UG/Open :wallbash:

А меня интересовала как раз таки информация о методах проецирования.

Но, видно, не судьба.

Как разработчики, бедные, обходятся.

фу на UG/Open

Ссылка на сообщение
Поделиться на других сайтах

Можно попробовать через "одно место" - KBE Api достучаться до параметров UF_CURVE_proj_p_t

1. Делаем adopt для через UF_KF_adopt_ug_objects для фичера CPROJ ( предварительно можно спросить не был ли этот фичер уже adopted через UF_KF_ask_fusion_object )

2. Потом спрашиваем ref chain этого объекта через UF_KF_ask_name_chain_of_instance

3. И наконец через UF_KF_ask_parameters спрашиваем параметры ( в число которых входят и данные из UF_CURVE_proj_p_t) и формируем данные для UF_CURVE_proj_p_t.

PS Выкладки чисто теоретические, сам не проверял.

Regardzzz ...

Ссылка на сообщение
Поделиться на других сайтах

2 niki

Это выше, чем высший пилотаж :(

Это чем дальше в лес, тем ...

Ну, хоть дебаггером не надо ковыряться...

Но... будем посмотреть еще и там.

Ссылка на сообщение
Поделиться на других сайтах

Дык тут проблемка не только в CPROJ.

Я вот с GRIP и API C уже с 11 версии вожусь. Можно сказать накипело.

По моему мнению API на UG уж очень сильно ( и умело ) кастрирован. Причем, по первой смотришь - елы-палы, как много разных возможностей. А когда начинаешь что-то писать, выясняется, что нужной-то ф-ции и нет, зато на одну и ту же фичу натыкано с десяток , которые разнятся версиями и иногда несущественными отличиями интерфейса. Достаточно посмотреть на ф-ции моделирования extrude, sweep, revolve. Такое впечатление, что там полный бардак и какое-то спешное затыкание заплаток и подмазывание трещин.

Зато вот для построения сплайнов ни хрена нормального нема. По крайней мере, у меня не получилось даже сымитировать интерактивное редактирование полюсов для сплайна, построенного через точки.

Я уж молчю про API на драфтинг.

Ссылка на сообщение
Поделиться на других сайтах

В принципе если так уж нужно я бы предложил восстановить метод проецирования

численно

Я думаю сложного в этом нет

Нужно иметь на входе исходную точку и спроецированную точку и поверхность

Точек можно несколько

Снять их можно с кривых при фиксированных параметрах начала или конца

По поводу функциональности UGOPEN

то видимо вся энергия разработчиков ушла на C++(UGOPENPP), Java и NET

которые все равно проигрывают UGOPEN

Ссылка на сообщение
Поделиться на других сайтах

Немного отвлекшись от CPROJ я увлекся изучением OFFSET_CURVE.

Результат также обескураживает.

Не удалось построить (параметрическую) эквидистантную кривую с offset_type = UF_CURVE_OFFSET_DISTANCE_FILLET;

В качестве одной из попыток был взят пример ufd_curve_ask_offset_dir.c из каталога UGOPEN.

И там для параметрической кривой используется offset_type = UF_CURVE_OFFSET_DISTANCE_TANGENT;

или UF_CURVE_OFFSET_DISTANCE_NO_TRIM;

При замене на UF_CURVE_OFFSET_DISTANCE_FILLET

функции UF_CURVE_create_offset_object(&offset_data,&offset_tag) и UF_CURVE_edit_offset_object(&ask_offset_data,offset_tag) выдают ошибку типа такой

*** ERROR code 1105004 at line 1096 in

ufd_curve_ask_offset_dir.c :

+++ The first parameter passed in was invalid

UF_CURVE_edit_offset_object( & Offset_data_pointer , Feat[0] );

И что делать в этом случае :wallbash:

Ваши предложения, господа

Ссылка на сообщение
Поделиться на других сайтах

2 nut888

Вручную все редактируется и работает.

Да, в том примере (ufd_curve_ask_offset_dir.c) я поменял значения эквидистант

-------------

Было

char distance_str[] = {"0.25"};

char neg_distance_str[] = {"-0.25"};

Стало

char distance_str[] = {"0.05"};

char neg_distance_str[] = {"-0.05"};

-------------

Далее я трогал только offset_type пытаясь создать параметрический элемент с offset_type = UF_CURVE_OFFSET_DISTANCE_FILLET; и

НИЧЕГО НЕ ПОЛУЧАЕТСЯ :wallbash:

Ссылка на сообщение
Поделиться на других сайтах

Если вручную Тебе это удалось построить то спроси у построенного

вручную объекта эту структуру UF_CURVE_ask_offset_parms

и распечатай ее значения

Потом сравни их с тем как Ты инициализизуешь свою структуру UF_CURVE_offset_data_s

при создании

Я обычно всегда так делаю когда у меня подобные вещи происходят

Tag объекта можно получить через debugger в UG

UGII_DISPLAY_DEBUG=1

Ссылка на сообщение
Поделиться на других сайтах

Если вручную Тебе это удалось построить то спроси у построенного

вручную объекта эту структуру UF_CURVE_ask_offset_parms

и распечатай ее значения

Потом сравни их с тем как Ты инициализизуешь свою структуру UF_CURVE_offset_data_s

при создании

Я обычно всегда так делаю когда у меня подобные вещи происходят

Tag объекта можно получить через debugger в UG

UGII_DISPLAY_DEBUG=1

Этот путь уже мною пройден (вещь то достаточно очевидная)

Но при типе скругления UF_CURVE_OFFSET_DISTANCE_FILLET

НЕ РАБОТАЕТ ни создание оффсетной кривой ни редактирование оной

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.
Примечание: вашему сообщению потребуется утверждение модератора, прежде чем оно станет доступным.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • ak762
      вот здесь попытка осмысления одного автора без имени https://author.today/reader/356024/3275441 
    • Viktor2004
      На Биглии пищалка впаяна как чип в плату кнопок с задней стороны. Так что выкусывать с платы придется
    • Orchestra2603
      @Jesse: Вот обратите внимание,как на англ. википедии пишут про разные ходовые варианты определения ПФ с разными коэффициентами     И понятно, что от этого и амплитуда тоже будет меняться...     В дискретном случае та же песня, просто роль этих кожффициентов вместо 2Pi и sqrt(2Pi) выполянют N и sqrt(N) соотвтетсвенно. Надо просто четко понимать, какой вариант используется в программе.
    • Nod801
      @andrei4ik  проверьте тут    
    • Orchestra2603
    • Fedor
      Идеи Маркса никому не удалось подтвердить практически. Чтобы они привели к успеху. Он как и многие марксисты критик, а не созидатель. :)
    • Orchestra2603
      Тут про другое речь, имхо. Это про выбор коэффициентов для прямого и обратного преобразования. Если выбрать sqrt(1/N), то мол и того и другого коэффициенты получаются одинаковыми, и, мол, красиво унитарно. Матрица обртаного  преобразования Фурье становится унитарной. но тут в выборе этих коэффициентов есть некотрая волность. Лишь бы только прямое от обратного и обртаное от прмого приводила к оригинальном усигналу. Равенство Парсеваля выполняется для как бы "среднего" значения энергии сигнала, а для среднего нужен множитель 1/N. Это из другой оперы. 
    • Jesse
      Странно. В Википедии наоборот пишут, что преобразование унитарное , т..е. сохраняет длины/энергию и соотв-но когда выполняется рав-во  Парсеваля при нормировке по 1/sqrtN. А у меня выполняется рав-во, когда нормировка идёт по 1/N. Странно..)) эт как?
    • Orchestra2603
      че-то не то, по-моему... у синуса не должно быть вещественной части. У него должны быть две палки на мнимой части: -1/2 на -20 Гц и 1/2 на 20 Гц. А вещественная вся везде равна нулю. Отсюда и модули на 1/2 на +-20 Гц. 
    • Jesse
      @Orchestra2603вещественная часть от DFT даёт единичную амплитуду , но уже при других параметрах нормировки)) А картина та же вроде получается.
×
×
  • Создать...