Jump to content
n-pigeon

Blender - NEWS oraz dyskusje

Recommended Posts

 

Nareszcie! :) Niby dało się wcześniej ale teraz nie trzeba się pierniczyć ~godzinę z driverami za każdym razem.

 

-------

https://developer.blender.org/rBdda355442dc7ba4f83f65cb792be3f27be8c9fee

Cycles: Support tube projection for images

 

This way Cycles finally becomes feature-full on image projections

compared to Blender Internal and Gooseberry Project Team could

finally finish the movie.

Lol. :D

 

----

 

Lukas Toenne pierdyknął combo-pusha związanego z Gooseberry 2 dni temu. Razem na oko jakieś 300 różnych comitów. Jakie cuda w środku. Podwaliny renderowania PTexa w Cyclesie, masa zupełnie nowych rzeczy z hair-sima. Dużo nowości z renderem włosów w cyclecie jak i w internalu. Grube zmiany w systemie particli.

Warto popatrzyć do Release logów co już jest dostępne. PTexa chyba możemy się spodziewać bardzo szybko. :)

 

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.74

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.74/Hair !!!

 

-----

https://developer.blender.org/D1008

Początkowa implementacja OpenVDB particle mesher modifier.

Edited by Monio

Share this post


Link to post
Share on other sites

Skompilowałem dzisiaj OpenVDB i spatchowałem "particle meshera" pod OpenSUSE. Szybki teścik przy 200K cząsteczek. "Cube surfer" się nie umywa do implementacji Kevina Dietricha - wykonał kawał dobrej roboty; kod jest szybki i forma modyfikatora daje sporo dodatkowych możliwości.

VDB2.gif

Edited by alex3d

Share this post


Link to post
Share on other sites
"Cube surfer" się nie umywa do implementacji Kevina Dietricha - wykonał kawał dobrej roboty; kod jest szybki i forma modyfikatora daje sporo dodatkowych możliwości.

Wolę jednak uściślić to co piszesz. Cube surfer to kawał roboty, a Kevin Dietrich nie wiele miał do zrobienia. Z cube surfer było masę roboty i złych założeń jak pisanie w powolnym pythonie, pisanie wszystko od zera (oni nie korzystają z OpenVDB) i efekt nie jest najlepszy. Kevin zrobił odwrotnie. Zamiast wykonywać kawał roboty wykorzystał gotowy kod (i to OpenVDB zawdzięczamy wydajność i możliwości, a nie Kevinowi), i tylko podpiął pod Blendera już gotowy napisany przez pracowników Dreamworksa kod.

Podsumowując "kawał dobrej roboty" tu nie za bardzo pasuje, bo mamy tu do czynienia z dobrą robotą, ale bardzo małą w myśl zasady pracuj mądrze nie ciężko (cube surfer to kawał roboty... tylko, że niezbyt mądrej ;p).

 

PS. Martwi mnie jednak rozwój OpenVDB przez Dreamworks... po zamknięciu Dreamworks.

Share this post


Link to post
Share on other sites

@Skoti rozumiem zamysł Twojego posta, ale szkoda czasu na taką pustą dialektykę. "Kawał dobrej roboty" pasuje wyśmienicie do implementacji jaką wykonał Kevin Dietrich. To "podpięcie" wcale nie jest taką prostą sprawą jak Ci się wydaje - OpenVDB to obszerna biblioteka. Pyroevil to bardzo dobry developer i go cenię, ale napisał skrypt (jeżeli porównujemy to ze standardami w branży), którego praktyczne zastosowanie będzie bardzo ograniczone i trafi do szuflady tak jak wiele mu podobnych:

 

Mesh from particles (metaball-based add-on)

PFluid Tools (metaballs-based add-on)

MSMesher (OpenVDB-based add-on)

Particle Surfacer (WIP MC-based add-on)

Polygonizer for particles (WIP MC-based modifier; patch for Blender 2.60 available)

 

