Blender - NEWS oraz dyskusje

Ja dobiegam czterdziestki i o ile w wielu przypadkach na prawde nastapila kosmiczna zmiana (na przyklad pojemnosc nosnikow - kiedys przeliczylem ile dyskietek potrzeba bylo by zmiescic co dzis mamy w breloczku do kluczy :D. Albo predkosc procesorow, miniaturyzacja czy chociazby internet) to jakos zauwazam postepujace oglupienie. Myslalby kto, ze majac natychmiastowy dostep do niemal nieograniczonej WIEDZY (czasami ciezko ja zweryfikowac, ale jednak) ludzie jako ogol zaczna z tego korzystac i ogolny intelektualny poziom wzrosnie. Tymczasem zamiast rozwijac swoje zainteresowania, dowiadywac sie nowych rzeczy, chlonac wiadomosci z zakatkow swiata o ktorych nie mielismy pojecia ze istnieja co mamy? Zdjecia kotkow, "viral videos" o tym jak sobie ktos w tylek ognie sztuczne wsadzil i co z tego wyniknelo, mamy bezmyslne mazianie palcem po ekraniku w obsesyjnej checi sprawdzenia co 2 minuty ile lajkow ma juz zdjecie naszego posilku i tak dalej. Wiem, ze nie wszyscy tak robia, ale nie potrafie oprzec sie wrazeniu, ktore swietnie ujal Lem, kiedy powiedzial "nie wiedzialem ze na swiecie jest tylu idiotow dopoki nie poznalem internetu"...

Ostatnio odwiedzilem ogromne akwarium - na moich oczach osmiornica zmieniala kolory i ksztalty, meduzy majestatycznie unosily sie w wodzie jak stworzenia nie z tego swiata, mielismy wcale sporego rekina na wyciagniecie reki i moglem "przybic piatke" z plaszczka. Niesamowite. Niemal wszyscy ludzie - a przynajmniej zdecydowana wiekszosc - ogladali to wszystko na ekranikach swoich telefonow, mimo, ze tam byli. Skretynienie totalne jak dla mnie. I niezaprzeczalnie choroba masowa. Pewien pan oburzyl sie, kiedy mu powiedzialem, ze przyszedlem tu poogladac osmiornice a nie jego i-pada, ktory raczyl wetknac mi przed nos zaslaniajac wszystko bo najwidoczniej poczul sie fotografem...

Tak ze jasne, pelna zgoda co do niezaprzeczalnego postepu technologicznego. Tyle, ze w jakis magiczny sposob okupionego proporcjonalnym zidioceniem.

Sorry za offtop ale coś się ruszyło w temacie asset browsera do blendka. ;D

https://mont29.wordpress.com/2015/01/14/assets-filebrowser-preliminary-work-experimental-build-i/

A wracając do tematu OpenGL, znacie jakiś przykład gdzie można zobaczyć czym wizualnie różnią się kolejne wersje? Poczytałem sobie pobieżnie na wiki, ale duża część ficzerów kompletnie nic mi nie mówi. Patrząc na ankietę z blenderartist, nie sądzę żeby zdecydowali się na wyższą wersję niż zakładaną 2.1. Odcięliby prawie 10% userów (pomijam kwestię jacy to userzy). Skok z wersji 1 na 2.1 jest dla mnie widoczny gołym okiem. Do zrozumienia niuansów między wyższymi wersjami przyda się jakieś wyjaśnienie.

i znowu widać jak mniejszość terroryzuje większość. Widać gołym okiem że ludzie od 2.1 to ludzie którzy kupili kompa i nigdy nic z nim nie robili i tak już im zostało i dla nich robić ?. A co oni takiego robią ? jakieś wielkie rzeczy, każdy narzeka na wydajność i tak jak wyżej pisano nawet u nas idzie kupić znośną kartę a jak już chcesz się zająć grafiką to jednak trzeba w coś zainwestować. Nawet na stronie apple nigdzie nie widać wzmianek o 2.1 najstarsza to 3.3 TU //// zaczyna się kolejne wciskanie kaktusa nie tam gdzie trzeba, może tak przeskoczmy z 1 na 1.2 OMG jaki przeskok normalnie skok technologiczny jak stąd do venus :mad:

