Projekt zu rechenaufwendig, daher unmöglich?

[Fantozzi]

Hallo,
ich hab ne Frage, vielleicht kann mir jemand helfen.

Und zwar will ich ein @ Zeichen mit vielen kleinen @ Zeichen füllen bzw überschütten (siehe Bild).
Leider aber komm ich nicht mal an die Hälfte der benötigten "kleinen" @ da mein Lappi in die Knie geht.
Ich bräuchte wesentlich mehr als nur 300 die ich bisher erreiche, wieviele genau müsste ich abstimmen (ich schätze an die 1000).



C4D hängt sich leider auf bei meinem Vorgehen...
Das sieht bisher so aus:

Ich erstelle ein Text Spline und gebe ein @ Symbol ein. Alle weiteren Einstellungen im Text Objekt belasse ich. Dieses Symbol schieb ich in ein Extrude Nurbs und konvertiere so dass ich nur eine Position im Manager habe (Verbinden+Löschen)
Dieses Objekt kopiere ich, verkleinere es extrem und weise es einem Klon Objekt (Mo Graph) zu. Dort stell ich "Gitter" und "Renderinstanzen" ein, und komme leider bei der Anzahl nicht über 7 7 7 hinaus. Mein Lappi bleibt dann einfach hängen wenn ich auf 8 8 8 gehe.

Ich lasse über "Rigid" Tag die Klone auf das große @ fallen so dass sie sich darin bzw darauf verteilen.
__________

Was kann ich machen damit ich dieses Vorhaben umsetzen kann?
Die Daten meines Systems:
Win 7 64bit
Intel Core Duo 2,26GHz
4GB Ram


Vielen Dank schonmal im Voraus
Ich hoffe mir kann geholfen werden
mfg

 

[Nova_Flow]

AW: Projekt zu rechenaufwendig, daher unmöglich?

passiert das selbe wenn du statt ein 1000 instanzen objekt zwei 500ter oder sogar mehr erstellst?
4gb sind auch nicht unbedingt wenig.

sofern du selbe probleme mit einem kommerziellem objekt hast, kannst du es über eine renderfarm laufen lassen.

 

[LochNess]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Eigenartig, dass der Rechner bereits so früh an die Grenzen geht... Bei vier Gb müsste der das doch schaffen. Die Frage ist jetzt vermutlich doof, aber du hast nicht etwa nebenbei noch ein paar andere Programme laufen?

Um die Anzahl der möglichen @s zu erhöhen, kannst du auch die Polygonzahlen runterschrauben.
Standardmäßig ist beim Spline-Objekt eingestellt, dass ab einer 5%-Abweichung ein Punkt gesetzt wird.
Ich kam dadurch auf 1026 Polygone (kommt natürlich auf die Schriftart an).
Stellt man den Schwellenwert für die Zwischenpunkte auf 25%, sind es nur noch 300 Polygone, also kannst du vermutlich die Menge der @s ungefähr verdreifachen.

 

[CUBEMAN]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Ich könnte mir vorstellen, dass die Simulation das Ganze ausbremst. Man könnte den gleichen Effekt auch mit einem Partikelsystem erreichen.
Außerdem sollten die Zeichen nur so hoch unterteilt sein, wie nötig. (Winkel bei den Spline-Zwischenpunkten erhöhen.)

Grüße, CUBE

 

[Frank_a_Potente]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Mal eine Verständnis Frage:

Ist es nicht so, das die Animation gerendert wird, und dann ein Film (in einem zuvor bestimmten Format) entsteht?

Ist es dann nicht egal, wie viel dort zu berechnen ist?
Dauert das Rendern dann nur viel länger?

 

[Nova_Flow]

AW: Projekt zu rechenaufwendig, daher unmöglich?

das stimmt auch je nach größe des endbildes dauert der rendervorgang.
aber das zu berechnende spielt dabei auch eine rolle. und weder pc den vorgang im ram gar nicht berechnen kann kommt man gar nicht zum rendern, egal in welchem format.
gerade bei kollision und besonders kollision von so vielen objekten dauert das immer etwas. der fall muss berechnet werden, der aufprall auf das große @ und die 1000 kleinen @´s kolledieren auch untereinander. das zieht bei jedem rechnen ram ohne ende.

@
gute idee mit dem partikel ich hätte es warscheinlich genau so gemacht.

