ZFX + Developia

Verfasst: **23.03.2017, 09:50**

Hallo zusammen,

nachdem wieder weit mehr als 750 Commits seit dem letzten Release auf Github eingegangen sind, plane ich mal wieder ein neues Release. Da es diesmal voraussichtlich einige API-Änderungen geben wird, lautet die geplante Versionsnummer 4.0.0.
Dazu sind etliche neue Loader hinzugekommen, ich habe an der Testschraube etwas gedreht, Obj kann nun auch größere Files lesen und und und. Besonders freut mich, dass Assimp nun auch einige freie 3D-Druck-Formate wie zum Beispiel 3MF unterstützt.

Einen genauen Zeitplan habe ich zur Zeit noch nicht ausarbeiten können, dafür rauben Job und Familie gerade zu viel Zeit :).

Und ich werde auf der diesjährigen Quo-Vadis Assimp noch einmal vorstellen. Mehr dazu später.

Gruß,
Kimmi

Verfasst: **23.03.2017, 22:31**

Jetzt habe ich einen Thread, den ich mit Bug Reports vollspammen kann ;)

Blender-Import verliert zwei Polygone: Lad bitte das Paket von http://www.thingiverse.com/thing:1675808/#files herunter. Darin liegen eine .blend und eine .stl. Die .stl ist durch Blender 2.72 tesseliert und tadellos (so sollte es aussehen). Importiert man jedoch die .blend, fehlen zwei Polygone (hier rot markiert; auf der Rückseite das selbe nochmal):

Assimp meldet Failed to triangulate polygon (no ear found). Probably not a simple polygon?. Vom Augenschein her sollte das Polygon via Ear Clipping aber problemlos zu bewältigen sein.

Verfasst: **24.03.2017, 11:00**

Moin,

vielen Dank für die Reports, Spam mich ruhig zu. Ich schau mir das Problem mal an. Allerdings bin ich gerade bei der Kleinigkeit von 221 offenen Issues und saufe etwas ab ( vorsichtig formuliert ).

Kimmi

Verfasst: **27.03.2017, 20:29**

Hoert sich so an als sei das einfach ein Bug im Triangulator. Der benutzt Ear Clipping, aber die Implementierung ist ziemlich dirty.

Verfasst: **28.03.2017, 11:31**

Habe ich gesehen ...

Der Termin für den Assimp-Vortrag bei der QuoVadis-2017 steht fest: 25.4. 15:00 :).

Kimmi

Verfasst: **29.03.2017, 23:25**

Error, TXXXXX: Collada: $$$___magic___$$$..dae - Unexpected sub element <ph> in tag <polygons>

Der Fehler tritt in einigen Collada-Dateien auf, die von SketchUp exportiert wurden. Andere Programme können sie problemlos lesen (inklusive Visual Studio). Ich darf das komplette Beispiel nicht anhängen, aber im Auszug sieht’s so aus:

Code: Alles auswählen

<polygons count="54" material="activeMaterial">
<input offset="0" semantic="VERTEX" source="#mesh-1-vertices"/>
<ph>
<p>0 1 2 3</p>
<h>4 5 6 7</h>
<h>8 9 10 11</h>
<h>12 13 14 15</h>
<h>16 17 18 19</h>
<h>20 21 22 23</h>
<h>24 25 26 27</h>
<h>28 29 30 31</h>
<h>32 33 34 35</h>
<h>36 37 38 39</h>
<h>40 41 42 43</h>
<h>44 45 46 47</h>
<h>48 49 50 51</h>
</ph>
<p>52 53 54 55</p>
<p>56 57 58 59</p>
<p>60 61 62 63</p>
<p>64 65 66 67</p>
<p>68 69 70 71</p>
<p>72 73 74 75</p>
<p>76 77 78 79</p>
<p>80 81 82 83</p>
<p>84 85 86 87</p>
<p>88 89 90 91</p>
<p>92 93 94 95</p>
<p>96 97 98 99</p>
<p>100 101 102 103</p>
<p>104 105 106 107</p>
<p>108 109 110 111</p>
<p>112 113 114 115</p>
<p>116 117 118 119</p>
<p>120 121 122 123</p>
<p>124 125 126 127</p>
<p>128 129 130 131</p>
<p>132 133 134 135</p>
<p>136 137 138 139</p>
<p>140 141 142 143</p>
<p>144 145 146 147</p>
<p>148 149 150 151</p>
<p>152 153 154 155</p>
<p>156 157 158 159</p>
<p>160 161 162 163</p>
<p>164 165 166 167</p>
<p>168 169 170 171</p>
<p>172 173 174 175</p>
<p>176 177 178 179</p>
<p>180 181 182 183</p>
<p>184 185 186 187</p>
<p>188 189 190 191</p>
<p>192 193 194 195</p>
<p>196 197 198 199</p>
<ph>
<p>200 201 202 203</p>
<h>204 205 206 207</h>
<h>208 209 210 211</h>
<h>212 213 214 215</h>
<h>216 217 218 219</h>
<h>220 221 222 223</h>
<h>224 225 226 227</h>
<h>228 229 230 231</h>
<h>232 233 234 235</h>
<h>236 237 238 239</h>
<h>240 241 242 243</h>
<h>244 245 246 247</h>
<h>248 249 250 251</h>
</ph>
<p>252 253 254 255</p>
<p>256 257 258 259</p>
<p>260 261 262 263</p>
<p>264 265 266 267</p>
<p>268 269 270 271</p>
<p>272 273 274 275</p>
<p>276 277 278 279</p>
<p>280 281 282 283</p>
<p>284 285 286 287</p>
<p>288 289 290 291</p>
<p>292 293 294 295</p>
<p>296 297 298 299</p>
<p>300 301 302 303</p>
<p>304 305 306 307</p>
<p>308 309 310 311</p>
</polygons>

Ich hätte erwartet, dass XML so entworfen wurde, dass man unbekannte Daten überspringen kann, statt den Import komplett abzubrechen.

Siderant®: Eine 5 MiB große XML legt Chrome für 10 Sekunden lahm, und Notepad++ für über zehn Minuten. WHAT THE FUCK – ein Kunde will DAE oder OBJ als Schnittstelle, und jetzt nehme ich OBJ einfach weil’s meinen Rechner nicht schon in der Textansicht einfriert.

Verfasst: **30.03.2017, 00:05**

@Siderant: Öffne das ganze mal mit Programmers Notepad, das kommt mit sehr großen Dateien hervorragend klar im Gegensatz zu Notepad++

Verfasst: **30.03.2017, 00:56**