Odcięliby prawie 10% userów (pomijam kwestię jacy to userzy).

Z czego pewnie 5% użytkownicy MacOS ze sprzętem obsługującym nowe wersje (tylko blender pokazuje tam 2.1, bo taki tworzy kontekst... gdy blender stworzy kontekst 3.3 to będzie działać i taki zobaczysz), a 3-4% to osoby po prostu, ze starymi sterownikami (do sprzętu wspierającego 3.3), bo nie mieli takiej potrzeby - gdy będzie trzeba to zainstalują.

Skok z wersji 1 na 2.1 jest dla mnie widoczny gołym okiem. Do zrozumienia niuansów między wyższymi wersjami przyda się jakieś wyjaśnienie.

Jaki skok? Wersji 2.1 Blender używa od lat. Teraz po prostu postanowili wywalić kod dla starszych wersji - nie jest to żaden skok, a po prostu oczyszczenie kodu ze staroci.

jeśli to jest 2.1 to dziękuję za taki postęp

jeśli to jest 2.1 to dziękuję za taki postęp

OpenGL 2.1 wprowadził tak na dobrą sprawę tylko GLSL 1.2 i względem starszych OpenGL niż 1.5 gwarantuje VBO (1.5 gwarantuje, a 2.1 dziedziczy to). Blender od początku obsługi GLSL obsługuje wersje 1.2 (od jakiegoś czasu GE obsługuje 1.3 jeśli dostępne).

To oznacza jedynie to, że będzie można wywalić kod dla kart bez shaderów (wykorzystujący multitexturing jeszcze na fixed pipeline), i daje możliwość wyrzucenia kodu dla kart nie obsługujących VBO (do teraz VBO było opcjonalne, a jeśli nie było to był kod, dla zabytkowych kart z początku lat 90 ;p). OpenGL 2.1 ogólnie nic nie dodaje do tego co blender obsługiwał... po prostu odejmuje konieczność dbania o karty starsze (IMHO stanowczo za nisko ten limit minimum ustanowiony, bo 2.1 już dziś praktycznie nie istnieje).

Czyli sugerujesz że zmiana na OpenGL 2.1 w rezultacie nie przyniesie zupełnie nic? Może palnę jakąś zupełną głupotę, ale wydaje mi się, że jeśli już viewport jest oparty o 2.1 to nie wykorzystuje jego możliwości. Nawet gdyby materiałom (dla viewportu) można było indywidualnie przypisywać shadery, które są dostępne przez MatCap, to już byłoby wg mnie dużo ładniej. Jeśli coś mylę od strony technicznej, to proszę mnie poprawić ;) I od razu zaznaczam, że nie jestem za ograniczeniem openGLa, tylko chcę się dowiedzieć ile na tych zmianach można zyskać/stracić. Ile konkretnie, dałoby podniesienie poprzeczki wyżej, z punktu widzenia użytkownika?

i tak, dalej moja głowa tego nie pojmuje na uj marnować czas i zasoby na taki znikomy postęp

To w ogóle jakiś skok będzie?

Czy będzie się dalo zaimplementować faktycznie dobrze funkcje z nowszych kart? (bez jakiś ogromnych awykonalnych nakładów)

Czy to naprawdę będzie zmiana z furmanki na traktor?

I ile dałby faktyczny skok do 4.x. Tzn ilu krotny byłby potencjalny wzrost performanceu i konkretnie jakie featury jak tesselacja czy coś.

Rozumiem, że BF chcą wspierać jak najwięcej ludzi, ale chyba nie zdają sobie sprawy, że jeśli już ktoś faktycznie nie ma 30$ na wymianę karty na jakąkolwiek nowszą. To przecież możne spokojnie pracować na starej wersji, a nie koniecznie najnowszej dla featursów z których i tak nie skorzysta..

Fajne :)

Czyli sugerujesz że zmiana na OpenGL 2.1 w rezultacie nie przyniesie zupełnie nic? Może palnę jakąś zupełną głupotę, ale wydaje mi się, że jeśli już viewport jest oparty o 2.1 to nie wykorzystuje jego możliwości.

Niestety OpenGL 2.1 większych możliwości nie ma.

