Перейти к содержанию

Lion007

Клуб разработчиков
  • Публикаций

    599
  • Зарегистрирован

  • Посещение

  • Победитель дней

    74

Lion007 стал победителем дня 26 декабря 2019

Lion007 имел наиболее популярный контент!

Репутация

367 Очень хороший

1 Подписчик

Информация о Lion007

  • Звание
    Разработчик nanoCAD

Информация

  • Пол
    Мужчина

Посетители профиля

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

  1. ну так я про это и говорю - на каждом шаге оно уменьшается на те самые 5%... а пример я просил, опасаясь того, что оно с первого раза в бесконечность улетит меня, честно говоря, больше ситуация 2 напрягает... видимо, базовую точку все-таки придется воткнуть - и хрен с ними с эффектами...
  2. пример в студию! потому что по моим наблюдениям, да и исходя из логики кода, работает оно совсем не так - в экран вписывается видимая часть икслайна. более того, если его в данный момент совсем не видно (ну уехал за экран, бывает) - то он как бы и не участвует в процессе. - рисуем кружочек - в сторонке рисуем xline - давим alt-0 наблюдаем постепенное уменьшение картинки (при зум-олл, насколько помню 5% свободного места по краям остается) - теперь сдвигаем картинку так, чтобы наш xline уехал за экран. - опять давим alt-0 наблюдаем зум к кружочку все это, безусловно, не особо радует, но трагедией, имхо не является. включить в рассмотрение базовые точки - идея, в общем-то , вполне здравая, формально правильная и даже легко реализуемая - но тут есть свои побочные эффекты... это я не к тому, что сейчас все сделано на "вау!" - просто вопрос вовсе не такой очевидный, как может показаться на первый взгляд. но и до него руки дойдут, не знаю как кого - а меня он уже не первый год раздражает
  3. XLINE и RAY - это проблема старая и известная. если не вдаваться глубоко в детали, то заключается она примерно в следующем : что считать экстентсами бесконечного объекта? вариантов, по большому счету, два, и оба так себе варианты, кривоватые - либо видимую часть, либо точки определения того самого xline. побочные эффекты имеют оба, какой вариант лучше - вопрос спорный. по большому счету, кмк, важность проблемы на самом деле минимальная, приближенная к никакой. переделывать, вероятно, будем - но по остаточному принципу, вот честное слово, есть задачи поважнее!
  4. АС1032 - это формат АС2018. как нетрудно догадаться, появился он в 2018 году. антикварный 5.1 его не читает (и не может) в принципе. чтобы работало - надо пересохранить в один из поддерживаемых 5.1 форматов - скорее всего подойдет 2013, но это лучше глянуть в самом 5.1 (в диалоге Save As развернуть список форматов и глянуть, что он поддерживает).
  5. UCS (она же ПСК), и выбрать опцию "world" ("мир") - или просто нажать на ввод. поставится исходная мировая система координат.
  6. в совсем старых - может и нет, но, по идее, сделано давно. тут, скорее, другой хитрый вопрос - а не имелась ли в виду не яркость (оно и раньше работало) а прозрачность? и вот тут начинается цирк с конями... не все принтеры поддерживают прозрачность вообще. причем узнать это снаружи - мягко говоря проблематично. то есть ты ему "вот тебе прозрачный квадратик!" - а он тихонько бурчит себе в картридж "хрен, тебе, а не прозрачный! радуйся, что вообще нарисую!"... но, допустим, XPS - поддерживает. тут выясняется, что код печати растров (наш) - ту самую прозрачность сам по себе тихонечко игнорирует... но это ладно, все равно он сейчас в переделке (потому что, например, тот же самый XPS фигово работает с большими растрами) - глядишь и прозрачность протащим. но на принтерах, которые ее не поддерживают - все равно радости будет мало. при этом, когда вывод идет на бумагу - все равно можно выкрутиться - сформировать уже готовую картинку (с учетом всей клюквы) - и отправить ее на печать именно как картинку. но при выводе в файловые форматы это далеко не всегда подходит. в том же PDF, например, народ хочет еще и тексты искать, а какие тексты, если оно все картинкой? собственно, в режимах, которые "не вайрфрэйм" - оно так и работает - печатается именно картинка, никаких векторов, и это можно использовать, когда возникают траблы с прозрачностью. такая вот хистория...
  7. воля ваша, коллеги, но что-то вы неправильно делате... или я неправильно что-то делаю... вставил растр. размножил его 5х5 штук - для наглядности. по строкам - фэйд с шагом 20. по столбцам - яркость с шагом 10. распечатал (XPS и PDF) получается примерно вот так : ну и до кучи... rasters.dwg rasters.pdf rasters.xps
  8. а растр какой? RGB, монохром или еще какой? а лучше всего - пример в студию!
  9. да пожалуйста, мне не жалко, для того и писалось! я рад, что хоть кто-то оценил... а чтобы было не так смешно - немного оффтопиковой философии поэты - обижаются, когда им говорят, что они складывают стихи. художники - обижаются, когда говорят, что они рисуют картины музыканты - ну, они как первые и вторые... я - смеюсь, когда говорят, что программисты составляют программы. на самом деле - все пишут... каждый свое. а если ты можешь написать что-то действительно свое - то сочинить пост на форуме - право, не фокус! а по вопросу.... в разработчики меня занесло по жизни. первую ошибку у отца в программе (согласно семейной легенде) я исправил примерно года в 3.5... беда в том, что я отлично помню этот момент, равно как свои 38.5 в этот момент - болел, однако... в общем, можно с полным правом считать это понтами - но я программер от бога. не то, чтобы это меня ставило выше прочих - нет, это просто талант... как музыкальный слух или способности к гимнастике. остальное - ручками... но это я уже выпендриваюсь... зы : про скучных программистов - это придумали не те люди, к которым лично я рекомендовал бы прислушиваться. программировать просто, интересно и весело!
  10. рассказываю физику процесса... невидимая карточка компутера умеет рисовать точки, линии и треугольнички. механизм растеризации (т.е выбор, какие пиксели на экранчике нарисовать, а какие нет) для каждого типа примитивов свой. если несколько упростить... ну, точка, понятно, просто рисует пиксель, в который попала (пиксель это все-таки квадратик). линия - те пиксели, центры которых лежат к ней ближе всего. а треугольничек - те пиксели, центры которых попали в этот треугольник. из этого следует несколько выводов : 1) точка рисуется всегда (ну, если попала в экран, ясное дело) 2) линия может пропускать пиксели, в которые (как в квадратики) попадают ее концы. звучит глупо, но это на самом деле правильно - иначе если мы нарисуем две линии с общей вершиной, пиксель эту общую вершину содержащий, нарисуется дважды, а это уже глубоко неправильно. 3) треугольник вообще выбирает пиксели как повезет, и это, как ни странно, тоже правильно - по той же причине (чтобы 2 треугольника с общим ребром не рисовали его дважды). далее, из пунктов 2 и 3 следует, что - линия длиной меньше пикселя имеет полное право не нарисоваться вообще - треугольничек размером меньше пикселя имеет полное право не нарисоваться вообще - узенький треугольник имеет право не рисоваться вообще, либо нарисоваться в виде цепочки разрозненных пикселей, не образующих непрерывную фигуру это была преамбула, а теперь будет амбула... буква TTF - это набор сплайновых контуров, внутренность которых надо закрасить. как это рисовалось? а очень просто - эта самая внутренность билась на треугольнички (точность, кстати, регулируется параметром TEXTQUALITY), и дальше эти самые труегольнички и отрисовывались. но, как мы уже выяснили, треугольнички могут нарисоваться как угодно - и тонкие элементы букв (состоящие, естественно, из маленьких-узеньких треугольничков) запросто превращались в отдельные точечки, букву никоим образом не образующие. тут надо заметить, что антиалиасинг эту проблему отчасти маскировал (поскольку там получался меньший эффективный размер пикселя) - но именно отчасти. с антиалиасингом тоже могло все развалиться... чтобы-таки получилась буква - по контуру всего этого безобразия рисовалась обводка линиями. но линии-то растеризуются иначе! из-за чего и получалось "жЫрно"... так что при такой механике были ровно те два варианта, которые я уже описывал - либо жирно, либо фрагменты букв пропадали (если без обводки). добавляем сюда необходимость масштабирования буквов в невменяемых пределах и получаем полную задницу... в результате пришлось знатно поизвращаться, чтобы всего этого избежать - а руки до этих извращений у меня дошли только сейчас. но поизвращался - сделал. такая вот хистория...
  11. не было в 10-ке нормально. было в разное время два варианта и оба не фонтан - либо с обводкой по контуру (тогда получается жирно) либо без (тогда тонкие элементы букв пропадали). пришлось извращаться - но получилось, в результате, вроде неплохо...
  12. в 11 - нету. а вот для следующей версии уже переделали, так что там все должно быть путем.
  13. тут есть нюанс... я, признаться, не поклонник динамического ввода - но я ретроград известный... так вот - все работает.... просто для этого надо вводить что-то не в динамический размер, а в командную строку. надо будет, конечно, об этом подумать - но с общем случае задачка как минимум нетривиальная - отличить ввод конкретного поля (дин. размера) от общекомандного кейворда. но подумаем... а так - все правильно, сокращения подсвечены в списке кейвордов заглавными буквами. ну, или на гиперссылочки в комстроке тыкать.
  14. друзья, а вам не кажется, что мы несколько отклонились от темы? ну, по крайней мере - от темы "с какого перепуга при попытке повернуть UCS вокруг X зовется эксплод, а вокруг Z- зум. надеюсь, я достаточно рассказал о технических деталях - что как происходит, почему оно происходит именно так и зачем это надо. возвращаясь к первоисточнику холивара... да без проблем - фигня война, накатать три отдельные команды - ну, (условно) типа UCS_ROTATE_X, ну и _Y _Z соответственно. на все про все - полчаса. тем более, что в кишках - это все равно упрется ровно в один и тот же код.... вроде бы - первоначальная проблема решена - ну, формально-то по описанию не повторяется! не, ну правда же! команда UCS_ROTATE_X заблокирована в блокэдите, и все путем... но есть нюанс. следующим ходом будет то, что кто-то воткнет в меню команду установки "среднепотолочно-удобной" системы координат. не сам придумал - отец научил - если надо посмотреть на модель вообще, то углы разворота (физический смысл - очень похоже на углы эйлера) - 17, 35, 7. это в градусах. это не абсолют - это именно среднепотолочноудобно. не понравится - доверни... но речь не о том. вот есть юзверь... ему надо что-то типа макроса - поверни мне UCS вот так. он знает, как работает (обычно) команда UCS. он честно пишет - где-то там, в кастомизаторе - что-то вроде UCS X 17 UCS Y 35 UCS Z 7 <и пробел>... и эта фигня ему 3 раза позовет команду UCS и сделает то, что он хотел. а можно просто из текстового редактора это скопипастить в комманд-лайн. это УДОБНО. - мы просто суем готовый кусок ввода. я не знаю как еще объяснить... ну удобно это! ясно даже и ежу (С) что если мы этот готовый кусок ввода воткнем невовремя - то нифига хорошего из этого не выйдет. насколько нифига - это как повезет... собственно, такой подход с одной стороны весьма гибок, а с другой - предполагает нечто вроде соглашения "добросовестного покупателя". то есть ты можешь в тот самый комманд-лайн швырять что угодно - но за контекст отвечаешь сам. равно как и за то, что нашвырял. и, опять-таки, возвращаясь к первоисточнику - возможно, я ошибусь, но исходный вопрос должен был ставиться не как "а фигли взлетает зум" - это я объяснил, и это (поверьте!) фигня... вопрос должен был стоять иначе - "фигли вы запретили менять UCS в блок-эдиторе?". вот на этот вопрос у меня ответа нет, кроме как "собезъянничали с АС" - и меня это тоже глубоко возмущает... а если у меня в блоке глубокое 3д, и мне без смены UCS грустно? в общем, не трогайте наш комманд-лайн, он не идеальный, но хороший... а вот как команды запрещали - это вопрос отдельный...
×
×
  • Создать...