Blender - NEWS oraz dyskusje

[Monio]

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53373

 

Cycles Hair rendering w svn. Na razie tylko dla CPU i w experimental features. Coś czuje że włoski będą śmigać jak należy znacznie szybciej niż planował Brecht. I bardzo mnie to cieszy. :) Testować!

 

---------edit----------

 

Dyntopo w Trunku! Będzie dostępne od builda r53450 który będzie można pobrać tutaj, pewnie jutro lub pojutrze.

 

http://nicholasbishop.net/wordpress/?p=733

Edytowane 30 Grudzień 2012 przez Monio

[n-pigeon]

Ooooo super :D

 

A tutaj ostatni meeting:

Hi all,

 

Here's notes from today's session in irc.freenode.net #blendercoders

 

1) Blender 2.66 targets

 

- Sergey Sharybin is nearly finished with the alpha pipeline refactor project. Simply said: we will stick to default straight RGBA for all (color managed) byte buffers, and default to premul RGBA for the (linear) float buffers. A lot of worms in this can, fuzzy and unclear code that needed fix up.

Sergey will provide a doc with his commit about the main changes people should be aware of, and where potential regressions could happen.

 

- Sergey also added support for 16 bits png.

 

- Nicholas Bishop's dynamic topo sculpt is nearly finished, and could go to trunk this week. It will not be fully f complete then, Custom Data (UVs, colors) will disappear in this mode. They will make sure the UI warns you for it.

 

- Sergej Reich is working on the Bullet physics branch still. He's now recoding a better Blender compatible point cache for it.

 

- Cycles hair render is now in svn, Stuart Broadfoot will add full docs a.s.a.p. here;

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

 

- Bastien Montagne won't be able to get Freestyle ready in the next weeks, so we move the target to 2.67.

 

- Note: we enter BCon2 now (targets frozen, mergers happen). Release early february.

 

2) Other projects

 

- Ton Roosendaal and Andrea Weikert discussed Asset browsing and systems for Blender. Ton's proposal for 'template assets' (default data for "Add New" options can mostly fit in well, but should be limited for default data. The Asset browser can handle it much nicer. Docs and conclusions will be coming later. There's a lot of interest in it.

 

- Martin Felke progressed well with his voronoi fracture modifier:

http://wiki.blender.org/index.php?title=User:Scorpion81

There's still reviews needed, probably not ready for release. As 2.67 it's feasible.

 

Thanks, and I wish everyone a happy new year! :)

 

-Ton-

[n-pigeon]

Noja miting maj frojnds:

 

Hi all,

 

Here's notes from today's meeting in irc.freenode.net #blendercoders. We tried to keep it short, lots of interesting code work todo!

 

1) Blender 2.65 progress

 

- Sergey Sharybin: Our official linux builds (also on builder.blender.org) are now glibc2.11 only.

 

- Sergey also completed the Alpha recode, which is in svn now

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

 

- Brecht van Lommel worked on hair, refactoring code and getting arbitrary (texture coordinates, vertex color, etc) attributes working on hair.

Brecht also worked on multiple importance sampling for lamps, an old todo, which should reduce noise on sharp glossy materials. Will be done monday or tuesday.

 

Next on the todo is work on 'ubershader' or displacement.

 

- Lukas Toenne: the pynode target probably moves to 2.67?

 

- Bastien Montagne: Freestyle integration is also a 2.67 target now.

 

- Sergej Reich: work on Bullet integration nearly done, ready for review this week (with end-user docs)

 

2) Other projects

 

- Ton Roosendaal experimented with simple and fast GLSL shaders for "matcap" (sphere texture mapped on normals). Works well even with current preview-rendered material icons. Could be used as GLSL-enhance option for standard Solid drawing, for modeling and sculpt. Still experimental.

 

Thanks,

 

-Ton-

[ikkiz]

coś cicho o SSS, a dziewczyny już czekają, żeby mieć ładną skórę.

[Monio]

Chyba teraz cała para idzie w te włosy. Trochę nie ta kolejność jak dla mnie ale włoski są też spoko. Niestety ten patent z raylenght node daje słabiutkie efekty w porównaniu z prawdziwym SSS. Lepsze niż nic ale nadaje się to tylko do świecenia za uszami a nie normalnego oświetlania skóry. Trzeba będzie jeszcze kilka miechów poczekać.

[n-pigeon]

O SSS nie jest cicho :) prace nad SSS rozpoczną się w przy okazji 2.67, ale to duuużo roboty, więc raczej skończy na 2.68/9 jeśli mu nikt nie pomoże.

 

Włoski miały być po SSS z tego co pamiętam, są wcześniej ponieważ inny koder się nimi zajął :P a skoro kod już jest, to Brecht przy nim trochę pomaga i radzi. Jeszcze dużo roboty zostało zanim wyjdą z pod experimental, wątpię byśmy ujrzeli gotowe włosy dla 2.66.

 

Ja czekam, aż Brecht powrzuca zaplanowane na 2.66 ficzery, ubershader, displacement i MIS dla lamp, to akurat to co mi teraz bardzo się przyda :X

[n-pigeon]

Multiple importance sampling dla lamp trafił do Trunk, pomaga przy dużych źródłach światła oraz ostrych odbiciach.

 

Przed:

Po:

 

http://www.miikahweb.com/en/blender/svn-logs/commit/53688

 

