Beiträge von TroY

Ah, jetzt weiß ich auch, was "Buoy" ist. Okay, da lehne ich mich jetzt mal nicht so weit aus dem Fenster. Bevor ich damit was "public" mache, will ich erstmal bisschen Erfahrung damit haben ...

Nichtsdestotrotz poste ich gleich mal im SF 'ne leicht überarbeitete Version. Mal schauen, was Bob dazu sagt, ein (grober) Verbesserungsvorschlag ist es ja so oder so.

Hab die Dropdown-Listen jetzt noch mit "Funktion" belegt, sodass er bei Auswahl eines Eintrags automatisch auf die Detailseite dieses Objektes geht.

Naja, mal sehen. Vll hat er ja ganz andere Pläne.

Zitat

Original von axolotl
WOW ! Gibts die schon ?

Sowas gibt's einerseits schon lange - andererseits aber in jüngerer Zeit auch für den "Normalmenschen" erschwinglich in Form von zwei Intel Xeon- oder jetzt AMD Opteron-Prozesseren, welche jeweils 4 Kerne haben. Ich warte eigentlich nur noch, damit die Preise noch weiter fallen können.

Typischer Fall von "8o".

Zweiter Hintergrund gefällt mir jetzt besser.

Also zum RF-GUI kann ich jetzt nicht so viel sagen - die Shots sehen für meine Augen jetzt gar nicht soooo schlimm aus. Man muss halt irgendwie sehr viele Optionen unter einen Hut kriegen und dabei halbwegs den Workflow berücksichtigen ...

Ich hab' mal was ganz Kleines gebaut und würde folgendes vorschlagen: Nachher mal ein kleiner Post im SF, was Bob überhaupt zu der Idee sagt. Wenn er "das" (konkretisiere gleich, was ich überhaupt gemacht habe) für gut befindet, können wir hier ja Ideen sammeln und ich versuche, das Dings erstmal so weit wie möglich unseren "Bedürfnissen" gemäß auszuarbeiten.

Die Sache ist nämlich, dass ich atm noch überhaupt gar keine Ahnung von Scripting in AoI habe und daher erstmal nur eine ganz normale Java-Anwendung gebaut habe. D.h. also, den jetzigen Code wird er keinesfalls einfach so einbauen können (selbst wenn er wollte), er wird bestenfalls eine Idee davon gewinnen können, was wir meinen. Ich würde mich dann bissel in das Thema reinfriemeln und - im Idealfall, falls er mir die Source zugänglich macht und wenn ich mich "fit" genug zu fühle (d.h. erstmal paar Testplugins schreiben, etc pp) - dieses GUI dann direkt ins Plugin übertragen. Wie gesagt, falls. Kann ja auch sein, dass er da lieber alleine weiterschafft, hat ja jeder andere Vorlieben.

In meiner Version sieht man hauptsächlich nur die Hauptänderung, die ich mir wünsche: Nämlich, dass die ComboBox zur Auswahl des Objekttyps möglichst direkt zugänglich ist.

Starten tut man das Ding ganz normal, "java -jar fluidGUI.jar" - den Output auf der Konsole kann man getrost ignorieren.

Meinungen?

