Ben®
19.09.2011, 12:42

Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

Moin Moin!

Neulich habe ich hier über das Rendern mit "Motion Blur" (zu Deutsch "Bewegungsunschärfe") geschrieben und bekam darüber auch interessante Rückmeldungen.

Jetzt ist eine gute Woche vergangen und ich habe etwas weiter mit diesem Effekt herumgespielt. Allerdings bin ich auch ziemlich ernüchtert.

Einen Propeller unscharf erscheinen zu lassen - das klappte noch ganz gut und mit nur unwesentlich verlängerten Renderzeiten (also vielleicht doppelt bis 5x so lang wenn der Propeller 50x überlappt dargestellt wurde).

[image]



Davon ausgehend wagte ich mich an ein komplizierteres Projekt:

Eine Lok mit:
- 6 Achsen mit Speichenrädern,
- zwei Koppelstangen,
- zwei Pleuelstangen und
- dem Schienenstrang, der auch verwischt, da die Kamera mit der Lok schwenkt.

Die Pleuel-, Koppelstangen und Räder laufen räumlich voreinander durch die Blickrichtung. Offenbar potenzieren sich hier die Renderzeiten. Ich habe nun ein Bild mit 8 Überlappungen rendern lassen und einen neuen Negativrekord aufgestellt:

[image]


Die Renderzeit betrug hierfür 4 Tage 2 Stunden 14 Minuten und 43 Sekunden!

[image]


Das gleiche Bild als Einzelbild ohne Motion Blur rendert in unter 90 Sekunden durch.

Daher habe ich versucht mit einem Grafikprogramm den Effekt durch Bildüberlagerung nachzubauen. Benutzt wurde das altmodische Picture Publisher 8.0, da ich es habe und damit umgehen kann. Kostete vor über 5 Jahren keine 15 Eur im Bundle mit Designer und weiterer nützlicher Grafiksoftware.

Die Ergebnisse könen sich im Vergleich auch sehen lassen:

[image]


Im normalen Mischmoddus verblassen tiefere (zeitlich frühere) Bildschichten. Insgesamt liegt ein leichter Grauschleier über dem Bild, den ich mir nicht erklären kann.

[image]


Der "wenn dunkler" Mischmodus läßt hellere bewegte Pixel verschwinden aber liefert schönere Farben.

[image]


Multiplikation der Bildpixel-Werte erzeugt knallige Farben und dennoch einen leichten Grauschleier.

Für diese Bildüberlagerung habe ich hier auch im PovRay etwas programmiert, damit immer 8 Bilder mit gleichem Ausschnitt gerendert werden, bei denen von Bild zu Bild nur die vom "Motion Blur" betroffenen Komponenten virtuell weiterbewegt werden. Alle 8 Bilder springt also die Lok etwas voran und in den darauf folgenden 7 Bildern bewegen sich nur Pleuel, Räder und Schienenstrang. (Wobei hier nur ein Zyklus zusammengefaßt wurde).

Hier könnte man sicherlich auch experimentieren und die ganze Szene sich bewegen lassen (allerdings wird dann ggf das ganze Bild leicht unscharf).
Außerdem habe ich die Transparenzwerte aktuell für alle Schichten identisch belassen und damit nur wenig herumexperimentiert. Da ist noch Potential.

Im Picture Publisher lassen sich auch primitive Makros schreiben, um die Arbeit des Überlagerns und Filterns zu automatisieren.
Leider klappt das nicht bis hin zum Öffnen von "nächsten" 8 Bildern einer Liste und auch nicht beim Speichern mit jeweils fortlaufenden Dateinamen.

Damit ist diese Lösung für eine Animation, die zum Schluß aberhunderte Bilder umfassen soll noch wenig geeignet. Vielleicht muß ich da unter Excel noch ein weiteres Makro schreiben, daß die Dateibenamung und Steuerung des Picture Publisher automatisch übernimmt (aber das überfordert aktuell noch meine PC-Kentnisse, um das aus dem Stegreif hinzubekomen).

Soweit von der Render- und Animationsfront. Ich melde mich, wenn das erste Filmchen in Motion Blur bei YouTube hochgeladen ist. MegaPov werde ich als Lösung definitiv aufgeben...

Leg Godt!


2 vorhergehende Beiträge sind ausgeblendet

Alle anzeigen Immer alle anzeigen Beitragsbaum

Ben®
19.09.2011, 17:39

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

» Hallo,
»
» also da muss ich Jojo Recht geben, die Bilder sind "erste Sahne". Ich hab
» da mal ne Frage und zwar, exisitiert derzeit ein gutes Tutorial, wo auch
» unwissende (wie ich) das Rendern verstehen ?
»
» Viele Grüße Martin


