Blocks und Nexus

Hier bin ich wieder, mit einer anfänger frage.

Das Level besteht nur aus Blocks.
Dieser kleine ausschnitt reicht aus, um den default nexus zu überlasten. Ich kann den nexus natürlich erhöhen, aber das kann auf die dauer doch nicht gut sein.
Wie löst ihr das problem?

Außerdem:
Gibt es eine möglichkeit die steine auf einer gewissen distanz zu entfernen und wiederherzustellen?
Momentan mach ich das mit INVISIBLE und PASSABLE, damit keine unnötigen polygone und kollisionen berechnet werden.
Die Map-entities lassen sich bei mir allerding gar nicht unsichtbar machen und wahrscheinlich gibts sowieso eine bessere lösung dafür.

Bestimmt hat jemand schonmal so eine frage gestellt, aber ich finde nur posts in dennen steht das man es machen soll, aber nicht wie ....

mfg
eure
OTTER

Heul beim "I hate WED" Thread mit, hilft zwar nicht, ist aber cool. Hab ich mir sagen lassen =/



Was macht dich so sicher das die Engine das Problem nicht bereits löst? Immerhin ist genau für so etwas ein Scenemanager gut. c_trace() und alles was damit zusammenhängt (c_move(), c_rotate() etc. pp), wird mit extrem hoher Wahrscheinlichkeit auf die Daten des Scenemanagers zugreifen und damit fällt eh alles raus was nicht in der Nähe ist.

Steht im Manual, wie man den Nexus setzt (-nx XX in der Befehlszeile).

Es kommt mir aber etwas komisch vor, dass dieses doch eher einfache Level den Default-Nexus von 40MB übersteigen soll?


Das wage ich doch arg zu beweifeln, warum sollten die ihren Dienst einstellen? Das hieße ja, dass sich Feinde, Plattformen usw. überhaupt nicht mehr oder ohne Kollisionserkennung bewegen, wenn die Objekte außer Sicht sind.

Superku, was ich damit sagen wollte:
Der scheduler bezieht sich nicht nur auf den sichtbaren Bereich
Der scenemanager bezieht sich nicht nur auf den sichtbaren Bereich

Wenn ich einen c_trace von vecA(-100, -100, -100) nach vecB(3, 42, 0) mache, und die Kamera bei vecC(1024, 1024, 1024) ist, wird c_trace natürlich die Daten vom Scenemanager nutzen die zwischen vecA und vecB vorliegen (wieviele Regionen das dann auch immer sind) und nicht die Daten von vecC in Betracht ziehen

Ahhh!

Übrigens: Mein wissenschaftlicher Vergleichstest ergibt folgendes:


Alle sichtbaren Blöcke sind auch WED-Blöcke (inklusive einiger, verschiedener Texturen), das Level ist ca 3mal so groß wie auf dem Screenshot und der Nexus ist bei 22MB.

Welche Fehlermeldung erhälst du denn genau?

Ich kanns mir nich erklären, aber nachdem ich ein wenig rumprobiert hab ist der nexus "NUR" mehr bei 32mb.
Außerdem kann ich das level auch nur über WED starten, da SED mir immer anzeigt "Nexus to small(0)" obwohl ich im spiel ja schon unter dem default wert bin.
Die braunen und gelben blöcke lassen übrigens auch einen unsichtbaren map-entity block spawnen(zur besseren kollisionserkennung).
Das macht aber nur 2-3mb unterschied.

[EDIT]: hab alles im level gelöscht und hab immer noch knapp unter 30mb nexus.
Ich mach grundsätzlich irgendetwas falsch....

Schon einmal an ein eigenes Levelformat gedacht?
Was für so ein Spiel einfach wäre, wäre ein Format das auf Rastergrafiken basiert und eine Farbe ein bestimmter Block ist. Die kann man dann auch einfach in Paint oder so editieren/erstellen.

Außerdem ist Zeugs zur Laufzeit generieren viel cooler.

Das ist eigentlich überflüssig. Schreibe in deren Aktionen
c_setminmax(my);
set(my,POLYGON); // oder auch nicht, wie du magst
oder setze deren Flags in WED.

