How can I create a 3D model file from geometric shapes? - geometry

I am writing a program that will output 3D model files based on simple geometric shapes (e. g. rectangular prisms & cylinders) with known coordinates in 3-dimensional space. As an example, imagine creating a 3D model of stonehenge. this question suggests that OBJ files are the easiest to generate, but I'm struggling to find a good tutorial or easy-to-use library for doing so.
Can anyone either
(1) describe step-by-step how to create a simple file OR
(2) point me to a tutorial that describes how to do so
Notes:
* Using a GUI-based program to draw such files is not an option for me
* I have no prior experience with 3D modeling
* Other formats such as WRL or DAE would work for me as well
EDIT:
I do not need to use textures, just combinations of simple geometric shapes positioned in 3D space.

I strongly recommend to use some ASCII exchange format there are many out there I usually use these:
*.x DirectX object (it is a C++ source code)
this one is easiest to implement !!! But there are not many tools that can handle them. If you do not want to spend too much time coding then this is the right choice. Just copy the templates (at the start) from any *.x file to get started.
here some specs
*.iges common and importable on most CAD/CAM platform (Catia included)
this one is a bit complicated but for export purposes it is not that bad. It supports Volume operation like +,-,&,^ which are VERY HARD to implement properly but you do not have to use them :)
*.dxf AutoCAD exchange format
this one is even more complicated then IGES. I do not recommend to use it
*.ac AC3D
I first saw this one in flight gear.
here some specs
at first look it is quite easy but the sub-object implementation is really tricky. Unless you use it you should be fine.
This approach is easily verifiable in note pad or by loading to some 3D model viewer. Chose one that is most suitable for your needs and code save/load function to your Apps internal model class/struct. This way you will be compatible with other software and eliminate incompatibility problems which are native to creating 'almost known' binary formats like 3ds,...
In your case I would use IGES (Initial Graphics Exchange Specification)
For export you do not need to implement all just few basic shapes so it would not be too difficult. I code importers which are much much more complicated. Mine IGES loader class is about 30KB of C++ source code look here for more info
You did not provide any info about your 3D mesh model structure and capabilities
like what primitives you use, are your object simple or in skeleton hierarchy, are you using textures, and more ... so it is impossible to answer
Anyway export often looks like this:
create header and structure of target file format
if the format has any directory structure fill it and write it (IGES)
for sub-objects do not forget to add transformation matrices ...
write the chunks you need (points list, faces list, normals, ...)
With ASCII formats you can do this inside String variable so you can easily insert into or modify. Do all thing in memory and write the whole thing to file at the end which is fast and also add capability to work with memory instead of files. This is handy if you want to pack many files to single package file like *.pak or send/receive files through IPC or LAN ...
[Edit1] more about IGES
fileformat specs
I learned IGES from this pdf ... Have no clue where from I got it but this was first valid link I found in google today. I am sure there is some non registration link out there too. It is about 13.7 MB and original name IGES5-3_forDownload.pdf.
win32 viewer
this is free IGES viewer. I do not like the interface and handling but it works. It is necessary to have functional viewer for testing yours ...
examples
here are many tutorial files for many entities there are 3 sub-links (igs,peek,gif) where you can see example file in more ways for better understanding.
exporting to IGES
you did not provide any info about your 3D mesh internal structure so I can not help with export. There are many ways to export the same way so pick one that is closest to your App 3D mesh representation. For example you can use:
point cloud
rotation surfaces
rectangle (QUAD) surfaces
border lines representation (non solid)
trim surface and many more ...

Related

VTK: display integration point data

I'm working with the VTK library in C++.
I have a mesh given as an unstructured grid and certain data given on integration points of gaussian quadrature on the cells (which was created by an external solver). For the sake of simplicity, let's assume that we talk about scalar data.
I also have a tool which displays VTK data graphically. What I want is to display the mentioned data with that tool, simply as interpolated/extrapolated scalar data on the whole grid.
My question is, is there something native to VTK with which I can give the mesh the scalar data at the integration points in some way and VTK handles the interpolation and extrapolation?
I mean, I could write an algorithm that processes the data, creates a new grid in which the cells do not share nodes (as the extrapolated values might not be continuous there), extrapolate the scalars to those nodes for each cell and then display that. However, by this I take away from the native possibilities of the VTK library (which seems to be quite strong in most other regards) and I don't want to reinvent the wheel anyway.
From https://vtk.org/Wiki/images/7/78/VTK-Quadrature-Point-Design-Doc.pdf, I am aware that there is the vtkQuadratureSchemeDefinition class and I think I know how to handle it, and I noticed vtkQuadraturePointInterpolator, which seems to do the opposite of what I'm searching for - interpolation to the integration points rather than extrapolating from them.
The newest entry in the VTK wiki otherwise seems to be https://vtk.org/Wiki/VTK/VTK_integration_point_support, which seems to be quite old, given that it pleads for the existence of some sort of quadrature point support in general, which currently already exists.
Also there is a question in the VTK mailing list which looks just like my question here:
https://public.kitware.com/pipermail/vtkusers/2013-January/078077.html, which seems to be without an answer.
Likewise, the issue https://gitlab.kitware.com/vtk/vtk/issues/17124 also seems to be about what I want to do, and it might hint at it currently not being possible, but it existing as an issue does not imply that it is not already solved (especially with no asignee to the issue).