Hallo Martin,

danke für's Lob auf die Bilder. Diese sind nun noch weit entfernt von 1. Sahne, sondern wirklich fürs schnelle Rendern optimiert (was bei Motion Blur eben nicht klappte).
Mir ist ehrlichgesagt nicht bekannt, ob es Tutorials für sowas (in Deutsch und verständlich für Anfänger) gibt. In Englisch findet man alles wichtige auf www.LDRAW.org.

Ich habe mehr durch Herumprobieren gelernt (und ab und an hier im Forum Tips aufgeschnappt). Wenn ich irgendwo mal sehr gute Bilder gesehen habe, habe ich auch konkret nachgefragt, wie die gerendert wurden.

Das allerwichtigste ist die richtige Ausleuchtung einer Szeene Menge und Art der Lichtquellen, , Orte der Lichtquellen, Helligkeit der Lichtquellen).
Bildkomposition, Qualität (Anti-Aliising) und eventuell andere Farbdefinitionen können das Ergebnis weiter verbessern. Der Gebrauch der LGEO-Teiledatenbank hilft die Qualität der Darstellung enthaltener Steine gewaltig zu verbessern (abgerundete Kanten etc).


Der Renderguru für mich - als ich damit begann - war Jeroen de Haan. Der hat mich damals erstmal ganz cool (aber freundlich) auflaufen lassen und mich wissen lassen, ich müßte erstmal ein gescheites Bild selbst rendern. Dann würde er mir helfen meine Fähigkeiten zu verbessern.....

Das saß, aber war auch hilfreich: so habe ich mich erst ziemlich in die Englisch-sprachige Originaldokumentation eingelesen und dann erst mit genügend Basiswissen ausgestattet mit Jeroen fast auf Augenhöhe diskutieren können.

Der hat vor allem den Einsatz von "Radiosity" auf die Spitze getrieben (also die Ausleuchtung per diffuser Reflexion in Ecken, die kein direktes licht sehen).

So habe ich z.B. das hier erstellt:

[image]



Später habe ich noch von Tim Gould einige Tricks aufgeschnappt (auch wieder nur auf Englisch).

Und nun habe ich binnen 5 Jahren wenig gerendert und das meiste wieder vegessen gehabt.....

Leg Godt!


Ben®
19.09.2011, 18:31

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

» Hallo,
»
» also da muss ich Jojo Recht geben, die Bilder sind "erste Sahne". Ich hab
» da mal ne Frage und zwar, exisitiert derzeit ein gutes Tutorial, wo auch
» unwissende (wie ich) das Rendern verstehen ?
»
» Viele Grüße Martin

» Hallo,
»
» also da muss ich Jojo Recht geben, die Bilder sind "erste Sahne". Ich hab
» da mal ne Frage und zwar, exisitiert derzeit ein gutes Tutorial, wo auch
» unwissende (wie ich) das Rendern verstehen ?
»
» Viele Grüße Martin

Moin Martin,

wenn Du grundsätzlich schon Sachen in PovRay gerendert hast, aber bisher z.B. einfach alles nur mit "L3PAO.exe" zum Rendern vorbereitest, dann lohnt es sich mal tiefer in die POV-Files zu schauen.

(Vorsicht: für Fachfremde wird es jetzt sehr chinesisch....!)


Oben im Kopf findet sich immer ein Block wie:

#declare QUAL = 2; // Quality level, 0=BBox, 1=no refr, 2=normal, 3=studlogo

#declare SW = .4; // Width of seam between two bricks

#declare STUDS = 1; // 1=on 0=off

#declare BUMPS = 0; // 1=on 0=off

#declare BUMPNORMAL = normal { bumps 0.01 scale 20 }
#declare AMB = 0.18;
#declare DIF = 0.45;


Irgendwann (recht bald) kommt die Zeile:
#declare O7071 = sqrt(0.5);

Dahinter wird dann die Szene beschrieben: Welche Steine sind enthalten? Wie sehen diese Steine in POV-Sprache aus?
Dann wird das Modell beschrieben: in welchen Mengen sind die vorher definierten Steine wo im Raum verbaut. Ggf. werden die Submodelle noch definiert. FERTIG!

Dieser Teil kann tausende Zeilen Code lang sein. Hier ändere ich NORLERWEISE nichts. Man kann aber auch hier noch die Lage von Modellen zueinander verändern etc..... Das ist aber kein Anfängerlevel mehr, denke ich.

