Support more 3D formats + better t3dm docs
Closed this issue · 5 comments
As a non-blender user, it's painful to get models from my software into blender to use fast64. Sometimes the imports just fail outright, or import incorrectly and require fixing.
I think it'd benefit everyone if we had a converter using assimp and a material definition file.
Also, the t3dm spec could use some clarification in a few places (otherwise I would write this myself). Namely how some values are stored/normalized, how textures are hashed, as well as what are vertex dest offsets, object part matrix index, "MSB", and quantized scale/offsets. Also, is the streaming format .t3ds, or .sdata?
The t3dm file description servers more as internal documentation (or if you're interesting in modifying t3d), it's also tightly coupled to structs at runtime in both C and ucode, and their API.
For that reason it can change at any time, and the .t3dm file should be treated as a build artifact.
I should probably clarify that in the documentation.
If you are in need for a custom format it's best to either modify the existing tools, or write a custom format that uses the C API at runtime like the builtin format does.
Although i recommend sticking to the builtin converter since there is a lot of preparation and optimization needed to generate valid & fast model data.
For materials, having support for regular materials is on my todo-list, although they will be inherently limited due to the hardware of the N64 and the specifics of the ucode.
Meaning there is a small overlap between what the N64 could do, and what other settings more modern materials can have.
That's also the reason fast64 was chosen, since it let's you set those specific settings with an accurate preview in blender.
But i agree that it would be a good thing to finally add this, this should also allow any other tools than blender to work.
(Note that most people tend to use blender for homebrew since it's free and open source, as i do myself, so i won't be able to easily fix any non-blender specific issues in the future)
For assimp and non gltf imports:
I looked briefly into this in the beginning and decided against it for now, the main reasons where that it would introduce another layer of conversion whereas gltf is a standard exchange format.
assimp also introduces a dependency on either Cmake or a library installed on the system, right now everything is self-contained.
I appreciate the quick response.
Thanks for the T3DM explanation. I'm really not keen on straying from what you've already built specifically for performance reasons. I don't think I could do as good of a job.
I'll continue looking for a process that works for me, but having a way of defining materials outside of fast64 would help a lot. As a stopgap, would it be difficult to have some generic defaults that the converter uses and expose the rest in code? I haven't looked into how much work this would be, but that would probably be well enough to solve my issues.
If normal materials are supported they would internally set some sensible defaults.
Setting it at runtime is partially supported right now, but there is a bit of logic involved in settings those.
For a hacky workaround one could add a way to load an external material by name of the material.
The way blender embeds the fast64 specific data in the gltf file is by converting it into a JSON string and putting it into the extra-data.
See: https://github.com/HailToDodongo/tiny3d/blob/main/tools/gltf_importer/src/parser/materialParser.cpp#L141
You could theoretically replace that read with a JSON load from a file.
I'm going to close this issue for now.
In general the direction has been going both towards a deeper integration with fast64 (potentially a new t3d mode there in the futrure), and outright ignoring materials but keep using the mesh data (for a custom material system)
The latter has now a setting you can use in a makefile: $(T3D_GLTF_TO_3D) "$<" $@ --allow-no-fast64 to not error out on missing fast64 data.
So for now i stopped looking into supporting other formats and regular materials.
I've been trying to get this to work with the changes you specified, but I cannot get any glb files that I create to work. Is my understanding correct that any glb file should work as long as we pass the --allow-no-fast64 in the makefile?
I get the following:
Segmentation fault make: *** [Makefile:35: filesystem/bones_n64_verge.t3dm] Error 139