29.06.2014, 23:40
Umgekehrt 
Meshes sind Primitve. bzw bestehen aus dem Kleinsten von ihnen, dem Dreieck. Aber die SL Prims, sind im Grunde scheinbar immer schon Meshes gewesen. Daher wohl auch die vielen Flächen beim Würfel 108, statt 12 (6 Seiten x 2 Dreiecke) die, eigentlich nur nötig wären.
Der Unterschied zwischen Viewer und Browser liegt im Ressourcenverbrauch und in der Geschwindigkeit. Unabhängig von allen getürkten Benchmarktests kann man sagen je näher der Code am Prozessor ist, desto schneller ist er und desto weniger Ressourcen verbraucht er. So ein Java Plugin besteht aus Code, der nicht direkt an den Kernel geht, also kein nativer Maschinencode ist. Das ist der Preis der Plattformunabhängigkeit. Er muss von so einem solchen nativen Maschinencode Programm gelesen und umgewandelt werden. Der Viewer hingegen besteht wahrscheinlich (hab noch nicht reingesehen) aus c++ : Das ist schon recht hurtiger, nativer Code. Allerdings hat diese Sprache sehr viele Abstraktionsschichten(ist sinnvoll, wenn mehrere Leute an einem Programm schreiben), welche auch einige Leistung fressen.Daher werden wohl zeitkritische Funktionen im älteren Bruder, dem funktionalen c geschrieben sein und wo es ganz ans Eingemachte geht, ggf sogar in Assembler. Damit ist man praktisch schon auf der Platine vom Rechner Kurz, der Viewer ist bedeutend schneller und im Verbrauch sparsamer. Mit HTML5 hat man nun ein paar Funktionen u. Optimierungen eingebaut, damit es überhaupt Sinn macht 3D Daten über Browser zu verarbeiten. Aber dennoch, ein nativer Viewer ist immer deutlich spürbar schneller und sparsamer. .
Meshes sind Primitve. bzw bestehen aus dem Kleinsten von ihnen, dem Dreieck. Aber die SL Prims, sind im Grunde scheinbar immer schon Meshes gewesen. Daher wohl auch die vielen Flächen beim Würfel 108, statt 12 (6 Seiten x 2 Dreiecke) die, eigentlich nur nötig wären. Der Unterschied zwischen Viewer und Browser liegt im Ressourcenverbrauch und in der Geschwindigkeit. Unabhängig von allen getürkten Benchmarktests kann man sagen je näher der Code am Prozessor ist, desto schneller ist er und desto weniger Ressourcen verbraucht er. So ein Java Plugin besteht aus Code, der nicht direkt an den Kernel geht, also kein nativer Maschinencode ist. Das ist der Preis der Plattformunabhängigkeit. Er muss von so einem solchen nativen Maschinencode Programm gelesen und umgewandelt werden. Der Viewer hingegen besteht wahrscheinlich (hab noch nicht reingesehen) aus c++ : Das ist schon recht hurtiger, nativer Code. Allerdings hat diese Sprache sehr viele Abstraktionsschichten(ist sinnvoll, wenn mehrere Leute an einem Programm schreiben), welche auch einige Leistung fressen.Daher werden wohl zeitkritische Funktionen im älteren Bruder, dem funktionalen c geschrieben sein und wo es ganz ans Eingemachte geht, ggf sogar in Assembler. Damit ist man praktisch schon auf der Platine vom Rechner
Kurz, der Viewer ist bedeutend schneller und im Verbrauch sparsamer. Mit HTML5 hat man nun ein paar Funktionen u. Optimierungen eingebaut, damit es überhaupt Sinn macht 3D Daten über Browser zu verarbeiten. Aber dennoch, ein nativer Viewer ist immer deutlich spürbar schneller und sparsamer. .