Danke, aber 5 MiB sind *nicht* groß. Notepad++ kann auch 100 MiB Text problemlos verarbeiten … aber scheinbar nur, so lange es kein XML ist :(

Verfasst: **30.03.2017, 13:00**

Der Komplettabbruch des Imports ist zur Zeit ein ziemlicher Hemmschuh. Dem kann ich nur zustimmen!

Kimmi

Verfasst: **30.03.2017, 13:11**

Ich denke, ich werde das mal ändern.

Verfasst: **04.04.2017, 23:39**

Krishty hat geschrieben:Danke, aber 5 MiB sind *nicht* groß. Notepad++ kann auch 100 MiB Text problemlos verarbeiten … aber scheinbar nur, so lange es kein XML ist :(

Meiner Erfahrung nach kann Notepad++ auch mehr als 100MiB große XML Dateien relativ zügig öffnen, jedoch kommet es wahrscheinlich stark auf die Tag-Längen an, sowie ob, und welche Lineendings verwendet werden.

Ich benutze für XML files aber lieber den "XML Notepad 2007" von Microsoft https://www.microsoft.com/en-us/downloa ... px?id=7973. Mit dem konnte ich schon so manche XML Datei laden, bei der in Notepad++ nix mehr ging.

Verfasst: **19.04.2017, 00:40**

Ich hatte gehofft, dieser Commit würde die OBJ-Probleme lösen, aber … er ist eine Katastrophe.
Bild

Da wird ein temporärer Puffer von ungefähr Dateigröße angelegt, MIT JEDER ZEILE, DIE GEPARST WIRD. Ich habe eine OBJ mit 100.000 Zeilen hier (nichts Ungewöhnliches, oder?). Assimp liest Chunks von 16 MiB auf einmal. Der aktuelle Chunk wird beim Parsen jeder Zeile kopiert. Macht 1,5 TiB temporäre Kopien. Auf die Speicherbandbreite meiner CPU umgerechnet macht sie drei Minuten nichts anderes als Speicher zu nullen – aber so weit komme ich garnicht, weil mein Arena-Allocator (der den PLY-Import 15× so schnell gemacht hat, wisstschon) bei 16 GiB mit out-of-memory kracht und das System da längst fünf Minuten thrasht …

[/rant] So wie ich das sehe, kann man da in-place arbeiten statt einen neuen Puffer anzulegen. Aber kA, wie das in euer Stream-Konzept passt.

Meine Problemdateien laden jetzt weiter, aber eine Normale ist out-of-Range (Index ist 1 zu groß) und das löst am Ende natürlich nochmal eine DeadlyImportError-Ausnahme aus, und dann war alles umsonst.

Verfasst: **19.04.2017, 07:24**

Ich guck mir das mal an. Es gibt leider einige Loader, die etwas suboptimal programmiert sind.

Verfasst: **02.05.2017, 16:28**

Wurde glücklicherweise schon bemerkt: https://github.com/assimp/assimp/issues/1237

Ich zweifle ehrlich gesagt daran, dass der original-Autor in der Lage ist, seine Lösung wasserdicht zu kriegen.

Verfasst: **03.05.2017, 13:54**

Ich werde das Ganze mal wasserdicht machen. Ich hab ein der Tat bei der Codelesung geschlafen.

Verfasst: **04.05.2017, 22:57**

Die Version von vor drei Stunden stürzt bei mir ab – in std::copy(tempBuf.cbegin(), tempBuf.cend(), ++curPosition); mit vector + offset out of range

Warum benutzt ihr überhaupt IOStreamBuffer<T>::getNextLine(), wenn das Newline-Zeichen in OBJ keinen logischen Zeilenumbruch bedeutet? Wäre das nicht die Stelle, an der man backslash + line break filtert, statt hinterher auf Backslash zu prüfen und die Zeilen dann wieder zusammenzukleistern? Wäre doch sicher auch mindestens eine Größenordnung schneller …

Verfasst: **05.05.2017, 00:39**

Beim Schreiben von getNextLine war mir dieser Zusammenhang nicht bekannt, da die bisherigen Files anders strukturiert waren. Da ist definitiv Luft nach oben. Wenn mir der Alltag mal wieder etwas Luft lässt, werde ich hier nachbessern. Wenn jemand anders gerade nicht jede Nacht zu früh einschläft; ich würde mich über etwas Hilfe freuen :)...

Gruß Kimmi

Verfasst: **10.05.2017, 17:25**

SpatialSort: use std::vector::resize( 0 ) to improve readability. commit 186629b37282d880ad059516c7a3673844b74ac9 Kim Kulling committed 2 days ago

Code: Alles auswählen

     // clear the array in this strange fashion because a simple clear() would also deallocate
     // the array which we want to avoid
-    poResults.erase( poResults.begin(), poResults.end());
+    poResults.resize( 0 );

resize(0) ist identisch mit clear() und der Kommentar ist zweifelhalft. Siehe hier, hier, und hier.

Verfasst: **10.05.2017, 20:23**

Ich sehe auch, dass ihr mit Master gemerged habt – enthält Master jetzt den defekten OBJ-Importer?

Verfasst: **11.05.2017, 16:18**

Clear und resize sind nicht gleich, clear released die Capacity, resize nicht, siehe : http://en.cppreference.com/w/cpp/contai ... tor/resize:

Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, rather than only the ones that would be invalidated by the equivalent sequence of pop_back() calls.

Den Effect kann man auch im Profiler beobachten: resize( 0 ) setzt die Size zwar auf 0, die Capacity allerdings nicht. Wenn nun jemand erneut Items pusht, wird kein erneuten Allocate durchgeführt, clear ist da langsamer.

Aber Obacht: das gilt nur für std::vector.

Gruß Kim

Verfasst: **11.05.2017, 16:18**

Der Obj-Importer-Bug ist bereits behoben.

Kim

Verfasst: **11.05.2017, 18:04**

kimmi hat geschrieben:Clear und resize sind nicht gleich, clear released die Capacity, resize nicht, siehe : http://en.cppreference.com/w/cpp/contai ... tor/resize:
Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, rather than only the ones that would be invalidated by the equivalent sequence of pop_back() calls.

Doch, http://en.cppreference.com/w/cpp/contai ... ote]Leaves the capacity() of the vector unchanged[/quote]Mit welcher STL hast du es gemessen?

[IMHO, wenn man es lesbar haben will:

clearAndKeepCapacity(poResults);

und

clearAndDeallocate(poResults);

mit

template <typename T> void clearAndKeepCapacity(std::vector<T> & v) {
v.clear(); // oder erase(begin(), end()) oder wasauchimmer
}

template <typename T> void clearAndDeallocate(std::vector<T> & v) {
std::vector<T>().swap(v);
}

Wenn schon leserlich machen, dann richtig ;) ]