Spannend wird es erst wieder ganz unten (in diesem Fall geht es um eine mpd-Datei aus dem ML-Cad mit Namen "driver.mpd", die gerendert werden sollte:

object { driver_dot_mpd #if (version >= 3.1) material #else texture #end { Color7 } }
// Floor:
object {
plane { y, 72 hollow }
texture {
pigment { color rgb <0.8,0.8,0.8> }
finish { ambient 0.4 diffuse 0.4 }
}
}
// Background:
background { color rgb <0,0,0>}

// Camera (Latitude,Longitude,Radius = 45,45,0)
camera {
#declare PCT = 0; // Percentage further away
#declare STEREO = 0; // Normal view
//#declare STEREO = degrees(atan2(1,12))/2; // Left view
//#declare STEREO = -degrees(atan2(1,12))/2; // Right view
location vaxis_rotate(<67.5286,-77.2955,-75.0807> + PCT/100.0*<67.218,-95.0606,-67.218>,
<-6389.79,-9036.53,6389.79>,STEREO)
sky -y
right -4/3*x
look_at <0.310603,17.7652,-7.8627> // calculated
angle 67.3801
rotate <0,1e-5,0> // Prevent gap between adjecent quads
//orthographic
}

// Lights:
light_source {
<1.85976,-75.0606,-104.535> // Latitude,Longitude,Radius: 45,0,134.436
color rgb <1,1,1>
}
light_source {
<102.687,-47.218,48.7384> // Latitude,Longitude,Radius: 30,120,134.436
color rgb <1,1,1>
}
light_source {
<-56.3528,-96.425,24.1349> // Latitude,Longitude,Radius: 60,-120,134.436
color rgb <1,1,1>
}

// Number of processed parts: 39
// From PARTS: 11
// LGEO parts: 3 (27%)
// stud.dat: 0
// BoundingBox: <-28.6547,-32,-39.8565> <32.3742,72,20.9084>
// Center: <1.85976,20,-9.47409>
// Size: <61.029,104,60.7649>


In diesem Block ist beschrieben, wo die Kamera steht, wohin sie blickt, wo die (drei) Lichter sind und wie hoch der Fußboden in die Szene gelegt ist.

Hier bastle ich immer reichlich herum. Testbilder rendere ich bei Qualität "O" in 320x240 Pixeln. Das geht in Sekunden.

****

Eine veränderte Szene könnte für mich so aussehen (inklusive eigenem Boden, Bodennebel und anderen als Standardlichtern):

object { Fokker__D7__wSticker_dot_mpd translate -1*<0,0,10> rotate <3,145,-15> translate <0,-938,0> #if (version >= 3.1) material #else texture #end { Color7 } }

mit dem Translate befehl schiebe ich das Fokker-Flugzeug in die mitte meiner Welt (o,0,0) und mit rotate drehe ich das Ding im Raum - kann also links recht und vorne einstellen, 145° ist schräg von vorne.
So bleibt die Kamera immer vernünftig zum Licht stehen und ich drehe das Bauwerk wie auf einer Bühne im perfekten Licht.

// White fog on horizon
fog{color rgb <0.8,0.9,1>*0.7 distance 4000 fog_type 2 fog_offset +50 fog_alt -380}

// White fog on horizon
fog{color rgb <256,210,130,>*.6/256 distance 100000 fog_type 2 fog_offset -350 fog_alt -300}

// Floor:
object {
plane { y,-4 hollow }
texture {
pigment {rgb <.1,.75,.1> }
finish {
ambient 0.2
diffuse 0.2
brilliance 0
metallic 0
specular 0
roughness 1/5
}
#if (BUMPS) normal { bumps 1000.0 scale 800 } #end
}
}

// Background:
background { color rgb <1,1,1>}


// Camera
camera {
#declare PCT = 0; // Percentage further away
#declare STEREO = 0; // Normal view
//#declare STEREO = degrees(atan2(1,12))/2; // Left view
//#declare STEREO = -degrees(atan2(1,12))/2; // Right view
location vaxis_rotate(<-1560,-925,0>*1 + PCT/100.0*<0,0,0>,
<0,-1.21e+006,0>,STEREO)
sky -y
right -4/3*x
look_at <-00,-938,00> // -cla
angle 29.5
rotate <0,1e-5,0> // Prevent gap between adjecent quads
//orthographic
}
// Lights:

light_source {
<-6000,-2300,-3600>
color rgb <0.78,0.8,0.8>*0.81
//der Multiplikator hinter dem<<>> schwächt das Licht ab.
}
light_source {
<-12500,-9500,14350>
color rgb <0.5,0.5,0.5>*0.95
}
light_source {
<-1500,-4000,-1800>
color rgb <0.91,0.9,0.9>*0.52 parallel point_at <0,-60,0>
// Parallellichter entsprechen Sonnenlicht. Andere Lichter werfen Schatten wie Straßenlaternen: je nach Objekt immer von der Lampe weg.
}
light_source {
<-1000,-120,-2100>
color rgb <0.55,0.567,0.567>*0.60 shadowless
//Schattenlose Lichter hellen Bereiche im Schatten (aber auch im Rest!) auf.
}


// Number of processed parts: 160
// From PARTS: 69
// LGEO parts: 42 (60%)
// stud.dat: 19
// BoundingBox: <-260,-145.699,-210> <260,69.8895,230>
// Center: <0,-37.9046,10>
// Size: <520,215.588,440>


Und das waren auch schon die wesentlichen Sachen. Oben vor #declare O7071 = sqrt(0.5); füge ich bei mir immer Jeroens Farben nach dessen alter Homepage ein:

// radiosity on/off
// 0 = off [default]
// 1 = on
//
#declare LDRAW_RAD_SWITCH = 0;

// radiosity level (works only when LDRAW_RAD_SWITCH = 1)
//
// LDRAW_RAD_LEVEL = 0; // Default
// LDRAW_RAD_LEVEL = 1; // Debug
// LDRAW_RAD_LEVEL = 2; // Fast [default]
// LDRAW_RAD_LEVEL = 3; // Normal
// LDRAW_RAD_LEVEL = 4; // 2Bounce
// LDRAW_RAD_LEVEL = 5; // Final
//
// LDRAW_RAD_LEVEL = 6; // OutdoorLQ;
// LDRAW_RAD_LEVEL = 7; // OutdoorHQ;
// LDRAW_RAD_LEVEL = 8; // OutdoorLight;
// LDRAW_RAD_LEVEL = 9; // IndoorLQ;
// LDRAW_RAD_LEVEL = 10; // IndoorHQ;
//
#declare LDRAW_RAD_LEVEL = 2;

// radiosity normal
//
// off [default]
// on
//
#declare LDRAW_RAD_NORMAL = on;

// radiosity media
//
// off [default]
// on
//
#declare LDRAW_RAD_MEDIA = off;

// Colour Library
//
// 0 = Standard L3P or LGEO colours
// 1 = Jeroen's Colour Library [default]
// 2 = Todd's Colour Library (unofficial and does not work with LGEO)
//
#declare COLOUR_LIBRARY = 1;

// variable reflection
//
// 0 = off [default]
// 1 = on
//
#declare LDRAW_VARIFLEX = 2;

// sky sphere
//
// 1 = white [default]
// 2 = clouds
// 0 = own (no sky_sphere is placed, define your own)
//
#declare LDRAW_SKYSPHERE = 2;

// Index Of Refraction
//
// 1.52 = default ABS
//
#declare INDEXOFREFRACTION = 1.45;

#include "ldraw_radiosity.inc"


Wichtig ist hier die Datei ldraw_radiosity.inc, die man in "LDRAW\POVray\includes" zu kopieren hat. Außerdem wird darin auf die Farbdefinition "LDRAW_RAD_COLOR2.inc" verwiesen, die ebenfalls dorthin zu kopieren ist. Diese Files sollte man via Google oder Lugnet-Suche sicherlich noch auftreiben können. Meine eigenen sind abermals gelegentlich abweichend von den Originalen....

Soviel mal als Crashkurs für bereits tiefer eingestiegene Anfänger.

Viel Erfolg für das eigene Rendern!


der seb
19.09.2011, 20:36

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

Hallo Ben,

vielen Dank für den Crashkurs. Ich beschäftige mich selbst auch schon länger mit dem Rendern, meistens mit Radiositiy.

Generell habe ich große Schwierigkeiten das "Plastikfeeling" von Lego nachzustellen. Meistens sehen auf den fertigen Bildern die Texturen und Farben einfach nicht nach Lego aus, z.B. hier:

[image]


hier half eine Nachbearbeitung mit Kontrast und Helligkeit ein wenig.

Schon besser gelang mir der Star Destroyer, der allerdings auch keine knallbunten Farben enthält

[image]



So richtig zufrieden bin ich mit keinem meiner restlichen Rendereien. Zu matt, zu grau, falsche Textur, mysteriöse Schatten im Bild, ...


An dieser Stelle sei noch auf das deutschsprachige Tutorium von Friedrich Lohmüller hingewiesen:
http://www.f-lohmueller.de/pov_tut/pov__ger.htm


grubaluk
19.09.2011, 22:42

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

Hallo!

Ich bin weit davon entfernt, mit meinen Render-Ergebnissen zufrieden zu sein unddie LEGO-Plastikoberfläche ist wohl einer der Endgegner des Renderns, aber da alles nur Spaß ist, kann man es ja mal versuchen (eine BR55):

[image]




Meine Arbeitsweise geht da in Richtung Try&Error oder Brute Force. Dazu ist es sinnvoll,sich die Farb- und Oberflächendefinitionen in eine eigene Datei
zu packen und diese dann in die pov-Datei einzubinden (Anm.: ich benutze auch immer die lgeo-Teile).

Eine eigene Farbdefinition sieht dann in der Include-Datei ungefähr so aus (z.B. Schwarz):

#declare weicolor_0 = texture {
pigment { rgbft <0.02,0.02,0.02, 0, 0> }
normal { WEI_STDNOR }
finish { WEI_STDFIN }
}
}
#declare Color0 = material { texture {weicolor_0} }
#declare Color0_slope = material { texture {weicolor_0 normal { WEI_SLOPENOR }}}
#declare Color0_rauh = material { texture {weicolor_0 normal { WEI_RAUHNOR }}}


Ich verwende dabei also eigene Definitionen für das Finish und die Normalen und habe so Einfluss auf die Variablen.
Vorher steht in der inc-Datei dann irgendwo:


#declare WEIFI_STDPNG=0.6; // Phong 0.3
#declare WEIFI_STDPHS=30; // Phong-Size 10
#declare WEIFI_STDBRILL=0.3; // Brilliance .8
#declare WEIFI_STDSPEC=0.8; // Specular
#declare WEIFI_STDROUGH=0.12; // Roughness -> gegen 0.1 sehr viel Plastik

// Werte für Normale
#declare WEINO_STDBUMP=0.05; // Standard Normal Bumps 0.01
#declare WEINO_STDSCALE=150; // Standard Normal Bumps Scale 20
#declare WEINO_STDTURB=4.0; // Standard Normal Turbulence
#declare WEINO_RAUHBUMP=0.10; // Standard Normal Bumps
#declare WEINO_RAUHSCALE=0.2; // Standard Normal Bumps Scale
#declare WEINO_RAUHTURB=0.0; // Standard Normal Turbulence
#declare WEINO_SLOPEBUMP=0.3; // Standard Normal Bumps
#declare WEINO_SLOPESCALE=0.2; // Standard Normal Bumps Scale
#declare WEINO_SLOPETURB=0.0; // Standard Normal Turbulence 0.0

// Standardnormal
#declare WEI_STDNOR = normal {
bumps WEINO_STDBUMP
scale WEINO_STDSCALE
turbulence WEINO_STDTURB
};

