Blender - NEWS oraz dyskusje

[Vaticinator]

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?

[mandragora]

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

[Zuorion]

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

[alex3d]

Fajne :)

 

[Skoti]

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.

Edytowane 16 Styczeń 2015 przez Skoti

[Monio]

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.

[Vaticinator]

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?

[Skoti]

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.

[alex3d]

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

Edytowane 18 Styczeń 2015 przez alex3d

[Monio]

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.

[alex3d]

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

 

 

 

 

Edytowane 20 Styczeń 2015 przez alex3d

[Skoti]

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

Edytowane 20 Styczeń 2015 przez Skoti

[Monio]

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

Toć przecież tak się dzieje od dłuższego czasu i wszystko wskazuje na to że ten trend będzie się pogłębiał! :)

 

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

W pełni zasłużenie. TechOscary są dla mnie jakoś wyjątkowo miarodajne w porównaniu do filmowych Oskarów. :D Edytowane 20 Styczeń 2015 przez Monio

[Skoti]

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

Edytowane 20 Styczeń 2015 przez Skoti

[Monio]

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

[Skoti]

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

[Monio]

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? ;)

[Skoti]

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.

[Monio]

 

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.

Edytowane 22 Styczeń 2015 przez Monio

[mandragora]

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

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

[alex3d]

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.

Edytowane 25 Styczeń 2015 przez alex3d

[Skoti]

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

[alex3d]

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

[Skoti]

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

[alex3d]

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

[Skoti]

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

[alex3d]

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

Edytowane 25 Styczeń 2015 przez alex3d

[Skoti]

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

[Nezumi]

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?

[arev]

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

[Skoti]

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.

[mandragora]

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

[Monio]

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.

[Skoti]

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.

[Monio]

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.

Edytowane 26 Styczeń 2015 przez Monio

[Skoti]

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/

[Monio]

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.

[Skoti]

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.

[Nezumi]

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.

 

[Monio]

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.

[ikkiz]

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

[Skoti]

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.

[Nezumi]

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?

Edytowane 28 Styczeń 2015 przez Nezumi

[Monio]

Skoti- Już mi się nie chce twoich bzdur czytać. Ciągle piszesz że chodzi o OGL2.1 i pomijasz lub po prostu kłamiesz że nie chodzi o nowocześniejsze API które pozwoli na wspieranie najnowszych wersji OGLa gdy to jest właśnie kluczowym założeniem tego projektu. To że na chwile obecną nie ma tam funkcji z nowszych wersji OGLa nie świadczy o absolutnie niczym i bynajmniej nie jest żadnym poparciem dla twojego pier*olenia.

 

Albo jesteś trollem albo masz tak hardcoreowy cognitivie bias i straciłeś umiejętność czytania ze zrozumieniem. Nie wiem. Wiem że nie powinieneś się wypowiadać w kwestiach w których nie masz pojęcia. Co udowadniasz chociażby podając link do nieaktywnego już repozytorium i pisząc że to nadal projekt jednej osoby gdy obecnie pracuje nad nim 5 ludzi z czego 2 to etatowi koderzy BF.

[Skoti]

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?

Jaki defetyzm? Mógłbyś o nim mówić gdyby chcieli dodać wsparcie teraz, a ja bym mówił, że im to się nie uda. Ja mówię tym, że będą działać właśnie zgodnie z planem, więc gdzie tu widzisz defetyzm? Dodatkowo uważam, że zaimplementują to dobrze (jako jeden z małego grona zapewne), ale zajmie im to tyle co planują, bo nic się nie dzieje, aby to wyprzedzić. Teraz projekt ViewportFX pracował nad przepisaniem wszystkiego, nad usunięciem FixedPipeline i uzależnieniu viewportu jako minimum = shadery, a nie fixedpipeline. To dużo pracy i nad tym się skupiał (aby w przyszłości w OpenGL 3+ gdzie jest wyrzucony fixed pipeline nie robiło problemów).

To bardzo ważna praca, ale nie wciskaj ludziom, że jest tam cokolwiek z OpenGL 3+, bo nie ma. VFX miał zrobić refraktoryzacje i napisać wsparcie minimum. Jest możliwość rozszerzenia tego o możliwości OpenGL 3+, ale to praca na przyszłość i IMHO błędem było pisanie wsparcia dla 2.1, bo już teraz mogłoby od razu napisane dla OpenGL 3.3, a tak to musisz poczekać na 2.8 (sam pomyśl - obecnie mamy 2.73... wsparcie dla OpenGL 3+ jest obecnie na etapie planów... wcześniej niż w 2.8 po prostu nie ma szans się pojawić... i to by było mega tępo!).

[Skoti]

Skoti- Już mi się nie chce twoich bzdur czytać. Ciągle piszesz że chodzi o OGL2.1 i pomijasz lub po prostu kłamiesz że nie chodzi o nowocześniejsze API które pozwoli na wspieranie najnowszych wersji OGLa gdy to jest właśnie kluczowym założeniem tego projektu. To że na chwile obecną nie ma tam funkcji z nowszych wersji OGLa nie świadczy o absolutnie niczym i bynajmniej nie jest żadnym poparciem dla twojego pier*olenia.

W projekcie chodzi o podwaliny pod nowocześniejsze API, dla przyszłych projektów jednak nie o ich wykorzystanie obecnie. I nie kłam, że tak nie jest bo dobrze wiesz, że właśnie tak. Ofc możesz zamiast pierdzielić farmazony z sufitu udowodnić, że tak nie jest - kod zarówno w czystej postaci jak i już obecnie połączony z master masz i wystarczy jedna linijka, aby udowodnić swoje racje, jednak wiesz, że jej tam nie znajdziesz.

