[Mr.g-c]

Zitat von raedor

Niemand zwingt euch, sie einzusetzen... und alle anderen finden sie toll.

Zu 2.: LOL, d.h. Du bist ganz gegen Jets, auch wenn es die 100%ig realistische Implementierung in ArmA gäbe?

Toll finde ich die Modelle davon auch... die Umsetzung ist allerdings äußerst mangelhaft - wenn man sie denn auf einem 14KM Seitenlänge Gelände überhaupt ansatzweise realistisch einsetzen könnte.....
Euch st schon klar welche Reichweite Flugzeugradarsysteme und die Meisten Raketen haben?
Selbst die Winzige Sidewinder hat eine Reichweite von 18 Meilen!!!
So gross ist nichtmal das Arma2 Gelände....

Würde es eine dynamische Viewdistance in Flugzeugen geben, so dass man auch in 5KM höhe noch was sieht und man von dort aus GPS oder Lasergelenkte Bomben abwirft, hätte ich nichts dagegen.

Die jetzige Art, die Jets wie Helikopter im Tiefflug zu Nutzen und wenn möglich noch mit der Boardkanone Bodenziele zu bekämpfen (A10 ausgenomen)ist allerdings äußerst Lächerlich.
Mal ehrlich, die Kamphelikopter/A10+SU25 passen da doch 10mal mehr ins Gefecht.

[Lester]

Wie gesagt, sieh es als Hollywoodeffekt an (Filme wirste doch auch sehen können ohne gleich die Krise zu bekommen ) und kümmer Dich nicht weiter darum.

Es ist müßig sich über derartige Randeffekte des Spiels aufzuregen, Kernelement ist nun mal die Infantrie.

[INNOCENT&CLUELESS]

Zitat:

@I&C
Gut getrollt ... nur leider nicht mehr ... da bin ich meistens besseres von Dir gewöhnt als die unterste Schublade.
In die Engine haben sie für VBS2 Möglichkeiten integriert Wärmebilder darzustellen, was deiner Aussage vollkommen zuwider läuft. __________________

Ich bin aber schon genaueres Lesen von dir gewohnt.

Es gibt KEINE gesonderte Simulation unterschiedlicher Wellenlängen sondern nur die unterschiedlich visuelle Darstellung von "the one and only" Licht. Das meinte ich aber nicht. BIS müsste "nur" die Simulation von Licht mehrfach in der engine clonen und die Ausbreitungsmerkmale je "Wellenlänge" unterschiedlich parametrisieren und fertsch ist die simulation von Radar, IR, Laser......

[raedor]

LOL, natürlich... das Licht wird ja in der RV sicher so physikalisch korrekt berechnet, daß dann alle anderen Frequenzen genauso gut funktionieren werden indem man ein paar Parameter verdreht... abgesehen davon, daß es in der RV bisher nur eine richtige Lichtquelle geben kann...

[Mr.g-c]

Zitat von Lester

Wie gesagt, sieh es als Hollywoodeffekt an (Filme wirste doch auch sehen können ohne gleich die Krise zu bekommen ) und kümmer Dich nicht weiter darum.

Es ist müßig sich über derartige Randeffekte des Spiels aufzuregen, Kernelement ist nun mal die Infantrie.

Vielleicht hast du Recht..... dann sollten sie es aber um gottes Willen nicht als Simulation bezeichnen.
Andererseits... die Zeichen Weltweit stehen auf Sturm und ich bin froh wenn wir alle in Mitte 2009 noch in der Lage sind überhaupt was zu Spielen......

[realplayer]

Zitat von Mr.g-c

Andererseits... die Zeichen Weltweit stehen auf Sturm und ich bin froh wenn wir alle in Mitte 2009 noch in der Lage sind überhaupt was zu Spielen......

Ein paar Wochen bleiben uns noch ArmA2 auszuprobieren bei Q2/2009

[INNOCENT&CLUELESS]

Zitat:

LOL, natürlich... das Licht wird ja in der RV sicher so physikalisch korrekt berechnet, daß dann alle anderen Frequenzen genauso gut funktionieren werden indem man ein paar Parameter verdreht... abgesehen davon, daß es in der RV bisher nur eine richtige Lichtquelle geben kann...

Du bist zu sehr dem Bekannten verhaftet und verlierst dabei den Blick fürs Mögliche.