Można tym co najwyżej zrobić gluta takiego jak od lat za pomocą fluidów.

 

Natomiast zainicjował temat meshera w blenderze i zrobił skuteczny pressing na innych developerów, którzy pewnie przetrą sobie szlak i później będą szukać pracy jako TD. Liczy się efekt i jakość, dobre chęci nie wystarczą. Z mojego punktu widzenia jest to przełom i otwiera blenderowi kilka opcji więcej z zakresu VFX, natomiast paradoksalnie po zaimplementowaniu OpenVDB większym ograniczeniem w symulacjach będą: blenderowy particle system i wydajność viewportu plus jeszcze parę innych kwestii.

Share this post


Link to post
Share on other sites
To "podpięcie" wcale nie jest taką prostą sprawą jak Ci się wydaje - OpenVDB to obszerna biblioteka.

OpenVDB to bardzo obszerna biblioteka, ale nie ma z nią Kevin nic wspólnego. To co on zrobił to było stosunkowo proste - OpenVDB to obszerna biblioteka, ale z bardzo prostym i dobrze udokumentowanym API. Jednak źle mnie zrozumiałeś... to bardzo dobrze, że wybrał łatwą drogę prowadzącą do najlepszego efektu i rozwoju tej części blendera zupełnie niezależnie (poprawki w OpenVDB poprawiają blendera, bez wkładu ludzi pracujących dla BF). Tak właśnie powinno się robić (czytaj pracować mądrze, a nie ciężko, jak w wypadku "Cube surfer" - wykonano tu wielokrotnie więcej pracy, a ta praca jest jedynie stratą czasu).

Share this post


Link to post
Share on other sites

Spoko, czyli co do tego się obaj zgadzamy. Jasne, że implementacja jest łatwiejsza niż pisanie czegoś swojego, ale nie ma co deprecjonować pracy Dietricha, bo ogarnięcie myśli takiego łebstera jak Ken Museth, siedzącego w tym przeszło 20 lat wymaga jednak pojęcia tematu. To jest ciekawe i fajne, że deweloperzy tacy jak np. Matt Ebb, którzy mają już styczność z tą wysoką półką w branży, jednak lubią coś tam sobie napisać do blendera. Otwarty kod jednak kusi :)

Share this post


Link to post
Share on other sites
Spoko, czyli co do tego się obaj zgadzamy. Jasne, że implementacja jest łatwiejsza niż pisanie czegoś swojego, ale nie ma co deprecjonować pracy Dietricha, bo ogarnięcie myśli takiego łebstera jak Ken Museth, siedzącego w tym przeszło 20 lat wymaga jednak pojęcia tematu.

Nie deprecjonuję jego pracy, a uważam ją za ważniejszą dla blendera niż marnowanie czasu na projektowanie własnego rozwiązania. Jednak nie zamierzam przekłamywać ile pracy wymaga jedno, a ile drugie (praca Kevina jest ważniejsza, a przy okazji w porównaniu banalnie prosta). Co do reszty to mocno przesadzasz. Nie potrzeba najmniejszego pojęcia. Przykładowo każdy dzieciak potrafi wykorzystać API Bullet i dodać jego obsługę do swojego silniczka, nawet gdy nie ma najmniejszego pojęcia o fizyce i nie potrzebuje tego, ani ogarniać myśli Erwina Coumansa czyli ikony silników fizycznych (Havok/Bullet). OpenVDB ma bardzo proste API i ogólnie implementacja polega na wydaniu odpowiednich poleceń. Tak w skrócie kod Kevina polega na wywołaniu funkcji zrób grida, dodaj voxele (cząsteczki), zrób z tego siatkę, zastosuj filtr (każdy ma ofc odpowiednie parametry, ale to jakie parametry mają być jest pozostawiane grafikowi, który musi te parametry ustawić) i nie musi mieć nawet pojęcia jak to się dzieje - to już robi OpenVDB, a wiedza jak to robi nie jest niezbędna (jest potrzebna mniej niż grafikowi, który później używa).

 

