I'd like to take the cross section of an STL mesh and import into Inkscape. I have taken the cross section by doing Filters->Quality Measures and Computation->Compute Planar Section, but I don't see any way to export that as a 2D file. Some forum posts elsewhere imply that this was a built-in feature of MeshLab in 2010, but there's no obvious way to do so in current versions?
You can export the planar section as a dxf file. Inkscape should be able to import this dxf file directly.
Related
I'm having problems understanding the the usage of VS2012's 3D features in a project. I'm current building a 3D project using DirectX (Direct3D) and want display a simple 3D object (teapot) for starters. I understand the usage of the shadergraph which is of great help, but when it comes to loading an FBX model, is there an alternative to using the Autodesk FBX SDK built in or am I just stuck with it (FBXSDK)?
Generally, is there anything in VS2012 for C++ similar in nature to how XNA uses it's content pipeline to simplify loading and working with models?
You will definitely need to manage the translation from the format of your model files to the typical D3D mesh/meshpart arrangement. You can get sometimes find models in the old .x format, which corresponds to a Direct3D model. This page has some good reference for loading .x files and also links to exporters for maya and max.
OTOH If your source data is in fbx, use the fbx sdk; it's just simpler than any alternative way to get fbx data. You'll need some library for importing 3d models and although they're all limited in different ways FBX has the advantage of being supported by the widest variety of DCC apps. There are text and binary versions of the FBX format, so if you're interested in manual debugging you can use the text based version to make it easier to crosscheck your results. This sample discusses using the FBX SDK with DirectX 11 - although it is in the context of vs 2010, there may be issues moving to VS 2012.
If you go with another intermediate format you should look for one supported by the 3d tool you'll be using or the model vendor you are buying from. Collada is the most widely available interchange format, and it's based on XML so you could probably implement your own loader -- however it's also notorious for complexity and inconsistent standards so I'd avoid it unless you have a compelling reason or a big trove f Collada format files.
If your needs are very simple and don't include animation, the OBJ format is widely available and easy to implement on your own -- however it does not support animation.
is there anything in VS2012 for C++ similar in nature to how XNA uses
it's content pipeline
As far as I know, there is no such thing. You will need your own solution, as always in native C++ world =). Probably, you can make use some of the modern rendering engines: Unity, OGRE, Irrlicht, Torque, etc.
when it comes to loading an FBX model, is there an alternative to
using the Autodesk FBX SDK built in or am I just stuck with it
(FBXSDK)
As far as I know, FBX is a closed proprietary format, so you stick with FBX SDK.
Another ways (from gamedev view)
FBX format is a terribly complicated and multifunctional. Typically, you don't need FBX to draw teapot. You don't even need FBX to create a good game.
to just draw teapot you, probably, better take another simple (or not so simple) format, such as .obj, .dae or .3ds. You can load it using 3rd party library, such as assimp (which is just few lines of code) or roll out your own loader (which is not so hard either).
to draw some meaningful interactive "teapots world" you will also need to wrap them into some kind of scene: scenegraph is a common solution.
mid-size game labels typically crate their own format, converter and loader for it:
artists create models in their favorite 3D editor
then they convert it using converter: convert to custom binary .mesh format. This can be done via plugin for 3D editor or in small standalone app
in C++ app, programmers just load .mesh, deserialize to structs and classes and use it.
serious game labels develop their own content pipelines: it can include multiple custom formats (static mesh, animated mesh, etc.), loaders (to load and stream content into app), 3ds max/Maya/Blender plugins, visual scene/level editors (to make artists happy). All content is created and managed by artists, so programmers don't need any integration of content to their IDEs.
Visual studio 2012 actually has it's own model processor now.
You can add different meshes to your project(I think that it natively supports .dae, .fbx, and .obj) and it'll spit out a ".cmo" model that's simple to parse.
The directX Toolkit also has pretty good support for loading the format, so if you're already using the DXTK, then I recommend seeing if the model loader meets your requirements.
I'm writing an application for creating 3D skeletal animations. I'm currently using Blender for modeling/rigging, export, then load and render the model with OGRE. But I'm stuck when it comes to exporting.
I'd like to be able to export the finished animated model/scene to some known file format, so that it can be imported back into Blender for rendering. So what's the best way to get the animated skeleton/armature back into Blender?
I think COLLADA is the way to go when it comes to file formats. I'm unsure about the library. FCOLLADA is dead, I'm not sure how up-to-date it is. The latest version of Assimp had COLLADA export functionality added to it, but unfortunately not for animation yet. There's OpenCOLLADA, which doesn't seem to be well documented, but there's two plug-ins which are probably better examples than any tutorial. Lastly there's COLLADA DOM.
Have you heard about FBX? It is widely used as an exchange format for geometry and animation. It support bones/joints which should fit for your skeletal animation.
Wikipedia: http://en.wikipedia.org/wiki/FBX
Autodesk Page: http://usa.autodesk.com/fbx/
I am taking an OpenGL course and we have the option to create models to use in our assignments with a 3D modeling application, like Maya or Blender.
I am not looking forward to typing in coordinates manually so I was curious what resources I should be looking into for writing OpenGL code and importing models. (Textures are coming later). I am also concerned by the scale I'm importing at but maybe that's silly to worry about at this point.
Thanks for any resource suggestions. OpenGL has so much out there I get overwhelmed sometimes when Googling for what I need.
EDIT:
This is what I ended up using.
http://www.spacesimulator.net/tut4_3dsloader.html
I downloaded the "Windows" version and with a few path changes to the includes, got up and running. It doesn't handle OBJ files but rather 3DS. Cheetah 3D exports to this type as well.
Blender can save files in .obj format, and a simple google search turns up several libraries for loading this into OpenGL. Here is one.
One of the simplest formats that can be used to export meshes is Wavefront OBJ (please search for it on Wikipedia as I'm only allowed to post one link at the moment). It's basically a text file that shouldn't be too hard to parse.
Or actually, if you're allowed to use GLUT, you could try and use its loader (as answered in OpenGL FAQ 24.040)
Don't worry about the object scale at the moment, you can always scale your object later. Just make sure you export it with local coordinates, not global (e.g. [0,0,0] should be the center of the object, not the world you're modelling).
I'd suggest not worrying about the scale of the objects for right now.
Now, the thing you're going to have to do is settle on a format for the 3D file. There are MANY options when exporting from a 3D program like Maya or Blender.
Might I recommend attempting a simple COLLADA importer. Specification information is here:
http://www.khronos.org/files/collada_spec_1_4.pdf
Another spec I've been using lately would also probably be suitable for this is OBJ.
The specification for OBJ is located here:
http://local.wasp.uwa.edu.au/~pbourke/dataformats/obj/
Also, there are several free sample 3D OBJ files located here. This will allow you to see the format of the files and really see how easy they can be to parse.
Keep in mind, OBJ can not support animation, and it is rather inefficient for rendering large scenes.
I'd say that the Obj format is a good balance for readability and functionality if you want to parse it yourself.
http://en.wikipedia.org/wiki/Obj
The easiest way would to be to find a library to do it for you but the possibilities would be limited to your chosen language.
You shouldn't be worrying about scale. OpenGL's matrices can easily rescale vertices.
I'm making a renderer using OpenGL. I have textured models in Blender / Sketchup (I can exchange between the two easily), and I'd like to be able to export those files into my renderer. My initial idea was to simply export the raw faces and render those triangles, but I'd like to easily slice my texture files into texture coordinates as well.
By that, I mean that my model faces get carved into triangles. You can see in this image (reproduced below) that my curve becomes 24 triangles. I would like to know what texture coordinates to use for each triangle.
Would a DAE file be the easiest way to do that? I've been reading the specs for the format and it looks easy enough. I think I could parse the XML and faithfully recreate the models in OpenGL. I'm wondering if there is an easier way (i.e. one that doesn't reinvent the wheel).
If you're comfortable with parsing the .dae-format, sure use it. However, if you're only interested in exporting textured triangle meshes I would consider using the .obj format which is much more simple to parse. From what I can tell both Sketchup and Blender can export this format.
If binary formats don't scare you, I'd suggest writing a Blender & Sketchup plug-in and exporting the geometry pre-baked into packed vertex arrays.
The beautiful thing about this method is that there's no parsing or type conversion in your app. Everything is ready to be sent to the GPU in simple contiguous memory copies. Great for static geometry.
A stripped down blender exporter looks something like this:
#!BPY
import bpy, struct
from Blender import *
self.fh = open("MyFileName", "w")
m = bpy.data.meshes["MyMeshName"]
faces = m.faces
for face in faces:
for (vertex, uv) in zip(face.verts, face.uv):
self.fh.write(struct.pack('<fff', *vertex.co)) # coords
self.fh.write(struct.pack('<fff', *vertex.no)) # normals
self.fh.write(struct.pack('<ff', uv.x, uv.y)) # uvs
self.fh.close()
If you wish to parse .dae files, i would suggest to look into Collada parsers.
.dae is actually the extension for Collada files, the latest effort from the Khronos group (maintainers of OpenGL) to have a single unified file format for 3D data exchange.
As for the existing parsers, here is what I've come across:
collada-dom, the reference implementation. As the name suggests, it is just an abstraction of the XML tree.
FCollada, a nicer abstraction. However, this project has been dead for almost two years, and, from what I've gathered, it is unlikely that we'll see any update in the future.
OpenCollada, a recent new effort. Haven't tried it, but there is an active community behind it.
That being said, if your only goal is loading a simple piece of geometry with vertices, normals and texture coordinates, going with the .obj file format might be a quicker way.
Any decent file format used by modeling programs (such as Blender or Sketchup) will include all information necessary to recreate the geometry you see. This should include the geometry type (e.g. triangle strips, individual triangles, etc), the vertices and normals for the geometry, the material properties used, and also the textures used along with the appropriate texture coordinates. If anything is lacking from a potential file format, choose another one.
If you think that parsing XML is simple, then I hope you're planning on using existing libraries to do this, such as expat, Xerces, or some other language specific implementation.
When considering import/export, first try to find an open source library that can handle the import for you and make the data available to your program in a reasonable format. If that's not available, and you must write your own importer, then try to find a simple ASCII (not XML-based) or binary format that fits your needs. PLY might be suitable. Only as a a last resort, would I recommend trying to implement an importer for an XML-based format.
There's also:
Lib3DS - http://www.lib3ds.org/
LibOBJ (won't let me post link)
You should take a look at:
http://sketchup.google.com/community/developers.html
The sketchup team provides a C++ COM server for free. Using this, you can get access to lots of information about a .skp file.
You should be able to use this COM server to write a .skp importer for your application.
You should try to get the .tlb file if you can. This will give you access to smart pointers, which will simplify your importer (COM client)
I used the version 6 SDK (which included the tlb file). The current version of the SDK does not appear to include this file.
Someone posted a solution (for the missing tlb file) on the developer forums:
http://groups.google.com/group/su-sdk-fileshare/topics
I am trying to assemble a scene in opengl, using already made objects. The problem is that the object are in .max format and have no external textures. How could I import my objects in opengl, without retexturing them. I am thinking about exporting them to 3ds and using a 3ds file loader. Could you recommend one, and of course it has to work only with the 3ds file itself, no external texture files.
3ds max already allows me to export the file to obj. I have an object that has no external texture file, but it is already fully colored as a 3ds file. Is there any way to import in opengl and have the same colors, for the trunk, leaves?
You might want to check out lib3ds which will parse the 3ds binary format for you and give you access to all of the objects properties. I think Autodesk also has their own toolkit for doing this.
You should look at this link. It is a 3DS viewer with source code that renders using OpenGL. The code is simple.
Another option could be Assimp, an open source asset import library for C or C++, which seems like a pretty good way to get 3DS assets into an opengl program. It'd be especially useful if you want it for skeletal animations, and supports embedded textures. Though at this point, this answer may be less for you than it is for other people coming across this question.
If I remember correctly, the 3ds file does not store the vertex normals so you will probably have to calculate them yourself somehow or otherwise it will use the normal of the face itself which is will be quite ugly.