am besten ist wenn du das mal ausprobierst. aber vor dem render oder rechenvorgang würde ich neu starten und nichts als cinema offen haben. so hast du maximalen ram zur verfügung (wenn auch alle unnötig im hintergrund laufenden sachen aus sind)

 

[liquid_black]

AW: Projekt zu rechenaufwendig, daher unmöglich?

reduzier die polys soweit es geht . irgendwo is da jedenfalls der wurm drinn ..da sollte deutlich mehr gehen .... du hast das grosse @ auch als verkleinerte version genommen ? denn liegt das an der riesigen polygonzahl ...die kleinen @ zeichen sollten deutlich weniger polygone haben ...die kannste ruhig nen bischen kantiger machen da man die ja nicht so extrem nah sieht .

 

[NT2005]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Hallo Fantozzi,

Wie es besser funktionieren könnte:
Du erstellst bei einem @ nur die Außenkante, dass heißt, du lässt das a im inneren weg. Das brauchst du bei der Berechnung nicht. Also nimmst am besten einen Zylinder und machst die kleine Kerbe rechts unten hinein. Dann animierst du das ganze über MODYNAMICS.
Danach erstellst du die gleiche Anzahl an Kopien mit deinem richtigen @ mit Hilfe von MOGRAPH und gehst dieses Tutorial durch:

Es kopiert die Animation von MODYNAMICS auf KEYFRAMES.

Sollten meine Berechnungen richtig liegen, sollte es damit besser funktionieren.
Solltest du noch Fragen haben, ich beantworte sie gerne für dich.

Bin gespannt was KBB schreibt.

 

[KBB]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Fantozzi woher die Ausbremsung bei Dir kommt, kann man ohne die Datei nur raten, was hier ja fleißig mit vielen guten Ideen gemacht wird. Und selbst mit fehlt einem vermutlich Dein Rechner.
Berechnet werden die dynamischen Effekte mit 1 Prozessor. Bei 4 GB darf er ruhig langsamer werden, aber nicht völlig in die Knie oder abschmieren, vor allem wenn auch schon die beschleunigende Renderinstanz aktiviert ist. Allerdings kommts wie schon mehrfach erwähnt dabei auch auf die Polygonzahl an, die verarbeitet werden muss.

Um festzustellen ob es wirklich die Polygonzahl ist, ersetze die kleinen @ doch bitte vorübergehend durch eine Scheibe mit Stärke: Zylinder auflösen und zurechtdrücken, die in etwa die gleiche Form hat, aber wesentlich weniger Polygone. So ~ 20-30, mehr brauchts nicht.
Der Trick ist, Du kannst die Berechnungen nun mit dieser Scheibe durchführen, und wenn es funktioniert, die Klone "Backen" und danach die Scheibe wieder durch das @ ersetzen. Das dann vermutlich deutlich abgespeckt werden muss, denn wenn das so funktioniert, liegt es wirklich an der Polygonzahl.



Cube MoGraph ist ein Partikelsystem
Was die Dynamics betrifft, das imo schnellste in Cinema.

Ist es nicht so, das die Animation gerendert wird, und dann ein Film (in einem zuvor bestimmten Format) entsteht?

Das Rendern ist die Entstehung des Films

Aber es gibt zig Dinge, die wie in diesem Fall automatisch ablaufen, die das Programm vorberechnen muss, bevor das eigentliche Einzelbild berechnet werden kann.
Bei den meisten Dingen im Alltag fällt das nicht auf, aber falls Dir Hyper- oder Sweep-NURBS, oder prozedurale Objekte und Texturen, Boole, Partikel usw. was sagt - das sind alles Dinge, die vor dem eigentlichen Rendern passiert sein müssen. Und zwar jeden Frame.
Alles, was später sichtbar sein soll (Geometrie) wird intern in Dreiecke umgewandelt. Dazu müssen sie aber erstmal Geometrie werden, sprich aufgelöst. Partikel müssen brav von vorn nach hinten durchgerechnet werden, Booles in ein Objekt überführt, prozedurale Shader in eine Bitmap im Speicher gehalten.
Und bei MoGraph muss halt erstmal jede Menge geklont und dann jedes Klon in Geometrie überführt werden, erstmal ist auch das nur prozedural, also gerade eben frisch errechnet

Bin gespannt was KBB schreibt.

*huch* da war noch der NT dazwischen