Dodatkowo Non Progressive Integrator otrzymał kilka napraw, ponoć jest teraz używalny to bardzo dobra wiadomość :)

 

Warto też wspomnieć, że ostatnio Campbell poprawia wydajność niektórych aspektów BMesha.

Edytowane 10 Styczeń 2013 przez n-pigeon

[ikkiz]

głupio mi się pytać, ale jak nie wiem, to pytam. Co to jest ten Integrator i co daje, że jest non progressive.

Oraz czy w kompilacji 53688 tam już mam, że działa tam Multiple importance sampling, czy trzeba to jakoś włączać - bo poprawa jest bardzo widoczna na pokazanych przykładach?

[n-pigeon]

Co do MIS jest teraz włączony domyślnie, wyłącznik dopiero zostanie dodany niedługo, tak jak to jest z MIS dla mesh lightów i otoczenia.

A jest potrzebny ponieważ MIS dodaje trochę czasu renderingu jeśli żadna lampa nie będzie miała z niego korzyści, np będzie mała, albo materiały w scenie będą bardzo rozmyte. Wtedy MIS będzie robił swoje obliczenia co doda do czasu renderu, ale nic korzystnego dla sceny nie zrobi.

 

Integrator zajmuje się dystrybucją sampli, jego opcje masz w panelu Sampling. Jest tam ptaszek z napisem Progressive, jak go wyłączysz przejdziesz w tryb Non progressive. W trybie Non progressive możesz dokładniej kontrolować, co dostaje ile sampli, przemnożone przez ilość sampli AA.

Teoretycznie "nie progresywny" integrator powinien być bardziej wydajny, ale w Cycles jak dotąd był wolniejszy jeśli używało się Indirect Illumination, więc korzystały na tym tylko sceny z samym Direct Lightingiem. Teraz ponoć Brecht go trochę naprawił, przy okazji, ale możliwe, że będzie wymagał jeszcze trochę pracy.

 

Z testów DingTo jakość IndirLight się mocno poprawiła, ja jeszcze się nie bawiłem.

 

Przed:

Po:

 

Z tego co wiem Arnold używa Integratora nieprogresywnego domyślnie. Jest trudniejszy w obsłudze, ale przy ustawianiu scenu do finalnych renderów warto go wykorzystać. Znaczy będzie warto, jak będzie w pełni sprawny.

[n-pigeon]

Obsługa pack'owania i generowanych plików graficznych w Cycles :) jednak jedynie dla SVM, w OSL na razie nie jest możliwe by to obsługiwać bez patchowania OSL.

 

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53737

[n-pigeon]

NO! Bardzo ciekawe nowinki!

 

Od teraz po naciśnieciu G 2 razy przechodzimy w tryb slide'owania :) vertex bądź edge. Campbell znowu daje czadu :)

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53768

 

 

Tygodniowe Meeting Notes:

 

Hi all,

 

Here's a summary of today's meeting in irc.freenode.net #blendercoders

 

1) Blender 2.66 status and planning

 

- Sergey Sharybin proposed to remove the old compositor code from svn now. It's there as compile option still, but not needed or used anymore, nor supporting new color management code.

 

- Ton Roosendaal: will do some "file flag" cleaning - for all the different .blend options we support now. It then will allow a formal definition of a 'template blend' too, which is like startup blend, but then you can have many.

 

- Bastien Montagne presents translations for add-ons in Blender:

https://codereview.appspot.com/7102054/

Campbell Barton will review.

 

- Ton has WIP code for "matcap" in Blender (sphere textures mapped on normals), this can provide a much faster and good looking GLSL shader option for "Solid" draw mode, especially useful for modeling and sculpt. UI control for this is still open, a proposal will follow this week.

 

- Sergey will work on movie support in Cycles, and clean up color/alpha operations in compositor (to prevent premultiplied colors messing up too easily).

 

- Sergej Reich expects to get his Bullet Branch in svn this week.

http://wiki.blender.org/index.php/User:Sergof/GSoC2012/Documentation

Campbell volunteered to review. We need good user feedback on this too!

 

- Ton did initial review of Jorge Rodriguez' GSoC (UI) project, and selected a handful of simple/compatible features that can merge too - but will first carefully check code.

 

- Lukas Toenne has a new doc for PynNodes, an overview of the DNA/BKE structure, including the major changes and couple of remarks: http://wiki.blender.org/index.php/User:Phonybone/Nodes_Documentation

Brecht van Lommel will review the project, he hopes it can get in for 2.66 still.

 

 

2) Other projects

 

- Bastien Montagne collected a list of fixes we need to do, which will break forward compatibility (old Blender reading newer files) when applied:

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Compatibility_Breaking

 

- Bastien confirms Freestyle branch is on track for 2.67!

 

Thanks,

 

-Ton-

[Monio]

http://blenderartists.org/forum/showthread.php?267414

 

Nie wiem czy było. Jaram się jak pochodnia.

 

----------------------

Z dzisiejszych newsów- Kilka procent szybszy cycuś na CPU

[floo]

@Monio było, ale widzę że dodali ikonki, jakaś nowa wersja się pojawiła? Muszę to sprawdzić.

[Monio]

Bardzo prężnie się to rozwija. Ton podobno jest zainteresowany przepisaniem tego na C. Na razie to prototyp, trzeba testować i dzielić się pomysłami.