Otter, Superku ich beneide euch um die nexus werte eurer Level. Ich krieg selbst für nur einen bruchteil meiner Grundfläche(unter berücksichtigung dass ich später noch schnell c_updatehull für tarrain brauche) meinen nexus nicht UNTER 100 mb! und das ist nur ein kleiner teil meines Tarrain!
Otter freue dich solange dein nexus klein bleibt!
EDIT: Ich weiß das ich das ganze Level auch deutlich reduzieren könnte das würde mir jedoch etwas wie granaten einschläge vermasseln also werde ich das als lätztes machen
@JustSid Gute Idee!
xxxxxxx

Ich checks nicht o__0'
Hab jetzt schon alles mögliche probiert, aber nexus wird nicht kleiner!
@JustSid:
Kann man diese methode auch leicht mit ganz normalen level strukturen verbinden?
Wenn ja, wo gibts ein tutorial dafür?
@Superku:
Die gelben und braunen blocks sind nicht komplett eckig sondern etwas abgerundet. Ohne die Map blocks, bleib ich auch mit diesen codestück beim springen manchmal hängen.
Und währe es nicht performance lastiger, wenn ich diese blocks alle auf POLYGON setze?
Wie hast du das z.B. bei "MeinKraft" gelöst? Erzeugst du tausende von blocks erst am beginn des spiels, oder sind die alle schon im level gesetzt?.
@xxxxxxx:
WOW! Du ärmster! Hoffentlich ergibt sich da auch was für dich.

mfg
OTTER

haben solche Map entities den Polygon nicht automatisch gesetzt? übrigens: ich kann auch den Nexus von ca. 30000 ohne richtiges Level nachvollziehen hatte ich auch obwohl ich zu der Zeit noch kein Level hatte.
EDIT: Ich war grade auf der suche nach einem Fehler da entdeckte ich in der Fehlermeldung liste das der Nexus auch für functionen gebraucht wird also kanst du kein Level geladen haben und trotzdem 30000 kb nx haben!
xxxxxxx

An den functionen liegts wahrscheinlich nicht.
Immerhin funktionieren meine anderen levels die viel größer sind als das jetztige mit nur 18mb nexus (1010 objects).
Der einzige unterschied sind halt die vielen einzelnen blocks. 59mb nexus (1353 objects)


Die braunen und gelben blocks sind modelle...

Ich glaube, in diesem Level sind einige Blocks aus der Reihe gerutscht.
Eigentlich macht es keinen Sinn, weil Du sicherlich keinen BSP aktiviert hast, aber was früher bei den mit Blocks gebauten Leveln tödlich war, waren Blöcke deren Flächen leicht versetzt zu den anderen waren.
Oder Deine Blocks sind, im unterschied zu denen Deiner anderen Level ein wenig kleiner, so dass sich nebeneinanderliegende Blocks nicht mehr zu einem größeren Block verbinden.

Nexus:
Wenn ich nicht ganz falsch liege setzt sich der Nexus doch groesstenteils
nur aus den Texturen, der bittiefe bzw aufloesung und vor allem den
Einstellungen beim Compilieren des Levels(Radiocity etc)+ shadowmaps.

Wenn du da etwas feintuning betreibst, sollte das auch sinken.
(z.b tesselate ausschalten (oder auto)).

Auch hast du einen minimum Nexus wert(wahrscheinlich fuer die Engine selbst).

Entscheidend ist auch die flaeche, die ein Pixel abdeckt, d.h. die texturflaeche pro Block.

Lücken zwischen meinen blöcken? Unmöglich! Hab das rasteranordnungsdingens in der oberen leiste mitte benutzt und die stehen absolut nahtlos nebeneinander.

Was ich aber herausgefunden hab ist, dass model-entitys im gegensatz zu map-entitys nach dem ersten erstellen kein bisschen nexus mehr erhöhen!
Wenn ich also alle Blocks durch neue model-blocks austausche hab ich was ich wollte.

Was mich aber jetzt brennend interessiert ist, ob diese methode einen hacken hat.