Easiest way to generate depth image/map from 3d model

I was wondering if anybody knew of an easy, robust way to generate depth images from 3d models (i.e. surface models, vertices with faces), with specifiable camera parameters.
I'd prefer "free" options if possible (e.g. pyOpengl or some open source Java library rather than say matlab).
I believe it is possible with the python blender api (noted here), but I'm hoping there's an easier way.
Note also that this question works only for that special case.
You can use DECA repository in Github. There, in ./demos, I used demo_reconstruct.py code to save the depth image.

Which CAD / geometry library should I use: CGAL Open CASCADE or Boost::Geometry something else?

For a customizable laser-cut drawers project I would like to be able to create the connection between any two intersecting perpendicular "2D" objects (with width) programmatically. For this I need to:
load and save 2D objects in some standard format.
extrude 2D object, and make the standard manipulations on 2D objects (specifically subtraction of objects.)
intersect 2 object, and be able to determine the "line" of intersection.
Which library/tool you would suggest for that? Can you estimate how difficult it would be to master it to do the above tasks?
Thanks,
Ronen
I'm biased ( PythonOCC dev ), but I'd say OpenCasCade would best fit your needs. Its comes wit Step and Iges importers out of the box ( more formats are supported commercially ), where you'd have to parse and reconstruct the geometry from a file with Boost and CGAL. Finally, neither of those packages deal with nurbs / CAD geometry ( BRep, boundary representation ) but merely triangles ( polygon soup ). So, OCC fits the scope best IMHO.
I have experience with OPENCASCADE and CGAL . Boost Geometry is very limited / simple and does not provider support for topological structures , solids , brep etc. The purpose has been quite different from the rest. Certainly, its quality is higher than any of the other two.
Opencascade among the three is least preferable choice in terms of quality. For example, everything is defined in global namespace, there are multiple macro definitions on header files, and has bloated classes. It has quite some support for various algorithms and constructs but only up to some point; for the rest you have to pay. These are somehow understandable, since it has been developed as an in-house library not for public access, and therefore they did not care about such things. The community is quite small, therefore you will have to go searching through the documentation a lot and experiment on how to do things. Usually, there are more than one way to work, and it is common to write many adaptors in your code to interface between different algorithms.
On the other hand CGAL is quite the opposite, has support for almost anything you can imagine, it is quite modern, and there is dedicated community along with very good documentation and examples for most use cases. There are different classes and algorithms depending on trade-off of the problem at hand. There is support for different UI (WIN/QT) and it interfaces well with STL / BOOST containers structures. Comparing to opencascade that does not even have a proper STL compatible iterator class, that is a significant difference.
Therefore, I would strongly suggest to work with CGAL.
In case you are forced to work with OPENCASCADE and want to use CGAL at the same time you will probably have to include header files such that Handle macro is undefed e.g.
#include <TopoDS_Shape.h>
#undef Handle
#include <CGAL/Alpha_shape_3.h>
#define Handle(ClassName) Handle_##ClassName

Signal Processing in Go