[Idaho]

A ja mam radochę z tego o czym pisał n-pigeon. W końcu na buildbot pojawiła się rev 53787 - Slide vertexów i edgy. Taka mała rzecz a ile zabawy ;)

[n-pigeon]

@Monio stare i jak na razie nic nie wynikło, ale w ciąż mam płomyk nadziei :D

 

Kilka fajnych rzeczy trafiło do trunka:

 

Campbell razem z Antonisem popracowali trochę nad unifikacją, poprawkami i drobniejszymi usprawnieniami Sculptu, Vertex i Texture Painta.

Campbell dalej poprawia wydajność BMesha, ale i Dynatopo.

 

Cycles od teraz obsługuje tekstury video:

http://www.miikahweb.com/en/blender/svn-logs/commit/53848

 

Modyfikator Laplacian Smooth od teraz ma możliwość wzmacniania form obiektu:

http://www.miikahweb.com/en/blender/svn-logs/commit/53853

 

[Monio]

Tej opcji od zawsze mi brakowało w zecie. Super sprawa.

Szkoda tylko że Blender nie łyka większych OBJotów jak xnormal. To jest uzależnione od vievportu czy po prostu przeliczania siatek? Więcej ramu pomoże?

 

 

 

----------------

 

http://blenderartists.org/forum/showthread.php?278787

 

Petarda.

Edytowane 18 Styczeń 2013 przez Monio

[n-pigeon]

Eh taki nudny ten dzisiejszy meeting, choć potem dyskusja psy-fi, jwilinks i nicholasa była ciekawa, ale nie ma co plotkować, liczą się fakty dokonane.

 

Hi all,

 

Here are the notes from today's session in irc.freenode.net, #blendercoders

 

1) Blender 2.66 progress

 

- Current projects and planning:

http://wiki.blender.org/index.php/Dev:Doc/Projects

 

- The Bullet branch is nearly finished, but needs some recode still for way how Groups are being handled.

 

- PyNode branch review didn't make it last week due to flu.

 

- Matcap work hasn't been finished last week either, integrating in a nice way is complicated. Sculpt code is also using different drawing.

 

- Most of the time meeting spent on defining whether to extend this release cycle with 1 or 2 weeks or not. We settled on the following:

 

Approved release targets/projects get until tuesday 22nd end of day to be added in trunk. We will try to stick to original planning, but if Bullet branch and/or Pynode gets in we can extend testing/fixing period (bcon3) with a week.

 

- Translation code for for Python Add-on scripts will get added today

 

- Rounded vertex-only bevel fix is coming soon, A complete new modifier implementation for Beveling becomes a 2.67 target.

 

2) Other projects

 

Nothing mentioned today.

 

Thanks,

 

-Ton-

 

ALE matcapy i nowy bevel mod coraz bliżej...

 

Druuuuumm~!

Edytowane 20 Styczeń 2013 przez n-pigeon

[mrys]

A nóż nadal potrafi pominąć kilka ścianek przy cięciu.

[n-pigeon]

Mrys, dlaczego tego nie zgłosisz, zaopatrując developerów w potrzebne pliki testowe, tak by mogli odtworzyć sytuacje kiedy występuje luka w działaniu knife.

Edytowane 20 Styczeń 2013 przez n-pigeon

[Monio]

n-pigeon:

 

Aluzju poniał? Pisałeś to sto razy. Mi również. Znajdź te posty, przeredaguj i zrób taki wątek, będzie szybciej dla ciebie i lepiej dla społeczności.

[n-pigeon]

Aluzju poniał.

[Nezumi]

Troche slabe jest to ze trzeba rzeczy oczywiste tlumaczyc fefnoscie razy :P

To nie Autodesk - tu mozna miec realny wplyw na program. No ale "co ja tam bede wysylal, niech ktos inny wysle a oni poprawia...

[ikkiz]

tyle, że trudno odtworzyć sytuację z knifem. Sam bym zgłosił, ale głupio pisać "czasem" i wysyłać plik, po to, żeby dev mógł stwierdzić, że jemu przecież działa. Za dużo zmiennych w odręcznym narzędziu, żeby mieć powtarzalność.

[mrys]

Mrys, dlaczego tego nie zgłosisz, zaopatrując developerów w potrzebne pliki testowe, tak by mogli odtworzyć sytuacje kiedy występuje luka w działaniu knife.

 

Błędy z nożem zgłaszałem ja, zgłaszali inni userzy. Część sytuacji dało się odtworzyć - część nie. Ile razy można czytać w odpowiedzi, że na razie tak musi być i że kiedyś tam...? Niestety nowy ficzer lepiej wygląda pr-owo niż mała poprawka w istniejącym narzędziu.

 

Żeby nie było, że zupełnie nic się nie dzieje - od czasu wprowadzenia b-mesha nóż i tak działa o niebo lepiej.

[n-pigeon]

@ikkiz

 

Da się trzeba tylko chcieć ;) .blend, obrazki, rysunki, opis i fin da się na pewno.

 

@Nezumi

 

Autodesk również ma system raportowania błędów i są one naprawiane, no, znam co najmniej jedną osobę która miała naprawione zgłoszone błędy.

Problem jest, jeśli użytkownicy stosują forum, by się żalić, zamiast Bug Trackerów.

 

