co do profilowania to konkretnie w moim
rasteryzerze (ktory mysle by jakos przyoptymalizowac
ale nie mam za specjalnych pomyslow) to leci mw
tak:

- najpierw kazdy trojkacik ma liczony kolor (tutaj
konkretnie 3 doty normalnych trojkata do kierunkow
do swiatel), to zajmuje ok 25% calosci - normalnie dla low poly to zajmuje mniej bo
to jest per trojkat
ale tutaj trojkatow jest duzo i sa male wiec zajmuje

- dlalej kazy trojkat jest transformowany do
pozycji kamery rzutowany i clipowany, to zajmuje ze 30% ( z tego klipowania jakos
chyba wyjatkowo nie jestem zadowolony ale na razie nie mam pomyslu)

- w koncu kazdy trojkat jest rysowany na 2d
(to zajmuje ze 40% calosci) - medota scanline
dosc prymitywna procedura mojego autorstwa

nie bardzo wiem jak to cholerstwo poprawic
ale moze z czasem i przy poszperaniu w necie cos sie znajdzie

do góry

>
> - dlalej kazy trojkat jest transformowany do
>
> pozycji kamery rzutowany i clipowany, to zajmuje ze 30% ( z tego klipowania jakos
chyba wyjatkowo nie jestem zadowolony ale na razie nie mam pomyslu)
>
>

hehe akurat wymyslilem cos (zapisalem wczesniej
po angielsku na inne forum)


well after some thinking i invented something:


precomputing the visiblity, it goes such way:

from the given point of view (there are sphere of them) some triangles of the model
(say 30%) are visible other (70%) are not - Divide this sphere on say 64 patches and
precompute for every triangle if it is seen from this 'patch'

(it would be heavy to precompute, for example cost of rendering a couple of frames
from couple of places on the patches, the testet traingle the last to check if it
pass the depth buffer -
so this is cost of 64patches x 5 places x noOfTriangles so for example for this model
320x300 000 = 90 MFrames this is a lot of precomputing :C but can be done i think)

then set the corresponding bit in some 64 word of flags 1 means form this patchg of
visibility this triangle is seen - that should be very simple to use and top eficient
clipping method :U - though this precomputation time scares me but this can be
optymized

do góry

W dniu piątek, 6 grudnia 2013 13:07:24 UTC+1 użytkownik firr napisał:
> >
>
> > - dlalej kazy trojkat jest transformowany do
>
> >
>
> > pozycji kamery rzutowany i clipowany, to zajmuje ze 30% ( z tego klipowania jakos
chyba wyjatkowo nie jestem zadowolony ale na razie nie mam pomyslu)
>
> >
>
> >
>
>
>
> hehe akurat wymyslilem cos (zapisalem wczesniej
>
> po angielsku na inne forum)
>
>
>
>
>
> well after some thinking i invented something:
>
>
>
>
>
> precomputing the visiblity, it goes such way:
>
>
>
> from the given point of view (there are sphere of them) some triangles of the model
(say 30%) are visible other (70%) are not - Divide this sphere on say 64 patches and
precompute for every triangle if it is seen from this 'patch'
>
>
>
> (it would be heavy to precompute, for example cost of rendering a couple of frames
from couple of places on the patches, the testet traingle the last to check if it
pass the depth buffer -
>
> so this is cost of 64patches x 5 places x noOfTriangles so for example for this
model 320x300 000 = 90 MFrames this is a lot of precomputing :C but can be done i
think)
>
>
>
> then set the corresponding bit in some 64 word of flags 1 means form this patchg of
visibility this triangle is seen - that should be very simple to use and top eficient
clipping method :U - though this precomputation time scares me but this can be
optymized

(for example it is easy to sign the triangles that goes out for sure, it is harder to
make sure the one that previously passed will is totaly overvritten so it is also
goes out, bout
probably by rendering in changed direction and suming the onet that goes out will
give the sum of the set that is invisible)

I will try to implement it and check how it is working after some resting i should
take

do góry

to jest chyba zreszta znana technika potential visibility sets

wogole co do optymalizacji to chyba warto wyroznic dwa typy - 'gładka' tj taka ktora
nie komplikuje kodu oraz taka ktora obciaza jednak kod pewna narzuconą komplikacją
(wspominam o tym bo mam pewne zle doswiadczenia z takimi obciazajacymi
optymalizacjami)
wogole to ostatnio przegladalem artykul nt rasteryzera w quake 2 i tam to dopiero sa
robione
chocki klocki - wlasnie bardzo daleko posuniete optymalizacje przy czym nieststy
sporo tez przycinania efektów

do góry