Was spricht dagegen "Lichtquellen" oder nennen wir sie "Strahler" einfach zu kathegorisieren, einfach nach Nummern, Typ1, Typ2 etc.
Dann definiert man für Sensoren ([simulierte]Auge, Kamera, IR Sensoren...) für welchen Typ "Strahler" sie empfindlich sind und mit welchem simulierten "Dämpfungsfaktor". Inwiefern Ausbreitung, Reflektion, Beugung etc überhaupt in der ArmA Engine simuliert ist - keine Ahnung - aber auf jeden Fall könnte man versuchen es erstmal halbwegs zu separieren und unterschiedlich zu simulieren.

Wenn zB Typ 1 = normales Licht
Typ2 = IR
Typ3 = Radar

ist, dann sollten Sensoren

Typ 1 nichts von Typ2+3 Strahlern sehen
Typ 2 Typ1 nur als Rauschen und Typ 3 nicht
Typ 3 nichts von Typ 1 und nichts von Typ 2 (ausser man simuliert korrekt einen Typ2 Strahler hoher intensität kombiniert mit einem Typ3 Strahler geringer Intensität)


Ist das Unmöglich?

[raedor]

Zitat von INNOCENT&CLUELESS

Du bist zu sehr dem Bekannten verhaftet und verlierst dabei den Blick fürs Mögliche.

Was spricht dagegen "Lichtquellen" oder nennen wir sie "Strahler" einfach zu kathegorisieren, einfach nach Nummern, Typ1, Typ2 etc.
Dann definiert man für Sensoren ([simulierte]Auge, Kamera, IR Sensoren...) für welchen Typ "Strahler" sie empfindlich sind und mit welchem simulierten "Dämpfungsfaktor". Inwiefern Ausbreitung, Reflektion, Beugung etc überhaupt in der ArmA Engine simuliert ist - keine Ahnung - aber auf jeden Fall könnte man versuchen es erstmal halbwegs zu separieren und unterschiedlich zu simulieren.

Wenn zB Typ 1 = normales Licht
Typ2 = IR
Typ3 = Radar

ist, dann sollten Sensoren

Typ 1 nichts von Typ2+3 Strahlern sehen
Typ 2 Typ1 nur als Rauschen und Typ 3 nicht
Typ 3 nichts von Typ 1 und nichts von Typ 2 (ausser man simuliert korrekt einen Typ2 Strahler hoher intensität kombiniert mit einem Typ3 Strahler geringer Intensität)


Ist das Unmöglich?

Nein, das habe ich nie gesagt. Du meintest nur, daß man das aktuelle Licht-Modell kopieren und vervielfachen müßte. Und das war falsch. Und das ist alles, was ich gesagt hab.

[flickflack]

Jap, man bräuchte es nur erweitern und zwar wieder an meiner Lieblingsstelle, den Shadern, die ja für Transform/Lighting/Texturing/Mapping verantwortlich sind. Und dann bräuchte man nur Zustände auswerten und entsprechend Mappen. Dass wäre in HLSL-Shadern einfach steuerbar über ne Technique, die man ausserhalb der Shader im Programmcode (Displayloop) zündet...Aus die Maus:

[C++]