[EDIT]Sorry Superku, hab mich getäuscht. Das mit den POLYGON funktioniert einwandfrei und ohne hängenbleiben.

was deine Luecken angeht: je groesser das level, desto ungenauer, ich glaub
das liegt bei 0,0001(?), muesste i.-wo im Manual stehen(fuer Bloecke).Das faengt leider schon bei 50000+ Quants an.Unterschiede zwischen den Modellen und Map-Entitis findest du auch im Manual, unter WED.

Nachteile bei Modellen hast du nicht.Vielleicht einen hoehren Speicherverbrauch.
(und externe Shadowmaps, sofern benoetigt).
Und die dynamische Beleuchtung bei wenigen Polygonen relativ zur Flaeche.

Danke Ayumi.
Da bin ich ja beruhigt.

Auch danke an alle anderen.
Das nexus problem konnte fürs erste umgangen werden

Habt ihr vielleicht auch noch eine idee wie man dashier vermeiden kann?
Die Blocks kleben 100% aneinander, haben aber manchmal einen spalt wenn man vorbeiläuft.

mfg
OTTER

Ist das ein echter screenshot, oder hast du das in einem Bildbearbeitungsprgramm nachgestellt? Denn da wundert mich grad etwas der Ausschnitt. Bzw sieht das irgendwie nach paralleler und nicht nach perspektivischer Projektion aus, wie es aber bei dem ersten Bild der Fall ist.
Auch ist mir jetzt nicht klar ob du da Modelle, Levelgeometrie oder Mapentities platzierst. Und wie sieht so eine Textur dazu aus? Im Fall von Modellen, was hast du da für ein UV layout?

Ayumis Kommentar halte ich für falsch, denn Gamestudio nutzt für das meiste ersteinmal nur fixed point variablen, so dass deren "Auflösung" zwar stark begrenzt ist, es aber keine Ungenauigkeiten gibt. Und wenn man an den maximalwert kommt geht es eben wieder auf der anderen Seite des Zahlenstrahls los. Wenn die Daten dann zur Grafikkarte gepusht werden werden da spätestens wohl floats draus, vermutlich gilt das für Modellvertices schon vorher und vielleicht auch für die Blockvertices, da könnte ich mir aber gut auch noch fixed point vorstellen. Jedenfalls spielt die float Präzision auch erst eine Rolle wenn man denn an die Grenzen von var kommt. und das sind eh solche mini Ungenauigkeiten dass es bis 100mio Einheiten oder so keine Rolle spielt.

@Slin

Nunja, in dem Fall meinte ich Bloecke und keine Modelle.Und je komplexer, desto
ungenauer, darum bin ich ja auf Modelle umgestiegen.

z.b. eine grosse Stadt, die zum teil nur aus Bloecken besteht und sich
nahtlos ineinander fuegen.Dazu gibts ja die einstellungen:

- don t snap vertics
- merge across leave

Bringt nur leider nicht immer was.Ich such dir das mal bei gelegenheit raus,
bin nicht sicher , wo ich das gelesen hatte.
(Oder jcl hat das mal erwaehnt?mhm...)
Jedenfalls hies es noch: Das reicht fuer Gamestudio vollkommen aus.



Und laut den Post nutzt sie jetzt Modelle, die Risse werden durch das tiled
skinning kommen, wie du schon angesprochen hast.(sofern Modelle) , ansonsten spielt auch die Beleuchtung eine Rolle.

ich weiß das Thema hat mehr oder weniger ein ende aber eins verstehe ich nicht ganz: Die Blöcke haben scheinbar (sogutwie) keinen einfluss auf den nexus bei mir blieb der konstant zwischen 30000 und 40000 Tausend aber es ist nicht jedesmal mehr geworden meistens lag der nexus bei 35000 und zwischendurch/nachdem ich mein tarrain hinzugefügt hatte war/lag er bei 40000 also der standart nexus war manchmal voll aber auch nicht sehr viel mehr!
xxxxxxx

Warum schreibst du immer tarrain? Das heisst terrain

