On Saturday, October 10, 2015 at 10:47:26 PM UTC+2, Radoslaw Jocz wrote:
> > Nie wiem co dokładnie robisz, z góry przepraszam, nie mam też czasu
> > się wczytać w Twój problem. Zwykle przed odrysowaniem czyści się
> > ekran poprzez wypełnienie każdego pixela jednolitym kolorem. Nie
> > wiem czy też czyścisz, czy nie, ale jeśli tak, to Twoja metoda wcale
> > nie jest szybsza.
> >
> > Pozdrawiam
>
>
> nie musi byc najlepsze czy najszybsze tylko nadajace sie do konkretnego
zastosowania,
>
> nie robie animacji tylko wyswietlanie statycznych elementow, dodatkowo jest
> zoom i scroll.
>
> poczatkowo zalezalo mi aby funkcja byla szybka i dokladne co do +-1 piksel.
> Opracowalem algorytm ktory pozniej zaimplementowalem.
> Chcialem to zmodyfikowac bo pojawialy sie niekiedy przesuniecia +-1 piksel
> pomiedzy oktetami w ramach tego samego okregu
>
>
> jak opracuje kolejny lepszy algorytm to napisze tutaj o tym

Dlaczego nie używasz gotowych bibliotek?

do góry

W dniu sobota, 10 października 2015 18:30:44 UTC+2 użytkownik firr napisał:
> W dniu sobota, 10 października 2015 17:48:51 UTC+2 użytkownik Radoslaw Jocz
napisał:
> > > wszystko jest super proste, po prostu jest to regula na na x dla danego y oraz
r,
> > > cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy
porownac
> > > kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z
jedno lub ze dwa, juz w to nie che mi sie wczytywac)
> >
> > wiem to doskonale,
> > problem z orginalnym midpointem jest taki ze jest dobry dla pelnych kół,
> > w całości lub w większości wyswietlanych, przec co mają mały promień.
> >
> > wyobraź sobie promien 1,000,000 pikseli w oknie 640x480 czy chcesz iterowac te
miliony niewidocznych punktów ???
> >
> > mia mam zamiaru obliczać sqrt, dla porownan potegi dlugosci wystarcza,
> > I na tym polega midpoint,
> > ponadto zakłada dzialania na intach wiec jest przenosny w 100%
> > problem polega na tym ze ja chce okienkowac koła lub wycinki koła o dużym
promieniu, z maksymalnym błędem +- 1 piksel na całym obwodzie co już dawno mi się
udało,
> >
> > teraz tylko się zastanawiałem czy mogłbym idealnie to rysować co do piksela,
> > oczywiście orginalny midpoint odpada
>
> moze spróbuj napisac midpoint ktory bedzie
> rysowac łuk od punktu A do punktu B, chyba
> nie powinno byc takie trudne - pozniej zostanie wyznaczyc A i B

Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego inaczej - tj wogole
nie midpointem - cos w stylu logo
- bierzesz punk startowy liczysz styczną
( a sytyczna do promienia to cos w stylu
{tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu - trzebaby to przemyslec
ale jest to ogolnie dobra idea, nie ma tych wiadomych problemow na jakie cierpi
midpoint bo jest 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)

do góry

W dniu środa, 14 października 2015 16:11:28 UTC+2 użytkownik firr napisał:
> W dniu sobota, 10 października 2015 18:30:44 UTC+2 użytkownik firr napisał:
> > W dniu sobota, 10 października 2015 17:48:51 UTC+2 użytkownik Radoslaw Jocz
napisał:
> > > > wszystko jest super proste, po prostu jest to regula na na x dla danego y
oraz r,
> > > > cale przyspieszenie wynika z tego ze nie trzeba liczyc pierwiastka wystarczy
porownac
> > > > kwadraty (i ew z rozwiniecia tych paru mnozonek i dodawan by zaoszczedzic z
jedno lub ze dwa, juz w to nie che mi sie wczytywac)
> > >
> > > wiem to doskonale,
> > > problem z orginalnym midpointem jest taki ze jest dobry dla pelnych kół,
> > > w całości lub w większości wyswietlanych, przec co mają mały promień.
> > >
> > > wyobraź sobie promien 1,000,000 pikseli w oknie 640x480 czy chcesz iterowac te
miliony niewidocznych punktów ???
> > >
> > > mia mam zamiaru obliczać sqrt, dla porownan potegi dlugosci wystarcza,
> > > I na tym polega midpoint,
> > > ponadto zakłada dzialania na intach wiec jest przenosny w 100%
> > > problem polega na tym ze ja chce okienkowac koła lub wycinki koła o dużym
promieniu, z maksymalnym błędem +- 1 piksel na całym obwodzie co już dawno mi się
udało,
> > >
> > > teraz tylko się zastanawiałem czy mogłbym idealnie to rysować co do piksela,
> > > oczywiście orginalny midpoint odpada
> >
> > moze spróbuj napisac midpoint ktory bedzie
> > rysowac łuk od punktu A do punktu B, chyba
> > nie powinno byc takie trudne - pozniej zostanie wyznaczyc A i B
>
> Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego inaczej - tj
wogole nie midpointem - cos w stylu logo
> - bierzesz punk startowy liczysz styczną
> ( a sytyczna do promienia to cos w stylu
> {tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu - trzebaby to
przemyslec
> ale jest to ogolnie dobra idea, nie ma tych wiadomych problemow na jakie cierpi
midpoint bo jest 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)

przynajmniej co do prostoty jesli nei do wydajnosci, ale by to trzeba sprawdzac a ja
ostatnio faza leniwa, ale przedyskutowac odrobikne mozna czemu nie

do góry

On 14.10.2015 16:11, firr wrote:

>
> Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego
> inaczej - tj wogole nie midpointem - cos w stylu logo - bierzesz punk
> startowy liczysz styczną ( a sytyczna do promienia to cos w stylu
> {tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu -
> trzebaby to przemyslec ale jest to ogolnie dobra idea, nie ma tych
> wiadomych problemow na jakie cierpi midpoint bo jest
> 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)



To jest bardzo niewydajne. Ale padł tam też inny pomysł. Jeśli nie chce
się nam naprawiać midpointa dla dużych powiększeń, narysuj beziera.
Te krzywe bardzo ładnie przybliżają ćwiartkę koła, mniejszy fragment
pójdzie jeszcze lepiej.

Za to rysowanie beziera jest ciut bardziej skomplikowane:
http://members.chello.at/~easyfilter/bresenham.html


pzdr
bartekltg

do góry

W dniu środa, 14 października 2015 19:40:56 UTC+2 użytkownik bartekltg napisał:
> On 14.10.2015 16:11, firr wrote:
>
> >
> > Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego
> > inaczej - tj wogole nie midpointem - cos w stylu logo - bierzesz punk
> > startowy liczysz styczną ( a sytyczna do promienia to cos w stylu
> > {tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu -
> > trzebaby to przemyslec ale jest to ogolnie dobra idea, nie ma tych
> > wiadomych problemow na jakie cierpi midpoint bo jest
> > 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)
>
>
>
> To jest bardzo niewydajne.

no nie wiem a z czego wynika to zwolnienie?
nalezalo by przetestowac


> Ale padł tam też inny pomysł. Jeśli nie chce
> się nam naprawiać midpointa dla dużych powiększeń, narysuj beziera.
> Te krzywe bardzo ładnie przybliżają ćwiartkę koła, mniejszy fragment
> pójdzie jeszcze lepiej.
>
> Za to rysowanie beziera jest ciut bardziej skomplikowane:
> http://members.chello.at/~easyfilter/bresenham.html
>

a gdzie jest zrodlo tego "set pixell aa"?
bo nie do konca wiadomo co autor ma na mysli,

rysowanie beziera jest ultraproste

void DrawBezier(float ax, float ay,
float bx, float by,
float cx, float cy,
float dx, float dy, unsigned color)
{
float step = 1.0/1000.0;

for(float t=0; t<=1; t+=step)
{
float u = 1.0-t;

float a = u*u*u;
float b = 3.0*u*u*t;
float c = 3.0*u*t*t;
float d = t*t*t;

float x = ax*a + bx*b + cx*c + dx*d;
float y = ay*a + by*b + cy*c + dy*d;

SetPixel(int(x),int(y), color);

}

}

problemem jest tylko to ze nalezaloby umiec jakos oszacowac w miare prostym kodem
dlugosc beziera dla danych punktow kontrolnych (analitycznie jest to trudny
wzór, a jak to oszocaowac nie wiem)
Byc moze ta wersja ze stronki liczy adaptatywnie tam wlasnie tą długosc/gestosc po
luku, nie wiem nie mam chwilowo zbyt duzo czasu by sie wczytywac



>
> pzdr
> bartekltg

do góry

> wzór, a jak to oszocaowac nie wiem)
> Byc moze ta wersja ze stronki liczy adaptatywnie tam wlasnie tą długosc/gestosc po
luku, nie wiem nie mam chwilowo zbyt duzo czasu by sie wczytywac
>
>
>
> >
> > pzdr
> > bartekltg

mi podoba sie prostota procedury midpoint tylko nie podobaja mi sie jej implementacje

dlatego tez musialem zaimplementowac swoja, dzialajaca lepiej dla moich potrzeb

jesli cos zmienie w swoim kodzie to beda to zmiany niewielkie.

obecnie nie jest to moim piorytetem, ale podystkutowac czasami warto

Mysle ze Bresenham i Midpoint powinny byc zawsze na int i long a nie float czy
double.
Widzialem juz w internecine tyle omowien procedury midpoint i kazde jest nieco inne,
lub podobnie mierne do kazdego poprzedniego, tylko jedno ktore widzialem omawialo
dobrze zagadnienie jego optymalizacji z analitycznym wyprowadzeniem ale brak w ogole
konkretnych zagadnien okienowania. Wikipedia jest dobrym przykladem jaki w tym
balagan, tyle tam wersji implementacji i jezykow i w kazdej inaczej jest wszystko
przypisywane, balagan.

Podstawa dobrej implementacji sa dobre zalozenie poczatkowe

circle_in_window(
long cx, long cy, long cr,
int wx1, int wy1, int wx2, int wy2)

arc_in_window(
long cx, long cy, long cr,
long ang_start_x, long ang_start_y,
long ang_end_x, long ang_end_y,
int wx1, int wy1, int wx2, int wy2)
)

dla wycinka dalem katy start, end podawane jako 2 liczby ze znakiem dla kazdego kata,
odpowiadaja one przyrostom pikseli dx, dy od srodka okregu

wx1, wy1, wx2, wy2 to wspolczedne okna do okienkowania (obcinania)

okno typu int wstarczy dla kazdego system graficznego
wszystkie parametry samego okregu jako long aby nie bylo przepelnien
i aby mozna zdefiniowac wszystko dokladnie np srodek okregu daleko za ekranem
duzy promien, dokladne co do piksela polozenie startowe i koncowe luku

mysle ze jest wszystko w porzadku z parametrami

do góry

> >
> > jak opracuje kolejny lepszy algorytm to napisze tutaj o tym
>
> Dlaczego nie używasz gotowych bibliotek?

bo dzialaja poprawnie tylko przy stosunkowo malym promieniu

do góry

> Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego inaczej - tj
wogole nie midpointem - cos w stylu logo
> - bierzesz punk startowy liczysz styczną
> ( a sytyczna do promienia to cos w stylu
> {tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu - trzebaby to
przemyslec
> ale jest to ogolnie dobra idea, nie ma tych wiadomych problemow na jakie cierpi
midpoint bo jest 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)

midpoint jest OK jest szybki w 100 i dokladny w 100 tylko trzeba go dobrze
zainicjowac i zrobic walidacje parametrow poczatkowych oraz dbac o to aby nie bylo
przepelnien

do góry

W dniu czwartek, 15 października 2015 11:29:39 UTC+2 użytkownik Radoslaw Jocz
napisał:
> > Ps na grupie zagranicznej (comp.lang.c) padla idea rysowanie tego inaczej - tj
wogole nie midpointem - cos w stylu logo
> > - bierzesz punk startowy liczysz styczną
> > ( a sytyczna do promienia to cos w stylu
> > {tx, ty} = {-ry, rx} ) i idziesz po prostu piksel do przodu - trzebaby to
przemyslec
> > ale jest to ogolnie dobra idea, nie ma tych wiadomych problemow na jakie cierpi
midpoint bo jest 'direction-agnostic' - w przypadku malych lukow to moze sie oplacac)
>
> midpoint jest OK jest szybki w 100 i dokladny w 100 tylko trzeba go dobrze
zainicjowac i zrobic walidacje parametrow poczatkowych oraz dbac o to aby nie bylo
przepelnien

tak czy owak to z zolwiem wydaje mi sie ciekawa metoda ale nie mam sily w tym teraz
podlubac mam wazniejsze sprawy na glowie

co do wyjasnien algorytmow to chwile zastanowailem sie jak wyjasnic zwyklego
bressenhama, nie mam czasu sie wczytywac
w tego klasycznego bressenhama

ale wychodziloby na to ze jesli np
ma byc narysowana linia o dx = 100 , dy=37
to w kazdym x++ do zmiennek kontrolney y
(mozn anazwac d) dodaje sie 37/100
i sprawdza czy przekroczylo 1.0 jesli tak
to y++ a zmiena kontrolna -1.0, tyle ze
aby uniknac ulamkow mozna dodawac samo 37 i sprawdzac z 100


dx= 100;
dy = 37;

for(;;)
{
x++;
d +=37; if (d>=100) y++, d-=100;
}

ot i wielka tajemnica raczej slamazarnego algorytmu (setki branchów), sam rysuje
linie na fixedpointach, kiedys mierzylem roznice
w wydajnosci ale nie pamietam (wersja na fixedpointach jednak raczej lepiej rokuje)
nie mam sily sprawdzac [mozna tez pomyslec
rozwinieta zoptymalizowana wersje

for(j=0; j<m; i++)
{
for(i=0; i<nx; i++ ) x++;
y++;
}

gdzie m i nx sa wziete z tablei dla
roznych popularnych slopów 1/1, 1/2, 2/3, 1/3, 1/4, 3/4, 1/5... itd

trzebabbedzie kiedys sprawdzic, szybkie linie sa dosyc wazne tak naprawde

do góry

On Wednesday, 21 October 2015 08:42:31 UTC+1, firr wrote:
>
> tak czy owak to z zolwiem wydaje mi sie ciekawa metoda ale nie mam sily w tym teraz
podlubac mam wazniejsze sprawy na glowie
>
> co do wyjasnien algorytmow to chwile zastanowailem sie jak wyjasnic zwyklego
bressenhama, nie mam czasu sie wczytywac
> w tego klasycznego bressenhama
>

Masz na mysli linie prosta jesli chodzi o bresenhama czy okrag?
Zakladam ze poprostu myslisz o midpoint a mowisz bresenham, bo o okregach mowimy.

Wyjasnienie dzialania modpointa jest proste. Mam 10 slajdow z wyprowadzeniami
analitycznymi ale nie chce mi sie tego tutaj przepisywac.

Podstawowa idea dzialania midpointa polega na rownaniu okregu i inkrementacjach x i
y. Zmienna decyzyjna opiera sie na rownaniu okregu
i sluzy jedynie do sprawdzenia czy promien r jest w miare dobrze zachowany w danym
punkcie p(x,y)

ponadto w przypadku x++; zwiekszamy promien dla x++; y--; zminiejsza sie promien
przyrosty zmiennej decyzyjnej d sa oparte na odpowiednim wyprowadzeniu analitycznym

startujac od dwolnego punkty p(x,y) mozna by zainicjowac d = x^2+y^2-r^2,
jednak nie jest to dokladnie to samo gdy startuje sie od x=0; y=r; d = 1-r
bo w midponcie d jest inkrementowane skokowo na podstawie poprzedniej wartosci, itd,
wiec w konsekwencji beda drobne roznice w porownaniu z orginalnym midpointem

wczesniej zastanawialem sie nad tym czy dalo by rade analitycznie wyprowadzic dane d
= f(x,y)
aby szybko zainicjalizowac d identycznie jak jest w orginalnym midpoincie
i rysowac identycznie co do piksela startujac od dowolnego punktu,
ale mysle ze to niemozliwe

ponadto przydalo by sie nawet wiecej
mial by powiedzmy dane poczatkowe:
x = x0, r

trzeba by wyznaczyc
y0 = f(x0, r)
d0 = f(x0, y0, r)
mysle ze takim rozumowaniem niewiele mozna by zdzialac.


uwazam wiec ze w przypadku rysowania okregu lub wycinka okregu z okienowaniem
powinno sie najwyzej 1 raz inicjowac zmienna d dla danego okregu,
mozna startowac od dowolnego punktu ale dobrze gdy to jest tylko 1 raz dla danego
okregu, dzieki temu cwiartki i oktety bedz wzajemnie idealnie dopasowane,

mozna to zrobic tak jak mowilem juz kiedys wczesniej wyznaczyc zakresy dla kazdej
cwiartki i oktetu i znalezc minimalny konieczny i wystarczajacy zakres dziedziny
funkcji ktora jest konieczna do narysowania wszystkich punktow okregu przez odbicia,

wtedy bedzie 1 petla i znany z gory zakres od-do
w petli sa sprawdzenia czy dany punkt jest jest
mozliwy do narysowania dla danego odbicia (jest 8 mozliwych odbic)
8 sprawdzen czy jest w oknie ) + (8 dodatkowo dla wycinka czy jest w zakresie katow
np podanych parami liczb, dx1, dy1, dx2, dy2 lub w inny sposob)

nie jest to mozliwa najszybsza metoda ale wystarczjaco dokladna i szybka
dla duzych promieni,
ponadto ma 2 wazne cechy
1. wszystkie rysowane oktety danego okregu sa idealnie symetryczne wzgledem siebie
2. rozpoczecie rysowania pierwszego widocznego punktu nie wymaga iteracji petli bo
punkt startowy rozny od P(0,r) jest obliczony (w przeciwienstwie do orginalnego
midpointa)

do góry