Innym problemem są bugi które nie tak łatwo naprawić... np. takie które wynikają z błędów projektowania programu, Blender też takie ma i co jakiś czas coś trzeba przepisać na nowo, programy Autodesk mają jeszcze gorzej ponieważ często asymilują zewnętrzne wtyczki jako nowe funkcje, code base im rośnie jest coraz bardziej nieuporządkowany, pofragmentowany itp.

 

Aktualnie w Blenderze na recode czeka Dependency Graph (gruuuba sprawa) i view port (to samo)

 

 

@mrys

 

Czytałem twój raport, błędów jest na pewno więcej, należy je wszystkie zgłosić, razem z .blendami, kod tego typu to nie po prostu "to zrób tak", narzędzia do mesha często mają tablice przypadków np. jeśli kawałek topo wygląda tak rób to, jeśli tak rób to, jeśli jeszcze inaczej rób tamto itd.

Takie przypadki trzeba stale dopisywać, błędy są różne, nie wszystkie są tym samym "knife nie rozcina poly" są różne "nie rozcina poly". Jak napiszesz o raport za dużo to nic się nie stanie.

 

A twoje gadanie "bo duże łądne ficzery" jest bez pokrycia, BF to nie jest firma nie potrzeba im reklam. Dodatkowo jest to niesprawiedliwe w stosunku do wszystkich którzy ciężko pracują naprawiając jak najwięcej błędów. Po prostu niektóre błędy są trudne do naprawienia...

 

Sam mam raport w trakcie dociekania jak go naprawić, już 3 miesiąc idzie, dzisiaj akurat dostałem kolejnego maila gdzie opiekun kodu dopisywał swoje notatki i ustalenia z śledztwa dlaczego ten błąd występuje.

Edytowane 20 Styczeń 2013 przez n-pigeon

[ikkiz]

@n-pigeon No myślę, że się da, znaczy uda.

Ja dziś próbowałem go wywołać, ale dziś mi knife tnie jak trzeba, bezbłędnie. Czasem się nie chce objawić, a gdzie tam do powtarzalności. Nie zrozum mnie źle, nie mówię, że to bez sensu, że się nie da, tylko zauważam pewną trudność pewnie związaną z tym, o czym napisałeś w ostatnim poście.

[mrys]

@mrys

A twoje gadanie "bo duże łądne ficzery" jest bez pokrycia, BF to nie jest firma nie potrzeba im reklam. Dodatkowo jest to niesprawiedliwe w stosunku do wszystkich którzy ciężko pracują naprawiając jak najwięcej błędów. Po prostu niektóre błędy są trudne do naprawienia...

 

Z całym szacunkiem, ale "moje gadanie" ma pokrycie w tym, w jaki sposób Blender był rozwijany przez ostatnich kilka lat.

Być może jest to tylko moje skrzywienie, ale uważam, że narzędzia modelarskie to obok renderera i edytora materiałów to absolutnie podstawowa część programu. A tymczasem mogliśmy śledzić epopeję b-mesha, nad którym przez dłuższy czas siedziała jedna osoba i to niezbyt efektywna. No ale trzeba było zrobić ficzery, żeby zrobić Sintela. I tak: od filmu do filmu. Dla ludzi rozwijających i poprawiających Blendera mam olbrzymi szacunek, ale to nie znaczy, że musi mi się podobać przyjęta strategia rozwoju (jeżeli w ogóle taka istnieje).

Dla kogoś, kto np. zajmuje się animacją, compositingiem itd rozwój Blendera jest na pewno bardziej widoczny, niż dla kogoś, kto potrzebuje dobrych narzędzi modelarskich. Tu przez długi czas nic się nie działo. A co do noża - być może faktycznie błędy wydające się użytkownikowi drobiazgami do poprawki, z punktu widzenia programisty wcale nie są drobiazgami. OK. Ale w żadnych roadmapach i planach na przyszłość nie widzę dopracowania noża tylko coraz to nowe ficzery (albo może po prostu nie zauważyłem).

[n-pigeon]

Właśnie o to mi chodzi oceniasz sytuacje całkowicie z perspektywy widza/użytkownika. Każdy z nas wie jakie ficzery mile by widział tu i teraz, ale koderzy nie patrzą na to z tej perspektywy, co jest użyteczne, co jest podstawowe.

 

Oni po prostu organizują sobie prace, biorą pod uwagę swoją wiedze, doświadczenie, zainteresowanie bez których robili by na odwal, biorą pod uwagę to co robili ostatnio, nikt nie lubi monotonnej roboty.

 

____________________

Dla ciebie wyglądało to tak:

trzeba było zrobić ficzery, żeby zrobić Sintela

. W rzeczywistości wyglądało to tak:

 

Ton: Przydało by się, w końcu zająć się BMeshem, to jest bardzo duży, skomplikowany i ważny projekt może wykorzystamy to, że teraz mamy fundusze z Open Movie i możemy się tym zająć zespołowo, przynajmniej pierwszą fazę. Kto jest chętny by potem zająć się wykończeniówką?

Campbell: Ja od dawna chciałem wziąć na warsztat BMesh, ale nie było czasu na tak duży projekt. Powinniśmy wykorzystać Duriana tak jak mówisz Ton, teraz albo znowu sobie poczekamy, na kolejną okazje.