Nie byłbym sobą, gdybym nie poprawił rażące mnie stwierdzenie "implementacja jest łatwiejsza niż pisanie czegoś swojego". Implementacja też pisanie czegoś swojego (wręcz głównie ;p). Już prędzej "napisanie wsparcia dla API gotowej implementacji (w tym wypadku OpenVDB) jest łatwiejsze niż zaprojektowanie i zaimplementowanie własnego rozwiązania."

Share this post


Link to post
Share on other sites
Nie byłbym sobą, gdybym nie poprawił rażące mnie stwierdzenie "implementacja jest łatwiejsza niż pisanie czegoś swojego".

 

@Skoti, haha Ty tak serio:)? Jak już w tak krytycznym tonie "Wujka Dobra Rada", to lepiej brzmi (bardziej dosadnie) moim skromnym zdaniem "nie poprawił rażącego mnie stwierdzenia" albo "nie poprawił rażące mnie stwierdzenia" albo postawiłbym przecinek przed rażące :)

 

http://www.youtube.com/watch?v=E9JoOh9fBR0

 

Ok, problem w tym, że popełniasz błędy logiczne na poziomie językowym w tej dyspucie, stawiając mylne tezy i uparcie przypisując je swojemu rozmówcy, już nie mówię o jakieś bardziej wnikliwej wykładni/analizie posta.

 

Otóż przywołany termin "implementacja" ma szersze znaczenie niż to stosowane w informatyce, w naukach prawnych używamy go jako wdrożenia, wprowadzania w życie [ang. "implementation", łac. "implere"] i to miałem na myśli: "wdrożenie istniejącego rozwiązania jest łatwiejsze niż pisanie czegoś własnego". Co do reszty to przemilczę, bo szkoda mi czasu :) No to masz jeszcze jeden pretekst, żeby coś zacytować ze mnie :)

Już prędzej "napisanie wsparcia dla API gotowej implementacji (w tym wypadku OpenVDB) jest łatwiejsze niż zaprojektowanie i zaimplementowanie własnego rozwiązania."

 

To jest wspaniała rada :) Hura! :)

Edited by alex3d

Share this post


Link to post
Share on other sites
Otóż przywołany termin "implementacja" ma szersze znaczenie niż to stosowane w informatyce, w naukach prawnych używamy go jako wdrożenia, wprowadzania w życie [ang. "implementation", łac. "implere"] i to miałem na myśli: "wdrożenie istniejącego rozwiązania jest łatwiejsze niż pisanie czegoś własnego". Co do reszty to przemilczę, bo szkoda mi czasu :) No to masz jeszcze jeden pretekst, żeby coś zacytować ze mnie :)

Termin implementacja ma znaczenie powszechne. Jednak my w tym konkretnym wypadku mówimy nie tyle nawet o informatyce, a o programowaniu. Implementacja w tym wypadku jako wdrożenie projektu poprzez zaprogramowanie go (implementację zaprojektowanych algorytmów i struktur danych) jest stosunkowo jednoznaczne, a wykorzystanie api gotowej implementacji OpenVDP znacznie mniej do tego sformułowania pasuje. Jednak jeśli już mówisz o naukach prawnych to jest bardzo dobra analogia. Implementacją prawa zajmują się politycy tworząc to prawo. Wykorzystaniem tego prawa już prawnicy odwołując się do tego prawa (API).

Share this post


Link to post
Share on other sites
Przykładowo każdy dzieciak potrafi wykorzystać API Bullet i dodać jego obsługę do swojego silniczka

 

Jesli juz to "byle" ale na pewno nie "kazdy" ;)

 

Kurde, serio nic osobistego Skoti, ale juz ktorys raz z rzedu zastanawiam sie dlaczego (skoro posiadasz konkretna wiedze i chyba Blender nie jest Ci jakos obcy szczegolnie ani nie jestes jego wrogiem) nie pomozesz w jego rozwoju.