// Standardnormal rauh
#declare WEI_RAUHNOR = normal {
bumps WEINO_RAUHBUMP
scale WEINO_RAUHSCALE
turbulence WEINO_RAUHTURB
};

// Standardnormal für Slopes
#declare WEI_SLOPENOR = normal {
bumps WEINO_SLOPEBUMP
scale WEINO_SLOPESCALE
turbulence WEINO_SLOPETURB
};

// Standardfinish
#declare WEI_STDFIN = finish {
ambient WEIAMB
diffuse WEIDIF
brilliance WEIFI_STDBRILL
reflection { 0.08,.3 falloff 4 } // 0.04, 0.03 falloff 4 //0.05,.3 falloff 4
specular WEIFI_STDSPEC
roughness WEIFI_STDROUGH
phong WEIFI_STDPNG
phong_size WEIFI_STDPHS
conserve_energy
};


Warum ich das nicht auch mit "reflection" gemacht habe, weiß ich nicht :|
Egal, jedenfalls kann ich die Datei dann in der eigentlichen pov-Datei vor den
dortigen Farbblock einfügen, welcher tollerweise mit IFNDEF arbeitet, meine Farbe also nicht überbügelt, sondern nur die setzt,
die ich nicht in meiner Datei habe:


...

#include "lg_defs.inc"
#include "lg_color.inc"
#ifdef (L3_Temp_Vers) #version L3_Temp_Vers; #undef L3_Temp_Vers #end
#include "wei_pov.inc" // <-MEINS!