Weil sich die Rechtschreibung einiger Wort noch nicht allzuweit in meinem Kopf verbreitet had, öh ich meine natürlich hat
Danke!

Zu dem nahtlos problem und dem bild das ich gezeigt hab:
Das ist ein frontaler ingame-shoot von aneinandergereihten map-entitys.
Ich benutze zwar inzwischen wie gesagt modelle für diese art von blocks, aber der fehler existiert nach wie vor.

Links map entitys ---- Rechts model entitys

Ich hab ganz schön lang gebraucht bis ich den richtigen winkel hatte, damit der fehler konstant zu sehen ist.
Wenn man mit der kamera während der bewegung auf den block blickt, blitzen überall solche striche auf.

Echt komisch, oder?
OTTER

Hehe ach das ist einfach zu erklaeren,...(nehm ich an)...

es koennte sein, dass das durch komprimierte TGA texturen
hervorgerufen wird.
Nehm ein anderes Grafikprogram oder versuchs testweise mit
der selben Textur aber bmp.
Auch waere die groesse zu pruefen(2er potenz).

Bei mir kam das nur mit TGA dateien vor.

Gibt es eine alternative zum bmp, den das funktioniert (bei mir zumindest) keinen deut besser.

Mhm, up das Model mal bitte, dannschau ich mir das mal genauer an.

Das model ist ein einfacher block, dessen skin auf primitivste weise in MED erstellt wurde. Ich glaube ja nicht das es an dem model oder dessen textur liegt.
Aber vielleicht täusch ich mich ja.
http://www.file-upload.net/download-3238227/test_b.mdl.html
Die streifen sind gut zu sehen wenn die camera in einem 90° winkel steht.

Liegt wohl an deinen Einstellungen, wie gedacht.
Was hast du denn so in der main stehen?Ansonsten könnte das auch
ein Hardwarefehler sein.Grafikkarte, versuch die mal vom Staub zu befreien(rausnehmen, kontakte reinigen)...etc

EDIT: Hast du sie immer im selben Level getestet?
Wenn ja, dann nehm mal ein "jungfraeuliches" Level.

Ich nehm für sowas einfach nen staubsauger! Kein Scherz! Aber das einzige was staub machen kann ist die efektivität der kühlung zu stoppen! Es müsste dann schon ein echter fehler sein den man nicht soeinfach/garnicht beheben kann.
xxxxxxx

Seid ihr alle bekloppt?! o_O
Das ist doch offensichtlich ein Problem mit den Kanten an angrenzenden Blocks, vermutlich wegen Präzisionsproblemen der Variablen.

xxxxxx, ich wünsche dir vom Herzen das du für den Tipp eines Tages Jumper einsaugst, ayumi dir wünsche ich das du irgendwann mit deiner Spucke deine Graka kaputt machst.

JustSid du meinst doch nicht ernsthaft das ich so blöd wäre um da nicht mit viel vorsicht daran gehen würde... mein post war auch nur auf das säubern der grafikkarte bezogen!
und dir wünsche ich das du eines Tages deinen PC im klo versänkst!
PS:
das machst du mit absicht oder?
xxxxxxx

Da bist du aber selber schuld, mit dem Usernamen...

Zum topic: weiss nicht, ob es etwas hilft, ist "create mesh" im wed angekreuzt?

Ich war etwas mit User und dem Namen der im Forum angezeigt werden sollte verwirt eigentlich sollte ich Affe heißen!
Aber trotzdem kriegen es viele/die meisen hin 7 mal ein x zu schreiben!
Nochma @JustSid wie soll man denn biiteschön seine Graka sauber machen?
@Topic: Otter in meinem Level habe ich auch so ein problem und diese dummen ShadowMaps machen es noch schön deutlich(in WED seh ich keinerlei vertiefungen/erhöhungen) Wie gros ist dein Level denn, also wie viele quants?
xxxxxxx

@JustSid

Bei deinem Kommentar kann einem echt die Spucke wegbleiben.
Dir gehts aber gut oder?
Erstmal solltest du dir meine Beitraege "gruendlichst" durchlesen,
bevor du auf meinen Post antwortest und falsche Sachen rein interpretierst, ansonsten halt lieber die Klappe.

