JasW

Użytkownik forum
  • Postów

    90
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    7

Odpowiedzi opublikowane przez JasW

  1. > Na ile można zaufać tym ustawieniom ZwCAD?

    1. Oszacowanie wysokości i azymutu słońca to zagadnienie astronomiczne  . 

    Można je wyliczyć dokładnie np na stronie  http://astronomia.zagan.pl/pliki/pozycja_slonca.html   wprowadzając współrzędne geogr. i czas. 
    Dla zadanej pozycji wyszło : 

           w dniu 6 grudnia 2019 o godz 12:00azymut : 184.13 deg  wysokość  16:36 deg    ( screen ) . 

    2. A teraz propozycja jak zweryfikować algorytmu w ZwCAD  :
    a) do rysunku proponuję dodać pionową kolumnę o znanej wysokości np. 10 m  - tworzącą  zegar słoneczny.
    b) na poziomie ziemii dodać jeszcze grid o odp. dobranym rastrze np. 1m  .

    Teraz długość i  kąt rzucanego cienia względem północy  pozwolą odtworzyć kąty algorytmu Zwcada  . 

    Jeśli kolega poda wyniki na forum to wszyscy będziemy wiedzieć czy ufać algorytmowi ZwCAD  ;-)  

    Mikołajkowe pozdrowienia,

    J.

    PS: Gdyby ktoś chciał wstukać odp. formuły np do do smath to na stronie  https://gegra.jimdo.com/strona-g%C5%82%C3%B3wna/geografa-fizyczna/wysoko%C5%9B%C4%87-g%C3%B3rowania-s%C5%82o%C5%84ca/  są odp. formuły .
     

    Kalkulator_Azymut_i_wysokosc_slonca.jpg

  2. Dzień  dobry,

    Grupy są bardzo użyteczne ale mają kilka ograniczeń. Nnie ma poza tym mechanizmów w utrzymywaniu ich spójności między projektami.

    Jednak tam gdzie kończą się możliwości grup lepiej używac bloków: 

    > Jeśli chodzi o kopiowanie to tak przypuszczałem, że to bardziej skomplikowane...

    Np sekwencja :

    BLOCK ( tworzymy ) 
    WBLOCK ( zapis na dysk )
    INSERT ( ładujemy z pliku w drugim projekcie ) .
    Do wyboru pozostanie jako blok lub po EXPLODE utworzenie grupy

    Pozdrowienia

    J.

  3. Można wykorzystać skróty Windows (zwane bardziej elegancko jako tzw linki symboliczne ) .  

    W praktyce tworzymy w katalogu projektu skrót prowadzący  ( nie do pulpitu a )  do podkatalogu naszej biblioteki 

    Jesli np. trzymamy zbiór obrazów i innych w katalogu  c:\biblioteka\* 

    A projekt utworzymy w katlaogu d:\Projekty\  

    to powinnismy w nim utworzyć skrót o nazwienp.  'biblioteka'  prowadzacy do katalogu c:biblioteka\ 

    przy załączaniu z opcja relative będzie pamiętana ściezka względna . 

    O linkach symbolicznych i jak się je robi google napewno pomoże (mi wyskoczyło pierwsze lepsze tu : https://leniwy.eu/news,10,Linki-symboliczne-w-Windowsie.htmlJ.

    J.

     

  4. Dzikuję za szybką reakcję. 

    Uprzejmie informuję że zadziałało  😉

    BTW: Czy  to wersja tylko pod  ZWCAD 2018 Architecture  czy może jest bardziej uniwersalna i obsłuży też 2018 Zwykly i Mechanical ) ew szerzej można liczyć na kompatybilność z  ZWCAD 2019 ?.

    O  Właśnie równocześnie pojawiła się odp.  Kolegi Martina_S 😉  dzięki.

    Choć pewna  wątpliwość pozostała:  Czy kompilacja *.zelx jest zależna od wariantu horyzontalno-wertykalnego ZWCAD ? 

    Pozdrawiam, 

    J.

     

  5. Fajny skrypt ten PowerDraw_2018  zacząłem eksperymentowac z racji potrzeby pracy na poliliniach i slabej obsługi ich modyfikacji w czystym ZWCAD 2018 . mam niestety zonk . 

    Po klku dniach  skrypt przestał się uruchamiać generując tylko niewiele mówiący "internal error" .

    To samo po załadowaniu zwykłym jak i w Startup Suite: 

    Command: _appload
    D:\Projekty\Zwcad2018\Toolbar\PowerDraw_2018.zelx load successfully!
    Command:
    Error: internal error

    Zaobserwowane na Zwcad Architecture 2018  wersja  2017.12.19 (25174) 32 bit

     

    Czy da się to jakoś zdebugowac problem. Bardzo proszę o jaką sugestię nie sprowadzaiącą się do pełnej reinstaklscji ZWCAD czy Windowsa 😉 

    Może coś jest w jakimś logu ?

    Pozdrawiam

  6. @Chris:,
    1. Może  wrzucisz  jakis prosty DWG  + screenshot w którym pokażesz złe przesłanianie. 
    2.  Może jako rozwiązanie  wystarczy właśnie 'trik'  jaki podałem w pierwszym moim poście. Dla złośliwych obiektów ustawienie Elevation lub ('z') dla obietów  =-1 albo +1
         To działa dla obiektów mających powierzchnie (np. 3d Face) , ale dla drutowych LINE/POLYLINE także powinno działać. Jeśli nie zadziała to dla mnie ewidentny BUG do załatania w ZWSOFT. 
    Uwaga:  Ważne: Do testów Użyj Shade mode innych niż wireframe  2D/3D. W trybach wireframe zapewne nie działa wspomaganie rozstrzygania o kolejności przez  z-bufor ).
     
    Używając Orbit lub rzutów innych niż TOP  będziesz widział i mógł wizualnie kontrolować co jest na górze co jest na dole. Prawdopodobnie nawet bez dotykania DRAWORDER. 
    Pozdrawiam,

    J.

  7. @Kojacku .

    1b) No cóż może fakty do kolegi przemowią? :
       DRAWORDER  niestety MA jednak wpływających na pracę w 3D.  Kolega zapewne chciał napisać , że nie powinien mieć....

      Wystarczy  popracować trochę w  Zwcad/Autocad z większym projektem 3D . DRAWORDER ma wpływ i to zły
      Selekcja obiektu 3D po użyciu ORBIT wykorzystuje niestety DRAWORDER co jest bez sensu.. Prowadzi to do oczywistych problemów i co do zasady jest niedoróbką np. w ZWCAD 2018 do dziś)  bo klikając na widoku z lewej strony możemy zamiast lewej ściany dostać w selekcji obiekt zasłonięty prawej ściany ....
    Używanie SHIFT+SPACEBAR przy skomplikowanych scenach także czesto niewiele wnosi.

    To jest właśnie scheda w pracy w 3D wynikający z orientacji pod pracę 2D.
    Jak powinno być? - w pierwszej kolejności selekcja wg kolejności wg bufora głębokości (z-order) bieżącego widoku. To oczywiste dla każdej aplikacji zorientowanej głownie na pracę w 3D ( Inventor/SolidEdge etc )  lub osoby która pisze aplikacje pod DirectX czy OpenGL.

    2,3)
    > Proszę o zapoznanie się ze strukturą danych obiektów LWPOLYLINE i POLYLINE. 

      Ciekawe, tak się składa, że znam te komendy nie tylko jako użytkownik ale także jako programista (z poziomu API). Znam także możliwości kolejnych 20..30 obiektów .
      To pozwala mi wypowiadać się co do schedy i historii Autocad (API  od 2002 do dziś) .  
      Dlatego też dziwię się trochę koledze dlaczego  zapomniał o dodaniu  do obiektywnego  porównania - trzecim typie polilinii :  "3D POLYLINE"  .   
       Jest w nim lista verteksów x/y/z:3D  a nie jak w POLYLINE i LWPOLYLINE lista verteksow 2D + Elevation.
       Czy 3dPOLYLINE  było w wersji 2.1 ?  - NIE! 
       To dla mnie oczywisty przykład ewolucji i optymalizacji ( używanie zwykłych  POLYLINE 2D do projektów 3D ma znaczne ograniczenia) 
     
    4) Kolego,  nie wiem w czym ci uchybiłem, może jakąś świętość Twoją obraziłem.ale...używanie fraz typu: nieporozumienie, bzdura, kula w płot to mało elegancka metoda dyskusji zakładająca, że jesteś alfą i omegą....    Gdy kogoś nie rozumiemy nie oznacza to jeszcze, że ten ktoś nie może mieć racji.... 

       Czy kolega zastanowił się co mam na myśli używając pojęcia z-bufora ?
        Jeśli nie,  to w rewanżu  proponuję zapoznanie/przypomnienie sobie  dwóch algorytmów określania widoczności w grafice 3D :
         a) współczesnej - sprzętowej opartej o  'z' bufor głębokości.
         b) historycznej - programowej opartej o algorytmy linii/płaszczyzny zasłoniętej'   ( gdy karty grafiki ni emiały akceleratorów 3D) 

        Zaręczam, to pozwala zrozumieć większość  moich sugestii i refleksji  dot. ewolucji rozwiązań 3D w kernelu AutoCAD .
         Także nadal podtrzymuję za pozyteczny  przykład CSS z parametrem  "z-index"   . 

    Na koniec może trochę nieskromnie  dodam:

    Grafiką 2D, 3D,  systemami CAD/CAE zajmuję się chyba już 35 lat,
    pozwala mi to wyrobić sobie pewne pojecie co do możliwości i ograniczeń takich narzędzia jak Autocad, ZwCAD oraz ich interfejsy API.
    W tym wątku w tematach innych niż pierwszy post Chrisa nie będę się już wypowiadał bo wątek meandruje za bardzo w kierunku Offtopic.

    Pozdrawiam,
    J.



     

  8. @kojacek: może trochę elastyczności w interpretacji wypowiedzi innych bo  nie rozumiem dlaczego dyskredytujesz  akapit w/g mnie jednak niesprzeczny z historią wchodzenia Autocad w 3D:
    a) Jednak do wersji Autocad 2.0 nie było obsługi 3D (to ważne bo wiele koncepcji Autocad z lat 1982..1985 przetrwało do dziś )  
    b) Od wersji 2.1 była ale to właśnie dotyczy spójnika  "...LUB (ew. lub w sposób naciagany) "
       To akcentuję bo to 3d wdrażano drobnymi krokami i to ciązy także do dziś.
        Widać po specyfice poleceń np. Polyline ( jest parametr Elevation ale to nie to samo co 'z' )

    Kiedy pojawiały sie polecenia i opcje dot. 3D mozna domniemać np. tu
    ( http://autodesk.blogs.com/between_the_lines/autocad-release-history.html )  


    @Chris:
    Nie mam zamiaru dyskutować o historii,  interesujący wydał mi się bardziej główny wątek dlatego zabrałem głos:
    Myślę że dla merytorycznej dyskusji ważniejsza jest tu zmienna DRAWORDERCTL.

    Moja propozycja obejścia problemów w 2D (OXY) dotyczy spróbowania używania współrzędnej 'z' do rozstrzygania kolejności tam gdzie DRAWORDER 'wymiękł'
    Co więcej to nic oryginalnego została ona zastosowana w innych typach proramow np. DTP : i HTML ( arkusze stylów CSS) np: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/Stacking_context_example_1

     

  9. Zasadniczo zgadzam się z @kojacek , dlatego choć nie pracuję w 2D ( łownie 3D które ma trochę inne problemy z przesłanianiem widoczności ) proponuję spróbować inne rozwiązanie : 

     Wejść 'minimalnie w 3D'  tzn. nadawać współrzędne 'z'  obiektów  zależnie od potrzeby widoczności  ( Z> 0  pierwszoplanowym) ( tło , Z< 0 tłu ). 
    Powstanie coś w stylu warstw opartych właśnie o  współrzedną 'z' .

    Zwykłym ORBIT możesz sprawdzić, który jest wyżej / niżej jednym rzutem oka. W blokach także to można zrobić.
    Potem w widoku Top View zasłanianie powinno być prawidłowe. 

    DRAWORDER i wiele funkcji właściwie wywodzi się z próby rozwiązania problemu kolejności rysowania obiektów w czasach gdzie ACAD'a nie mógł w ogole (ew. lub w sposób naciagany)  pracować w 3D tzn. obiekty miały tylko współrzedne X,Y ew. odległośc od plany OXY.

    PS1: Niezależnie od tego czy to da efekty , proponuje poczytać w helpie o ustawieniach zmiennych DRAWORDERCTL , SORTENTS  i samym DRAWORDER.

    Ja czasami mam problem odwrotny - z selekcjami w 3D - czasami najpierw łapie obiekt dalszy. Mimo eksperymentów z powyższymi zmiennymi zawsze z duzymi modelami był jakiś problem.

    W 'czystych aplikacjach 3D nie ma takiego problemu.

    Dla mnie w ZWCAD przy pracy w 3D powinna być przy selekcjach możliwość całkowitej dezaktywacji wpływu DRAWORDERCTL , SORTENTS  i powinien działać wyłącznie algorytm oparty o bufor głębokosci 'z' w lokalnym układzie współrzędnych  (tak to rozwiązują akceleratory w kartach graficznych 3D aby poprawne wyświetlanie złożone sceny z np. 100K  elementów .

    J.
     

  10. Raczej przebudowują oprogramowanie forum i im się linki pozmieniały .

    W menu nawigacyjnym  mają chyba niezaktualizowany link 

    fora mają nowy adres: https://www.zwsoft.com/forum/forum.php  
    Wątek dot. Zwcad Architecture  , któremu także kibicuję 😉 nadal żyje. Widać go  tu:  https://www.zwsoft.com/forum/forum.php?mod=forumdisplay&fid=2

    Pozdrowienia ,

    J.

     

  11. Ja zacząłbym od zapoznania się z wbudowanymi  w jądro API i metodami zapisywania dod. informacji w samych obiektach  (  XDATA i atrybuty (do bloków )  )

    Nie ma wtedy problemu z rozjechaniem się danych i bazy danych ( osobne pliki ) które wskazano wyzej jako ew. problemy.

    SQLite jest ok. ale rezerwowałbym go dla bardziej złożonych  projektów gdzie raport będzie dotyczył przetworzenia dużej ilości obieków ( ~ > 10000 ) bo wtedy w API wychodzą pewne ograniczenia ... 

    J.

  12. Dołączam się do uwag do działania okna Properties  ( właściwości skrót Ctrl+1 )

    Cieszę się że poprawiono sposób selekcji wierzchołków polilinii (vertex) - są teraz przyciski < > zamiast rozwijanego jako ComboBox V . Kto dużo pracował na poliliniach ten wie o co chodzi. Plus dla zespołu Zwcada :-)  

    Jednak okno "Properties" wymaga optymaizacji: 
    Design okna - zbyt rozwlekły, mnóstwo wolnej przestrzeni między napisami.
    Zwolnione miejsce przydało by się na ulepszony mechanizm dokowania :

    Problem dotyczy właściwie wszystkich okien dokowanych do lewej lub prawej krawędzi: 
    Jedno okno po zadokowaniu zawłaszcza całą wysokość krawędzi ( mi po wielu minutach prób nie u dało się umieścić dwóch zadokowanych okien jedno pod drugim (np. Properties + design center albo okno komend )

    Zoptymalizowane dokowanie to temat wg. mnie rozwojowy dodałem także osobny wątek dotyczący okna _Layers :

     

    Pozdrawiam

    J.

     

  13. Dokowanie okien do krawędzi to świetny patent. 
    Szczególnie jedno okno ( _Layers ) warto by do dokowania przystosować. 

    Byłoby to skokiem jakościowym w ergonomii (możliwość pracy z otwartym na stałe oknem _Layers już kilka lat temu wdrożyła konkurencja. 
    Doceni to ten kto musi równolegle pracować na kilkudziesięciu / a czasem kilkuset warstwach.

     

  14. 1. Zasadniczy kierunek rozwiązania  to użycie  XData.  Każdy obiekt może mieć zdefiniowane dane dodatkowe.

    Praktyczna obsługa  musi jednak być programowo np. nakładki ( Lisp / VB / C# ) .  Helpy Zwcada i Autocada dla developerów dosyć szeroko traktują temat.

     

    2. Pewna praktyczna  idea łączenia obiektów ( np. polilinii z blokiem lub mtext ) jest pod tym adresem

       http://www.lee-mac.com/associativecenterlines.html

    Była także pewna dyskusja na tym forum z rozwiązaniem pewnego Bug'a ZwCAD;a ( już ok ) . Przykładowy skrypt lispa używa kilku technik Asocjacje/reaktory/XData)  i to raczej 'tylko dla orłów' 

    Takie asocjacje interaktywne to bardzo praktyczne rozwiązanie . Niestety  wprowadza także dod. ograniczenia ( przenośność ) .

    Pozdrowienia,

    J.

  15. Witam,

    Na ZWCAD 2018 vernum 21849 POL sprawdzone i po korekcie acOCS na zcOCS  i zadziałało!.

         Poprawny wynik po translacji to  punkt  [ -3,1,-1.5 ]

     

    Trochę mnie zaskoczyło, że rozwiązanie wyglądało na banalne. 

    Jednak po sprawdzeniu na starszym ZWCAD 2017 vernum 18776 ENG  bug był i to conajmniej jeden:

    m.inn VBA nie znał stałej zcOCS ( = 4)  stąd kompilator nie zgłosił błędu z powodu ( stała acOCS otrzyma wtedy wartoiśc =0.

    Aby ten problem wykryć przed kompilacja trzeba by dodać deklarację na początku kodu:

    Option Explicit    ' Wymusza jawną deklarację zmiennej z typem przed pierwszym użyciem
    

    Podsumowując: 

    Od ZwCAD 2018 można już używać  w VBA  TranslateCoordinates do np: konwersji polilinii 2D   na 3D

    Dziękuję za informację  i pozdrawiam,

    J.

     

  16. Spróbuję potestować nową wersję bo widze, że z wydajnością cos się ruszyło.

    Z tego co zauważyłem jest jednak zamieszanie w opisach i sygnaturach : 
     
    1. jak wskazał już kolega Parikon - rozjechały się daty i vernum wydań oficjalnych Zwcad 2018 POL i ENG . Wg mnie to ryzykowna praktyka.

    2. Wątpliwości jesli nie zamieszanie  pogłębiają niespójne w opisach daty wydań wersji POL ( na zwcad.pl ) i na stronie archiwów - jakicad.pl ( tam data wydania jest  22.09.2017 ). 

    3. Co gorsza - w opisach  [2] nie podano jakich vernum dotyczą (święta zasada pozwalająca ew. bugi i uwagi jasno odnościć do konkretnego wydania  ) . 

     4. Zerknąłem na opis na zwcad.pl (https://www.zwcad.pl/zwcad-2018.html )  Linki do pobrania na tej stronie maja w nazwach 'Beta'  ( także wątpliwość czy pobieram wersję aktualną ...) . 

     kopia: Pobierz teraz ZWCAD 2018:

    [ZWCAD 2018 PL 32bit] link prowadzi do ... zwcad-download/zwcad/wersje-beta/zwcad-2018/105-zwcad-2018-beta-pl-32bit.html
    [ZWCAD 2018 PL 64bit] link prowadzi do  ...zwcad-download/zwcad/wersje-beta/zwcad-2018/104-zwcad-2018-beta-pl-64bit.html

    -

    Najważniejsze zatem kwestie do ustalenia i zafiksowania w opisach :

    Jakie daty i vernum mają oficjalne wydania Zwcad2018 ENG i POL ?

    Pozdrawiam

    J.

     

  17. Ja sprawdziłem na  Windows 7 PL  i klawiatura PL tzw. programisty : 

    Windows (na pewno do wersji 7) nie uwzględnia  zmiany separatora dziesiętnego w ustawieniach regionalnych z przecinka na kropkę w obsłudze klawiatury numerycznej  ( u mnie daje nadal ',' ) 

    Ew. korektę może dokonać odp. aplikacja (  przemapowanie klawiatury ). 

    Co ciekawe tak robi np. MS Excel ale już n ie MS Word !  

    Prosty test: 

    1. W ustawieniach regionalnych podajemy kropke (.) jako separator dziesiętny
    2. MS Excel po naciśnieciu kropki na klawiaturze numerycznej pojawia się kropka  (czyli lokalnie  poprawnie ! )
    3. W Zwcad 2017 (ENG) po naciśnięciu kropki na klawiaturze numerycznej w linii komend pojawia się przecinek ( błąd ) . 

    Dodam, że mój MS WORD 2003 również pokazuje przecinek (czyli ignoruje ustawienie regionalne ! ) . 

     

    1 godzinę temu, dmatusz3 napisał:

    Nie wiem czy jest w naszej mocy zmiana działania kalkulatora (wydaje mi się, że zmian trzeba dokonać znacznie głębiej).

    Wg mnie ZWCAD' także w linii komend ( i oczywiście kalkulator ) powinny przemapować jednak wspierać ew. korekty systemowych zmieniona zmianę separatora dziesiętnego tak jak MS Excel.
    Może i głębiej ale jednak ZWCAD'owi powinnno byc bliżej do MS Excel niz MS Word.

    Pozdrawiam,

    J.

  18. Dnia 4.11.2014 o 13:11, perlon napisał:

    Bardzo ciekawa tematyka. Niestety jest pewna nieścisłość w naświetleniu tematu sieci VPN. Tunel łączący dwa komputery w sieci nie tylko ma wlot i wylot ale również stację przesiadkową w postaci serwera hamahi. Jest to słaby punkt tego rozwiązania bo powierzamy bezpieczeństwo danych przesyłanych przez tunel osobie/organizacji trzeciej. Niemniej w pewnych przypadkach funkcjonalność bardzo użyteczna. Czekam na kolejne odcinki.

    Mam podobne zdanie co kolega. To raczej dla małych teamów bez klauzul na konieczności zachowania podwyższonej poufnosci. 
    Dobre na początek ponieważ jest bardzo proste w instalacji i uruchomieniu. 

    Pytanie: Czy przy zestawianiu tunelu musimy być zalogowanii do jakiegoś konta np. w domenie vpn.net ?

    Jeśli tak to cały ten ruch powinien być prześwietlony przez niezależna firmę w celu wykluczenia podatności na wycieki informacji lub podatność na bardzo stary już atak typu "man i n the middle"

     

    Pozdrawiam, 

    J.