Time Nick Message 02:29 MTDiscord I'm interested, what stage and where is the work ongoing? 02:30 MTDiscord I know that gltf is apparently lossy or something cause people online used to say it was only for rendering, and not storing the model data. I.e. you don't want to reimport one into blender cause it'll be much worse 02:31 MTDiscord Sounds like .blend is to .midi as .gtlf is to .mp3 then 02:37 schwarzwald[m] exe_virus: By the end of tomorrow (Saturday) I expect to be able to load a non-animated mesh with a single texture. 03:49 MTDiscord @ExeVirus that sounds bogus; gltf is a transmission format, eg. literally designed to be interopable 03:49 MTDiscord you also cant "compress" model data like you would a video or sound. so that comparison doesnt really work anyway 06:40 MTDiscord followup to what I said eariler: GLTF is not only for rendering, but it is in fact optimized for it. Its meant to be as close to the final rendering format (what opengl expects) as possible. It is still a regular model format, though 08:36 pgimeno as for the 24 vertices, it may be that shared vertices form a visually uniform surface (e.g. for organic shapes), and you only get sharp cuts (as in geometric shapes like a cube) if you have the faces belong to different vertices. I've seen that happen in other contexts. 11:08 MTDiscord Well, you can compress model data, that's what draco is. And I believe gltf will have draco support at some point, yes. But more to what I was talking about: gltf, iirc, only supports certain types of animations, so more sophisticated animations get simplified on export, and vertecies get broken apart, as the discussion earlier showed. I.e. on import, you have to rejoin vertices, and perhaps recreate some animations. Besides that, 11:08 MTDiscord yeah it's not a bad interchange format, and far better than our .b3d hell 13:13 sfan5 schwarzwald[m]: not to discourage you from restoring some unit tests but irrlicht will eventually be assimilated into minetest so restoring a bunch makes more sense at that point IMO 13:14 sfan5 the only reason I was writing tests for irrString now is that I plan to replace the internal implementation and want to avoid regressions 13:14 sfan5 we're hopefully getting rid of it entirely in the long run 13:25 schwarzwald[m] This isn't a restoration. I'm test driving the glTF loader. 13:25 sfan5 saying this because I saw you closed your PR 13:25 schwarzwald[m] I started in Catch2 looking ahead to when we merge it into Minetest; Minetest already has Catch2 in the build. 13:26 schwarzwald[m] Ahh, that. It can always be reopened later. I closed it because a lot of what it tested had been removed. 13:27 sfan5 wasn't catch2 for benchmarks or does it also do tests? 13:27 schwarzwald[m] We use it in Minetest only for benchmarking, but it is a unit testing framework. 13:28 sfan5 I see 13:28 schwarzwald[m] TEST_CASE("invalid JSON returns nullptr") { 13:28 schwarzwald[m] ScopedMesh sm("source/Irrlicht/tests/assets/json_missing_brace.gltf"); 13:28 schwarzwald[m] CHECK(sm.getMesh() == nullptr); 13:28 schwarzwald[m] } 13:28 schwarzwald[m] it looks like so. Not sure how well that goes over the relay. 13:35 schwarzwald[m] I worked hard last night and early this morning, so I'm closer than I thought I would be to loading simple meshes. I think all I have left is to fill in a couple more tests just in case. 13:37 schwarzwald[m] Do you know whether there's a way to temporarily disable Irrlicht's logger? 13:41 schwarzwald[m] Or even disable it entirely in the test executable? The logging is distracting from the test output. 13:53 Zughy[m] I guess this can be closed, Hecks is gone https://github.com/minetest/irrlicht/pull/53