Closed finnbear closed 3 years ago
This proposal also makes sense, one does need to have a lot of glTF knowledge to decode common attributes, such as position and colours.
Yet this high level reader should maintain the glTF data model, it will just help decoding the binary buffers into higher level entities by using gltf/binary
, therefore it will still require some glTF knowledge.
@finnbear I´ve added a new modeler.Read* api in v0.17.0. It does not work with meshes but with accessors, as I wanted to start from the bottom (bufferviews and accessors) and leave the higher level models (primitives and meshes) for the end. I´ll continue the work when I find enough inspiration.
Take a look at this new release, maybe it does meet your needs already.
Take a look at this new release, maybe it does meet your needs already.
Thank you very much! I'll download the latest changes and try implementing my project again. I think I'll be able to say soon whether it meets my needs.
Alright, I was able to implement basic reading of positions from my GLTF file:
package main
import (
"fmt"
"github.com/qmuntal/gltf"
"github.com/qmuntal/gltf/modeler"
"log"
)
var (
objectPath = "../../objects/molding.glb"
)
func main() {
doc, err := gltf.Open(objectPath)
if err != nil {
log.Fatal(err)
}
mesh := doc.Meshes[0]
primitive := mesh.Primitives[0]
positionIndex := primitive.Attributes["POSITION"]
positionAccessor := doc.Accessors[positionIndex]
positions, err := modeler.ReadPosition(doc, positionAccessor, nil)
if err != nil {
log.Fatal(err)
}
fmt.Printf("%#v", positions)
}
I think this meets my basic needs, but I do have some suggestions:
modeler.Read*(...)
take the document and the index of the accessor, not the document and the accessor. It seems like the client has to dereference the accessor unecessarily (in my case, the positionAccessor := doc.Accessors[positionIndex]
line).const
strings POSITION
, NORMAL
, etc. from your library, as they get used a lot to refer to attributes (including in your code, especially the test code).image
package, which specific formats can register importers into). I think the thing the realistic next step is to remove the need to think about accessors and skip directly from primitives to positions, normals, etc. (but please take your time to make a well designed API)Thank you @qmuntal!
Edit: feel free to close this issue
@finnbear thanks for the review and sorry for the late response, for whatever reason I did not see the notification.
Some comments about your suggestions:
Sorry to reopen this thread as I was looking to ask a question more than raise an “issue”.
1.) Will this package allow me to read and load my .glb file from Go into my THREE.js scene?
2.) Would I need to create my own accessor function to bridge Go to my JavaScript?
3.) Would using your library essentially remove the .glb from public storage and network traffic since it’s loaded with Go at runtime?
Sorry again if these are misinformed questions 😅 I’m new to Go and have been trying to find a way of encapsulating my .glb files to avoid:
I was initially inspired by SketchFab, which uses a proprietary .binz format that I can only assume uses some sort of decryption logic in a custom JavaScript loader.
The closest I saw to what I wanted was this Doom 3 in-browser port that uses JavaScript with WASM. The 3d assets weren’t publicly stored nor transferred network traffic (Link).
I’d love to hear your thoughts! Thank you 🙏
This is similar to #15 except that that was regarding a way to create a GLTF document whereas I would like a way to read GTLF document without any knowledge of GLTF.
The ideal API for me would take a document, a mesh index, and return vertices, normals, uvs, material indices, etc.
You could call the package
scanner
,reader
,inspector
, etc.