Aufgaben für Juni 2009

Eddy (Ich):
- Energiesystem
- Regen
- 3D-Windsystem
- (Fahrstuhl) ?

Trike:
- Sägewerk
- Baum-fällen und Holz
- Scriptbasierter Landschaftsgenerator (?)
- Conkit-Verbesserung

Carli:
- Heightmaps zum Laden der Landschaft

James:
- Model: Fahrstuhl (schon rdy oder?, what about upload )?

Ok ? So könnte ichs mir vostellen.

Willi:
- Wolkenmodell überarbeiten
- Billiges Model für Leitungsbausätze (oder nehmen wa das vom conkit)

bevor Trike mit dem Conkir anfangen kann fehlt noch was entscheidendes: das Menü.
Wie habt ihr euch das z.B. vorgestellt? (zur Not werd ichs auch machen, so ist das nicht, aber Community ist eben Community)

Öhm ich bin daran gescheitert dass ich es nicht hinbekommen hab, das der rendermenu-Callback aufgerufen wird. Ich habs dann aber auch nicht weiter versucht.
Braucht man zum publizieren von Methoden eig. den register-typ? Ich hab in o eine Funktion "boing" und würde die dann gerne mit o.boing aufrufen.


Öhm, ich dachte da so an was clonkiges. Also ein Menü unten rechts (natürlich mit Abstand), in dem man das Zeug auswählen kann. Dafür könnte man ja auch das bisherige menu_back nehmen.

hm..und ich versteh den ganzen menü-script nich :/

Mit Pushcrew legst du die Steuerung und die Rendermenu-Anzeige vom Clonk aufs Menü um
Mit Popcrew gibst du die Steuerung wieder zurück


Register ist eine Aufrufkonvention, wie stdcall oder cdecl eben, aber nicht zu empfehlen, weil experimentell und verbugt.

Die Heightmap ist fertig.
Todo: Dokumentieren, übers Netzwerk übertragen
Leider ist Synchronität der Erstellung der Landschaft stark von der Grafikkarte abhängig.

schon im svn drin?

Sieht so aus. Die ENgine hänkt sich aber beim laden auf.

bei mir gehts..läd bloß n bisschen, aber auch noch ok..und das ergebnis sieht echt super aus

Wow das mit Hightmap is aber Schön

ganz meinerseits

Aber eins wäre noch schön wenn das lalles abgerundet wäre oder das man das einstellen könnte z.b. Abgerundet: http://www.clonk.de/gallery.php?lng=de&sec=cx2&img=ashlands_travel1.jpg Hier sind die Berge ja so abgerundet nicht so eckig wie bei gwX, in gwx sind auch immer so stufen.

das hängt mit der Auflösung der heightmap zusammen.
Ein Grafustufenbild kann 255 Stufen unterscheiden, das ist nicht gerade viel. Mehr bringen würde hier ein 16bit Graustufen-Bild.
Aber welches Format nehmen wir da?

@carli: könntest du nich ne func machen die an einem bestimmten punkt (x,y,z) guckt, ob sich dort eine flüssigkeit, ein festes mat, oder luft befindet?
z.b. so

Code:

stdcall IsInLiquid(x,y,z);
stdcall IsInMat(x,y,z);
stdcall IsInSky(x,y,z);

edit:
ich brauch die für das haifischseeszen, und außerdem wird die ganz praktich, wenn wir uns mal ans boot machen, um zu guckn, was unter dem is

Da gibts auch so ein Problem mit Bäumen Und Gras da is Hälfe in der Luft und an orten wo mans nicht mag

unter andrem dewegn brauch ich die funktion, weil man die orte dann ohne gras machen kann, indem man die höhe abfragt, wo kein material mehr is

- Scriptbasierter Landschaftsgenerator (?)

Wäre es nicht gut, wenn die Engine an sich einige festgelegte Algorithmen eingebaut hat, mit denen man Voxelmaps generieren kann? Das Generieren solcher mit einer Funktion in einer Interpretersprache stelle ich mir nicht allzu schnell vor...
Einteilen könnte man diese dann in 2D Algos und 3D Algos. Da eine Voxelmap ja drei dimensional ist muss man bei den 2D Algos eine Ebene bestimmen auf den der Algorithmus angewandt wird. Beispielsweise mit der Ebenengleichung Ax + By + Cz > D, wobei D durch die Funktion des Algorithmus ersetzt wird. Also quasi:
Ax + By + Cz > D(x,y). Damit sollten nicht nur gerade Szenarien möglich sein, sondern auch Hänge etc.
D(x,y) ist dann beispielsweise die Funktion die auf einzelne Werte der Heightmap zugreift, oder einen Wert berechnet, der die Höhe an der bestimmten Stelle angibt.
A,B,C sind die x,y und z-Werte der Normalen der Ebene. Sind x = y = 0 und z = 1, so hat man eine gewöhnliche "Heightmap mit Voxeln". Variiert man diese Werte, bekommt man Hänge etc.
Anders kann für jeden Voxel x,y,z ein Wert durch die Funktion D(x,y,z) berechnet werden. Ein solcher Algorithmus könnte z.B. der von Perlin Noise sein. Damit könnte man dann quasi unendlich große Höhlensysteme bauen, oder, kombiniert mit einem der obig genannten 2D-Algos, eine durchlöcherte Landschaft mit Schluchten, die bei jedem Neustart immer wieder anders aussieht.

Naja, die Liste von Ideen wird langsam zu lang...

nyon

was ich höre klingt toll, nur die gleichungen versteh ich nich..aber schön schön.
nur wer kacht das ding dann?

ein mapeditor mit brushes(objekte, materiale) & voxel und so wär nett ^^

Meinst du sonen Editor wo man selber Maps zeichen kann?, Eigentlich wäre das doch garnicht so schwer wenn es Heightmap gibt, oder?

Es gibt bereits eine engine-interne Variable, die bezeichnet, in welchem Material ein Objekt gerade steckt. Wenn man das noch etwas ausbaut, kommt sicherlich was ordentliches zustande.
folgende Vorschläge:

Code:

stdcall GetInside(x,y,z) mit Rückgabewert Material an der Welt-Position
stdcall ObjectInside(object) mit Rückgabewert Material, in dem das Objekt gerade taucht

wenn du dein OK gibst bau' ichs so ein

"dein OK": du bist doch leader
wär schon schön, brauchn könnte man vllt dann noch ne func die angibt, ob das mat flüssig oder fest is, weil ich nich so gern palmen im wasser spawne^^
vllt könnte man in beides noch Mat schreiben(also z.b. GetMatInside) damit man so erkennt, was es zurück gibt, sonst is aber alles schön (ich denk nur an die leute die gwx-script nich lernen wollen, wenn wir erstmal status habn , scripter werden ja scheinends immer gebraucht )

Du könntest doch einfach eine konstante Liste der IDs der flüssigen Materialien erstellen - alle anderen sind eben unflüssig.

Code:

cdecl matisliquid(m)
{
if(m = getid("water"){return 1;};
if(m = getid("acid"){return 1;};
return 0;
}

noch besser: eine Engine-Funktion, die die Eigenschaften eines Mateials zurückgibt!