(Falls wir dieses Thema weiterverfolgen, vll 'nen eigener Thread?)

Zitat

Original von vidiot
Ich finde sogar der erste Reiter hat sich zurückentwickelt!

Die Tabellenübersicht war doch klasse! Gerade wenn ich mehrere Objekte habe.

Seine Argumentation versteh' ich aber auch. Bei den vielen verschiedenen Typen, die es mal geben wird, klappt 'ne Tabelle nicht mehr. Hm, ob ich mich mal an Java setze und mir eine "gescheite" GUI überlege?

Zitat

PS: Ja - ich glaube auch - das sich bald mehr Leute zum Spielen finden - insbesondere wenn die nächsten Versionen tatsächlich Softbodies und Rigidbodies unterstützen und wir mit Softballs und Wasser kegeln können.

Darauf freu ich mich auch schon.

Rendern per Raytracer wird übrigens erheblich beschleunigt, wenn man die fein unterteilten TriMeshes nur zum Backen benutzt und sie für das End-Bild versteckt ... das mit den Grids bringt auch nochmal einen großen Schub, wodurch aber leider auch die flüssigen Oberflächen kantiger werden.

"Mesh preview" hab' ich soeben beim Schreiben dieser Zeilen geblickt - sehr praktisch. Wenn auch rechenintensiv.

XSPH ist bei mir allerdings bei ein paar Tausend Partikeln unbrauchbar langsam.

thx

Zur Renderzeit: Das liegt hauptsächlich an der frühen Version des Fluid-Plugins, vorallem im Zusammenhang mit AA und sonstigen Effekten - eine Vor-Version des Bildes hat in derselben Auflösung nur eine Stunde gebraucht. Rendern von Fluids ("Backen" geht in ein paar Minuten) wurde aber im Vergleich zur Vorgängerversion des Plugins schon erheblich beschleunigt und wird in Zukunft auch noch besser werden ... im Moment braucht man halt noch Geduld.

(Aber mein X2 4200+ wird im nächsten Frühjahr eh durch 'ne 8-Kern-Maschine ersetzt. :P)

Verwendete Programme: Art of Illusion 2.5.1 (Fluid Simulation Beta 0.6), GIMP

Erstes "richtiges" Bild meinerseits mit Fluids.

Coole Materialien. Fehlt nur noch die FluidSim.

Wurschtele schon fleißig damit rum.

Verstehe das meiste Neue aber noch nicht so richtig - kommt bestimmt noch. Und das neue GUI find' ich allerdings etwas, naja, "klick-intensiver".

Zitat

aber im Augenblick denke ich spielen nicht zuviele Leute außer Troy und mir damit?

Befürchte ich auch. Aber wird sich sicherlich noch ändern. :winke1

lol, super

Und die Kuh freut sich noch ...

Sorry für den Doppelpost, aber habe etwas zu berichten.

Man erinnere sich bitte kurz an das Rückstau-Problem am Ende von Rampen (das hier). Man kommt denkbar einfach zu einem "sauberen Abgang", wenn man sich kurz überlegt, wie das Plugin arbeitet: nämlich hauptsächlich auf Partikel- und damit Vertexebene.

Bild 1 im Anhang zeigt das Ende meiner Rampe und man sieht, dass auf der "Rutschfläche" recht wenige Vertices sind - an der Kante dagegen recht viele, bedingt durch die Rundung und das Subdividen.

Bild 2 zeigt nun, wie dieses Rampenende für die ankommenden Partikel aussieht. Überall, wo vorher ein Vertex war, ist jetzt ein Blob. Auf der Rutschfläche ist also fast nichts, kaum Widerstand - und bedingt durch die Gravitation zieht es die fließenden Teilchen auch ein bisschen in die "Fläche" hinein. Sieht man ja auch auf dem Video oben, die Dinger sind richtig an die Rutsche gepresst. Hinten an der Kante finden sie aber plötzlich eine Barriere vor, durch die wesentlich höhere Dichte. So kommt es zum Rückstau.

Also klar, da sind zu viele Punkte. Sprich, beim Modeln bis zuletzt Smoothing auslassen - vorallem beim Subdividen, da der TME sich sonst an die Rundung anzupassen versucht und noch mehr Vertices erzeugt. Und natürlich die Kante ganz am Ende nur sehr wenig bis gar nicht subdividen.

Ich habe das mal gemacht und hier ist das Ergebnis: Nur noch leichter Rückstau (an den Seiten war mir das zu viel Friemelei...) und wesentlich besseres Abfließen. Es bleibt in der Mitte fast nichts mehr hängen oder fließt sogar zurück.

Bild 3 im Anhang zeigt die modifizierte Rampe.

Schätze mal, dass das auch in Zukunft noch eine Rolle spielen wird - es sei denn, delt0r zerlegt alle "Obstruction"-Objekte von grundauf neu, sodass sich eine gleichmäßige Vertex-Verteilung ergibt. Oder wollte er das auf Basis von Meshes machen? (hab' da nicht so den Überblick...)

Naja, bei 0.5 und 0.5 ist natürlich keins größer als das andere, das stimmt schon. So gesehen macht es auch in gewisser Weise Sinn, dass bei einem derartigen Vergleich "nichts" herauskommt.

Ein größer-gleich wäre sicherlich sinnvoll. Oder eben eine einfache Korrektur, damit es mit dem Manual übereinstimmt: "Greater Than returns 1 if the top input is greater than the bottom and 0 otherwise." Wie gesagt, im "otherwise" steckt imo auch der Fall, dass beide gleich sind.

Von der Programmierersicht ist es aber schon seltsam. Normalerweise hätte ich naiverweise etwas wie "if (a > b) { ... } else { ... }" erwartet, was dann halt darin resultiert, dass bei Gleichheit auch der "else"-Teil ausgeführt wird. Ein Blick in den Quellcode zeigt aber, dass dieser simple Vergleich lange nicht so "trivial" ist und dass (soweit ich das sehen kann) wirklich auch ein spezieller Fall dafür vorhanden ist, wenn beide Werte gleich sind. Was genau dann der Wert ist, kann ich aber nicht sagen, dazu weiß ich vom AoI-Code zu wenig ...

Wie auch immer, ich poste das mal im SF.

-edit: Peter meinte, dass es wohl einfach zu fixen sei und er es in der finalen 2.5.1 aufnehmen will.

Zitat

Original von vidiot
Warum? S. Blender - was erwarten die Leute von Blender, obwohl (oder weil?) es kein kommerzielles Produkt ist?

1:0 für dich. Bin da immernoch (ungewollt) sehr "konservativ" und denke immer sofort, "Leistung hat auch seinen Preis" - aber Blender ist natürlich ein Paradebeispiel für's Gegenteil. Wobei man sicherlich auch immer ein bisschen unterscheiden muss, welche Fördermittel trotzdem im Hintergrund mitspielen ...

Zitat

Bei dem Plugin möchte Deltor die Timesteps adaptiv machen - wir dürfen gespannt sein.

Adaptiv? Das klingt interessant und ich frage mich, wie er das realisieren will.

Zitat

Da stimme ich Dir zu - aber ich glaube Deltor erwartet auch etwas:

Eine große Menge Feedback - und damit ist neben rein sachlichen Dingen (Bugs und Vorschläge zur Gui) auch eine Menge Lob gemeint.
-> Verdient hat er es.

Auf jeden Fall hat er das! Habe ja auch schon einen kleinen Kommentar in seinem Blog hinterlassen.

Zitat

Das mit der Kugeln hab ich gestern mal probiert - sehr kreativ!

Hatte die Kugeltropfenbilder von Blender gesehen und wollte dann unbedingt mal ausprobieren, was delt0r's Plugin zu der Idee sagt ...

Apropos: Wenn in Blender die "Resolution" für die Fluids zu gering eingestellt ist, sieht das Ergebnis genau wie in AoI aus. Vll würden uns einfach nur mehr Partikel (neben einer besser ausgefüllten Kugel) zu einem richtigen "Splash" verhelfen? Werde ich nachher mal austesten.

- Nachtrag: Hat nicht geholfen.

Habe ein kleines Problem hier. Ich weise einem Objekt einen procedural position track zu, um es besser kontrollieren zu können. Dabei bin ich (imo) auf einen Fehler in AoI gestoßen, einfach gesagt sieht die Sache wie folgt aus.

Wenn ich das Value "Time" mittels "Greater Than" mit einem festen Wert, bspw. 0.5 vergleiche (also: "Ist Time größer als 0.5?") und den Output meinetwegen in die Y-Koordinate stecke (X und Z bleiben 0), erwarte ich, dass das Folgende passiert: Ist die Zeit noch nicht 0.5, dann ist das Ergebnis vom Vergleich 0 und das Objekt sitzt bei 0/0/0. In allen anderen Fällen müsste das Ergebnis ja 1 sein, da "Time" dann größer als 0.5 ist.
Das funktioniert auch wunderbar, bis auf die eine kleine Stelle, an der die Zeit genau 0.5 ist. Dann liefert das Modul ein unbrauchbares Ergebnis und die Y-Koordinate des Objektes ist undefiniert - somit verschwindet es.

Das Beispiel habe ich zum besseren Verständnis mal hierhin hochgeladen:
http://www.uninformativ.de/gal/3d/misc/GreaterThanError.aoi

Zieht man die Zeitleiste langsam nach 0.5, passiert erstmal gar nichts. Genau bei 0.5 ist das Objekt dann verschwunden und, da die Y-Koordinate irgendwie hops geht, auch in der Zeit nach 0.5. Schiebt man nun auf bspw. 0.6, setzt die Y-Koordinate manuell wieder auf 0 und schiebt dann die Zeit weiter nach 0.7, springt der Würfel auf 0/1/0. Daraus schließe ich, dass vor und nach 0.5 alles korrekt ist, aber genau bei 0.5 irgendwas nicht stimmt.

Mache ich da etwas falsch oder ist das wirklich ein Fehler? Wenn ja, werde ich mal einen Post im SF-Forum machen.

-edit: Ok, ich habe nun ein Workaround gefunden. Normal kommt mir das trotzdem nicht vor, Meinungen?
http://www.uninformativ.de/gal…/GreaterThanError_Fix.aoi

Zitat

Original von vidiot
Zur Geschwindigkeit hat Deltor gesagt das er - sobald das Backen "multithreaded" ist and er Simulationsgeschwindigkeit von Realflow vorbeiziehen möchte....

An den Features nicht (ich kann das nicht oft genug "stressen")

Die Features von Realflow kenne ich (zum Glück) nicht, aber da das ein kommerzielles Produkt zu sein scheint und delt0r ganz alleine und kostenlos arbeitet, wäre es eh ein bisschen utopisch, von ihm ein gleichwertiges Produkt zu erwarten.

Zitat

Mit Blender habe ich mich dazu immer noch nicht beschäftigt.

Ich hab damit gestern mal rumgespielt. Von der Handhabung her eigentlich fast identisch, aber schon jetzt rein gefühlsmäßig langsamer. Dafür scheint mir Blender viel größere Timesteps verwenden zu können, was die Sache dann doch wieder schneller machen kann. Beim Unterschied Meshes und Surfaces kenne ich mich jetzt nicht gut genug aus, um das wirklich beurteilen zu können.

Zitat

Immerhin reden wir hier von einer beta Version - einer frühen noch hinzu.

Jup, und dafür tut sie schon ziemlich gut imo.

Zitat

Original von delt0r
So I am trying to isosurface speed ups now. Its about 5-10 times faster, but its all wrong at this point.

Nüchtern scheint er ja großteils wieder zu sein nun. Ich persönlich warte aber auch gerne etwas mehr, als überhastete Releases zu haben.

Sehr cool. Wie lange haben die gedauert in dieser Auflösung?

Die 2.5.1 hab' ich hier schon in Betrieb.

Zur Größe nochmal. Ein Partikel ansich ist 5cm groß, meint er mit "smoothing size" (= 20cm) dann das gesmoothte Partikel im Raytracer? Wenn dem so ist, dann müsste das Glas ja ~40m groß werden. Was mich zu einem Punkt führt, der mir vorhin aufgefallen ist: Wenn ich Objekte zu groß mache, dann kommt es zu dem 68'000-Partikel-Bug und er verheddert sich. Lasse ich das Objekt in der Szene, aber setze es nicht mehr als Hindernis ein, dann tritt der Fehler nicht mehr auf und alles ist ok.

Wie lange dauert das Backen eigentlich z.B. in Blender? Habe dazu jetzt in Google auf die Schnelle nichts gefunden, dafür viele tolle Blender-Ergebnisse - meinst du, delt0r bewegt sich auch in diese Richtung?

Zum Schluss noch ein paar Videos von mir, dann warte ich auf die 0.6er.

• Grosser Wassertropfen (mehrere Spheres ineinander)
• Grosser Wassertropfen in eine tiefe Wölbung fallend (Raytracer, LQ)
• Umgeworfene Kiste
• Umgeworfene Kiste (Raytracer, LQ)
• Wasser aus einer Kiste herausschleudern

Was mir dabei bisschen negativ auffällt, ist, dass Partikel - so sie denn erstmal den Boden berühren - fest an ihm klebenbleiben und nicht mehr nach oben zurückgeschleudert werden. Dadurch kommt es vorallem bei den großen Tropfen nicht zu einem typischen "Splash", sondern sieht schon sehr nach Quecksilber aus.

Stating the obvious: Dem Raytracer hilft es sehr auf die Sprünge, wenn man schattenlose Lichter verwendet und die "max ray depth" auf 1 setzt ... bis mir das mal eingefallen ist.

Zitat

Dein Wasserglas sieht doch fantastisch aus!!!

thx

Fein, dann warte ich auch erstmal auf die 0.6er. Auch schön zu sehen, dass laut deinem SF-Posting manche Probleme (Backen startet mit ~68k Partikeln und sonst passiert nichts, "Rückstoß" am Rampenende (siehe auch dieses Video, die Rampe hört am Ende horizontal auf), etc) wohl nicht an mir liegen.

Zitat

Also remember with default parameters, think more like swimming pools than glasses.

Das geht dann ja so in deine Richtung eigentlich - große Behälter. Aber was ist denn eigentlich "groß"? Ich lasse hier gerade etwas backen mit einem Bottich von ca. 30x40 und stoße dabei schon längst an das obere 30'000er Limit.

Mal sehn, was die neue Version heute abend so bringt.

-edit: Das hier ist das Ergebnis mit einem "großen" Bottich. Was hat es eigentlich mit diesem "Blitzen" auf sich? Schätze mal, das liegt am Raster-Renderer - kann man das irgendwie vermeiden?

Also, wie das bei mir immer so ist, ist das Endergebnis nicht ganz so das geworden, was ich mir vorgestellt hatte - nach der langen Zeit (ganze 24 Stunden hat das kleine Bild auf meinem Athlon X2 4200+ gebraucht) wollte ich's dann aber auch nicht mehr verwerfen, ergo: Klick. Zum Glück musste ich die Strahltiefe nicht erhöhen, das wär's ja noch gewesen am Ende - zumindest seh' ich jetzt keine Artefakte da.

Nebenher hab' ich auf'm Notebook noch bissel rumgespielt und sind ein paar Animationen bei rausgekommen, welche ich mal hier hin gepackt habe. Sind allerdings alle mit dem Raster-Renderer gemacht, weil ich für eine Animation von 10 Sekunden dann keine 3 Stunden opfern wollte.

Für kleinere Tests hat es sich bei mir bewährt, den density factor der Wasserquelle runterzusetzen, auf 0.125 oder noch tiefer. Dadurch bekommt man zwar kein so dichtes Wasser, aber er ist wesentlich flotter und man kommt schneller zu seinem Preview.

Bin gespannt, wo das noch hinführt.

-edit: Link korrigiert

Wie wirft man denn ein Objekt in bereits bestehendes Wasser hinein?

Das mit großen Behältern haut bei mir aber nicht so wirklich hin. Ich schätze mal, du willst das Backen damit beschleunigen, oder? Also hier kommt das am Ende auf's selbe drauf raus, denn der Bottich oder was auch immer muss ja dann entsprechend feinmaschig sein, damit nichts durchtropft - was dann wieder länger dauert.

Lasse hier schon seit einigen Stunden "Wasser im Glas" rendern - sieht schon recht vielversprechend aus, aber hat erst 30% oder so. Schätze mal, vor morgen früh wird das nicht fertig sein.

Also gefühlsmäßig schneller ist es geworden, das stimmt, auch wenn es für transparente Sachen immernoch verglw. lange braucht. Aber wenn noch Luft nach oben ist, lässt das ja hoffen.

Aber:

Zitat

Auch ist das benutzte Koordinatensystem nun dem von AoI per Vorgabe gleichgestellt.

Wie meinst du das? Die vorgegebene Fließrichtung ist ja immernoch -Z und damit zur Seite hin.

Trotzdem schön zu sehen, dass es voran geht. Wenn ich das von meinem laienhaften Standpunkt aus beurteilen darf, ist das Plugin imo 'ne ziemliche Bereicherung für AoI.

Sieht schonmal sehr cool aus. Macht auch einen sehr soliden Eindruck bis jetzt, fühlt sich gar nicht so sehr nach Beta an.

Hat leider erstmal 'ne ganze Weile gedauert, bis ich geschnallt habe, dass er im Plugin die "Default-Gravitation" in -Z-Richtung hat und nicht in -Y-Richtung - weswegen bei mir das Zeug nie nach unten floss, sondern immer zur Seite weg.

Lasse gerade das erste Testbild rendern - und merke, dass ich eine neue Packung Geduld brauche.

Huhu mal wieder.

Zitat

Original von vidiot
- Mehr Parallelisierung des Raster Renderers und der Photonmaps
- Teile des Vorprozessings einer Szene für den Raytracer sind
ebenfalls parallelisiert. Was insbesondere hilft wenn
viel Displacementmapping benutzt wird!!!

Ja, das ist prima! Die weitere Parallelisierung merke ich hier auf meinen DualCores wirklich sehr. Endlich muss man im Textureditor auch bei einem großen Vorschaufenster nicht mehr ewig warten (bei Displ.).

Einzig bissel seltsam finde ich die neuen Kurven dort, so wirklich viel übersichtlicher ist das nicht.

Schade, dass ich im Moment so wenig Zeit für's Rendern finde ...

Okay, dank dir, hab's geschnallt glaub ich.

Brauche noch sehr viel Übung in diesem Bereich ... :compi:

Du musst dir mal anschauen, was DigitalDream sonst noch so macht, wenn du's noch nicht getan hast. Da sind lauter so krasse Dinger dabei, das ist kein Einzelfall.

Hmmm, ich gehe das irgendwie total falsch an, glaube ich.

Im Anfang ein einfaches Beispiel. Ich will die beiden Faces, die ich oben markiert habe, nach innen extruden. Jedoch kriege ich außen immer so unschöne Ränder/"Überhängsel", wie man's unten sieht. Ziehe ich die umliegenden Vertices noch näher an die Ecken heran, kriege ich zwar im Idealfall innen eine schöne Rundung, so wie ich das auch haben will. Aber außen bleibt es so wie es am Anfang auch schon war - siehe kleines Bild.

Noch mehr subdividen hilft nicht, gezielt Edges einfügen auch nicht, ...

Was mache ich da falsch?