Do projektu już link podałem, ale jeśli chcesz kod już po połączeniu z masterem to proszę bardzo:

https://developer.blender.org/diffusion/B/browse/

 

Co udowadniasz chociażby podając link do nieaktywnego już repozytorium i pisząc że to nadal projekt jednej osoby gdy obecnie pracuje nad nim 5 ludzi z czego 2 to etatowi koderzy BF.

Podaje Ci link do skończonego projektu - to jest gotowy kod, który został połączony z master branch i nowych możliwości tam się nie rozwija. Na nowe możliwości musisz poczekać dopiero na przyszłe projekty. Co do "osób pracujących nad projektem" to masz na myśli:

psy-fi (jedyne co zrobił to stworzył brancha), campbellbarton (poprawki stylu wyglądu kodu do reszty blendera, aby wyglądał jak reszta 20 letniego kodu) czy kilka innych osób, których wkład to bugfixy na danych platfomach, ale nie praca nad możliwościami? Jeśli nie masz pojęcia o czym mówisz to lepiej nie mów

[alex3d]

@skoti nie da się czytać tego bełkotu, tzn. zaczynam czytanie Twoich postów i kończę na nicku.

 

Dalszy postęp Bishopa w pracy nad PTex-em:

 

[Monio]

W projekcie chodzi o podwaliny pod nowocześniejsze API, dla przyszłych projektów jednak nie o ich wykorzystanie obecnie.

Serio? No popatrz jaki zbieg okoliczności. Tak się składa że to dokładnie pisałem gdy ty jeszcze 24 godziny temu upierałeś się że głównym golem projektu jest przeskok do OGL2.1 i tyle. Możesz przeczytać swoje poprzednie posty w tym temacie, linijka po linijce.

Dzięki obsłudze EGL i ujednoliconemu systemowi abstraction layers dodanie API nowszych wersji OGLa będzie o wiele łatwiejsze o ile w ogóle wykonalne przez osoby ktore nie znają całego codebase blendera. Kiedy to zaskutkuje funkcjami i OGL3/4 nie wiemy. Wiemy za to że będzie to czas i wysiłek nieporównywalnie mniejszy niż przed viewportfx.

 

Dobrze że przynajmniej dowiedziałeś się o co chodzi w viewportfx. Szkoda że musiałeś poprzedzić ten moment kilobajtami bullshitu.

[alex3d]

Instrukcja korzystania z Ptex: http://wiki.blender.org/index.php/User:Nicholasbishop/Ptex

 

Prezentacja cyclesa w Rhino:

[Skoti]

Serio? No popatrz jaki zbieg okoliczności. Tak się składa że to dokładnie pisałem gdy ty jeszcze 24 godziny temu upierałeś się że głównym golem projektu jest przeskok do OGL2.1 i tyle. Możesz przeczytać swoje poprzednie posty w tym temacie, linijka po linijce.

Starałem się, pisać zrozumiale, ale nie obrażać intelektu rozmówcy, jednak do tego mnie zmuszasz, bo widzę, że nie rozumiesz słowa pisanego i trzeba łopatą:

"W projekcie chodzi o podwaliny pod nowocześniejsze API", a dokonano tego poprzez "jedynie wywalenie starych rzeczy przed OpenGL 2.1 i nie "wykraczania" poza jego możliwości". VFX zakładał wywalenie starych rzeczy jak fixed pipeline (2.0 wymaga shadery, a od 2.1 język GLSL jest używalny, dlatego takie wymaganie), zapewnienie framebuffer object. To jest to całe przygotowanie pod nowe OpenGL, bo do dziś stosuje się FBO, do dziś stosuje się shadery GLSL (ofc ich język i API to już zupełnie inna rzecz i trzeba napisać je od nowa) do dziś stosuje się VBO (to co, że dziś pakuje się do VAO, używa instancingu i rysuje niebezpośrednio). Polegało to na wywaleniu dinozaurów i zastąpienie starociami, które teraz będzie się znowu przepisywać, poza FBO (no ok, jeśli będą chcieli mieć MSAA w viewporcie to będą musieli poprawić (OpenGL 3.2), ale to potrzebuje najmniejszych zmian).

 

Dzięki obsłudze EGL

Tu mnie zszokowałeś! Co niby zyskujemy dzięki obsłudze EGL (obsługiwanego tylko na Androidzie i działającego tylko z OpenGL ES) poza dodatkowym kłopotem martwienia się o kolejny sposób tworzenia kontekstu (blender już wspiera SDL, WGL, GLX, Cocoa to jeszcze dowalono EGL... którego obsługe już miał poprzez SDL)? Ktoś Ci podpowiada, żebyś pisał takie brednie, czy tak sam z siebie je wypluwasz?

 

Kiedy to zaskutkuje funkcjami i OGL3/4 nie wiemy. Wiemy za to że będzie to czas i wysiłek nieporównywalnie mniejszy niż przed viewportfx.

Wysiłek po pierwsze zbędny - taki sam byłby koszt czasowy stworzenia viewportfx od razu minimum 3.3 pomijając pisanie kodu dla 2.1, który nikomu do szczęścia nie jest potrzebny. Koszt pisania wsparcia dla OpenGL 3+ szacuję na połowę czasu ViewportFX (jest to więcej niż połowa pracy włożonej w VFX (bo tu już były gotowe shadery pamiętające jeszcze yo franky (w GL3.0 api GLSL się zmieniło i trzeba je przepisać, a wszystko poza FBO co zrobiono teraz też trzeba robić od zera (poza usuwaniem starego kodu))), ale licze, że widząc efekty będzie iść szybciej)... Blender 2.80 pojawi się za jakieś 1.5 roku, a viewportFX to projekt mający już blisko 3 lata.