Ton: Ok, w końcu pójdziemy z tym projektem, EditMesh był już nie używalny, teraz będzie można w końcu porobić coś przy modelowaniu, userzy się przy okazji ucieszą.

 

Tak to mniej więcej wyglądało, Campbell pracuje nad BMeshem do dzisiaj i to nisko poziomowe sprawy jak i ficzery.

 

I tak: od filmu do filmu.

W tym roku nie będzie filmu, ma być 100% kodowanie Blendera, a pieniądze wpływają jako tako, bo Developerzy maja się zajmować jakimś magicznym Dependency Graph. Userzy nie wiedzą nawet co to jest. Projekt równie ważny, a może i ważniejszy od BMesh, ale na niego nie ma hype, bo nie są to jakieś kolorowe bevele i knify, ale jakoś Developerzy chcą się za to zabrać i to nawet bez filmu? I gdzie tu twoja teoria?

 

Developerzy mają gdzieś hype, biorą na siebie zadania które TRZEBA wykonać, bo taka jest sytuałacja, albo CHCĄ coś zrobić to ich hobby i organizują to tak by mieć na to środki, tyle.

To nie Blender służy Open Movie, tylko Open Movie służy Blenderowi.

Ton na swoje utrzymanie i jednego kodera zarabia za pośrednictwem sklepu z treningowymi DVD i gadżetami.

Open Movie to zastrzyk gotówki na dodatkowych 2 koderów, pracujących full-time in-house.

 

______________________

Ale w żadnych roadmapach i planach na przyszłość nie widzę dopracowania noża tylko coraz to nowe ficzery (albo może po prostu nie zauważyłem).

 

Nie myl Roadmap wydań, z ToDo poszczególnych developerów. Roadmap to tylko podgląd tego co się pojawi, w najbliższych wydaniach, bo dany projekt jest bliski ukończeniu, albo jest ukończony.

Programiści piszą sobie sami ToDo i są tam naprawy o których nawet nie wiesz, że są potrzebne, są to z reguły mniejsze zadania, ale pracują nad nimi ciężko, na 50 commitów poprawek, przyspieszeń, napraw, przypada 1 commit jakieś super duper funkcji.

To, że czegoś nie widzisz nie znaczy, że tego nie ma.

 

Wejdź na Release Log Blendera i poczytaj w ostatnich wydaniach naprawione bugi i pomniejsze poprawki, policz sobie ile tego jest, a to nie wszystko, wiele jest pominiętych, ponieważ były commitowane w paczce np. albo zostały przeoczone przy spisywaniu.

 

Mówienie, że wszystko kręci się wokół dużych kolorowych funkcji mogę nazwać jedynie nieprawdą wynikającą z niewiedzy.

Listy wykonanych pomniejszych ToDo i projekty takie jak Deps Graph mówią same za siebie.

 

 

 

@Ikkiz

Hmm, ja bym wziął, modelik ustawił odpowiednio view port i zapisał.

Napisałbym, żeby otworzyć plik z UI i bez poruszania kamery ciachać ja na rysunku, aż knife nie chwyci geo. Może tak by dało rade? Przyznaje, że raportowanie takich bugów to upierdliwa rzecz.

Edytowane 21 Styczeń 2013 przez n-pigeon

[Monio]

Ja blenderowe SVN śledzę każdego dnia to właśnie poprawki istniejących rzeczy stanowią jakieś 95% zgłoszeń kodu. Ostatnio było bardzo wiele poprawek związanych z bmeshem i knifem. Raczej nie sprawdza się twoja teoria Mrys, przynajmniej nie w ciągu ostatniego roku.

[mrys]

Właśnie o to mi chodzi oceniasz sytuacje całkowicie z perspektywy widza/użytkownika.

 

A jak mam oceniać? Nie developuję Blendera, tylko go używam. Tak, masz rację, z mojego punktu widzenia Dependency Graph jest nieistotny (chociaż dla funkcjonowania programu zapewne jest). Natomiast nóż, którego używam bez przerwy i bez przerwy muszę po nim czyścić i korygować siatkę jest bardzo istotny. Trywialne porównanie, ale jadąc samochodem niespecjalnie mnie interesuje, jak to dokładnie jest, że ja naciskam guzik a zapala sie reflektor, byleby sie zapalał.

 

Punkt widzenie użytkownika jest istotny, bo jaką rację bytu ma program, którego się nie używa? A użytkownika np. trudno przekonać, że o ile tak banalna operacja jak przenoszenie obiektu z warstwy na warstwę w B2.49 trwało ułamek sekundy a w B2.65 trwa kilka sekund, to jest to postęp (chociaż zapewne za pogorszeniem jednego parametru stoi mechanizm, umożliwiający w zamian 100 innych rzeczy). Być może w tym tkwi problem, że wielu developerów nie używa Blendera ot tak, do pracy tylko go rozwija.

 

Wiem, że o wielu rzeczach w rozwoju Blendera nie wiem i naprawdę doceniam i jestem wdzięczny ludziom, którzy dłubią przy programie, bo robią gigantyczną pracę. W ten sposób (tzn. znienacka) znikneło bardzo wiele problemów, charakteryzujących pierwsze wersje Blendera z b-meshem, chociażby upierdliwe multiplikowanie wierzchołków przy powielaniu fragmentów siatki, za co autorowi poprawki wystawiłbym pomnik :). I zapewne (mam nadzieję) tak samo w końcu zniknie problem z osieroconymi face'ami po użyciu noża.

 

