Für diejenigen von euch, die grad etwas Zeit über haben, hätte ich einige Tests, die für die Kompatibilität von Mcad 2.0 wichtig wären.

Genaugenommen machen meines Wissens nur ATI Rage PRO Karten Probleme (auch mit diesen funktioniert Mcad - bringt aber in mehr oder weniger regelmäßigen Zeitabständen Fehlermeldungen), ich möchte aber gern sicher stellen, dass es wirklich nicht Mcad ist, das da ein Problem hat.
Wenn möglich testet also Mcad nicht nur auf Rechnern mit den neuesten GeForce / Radeon Karten, sondern evtl. auch auf älteren Maschinen.

Bitte versucht folgende unabhängige Aufgaben (oder auch nur eine davon) nachzuvollziehen (stellt vorher die Sprache unter "Language" auf Deutsch um) und postet dann die Ergebnisse. Wenn euch sonst irgend etwas auffällt, wäre ich natürlich auch froh, dies zu erfahren :

Aufgabe 1.
- erstellt zwei Kugeln (oder andere Objekte)
- erstellt zwei neue Materiale mit unterschiedlichen Eigenschaften
- Ordnet die Materiale den Objekten zu (Objekt anwählen, dann auf Material klicken)

Aufgabe 2.
Selbiges in grün, aber mit Texturen (2D-Texturen laden, beliebige Bitmaps auswählen)

Aufgabe 3.
- Klickt im Menüpunkt Werkzeuge auf "OpenGL Status" - stehen im oberen Teil des Fensters irgendwelche Fehlermeldungen?
- wenn ja: wählt die DefaultRenderSettings aus, klickt auf das blaue Plus und deaktiviert den gelben Haken neben SeparateColor (einfach draufklicken, beide Knöpfe sollten nun deaktiviert sein). Schaut euch nochmal den "OpenGL Status" an. Ist die Fehlermeldung weg ?
Als "Belohnung" für die Aufgabe drei erhaltet ihr übrigens recht detaillierte Auskünfte über euren OpenGL Treiber

Aufgabe 4.
Klickt im Menüpunkt Werkzeuge auf "alternative OpenGL Bibliotheken", wählt dann aus den Standardbibliotheken den MesaGL Treiber aus und klickt auf OK.
(ihr könnt ein wenig rumspielen, um eine Software OpenGL Implementation zu bewundern). Aktiviert wieder die Windows-Standardbibliotheken.

Aufgabe 5.
Ändert das verwendete Pixelformat unter Werkzeuge > Pixelformat ändern.

Aufgabe 6.
Stellt ein paar Objekte zusammen und speichert das Ganze als Delphisource. Startet dann die entsprechende .dpr unter Delphi.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Hi !
Also erst ma en riesen Lob für dieses Meisterwerk von Editor. Einfach genjal. Also ich hab ne Gf2 Ti und nen Athlon XP 1800+ Betriebssystem Windoof 98. Bei mir is noch kene Fehlermeldung aufgetreten(Ich glaube das ist das erste Programm das das jemals bei mir geschafft hat )
Ich code zurzeit an nem eigenen Spiel, und wollt da fragen ob ich deinen Editor da benutzen darf. Natürlich nenn ich auch mal deinen Namen im Credits Menü.
Mfg
Ich

_________________
Wer Ordnung hält, ist zu faul zum Suchen

Danke für die Rückmeldung - und schön, dass alles funktioniert.

So lange du dein Spiel nicht verkaufst, kannst du Mcad 2.0 ohne weiteres verwenden. Ich zwinge auch garantiert niemanden dazu, mich in den Credits zu erwähnen :huh: - freue mich aber natürlich sehr, wenn dies der Fall ist.

Wenn du unbedingt gierige, kommerzielle Software a'la Bill Gates erstellen willst, solltest du Mcad 2.0 lizensieren (zur Zt. nur per Mail möglich, da noch im Betastadium) - oder aber du verwendest die Vorversion Mcad 1.4, die ist OpenSource und kann exklusiv bei DelphiGL in der Projektesektion heruntergeladen werden (wird von mir aber nicht mehr supported).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Also an kommerzielle Verwendung is zur Zeit noch gar nicht zu denken. In den Credits tu ich dich auf alle Fälle nennen. Weil du mir mit dem Editor ne riesen Arbeit erspart hast(Wenn ichs überhaupt hingekriegt hätte).
Danke !

_________________
Wer Ordnung hält, ist zu faul zum Suchen

Eigentlich wurste ich lieber direkt im Quellcode rum, weshalb ich MCAD bisher noch kaum genutzt hab. Aber Carad wollt ich mir dann unbedingt mal näher ansehen, denn selbst als erfahrener Programmierer kann man es doch prima als Prototyping-Tool nutzen um z.B. bestimmte Szenen zu testen bevor sie in die Anwendung reinkommen.
Aber bei meinem "Ausflug" in dein Programm gabs direkt ein Problem, denn ich konnte keins von meinen 3DS-Modellen laden, da dies jedesmal mit ner Zugriffsverletzung seitens der atioglxx.dll quitiert wurde. Ich kann also z.B. nicht ein einziges bei SETH mitgeliefertes Modell laden und auch die 3DS-Modelle aus meinem neusten Projekt resultieren in der selben Fehlermeldung. (Datei->Importieren->3D Studio Datei laden)
Treiber ist übrigens der neuste Catalyst-Hotfix, also der Beta 3.10 (zum ersten mal mit ner 1.4 im GL-Versionsstring).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Danke für die Meldung. Also der Fehler ist (bzw. war, inzwischen ist die neue Version mit BugFix online ) nicht die Schuld des OpenGL Treibers.

Der 3DS-Import ist eigentlich ein Relikt, und würde eigentlich schon länger auf der Liste der zu überarbeitenden Dinge stehen - allerdings waren mir immer andere Sachen wichtiger (ein weiterer bekannter Fehler ist, dass die Transformationsmatrizen von zusammengesetzten Körpern nicht korrekt importiert werden - bei Einzelobjekten fällt dies jedoch nicht auf).
Das Problem war, dass die 3DS Importroutine (basierend auf Lischkes 3DS-Loader) nicht für Multitexturing ausgelegt war, und daher auch keinen Platz für Texturkoordinaten reservierte - beim Aufruf derselben gabs dann einen Fehler.
Nachdem die Basiskörper von Carad (bzw. Mcad) schon seit fast einem Jahr Texturkoordinaten getrennt von Schnittpunkten verwalten (um in der Anzahl von Textureinheiten flexibel sein zu können, vor ein paar Wochen kamen auch noch Vertexparameter hinzu - auch wenn die Schnittstelle dazu in Carad noch nicht offengelegt ist), und du der Erste bist, der mir den Fehler meldet, nehme ich an, dass diese Funktion nicht besonders häufig genutzt wurde .

Vielleicht kannst du auch noch mal gegenchecken, ob deine Modelle jetzt funktionieren.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Habs grad getestet, und das Laden der 3DS-Modelle klappt an sich. Aber sobald man ein 3DS-Model in der Szene hat, scheint was mit der Beleuchtung ned mehr zu stimmen, wie folgende Screenshots dokumentieren :

Kommt auf den Screenies zwar ned so gut rüber, aber wenn je nach Blickwinkel verändert sich die komplette Szenenbeleuchtung...also wohl irgendwo ein Attribut im 3DS-Loader verändert.
Ausserdem sieht das 3D-Objekt texturiert auch nicht so aus wie es soll :

Die Textur wird nämlich mit nem grauen Schleier überzogen. Sie sollte eigentlich sattgrün sein.

P.S. : Mike Lischkes 3DS-Loader ist wirklich kein schönes Stück code. Habe ihn in SETH auch um Multitexturing erweitert, mache aber dort eigentlich nix anderes als die Koordinaten von TMU0 auf alle anderen genutzten TMUs zu kopieren. Ich nutze daher in aktuelleren Projekten auch lieber den Loader von Noeaske, der wesentlich übersichtlicher und dadurch leichter zu modifizieren ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Die Beleuchtung ist an sich korrekt - Carad erstellt für 3DS-Dateien keine automatischen Normalvektoren, außerdem sind nur die importierten Materiale daran gebunden - das heißt für die 3DS-Daten sind die DefaultRenderSettings mit aktivierter Beleuchtung aktiv, allerdings ohne gesendete Normalvektoren...

Klicke ein aktives Objekt rechts an, und berechne entweder Flächennormale oder geglättete Normale, dann sollte zumindest die Beleuchtung stimmen.

Carad versucht auch die 3DS-Materiale zu importieren, kann aber sein dass diese nur annähernd passen (mir scheint es auch, dass die zumeist viel zu blaß sind - außerdem ist der Spekulare Beleuchtungsanteil meist sehr hoch, was so wahrscheinlich auch nicht stimmt). Daher auch die seltsame Texturierung - die kommt wegen der Kombination aus Material und Textur zustande.
Vielleicht änderst du mal die Parameter des/der automatisch generierten Material(e), bzw. entfernst sie ganz vom Objekt, wenn du eine Textur daran gebunden hast - dann sollte es "richtiger" aussehen.

Das Ganze ist nicht so ganz stimmig - insbesondere sollte es nicht notwendig sein, eine importierte Szene noch nachzubearbeiten - der 3DS Import ist aber schon eine uralte ad-hoc Lösung, die schon längst überarbeitet gehört - was insofern in der Priorität gestiegen ist .

Ich werde aber in nicht allzuferner Zeit nativen Support für dein SETH Format einbauen, muss zuvor aber noch die Bearbeitung von Vertexparametern offenlegen - das 3DS Format ist mir nicht so sehr sympathisch (viel zu konfus für meinen Geschmack).
Wie schauts eigentlich mit Noeskas 3DS-Loader aus? Importiert der Materiale, Positionen von zusammenhängenden Objekten und Texturkoordinaten korrekt?

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

So, jetzt hat mich der schwächelnde 3DS-Import doch genug gestört, dass ich ihn überarbeitet habe. Bei der Durchsicht des Codes waren dann noch zwei haarsträubende Bugs drinne (und das schon seit langer, langer Zeit ...): Beim Import einer Materialfarbe importierte ich RGG anstat RGB, der Shininessfaktor war viel zu klein, da er im 3DS Format von 0-1, in OpenGL abr von 0-128 skaliert wird - ich ihn aber direkt übernommen habe...

Diese Fehler sind nun behoben, außerdem sollten nun auch zusammengesetzte Objekte richtig positioniert werden - und es werden standardmäßig Flächennormale berechnet (der Geschwindigkeit wegen) - wers braucht, kann in Carad ja selbst geglättete Normale berechnen lassen.

Die neue Version ist bereits online, nochmals danke dass du mich darauf hingewiesen hast.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/