@OBJ: Stimmt; der Crash ist raus :) Die Geschwindigkeit ist aber nichtsdestotrotz eine Katastrophe – wenn ich in Notepad++ alle Backslash+Newline aus meiner Testdatei lösche (15 Sekunden Arbeit), lädt die OBJ in drei Sekunden. Wenn ich sie drinlasse … muss ich den Test nach zwei Stunden mit 100 % Kern-Auslastung abbrechen weil ich nicht weiß, ob es je fertig geworden wäre oder in einer Endlosschleife hängt. Da war der Crash fast besser.

Verfasst: **11.05.2017, 18:57**

Ops, das war mal anders. Gut zu wissen, das mit dem clear(), danke :). Ich hatte mich schon ewig gewundert, warum clear das früher ( so vor 10 Jahren ) im VS anders gemacht hat. Die Messungen habe ich damals durchgeführt und bis heute nicht wiederholt.
Welches Obj-Modell benutzt du? Ich habe da gerade kein ungünstiges Modell bei der Hand, um das nachzuvollziehen. In der Tat habe ich den Fix in Eile mit dem Dragon gegen gecheckt und da sind die Linebreaks nicht drinne, Schande über mich.

Verfasst: **11.05.2017, 21:31**

X3D behandelt Kommas endlich als Whitespace, schön :)

Für die verbleibenden Probleme habe ich dir nochmal Testfälle geschickt.

Verfasst: **12.05.2017, 09:24**

Danke für das Feedback, ganze Menge ...

Gruß Kim

Verfasst: **15.05.2017, 22:29**

Mir ist gerade beim Testen noch eine desaströse Nebenwirkung des OBJ-Problems aufgefallen.

Nämlich scheint OBJ der Standard-Importer zu sein, falls ihr ein Format nicht erkennt und es Text-only ist. Von da an passiert der GAU:

textbasiertes Format; kein Importer passt … Found a matching importer: Wavefront OBJ
natürlich springt er mit den unbekannten Daten in ignoreNewLines()
natürlich bleibt er dann in der Schleife hängen, die stundenlang Assimp damit deadlocked, in einen std::vector zu kopieren

Kurz: Früher hat jedes unbekannte Datei zu einem abgebrochen Import geführt, wie es sein soll. Jetzt führen die meisten unbekannten Dateien zum Deadlock im OBJ-Backslash-Removal.

Verfasst: **16.05.2017, 09:24**

WTF! Ich mach mich heute abend drann, ich hab ja sturmfrei!

Kimmi

Verfasst: **18.05.2017, 08:22**

So, und STL's > 500 MB wollen auch nicht: https://github.com/assimp/assimp/issues/1277

Verfasst: **01.06.2017, 11:16**

Aber immerhin: overflow und obj mit Linebreaks sind nun schon mal gefixed.

Verfasst: **01.06.2017, 14:39**

Absolut; meine Backslash-Datei lädt jetzt wieder in einer Sekunde statt in 8+ Stunden :)

ZFX + Developia

Assimp-News

Assimp-News

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant

Re: Neuer Assimp-Release geplant