....

#ifndef (Color7)
#declare Color7 = #if (version >= 3.1) material { #end texture {
lg_grey
} #if (version >= 3.1) } #end
#declare Color7_slope = #if (version >= 3.1) material { #end texture {
lg_grey
#if (QUAL > 1) normal { bumps 0.3 scale 25*0.02 } #end
} #if (version >= 3.1) } #end
#end

#ifndef (Color8)
#declare Color8 = #if (version >= 3.1) material { #end texture {
lg_dark_grey...
...usw....


Nu kommt ggf. Brute Force: Man kann die von Ben in seinem Motion-Blur-Tutorial benutzte clock-Variable auch für "Belichtungsreihen" wie
bei einer Kamera einsetzen und schauen, was sich so tut, z.B.für die Phong Size von 0 bis 100:


#declare WEIFI_STDPHS=10;

#declare WEI_STDFIN = finish {
ambient WEIAMB
diffuse WEIDIF
brilliance WEIFI_STDBRILL
reflection { 0.08,.3 falloff 4 } // 0.04, 0.03 falloff 4 //0.05,.3 falloff 4
specular WEIFI_STDSPEC
roughness WEIFI_STDROUGH
phong WEIFI_STDPNG
phong_size WEIFI_STDPHS*10*clock
conserve_energy
};