@xxxxxxx

Grafikkaten reinigen sich mit nix, wie er so schoen interpretiert hat^^
Aber ich verzichte mal auf meine Aussage, da soll er selbst drauf kommen.

Grafikarten nicht aber ihre Lüfter, jedenfalls sofern es keine wasser/flüssiger stickstoff kühlung ist(die werden aber eh nur bei prozessoren benutzt)!
xxxxxxx

Große Worte für jemanden der glaubt das eine Linie aus Pixeln entlang der Kante von zwei oder mehr Objekten ein Hardware Fehler ist der durch reinigen der Grafikkarte behoben werden könnte.

Ist mir auch gerade aufgefallen, aber das hat damit nichts zu tun.

Sie schickte mir auch nur ein Model.Daran hab ich das abgeleitet.Ganz einfach.
Und nun spar dir bitte weitere Kommentare.


ich stimme mal Widi zu..., wenn sie allerdings nur mit Modellen arbeitet,
wuerd ich das im compiler rausnehmen, dann wird das Problem vielleicht
verschwinden.

EDIT: User "jane" meinte noch, dass dies dann auch dein Nexus
problem regeln koennte.

Sidy ... sei nicht so fies!

An der Grafikkarte liegts bestimmt nicht (oder an der Kühlung).
Immerhin ist mein Computer erst 3 monate alt.


Das im Bild gezeigte level wurde ohne script gestartet. Einfach build und test.

Ich habe da so eine Ahnung. komm aber gerade nicht drauf wie ich das beschreiben soll hmm.

irgendwie kommt es mir so vor als wenn es indirect mit der beleuchtung zu tun hat.

Die Linie sieht für mich jedenfalls so aus als wenn sie von der hellen Kannte kommt.

Teste das mal und stell die Beleuchtung um.

Ja, die striche entstehen auf jedenfall dadurch das man die helle seite des würfels kurz durch diesen "spalt" aufblitzen sieht.

Würde der würfel auf jeder seite gleich beleuchtet werden würde es zumindest farblich nicht mehr auffallen. Aber das ist nicht wirklich eine lösung. :\

naja aber immerhin ein lösungsansatz.

jetzt wissen wir warum der Fehler auftritt.
Wir müssen nur noch rausfinden WARUM?

Enginefehler? Einstellungssache?

Ich vermute, dass es sich dabei um irgendeine ungenauigkeit handelt. Du könntest mal versuchen die Blöcke minimal größer zu skalieren, aber eben wirklich nur gaaaaanz minimal um eben diesen Spalt der offenbar vorhanden ist zu überbrücken, ohne aber dass sich faces überlagern, denn zfighting ist noch häßlicher als Spalte .

Kann doch nicht sein, das das nur bei mir so ist.
Das mit dem größermachen und kanten übereinanderlegen hab ich auch schon probiert. Kein erfolg.
Stapelt doch mal ein paar kisten auf- und nebeneinander und fliegt mit der kamera rund herum.

Ich habs auch! Allerdings benutzte ich keine Shadow maps so sieht man es zum glück nicht(jedenfals bei mir)!
xxxxxxx

Was für eine Seitenlänge hat denn so ein Block?

64 x 64 quants.
Die größe eines ganz normalen small cube's im WED.
Map-entity und model block haben den selben fehler ist also egal mit was man es testet.

Hehe also ich hab mit meiner Vermutung recht behalten, siehe PM.

Nehm den Snap raus, dann verschwindet das Problem.(getestet,
dabei hatte ich auch solche komischen Striche)

mal für mich und all diejenigen die das selbe Problem haben

welchen Snap rausnehmen?

Oben rechts in WED gibts ein kleines fenster mit Snap Haken.
Den einfach raus nehmen,....allerdings sind die meisten dazu
zu faul;)....ich hab die Funktion einmal probiert, ...das ist
nun einige Jahre her:p

EDIT: Bei Otter ist das problem damit aber leider immer
noch nicht geloest...

hab das ebend versucht bei mir nachzustellen
bei mir kahmen diese lichtdingens-Striche nicht hmm

