Exigo

Ale fajna sprawa z tym edytorem. Teraz spędziłem trochę czasu nad ogarnianiem mat'sów. Poniżej efekt, zamieniający static mesha w "lodowe propsy" z kolcami, szronem, śniegiem i w ogóle, wszystko (prawie, prócz normalek) proceduralnie. Kolce są robione vertexshaderem. Dobre, bo jakąkolwiek siatkę by nie wrzucić, nawet jakiś przypadkowy shit, byle by zawierało uv coordy, to i tak zamienia na coś sensowniejszego. mesh --[shader]--> efekt

Przez całą noc zapoznawałem się z udk, w sumie kiedyś musiało do tego dojść. Zaje***ty silnik-soft. Scenka poskładana z zawartych assetów.

U mnie wygląda to tak: Jestem na miejscu, w sobotę wieczorem na afterce będę co jest pewne. Właściwa impreza (PH) pod znakiem zapytania, zobaczymy. Zależy co zaprezentują. W niedzielę nawet jeśli uda mi się przyjść to tylko na momencik, na pewno nie zostanę na zakończenie bo muszę się szybko zwijać na poniedziałkowy, poranny egzamin. Szkoda że nie będzie nikogo z administracji która ogarnęłaby wszystkich na meeting wspomniany przez Willa, w celu pamiątkowej fotki czy coś w tym stylu. Mnie chyba z twarzy znacie, pewnie się zobaczymy, w szczególności wieczorem.

Sculpt rękawicy, gdzie pierwszy raz użyłem narzędzia pod nazwą polygroups (jak i uprzednio specjalnie przygotowałem mesha w tym celu). W planach reszta setu, zobaczymy.

W sumie blisko. Czemu nie.

Pewnie chodziło o postprocessing. Po prostu obleciał byś scenę shaderem i na podstawie depth mapy robił mgłę. Nie dość że byłoby per-pixel, to jeszcze mniej wymagające obliczeniowo.

Dla odmiany piszę sobie kosmicznego rts-a. Placeholdery wszędzie. Formacje z sortowaniem, statki są łączone w grupy, a do tych większych maszyn można montować jakieś działka, etc. Nic wielkiego na screenie, ale kodu jest chmara. @Edit: Teraz mogą strzelać i co najważniejsze wybuchać. Z tym wybuchaniem było niefajnie bo zostałem zmuszony do przepisania paru rzeczy. Po prostu nie przewidziałęm że coś może kiedyś po prostu "zniknąć". :D https://gmclan.org/uploader/3290/rts_forms_test_v3.jpg

Trzeba się kiedyś nauczyć robić twarze. Największym wyzwaniem jest ucho, to wam powiem.

Jeśli nie zaszły zmiany to głównie brany jest wynik z egzaminów. Oceny też, ale nie mają znaczącego wpływu. A to całe dostawanie się i napięcie wokół: ściema. Bo nie ma czegoś takiego jak liczba ograniczonych miejsc w szkołach średnich (no chyba że w skrajnych przypadkach) w przeciwieństwie do studiów, a jak jest za dużo chętnych to kombinują na wszystkie sposoby aby upchać chętnych (np. podział na grupy). Tak więc śmiało bij tam gdzie chcesz.

No dobra, czas to wysłać w sieć. :) <link do dropboxa z modelem (20MB)> <inne ujęcia, siatka i minaturki tekstur> Btw. model jest skonstruowany pod skyrimowego mesha, więc jeśli znajdzie się jakiś zapalenieć żeby to zriggować i wrzucić to do jakiegoś moda, czemu nie.

Poniżej model lp 1982 tris z wypalonym ao. Pozostało to jeszcze pomalować. Pióra mają oddzielny materiał + transparency. W zasadzie pierwszy raz robię tak złożony model (asymetria, materiały, grupy). @Edycja: Rysuję teksturę, poniżej zaczęta.