Zur Berechnung wird das Innere beim @ in MoDyn nicht herangezogen, nach innen gerichtete Flächen werden m.W. komplett vernachlässigt. Deshalb kann man überhaupt auf geringer aufgelöste, "gedeckelte" Formen zurückgreifen.
Ich nehme die grobe Form wegen des Tempos, nicht wegen der Löcher die imo keine Rolle bei MoDyn spielen.

Ich weiß nicht, ob es wirklich eine gute Idee ist, jedes Keyframe zu backen. Es spielt vermutlich keine große Rolle, wenn die MoDyn schon gebacken ist, aber das @ so eine riesiege Polygonzahl hat. So rund wie das ist, hat es die.

 

[NT2005]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Hallo KBB,

Also erstellt MODYNAMICS nur eine Hülle um dem Objekt und lässt die Fuge zwischen dem a und dem Ring um das a außen vor?

Ob man backen oder einen Cappucino bevorzugt, ist egal sobald das Ergebnis stimmt.

 

[KBB]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Also erstellt MODYNAMICS nur eine Hülle um dem Objekt und lässt die Fuge zwischen dem a und dem Ring um das @ außen vor?

M.W. ist das so, ja. Versuch mal, ein paar Ringe wie Kettenglieder ineinander zu stecken und die per MoDyn schwingen zu lassen - es geht nicht ohne Trick, weil MoDyn das Loch des Kettengliedes nicht "sieht". Dazu gabs erst vor Kurzem ein schönes Tutorial vom GreyscaleGorilla (OK, das war im Januar ).

Man könnte zwar die echte Geometrie für MoDyn nutzen, indem man im Rigid Body "Statisches Mesh" angibt. Nur hier wird die komplette Geometrie zur Berechnung herangezogen. Aber hier wird auch nichts mehr bewegt, denn wie der Name sagt, ist das Mesh dann statisch, also ruhend - das Objekt ist nur noch Kollisionsobjekt.

Ob man backen oder einen Cappucino bevorzugt, ist egal sobald das Ergebnis stimmt.

Auf das Ergebnis selbst ergeben die beiden Wege keinen Unterschied. Fraglich ist nur, ob der Rechner beide Wege bis zum Ergebnis schafft Aber wahrscheinlich ist der Unterschied nicht sehr groß, vielleicht sogar zum Nachteil von MoGraph, da hier ja noch die Klone erzeugt werden (sonst könnte man sie nach dem Backen nicht einfach austauschen), auch wenn ihre Position, Drehung und Skalierung schon feststeht.
Das Backen der Keyframes per Cappu ist aber optimal, wenn man z.B. die Animation per FBX oder MDD in ein anderes Programm transferieren möchte.

 

[Yorker]

AW: Projekt zu rechenaufwendig, daher unmöglich?

...vor allem wenn auch schon die beschleunigende Renderinstanz aktiviert ist...

Renderinstanzen schonen lediglich den Arbeitsspeicher. Wer also genug Arbeitsspeicher hat, wird durch Renderinstanzen keine Beschleunigung feststellen.

 

[KBB]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Beschleunigung der Bildanzeige, aber sicher
Ah, und das Rendern wird natürlich auch beschleunigt ...

 

[Fantozzi]

AW: Projekt zu rechenaufwendig, daher unmöglich?

VIELEN LIEBEN DANK FÜR DIE ZAHLREICHEN TIPPS!!!
Natürlich hab ich nebenher keine unnötigen Programme offen, das kenn ich ausm Musik bereich.

Ich werd alles mal im laufe des Tages und Abends ausgiebig testen und dann bescheid geben woran es lag (hoff ich).

Ich hab wie gesagt, in Sachen unterteilung usw alles auf standard gelassen, ich hab nur die Veränderungen vorgenommen die im Anfangsthread auch stehen.
Die spätere Auflösung sollte bei ca 6000x4000 liegen....vielleicht noch als brauchbare Info

Danke nochmal an jeden einzelnen, ich werd alles austesten.
mfg

 

[Nova_Flow]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Wow die größe als video?!
kannst du natürlich machen, aber wo soll das denn in oreginal größe laufen?
sind 3000x2000 nicht völlig ausreichend?
ist ja auch unnötige render zeit

 

[nux95]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Hatte ganz ehrlich keine Lust ALLES durchzulesen, aber Mozilla hat für mich das Wort Cache hier noch nicht gefunden also denke ich es ist noch nicht gefallen

Natürlich kann es auch an der Polygonzahl liegen, allerdings ist die Berechnung ebenfalls rechenintensiv.
Versuche es mal mit dem MoGraph Cache Tag und backe die Simulation.

Wenn die Polygonzahl den RAM deines Lapotops übersteig könntest du die Simulation mit einem niedrigeraufelösten @-Objekt berechnen lassen und fürs finale rendering austauschen. Ist allerdings kein ersatz für gute Qualität

lg nux95

EDIT: Ok ich sehe backen ist schon drangewesen.
@NT2005 Wenn cih mich nciht irre muss man mit dem Cache Tag keine Keyframes erstellen. Es können die Objekte unter dem Klonobjekt ausgetauscht werden und der Animationsablauf bleibt gleich, meines wissens. Somit vllt etwas praktischer

 

[Yorker]

AW: Projekt zu rechenaufwendig, daher unmöglich?

Beschleunigung der Bildanzeige, aber sicher
Ah, und das Rendern wird natürlich auch beschleunigt ...

Das widerspricht meinen Erfahrungen. Die Cinema-Hilfe dürfte mir da ebenfalls zustimmen, wenn ich mich recht erinnere.

 

[Fantozzi]

AW: Projekt zu rechenaufwendig, daher unmöglich?

nein nein, kein video....einfaches bild....
das wäre ja X größer als HD

 

[KBB]

AW: Projekt zu rechenaufwendig, daher unmöglich?

@ Yorker

Bildanzeige: Nimm einen Kloner-Gitter mit beispielsweise 10x10x10 einfachen Kugeln, Boden drunter, beides mit Rigid Body versehen, und lass die Animation laufen. Die 1.000 Kugeln sollten schon ausreichen, um das Bild ruckeln zu lassen.
Stell dann im Klon auf Renderinstanzen um. Die Abspielfrequenz verdoppelt sich sofort. Hast Du einen schnelleren Rechner, vergrößere die Kugelanzahl bis es ohne RI schleppend wird.
Wenn sich nichts beschleunigt, liegt das an langsamem Rechner oder Graka, normalerweise tut es das sofort und spürbar. Und steht auch irgendwo in der Hilfe, aber nicht unter Klon.

Renderinstanz: sicher schonen die den Speicher. Dem Renderer ist es mit eingeschalteten RI nahezu egal, ob da nu 1 Baum zu rendern ist oder 200 da stehen, und mehr Instanzen rendern auch länger, aber nicht mit linearem Zeitzuwachs.
Spannend wirds in dem Moment, wo RI abgechaltet ist und hochauflösende Objekte den Speicher knacken - wie das hier offensichtlich der Fall ist. Die 200 Bäume bekommst Du dann u.U. garnicht mehr am gleichen Tag zu sehen, bestimmt nicht bei einer Auflösung von 6.000x4.000
Denn dann wird ohne RI fleißig ausgelagert, und das dauert
Wenn man Glück hat, wird nur ausgelagert. Manche Szenen sind garnicht erst renderbar ohne RI.

Wenn cih mich nciht irre muss man mit dem Cache Tag keine Keyframes erstellen. Es können die Objekte unter dem Klonobjekt ausgetauscht werden und der Animationsablauf bleibt gleich, meines wissens. Somit vllt etwas praktischer

Auch das stand schon da, nux

 

[Fantozzi]

AW: Projekt zu rechenaufwendig, daher unmöglich?

SUUUUPER !!!!!!!!
Ich bin gerade endlich dabei zu testen (war heute nicht am PC wegen Privatem usw....) und es fühlt sich schon ganz anders an hab eben von der Anzahl her 10 10 10 genommen und mein Rechner atmet noch ruhig Das hab ich erreicht in dem ich den Winkel Wert der kleinen @ wie vorgeschlagen auf 25° gestellt habe. Nachm Rendern werd ich dieses Wert evtl noch abstimmen und die Anzahl der @ aber es ist schonmal ein sehr sehr sehr großer Schritt bzw Sprung nach vorne

ich halte auf dem Laufenden
vielen unendlichen dank nochmal
mfg

edit: muss nur noch rausfinden woran es liegt dass die kleinen @ durchfallen....das hab ich hoffentlich bald rausgefunden, ohne hilfe
edit²: gut ich habs

Aber eine Frage hätte ich noch, die kleinen @ dringen etwas durch den Boden durch, also sie sind auf der Unterseite des Bodens sichtbar.
Ich hab mir aber auch schon überlegt einen "doppelten Boden" in das @ einzubauen, so dass die kleinen nicht das gesamte Objekt füllen müssen...es ist ja im Endeffekt nicht transparent...