I ostatnia kwestia:

 

Każdy z nas wie jakie ficzery mile by widział tu i teraz, ale koderzy nie patrzą na to z tej perspektywy, co jest użyteczne, co jest podstawowe.

 

Oni po prostu organizują sobie prace, biorą pod uwagę swoją wiedze, doświadczenie, zainteresowanie bez których robili by na odwal, biorą pod uwagę to co robili ostatnio, nikt nie lubi monotonnej roboty.

 

Albo się przejęzyczyłeś, albo potwierdziłeś, że strategia rozwoju Blendera polega na: co się akurat komu chce. :)

 

 

A tak naprawdę, chodzi o bycie szczęśliwym. Mnie do bycia szczęśliwym z Blenderem brakuje już tylko tego cholernego noża, który gdyby działał jak powinien to byłby (prawie) absolutnie cudowny :)

Edytowane 21 Styczeń 2013 przez mrys

[n-pigeon]

A jak mam oceniać? Nie developuję Blendera, tylko go używam. Tak, masz rację, z mojego punktu widzenia Dependency Graph jest nieistotny (chociaż dla funkcjonowania programu zapewne jest). Natomiast nóż, którego używam bez przerwy i bez przerwy muszę po nim czyścić i korygować siatkę jest bardzo istotny. Trywialne porównanie, ale jadąc samochodem niespecjalnie mnie interesuje, jak to dokładnie jest, że ja naciskam guzik a zapala sie reflektor, byleby sie zapalał.

 

Nie mam do Ciebie pretencji, tylko tłumacze jak rzeczywiście to działa. Nie jest tak jak mówisz, masz prawo tego nie wiedzieć, ale ja wiem i dlatego opowiadam jak to wygląda od kuchni. ;)

 

Punkt widzenie użytkownika jest istotny, bo jaką rację bytu ma program, którego się nie używa? A użytkownika np. trudno przekonać, że o ile tak banalna operacja jak przenoszenie obiektu z warstwy na warstwę w B2.49 trwało ułamek sekundy a w B2.65 trwa kilka sekund, to jest to postęp (chociaż zapewne za pogorszeniem jednego parametru stoi mechanizm, umożliwiający w zamian 100 innych rzeczy). Być może w tym tkwi problem, że wielu developerów nie używa Blendera ot tak, do pracy tylko go rozwija.

 

Nikt nie twierdzi, że punkt widzenia użytkownika nie jest istotny, ja tego nie mówiłem. Stwierdziłem jedynie fakt, że użytkownik gówno wie, wie tylko to co chce, developer ma świadomość wielu rzeczy których użytkownik nawet nie rozumie, a użytkownik wie czego oczekuje. Rozwijanie projektu takiego jak Blender polega na współpracy tych grup, co jest czynione.

Gdyby developerzy rozwijali Blendera tak jak użytkownicy sobie tego życzą, to by wszystko się rozchodziło o świecidełka i ładne funkcje, a przecież w poprzednim poście to krytykowałeś.

 

Wiem, że o wielu rzeczach w rozwoju Blendera nie wiem i naprawdę doceniam i jestem wdzięczny ludziom, którzy dłubią przy programie, bo robią gigantyczną pracę. W ten sposób (tzn. znienacka) znikneło bardzo wiele problemów, charakteryzujących pierwsze wersje Blendera z b-meshem, chociażby upierdliwe multiplikowanie wierzchołków przy powielaniu fragmentów siatki, za co autorowi poprawki wystawiłbym pomnik :). I zapewne (mam nadzieję) tak samo w końcu zniknie problem z osieroconymi face'ami po użyciu noża.

 

Wszystkie stare problemy z czasem znikną, pojawią się na ich miejsce nowe. :) Jako użytkownicy możemy jedynie raportować błędy, a jeśli coś przykrywa kurz to co jakiś czas grzecznie odkopać ;) zapytać jaki jest tego status i trele morele. Devy mają tyle roboty, że nawet nie wiedzą w co ręce włożyć... ale słuchają się opinii użytkowników, powiem, że nawet więcej niż kiedyś, bo pojawiło się dużo nowych entuzjastycznych developerów i starzy mają mniej roboty przy niektórych rzeczach, i ToDo się już tak nie piętrzą jak kiedyś.

Szkoda, że Gimp nie ma takiego szczęścia :D może jak opadnie kurz po GEGLu i GTK 3 :)

 

I ostatnia kwestia:

 

Albo się przejęzyczyłeś, albo potwierdziłeś, że strategia rozwoju Blendera polega na: co się akurat komu chce. :)

 

A tak naprawdę, chodzi o bycie szczęśliwym. Mnie do bycia szczęśliwym z Blenderem brakuje już tylko tego cholernego noża, który gdyby działał jak powinien to byłby (prawie) absolutnie cudowny :)

 

Nie przejęzyczyłem się, to co jest robione to głównie zależy od tego co się komu chce, to jest projekt rozwijany przez pasjonatów, nie roboli którym się kazało.

Niektóre rzeczy stają się z czasem tak upierdliwe, że następuje pospolite ruszenie, inne są robione ponieważ ktoś się zainteresował jakąś tematyką i chce przy niej popracować, inni robią rożne rzeczy, nawet np. naprawiają bugi, dla sportu, bo lubią urozmaiconą robotę, drobniejsze zadania.

 

