| Time |
Nick |
Message |
| 00:16 |
|
proller joined #minetest-dev |
| 01:11 |
|
proller joined #minetest-dev |
| 01:17 |
|
diceLibrarian joined #minetest-dev |
| 02:08 |
|
diceLibrarian joined #minetest-dev |
| 02:29 |
MTDiscord |
<exe_virus> I'm interested, what stage and where is the work ongoing? |
| 02:30 |
|
Evergreen joined #minetest-dev |
| 02:30 |
MTDiscord |
<exe_virus> 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 |
<exe_virus> 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. |
| 02:54 |
|
GreenXenith joined #minetest-dev |
| 03:49 |
MTDiscord |
<GreenXenith> @ExeVirus that sounds bogus; gltf is a transmission format, eg. literally designed to be interopable |
| 03:49 |
MTDiscord |
<GreenXenith> you also cant "compress" model data like you would a video or sound. so that comparison doesnt really work anyway |
| 04:38 |
|
cranezhou joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:25 |
|
rubenwardy joined #minetest-dev |
| 05:45 |
|
calcul0n_ joined #minetest-dev |
| 06:01 |
|
k327[m] joined #minetest-dev |
| 06:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:22 |
|
HuguesRoss joined #minetest-dev |
| 06:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:22 |
|
Goobax[m]1 joined #minetest-dev |
| 06:23 |
|
ROllerozxa joined #minetest-dev |
| 06:27 |
|
_Zaizen_[m]1 joined #minetest-dev |
| 06:27 |
|
lebruhgamer[m] joined #minetest-dev |
| 06:28 |
|
Goobax[m] joined #minetest-dev |
| 06:40 |
MTDiscord |
<GreenXenith> 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. |
| 08:57 |
|
Fixer joined #minetest-dev |
| 08:57 |
|
appguru joined #minetest-dev |
| 09:16 |
|
Fixer_ joined #minetest-dev |
| 09:17 |
|
appguru joined #minetest-dev |
| 09:18 |
|
appguru joined #minetest-dev |
| 10:40 |
|
appguru joined #minetest-dev |
| 11:08 |
MTDiscord |
<exe_virus> 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 |
| 11:52 |
|
appguru joined #minetest-dev |
| 13:03 |
|
proller joined #minetest-dev |
| 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 |
|
proller joined #minetest-dev |
| 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 |
| 14:06 |
|
Desour joined #minetest-dev |
| 14:10 |
|
fluxionary_ joined #minetest-dev |
| 14:57 |
|
appguru joined #minetest-dev |
| 16:12 |
|
kilbith joined #minetest-dev |
| 16:29 |
|
appguru joined #minetest-dev |
| 19:08 |
|
calcul0n joined #minetest-dev |
| 21:28 |
|
pgimeno joined #minetest-dev |
| 21:55 |
|
TheCoffeMaker joined #minetest-dev |
| 22:46 |
|
GreenXenith joined #minetest-dev |
| 23:35 |
|
panwolfram joined #minetest-dev |
| 23:51 |
|
proller joined #minetest-dev |