Piszesz zawsze odpowiedzi ze "szkoda czasu", ze nie zgadzasz sie z tym czy owym w fundacji... No ale produkujesz tu kilometry tekstu - nie wnikam czy masz racje czy nie ale czas niechybnie tracisz. 10% tego tekstu przelana na ilosc linijek kodu i sam bys z Blendera przerobil :D I nie pisze tego zlosliwie - od tego jest forum, zeby sobie pogadac. Ale fajnie jakbys dorzucil sie z kodem do Blendera.. A moze juz cos kiedys zrobiles/robisz?

Share this post


Link to post
Share on other sites

Skoti boi się zarażenia giepeelem, nie kojarzysz? W związku z czym może tylko... "recenzować" pracę innych ;-)

Share this post


Link to post
Share on other sites
skoro posiadasz konkretna wiedze i chyba Blender nie jest Ci jakos obcy szczegolnie ani nie jestes jego wrogiem

Blendera lubię od strony użytkownika, bo tu jest super. Od strony kodu i licencji to jest sieczka. Kod core blendera do przepisania praktycznie od zera z C do C++ jest planowany na 3.0 i może wtedy po refraktoryzacji api będzie się przyjemnie dla blendera pisać. Jednak dalej pozostanie kwestia wirusologicznej licencji.

 

Piszesz zawsze odpowiedzi ze "szkoda czasu", ze nie zgadzasz sie z tym czy owym w fundacji... No ale produkujesz tu kilometry tekstu - nie wnikam czy masz racje czy nie ale czas niechybnie tracisz.

Ta strata czasu już by pozostała - jest ona robiona w czasie rozluźnienia od programowania podczas przeglądu internetowej prasy. Zaangażowanie się w blendera nie wyparłoby tego czasu, ale czas na inne rzeczy.

 

10% tego tekstu przelana na ilosc linijek kodu i sam bys z Blendera przerobil :D

A wiesz, że ostatnio się zastanawiałem czy blenderowi nie zrobić konkurencji. Bo od strony kodu łatwiej byłoby do mojego edytora (modyfikatory już mam typu OpenSubDiv od jakiegoś czasu, czy narzędzia do animacji kości, ale brak edycji siatki) dodać narzędzia modelarskie niż naprawiać blendera, który w 20sto letnim kodzie ma śmietnik ciężki do naprawienia.

Share this post


Link to post
Share on other sites

bo to jest tak że jak zaczynali przepisywać to wszyscy hurrrrrrrra ale nikt nie przemyślał czy warto czas marnować na pierdoły które niczego nie wnoszą i tu jest problem ile to czasu czekaliśmy na Dependency Graph, cycles a jednak marnujemy czas na internala, bmesh a marnowaliśmy czas na stary system, ciągle stary viewport a nie pisać od początku w tym ogl 4, tak chyba było w tym czasie ale np wg mnie fajne sprawy związane z modelowaniem nikt nie wprowadził tylko jakieś pierdy dziwne

Share this post


Link to post
Share on other sites

Nie wszystkie moduły blendera były pisane 20 lat temu i różne moduły mają różną jakość. Pisanie edycji siatki pod b-mesha jest nieporównywalnie łatwiejsze niż przed nim. Jego wydajność nie powala, xsi czy modo spisują się lepiej, ale bardzo źle nie jest. Jak piszesz coś pod bmesha to w ogóle nie musisz sie interesować 90% kodu blendera i na pewno żadną częścią która pamięta lata 90.

Share this post


Link to post
Share on other sites
Nie wszystkie moduły blendera były pisane 20 lat temu i różne moduły mają różną jakość. Pisanie edycji siatki pod b-mesha jest nieporównywalnie łatwiejsze niż przed nim. Jego wydajność nie powala, xsi czy modo spisują się lepiej, ale bardzo źle nie jest. Jak piszesz coś pod bmesha to w ogóle nie musisz sie interesować 90% kodu blendera i na pewno żadną częścią która pamięta lata 90.