Auf die Weise kann man versuchen, Einstellungen zu finden, die beim Rest der verwendeten Techniken ein brauchbares Ergebnis liefern.
Oder man verucht die ganzen Variablen zu verstehen. Ich hab das nicht geschafft und - der Herrgott ist mein Zeuge - ich habe
es versucht.
Meine Variante strotzt sicherlich nicht vor Eleganz, aber ist ab und an recht effektiv.

Grundsätzlich kann das Setzen von Variablen beim Testen helfen, schnell Werte zu ändern (oder halt solche Testreihen zu berechnen).
So sehen die Lichtdeklarationen bei mir typischerweise so aus:


#declare WEIAREA = 2; // <=1 -> Schaltet die Rechenfresser bei Vorschau ab
#declare WEIINTENSE = 0.40; // eine Art Dimer
#declare WEIAREASIZE = 4; // Skalierung der Größe bei Area-Lights

light_source {
<7000,-7000,8000>
color rgb WEIINTENSE*<1.0,.9,.9>
spotlight
point_at <0,60,0>
radius 15
falloff 24
#if (WEIAREA > 1)
area_light WEIAREASIZE*<-100,0,-100>, <100,0,100>, 3, 3
circular
orient
adaptive 1
jitter
#end
}
light_source {
<6000,-8000,-7500>
color rgb WEIINTENSE*<1.0,0.9,0.9>
spotlight
point_at <0,60,0>
radius 17
falloff 20

#if (WEIAREA > 1)
area_light WEIAREASIZE*<-100,0,-100>, <100,0,100>, 3, 3
circular
orient
adaptive 1
jitter
#end
}
light_source { ....


Vielleicht waren ja ein paar Anregungen dabei. Falls Interesse an der inc-Datei besteht, kann ich die bei einer PM auch mailen. Steht halt
auch mit den Jahren viel Stuß drinne, wofür man sich schämen muss, aber aufräumen tu ich trotzdem nicht.

Gruß
Andreas


Ben®
19.09.2011, 22:55

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

Hallo,

danke für Deine Rückmeldung und vor allem den Verweis auf die Beispielbilder!

Bei denen sind mir vor allem die "verschossenen" Hellblauentöne aufgefallen.
Eine Idee, wie die Bilder generell zu verbessern sind, weiß ich auch nicht per Ferndiagnose zu sagen.

Mit dem "Index of Refraction" habe ich eine Weile herumgespielt. Und noch bedeutender fand ich die beiden Werte für AMB und DIF.


» Schon besser gelang mir der Star Destroyer, der allerdings auch keine
» knallbunten Farben enthält
»

[image]



Der ist schon ziemlich genial gerendert. Bei Radiosity hatte ich (wohl 5 Jahre her) immer das Problem von Mangel an Arbeitsspeicher und Geduld. Große Szenen nahmen schonmal gerne über 3 GB an (bei 1 Gig physikalischen Speicher war das dann zuviel). Da hat man heute weniger Probleme mit 2-4 Gig vorhandenem Speicher und 2x mehr Auslagerung. Renderzeiten von über 12 Stunden waren hier auch oft normal.

Darf ich rückfragen, was Da Deine Erfahrungen sind?

*****

Was mir auf Brickshelf gefällt ist das hier.

Man sieht aber auch die Probleme: schwarz ist zumeist zu grau. Oberflächen spiegeln oft zu sehr. Anderes ist fast perfekt (vor allem Glasteile):

[image]


Mit kleinerem AA-Wert (Anti-Aliising) wären auch die Pixeltreppen weg gewesen....

[image]


Bei diesem Modell wären die Reifen in matterer Version (für Gummi eine eigene Farbe abweichend zu schwarz definieren!) wünschenswert. Zudem hätte ich mir "Bumps = 1" gewünscht: dann wäre die Spiegelung im Sitz nicht "perfekt", sondern mit welligen Abbildungsfehlern (eben als ob die Steine gaaaanz bißchen gewölbt + krumm wären).

Die wohl besten Renderings die ich kenne sind die von Garfield
.
Leider habe ich keine Idee, was er für Einstellungen fährt.

» An dieser Stelle sei noch auf das deutschsprachige Tutorium von Friedrich
» Lohmüller hingewiesen:
» http://www.f-lohmueller.de/pov_tut/pov__ger.htm

Schaute ich gelegentlich drüber: bietet in der Tat viel interessantes Wissen, aber hilft kaum in Bezug auf Legospezifische Fragen.

Dann weiterhin alles Gute fürs virtuelle Bauen und Darstellen!


Ben®
19.09.2011, 23:11

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

» Hallo!
»
» Ich bin weit davon entfernt, mit meinen Render-Ergebnissen zufrieden zu
» sein unddie LEGO-Plastikoberfläche ist wohl einer der Endgegner des
» Renderns, aber da alles nur Spaß ist, kann man es ja mal versuchen (eine
» BR55):
»
»

[image]



Moin Moin!

Sehr schön Dein Bild! Vor allem das rot sieht täuschend echt aus: ich guckte 2x ob das nun das Beispielphoto ist und das Render weiter unten folgen würde.... Erst die fehlenden LEGO-Schriftzüge auf den Studs nahm ich dann als "Mangel" wahr.
Übrigens nicht nur ein schönes Renderergebnis sondern auch eine wunderschöne Lok die den Aufwand der virtuellen Arbeiten absolut wert war! Besonders die Hörner als Blattfedern sind ein Detail, welches ich bei Gelegenheit mal borgen möchte....

Gute Tips in der Tat. Sowohl die Farben ins POV-File zu nehmen, wie auch die Idee mit Clock verschiedenes auszuprobieren.

Oftmals finde ich sogar "falsche" Parameter attraktiv. Diverse Fans haben so sozusagen eine eigene Handschrift entwickelt.
Als Beispiel nenne ich hier mal "UR": dessen Bilder sehen immer "naß" aus. Zu reflektierend, zu stark beleuchtet. Aber eben sehr eigen.....

Danke fürs Teilen Deiner Code-Zeilen!


grubaluk
19.09.2011, 23:51

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

» Danke fürs Teilen Deiner Code-Zeilen!

Ich kann den Dank nur zurückgeben! Bin schon gespannt, wie das mit dem Motion Blur endet. Hatte das vor Jahren auch versucht
und war ebenfalls auf das Grau-Problem beim Überlagern der Bilder gestossen.

Und falls diesen Thread nochwer liest: Die Bewegung in den einzelnen Teilen bei Bens Lok mittels der Clock-Variable zu setzen und
abzustimmen (wo ist grad die Pleuelstange? wie die Achse von den Rädern? und ist das mein Schädel, der sich gerade dreht?),
ist eine Schw...e-Arbeit

Aber es lohnt sich! Es ist sicher eine andere Variante, als seinem Lego-Flugzeug Leben einzuhauchen, indem man damit zwischen den
Fingern über den Wohnzimmertisch klettert und "Brummbrumm" macht, aber genauso faszinierend. (Wobei: heimlich machen wir das vielleicht
auch).

Irgendwie muss ich auch mal wieder mehr in der Richtung machen, herrje...

Gruß
Andreas


Vollbi
20.09.2011, 09:03

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

Hi,

mal ne ganz blöde frage :blink: , da ich die Teile teilweise schon genial finde.

wenn ich es richtig verstanden habe, habt ihr diese Sets nicht original von Lego gebaut?!

Was ist dann eigentlich die Grundlage der teilweise täuschend echt aussehenden Renderings?

Gruß

Uwe


der seb
20.09.2011, 10:50

Re: Nochmal zum Rendern mit "Motion Blur" => Fehlschlag unter MEGAPOV

Hallo Ben,

» Bei denen sind mir vor allem die "verschossenen" Hellblauentöne
» aufgefallen.
» Eine Idee, wie die Bilder generell zu verbessern sind, weiß ich auch nicht
» per Ferndiagnose zu sagen.

Eine eigene Farbdatei hatte ich bisher noch nie angewendet. Mal sehen, ob das bei den hellblauen Tönen was bringen würde.
Ich bin leider gerade am falschen PC um meine Einstellungen zu posten, mache ich aber demnächst noch.

» Der ist schon ziemlich genial gerendert. Bei Radiosity hatte ich (wohl 5
» Jahre her) immer das Problem von Mangel an Arbeitsspeicher und Geduld.
» Große Szenen nahmen schonmal gerne über 3 GB an (bei 1 Gig physikalischen
» Speicher war das dann zuviel). Da hat man heute weniger Probleme mit 2-4
» Gig vorhandenem Speicher und 2x mehr Auslagerung. Renderzeiten von über 12
» Stunden waren hier auch oft normal.
»
» Darf ich rückfragen, was Da Deine Erfahrungen sind?

bei 2 GB Speicher, Pentium 4 sind für größere Bilder mit Radiosity zweistellige Stundenzeiten normal. Der Taj Mahal im Flickrset hat in der größten Auflösung ca. 16 Stunden gebraucht, der Eiffelturm etwas über 11. Kleinere Sets mit wenigeren Teilen wie das Brandenburger Tor gehen in unter einer Stunde durch, wobei das Fanworthshaus durch die Glasscheiben auch wieder enorm viel Zeit benötigte.

» Man sieht aber auch die Probleme: schwarz ist zumeist zu grau. Oberflächen
» spiegeln oft zu sehr. Anderes ist fast perfekt (vor allem Glasteile):
» Mit kleinerem AA-Wert (Anti-Aliising) wären auch die Pixeltreppen weg
» gewesen....

Die Beschaffenheit von Schwarz behebe ich meistens in der Nachbearbeitung mit Kontrast- und Helligkeitswerten, so kommt auch oft der matte Schleier vom Bild.



» Die wohl besten
» Renderings die ich kenne sind die von Garfield
.
» Leider habe ich keine Idee, was er für Einstellungen fährt.

Die wären in der Tat interessant, noch viel besser finde ich aber die Bilder von Dlarian:

[image]


Das ist eines der besten Bilder die ich bisher gesehen habe. Die Texturen der Dachsteine, das "Legofeeling", als würden die Steine direkt aus der Schachtel kommen und noch diesen "neuglänzenden Film" auf der Oberfläche haben.


» » An dieser Stelle sei noch auf das deutschsprachige Tutorium von
» Friedrich Lohmüller hingewiesen:
» » http://www.f-lohmueller.de/pov_tut/pov__ger.htm
»
» Schaute ich gelegentlich drüber: bietet in der Tat viel interessantes
» Wissen, aber hilft kaum in Bezug auf Legospezifische Fragen.

der Link galt in erster Linie "BricksOnRails", um vielleicht mal in die Basics einzusteigen. Eine brauchbare Einstellung fürs Rendern findet man leicht über Google und der Rest ist wie schon so oft gesagt Try&Error


Ben®
20.09.2011, 10:56

Re: Nochmal zum Rendern // Virtuelles Bauen.

» Hi,
»
» mal ne ganz blöde frage :blink: , da ich die Teile teilweise schon genial
» finde.
»
» wenn ich es richtig verstanden habe, habt ihr diese Sets nicht original
» von Lego gebaut?!
»
» Was ist dann eigentlich die Grundlage der teilweise täuschend echt
» aussehenden Renderings?
»
» Gruß
»
» Uwe

Hallo Uwe,

es gibt einige Programme, um mit Legosteinen "virtuell" (also am PC-Bildschirm) zu bauen. Das haben wir hier bei den Modellen dieses Threads so gemacht.

Als Programme gibt es:
1)
"LDraw" (ein von Fans programmiertes Programm - kann fast alles, aber je mehr Zeit man bereit ist zu investieren, desto besser und mächtiger wird das. Nicht unbedingt für Kinder, aber wenn installiert auch von Kindern beherschbar). Dies ist DAS Profiprogramm meiner Wahl - ohne wenn und aber!
2)
"LDD" ist die alternative von LEGO selbst: gratis aber nicht alle Elemente verfügbar. Frühere Versionen waren computerleistungsfressend und instabil. Kinder kommen damit wohl intuitiv klar. Ich selbst bin zu verkopft dafür.
3)
LeoCad => früher eine komfortable Alternative zu LDraw. Keine Ahnung wieweit das heute noch gepflegt ist und welche Vorteile es ggf. bietet.

Mehr oder (eher) weniger leicht kann man mit allen Programmen Bauanleitungen erstellen.
Mit Hilfe weiterer Programme ("Renderer") können aus 1 und 3 grafisch sehr hochwertige Bilder erzeugt werden. Die Rohbilder bei 1+3 sind eher simpel. bei 2) sind Bilder mittelmäßig bis gut.

Zu 1) gibt es alles unter www.ldraw.org. Das umfaßt auch diverse deutschsprachige Seiten mit Anleitungen.

Leg Godt!


13 nachfolgende Beiträge sind ausgeblendet

Alle anzeigen Immer alle anzeigen

Gesamter Thread: