>
> http://0x80.pl/articles/bresenham.html#rasteryzacja-
okregu
>

nie jest powiedziane ze zwykle ztablicowanie y[x]
(scene way) okregu nie dzialaloby lepiej - co do
wydajnosci to nie wiem ale na pewno jest prostsze
(do uruchomienia) - np ja w swoim rasteryzerze zeby wyrenderowac kulke musialbym
skladac dwa
bressenhamy (i rozpatrywac przypadki szczegolne
wlasnie obciac przez ekran itd - na tyle mi sie
tego nie chcialo robic ze tego nie zrobilem dla z
wtedy wogole - teraz najpewniej po prostu stablicuje jakies spore kolko i pozniej
bede dla petli po x wyluskiwal y a w wewnetrznej
po x wyluskiwal z - done (co prawda sa male szczegoly, powiedzmy ze stablicowane mam
kolko
w tablicy od 0..do 512 (dla 0..R) i chalbym z tego wtbrac wartosci dla kolka o
promieniu 10
jak to zrobic bez dzielenia ? (tutaj potrzebne 512/10 ) - mozna np stablicowac
dzielenia

do góry

wogole powinienem wrocic do roboty nad
frameworkiem (moze dorobic blending) i
takich wlasnie tematow

do góry

W dniu czwartek, 27 czerwca 2013 11:36:46 UTC+2 użytkownik firr napisał:
> >
>
> > http://0x80.pl/articles/bresenham.html#rasteryzacja-
okregu
>
> >
>
>
>
> nie jest powiedziane ze zwykle ztablicowanie y[x]
>
> (scene way) okregu nie dzialaloby lepiej - co do
>
> wydajnosci to nie wiem ale na pewno jest prostsze
>
> (do uruchomienia) - np ja w swoim rasteryzerze zeby wyrenderowac kulke musialbym
skladac dwa
>
> bressenhamy (i rozpatrywac przypadki szczegolne
>
> wlasnie obciac przez ekran itd - na tyle mi sie
>
> tego nie chcialo robic ze tego nie zrobilem dla z
>
> wtedy wogole - teraz najpewniej po prostu stablicuje jakies spore kolko i pozniej
>
> bede dla petli po x wyluskiwal y a w wewnetrznej
>
> po x wyluskiwal z - done (co prawda sa male szczegoly, powiedzmy ze stablicowane
mam kolko
>
> w tablicy od 0..do 512 (dla 0..R) i chalbym z tego wtbrac wartosci dla kolka o
promieniu 10
>
> jak to zrobic bez dzielenia ? (tutaj potrzebne 512/10 ) - mozna np stablicowac
dzielenia

co gorsza trzebaby tez jednak dzielić (mnozyc)
te rzeczy wyciagniete z tablicy, czyli dwa 'skalowania' z = B*y[A*x] no ale raczej da

rade na fixpointach, sumarycznie nie wiem czy byloby szybciej czy wolniej niz na
midpoincie
ale jednak chyba latwiej zakodowac - moze to przetestuje za jakis czas

do góry

> wogole powinienem wrocic do roboty nad
> frameworkiem (moze dorobic blending) i
> takich wlasnie tematow

trzeba by potestowac bresenhama dla odcinków
vs zwykly sposób rysowania na fixedpointach
(ciekawilo mnie zawsze czy fix nie sa przypadkiem
szybsze) & midpointa vs teblicaka (pozniej przejsc
do rozmytych) - nie wiem czy zdolam sie za to wziac
ale trzebaby , mus to mus

do góry

>
> Pisałeś zdaje się, że nie możesz używać putpixel. Co się zmieniło?
>
>
> Co do zasadniczego pytania: przemnóż d przez 4, żeby nie było ułamka.
>
> Przez 4 też musisz przemnożyć czynniki wpływające na d.
>
>
>
> Pozwolę sobie dać linka do mojego art., gdzie ten temat już przerabiałem:
>
> http://0x80.pl/articles/bresenham.html#rasteryzacja-
okregu
>

Putpixela nie ma w Javie SE i Androidzie ale mozna rysowac krotkie odcinki,
lub jesli juz konieczny jest putpixel to moga byc prostakoty o bokach = 1
Jednak w celu optymalizacji mozna wspolrzedne odcinkow dac do tablicy i wywolac za 1
razem. W SE i Andr. sa do tego funkcje (w graphics i canvas).

Co do przemnozenia przez 4 to nie jest to konieczne bo mozna uzyc podstawienia
h = d - 1/4 a porownanie z 1/4 mozna sprowadzic i tak do 0 bo to liczby calkowite.
Mam kilka artykulow na temat midpoina w niektorych omawiaja drobne optymalizacje
polegajace na: uproszczeniu floatow do intow, redukcji wyrazen aby uniknac omnozenia
i tylko dodawac.

Jednak moze pytanie bylo na temat jak zainicjowac zmienne aby rysowac od dowolnego
punktu na okregu P(0, r) to wszyscy omawiaja.

Zauwazylem ze zmienna decyzyjna d to jest poprostu zmienna opisujaca rownanie okregu.
I mozna ja pezposrednio dowolnie zainiacjowac na poczatku majac obliczony punkt
startowy.
Poczatkowo nie bylem pewien jak bezposredno zainicjowac zmienna d od innego punktu
niz P(0, r), dlatego ze w petli do uzyskania kolejnej wartosci d uzywa sie wartosci
poprzedniej.

W niektorych artykulach jest opisane to bardziej zrozumiale, bez niepotrzebnych
skrotow. Wiec,
d = f(x,y) = x^2 + y^2 - r^2

Jednak nigdzie nie widzialem takiego przykladu aby zainicjowac d od innego punktu niz
(0, r), czy od (1, r - 1/2).

W celu optymalizacji rysowania w Javie chce rysowac krotkie odcinki.
Nie musze przechowywac w pamieci kazdego punktu.
Nie jestem jednak pewien czy inicjowanie duzych tablic ktore przechowuja punkty
odcinkow jest dobrym rozwiazaniem bo wtedy obciaza to pamiec.

Zalezy mi na tym aby przy dowolnym powiekszeniu abstrakcyjnego ukladu wspolrzednych
poprawnie wyswietloac okregi.
Widze ze standardowe bibliteki w Javie (ale pewnie nie tylko) maja bugi ktore
uniemozliwiaja poprawne rysowanie okregow o duzym promieniu.

public abstract void drawOval(int x,
int y,
int width,
int height)

public abstract void drawArc(int x,
int y,
int width,
int height,
int startAngle,
int arcAngle)

inty uniemozliwiaja podania okregu o duzym promieniu o srodku daleko od okna ekranu

public void drawCircle(float cx, float cy, float radius, Paint paint)

W Androidzie niby jest juz lepiej ale i tak implementacja algorytmu jest kiepska
co powoduje niedokladnosci przy duzym promieniu, co wynika prawdopodobnie z
przepelnienia intow.

do góry

W dniu piątek, 28 czerwca 2013 08:33:00 UTC+2 użytkownik firr napisał:
> > wogole powinienem wrocic do roboty nad
>
> > frameworkiem (moze dorobic blending) i
>
> > takich wlasnie tematow
>
>
>
> trzeba by potestowac bresenhama dla odcinków
>
> vs zwykly sposób rysowania na fixedpointach
>
> (ciekawilo mnie zawsze czy fix nie sa przypadkiem
>
> szybsze)


kiedys wlasnie przyszlo mi do glowy ze
trywialna wersja na fixpointach moglabybyc
szybsza (samemu mi to wpadlo do glowy bo nie
widzialem nigdy by ktos tak robil)
bo bressenham ma rozgalezienia,a fixy nie mają
i sa do tego latwiejsze do napisania i ja np
uzywalem w frameworku wlasnie z lenistwa fixpointow

bressenham:

for(int i=0;i<deltaY;i++)
{

SetPixelInDibInt(x,y,color);

temp-=deltaX;
y+=dy;
if(temp<=0) x+=dx, temp +=deltaY;

}

fixy:

for(int i=0; i<ile; i++)
{
x += dx ;
y += dy ;

int yc = (y>>16);
int xc = (x>>16);

SetPixelInDibInt(xc,yc,color);
}

u mnie na slabym kompie nakreslenie

if(f_pressed)
{

for(int k=0; k<2*5; k++)
for(int i=0; i<500; i++)
DrawLineBressenhamUnsafe(250,0,i,400,i<<8);
}
else
{
for(int k=0; k<2*5; k++)
for(int i=0; i<500; i++)
DrawLineScreenFixpointUnsafe(250,0,i,400,i<<8);
}

5tys lini zajmuje 30 ms fixpointem jest sladowo
szybsze (gdzies tak 29.5 zamiast 30 ms)

do góry

Dnia pamiętnego Fri, 28 Jun 2013 11:40:51 -0700, firr wyjmując peta
oznajmił:

> W dniu piątek, 28 czerwca 2013 08:33:00 UTC+2 użytkownik firr napisał:
>> > wogole powinienem wrocic do roboty nad
>>
>> > frameworkiem (moze dorobic blending) i
>>
>> > takich wlasnie tematow
[wytnięte nieczytelne łajno]
> 5tys lini zajmuje 30 ms fixpointem jest sladowo szybsze (gdzies tak 29.5
> zamiast 30 ms)

Taki przyjemny wątek był, a ty go zasrałeś dyskutując sam z sobą.

--
Edek

do góry

>
> W celu optymalizacji rysowania w Javie chce rysowac krotkie odcinki.
>
> Nie musze przechowywac w pamieci kazdego punktu.
>
> Nie jestem jednak pewien czy inicjowanie duzych tablic ktore przechowuja punkty
odcinkow jest dobrym rozwiazaniem bo wtedy obciaza to pamiec.
>

Szybkie i niezawodne okienkowanie okregu juz mam, lacznie z szybkim odrzucaniem i
akceptowaniem calosci.
Odnosnie midpointa to zrobie to na podstawie orginalu z modyfikacjami dla wlasnych
potrzeb.
Dla kazdego zakceptowanego fragmentu z 1/8 okregu bedzie cos takiego

midoint1(xc, yc, r, x1, y1, x2, y2)

x1, y1, y2, y2 sa to relatywne odleglosci do srodka.


Bede musial jednak zaimplementowac 8 funkcji dla midpointa aby efektywnie wykorzystac
funkcje renderujace drawLines lub drawPollyLine

public void drawLines (float[] pts, Paint paint)
public void drawLines (float[] pts, int offset, int count, Paint paint)
public abstract void drawPolyline(int[] xPoints,
int[] yPoints,
int nPoints)

bo punkty musza tu juz byc przeliczone jako absolutne wiec lepiej jest zrobic 8
oddzielnych procedur.

Ze wzgledu na to ze wielkosc tablicy rosla by wraz z wielkoscia okna czy
rozdzielczosci to moge zadeklarowac jej stala wielkosc, powiedzmy na 25 odcinkow
i w razie kotrzeby kilkukrotnie wywolywac funkcje drawLines.
Pozniej wielkosc tablicy i "dlugosc" odcinkow mozna bedzie dobrac tak aby dzialalo
dokladnie i szybko.

do góry

Dobrym chyba omowieniem algorytmu jest
https://www.cs.drexel.edu/~david/Classes/CS430/Lectu
res/L-06_Circles.pdf

Ponadto tutaj x i y jest jako odleglosc od srodka co mi odpowiada,
bo takie mam dane z cwiartek po okienkowaniu.

Poczatkowe d wylicze poprostu z funkcji x^2+y^2-r^2 na podstawie punktu startowego
p(x,y) czyli w punkcie p(x+1, y-1/2) i zaorkagle wynik do long,
i postaram sie aby wszystko co mozliwe zrobic na liczbach calkowitych

Pozniej jak juz stwierdze ze dzialala to pobawie sie z optymalizacja
wykorzystujac te funkcje.
public void drawLines (float[] pts, int offset, int count, Paint paint)
public abstract void drawPolyline(int[] xPoints, int[] yPoints, int nPoints)

to chyba na tyle w tym temacie.

do góry

Zaimplementowalem pod SE, rysowanie punkt po punkcie za pomoca
Graphics -> fillRect(int x, int y, int width, int height),
i mimo to ze jest punkt po punkcie to dziala szybko.

W Androidzie: Canvas -> drawPoint(float x, float y, Paint paint)
a pozniej zoptymalizowalem na
Canvas -> drawPoints(float[] pts, int offset, int count, Paint paint)
uzywajac 100 elementowej tablicy float jako pole klasy
(wiec jest zawsze dostepna w pamieci).
Na razie nie widze czy jest to szybsze i o ile ale sadze ze powinno byc.

Nie wiem dlaczego w Androidzie do wspolrzednych x, y nie uzywaja zmiennych typu
integer czy long tylko float ale i tak szybko to dziala.
Myslalem ze beda wieksze problemy.

do góry