I have come up with an idea for an audio project and it looks like Go is a useful language for implementing it. However, it requires the ability to apply filters to incoming audio, and Go doesn't appear to have any sort of audio processing package. I can use cgo to call C code, but every signal processing library I find uses C++ classes which cgo cannot handle. It looks like libsox may work. Are there any others?
What libsox can provide and what I need is to take an incoming audio stream and divide it into frequency bands. If I can do this while only reading the file once, then bonus! I am not sure if libsox can do this.
If you want to use a C++ library you could try SWIG, but you'll have to get it out of Subversion. The next release (2.0.1) will be the first released version to support Go. In my experience the Go support is still a little rough, but then again the library I tried to wrap is a monster.
Alternatively, you could still create your own bindings through cgo using the same method SWIG does, but it will be painful and tedious. The basic idea is that you first create a C wrapper, then let cgo create a Go wrapper around your C wrapper.
I don't know anything about signal processing or libsox, though. Sorry.
There is a relatively new project called ZikiChombo
which contains so far some basic DSP functionality geared toward audio, see here
The dsp part of the project has filters on its roadmap, but they are not yet there. On the other hand some infrastructure for implementing filters, such as real fft and block convolution is there. Meaning that if you want FIRs, and can compute the coefficients by some other means, you can run them via convolution in zc currently with sound in real time.
Basic filtering design support (FIR,Biquad), for example using an ideal filter as a starting point will be the next step for zc. There are numerous small self-contained open source projects for basic and more advanced FIR and IIR filter design, most notably Iowa Hills which might be more accessible than a larger project to compute filter coefficients outside of Go.
More advanced filtering such as Butterworth, and filters based on polynomial solving and the bilinear transform will take more time for zc.
There is also some software defined radio Golang projects with some code related to filtering, sorry don't have the links offhand but a search for the topic may lead you to them.
Finally, there is a gonum Fourier package which also supplies fft.
So Go is growing some interesting and potentially stuff in this domain, but still has quite a ways to go compared to older projects (which are mostly in C/C++, or perhaps with a Python wrapper via numpy for example).
I am using this pure golang repo to perform Fourier Transforms with good effect
https://github.com/mjibson/go-dsp
just supply the FFT call with a
import (
"github.com/mjibson/go-dsp/fft" // https://github.com/mjibson/go-dsp
)
var audio_wave []float64
// ... now populate audio_wave with your audio PCM samples
var complex_fft []complex128
// input time domain ... output frequency domain of equally spaced freq bins
complex_fft = fft.FFTReal(audio_wave)

Which 3D Model format should I be using?

Im writing a game engine and I'm wondering what 3D model format should I use/load/export? Obj seems universal and easy but it also appears to be unreliable in that most models out there contain errors and it doesn't store anywhere near as much as other formats.
There appear to be formats specifically for games such as MD2/3/5 but Im not sure, I use wings3d if I model, and I don't know what other details beyond purely loading what I need and support from the format Id have to implement, such as would I need to implement IK? and can I use scripted per piece animation rather than Inverse kinematics and bone rigging?
Collada is an open XML based format for 3d models owned by the Khronos group(OpenGL standards body)
From the Collada.org FAQ:
The COLLADA 1.4.x feature set includes:
Mesh geometry
Transform hierarchy (rotation, translation, shear, scale, matrix)
Effects
Shaders (Cg, GLSL, GLES)
Materials
Textures
Lights
Cameras
Skinning
Animation
Physics (rigid bodies, constraints, rag dolls, collision, volumes)
Instantiation
Techniques
Multirepresentations
Assets
User data
Before worrying about what 3D formats you want to support, I think you should really focus on what features you are planning to implement in your engine. Write those down as requirements, and pick the format that supports the most features from the list... as you'll want to showcase your engine (I am assuming you are planning for your engine to be publicly available). You might even want to roll your own format, if your engine has specific features (which is always a good thing to have for a game engine).
After that, support as many of the popular formats as you can (.X, .3DS, .OBJ, .B3D)... the more accessible your engine is, the more people will want to work with it!
Collada is a nice and generic format, but like Nils mentions, it is not an ideal format for final deployment.
I use my own binary format. I've tried to use existing formats but always run into limitations. Some could be worked around, others where showstoppers.
Collada may be worth a look. I don't think that it's that good as a format to be read by a 3D engine. It's fine as a general data-exchange format though.
http://www.collada.org/mediawiki/index.php/Main_Page
+1 for Collada. You may also want a custom native binary format for really fast loading (usually just a binary dump of vertex/index buffer data, plus material and skeleton data, and collision data if appropriate).
One trend in the games industry is to support loading a format like collada in the developer build of the engine, but also have a toolchain that exports an optimized version for release. The developer version can update the mesh dynamically, so as artists save changes, the file is automatically reloaded allowing them an (almost) instant WYSIWYG view of their model, but still providing a fully optimised release format.
support Collada well, and then supply good converters to/from the other formats (this might be the hard part). This will give you maximum flexibility. Take a look at C4 engine
Collada is great, but it lives more on the 3D app side of things. ie it's best used for transferring 3D data between applications, not loading 3D data from within a games engine. Have you looked into Lua? It's widely used in games because its a scripting language that's both ridiculously quick (perfect for games) and very flexible (can be used to represent whatever data you need for your engine).

Resources