B-mesh jest pisany zgodnie z zaleceniami i wzorcami projektowymi jak 20 lat temu (tak samo jak najstarsze elementy blendera) i nic tu się nie poprawiło. Są jedynie dwa moduły które się wyróżniają olewaniem starego stylu pisania: Game Engine i Cycles (twórca Bullet Erwin Coumans (on rozpoczynał projekt Blender Game Engine w 2000 roku), jak i Brecht van Lommel nie przejmowali się tym jaki blender jest i postanowili zrobić projekty nowocześnie) - cała reszta projektów jest pisana w sposób jaki była by pisana 20 lat temu (w tym bmesh).

Co do Erwina Coumansa to żałował on tego, że BGE jest na GPL i przez tą licencje uznał, że nie ma co go rozwijać (i zrobił inny silniczek do prototypowania gier czyli gamekit na licencji BSD), a Brecht napisał Cycles na licencji BSD, a nie GPL (kod Cycles żyje własnym życiem jako osobny projekt na dobrej licencji).

 

ciągle stary viewport a nie pisać od początku w tym ogl 4

Wygląda na to, że jeszcze długo nie będzie GL4... według roadmapy teraz chcą zrobić tylko OpenGL 2.1 jako minimum, znakiem zapytania jest w 2.8x napisanie obsługi GL3 w viewporcie, a GL4 nie jest nawet uwzględniony w Blender 3.0, który ma być przepisywany cały.

Share this post


Link to post
Share on other sites
Wygląda na to, że jeszcze długo nie będzie GL4... według roadmapy teraz chcą zrobić tylko OpenGL 2.1 jako minimum, znakiem zapytania jest w 2.8x napisanie obsługi GL3 w viewporcie, a GL4 nie jest nawet uwzględniony w Blender 3.0, który ma być przepisywany cały.
Da fuk? Nie ma żadnych takich informacji. Nie ma żadnej roadmapy mówiącej co i kiedy będzie implementowane. Opierasz to wyłącznie o wróżenie z fusów i chęci siania FUDu.

 

Goście z BF zapowiadają że jako minimum będą korzystali z OGL w wersji X. Ty piszesz w taki sposób jakby korzystali z wersji X jako maksimum. Zupełnie bezpodstawne.

Edited by Monio

Share this post


Link to post
Share on other sites
Da fuk? Nie ma żadnych takich informacji. Nie ma żadnej roadmapy mówiącej co i kiedy będzie implementowane. Opierasz to wyłącznie o wróżenie z fusów i chęci siania FUDu.

 

Goście z BF zapowiadają że jako minimum będą korzystali z OGL w wersji X. Ty piszesz w taki sposób jakby korzystali z wersji X jako maksimum. Zupełnie bezpodstawne.

Mówię o roadmapie może już nie najmłodszej (połowa 2013), ale najbardziej aktualnej i stosunkowo dokładnie realizowanej. Ofc możesz nazywać opieranie się na oficjalnej roadmapie z oficjalnej strony jako wróżenie z fusów i sianie FUDu... to już twoja sprawa

http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/

Share this post


Link to post
Share on other sites

Czytanie ze zrozumieniem niebardzo. Siejesz FUD pisząc jakoby viewport blendera nie miał jeszcze długo obsługiwać OGL3 albo 4. Nie ma na ten temat absolutnie żadnych informacji!

Możliwe "że jeszcze długo nie będzie OGLa4" jako MINIMUM wymagane do uruchomienia aplikacji. To akurat masz jak w banku. Viewporty wszystkich ważniejszych softów do grafiki korzystają dzisiaj w najlepszym wypadku z OGL2.1 jako wymaganie minimalne. Tylko że minimalne zasoby sprzętowe potrzebne do uruchomienia aplikacji to rzecz zupełnie osobna od tego w jakim stopniu viewport będzie korzystał z dobrodziejstw nowszych wersji OGLa.

 

