View Full Version : [FRAGE] - Bsp 4 (kleiner Vorgriff): Wie langsam darf es sein?
Hallo,
ich habe jetzt den Scanfill und das Backface Culling in Bsp 4 implementiert.
Die Frage ist wie langsam darf die Anzeige sein?
Ich weiß das "Software-Rendering" nicht grade flott ist, aber meine bee.atoff
oder system.atoff ruckeln schon ganz schön bei Flat Fill (wenn man sie transformiert logischerweise).
Ich nehme mal an es liegt an meiner verkorksten Implementierung der Algorithmen. Aber wie wird das dann erst bei Phong Shading Berechnungen?
Da brauch ich ja dann nen Cluster.
Hat da jemand zufällig schon Erfahrungen und kann mir sagen ob es bei ihm auch so ist? Und wie wirkt sich eine zu ruckelige Anzeige auf die Abgabe aus?
Naja zumindest der Würfel und der Sphere gehen super :)
Danke und lg,
Roland
Wolfibolfi
20-10-2004, 13:12
Das Programm is einfach lahm, bei mir hats auch geruckelt als gäbs keinen Morgen.:D
Is denen bei der Abgabe aber eh wurscht.
Was hast du für einen Rechner? Mir is aufgefallen, dass P3s ziemlich langsam sind, und P4s bei Java ziemlich rocken. Also die an sich schlechte Pro-MHz Leistung beim P4 is bei Java (oder zumindest dem CG-Programm) gar nicht mehr so schlimm.
ChrisChiu
20-10-2004, 13:16
Was für ein System hast du? Auf meinem Athlon XP 2500+ ist es jedenfalls auch langsam, es liegt also vermutlich nicht an deiner Implementation.
Bee und System sind relativ hochpolygonig, d.h. schnell werden die beiden atoffs nicht wirklich sein können.
Keine Sorge, mein Programm war damals auch super langsam (noch dazu auf alten PII Laptop :shinner: ). Glaube mich zu erinnern, dass es da auch ein atoff file gab mit einem ziemlich sarkastischen Text a la:"The Speed of Java" oder so.
Phong Shading wird später überhaupt furchtbar langsam.
Jaja das ist schon okay...
die biene zu öffnen mit den shadern war bei meinem ur alt rechner damals ain selbstmordkommando...
und erst eine rotation oder meine güte...
also einfach immer die sphere oder den würfel verwenden*g*
lg
Hallo,
ja sowas in der Richtung dachte ich mir schon das ich mit meinem
Athlon XP 1.6 GHz kein Leiberl habe :)
Wollte nur sichergehen das nicht eine gewisse "Mindestframerate" verlangt wird.
Schließlich hat man ja selbst auch gewisse Ansprüche. Unter 25 fps geht nix *g*
Also Würfel ich komme.
lg,
Roland
naja .. java kannst du nicht alle schuld geben ... ich mein, das cg framework ist ja nicht gerade optimiert ... tausende von objekte werden erstellt gezeichnet und dann wieder verworfen ... und das bei jedem redraw. das wär auch langsam, wenn das ganze in c++ programmiert worden wäre, da hilft auch der effizenteste linienalgorithmus nix mehr.
ChrisChiu
20-10-2004, 19:49
naja .. java kannst du nicht alle schuld geben ... ich mein, das cg framework ist ja nicht gerade optimiert ... tausende von objekte werden erstellt gezeichnet und dann wieder verworfen ... und das bei jedem redraw. das wär auch langsam, wenn das ganze in c++ programmiert worden wäre, da hilft auch der effizenteste linienalgorithmus nix mehr.
Trotzdem ist der Hauptanteil an der Langsamkeit vor allem Java zu verdanken. Sicher wär's auch nicht so schnell unter C++, ist ja immer noch Software-Rendering. Übrigens hat Java nicht so einen Performance-Impact beim Erstellen und Verwerfen von Objekten wie es C++ hat, in Java ist das also durchaus in Ordnung.
Allerdings denk ich Didaktik geht vor Optimierungstricks, die dann keiner versteht. Es hat in der Vergangenheit schon einige Dinge gegeben, wo in älteren Frameworks etwas "optimierter" gemacht worden ist, und das von keinem verstanden wurde.
Die Geschwindigkeit ist jedenfalls in CG1 LU noch relativ zweitrangig. Dafür gibt's ja dann die weiterführenden LVAs wie CG2/3 LU und Echtzeitgrafik :)
Allerdings denk ich Didaktik geht vor Optimierungstricks, die dann keiner versteht. Es hat in der Vergangenheit schon einige Dinge gegeben, wo in älteren Frameworks etwas "optimierter" gemacht worden ist, und das von keinem verstanden wurde.
kann ich vollkommen verstehen immerhin muß das dann wieder in diversen Foren breitgetreten werden um es den Leuten veerständlich zu machen...
also natürlich nur ihr tutoren:D
aber ich mein zum testen der algorithmen reicht doch in den meisten Fällen sowiseo die Sphere oder sonstige einfache konstrukte...(es sei denn beim flieger sind keine normalvektoren eingetragen:D)
ich wollte damit ja auch nicht sagen, dass das framework optimiert werden soll. was ich damit ausdrücken wollte ist, dass es nicht nur die schuld von java ist, dass das framework langsam ist. zb bei algodat 2 mussten wir ein dna sequenze alignment programm schreiben, ich habs in java gemacht und es war schneller als einige c/c++ varianten ... und ich glaub nicht dass mein algorithmus so viel besser war als die anderen :-)
object creation ist meiner meinung nach beim CG1Framework sicher einer der haupttäter, da die ganzen codefragmente der algorithmen von der java runtime mit ziemlicher sicherheit jit compiliert werden und als native code laufen.
hallo,
habe soeben den scan-fill-algo implementiert und mich gewundert, warum einige horizontale Linien nicht gezeichnet werden. irgendwie steh ich an.
es gibt zwar in dem algo bei dem erstellen der edgelist eine abfrage ob eine horizontale linie vorliegt aber keine weitere behandlung falls es eine ist, jedoch hab ich mir die punkte ausgeben lassen die eine kante bilden und es sollte eigentlich keine gerade sein. beim stern wie er im bild unten zu sehen ist, ist es ja auch eigentlich ersichtlich.
irgendwie steh ich im moment aber an woran es liegen könnte. ich hab auch versucht, den algo nahezu 1:1 zu übernehmen (mit yNext und makeEdgeRec) wobei ich natürlich nur die clipped[][] genommen habe und nicht die vertices[].
bei dem beispiel-screen 2 für die 4te abgabe sind ja der würfe, sie sphere und die teapot zu sehen. wurden diese verschoben oder befinden sich diese noch an den original positionen? bei mir schaut das nämlich wie in img2 aus. anscheinend hab ich aber bei der umwandlung der projektions- in device-koordinaten einen fehler beganngen :( ... es lebe die allseits beliebte fehlersuche
lg,
roman
edit: habe hoffentlich den fehler gefunden, obwohl hier und da ist leider noch ein oder 2 pixel zu sehen, die nicht zu sehen sein sollten (teapot oder flügel von bee). stutzig machte mich die ausgabe der activelist bei den scan(lines) 140, 150, 160 des Stern.atoff da hier zwar die edges der jeweiligen zeile in der activelist eingetragen wurden in der fillscan-methode jedoch trotzdem die differenz der beiden kanten 0 ergab, da er 2x die gleiche kante hernahm, und somit keine linie gezeichnet wurde. nachdem ich activelist.update vor fillscan in der drawclipped-methode gestellt habe funktioniert es nun im großen und ganzen :) lediglich die eigentliche kante fehlt mir noch in meiner ausgabe, da nur das innere der kante gezeichnet zu werden scheint
edit2: soda ... und mit vorstellen der resort-methode vor die fillscan()-methode ist nun die ausgabe so wie sie sein soll, ohne gelegentliche punkte :) kleiner tipp noch an jene, die es vielleicht erst machen: der algorithmus kümmert sich anscheinend nicht um die schließende kante, also die von cnt-1 hin zu 0.
Wolfibolfi
21-10-2004, 15:40
Vielleicht irgendwo ein "<" und ein ">" verwendet, aber kein ">=" oder "<=".. oder irgendwo in einer schleife um eins zuwenig iteriert..
Trotzdem ist der Hauptanteil an der Langsamkeit vor allem Java zu verdanken.hast du irgendwelche fakten, die diese meinung untermauern würden? irgendwelche benchmarks? selbst, wenn ein java-programm 10% oder meinetwegen sogar 20% langsamer wie ein äquivalentes c++-programm wäre, kann man bei einem ruckeligen software renderer wohl kaum davon sprechen, das läge _vor allem_ an java.
thebigMuh
21-10-2004, 20:37
Ich habe für Multimedia 1 einen Convolution Filter in Java geschrieben (Weichzeichner Gruppe, falls irgendwer das schon gemacht hat / noch machen wird). Der soll, idealerweise, über ein Video drübergelegt werden. Da das allerdings schweinehundeelendslangsam ist, hab' ich genau den gleichen Filter noch einmal in C++ für DirectShow geschrieben.
Java: 3x3 box blur fängt bei einem 352x240 Video an, frames zu verlieren. Höhere Videoauflösung und/oder größere Kernels sind überhaupt unbenutzbar, und das JMF schmiert gerne mit einer Access Violation ab.
C++: 720x360 DivX mit 5x5 box blur rennt spitze :thumb: 40% Prozessorauslastung.
Wenn ich irgendwann zwischen meinen Übungen Zeit finde, pack ich den Filter mit UI und allem zusammen, dann kann's gern jeder ausprobieren. Naja, und der JMF Filter sollte für MM1 sowieso bis Ende des Semesters fertig sein :)
Zusammenfassend: Die zwei Filter sind so ziemlich die schäbigsten und einfachsten Dinge die man machen kann - über ein ByteArray drüberiterieren, und halt viele casts (Byte in float und wieder zurück in Byte), Multiplikationen und Additionen durchführen. Java stinkt dabei mächtig ab. Es werden keine Objekte instanziiert, oder sonst irgend ein Mumbo-Jumbo gemacht. Die DirectShow und JMF translate() bzw. process() Funktionen sind sich erstaunlich ähnlich, beide haben sowohl als Eingabe als auch als Ausgabe ein einfaches eindimensionales array aus bytes.
Ciao, ¡muh!
... Da das allerdings schweinehundeelendslangsam ist, hab' ich genau den gleichen Filter noch einmal in C++ für DirectShow geschrieben.
hallo,
hm ... hast du es wirklich für oder mit directshow unterstützung gemacht? wenn du es mit directshow unterstützung gemacht hast, was ich mir gut vorstellen kann, dann ist es auch kein wunder wenn es wesentlich schneller ist als java. einerseits ist keine virtuelle machine notwendig die alle aufrufe des programms überwacht, andererseits kann directshow auf eine volle hardwareunterstützung (windows-hall-layer) zurückgreifen. java muss hier erst umständlich beim system nachfragen.
also direct show mit java zu vergleichen finde ich wie wenn du einen ferrari mit einem truck vergleichst.
was aber nun java als grafik-umgebung angeht. david brackeen hat in java einen software renderer geschrieben, der neben fullscreen auch noch ansehliche frameraten (für einen softwarerenderer) zusammenbringt. und das mit bsp-trees einigen ki-algorithmen und sonstigen goodies. und das beste ist, jeder kann es selber testen: http://www.brackeen.com/javagamebook/ source runterladen und austesten ;)
das buch kann ich übrigens sehr weiterempfehlen. also mir gefällt es wirklich sehr gut und es ist nicht so verwirrend geschrieben wie das von Hearn Baker.
mich würde interessieren, wie viel schneller die bsp wären, wenn man diese dann statt mit software-rendering mit jogl oder einer anderen OpenGL-Unterstützung programmiert.
lg,
roman
thebigMuh
21-10-2004, 23:20
wenn du es mit directshow unterstützung gemacht hast, was ich mir gut vorstellen kann, dann ist es auch kein wunder wenn es wesentlich schneller ist als java. einerseits ist keine virtuelle machine notwendig die alle aufrufe des programms überwacht, andererseits kann directshow auf eine volle hardwareunterstützung (windows-hall-layer) zurückgreifen. java muss hier erst umständlich beim system nachfragen.
Naja, genau darum ging's hier ja :)
Da Java den Bytecode durch eine VM wurschten muß, geht ein ganzer Haufen Performance flöten.
Und ich habe den Effekt zwar als DirectShow Filter geschrieben, aber das heißt nicht, daß ich irgendwelche spezielle Hardware benutze um den Effekt zu rendern. Die Vorgehensweise ist bei C und Java identisch - ich krieg ein Array mit dem Bild, und wende eine Faltung darauf an, komplett in Software. Daß es noch um einiges schneller wäre wenn ich in C meine Grafikhardware verwenden würde ist mit schon klar :D Also: Nur Software hier, keine Pixelshader oder sonstiges um die Faltung zu berechnen.
Ciao, ¡muh!
ChrisChiu
22-10-2004, 00:10
hast du irgendwelche fakten, die diese meinung untermauern würden? irgendwelche benchmarks? selbst, wenn ein java-programm 10% oder meinetwegen sogar 20% langsamer wie ein äquivalentes c++-programm wäre, kann man bei einem ruckeligen software renderer wohl kaum davon sprechen, das läge _vor allem_ an java.
Du beantwortest die Frage selbst: es ist halt ein Software-Renderer! Sowas ist halt langsam.
Und dass das Java-Programm wohl 10-20% langsamer ist als es das äquivalente C++ Programm wäre, genau das meinte ich ja.
Du scheinst meine Aussage so zu interpretieren als ob ich gesagt hätte, dass es unter C++ plötzlich superschnell wäre, aber das ergäb wohl keinen Sinn
:eek2:
ChrisChiu
22-10-2004, 00:14
mich würde interessieren, wie viel schneller die bsp wären, wenn man diese dann statt mit software-rendering mit jogl oder einer anderen OpenGL-Unterstützung programmiert.
Das wäre sinnfrei (im Kontext der LU zumindest; es steht dir allerdings frei, das trotzdem auszutesten, obwohl das wohl nicht sonderlich interessant wäre, die Beispiele sind halt "nur" ein Renderer und noch keine echte Engine). Der Zweck der CG 1 Laborübung ist es, genau die Funktionen, die OpenGL bereitstellt, zu implementieren. Also quasi jene Aufgaben zu implementieren, die die Hardware normalerweise implementiert. Das Lehrziel ist, dass man dann eben genau weiß, was die Hardware macht. Ist ja auch CG1.
Wenn du OpenGL programmieren willst, empfehle ich dir die Computergraphik 2/3 Laborübung, sowie die Echtzeitgrafik VU, die ja weiterführende Lehrveranstaltungen sind.
Also bevor da irgendwie Kritiken auftauchen wie "warum macht man das in Software", sollte man sich mal erst überlegen was das Lehrziel im großen Kontext (also im Zusammenhang mit den weiterführenden Lehrveranstaltungen) ist. Dann kommt man drauf, dass es so wie es in CG1 LU gemacht wird, didaktisch wohl optimal ist.
Also bevor da irgendwie Kritiken auftauchen wie "warum macht man das in Software", sollte man sich mal erst überlegen was das Lehrziel im großen Kontext (also im Zusammenhang mit den weiterführenden Lehrveranstaltungen) ist. Dann kommt man drauf, dass es so wie es in CG1 LU gemacht wird, didaktisch wohl optimal ist.
hm ... eigentlich war das keine kritik an der lva oder weil ich unbedingt opengl programmieren will, ich verstehe es auch und finde es sogar gut alles von grund auf mindestens einmal gemacht zu haben um die vorgänge dahinter besser zu verstehen. ich habe das post eher als antwort auf muh's posting gestellt, wo er directshow und c++ verwendet und dabei wesentlich schneller ist und ich einfach damit sagen wollte, dass wenn ich java mit opengl verwende die frameraten auch wesentlich besser sein würden.
lg,
roman
thebigMuh
22-10-2004, 02:33
Aye, s'wäre richtig.
Aber wie gesagt, ich habe keine Hardwarebeschleunigung verwendet.
Hier source:
Java:
public int process(Buffer inBuffer, Buffer outBuffer)
{
//...hier gibt's nichts zu sehen
int minBoundx, minBoundy, maxBoundx, maxBoundy;
float[] tempVal = new float[3];
maxBoundx = (int)Math.floor(kernelWidth / 2.0f);
maxBoundy = (int)Math.floor(kernelHeight / 2.0f);
minBoundx = -maxBoundx;
minBoundy = -maxBoundy;
for ( y = 0; y < ih; y++)
{
for ( x = 0; x < iw; x++)
{
tempVal[0] = tempVal[1] = tempVal[2] = 0.0f;
ip = lineStrideIn * y + pixStrideIn * x;
for ( cy = minBoundy; cy <= maxBoundy; cy++ )
{
if ( y + cy >= 0 && y + cy < ih )
{
for ( cx = minBoundx; cx <= maxBoundx; cx++ )
{
if ( x + cx >= 0 && x + cx < iw)
{
ip = lineStrideIn * (y + cy) + pixStrideIn * (x + cx);
tempVal[0] += ((float)((int)inData[ip] & 0xFF)) * kernel[cx + maxBoundx][cy + maxBoundy];
tempVal[1] += ((float)((int)inData[ip + 1] & 0xFF)) * kernel[cx + maxBoundx][cy + maxBoundy];
tempVal[2] += ((float)((int)inData[ip + 2] & 0xFF)) * kernel[cx + maxBoundx][cy + maxBoundy];
}
}
}
}
outData[op++] = (byte)((tempVal[0] < 0.0f)?0.0f:((tempVal[0] > 255.0f)?255.0f:tempVal[0]));
outData[op++] = (byte)((tempVal[1] < 0.0f)?0.0f:((tempVal[1] > 255.0f)?255.0f:tempVal[1]));
outData[op++] = (byte)((tempVal[2] < 0.0f)?0.0f:((tempVal[2] > 255.0f)?255.0f:tempVal[2]));
}
}
return BUFFER_PROCESSED_OK;
}
(Ich hoffe ich werde nicht von einem MM1 Übungsverantwortlichen geschlachtet - drum habe ich ein paar Zeilen am Anfang entfernt, das funktioniert so NICHT.)
Und hier in C++ (Kernelgröße fix auf 5):
HRESULT CBlurFlt::Transform(IMediaSample *pIn, IMediaSample *pOut)
{
CheckPointer(pIn,E_POINTER);
CheckPointer(pOut,E_POINTER);
//make a straight dump of our properties first
HRESULT hr = Copy(pIn, pOut);
if (FAILED(hr)) {
return hr;
}
// Check to see if it is time to do the sample
CRefTime tStart, tStop ;
hr = pIn->GetTime((REFERENCE_TIME *) &tStart, (REFERENCE_TIME *) &tStop);
if (tStart >= m_effectStartTime)
{
if (tStop <= (m_effectStartTime + m_effectTime))
{
if (this->m_effect != IDC_BLUR)
{
return Transform(pOut);
}
else
{
// we apply the blur effect as copying effect
// grab essential image metrics
BYTE *pData; // Pointer to the actual image buffer
BYTE *pOData; // Pointer to output data
long lDataLen; // Holds length of any given sample
int x,y; // General loop counters for transforms
RGBTRIPLE *prgb; // Holds a pointer to the current pixel
RGBTRIPLE *orgb; // output triple
float tPx[3]; // temporary pixel value for convolution
int i, j;
float *kernel; // our kernel
int kWidth, kHeight, kOff; // kernel dimension & Offset
kWidth = kHeight = 5;
kOff = (kWidth-1)/2;
kernel = new float[kWidth * kHeight];
for (j = 0; j < kHeight; j++)
for (i = 0; i < kWidth; i++)
kernel[j*kWidth + i] = 1.0f / (float)(kWidth * kHeight);
AM_MEDIA_TYPE* pType = &m_pInput->CurrentMediaType();
VIDEOINFOHEADER *pvi = (VIDEOINFOHEADER *) pType->pbFormat;
ASSERT(pvi);
CheckPointer(pIn,E_POINTER);
pIn->GetPointer(&pData);
lDataLen = pIn->GetSize();
CheckPointer(pOut, E_POINTER);
pOut->GetPointer(&pOData);
orgb = (RGBTRIPLE*) pOData;
// Get the image properties from the BITMAPINFOHEADER
int cxImage = pvi->bmiHeader.biWidth;
int cyImage = pvi->bmiHeader.biHeight;
prgb = (RGBTRIPLE*) pData;
for (y = 0; y < cyImage; y++)
{
for (x = 0; x < cxImage; x++, orgb++)
{
tPx[0] = tPx[1] = tPx[2] = 0.0f;
for (int kx = -kOff; kx <= kOff; kx++)
{
for (int ky = -kOff; ky <= kOff; ky++)
{
int cx = x + kx, cy = y + ky;
if (cx >= 0 && cx < cxImage &&
cy >= 0 && cy < cyImage)
{
int curPos = (cy * cxImage + cx);
tPx[0] += prgb[curPos].rgbtRed * kernel[(ky + kOff) * kWidth + kx + kOff];
tPx[1] += prgb[curPos].rgbtGreen * kernel[(ky + kOff) * kWidth + kx + kOff];
tPx[2] += prgb[curPos].rgbtBlue * kernel[(ky + kOff) * kWidth + kx + kOff];
}
}
}
orgb->rgbtRed = (BYTE)tPx[0];
orgb->rgbtGreen = (BYTE)tPx[1];
orgb->rgbtBlue = (BYTE)tPx[2];
}
}
return NOERROR;
}
}
}
return NOERROR;
} // Transform
Das war's prinzipiell. Falls irgendjemandem ganz große Performancehunde einfallen, die ich in Java eingebaut habe, bitte melden :)
Daß der C++ Filter weit davon entfernt ist, optimiert zu sein, ist mir klar (z.B.: ich füll für jeden frame den kernel neu an :P ) - war trotzdem schon viel schneller.
Ciao, ¡muh!
Du scheinst meine Aussage so zu interpretieren als ob ich gesagt hätte, dass es unter C++ plötzlich superschnell wäre, aber das ergäb wohl keinen Sinnnatürlich ergäbe das keinen sinnm aber du hast in etwa das gesagt, deshalb habe ich nachgefragt. es ging ja nicht darum, dass das programm _ein bisschen_ langsamer als irgend eine referenz-implementierung, sondern _extrem_ langsam ist. wenn du sagst, das liegt vor allem an java, dann bedeutet das, dass es eine andere sprache/plattform (je nachdem, was du mit java ursprünglich überhaupt gemeint hast *g*) gibt, mit der es viel schneller geht. jetzt ist eh alles klar ... wenn du eigentlich meinst, dass es vor allem daran liegt, dass es ein software-renderer ist, dann sag das halt gleich :-)
ChrisChiu
22-10-2004, 07:50
natürlich ergäbe das keinen sinnm aber du hast in etwa das gesagt, deshalb habe ich nachgefragt. es ging ja nicht darum, dass das programm _ein bisschen_ langsamer als irgend eine referenz-implementierung, sondern _extrem_ langsam ist.
So extrem auch wieder nicht. Aber aus Java ist wie gesagt wohl auch nicht so sehr viel mehr rauszuholen. Will sagen, als Java-Implementation ist das Framework wohl +/- 5-10% der maximal erreichbaren Performance. Man wird aus vereinzelten, nicht wirklich grundlegenden Optimierungen wohl nicht wirklich viel herausholen können. Mit grundlegenderen Optimierungen mein ich die eigentlich bessere "Form" von Optimierung, nämlich z.B. ein komplexitätstheoretisch besserer Algorithmus. Das Framework verwendet ja eigentlich die bekannten Algorithmen, und insofern wird sonst wohl nicht mehr so viel zu holen sein an Performance.
wenn du sagst, das liegt vor allem an java, dann bedeutet das, dass es eine andere sprache/plattform (je nachdem, was du mit java ursprünglich überhaupt gemeint hast *g*) gibt, mit der es viel schneller geht.
Insofern wollte ich herrausstellen, dass das Framework jetzt keineswegs horrend langsam ist, und als Java-Implementation nah an der Grenze der maximal möglichen Performance einer solchen Anwendung kommt. Und somit eher noch eine andere Sprache etwas an Performance rausholen kann. Es somit zum Großteil an Java liegt, und nicht an einer "schlechten" Implementation des Frameworks.
Es wird zwar schon hier und da zwecks Didaktik der eine oder andere mögliche "Performance-Trick" nicht angewandt, um die Studenten nicht zu verwirren, aber das ist alles nicht wirklich gravierend.
jetzt ist eh alles klar ... wenn du eigentlich meinst, dass es vor allem daran liegt, dass es ein software-renderer ist, dann sag das halt gleich :-)
Ein Software-Renderer ist langsam, das ist jetzt nicht unbedingt eine neue Erkenntnis :). Und für ein Java-Programm ist dieser Software-Renderer nahe am maximal machbaren an Performance.
Ich weiß nicht was ihr alle erwartet, aber das ist ein Standardsoftware-Renderer, der eigentlich ziemlich ordentlich funktioniert, dafür dass er ein Software-Renderer ist. Assembler-handoptimierte Software-Rendering-Performance wie es in der Demoszene z.B. üblich ist (oder zumindest war), die jeden nur erdenklichen Trick ausnützen oder approximieren, wird wohl keiner von einem Java-Programm erwarten (und genau so ist das "das liegt zum Großteil an Java" zu verstehen).
So extrem auch wieder nicht. Aber aus Java ist wie gesagt wohl auch nicht so sehr viel mehr rauszuholen. Will sagen, als Java-Implementation ist das Framework wohl +/- 5-10% der maximal erreichbaren Performance. ...
... Und somit eher noch eine andere Sprache etwas an Performance rausholen kann. Es somit zum Großteil an Java liegt, und nicht an einer "schlechten" Implementation des Frameworks.
Ein Software-Renderer ist langsam, das ist jetzt nicht unbedingt eine neue Erkenntnis :). Und für ein Java-Programm ist dieser Software-Renderer nahe am maximal machbaren an Performance. ...
hm ... mir kommt der software-renderer von david brackeen (http://www.brackeen.com/javagamebook/) trotzdem noch schneller vor. zudem liegt mir die art wie der autor schreibt wesentlich mehr als jene von harn baker.
ich habe aber noch nicht versucht, objekte wie das bee.atoff oder system.atoff in david brackeens software-renderer zum laufen zu bekommen. bisher hab ich aber durchwegs frameraten von 50 frames aufwärts gehabt, und das bei bsp-trees mit pathfinding und anderen game-goodies
lg,
roman
ChrisChiu
22-10-2004, 15:45
hm ... mir kommt der software-renderer von david brackeen (http://www.brackeen.com/javagamebook/) trotzdem noch schneller vor. zudem liegt mir die art wie der autor schreibt wesentlich mehr als jene von harn baker.
Von den Kapiteln her scheint mir das Buch vom Brackeen jedoch einen anderen Schwerpunkt zu haben als die CG1 LU. Ich habe das Hearn Baker Buch jedenfalls mittlerweile sehr gern (trotz einiger Schnitzer wie Fehlern auf ein paar Seiten, zumindest bei meiner Second Edition), weil es wirklich ein (nicht nur spielspezifisches) Resource Book für (fast) alles computergrafische ist, und sich nicht nur auf (interaktive) Echtzeitgrafik (wie etwa Spiele) bezieht, sondern auch die nicht-Realtime Themen einschließt (die etwa auch in CG2 und CG3 VO dann relevant sind). Ich bezweifle dass der Brackeen Themen wie Triangulationsalgorithmen für konkave Polygone mit einschließt :).
ich habe aber noch nicht versucht, objekte wie das bee.atoff oder system.atoff in david brackeens software-renderer zum laufen zu bekommen. bisher hab ich aber durchwegs frameraten von 50 frames aufwärts gehabt, und das bei bsp-trees mit pathfinding und anderen game-goodies
BSP-Trees sollten ja eher beschleunigend wirken, ist also ned so ein Argument wenn man sagt "Wow der ist schnell obwohl er BSP-Trees verwendet". Pathfinding dagegen schon, gut.
Bei den einfacheren Objekten ist das CG1 Framework jedenfalls auch schnell, es geht ja eigentlich nur um jene "langsamen" Objekte und langsamere Shading Varianten wie halt Phong Shading.
Wer mir wohl den "Software-Renderer" vom Brackeen mal anschauen und schauen inwiefern da Unterschiede sind.
EDIT: hab mir das jetzt mal angeschaut, der schaltet ja in einen Fullscreenmodus. Ich schätz einmal, dass der da einfach optimierte FrameBuffer Klassen verwendet oder so (ähnlich DirectX, oder vielleicht mit native-Komponente in die Richtung). Das CG1 Framework verwendet ja einfach nur einen regulären Canvas, und die Bilddaten sind ein einfaches Array, das nicht über den Videospeicher gemanagt wird.
Weiters sind die Objekte zumindest im Chapter 9 und Chapter 16 Beispiel jetzt nicht unbedingt der Polygon-Komplexitätshammer. (sind wohl nur ein paar Duzend Triangles pro Bildschirm, eben dank BSP-Culling). Gut, dafür gibt's Texturing. Ist also jetzt nicht unbedingt vergleichbar mit den 3d-Atoffs, da hat jedes einzelne ja mehr Polygone als eine beliebige Szene in dem Beispiel.
Insgesamt denke ich lenkt bei seinem Software-Renderer viel Optimierungszeugs wie der Fullscreenmodus oder die Klassen für diesen Framebuffer-Modus eher ab vom eigentlich wichtigen, den grundlegenden Algorithmen mit denen auch die 3D-Beschleuniger-Hardware und die 3D-API selbst arbeitet.
Das Lighting sieht auch komisch aus, wenn sich diese Geschütztürme drehen, ändert sich die Beleuchtung darauf nicht (sieht statisch aus). Gerade Lighting ist aber der Performance-Killer, speziell mit Schattierungstechniken wie Phong Shading (oder auch Gouraud-Shading bei den komplexeren 3D-Atoffs).
Also ich muß ehrlich sagen beeindrucken tut mich der Brackeen-Software-Renderer nicht - er ist auf interaktive Geschwindigkeit ausgelegt, und scheint sehr viel auszulassen was aber im CG1 Framework drin ist, und an anderer Stelle wieder viel zusätzlich zu haben was für die CG1 LU den Rahmen sprengen würde (das ganze Game und Szene-Zeugs, also quasi die Engine. Bei CG1 LU geht's ja nicht um eine Engine). Mich wundert's ehrlich gesagt nicht, dass der schneller wirkt (meiner Vermutung nach aber nicht wirklich ist, zumindest nicht gravierend).
Ich glaub du kannst den Brackeen einfach nicht mit dem Hearn-Baker vergleichen, und auch die beiden Frameworks nicht. Die Performance vom CG1 Framework halt ich aufgrund der erwähnten Dinge, die es macht, jedenfalls für nicht schlechter als die vom Brackeen Renderer.
(windows-hall-layer)
_hall_ layer? hardware abstraction layer layer layer? ;-)
mich würde interessieren, wie viel schneller die bsp wären, wenn man diese dann statt mit software-rendering mit jogl oder einer anderen OpenGL-Unterstützung programmiert.
habe mir noch nicht alle tasks angesehen, aber ich glaube da ist kaum was dabei, das außerhalb der kernfunktionalität von OpenGL 1.0 liegt. eine OpenGL-version wäre also fast rein GPU-bound und somit je nach grafikkarte ziemlich schnell.
habe in den ferien ein paar OpenGL-bindings für java ausprobiert und würde jogl empfehlen. leider ist die kompatibilität mit neueren grafikkarten noch nicht so toll, mit java habe ich sogar noch schwierigkeiten, einen exclusive fullscreen mode zu kriegen. lwjgl ist anscheinend ein bisschen besser, was kompatibilität angeht, und umgeht awt/swing-probleme dadurch, dass es das gesamte fenster mit der native lib macht. allerdings hat das einige unangenehme eigenheiten (code, der mit jedem anderen binding funktioniert, weil sich die meisten an die C-syntax halten, muss grundsätzlich umgeschrieben werden), ist schlecht dokumentiert, und der lead-developer ist mir auch nicht sonderlich sympathisch.
hast du schon was mit jogl gemacht? ich schreibe gerade an einer engine ...
mit java habe ich sogar noch schwierigkeiten, einen exclusive fullscreen mode zu kriegen.
dafür brauchst du aber noch keine opengl unterstützung, das kann java so alleine auch schon ;)
folgendes codesnipplet von david brackeen (http://www.brackeen.com/javagamebook/) könnte weiterhelfen:
JFrame window = new JFrame();
// width, height, colordepth, refreshrate
DisplayMode displayMode = new DisplayMode(800,600,16,75);
// get the GraphicsDevice
GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice device = env.getDefaultScreenDevice();
// use the JFrame as the full screen window
window.setUndecorated(true);
window.setResizable(false);
device setFullScreenWindow(window);
// change the display mode
if (displayMode != null && device.isDisplayChangeSupported())
{
try
{
device.setDisplayMode(displayMode);
}
catch (IllegalArgumentException ex) { }
}
um wieder auf den alten DisplayMode zurückzustellen genügt es setFullScreenWindow(null); zu setzen zB
public void restoreScreen()
{
Window window = device.getFullScreenWindow();
if (window != null)
window.dispose();
device.setFullScreenWindow(null);
}
hoffe es kann weiterhelfen.
lg,
roman
ach ja wegen speed wireframe -> scanfill ... mit ein paar tricks ist scanfill nicht viel langsamer als wireframe ( ich würde sogar sagen bei mir ists fast gleich schnell )
ChrisChiu
25-10-2004, 02:19
ach ja wegen speed wireframe -> scanfill ... mit ein paar tricks ist scanfill nicht viel langsamer als wireframe ( ich würde sogar sagen bei mir ists fast gleich schnell )
Naja, "fast" gleich schnell sind sie sowieso, da der wirklich verlangsamente Faktor erst die Beleuchtungsberechnung sein wird.
Aber zumindest von der Fillrate her ist ja scanfill ein wenig aufwendiger (mehr Pixel zu füllen). Das muß aber nicht unbedingt viel gravierender sein als Wireframe (je nach Bildschirmauflösung und Größe des Objekts im Viewport), also hast du schon recht.
vBulletin® v3.7.1, Copyright ©2000-2009, Jelsoft Enterprises Ltd.