Nawet gdyby materiałom (dla viewportu) można było indywidualnie przypisywać shadery, które są dostępne przez MatCap, to już byłoby wg mnie dużo ładniej.

To o czym mówisz to nie możliwości OpenGL, a po prostu rzecz do zrobienia przez pracowników BF. Problem w tym, że właśnie obsługa dużej ilości różnych API od staroci z 2.1 po nowoczesne API sprawi, że tego czasu nie będzie na nic takiego (ba nawet na nowoczesne api zapewne braknie pary).

PS. Po co ci MatCapy gdy możesz sobie sam je zrobić z materiałami blendera i cieniowaniem viewportu ustawionym na GLSL? (załącznik)

I od razu zaznaczam, że nie jestem za ograniczeniem openGLa, tylko chcę się dowiedzieć ile na tych zmianach można zyskać/stracić. Ile konkretnie, dałoby podniesienie poprzeczki wyżej, z punktu widzenia użytkownika?

To nie działa tak, że jest to ograniczenie... to jest strata czasu. To, że minimum będą wspierać 2.1, nie oznacza, że nie mogą sprawdzić czy karta obsługuje nowsze i tamte wspierać inaczej. Problem polega na tym, że praktycznie wszystko trzeba pisać kilka razy.

Co zyskiwane jest w nowych wersjach?

3.0:

- szybki rendering do tekstury (przez ograniczenie się do 2.1 jako minumum muszą sprawdzać czy jest FBO obsługiwane i jeśli nie to robić inaczej),

- Texture Array - tablice tekstur, które powodują, że blender nie musi bindować tekstur na każdy obiekt osobno, a są trzymane w tablicy, co zmniejsza narzut na CPU... niestety w wypadku 2.1 trzeba wspierać bindowanie per object

- Transform Feedback - obliczenia na siatce na GPU, które przez CPU są odczytywane. Daje to olbrzymie przyspieszenie przykładowo przy modyfikatorach - zamiast się męczyć na CPU z modyfikacją siatki, znacznie lepszą opcją jest zrobienie tego na GPU przez Transform Feedback... ofc tylko ze względu na to, że ograniczenie jest do 2.1 trzeba kod tych modyfikatorów powielać... jeśli jest TF to wykorzystać kod na GPU, jeśli nie to liczyć powoli na CPU.

3.1:

- Instancing (i tak - obecnie blender obywa się bez niego! Tylko softowo instancing jest po stronie CPU, ale na GPU już rysuje wszystko osobno).

- Uniform Buffer Object - coś jak VBO, tylko dla uniformów (zmienne przekazywane do shaderów). Pozwala zmniejszyć ilość bindowania i nie trzeba danych przesyłać - odpowiednie dane dla obiektu już są na GPU tylko się wskazuje gdzie.

3.3

- occlusion query - odpytywanie GPU czy obiekt jest zasłonięty i jest sens go rysować

- instanced arrays pomagają lepiej wykorzystać instancing

Podsumowując tu wszędzie zyskujesz wydajność*i możliwość napisania tylko raz, a nie wiele razy. To wszystko to tak naprawdę podniesienie tylko o jeden szczebelek, bo wszystkie karty Nvidii (od serii 8k z 2006r) czy AMD (2k z 2007r.), które wspierają 3.0 wspierają i 3.3 (wystarczy zaktualizować sterownik). Czas zaoszczędzony zarówno na wydajności jak i na pracy nad wspieraniem wielu ścieżek renderingu można wykorzystać na pracę nad lepszymi możliwościami (bo jest kiedy i jest jak, bo wydajność programu pozwala na dołożenie trochę do niego).

Seria 4.x przynosi już zupełnie kosmos w wypadku OpenGL (w tym typowo dla programów jak Blender z viewport_array - czyli przykładowo 4x okienka (viewporty) z siatką widzimy i za jednym przetwarzaniem wierzchołków renderujemy do wszystkich 4rech, zamiast 4x przetwarzać wierzchołki dla każdego z osobna), ale to powinno być już jako alternatywna ścieżka, a jako minimum 3.3. Ofc opisałem tylko część z rzeczy dodanych w kolejnych wersjach (w tym nie opisałem bardzo ważnej i dużej aktualizacji 3.2 (z geometry sharedami, które pozwoli na więcej włosów/cząsteczek w takim samym czasie)), aby tylko tak na szybko pokazać ile mnij roboty byłoby ograniczając się do 3.3.

Może tak. Sam ogl2.1 nie jest problemem. Mogą wykryć karty z nowszymi wersjami i dla nich przygotować specjalne ficzery i stworzyć inny kontekst ogl. Szczególnie teraz bedzie to łatwiejsze z viewportFx.

Problemem jest to że jest spora szansa że w ogóle nie będą pisać rzeczy w nowym ogl bo stwierdzą że 2.1 "wystarczy", albo utrzymanie 2 gałęzi zupełnie innego kodu będzie za trudne. Jakby przeszli na (i tak starego) ogla3.3 to nie musieloby się zastanawiać nad kompatybilnością ficzerów z 2.1 w ogóle.

Dzięki Skoti, na takie wyjaśnienie liczyłem :) Teraz zupełnie rozumiem Twoje zażenowanie związane z tą "zmianą" openGLa. Mam nadzieję, że ktoś w BF podobnie uświadomi resztę załogi i podejmą słuszne wnioski.

PS. Po co ci MatCapy gdy możesz sobie sam je zrobić z materiałami blendera i cieniowaniem viewportu ustawionym na GLSL? (załącznik)

A można to zrobić z wybranym Cycles Render?

A można to zrobić z wybranym Cycles Render?

Nie, bo nikt nie ma czasu napisać shaderów odpowiadających tym materiałom (zaimplementowanie shaderów Cycles w GLSL). Ale ofc jest to wykonalne, nawet z OpenGL 1.x i shaderami ASM, a samo ograniczenie się do 2.1 tu niczego nie poprawi.

Animacja testowa z gooseberry. Bardzo podoba mi się jakość z jaką świeci cycles - shader/oświetlenie włosów wygląda rewelacyjnie. Łatwość budowania shaderów i eleastyczność tego silnika są jednak niesamowite i gdzieś jednak zmuszają do zastanowienia z jakim innym silnikiem można cyclesa porównywać (jeśli chodzi o renderowanie animacji), a później do stwierdzenia, że to jednak taki mniejszy brat arnolda, poza paroma funkcjami, o braku których, ciągle tutaj wspominamy, skalowalności, optymalizacji, displacementu. Widać lekki flickering na włosach i na marynarce, ale to bardziej wina zmian/błędów animatora, które wyszły w trakcie renderingu niż cyclesa.

I kroczek w kierunku assetów: https://mont29.wordpress.com/2015/01/14/assets-filebrowser-preliminary-work-experimental-build-i/

Ściągnąłem build i pomysł na przeglądarkę plików przy appendowaniu wygląda całkiem sensownie, natomiast stabilność jest w tej chwili kiepska, więc można wnieść sporo uwag :)

Edit: i ostatnia kwestia, meshery nabierają kształtu:

Bazujący na OpenVDB:

i CubeSurfer od pyroevil: buildy http://pyroevil.com/cubesurfer-addon-download/ i dokumentacja do ściągnięcia; zabieram się do testów :)

Hi all,

 

Here are the notes from today's 15h UTC meeting in irc.freenode.net #blendercoders.

 

1) Release targets for upcoming 2.74

 

- People noted that the proposed planning for next release was more than 2 months.

 

- We might need to reserve enough time for Multiview, Viewport, and several Gooseberry projects to be migrated. But if that's needed has to be figured out still.

 

- Everyone gets one more week to get their projects shortlisted as 2.74 targets!

 

2) Release 2.73a

 

- Meeting decided to go for an 'a' update after all. Minor but important fixes were done already.

For example: Knife bugs, Cycles has bug (black meshes on certain circumstances).

 

- Monday Sergey Sharybin and Campbell Barton will review and move over the essential fixes (and mail to this list to verify). If all goes fine, we then ask for a build on tuesday.

 

3) other projects

 

- Kevin Dietrich posted videos with the first OpenVDB particle results:

http://blenderartists.org/forum/showthread.php?357512-Dev-OpenVDB-Based-Particle-Mesher-Modifier

He'll be in touch with Campbell and Lukas Toenne, to make sure modifier designs and particle plans are well aligned.

 