Ja bym chciał żeby podbili minimum do 3.x ze względu na stratę zasobów i nikły promil osób które mogą na tym ucierpieć. I tu jest sendo sprawy bo w przypadku 3.x będzie to promil userów ale już w przypadku 4.x odcięliby się od paru procent userbase.

Share this post


Link to post
Share on other sites
Czytanie ze zrozumieniem niebardzo.

Widzę, więc spróbuję napisać prosto.

 

Siejesz FUD pisząc jakoby viewport blendera nie miał jeszcze długo obsługiwać OGL3 albo 4.

Piszę tylko, że na to wygląda i jeśli tego nie widzisz to uargumentuje to. Soc-2014-viewport_fx jest projektem obecnie jedynym prowadzonym w ramach viewportu. Jego celem jest jedynie wywalenie starych rzeczy przed OpenGL 2.1 i nie wykracza poza jego możliwości (dalej nie ma mowy nawet o instancigu itp - możesz sprawdzić, bo źródła są dostępne). Jedyne plany na temat wprowadzenia obsługi API OpenGL 3+ to ta roadmapa z znaczącym znakiem zapytania (czyli dopiero następca projektu viewport_fx), która sugeruje, że dodanie możliwości OpenGL 3 może będzie możliwe w okolicy Blender 2.8x (nie jako minimum, a jako wsparcie jako takie).

 

Viewporty wszystkich ważniejszych softów do grafiki korzystają dzisiaj w najlepszym wypadku z OGL2.1 jako wymaganie minimalne. Tylko że minimalne zasoby sprzętowe potrzebne do uruchomienia aplikacji to rzecz zupełnie osobna od tego w jakim stopniu viewport będzie korzystał z dobrodziejstw nowszych wersji OGLa.

Hmmm Mudbox wymaga OpenGL 3.x jeśli dobrze pamiętam, Maya olała kompatybilność i napisała nowy viewport 2.0, który jeśli dobrze pamiętam wymaga GL3+ (jako failback zostawili nierozwijany viewport 1, ale nowy już wymaga wyżej). Ofc są takie jak Softimage, które dalej są kompatybilne z OpenGL 1.5 i rozszerzeniami obsługują nowe GPU... problem w tym, że blender do tej pory łącznie z mającym dołączyć do niego viewportfx tego nie robi (to dopiero pole do popisu na kolejne lata rozwoju blendera, a obecnie jedynie usunięto starocie).

 

Ja bym chciał żeby podbili minimum do 3.x ze względu na stratę zasobów i nikły promil osób które mogą na tym ucierpieć. I tu jest sendo sprawy bo w przypadku 3.x będzie to promil userów ale już w przypadku 4.x odcięliby się od paru procent userbase.

Ja też. Tylko zauważ, że w wypadku blendera to strata zasobów w tym wypadku to długi okres czasu - od kilku lat są prowadzone projekty tylko w sprawie uporządkowania api i usunięcia staroci z viewportu, czego zwięczenie ma się pojawić w 2.7x (projekt soc-2014-viewport_fx) i będzie można zacząć myśleć o wsparciu OpenGL 3+ (jako rozszerzeniach do minimalnego 2.1). Dodanie obsługi dla OpenGL 3.x w 2.8x to mega szybkie tępo jak na rozwój viewportu w blenderze. Obsługa OpenGL 4.x puki co nawet planowana nie jest.

Share this post


Link to post
Share on other sites

C-C-C-COMBO BREAKER! ;)

 

Andrew zaczyna sprzedawac (za - trzeba przyznac - niezbyt wygorowana cene) swoj pack roznych trawek. Moim zdaniem dopracowal to na maksa - ilosc detalu na prawde spora. Za niecale $60 ogromna oszczednosc czasu, duza konfigurowalnosc i efekt pierwsza klasa.

 

Share this post


Link to post
Share on other sites
Jego celem jest jedynie wywalenie starych rzeczy przed OpenGL 2.1 i nie wykracza poza jego możliwości

O Chryste... Oczywiście że NIE jest to cel viewportFX! To że przeskakujemy na OGL2.1 to bonus który dostajemy przy totalnym refactoringu API renderingu. Nie masz kompletnie pojęcia czego dotyczy ten projekt, więc może po postu się nie wypowiadaj?

http://wiki.blender.org/index.php/User:Jwilkins

 

od kilku lat są prowadzone projekty tylko w sprawie uporządkowania api i usunięcia staroci z viewportu (...) Dodanie obsługi dla OpenGL 3.x w 2.8x to mega szybkie tępo jak na rozwój viewportu w blenderze
Pamiętam jak kiedyś pisałeś że viewportFX to projekt jednego studenciaka nie powiązanego z BF. Teraz opisujesz to jakby pracowała nad nim cała fundacja i według tego estymujesz jak bardzo wolno będzie się rozwijał viewport blendera. FUD na maksa.

Share this post


Link to post
Share on other sites
O Chryste... Oczywiście że NIE jest to cel viewportFX! To że przeskakujemy na OGL2.1 to bonus który dostajemy przy totalnym refactoringu API renderingu. Nie masz kompletnie pojęcia czego dotyczy ten projekt, więc może po postu się nie wypowiadaj?

http://wiki.blender.org/index.php/User:Jwilkins

Totalny refraktoring jest potrzebny do usunięcia starych elementów pamiętających jeszcze OpenGL 1.0. Fajnie, że podałeś link potwierdzający moje słowa i że na tym się skupia (wywalenie staroci (niestety też, dzięki temu linkowi dowiedziałem się, że celem jest marnowanie dodatkowo czasu na implementacje staroci z OpenGL 1.0 za pomocą emulowania ich w nowym, jak glBegin/End za pomocą VBO (aby dalej skrypty mogły używać nieefektywnego sposobu rysowania))). Jedyne co w tym projekcie pocieszające to właśnie refractoring i oczyszczenie kodu co da możliwość w przyszłości dodawania możliwości OpenGL 3.x i wyżej, ale to już nie jest celem tego projektu na teraz - celem jest jedynie danie możliwości, żeby za następne kilka lat to wykorzystać.

Ja jednak podam Ci poważniejszy link czyli kod:

https://developer.blender.org/diffusion/B/browse/soc-2014-viewport_fx/

Niestety tam nie jest nawet rozpoczęte wsparcie dla jakichkolwiek możliwości wyżej niż OpenGL 2.1.

 

Pamiętam jak kiedyś pisałeś że viewportFX to projekt jednego studenciaka nie powiązanego z BF. Teraz opisujesz to jakby pracowała nad nim cała fundacja i według tego estymujesz jak bardzo wolno będzie się rozwijał viewport blendera. FUD na maksa.

To był i jest projekt jednoosobowy. Nie pisze, że pracuje nad nim cała fundacja... cała fundacja olała viewport i czeka na efekty pracy tej jednej osoby. Wcześniej taka sytuacja była przy BMeshu, który od 2007 roku powstawał jeszcze dla 2.4x wszedł dopiero w 2012 roku w mękach i raczej rozczarowująca.

Share this post


Link to post
Share on other sites

A Blender, za nic sobie majac to jak z nim zle, jak wszystko jest rozczarowujace, zle prowadzone, przestarzale i na wirusowej licencji - wciaz sie rozwija :D

I zeby nie bylo - tez mialem i miewam watpliwosci co do wyborow fundacji (jak ostatnio z tym OpenGLem 2.1) ale raz po raz siadajac do nowej wersji widze ze na szczescie niepotrzebnie sie obawialem. Chlopaki daja rade - po cholere ten defetyzm?

Edited by Nezumi

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy