Everything I've found seems to indicate that in order to export a vertex animation a point cache file must also be generated, but that means in addition to the FBX file a whole new folder with that cache data must also be built. Is there no way to store the (vertex) animation data entirely in the FBX file?
That's correct. The FBX stores the mesh/topology, and the point cache stores the offsets of the vertices over time.
The FBX file format stores mesh topology, shapes and skin deformers, but not the actual vertex cache data since it can be of various formats, such as MCX (Maya), PC2 (Max) or ABC (Alembic). Also, for access and performance reasons, it is preferable that the cache data stays in a separate file so that software can read asynchronously from it without having to deal with the complexity of the FBX data model.
Related
I have different meshes with different VBOs, some may have normals, some not, etc. Every mesh also has its VAO with all VBOs being bound.
Then I draw all meshes with instancing. I plan to use a shared global VBO of mat4 to store dynamically calculated transformations every frame. Every VAO also needs to point at this shared VBO additionally. Also the number of every mesh instances may vary.
But I guess we want to reduce the amount of data uploading commands to GPU, that's why I want to accumulate all the matrices in a contiguous memory and send it in a single glBufferSubData command.
Different batches of different instanced meshes want to use different segments of the shared VBO to read the matrices from. So I need to update VAOs each frame as well.
The question is: how should I perform this in a better way? And is such an architecture actually a good one? I guess I should use glBindVertexBuffer for the shared VBO on each VAO, so I update the offset and size of the segments, and VAOs are lightweight, but is it really a standard solution?
You should not be concerned with updating VAOs. In fact, you should not have one VAO per mesh at all; have one VAO per vertex format (aka: the stuff set by glVertexAttribFormat and glEnable/DisableVertexAttrib), and try to make all of your meshes use the same vertex format. Setting buffer binding state is much cheaper than setting vertex format state.
So the idea ought to be that you bind a VAO for a vertex format, then iterate through all of the objects that use that format, using glBindVertexBuffer as needed for their individual data.
I'm working with Vulkan since a few weeks. I have a question about the data structure of a model:
I'm using Assimp for loading fbx and dae files. The loaded model then usually contains several nodes (RootNode and their ChildNodes).
Should I keep this structure on non-rigged models? Or could I transform all the meshes (or rather their vertices) into world space at the first loading by multiplying with the offset matrix of the node (and then delete the node structure in my program)? Because I've never seen that someone transform a node (and their meshes) after loading, if the model isn't rigged.
Or is there any other reason why I should keep this structure?
Assimp also offers the flag aiProcess_PreTransformVertices to flatten the transformation hierarchy. You can also do it manually, of course, by using the aiNode::mTransformation matrices and multiplying them in the right order.
A potential problem with these approaches (especially with the flag) can be that the material properties of sub-meshes can get lost. Assimp doesn't care if sub-meshes have different material properties and just merges them, s.t. the material properties can get lost for a certain sub-mesh. This also applies to other properties like sub-mesh names. If sub-meshes get merged, only one (arbitrarily chosen?) sub-mesh name remains.
I.e. you'll want to prevent flattening the node hierarchy if you would like to use specific properties (names, material properties) of sub-meshes.
If your concern is only w.r.t. transforming them to world space: If you are never going to do something with the nodes in object space (like, e.g., transforming a sub-node in relation to a parent node), then I don't see a reason to not transform them into world space.
I have this stl model that has >3 million vertices and have to render it on screen. Right now, loading the model using a Threejs STL loader crashes the browser. Based on some research, I'm considering doing some of the following:
Stream the STL file to the client and have the STL loader load the model in 1mb chunks
Every time a chunk gets loaded, I can create a buffer geometry and construct a mesh from it. I can do this for every chunk and add all the meshes to the scene. Thus the scene will have multiple meshes in it, but look like it's the original model.
I have a pretty good idea of how to do step 2, but is the first part possible? Can a three.js STL loader load an STL in chunks (assuming it's being delivered to the client in chunks) as I've described?
The Three.js STL loader won't do that for you (it will always load the whole file and then parse).
You'd have to load and parse the file in chunks yourself. It is a pretty straightforward file format (https://en.wikipedia.org/wiki/STL_(file_format) ), you'd have to handle the case where a STL triangle structure spans chunks, however.
Another option, if it makes sense for your application, is to read and preprocess the file into a format that can be read in chunks in the browser.
I wish to construct an animation in Paraview starting from some files obtained in an optimization process. I have a mesh made of tetrahedrons and at each iteration I have a scalar field on this mesh.
I could create a VTK file for each iteration, but such a file is larger than 100Mb and it would take more than 15GB to store all the vtk files. Moreover, the geometry part in each vtk file is the same, so I guess there is a more efficient solution. Therefore my question:
Is it possible to make animations in Paraview by changing a scalar field on a fixed geometry?
(if this is not the right forum to ask this, please let me know where it could be more appropriate)
I have a modifiable terrain which is stored in a vertex buffer. Because of its large number of vertices, I do not want to upload all vertices again every time the terrain is modified. What I do by now is to split the terrain into smaller chunks so that I only have to recreate the buffer of the area containing the modification of the terrain.
But how can I just add or remove some vertices of an existing buffer?
You can either use glBufferSubData as datenwolf said, or if you are planning on making a lot of modifications and accessing randomly the data, you may want to map the buffer into client memory using glMapBuffer and later unmap it with glUnmapBuffer. (Then, based on the access specifiers you chose, you can edit the data as a C array)
You can change data in an existing buffer using glBufferSubData