Thanks,

 

-Ton-

Hi all,

 

Here are the notes from today's Blender UI meeting in irc.freenode.net,

#blenderui

 

1) Current status/Goals for 2.74

 

- Jonathan Williamson and Pawel Lyczkowski are still working on the

new keymap(s) but 2.74 is to soon. They're aiming for 2.75 instead (of

course it will be optional at first).

 

- It is still unclear how exactly we will deal with keymaps in future,

but we all agree that we shouldn't try to fit all needs with just one

keymap. Instead the proposal is to have one really minimal keymap -

easy for new users and a solid base for custom, workflow orientated

keymaps - and a bigger one like the current, but still not that

massive and much more organized.

 

- Sticky Keys patch is basically finished, review and merge should happen soon

 

- Same applies to Value Ladders (https://developer.blender.org/D760)

 

- There are a few "smaller" patches like File Browser font preview

(https://developer.blender.org/D1002) and thumbnail zooming

(https://developer.blender.org/T27830), some outliner related patches

(https://developer.blender.org/T43282), ... . They are all waiting for

review but should go into 2.74 as well

 

2) Possible goals for 2.75

To set development priorities early enough we already talked about the

goals for 2.75:

 

- Some feedback from the Gooseberry team (others are welcome as well!)

is needed for custom wireframe colors and we are also not sure how

it's going code wise, but it looks like a tangible topic for 2.75

 

- Getting some widgets from the widget project into master is also a

goal for 2.75. Julian Eisel will help Antony Riakiotakis with that (so

he can focus more on the viewport project! :) )

 

- Also goals for 2.75: User Preference tabs

(https://developer.blender.org/D667) and viewport navigation icons

(https://developer.blender.org/D584).

 

3) Other projects

- Modifier drag & drop and the 2D-widget redesign (not to confound

with the viewport widgets) are on this list

 

- We also talked about something like a "Tip of the Day" or a "First

time using Blender? Take a tour" section for the splash, but we need

coders to pick that up (both shouldn't be too hard to implement)

 

We will use the mailing list to schedule the next meeting, but it is

to be expected in the next weeks to review the status for the 2.74

release.

 

Thanks all,

 

- Julian (Severin) -

2.74 będzie super ale to co się pojawi za pół roku to będzie potęga. :D Jestem strasznie ciekaw nowej Keymapy + pies + sticky keys. Z chęcią się przestawię dla rozruszania mózgu. Fajnie jakby też odświerzyli bazowy theme, lubię zapach nowości. :)

Oby tylko dostosowali blendka również do nowszego OGLa, jedyna rzecz o którą się teraz boje.

@Monio, faktycznie sporo ciekawych opcji zapowiada się w ciągu tego roku.

Test meshera CubeSurfer. Odczucia mam takie, że trzeba poczekać na konkurencyjny projekt bazujący na OpenVDB (nie ma jeszcze builda), z racji tego, że ten ostatni będzie napisany bezpośrednio w blenderze, a nie jako addon, powinien być o wiele wydajniejszy i będzie miał więcej opcji z filtrami itd., czyli OpenVDB w prawdziwym tego słowa znaczeniu. W tym dokumencie:http://www.museth.org/Ken/Publications_files/meis2013_abstract_museth.pdf na 3 stronie (obrazek nr 2) widać jak ważne są filtry dla efektu końcowego powierzchni: CubeSurfer jest gdzieś pomiędzy 2 a 3 stadium.

Poniżej trzy proste testy, zrobiłem ich od wczoraj kilkadziesiąt, przy czym bardziej skomplikowane symulacje (falujący ocean itp.) dostają wąskie gardło i komp mi się zwiesza - zjada RAM, max zużycie procesorów i zero efektu. Do końca tygodnia potestuję na innych nastawach przy bardziej złożonych symulacjach, tj. milionach cząsteczek, zobaczymy czy CubeSurfer sobie poradzi, chociaż na pierwszy rzut oka porównując z houdinim to widzę, że sobie nie poradzi, zarówno ze skalą jak i z czasami symulacji per klatka nie mówiąc o innych aspektach solverów. CubeSurfer to raczej małe i średnie symulacje, w stylu jogurt, czekolada do reklamy niż coś o większej skali i okres przejściowy do czasu aż pojawi się OpenVDB od Kevina Dietricha lub coś jeszcze bardziej zaawansowanego.

Odczucia mam takie, że trzeba poczekać na konkurencyjny projekt bazujący na OpenVDB (nie ma jeszcze builda), z racji tego, że ten ostatni będzie napisany bezpośrednio w blenderze, a nie jako addon, powinien być o wiele wydajniejszy i będzie miał więcej opcji z filtrami itd., czyli OpenVDB w prawdziwym tego słowa znaczeniu.

Od lat mam marzenie, że zaczną wykorzystywać branżowe standardy, zamiast pisać sami wszystko. Ogólnie chętnie bym zobaczył połączenie Bullet (teraz już z liczeniem na GPU, symulacje cząsteczkowe itp.) z OpenVDB (cząsteczki wypluwane przez Bullet wrzucane jako input do OpenVDB). Czyli połączenie tak jak w Houdini czy w narzędziach Pixara/Dreamworksa.

BTW. wiedzieliście o tym, że w tym roku twórca silnika Bullet (Erwin Coumans) i twórcy OpenVDB dostali techniczne Oskary za zasługi dla branży filmowej?

http://www.oscars.org/news/21-scientific-and-technical-achievements-be-honored-academy-awardsr

Od lat mam marzenie, że zaczną wykorzystywać branżowe standardy, zamiast pisać sami wszystko.

Dostępne od dawna: OpenEXR, OpenColorIO, OpenImageIO, OSL, Bullet na CPU

Rozpoczęte projekty: OpenSubdiv, Ptex(!), Alembic (najpierw jako wewnętrzny cashe, potem jaki import/export)

Tak na pardwę z dużych branżowych standardów to brakuje właśnie OpenVDB i Bulleta na GPU. Cierpliwości. Jak będą robić zunifikowany system do symulacji PO pilocie Gooseberry to bankowo dodadzą te rzeczy. Na razie niech się skupią na Viewporcie. :)

BTW. wiedzieliście o tym, że w tym roku twórca silnika Bullet (Erwin Coumans) i twórcy OpenVDB dostali techniczne Oskary za zasługi dla branży filmowej?

http://www.oscars.org/news/21-scientific-and-technical-achievements-be-honored-academy-awardsr

@Monio: Nie do końca jest tak.

OpenImageIO to żaden standard (to zwykły studencki projekt GSoC) - to po prostu biblioteka do ładowania plików jak JPG/PNG/OpenEXR... i nie jest akurat ważne, czy z niego korzysta czy z innego rozwijanego rozwiązania jak FreeImage (różnice niewielkie - ten czyta RAWy, ten czyta tekstury w formatach IFF/Zfile). Wśród programów 3d z OpenImageIO chyba tylko blender z niego korzysta, więc taki z niego "standard" ;].

Bullet na CPU... ciężko mówić o tym, że blender go wspiera. Do wykrywania kolizji? Nie wykorzystuje. Do symulacji ciuchów? No też nie. Do Softbody? Kiedyś tak (2.4)... teraz nie. Do symulacji fluidów/dymu... no i znowu nie (dla przykładu w Houdini wszędzie tak). Bullet wykorzystuje się w blenderze tylko do brył sztywnych i gameengine (tu softbody dalej wykorzystuje bullet).

Widzę, że zaczynają stosować standardy co bardo cieszy, jednak smuci to, że idzie im to strasznie powoli i po prostu wymieniają rzeczy, które już są napisane (na które już zmarnowali czas), a i obecnie jest marnowany czas (przykładowo alembic). Przykładowo na wsparcie w Cycles formatu blenderowej wolumetryki stracono czas (który powinno się poświęcić na napisanie wsparcia dla OpenVDP (od 2012 roku od Dreamworks) lub konkurencyjnego Field3D (od 2010 roku i też twórcy z Sony dostali technicznego oskara w tym roku)), robi się teraz po latach wsparcie dla Alembic, podczas gdy jest to bardzo ograniczony bakeowany format od Sony, który praktycznie niczego nie załatwia, a nawet nie myśli się o edytowalnym pośrednim formacie jak Pixarowy USD (Universal Scene Description), który jest faktycznie potrzebny użytkownikom (bo nie oszukujmy się, że FBX jest dobrym standardem)... i co więcej wsparcie dla Alembic dostaje się gratis (Alembic jest pluginem do USD, dlatego nie ma wielkiego sensu pisanie dla niego wsparcia, gdy można je mieć z automatu) - tu IMO byłoby mądrzej zająć się czymś innym lub wykorzystać dokumentacje API, aby przygotować się do wsparcia dla SDK, gdy Pixar go wyda, wsparcie dla bullet dla wszystkiego (czytaj, aby fizyka ze sobą współpracowała, a nie jedna symulacja przeszkadzała innej) nawet w planach nie jest.

Ogólnie jest lepiej, bo już nie jest tak, że standardy swoje, blender swoje, ale dalej dobrze nie jest.

USD nie jest jeszcze dostępny w żadnym konsumenckim sofcie i nie wiadomo kiedy/ czy Pixar go wyda i nawet nie wiemy czy się przyjmie. Autodesk bankowo będzie go tępił bo to konkurent ich parszywego FBXa. Collady produkty ADSK nie potrafią poprawnie obsłużyć do dziś.

Już lepiej inwestować w Alembica który ma oczywiste wady ale działa dzisiaj, przyjął się. USD teoretycznie jeszcze nie istnieje dla szarych zjadaczy chleba i nie umożliwia komunikacji między ich programami. Nie każdy pracuje w Pixarze. ;)

USD nie jest dostępny w żadnym sofcie, bo przeprowadzają testy (m.in. z autodeskiem), czy nie ma buggów (od początku współpracują z Pixarem ludzie z ILM). Wypuszczą go raczej szybko, a API już jest dostępne (już można pisać).

Autodesk nie będzie tępił, a sam jest zainteresowany jednym uniwersalnym formatem i wie, że fbx nim nie jest.

Co do Collady to chciałem zapytać się, czy znasz jeden program obsługujący go poprawnie? No właśnie - blender do dziś nie potrafi poprawnie tych plików czytać. Problemem Collady jest to, że tego formatu praktycznie nie da się poprawnie wspierać!

Osoby korzystające z Alembica to bardzo mały ułamek. Ja nie widzę sensu tego formatu, poza animatorem, który chce robić w innym programie. Do niczego innego za bardzo się nie nadaje, jest to format stratny, usuwane są dane przy eksporcie, których nie możesz przywrócić. Przyjął się, ale akurat wśród użytkowników blendera, to akurat zapewne większości zupełnie on zwisa. USD nie ma tych wad, idealne wsparcie dla Alembic dostajesz gratis, a wyjdzie zapewne przed Alembic w blenderze (czytaj zanim wejdzie do kodu blendera trzeba będzie myśleć o usunięciu tego kodu) i to od razu ze wsparciem w praktycznie wszystkich programach (główni twórcy softu 3d sdk już mają).

Chciałbym uwierzyć że Autodesk zrezygnuje z FBXa na rzecz USD. Tylko zwyczajnie tego nie widzę. Dzięki relatywnie prostemu do połączenia FBX SDK stworzyli uniwersalny format wymiany danych, który mogą kontrolować oraz modyfikować kiedy i jak tylko im się podoba. Przeskoczenie na USD (na którym totalnie nic nie zyskują bo mogą wsadzić w FBXa co chcą) to dla nich utrata wpływów w branży na rzecz wspierania konkurencyjnych firm. Wierzysz że to pójdzie tak gładko? ;)

Chciałbym uwierzyć że Autodesk zrezygnuje z FBXa na rzecz USD.

Nikt nie mówi, że zrezygnują. Będą wspierać oba. Tylko nie zaistnieje sytuacja jak z Collada, bo Pixar ma standardową dobrą implementacje (tak jak Alembic), więc jego wsparcie jest proste.

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.

Ja dodam raczej pierdołę ale może się przydać

Stronka z klawiszami w blenderze i parę innych programów

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.

"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.

@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.

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).

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 :)

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."

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! :)

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).

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?

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

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.

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

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.

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.

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.

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.

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/

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.

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.

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.

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

a FUD'u nie lubię najbardziej z wszystkich trzyliterowych skrótów.

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.

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?