// m_pEffect Instanz eines Shaderobjekts
switch (optics) {

case 1 /* FLIR */:
m_pEffect-> SetTechnique(“FLIRVISION");
break;

case 2 /* RESTLICHT */:
m_pEffect-> SetTechnique(“NVISION");
break;

case 3 /* RÖNTGEN */:
m_pEffect-> SetTechnique(“RGVISION");
break;

default:
m_pEffect-> SetTechnique(“NORMALVISION");
break;
}

[/C++]

Im Shader würde man jeder Technique jetzt ne andere Renderfunktion zuweisen, in der die Lichtformeln angepasst sind. So kann man Lichtquellen ein- oder eben ausschliessen. Bei FLIR/WBG bräuchte es bspw kein diffuses Lighting der Punktlichter im Raum, weil die "Leuchtkraft" des Pixels/Texels durch den Wärmekoeffizienten und die Polarisation der Optik besimmt wird, also wird der diffuse Faktor der Umgebungsbeleuchtung (Hemisphärenlicht, Sonne etc.) in der Lichtgleichung einfach missachtet und die endgültige Farbe des Pixels ohne diesen Faktor berechnet. usw. usf.

Richtige Photonen durch die Gegend zu ballern oder alles Raytracing zu unterziehen ist atm nicht wirklich in RT-möglich. Zumindest nicht bei der Szenengröße und Fülle.

[INNOCENT&CLUELESS]

Zitat:

Nein, das habe ich nie gesagt. Du meintest nur, daß man das aktuelle Licht-Modell kopieren und vervielfachen müßte. Und das war falsch. Und das ist alles, was ich gesagt hab.

Das währe nur der Design-Ansatz des Ahnungslosen gewesen in völliger Unkenntnis der aktuellen Implementierung.

Trotzdem halte ich es für den einzig richtigen Ansatz um diesen Aspekt in der Engine zukunftssicher zu implementieren - alles gesondert zu behandeln.

Bis dahin kann ja flickflacks Ansatz helfen wenn es nicht die CPU/GPU zerreisst.

@Flickflack: Kann man damit auch radarreflektion simulieren? Derzeit ist für den vehiclescanner einfach nur eine Art "radarfootprint" definiert, egal in welcher Laage das vehicle ist und egal wie die Wetterbedingungen sind (wenn ich richtig informiert bin)

Wenn nun eine Lichtquelle der Klasse "Radar" die Umgebung ausleuchtet, dann entstehen besonders helle Reflektionen auf Flächen, welche als solche definiert sind. Könnte man dies nutzen um nur vehicles "Radar" reflektieren zu lassen und den virtuellen radarempfänger nur Licht ab einer bestimmten intensität anzeigen zu lassen?

[Bensu]

Zitat von flickflack

Ne ich glaube er meint damit eher das "Vorhersageproblem" in MP-Spielen. Guter Code überbrückt Aussetzer im Protokollstrom und interpoliert die Bewegung, damit die "flüssig" bleibt. Und umso weiter die Sprünge, und unkontrollierter wegen der schnellen Richtungsänderungen, desto schwieriger die "Vorhersage", was dann also voraussetzt, dass kontinuierlich Daten reinfliegen, damit die Bewegungen weniger vorhergesagt werden müssen. Also noch mehr Last und "Lageinfluss" auf alles andere.

Ja, aber dieses Argument gilt nicht wirklich... Beispiel: Läuft ein Soldat vor mir und plötzlich ist er einen Meter mehr auf der linken Seite, oder fliegt ein Jet über mich und "beamt" sich 10 Meter nach links ist relativ gesehn genau das gleiche, und nervt beide Male gleich stark. Schlechter Ping, bleibt schlechter Ping, egal op Infanterist oder Pilot!

Und warum sollten Flugzeuge in Arma keine Daseinsberechtigung haben? In Ofp könnte ich dem ja noch zustimmen, immerhin konnte man da kaum mehr als 2000m Sichtweite einstellen, egal auf welchem PC. Bei Arma sind selbst die 10000m, bei entsprechendem PC drin, und somit kann man seine Ziele schon aus grosser Entfernung bekämpfen. --> Realistisch

[Lester]

Zitat von INNOCENT&CLUELESS

Bis dahin kann ja flickflacks Ansatz helfen wenn es nicht die CPU/GPU zerreisst.

Sein Ansatz würde performancemäßig theoretisch keine Auswirkungen haben, da lokal der Sichtmodus auf andere Texturen/Shader gewechselt wird.
Ich möchte Wetten das ungefähr genau der Mechanismus ist, den VBS2 für das Wärmebild anwendet.

Allerdings zieht die Sache einen kleinen Haken mit sich, jeder zusätzliche Sichmodus benötigt einen Satz Shader auf den umgeschaltet wird (kein Problem) unter Umständen aber auch zusätzliche Texturen, deren Speicherplatz sehr schnell zum riesigen Problem werden kann weil das Streaming dann deutlich häufiger gefragt sein wird.

[burns]

Zitat von Lester

Allerdings zieht die Sache einen kleinen Haken mit sich, jeder zusätzliche Sichmodus benötigt einen Satz Shader auf den umgeschaltet wird (kein Problem) unter Umständen aber auch zusätzliche Texturen, deren Speicherplatz sehr schnell zum riesigen Problem werden kann weil das Streaming dann deutlich häufiger gefragt sein wird.

Vom Platz her seh ich als Endanwender kein Problem .. 16GB hat ArmA momentan bei mir. Da wären +6gb zum Hauptspiel für ein FLIR und andere Sichtmodi leicht zu verschmerzen.

Oder meintest du Speicherplatz im Sinne von RAM?
Weiss ja nicht wielange die Engine braucht um son Shaderwechsel auszuladen und durchzuführen. Beim Wechsel von Tag auf Nacht per Skiptime, bei NVG & setaperture, oder Shaderless (beim Speichervorgang sieht man des häufig), ist von einem Ladevorgang sogesehen ja nichts zu merken. Aber mit nem Haufen Texturen der gewechselt werden muss, sähe das wohl auch schon wieder anders aus..

Im Interview war afaik auf die Frage VBS2 FLIR ja/nein nur die Rede vom unheimlichen Arbeitsaufwand den es benötigte, und das es deshalb wohl nicht in ArmA2 schaffen würde. Der Unterton von "ätschibätsch, exclusive Feature" lassen wir mal raus

[laggingape]

Zitat von burns

Der Unterton von "ätschibätsch, exclusive Feature" lassen wir mal raus

Wär ich mir gar nicht so sicher, was ich im VBS2 Customer Support Forum zum Thema ArmA 2/ArmA2 Engine so mitbekommen habe ist es gar nicht so sicher das die VBS 2 Version mit der neuen (Arma2) Engine alle features vom VBS 2 mit ArmA 1 Engine bekommt. ... Muss aber dazu sagen das die Infos recht wage sind.

[Lester]

Ich meinte natürlich den Rambedarf, zumal teilweise ohnehin bei Texturenqualitäten unverständlich geklotzt wird.
Fallschirm, Blätter und (teilweise) Uniformtexturen sind oft deutlich detailierter als sie jemals auch auf härtesten Einstellungen sichtbar sind.

Ein zusätzliches Texturenset halbiert grob betrachtet somit den verfügbaren Speicherplatz, Ladezeiten im direkt sichtbaren Bereich
oder Ansichtumschaltzeiten (ausblenden, laden, einblenden) im niedrigen 2stelligen Bereich wären jedenfalls sehr *räusper**piieep*.

[burns]

Zitat von Lester

oder Ansichtumschaltzeiten (ausblenden, laden, einblenden) im niedrigen 2stelligen Bereich wären jedenfalls sehr *räusper**piieep*.

Macht man halt ne Ladeanimation rein, wie früher bei Resident Evil
Oder verwendet fürs FLIR z.B. einfach gekachelte Texturen, ist ja eh alles nur Schwarz & Weiss. Somit hätt man dann für ein tolles feature ganze 100kb zu laden

Zitat von laggingape

..das die VBS 2 Version mit der neuen (Arma2) Engine alle features vom VBS 2 mit ArmA 1 Engine bekommt. ...

Hää?
VBS2 = ArmA2 = VBS2 + ArmA1 ?

evtl. war mein Frühstückstoast vergammelt und ich werde fiebrig ... aber für mich ergibt das keinen Sinn

[laggingape]

Zitat von burns

Hää?
VBS2 = ArmA2 = VBS2 + ArmA1 ?

evtl. war mein Frühstückstoast vergammelt und ich werde fiebrig ... aber für mich ergibt das keinen Sinn

Hast recht, verdammt kompliziert geschrieben , ich glaub eher mein Toast war vergammelt.

Bin in der Arbeit, sprich hab jetzt nicht wirklich zeit nochmal was zu schreiben.

[Blackland]

VBS2 wird in Version 2 mit den Features der VRE3 ausgestattet werden/sollen/mögen ....

Die jetzige VBS2 Version (vor 2.0) hat das noch nicht.

Die Frage ist also: Was fällt weg, was kommt dazu? Ist doch net so schwer...

[flickflack]

Zitat von Bensu

Ja, aber dieses Argument gilt nicht wirklich... Beispiel: Läuft ein Soldat vor mir und plötzlich ist er einen Meter mehr auf der linken Seite, oder fliegt ein Jet über mich und "beamt" sich 10 Meter nach links ist relativ gesehn genau das gleiche, und nervt beide Male gleich stark. Schlechter Ping, bleibt schlechter Ping, egal op Infanterist oder Pilot!
[...]

Ist natürlich doch ein Argument, weil sich ein Flugzeug schneller bewegt und damit gravierendere Richtungsänderungen über größere Distanzen hinweg vollführen kann, als ein Fusssoldat. Das dürfte sich beweisen lassen

@Lester: Die Texturen sind dabei egal, Du hast bereits mindestens alle diffusen Texturen am Start, was endgültig für eine Farbe rauskommt ist dabei relativ Latex. Der Pixelshader (was allerdings lustigerweise auch der Vertexshader kann, also hier der Effekt "Nightshader") definiert nach bestimmten Formeln, welche Farbe entsteht. Die endültige Texelfarbe wird durch Lichteinfluss und Texelfarbe (der Ausgangstextur) bestimmt, plus eigenem Kram. Der Nightshader in OFP ist eigentlich recht simpel und ein gutes Beispiel, wenn er so funktioniert wie ich mir das von aussen so denke. Im Endeffekt macht da die HW T&L-Pipeline auch nix weiter, als alle Farben in den grünen Farbbereich zu schieben. Bei RGB(A) auch kein großes Problem. Man braucht kein zuvor gefärbtes Textureset. Deshalb einfach eine Textur - wie die dann endgültig aussehen soll, definieren die Shader. Obs jetzt grün wie in "NIGHTVISION" oder FLIR-Weiß ist und schnöde rauscht, is Brust. Wenn man jetzt aber noch doll mappen will und irgendwelche Sci-Fi-Krötenbuckelekelschimmel-Optik bauen will, denn brauchste natürlich neue Texturemaps. Jo. Aber für die normalen Sichtmodi reichts: Ich kann das Objekt und seine Textur identifizieren, dank irgendwelcher Attribute, und ich kann dieses Objekt nach bestimmten Kriterien entsprechend umgestalten.

@IC: Mit dem Radar muss ich mal kurz nachdenken...

Ich glaube das Aussenden von Strahlen wird in Spielen nicht implementiert, sondern eher der Effekt als solcher. Der Merovingian aus Matrix würde sagen: Cause and Effect. Das Cause ist gar nicht mal so wichtig, weil man die Wirklichkeit versucht nachzubilden, nicht abzubilden - zumindest im Spielsektor. Als erstes würde man versuchen das 3D-Scannerfeld auf eine 2D-Radaranzeigen zu blitten->RenderToTexture() - irgendwie fancy. Dann weiss man ja als Coder selbst, welche Objekte für Radar interessant sind, dass könnte einfach nur ne Eigenschaft/Attribut des Objekts sein, die im Vision-Mode "Radar" sichtbar gezeichnet werden. Und/oder man speich0rt das Attribut in der Vertexdeclaration:

Zitat:

const D3DVERTEXELEMENT9 vertexDecl[] =
{
...,
{ 0, 28, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0 },
{ 0, 40, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0 },
...,
D3DDECL_END()
};

TEXCOORD ist der interessante Punkt, hier könnte man von TEXCOORD0 bis TEXCOORD7 Werte hinzufügen, unter anderem auch Eigenschaften (FLIR/RADARREFLECT->kein RADARREFLECT-Attribut, also in RADARVISION erst gar nicht zeichen, oder voller Alpha drauf....ferddich), die man widerum im Shader auswerten, einfärben und dank RenderToTexture() auf den Radarschirm in 2D anzeigen könnte. Man wertet vermutlich also eher logisch aus: Hat das Objekt eine "radarerfassbare" Höhe, reflektiert es Radarstrahlen etc. pp. Das könnte man dann verbinden mit der eigenen Position und nem Taster (Raypicking vermutlich) der die Objekt scannt, oder man rennt gleich durch den Szenengraph und weiss damit sofort wo man ist, und was "scanbar" im Umfeld rumgurkt. Senden und Empfangen, also physikalische Analyse, ist in Spielen, die wirklich echtzeitritisch sind, eher unwahrscheinlich. Man simuliert den Effekt und ein bissel "Rechnen und Erfassen", aber so richtig mit Strahlen und krassem Dingsbums nicht. Es sei denn, es ist ne 1A-Simulation, die sich nur mit einem Fahrzeug auseinandersetzt. Oder bald dank Multicores. Vermutlich aber geht die Hauptlast weiterhin eher in Grafik als Mechanik. Und bei ner Konzentration auf Grafik, wird man den Rest "tricksen"...watn kack langer Text!

[Bensu]

Zitat von flickflack

Ist natürlich doch ein Argument, weil sich ein Flugzeug schneller bewegt und damit gravierendere Richtungsänderungen über größere Distanzen hinweg vollführen kann, als ein Fusssoldat. Das dürfte sich beweisen lassen

Klar, das stimmt. Hab ich ja sogar selbst geschrieben, nur spielt es keine Rolle. Ein Fusssoldat ist nunmal meist nur wenige Meter vor mir, während sich ein Jet meist mindestens einige hundert Meter bis ein par Kilometer weit von mir weg ist. Das gleicht sich wiederum aus.

Nehm ich einen nahen Soldaten ins Visier oder einen entfernten Jet, verschlechtern sich, wenn der Gegenspieler eine schlechte Verbindung hat, die Chancen ihn zu treffen beide male um mehr oder weniger den gleichen Wert