Czarownik, który rzekomo miałby zdolność przemiany w kruka, jak ten, no, medivh z W3. Piór jak widać nie ma, ale w założeniu będą wystawać spod tych trzech górnych warstw szaty. Pipeline determinuje zrobienie tego na końcu. No i myślę żeby wywalić te pióra wokół maski i walnąć mu jakiś kaptur (maskę zostawić). Będzie bardziej mrrroczny. Będzie to pierwszy model z elementami asymetrii. (pierwsza wersja, link)

Istnieje sposób na ustalenie iteracji krzywej Béziera tak, aby odległości pomiędzy zwróconymi punktami były równe (punkty obok siebie, tzn. coś w stylu n i n+1)? Iterując liniowo (np. i += 0.1) rozłożenie punktów jest nieoptymalne w sytuacji zgięcia krzywej. Punkty rozłożone są nierównomiernie. Obrazując, zagęszczenie na wymienionym "zgięciu" jest bardzo małe. Można zrobić jakąś metodę na to?

Rozmyte nie ze względu na teksturę, ale upchane coordy uv na rzecz innych części ciała. Było to zamierzone. Zresztą, chodzi o kolejność "na co najpierw patrzę", i dostosowanie detalu. Najpierw są cycki, potem twarz, przerażająca ilość świecących oczu, zęby, itd. Nogi w tym przypadku są najmniej ważne po tym przez co przechodzi obserwator. Problem rozmycia pewnie jest wyolbrzymiony ze względu na złe ujęcie. W każdym razie dzięki za uwagę, widocznie przegiąłem, przyznaję, rozmyte. ; ) Btw. Polecam pobranie triala Marmoset Toolbag. To taki viever do next-genowych modelów. Po prostu wrzucacie model, podpinacie tekstury, i nie musicie się opierać na samych zrzutach. No i fajna zabawa suwakami od shaderów.

Jee, skończyłem. Trochę się zeszło, z dużymi przerwami. Po za tym była masa problemów po drodze, m. in. przez lwią część czasu próbowałem rozgryźć czemu xsi nie exportuje mi uv. Pająk. 4966 trisów. Model do pobrania (link). Inne ujęcia (link).

Nieee, on Konrad ma na imię, nie jesteście w temacie. Btw. http://forum.warsztat.gd/index.php?topic=2...12477#msg312488

@Shil, bo to jest kobieta pracująca, wyzwolona, czy coś w tym stylu. A oczy są, i to całkiem sporo, jest też kilka na klacie (jak masz te wgłębienia). Btw. właśnie skończyłem retopo brzucha, jeszcze odwłok i noga. Najbardziej nudna robota. https://gmclan.org/uploader/3290/spider_que...opo_process.jpg

Haha. Miałem zrobić bardziej ogarniętą twarz, ale wyszło jak zwykle. Czyli z zębami. Dużo zębów.

Niedawno zacząłem tą panią. Tym razem postanowiłem nie wrzucać wszystkiego do jednego toola z dynameshem bo nauczyłem się że update traci na jakości, a nie mam tyle ramu żeby trzymać parę mln trisów. Btw. przegrzebałem całą sieć w poszukiwaniu sensownego basemesha z babskim ciałem, ale nie idzie. Albo słabe, albo trzeba płacić. Wkurzyłem się i zripowałem części ciała ze skyrima, połączyłem, usunąłem trinagulację i poprawiłem parę rzeczy w topolgii. Może komuś się przyda: https://gmclan.org/up3290_3_female_quad.html (uwaga, ma suty!)

n = floor(x / 640); zwróci ci liczby naturalne od zera wzwyż oznaczające wielokrotność "przekroczenia" granicy. Potem możesz to sobie liczyć view_xview = n * 640;

Zwykłe rysowanie co klatkę. Po ustawieniu traile stale zmieniają pozycje co ustalony wektor, tak więc każdorazowo trzeba je przerysowywać. Tip w stylu pakowania traili do surface i stopniowe fade-owanie wszystkiego nie zadziała (właśnie ze względu na konieczność każdorazowego rysowania). Choć powiem szczerze że z początku myślałem o tym.

