Posts by forkboy

    Nun die "Preisfrage" ist doch ziemlich einfach. Wenn man eigene Modelle bauen möchte, kostet das 29,99. Und der HomeNos gehört nun nicht zu dem Programmen, die man unbedingt jährlich auf den neuesten Stand halten muss (bzw. kann man das ja auch gar nicht).


    Noch mal zur Versionshistorie:


    HomeNos 5

    HomeNos 8

    HomeNos 13

    HomeNos 14


    Ja, dass Version 14 nahezu zeitgleich mit dem Release von EEP 14 kam, kann Erwartungen geweckt haben, dass das jetzt für immer so sein wird, dass mit jeder neuen EEP-Version, auch gleich eine neue HomeNos-Version kommt. Jedoch hat der alleinige Release von EEP 15, bisher ohne neuen Nos, diesen neuen "Trend" doch schon wieder gebrochen, nicht wahr. Ankündigungen des Verlags dazu sind mir auch nicht bekannt.


    Im Prinzip ist hier wohl wieder die "Normalität" eingekehrt, also die Situation der Zeit zwischen Version 8 bis 13.


    Ich bin mit EEP 12 eingestiegen und habe mir dann auch den HomeNos 8 geholt, nachdem ich noch eine EEP-9-Version im Netz kaufen konnte. Als kurz danach der HomeNos 13 herauskam, habe ich mir den auch zugelegt. Das hätte ich aber streng genommen nicht tun brauchen. Auch mit dem HomeNos 8 könnte ich mir immer noch Modelle bauen. Die Version 13 ziehe ich nur vor, wegen des neu integrierten Blender-Export-Plugins.


    Also, eine einmalige Investition von 29,99 Euro reicht aus, und man kann seine eigenen Modelle bauen. Ein ständiger, erneuter jährlicher Kauf, oder gar alle Jubeljahre, ist nicht erforderlich. Und es sieht zur Zeit nicht danach aus, als ob sich daran etwas wird.

    Dem nummerischen Aspekt kann ich nicht zustimmen, es ist auch eine Ordnungs- oder Platzfrage wenn "extra" darum eine EEP-Version auf dem Rechner sein muss, die man so nicht brauchen würde.

    Wie gesagt, kann man nach der Installation den größten Teil von EEP 13 löschen, weil die ganzen Modelle und Anlagen usw., die ja den größten Teil der Installation ausmachen, braucht man ja nicht, wenn man hauptsächlich in EEP 15 arbeitet. Was man genau noch auf der Platte lassen muss, damit der HomeNos startet, ist, wie gesagt, irgendwo im Forum beschrieben worden. Und das was übrig bleibt braucht man ja doch, nämlich um den HomeNos 13 zu starten. Letztendlich ist da also nichts, was man nicht braucht.



    Und in der Tat wäre es so, dass er sich z.Z. etwas altes mit eingeschränktem Funktionsumfang kaufen müsste.

    Nun ja, das hört sich an, als ob der HomeNos 14 (oder der HomeNos 15, wenn es ihn gäbe) ein ganz neues Progrämmchen wäre, mit unheimlich vielen neuen Funktionen, die man auch alle unbedingt braucht, nicht wahr (oder andersherum: der HomeNos 13 ist so veraltet, dass man damit nichts mehr anstellen kann). Dazu habe ich ja schon alles gesagt. Wenn es nicht ankommt, kann ich da nicht viel machen und wiederholen möchte ich mich nicht laufend.


    ---------------


    Ob eine "virtuelle" EEP-Installation (im Sinne, wie es einige Posts hier drüber geschildert wurde) wirklich ausreicht, da habe ich meine Zweifel. Ich glaube, das geht so einfach nicht. Die Registrierungspolitik von Trend ist schon recht restriktiv. Vll. soll dieser ganze Thread auch wieder nur eine versteckte Unmutsäußerung in dieser Richtung sein, und es geht gar nicht darum den Nos zu bekommen, um sich selbst Modelle zu bauen. Wer weiß, der "Wutbürger" sucht sich die schillerndsten Wege, um seinen Frust abzuarbeiten. Ich lese den Thread immer mehr in diese Richtung. Da ist also jemand, den interessiert der Nos nicht die Bohne. Aber, was er machen müsste (oder was er sich vorstellt, machen zu müssen), um ihn zu bekommen, regt ihn dermaßen auf, dass er diesen Thead unbedingt starten musste.

    Ich wollte nur gesagt haben, dass der TE mit dem Konstruieren loslegen könnte, wenn er denn wollte. Aber er stört sich weiterhin lediglich an einer kleinen und unwichtigen numerischen Ungleichheit. Die Beschriftungsfunktion scheint ihn nicht zu interessieren (sonst hätte er dazu was gesagt), also könnte der Nos 13 reichen. Aber er möchte die Zahlen schön passend. Nun, jeder wie er meint.

    So viele neue "Fähigkeiten" sind es ja nun nicht. Das Beschriften-Feature z.B. braucht man nun nicht unbedingt, wenn man sich sowieso nur eigene Modelle baut. Man fügt die gewünschte Beschriftung, oder was auch immer, beim Bauen des Modells hinzu, und benötigt die Möglichkeit, diese Änderungen in EEP vorzunehmen, dann ja nicht mehr. Für die Kunden eines Shop-Modells ist es sicher ein nettes Feature, aber, wie gesagt, wenn man sich nur eigene Modelle baut, ist es relativ sinnfrei. Und dann fiele mir nur noch die Physik-Unterstützung für Beladematerialien ein. Wenn du nicht vorhast, ausschließlich solche Modelle zu bauen, oder Modelle mit Beschriftungsmöglichkeit für den Shop, sollte der HomeNos 13 mehr als ausreichen. Du musst dann nur noch zusätzlich EEP 13 noch mal installieren. Irgendwo hier im Forum gibt es aber Hinweise, was man aus dieser EEP13-Installation alles rauslöschen kann, damit man nicht zwei volle Versionen auf der Festplatte haben muss, sondern nur eine auf das Nötigste beschränkte Version 13, soll heißen: damit der Nos startet.

    Die ganze Diskussion um EEP heißt für mich aber nicht, dass ich mit dem derzeitigen EEP unzufrieden bin, ganz im Gegenteil. Bei mir läuft es stabil und sehr gut. Das gilt auch für die Framerate, auch wenn EEP jetzt nicht die Möglichkeiten der neuesten Hardware voll ausschöpft.

    Dann hast du dich mittlerweile damit zufrieden gegeben, dass EEP keinen SLI-Betrieb unterstützt? :aa_1:


    ---------------------


    Das mit dem "Nicht an Konventionen des BS halten" verstehe ich nicht ganz. Ist das eine verklausulierte Kritik am Kopierschutz?

    Ich fühle mich geneigt, mal etwas grundsätzliches dazu zu sagen.


    Das Thema kommt ja immer mal wieder auf. Und immer wieder muss man feststellen, dass EEP kein Benchmarkprogramm für die neueste Hardware ist. Das war es wohl auch nie gewesen (Spiele eignen sich sowieso nur bedingt dazu, deswegen gibt es ja spezielle Benchmark-Programme). Erstaunlich dabei ist jedoch der scheinbar unerschütterliche Glauben, dass dies gefälligst so sein müsste. Die Engine von EEP ist in den Grundzügen seit EEP 7 unverändert (es gab mal den Versuch, die Mehrkern CPU-Nutzung zu verbessern (mit bescheidenem Erfolg, wie viele hier nach ausführlichen Testen berichteten)), also seit 2010. Spiele werden, was das angeht, auch keineswegs "zukunftssicher" entwickelt, dass man also überhaupt Gedanken darauf verschwendet, ob ein Spiel in 10 oder 20 Jahren noch die neueste Hardware ordentlich fordert. Eher das Gegenteil, steht der Gedanke, dass zum Erscheinungsdatum eines Spiels, dieses möglichst keine zu hohen Hardwareanforderungen hat, damit man die größtmögliche Nutzerzahl ansprechen kann, wohl mehr im Fokus. Wie sich Hardware in 10 Jahren entwickeln wird, ist schwer vorauszusagen. Eine Prognose für das nächste Jahr, ist im Prinzip schon vermessen. Und die Hardware wird nicht nur an sich schneller, sondern bekommt auch immer neue (oder effizientere) Rechenverfahren "gelehrt". Von AVX z.B. konnte man 2010 noch nichts ahnen (flächendeckende 64-bit-Unterstützung haben wir auch noch nicht allzu lange), usw. usf.

    An Einstellungsmöglichkeiten, an denen man herumschrauben kann (bzw. teilweise muss), hat EEP aber schon genügend, wie ich finde.


    Es gäbe auch die Möglichkeit, dass sich ein Kon die Variante, die auf den Anfangsbildern zu sehen war, noch einmal vornimmt, und es besser macht, wenn da wirklich Bedarf sein sollte.

    Wenn man eine Cubemap gewählt hätte, die zu dem oben präsentierten Szenario passen würde, dann würde es halt an anderer Stelle wieder unpassend sein.


    An Cubemaps in EEP herumzuschrauben (also, dass die Entwickler Zeit darauf verwenden) halte ich nicht für günstig. Ziel sollte es sein, irgendwann passable Echtzeitspiegelungen zu haben. Das geht seit einiger Zeit in Spielen sehr gut. Die Berechnung ist in modernen Engines also möglich.


    Bis dahin gilt die alte EEP-Regel: nicht zu nah ranzoomen und nicht so genau überall hinschauen. :aa_1:

    Ist mir so noch nicht aufgefallen. Hab's aber auch nicht ausgiebig getestet (in EEP, meine ich, in Blender, und anderen Programmen gibt es keinerlei Probleme). Wenn ich mit meinem Tipp zu vorschnell war, entschuldige ich mich dafür.

    Bezweifel ich. Steine, Felsbrocken sind keine guten Vorführobjekte für Normal-Maps oder Bumpmapping.


    Eine Heizung z.B., ganz einfaches Objekt, Quader mit 6 Polygonen, Struktur mit Bump-Map:


    Beispiel in 3dmax (ist etwas unscharf bzw. klein, weil es ein kleiner Aussschnitt eines größeren Bildes ist (wenn ich das Projekt noch wiederfinde könnte ich es noch mal größer rendern, vll. reicht es aber schon)). Bump-Map ist ganz simpel, weiß mit schwarzen Strichen für die vertieften Rillen.



    ... dann muß ich die UVs neu machen und die Texturen zusammenschneiden.

    Du kannst für die Schrift(en) auch "Tafeln" machen, also ein neues, eigenes Objekt, ein Polygon (oder zwei, wenn's sein muss) pro "Tafel", und diese dann über der/den Stelle(n) platzieren, wo die Schrift(en) hin soll(en). Das exportierst du dann als ein weiteres Objekt in dein Nos-Projekt. Die vorherigen Texturen kannst du dann so weiterverwenden, ohne neues UV-Mapping. Jedoch würde auch ich vorschlagen, sie zu verkleinern. Wenn du sie proportional verkleinerst, also das Seitenverhältnis sich nicht ändert (also von 4096 * 4096 auf 2048 * 2048 z.B.), passen auch die UV-Koordinaten weiterhin.

    In dieses Thema haben sich schon einige regelrecht verbissen, bis jetzt immer mit sehr bescheidenem Erfolg. Wir sollten es einfach akzeptieren, dass EEP Bumpmapping nur in geringem Maße umsetzt, und Normal-Maps überhaupt nicht funktionieren. Das kann sich erst ändern, wenn Änderungen an der Grafik-Engine vorgenommen werden. Da hilft kein Rumgefummel, kein "es muss doch gehen, in Blender geht es doch auch", und auch keine geheimen Einstellungen.


    Spart euch die Zeit und die Energie, und investiert sie lieber ins Konstruieren von neuen Modellen.

    Das Beispiel ist noch zu einfach, um einen Vor- oder Nachteil erkennen zu können. Der Aufwand ist noch ungefähr derselbe, also ob ich es mir so zusammenklicke, oder den selbst Code eingebe. Zur Übersichtlichkeit lässt sich auch noch nicht viel sagen. Bei der grafischen Variante stellen sich aber Fragen: Was haben die Reiter zu tun? Was ist wenn, ich auf den Nachunten-Aufklappen-Pfeil drücken, was kommt da alles, usw.?


    Die Logik erklärt sich auch nicht besser bzw. genausowenig aus sich selbst heraus. Warum braucht man da eine Variable?

    Oder anders gesagt, die Möglichkeit überflüssige, oder gar unsinnige Codezeilen zu produzieren, wird dadurch auch nicht ausgeschaltet.

    Anscheinend ist dem "Reitenden-Boten" auf dem Weg nach Polen der Gaul verreckt.

    Es ist zwar hier nicht der Thread dafür, aber es passt so schön: Ich empfehle "Eine kaiserliche Botschaft" von Kafka zur Lektüre.


    --------------------


    Es handelt sich bei einem Bugtracker, wie der Name schon andeutet, um eine Sammlung an Fehlern, die aufgefunden wurden. Um mehr nicht! Du hast einen Fehler gefunden, du hast ihn gemeldet, und du hast Rückmeldung erhalten, dass deine Fehlermeldung angekommen und an die richtige Stelle weitergeleitet wurde. Damit hat der Bugtracker seine Funktion einwandfrei und erschöpfend zur Ausführung gebracht, und seine Arbeit ist damit getan. Alles ist gut, alles hat genauso geklappt, wie es sollte.


    Eine Fehlermeldung an den Bugtracker weiterzugeben, ist nicht etwa mit einer Pizzabestellung zu verwechseln. Man erwirbt da keinerlei Anrecht, eine Lieferung erwarten zu dürfen.

    Achso, an Cloud habe ich nicht gedacht (da mache ich persönlich noch einen Bogen drum). Das könnte sein, dass das keine/kaum Arbeit macht.


    ------------------


    Ich leide auch ein wenig an Perfektionismus. Ich verstehe das alles vollkommen, und weiß auch, dass das nichts mit Zug zum Weltruhm zu tun hat. Aber man neigt dazu, sich mehr Arbeit zu machen, als man müsste, oder sich mit Sachen länger als nötig aufzuhalten.


    Aber, du scheinst das im Griff zu haben. Ich bin's beruhigt. :aa_1: