Was ist denn mit DPIT Simple Particles?
Es ist einfacher… ;O) Wie von mir schon beschrieben, berücksichtigt es immer die aktive Selektion und erzeugt die Verknüpfungen von selbst. Außerdem ist es durchdachter - alles geht mit allem. Houdini ist genau so.
Aber bitte doch. Du bist mit Sicherheit nicht allein. Vielleicht hat Jack einfach noch nicht mit anderen Programmen gearbeitet um zu sehen, dass es auch einfacher geht. Aber lass uns friedlich beliebn, sonst werden dass hier wieder Diskussionen wie “AR ist doch ganz gut…” (weil was anderes noch nie benutzt wurde)…
Mylenium
Doch, ich schaue mir durchaus andere Programme an. Ich finde nur ehrlich gesagt Maya schrecklich. Klar, mächtig und offen und all das, aber die Bedienung und die GUI schreien mir “Benutz mich nicht” entgegen.
Vielleicht liegt es einfach daran, dass ich mir die Software kaufe, mit der ich gut arbeiten kann. Ich hol mir nicht erst Cinema und beschwer mich dann über die Usability und die Features.
Generell finde ich den Vorwurf, die Leute fänden Cinema nur gut, weil sie nichts anderes benutzt hätten, völlig idiotisch. Vielleicht sind nur andere Leute in der Lage, mit AR gute Bilder zu erzeugen (bzw. mit TP gute & schnelle Partikel-Setup zu erstellen), während Ihr das nicht beherrscht.
Ich habe mir auch unbiased Renderers wie Indigo angeguckt, und ich muß es sagen: Es sieht von allein zwar realistischer aus, als ein unoptimiertes AR-Bild, aber um da eine vernünftige Rendergeschwindigkeit hinzubekommen, muß ich genau so lange an der Szene rumdoktern, wie ich bei AR für das Lichtsetup brauche. Nur kann ich in AR danach schnell nochmal neu rendern, wenn ich an der Szene was verändert habe. Bei unbiased Engines dauert das dann wieder 2 Tage.
Fazit: Ob es um Partikelsysteme oder Renderer geht: Hört auf, Euch über Cinema zu beschweren; niemand zwingt Euch dazu, es zu benutzen. Wenn es Euch nicht gefällt oder Ihr damit nicht umgehen könnt, benutzt halt was anderes. Und informiert Euch vorher, wofür Ihr Euer Geld ausgebt, sonst werden Ihr wieder enttäuscht.
Grüße,
Jack
Na ja, es gibt wohl kaum eine Software, die ALLES zur Zufriedenheit des Benutzers umsetzen kann. Und wenn es hier und da Bereiche gibt, die (durch eine große Anzahl an User Feedback) offensichtlich überarbeitungswürdig erscheinen, dann ist das nunmal so. Aussagen wie “Benutzt halt was anderes” sind der Weiterentwicklung auch nicht gerade dienlich 
Gruß,
Andreas (der TP und XPresso auch nicht besonders mag)
Klar, seh ich schon ein. Ich versteh nur nicht, dass die Leute jahrelang bei einer Software bleiben, über die sie immer nur jammern. Wenn ich so viel über XPresso, TP und AR jammern würde, wie andere hier, dann wär ich längst auf ne andere Software umgestiegen.
Grüße,
Jack
Auf der “anderen Seite” gäb’s dann genauso viel zu Jammern …
weil wir hier in deutschland sind und weil andere software noch
komplizierter ist. in maya muss man richtig programmieren können,
wenn man das partikel system ausbauen will. houdini td’s gibts
nur zwei oder drei auf der kompletten welt und wenn ich an
tp in max denke muss ich mich schütteln: mein rekord waren
damals bei scanlie 43 abstürze an einem tag! wenn man einmal
aus versehen alle nodes aus dem bild scrollte, hat man die nie wieder gefunden und konnte nochmal neu anfangen etc pp
(damit ich nicht verklagt werde: das ist jetzt natürlich in tp 3 alles
etwas besser! )
aber ich verstehs auch nicht. die kommentare sind zwar berechtigt..
tp ist nunmal kompliziert, aber man kann auch tp nicht mt einem
ultra simplen partikel system wie zb trapcode für aftereffects vergleichen.
das sind zwei komplett verschiedene systeme. da wäre ein vergleich
mit unserem standard particlesystem angebrachter.
dem könnte maxon gerne mal ein update verpassen!
und wer mehr funktionalität will, soll eben tp richtig lernen oder die
tollen presets von björn verwenden, aber nicht dauernd meckern!
ich lese hier immer “meckern” und “jammern”, und das das ja so schlimm ist.
ich benutzte cinema weil es eigentlich recht simpel und “designerfreundlich” ist und auch damit wirbt.
der thread stellt indirekt die frage, was man sich als nächstes wünscht, und ich wünsche nunmal ein einfach zu bedienendes partikelprogramm in dem 3D tool meiner wahl, was ist denn daran falsch?
ich finde, danach zu fragen völlig legitim.
btw, man konnte auch mit mokka2 chars animieren, was denkt ihr, warum maxon dennoch mokka3 rausgebracht hat… manmanman…
Na da hätte ich aber gerade von dir anderes erwartet. Du läßt dich da an der falschen Stelle von rein kosmetischen Unzulänglichkeiten abschrecken.
Deine Wortwahl läßt zu wünschen übrig. Kein Mensch “beschwert” sich oder “jammert”. Es muss aber dennoch erlaubt sein, objektiv-analytisch Schwächen in Funktionen und Implementationen darstellen zu dürfen. Derartige Gedankenspiele gleich als Entwertung der selbigen darzustellen und uns mit unseren vermeintlich mangelnden Kenntnissen zu konfrontieren sind lahme Klischees, nichts weiter. Ich könnte mich jetzt auch hinstellen und sagen: Ätsch, ich kann MoGraph besser als du, aber das bringt uns beide nicht weiter.
Und ich möchte mir auch mal erlauben, einen Gedanken anzubringen: Veränderung und Verbesserung fängt auch mit den Usern an. Es bringt überhaupt nix, wenn Leute sich hier hinstellen und sagen: Das Tool ist gut, nur die User zu blöd. Es bringt die Entwickler überhaupt nicht weiter, wenn sie sich in trügerischer Sicherheit wiegen, aber vielleicht doch generell was ganz Falsches entwickeln.
Ich gebe gern zu, dass ich Zyniker aus Überzeugung bin und vielleicht zu den ewig Unzufriedenen gehöre, aber du solltest mal darüber nachdenken, dass wenn von 10 Usern 5 Einwände erheben, dass mindestens genau so viel Wert hat wie die 5 anderen User, die uneingeschränkt begeistert sind.
Man kann nicht alles auf mangelnde Fähigkeiten und Kenntnisse schieben, manchmal ist es eben doch die Software.
Mylenium
Nein, muss man nicht. Keiner zwingt einen, MEL zu benutzen, solange man nicht will und wenn du an tiefere API-Programmierung denkst, ist die Situation nicht anders wie in anderen Programmen.
Macht doch keiner. Die Kernfrage ist doch auch eine ganz andere: Könnte TP nicht benutzerfreundlicher und noch leistungsfähiger implementiert werden? Ich denke schon und das its eigentlich alles, was Maxon nun mal endlich lernen muss. Schöne Features zu haben und ein Modul nach dem anderen rauszubringen ist ja alles schön und gut, aber ohne wirkliche übergreifende Integration und einfache Bedienbarkeit nutzt das überhaupt nix. Andere machen vor, wie es besser geht und irgendwann muss doch mal einer merken, dass sich C4D mit seinem Beharren auf bestimmten Prinzipien selsbt im Weg steht.
Mylenium
Eigentlich hatte die Kernfrage mit dem Osterhasen und der Siggraph zu tun
Nein im Ernst: Ich wusste gar nicht, dass so ein großes Bedürfnis nach einem überarbeiteten Partikelsystem besteht, mir kommt vor in den Foren werden auch relativ wenig Fragen dazu gestellt. Vielleicht heißt das aber auch nur, dass es die wenigsten nutzen…
Du hast schon recht, TP ist schon sehr eigen in der Bedienung, man braucht für die simpelsten Dinge ewig (zB einen Partikeleffektor mit Falloff einstelln… na gute Nacht). Vielleicht sollte Maxon aber da eher das Standard-Partikelsystem um einige Dinge wie Kollisionen/FollowSpline etc. erweitern, anstatt da TP komplett umzukrempeln. Das würde dem Großteil der User reichen, und für Hardcore-Partikelsachen mit absoluter Kontrolle muss man eben an TP ran. Heißt aber nicht, dass Maxon es nicht auch vereinfachen/erweitern sollte.
Also da muss ich dir widersprechen. Gerade die letzten Module wie Hair oder Mograph zeigen, dass die Integration wirklich gut funktioniert. (Habe nicht so viel Erfahrung mit Mograph, aber mit Hair hatte ich jedenfalls keinerlei Probleme im Workflow. Das einzige was ich zu beanstanden habe ist, dass es mittlerweile 4 verschiedene Kollisons-Tags gibt, jedes Dynamics-System seine eigene Gravitation, Wind, etc hat, obwohl sich sogar da die Effektoren vom Standard-Partikelsystem verwenden lassen. Das ist meines Wissens nach in anderen Programmen auch nicht anders gelöst, da braucht auch jedes Dynamics-System seinen eigenen Solver und Kräfte.)
Und die R10 hat gezeigt, dass auch das nicht zutrifft. Gesamte Timeline neu, gesamtes Mocca neu, wo lässt sich da behaupten, dass Cinema auf bestimmten Prinzipien beharrt?
Und die meisten Workflow-Prinzipien, nach denen C4D arbeitet, sagen mir persönlich sehr zu. Drum verwend ich es.
lg
Günter
Ja, Hair und Mocca3 sind schon genial. Da ist es doch nur normal, das man darauf wartet, das die übrigen Module da gleichziehen. Bei jedem Update erwartete ich, das Dynamics mal richtig integriert wird. Aber es bleibt ein grauenvoller Fremdkörper. Naja, mir ist’s egal, ich hole mir bald PhyTools und Co., dann pfeif’ ich drauf 
Ja eben, genau das ist der springende Punkt: Wie dämlich ist es eigentlich, für jedes Modul ein eigene Kollisionsroutinen schreiben zu müssen und die User mit zusätzlichen Tags zu belästigen? Sowas sind Dinge, die müssen auf elementarstem Level in der API gelöst werden Und ein Programmierer schreibt dann nur noch ein #include collision_detect.c in seinen eigenen Code, egal ob er nun Dynamics programmiert, eine Gameengine oder Modelingtools mit Snapping/ Surface Placement.
Genau das hat Maxon aus meiner Sicht nicht drauf, aber wie sollte es auch - solange ganze Module von nur zeitweise eingekauften Leuten entwickelt werden, wird sich das nicht ändern - leider. Natürlich kann man guten Willen hier und da erkennen und es tut sich ja auch was, bloss manchmal kommt’s mir trotzdem noch ein bissl wie in dem berühmten Spruch vor: Vorne was aufbauen und hinten mit dem Arsch einreissen. Gerade die R10 mit ihren vielen Bugs hat bei allem Guten auch das bewiesen.
Mylenium
Ich bin kein Programmierer und daher ist es mir relativ egal wie es implementiert ist, solange es schnell genug ist…
Und was die zusätzlichen Tags betrifft: ob ich jetzt eines mehr oder weniger hinzufüge, ist denke ich wirklich nicht der Rede wert und bremst den Workflow nicht wirklich. Zudem ermöglichen mehrere Tags, dass ich zB unterschiedliche Reibung für Hair und Cloth am selben Character einstellen kann… natürlich wärs praktischer, das alles in einem einzigen Tag zusammengefasst zu haben, aber für mich ists so wies jetzt ist kein großes Hindernis.
In der R10 wurde offenbar viel im Core geändert, wenn das ganze Animationssystem neu geschrieben wurde. Das hat sich eben in einigen Bugs bemerkbar gemacht, aber das lässt sich wohl kaum verhindern wenn derart gravierende Änderungen gemacht werden. Besser so, als gar nicht geändert.
Woher hast du denn die Info dass Maxon Leute zeitweise zukauft, um sie Module entwickeln zu lassen? Mich würd so ein bisschen Hintergrundinfo schon interessieren…
lg
Günter
Kann man drüber streiten. In der Tat gibt es 'ne ganze Menge verschiedene Algorithmen für Kollisionserkennung, selbst für Rigid Bodies gibt es allein schon mehrere Ansätze, allerdings lägen aus meiner Sicht die Vorteile einer globalen Implementation auf der Hand: Wird diese erweitert, können alle Komponenten diese Verbesserungen ohne eigene Änderungen oder nur mit geringen Änderungen nutzen. Dass das im Moment so nicht geht, ist mir schon klar, weil es eben auch bedeutet, dass die gesamte Dynamics-Schiene ein ganzheitliches Konzept bräuchte.
Was die Steuerbarkeit angeht, sehe ich keine Probleme - dafür könnte man einen “Dynamics Relationship Editor” wie in Maya implementieren oder aber jedes Objekt mit einem Wichtungsattribut versehen, dass die Verwendung und Intensität der Dynamics steuert. Isses 0 gibt’s keine Kollision, isses 1 gibt’s eine, Bei anderen Attributen gäbe es noch Werte dazwischen die als Multiplikatoren z.B. für Reibung dienen um beispeilsweise durch Verringern der Werte eine Slowmotion bei trotzdem physikalisch korrektem Verhalten ermöglichen.
Soweit ich informiert bin, wurden Sketch & Toon und Hair von externen Leuten entwickelt, die nicht fest von Maxon angestellt sind. Das müßte aber bekannt sein, ich habe die Info auch bloss von CGTalk. MoGraph wurde ganz offensichtlich zu großen Teilen von Per-Anders Edwards entwicklet, der auch in der R10 seine Finger drin hatte. In welchem Verhältnis der derzeit zu Maxon steht, weiss ich nicht.
Man muss allerdings fairerweise sagen, dass solches “Remoting” nicht unüblich ist, der Unterschied ist aber, dass bei anderen Herstellern die Arbeitsteilung anders ist. Leute entwicklen keine kompletten Module/ Komponenten, sondern nur einzelne Technologien die dann einheitlich von einem festen Team implementiert werden.
Um mal beim Beispiel zu bleiben: Es wäre also unter diesem Aspekt sinnvoller, wenn ein Entwickler nur die mathematische Seite von Thinking Particles beackert und ein anderer im Kernteam die Implementation übernimmt, ohne dass dann dabei “Geek Stuff” rauskommt. Letzten Endes würde dass schon eine zusätzliche Möglichkeit der Verbesserung bringen: Da der Mensch, der die XPresso-Boxen programmiert, schon ein Resultat vorgelegt bekommt, kann er eventuell unverständliche Dinge früher entdecken und Feedback für Änderungen geben.
Nun ja, aber beenden wir das jetzt. Ist letzten Endes nicht unser Bier. Irgendwie kriegt’s Maxon ja vielleicht doch mal hin.
Mylenium
ich habe bis vor zwei tagen auch über TP geschimpft da ich es mir schlicht und ergreifend nie richtig angeguckt habe. na ja die letzte nacht war lang aber hat auch licht ins dunkel gebracht, hätte nie gedacht TP könne spass machen.
ich kann nicht sagen ob es gegenüber anderer software langsamer ist aber ich finde es jetzt toll so ein komplexes partikel system zu haben.
aber eins ist sicher das standard system sollte verbessert werden - nur nen setup für einen wirbelsturm wird man nicht sonderlich benutzerfreundlich gestalten können.
für die ersten schritte hat mir dieser workshop sehr gut weitergeholfen
( http://www.amanda3d.de/content/download/tp_tutorial/tp_tutorial.pdf )
gruß 3ddd ( der, bei dem jetzt die partikel regnen)
Das ist aus programmiertechnischer Sicht so nicht machbar, um das freundlich zu formulieren. There’s no free lunch.
Wenn Du Deine gloable Implementation erweiterst, musst Du dann zwangsweise in allen Modulen die Implementierungen nachziehen, sonst ist Dein schönes Konzept leider wieder Toast.
Es gibt ein solches “ganzheitliches Konzept” auch einfach nicht, weil man es nicht für alle möglichen Wechselwirkungen im voraus coden kann (und nicht zuletzt wäre das Ganze nicht performant). Die Kollisionen von Festkörpern, Partikeln, Splines etc. sind prinzipiell bedingt einfach unterschiedlich zu handhaben, und diese Methoden sind untereinander nicht beliebig kompatibel.
Was allerdings schön wäre, wenn das aus Benutzersicht ähnlicher aussähe, so dass man sich nicht mehr als nötig mit den Unterschieden auseinander setzen müsste.
Aber m.E. krankt Dynamics nicht in erster Linie an schlechter Integration, sondern an schlechter Bedienbarkeit, v.a. wenn man das mal mit PhyTools/SB vergleicht.
Kabe
Ups, das meinte ich eigentlich auch mit Integration. Warum muss ich auf ein Dynamics-Tag doppelklicken damit so ein dämliches Fenster auftaucht? Wieso steht der Kram nicht im Attribute-Manager? Cinema-Steinzeit ist das!
Dynamics ist aber auch lahm im Vergleich zu PhyTools