To hobby :) tak jak u Ciebie modelowanie samolotów, gdyby naglę ktoś kazał Ci modelować coś innego prawdopodobnie nie wkładał byś w to już tyle serca, tak samo działa to u devów.

 

To ma swoje wady i zalety, zaletą jest to, że nie robią na odwal ;P nawet jak coś nie jest ukończone na takim poziomie funkcjonalnym jak np. maxowe pluginy rozwijane od jakiegoś czasu, to kod od strony projektowej i wykonania jest zrobiony jak należy, dzięki czemu można z tym działać potem dalej, np. symulacja dymu tak miała :) najpierw powstał symulator dymu, niespecjalnie bogaty, ale wykonany starannie, potem ktoś dodał dodatkowe funkcje dla ognia i jeszcze coś tam podrasował i tak będzie się to powtarzać co jakiś czas.

 

Blender to strasznie duży projekt, to co Ci ludzie z nim robią to jest coś niebywałego. :)

 

Powodzenia z tym knifem, by coś się ruszyło w miarę szybko ;) ja teraz wyczekuje nowego modyfikatora oraz kolizji i automerga w Bevel. :)

[Monio]

Usprawnienia w obsłudze Collady. Całkiem ważna sprawa. Jeszcze tylko żeby colladamax i colladamaya były napisane jak trzeba. ;D

 

Obsługa MDD. Również ważna sprawa w import-export. Teraz będę mógł sobie robić animowane blendshapey w zbruszu. :)

.

 

--------

 

 

Model jest paskudny ale mocap mordki całkiem udany.

Edytowane 21 Styczeń 2013 przez Monio

[n-pigeon]

Obsługa MDD... pff, pfffffff, jak ty żeś to napisał, powinno być:

 

Mesh-cache modifier w Trunk! Obsługuje formaty MDD i PC2! Jeja! \o/

 

wiki: http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Deform/Mesh_Cache

 

To baaaaardzo ważna i przydatna rzecz :D teraz tylko czekać na obsługę Alembic :) Blender wzbogacił się właśnie kolejną ważną "production feature" ;)

 

 

 

Do tego Ton pokazał sneek-peek matcapów, ale kurna czy ja tam widze gauraud shading? Mam nadzieje, że tylko mi się wydaje bo będę zawiedziony...

 

[Monio]

Wolałbyś to na flat shade? Ja tak. Może będzie dało się wybrać. Albo będzie za to odpowiadał shading obiektu.

 

Powiedz mi jeszcze. Jakie szanse na zaimportowanie do blendera bardzo masywnych OBJotów? Mówię o siatkach typu 2 miliony poly. W blenderze za pomocą multiresa mogę taką zrobić ale zaimportować z pliku już nie. Ram i procek? Wyświetlanie w blenderze? Poprawki Bmesha będą miały na to wpływ?

[Nezumi]

Jakie szanse na zaimportowanie do blendera bardzo masywnych OBJotów? Mówię o siatkach typu 2 miliony poly. W blenderze za pomocą multiresa mogę taką zrobić ale zaimportować z pliku już nie.

 

Przed chwila wykonalem tescik - w ZB zrobilem obiekt ktory mial ponad 3.6 miliona poly, eksportnalem do obj (zajmuje 240MB) i... bez problemu zaimportowalem do Blendera (zajelo mu to jakies 15-20 sekund moze). Sculpt chodzi tak samo jak na obiekcie stworzonym w Blenderze (czyli slimaczy juz przy takich obiektach :D). Procek i5-3330, pamiec 8GB.

[n-pigeon]

@Monio

 

Nie, zupełnie nie o to chdzi. Flat i smooth shading raczej będzie działać.

Chodziło mi o to, że obecnie Solid mode może wyświetlać jedynie używając vertex shadingu (gauraud), a mi się marzy opcja z pixel shadingiem (fragment/phong shading), w smooth mode przejścia gradientów miedzy vertexami były by dzięki temu gładsze :/ no nic muszę chyba poczekać na przepisany view port.

 

Co do .obj nie mam pojęcia :B

[Monio]

Nezumi. Win czy linux? Przetestuje z cpu-z jak blender zużywa ram przy takim imporcie. Ja mam 6 giga i może tutaj jest problem.

 

N-pigeon. Są jakieś ramki czasowe na ten przepisany viewport czy nie wiadomo?

[Nezumi]

Monio - pod win7, chwilowo nie mam czasu na instalke linucha.

[n-pigeon]

N-pigeon. Są jakieś ramki czasowe na ten przepisany viewport czy nie wiadomo?

 

Nope, Jason Wilkins od swojego tegorocznego GSoC nad nim pracuje, w tą niedziele trochę dyskutowali o tym projekcie z Tonem.

Prawdopodobnie zostanie finalizowany razem z recodem Dependency Graphu, tyle wiem :D

 

A więc wiadomo tylko tyle, że chodzi o rok 2013 :D

[Idaho]

Nezumi. Win czy linux? Przetestuje z cpu-z jak blender zużywa ram przy takim imporcie. Ja mam 6 giga i może tutaj jest problem.

 

Raczej nie. Przed chwilą dla sprawdzenia zaimportowałem model ok 4.2 mln, plik 246 MB ładował ok 1.5 -2 min i załadował obj. Mam mniej pamięci niż ty, linux 64-bit, build 53842. Co mnie zdziwiło, to to że obracać model jest fakt, ciężko ale pędzle działają szybko (chociaż tyle dobrego).

P.S. sorry za offtop

[n-pigeon]

tutaj nie ma offtopów dopóki chodzi o blendera lub cg ;P

[Monio]

Idacho- To chyba dyskusja na temat blendera wiec raczej on topic. ;)

 

Jason Wilkins od swojego tegorocznego GSoC nad nim pracuje

Znalazłem watek o tym i przeczytałem cały.

To co gość planuje jest boskie. Jeśli zejdzie mu się do końca tego roku to ja grzecznie poczekam, oby tylko wykonał wszystkie swoje założenia. Swoją drogą mega smutna sprawa z tym promilem gości którzy za wszelką cenę chcą odpalać blendera na swoich 8 letnich netbookach i dlatego psioczą na openGL 3. Hobbyści... Dlaczego hobbystycznie nie używają blendera 2.49 przykładowo. Co za pie*** brak wyobraźni.

Postuluje o tryb koloru CGA dla blendera, lubię fiolet z błękitem...

Edytowane 22 Styczeń 2013 przez n-pigeon
wulgaryzmy

[n-pigeon]

W tym roku ma pojawić się nowy silnik viewportu, nie wiadomo ile zajmie jego skończenie, więc na razie trzeba brać to na chłodno ;)

 

Nie przejmowałbym się psioczeniem na OGL 3 i 4, OGL to nie DX :) Jest kompatybilny sam z sobą wstecz ;)

Jak Jason sam tłumaczył, silnik będzie wykorzystywał głównie funkcje OGL 1.1 minus funkcje uznane za przestarzałe i tyle, to jest Core OGL, wszystkie dodatkowe nowsze funkcje to rozszerzenia które mogą być po prostu nieaktywne jeśli użytkownik ma za starą kartę, ale Blender będzie działczył tak czy inaczej.

 

Głównym zadaniem nowego Core Viewportu jest po prostu modernizacja i ujednolicenie kodu, który obecnie używa wielu przestarzałych funkcji i jest rozrzucony po całym Blenderze.

Chodzi głównie o to, by łatwiej było ten silnik konserwować oraz rozszerzać, dopiero następnym krokiem jest dodanie ficzersów/efektów (FX), które mogą spokojnie korzystać z nowszych funkcji OGL.

 

PS

Dla zdrowia psychicznego nie czytaj postów FreeMind'a :P

[floo]

@n-pigeon jaka jest szansa że przy nowym silniku dla viewportu wzrośnie wydajność przy sculpcie?

[Monio]

Spora. Jakoś tak 100% pewności że wzrośnie. ;)

[n-pigeon]

Wzrośnie ogólnie wydajność, w sculpcie pewnie też. Tylko wydajność sculptu nie zależy aż tak bardzo od renderowania poly... jeśli ktoś nie używa eksponatu muzealnego to viewport sculptu spokojnie wyrenderuje miliony poly z tak prostym shadingiem jakiego używa Solid Mode.

 

Wydajność sculptu tkwi w transformowaniu samych vertexów, a więc zależy głównie jak wydajny jest multires modifier i brush engine, a nie sam view port. Oznacza to, że jeśli masz nową kartę, a sculpt działa wolno przy pędzelkowaniu, to wąskim gardłem są obliczenia CPU nie GPU.

Blender przed translacją vertexów za pomocą brusha, wykrywa które vertexy będą brały udział w translacji tak by nie odświeżać całego mesha tylko jego fragment, potem dopiero są te vertexy transformowane do nowej pozycji i to trwa najdłużej, im gęstsza siatka tym więcej trzeba przeliczyć. Potem nowe pozycje tych wybranych vertexów są wysyłane do karty graficznej, by je ponownie wyrenderować.

 

Przyspieszenie view portu sprawi, że obracanie i poruszanie się po scenach gdzie jest dużo poly będzie płynniejsze, podobnie animacja (recode Deps Graphu też przyspieszy renderowanie animacji) oraz Edit Mode który musi rysować znacznie więcej niż Sculpt Mode, ale wątpię by pędzelkowanie zyskało dużego busta w porównaniu do tego ile zyskają inne tryby, ale nie wiem jak bardzo wzrośnie wydajność, tego się dowiemy kiedy ukończą projekt.

 

PS

Dependency Graph również przyspieszy Blendera w różnych miejscach w tym viewport, też warto śledzić co się dzieje.

Edytowane 22 Styczeń 2013 przez n-pigeon

[n-pigeon]

Matcapy w Trunku! :)

 

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport

[mookie]

Proste rozwiązania, a jak przydatne, teraz panel N i Toolbox będą mogły być przezroczyste, zwiększając tym samym widok w 3D View! Genialne w swojej prostocie!

[Monio]

Matcapy oczywiście spoko ale dobór samych obrazków zrobili słabiutki. Tylko 3 z nich jako tako nadają się do sculptowania i modelowania. Reszta będzie wypalała oczy. Zaraz tweetne do tona trochę moich matcapów. ;)

 

Klik do galerii. Renderowane w cyclesie i testowane w zbruszu.

http://www.sendspace.com/file/vdvbos

Edytowane 22 Styczeń 2013 przez Monio