Mimo wszystko wrócę do pytania związanego z metodą. Otóż przy kilkunastu aktywnych generatorach tworzących w sumie maksymalnie z 600 trailów, gra jest bardzo "żerna". Wydaje mi się że problem tkwi w pętli przeszukującej nieaktywne komórki. Jak komuś przyjdzie do głowy alternatywne rozwiązanie, niech pisze. Będę wdzięczny za jakiekolwiek pomysły.

Dobra, jednak wystarczyło oddzielić pętlę logiki od pętli rysowania. For wykonuje się liniowo od początku do końca a rysowanie potrzebowało elementów "przyszłych" iteracji, których traily nie były <jeszcze> zaktualizowane do nowej pozycji. Stąd te artefakty w postaci przesunięć. Problem można potraktować jako rozwiązany. Dzięki za pomoc. :)

Każdy trail musi trzymać indeks do następnego. To i-1 miało by to sens, jeśli istniała by tylko jedna wiązka. Ja natomiast korzystam z jednej tablicy dla nieokreślonej liczby wiązek. W takim przypadku, np. trzech wywołań add_trail co klatkę, a silniki były by ułożone szeregowo, ciąg miałby kształt harmonijki (dlatego że odwołuje się do poprzedniego indeksu który utworzył inny silnik).

Witajcie, kombinuję nad systemem "cząsteczek połączonych" do wizualizacji efektu śladu po silniku. Generalnie chodzi, ale czasami w ciągach występują artefakty których pochodzenia nie mogę odgadnąć. Wygląda to tak: Struktura traila (poszczególne komórki): x, y, wektor x, wektor y, życie (1-0), oraz adres na do traila z którym jest połączony. Na początku deklarowana jest wartość trzymająca max. ilość cząsteczek. GML trail_max = 0; Skrypt dodania traila: (początek skryptu wyszukuje "pusty" slot na ustawienie na nim traila) (pusty = nieużywany) GML var i; for (i = 0; i < main.trail_max; i += 1) { if (main.trail[i, 4] == -1) { break; } } main.trail[i, 0] = argument0; main.trail[i, 1] = argument1; main.trail[i, 2] = argument2; main.trail[i, 3] = argument3; main.trail[i, 4] = 1; main.trail[i, 5] = argument4; if (i == main.trail_max) { main.trail_max += 1; } return i; Skrypt rysujący wszystko: GML draw_set_blend_mode(bm_add); for (i = 0; i < trail_max; i += 1) { if (trail[i, 4] > 0) { trail[i, 0] += trail[i, 2]; trail[i, 1] += trail[i, 3]; _i = trail[i, 5]; if (_i != -1) { draw_line_width_color(trail[_i, 0], trail[_i, 1], trail[i, 0], trail[i, 1], 4 + (8 * trail[i, 4]), make_color_hsv(0, 192, trail[_i, 4] * 192), make_color_hsv(0, 192, trail[i, 4] * 192)); } trail[i, 4] -= .05; } else { trail[i, 4] = -1; } } draw_set_blend_mode(bm_normal); Używanie funkcji dodania traila wygląda tak, że jeśli trigger jest "pressed", tzn. pierwszy raz wciśnięty wciśnięty po przerwie, ustawiam: GML if _triggler_bool_press { dev_id.my_trail_last = -1; } Można to zinterpretować jako "zamykanie ciągu". W przeciwnym przypadku, czyli standardowo: GML dev_id.my_trail_last = add_trail(_xx, _yy, _vx, _vy, dev_id.my_trail_last); Mówiąc o artefaktach, miałem na myśli to co jest przedstawione na screenie (zapomniałem wyciąć, phi): Ślad jest poprawny (przerywany). Problemem są jednak te nagłe "skręty" które mają przemieszczenie odwrotne do wektora ciała. Tylko nigdzie nie mogę znaleźć powiązania. Co jest tego przyczyną? Będę wdzięczny jeśli ktoś wpadnie na jakiś trop. Lub ewentualnie zasugeruje lepsze rozwiązanie (np. na jakimś innej strukturze danych, nie koniecznie tablicach).