Wie hast du den die lichter platziert?

EDIT: jetzt hatte ich es auch als ich die Lampe direct vor der wand hatte also bei mir waren es schattenstriche.

Vielleicht musst du nur die Lichter anderst platzieren.

EDIT2: das habe ich im WED-FAQ gefunden:
F: Ich bekomme quer über einige Blocks im Boden oder der Decke sichtbare Lichtnähte.
A: Der am häufigsten vorkommende Grund für Lichtnähte ist das Aufspalten eines Blocks - beispielsweise durch CSG Subtract - und ein Setzen des Flags Smooth für die vom Block abgetrenneten Teile. Dies glättet die Beleuchtung um die Kanten der Teile und ergiebt so Nähte verschiedener Helligkeit wenn sich die Teile berühren.
F. Ich habe hochauflösende Modelle als Geometrie in mein Level importiert, sie sehen aber nicht so glatt aus wie wenn ich sie als Entities platziere. Es gibt Helligkeits-Nähte entlang der Polygonkanten.
A. Wenn Sie ein Modell mit extrem kleinen Polygonen, die nur für ein oder wenige Lightmap-Pixels pro Polygon Platz lassen importieren, sind Unterschiede in der Lightmap-Helligkeit zu sehen. Die Lightmaps haben in diesem Fall nicht genügend Pixel, um zwischen den Polygonen zu glätten. Entweder erhöhen Sie die Lichtwerte oder die Lightmap-Auflösung oder die Größe der Polygone. Auch werden die Normalen zwischen aneinanderliegenden Polygonen nur dann geglättet, wenn Sie das Flag Smooth des Bloxks gesetzt haben - ansonsten bekommen Sie in der Regel scharfe Kanten an der Level-Geometrie.

Ich habe das Problem bei mir jetzt mal nachgebaut und bisschen damit herum probiert. Es ist alles perfekt aligned, man sieht die helle Seite von dem einen Block durch und nicht den Hintergrund und das verbessern des Depthbufferpräzision durch ändern der far und near Clipplanes auf einen extrem engen Bereich bringt keine Besserung. Da das Problem bei Isometrischer Projektion nicht mehr auftaucht und sich auch nur an den Seiten zeigt kann ich mir ein Präzisionsproblem bei der Projektion vorstellen. Du könntest mal versuchen das als Bug zu reporten, ich bin mir allerdings nicht sicher ob sich das fixen lässt. Aber vielleicht hat jcl auch noch irgendeinen guten Lösungsansatz parat. Ansonsten würde ich vermutlich für solche teile einfach nePlane statt eines cubes nehmen und dann nur an den Seiten noch entsprechendes Faces dazu nehmen. Am Besten wäre aber eventuell auch soetwas komplett als durchgehendes, bzw weniger größere Meshs umzusetzen. Denn eine hohe Zahl an Objekten, egal wie lowpoly sie ist, ist in der Regel eher ungünstig für die Performance.
Was noch sein könnte, ist Zfighting zwischen den Pixeln der Seitenwand und der Wand nach vorn, da an der Ecke ja im Prinzip beides auf der gleichen Pixelreihe liegt. Dazu werd ich jetzt nochmal was ausprobieren...

@M4sterm1nd: Deine Mühen verwirren eher als zu helfen, denn das was du da zitierst ist ein Problem mit statischen Lightmaps, bzw interpolierten Normalen. Da in diesem Fall beides nicht auftritt haben die FAQ Zitate nunmal auch nichts mit dem Problem zu tun.


Edit: Ändern der Trireihenfolge durch Löschen und neu Erstellen einiger Faces, bzw durch erstellen von Gruppen bringt auch keinen Unterschied.

oh du hast recht Slin da hab ich mich ein bisschen dumm ausgedrückt.

Das im FAQ nur soetwas zu finden ist, hab ich eigentlich gemeint.

Gibt es diesbezüglich schon etwas neues ob es ein bug oder ähnliches ist?

Von meiner Seite zumindest keine besserung.
Weis auch gar nicht was ich noch ausprobieren könnte ...