3

I'm having a hard time understanding the differences between the different representations of 3d objects following this slide (full video)

(The segment is this one)

Different representations Reading the corresponding wiki pages, I can't understand the following things:

  1. Which one is stored as 2D images are usually stored ("classic" 2d array of 3 RGB values)
  2. How do the others get stored?
  3. I understand that Mesh is a collection of polygons, but how does it get stored as a file?
  4. what is the difference between volumetric and point cloud?
| improve this question | |
5

Disclaimer: not an expert

Going by your points:

  1. The only one of the four stored as a 2D "flat" image is the Projected View. That is the actual rendering of the 3D model in a certain projection onto a plane, which is just a normal (2D) image.
  2. Actual file formats can be a bit complicated and include things such as compression algorithms and metadata. To keep it cleaner, I will only address the general idea behind the aproaches.
    • Point Cloud you would store a list of coordinates of (as many as possible) points on the surface of your object. The more points you store, the more details you retain.
    • Mesh, as you said, is a list of polygons, so you would store a list of points (verices of the polygon) and then a list of lists defining which points form a polygon together. Example of a cube object (polygons are the square sides)
      • vertices as tuples of coordinates: 1: (0,0,0), 2: (1,0,0), 3: (0,1,0), 4: (1,1,0), 5: (0,0,1), 6:
        (1,0,1), 7: (0,1,1), 8: (1,1,1),
      • and then the polygons as lists of vertices: [1,2,4,3], [5,6,8,7], [1,2,6,5], [3,4,8,7], [1,5,8,4], [2,6,7,3]
    • volumetric I am not sre about this one, I think they might be refering to voxels. Voxels are like pixels, but 3D, so you would divide your space into small cubes and then write down coordinates of each of the cubes that is filled by the object that you try to represent (possibly even including color, opacity, material...). Again, smaller or larger voxels (cubes) provide you with more or less detail (just as less pixels show lower quality images).
    • Projected view see above. That is just a normal image. You can have many different projections/renderings/images from one 3D model. Generally, you cannot create the original 3D model, if all you have is a projection of it.
  3. See above for a small (badly formatted) example. Note that there are more ways to accomplish the same thing.
  4. Again, see above. They are actually quite simmilar, but the point cloud approach does not start out with a regular grid. You just use some points, not pre-determined ones. With volumetric/voxel approach, you start with a rigid (3D) grid and then you fill it in (or not) depending on what the shape is.
| improve this answer | |
  • 2
    Note the voxel representation does not need to have constant size elements they can have different sizes. Also best not think them as boxes, also pixels not as squares but point samples that interpolate somehow. It could be a box filter but it is likely something like sinc or gaussian make more sense. Also volumetric does not need to be voxels it can be any implicit or explicit formulation like metaballs for example. – joojaa Sep 24 '18 at 15:48
  • J.E thanks for the intuitive and thorough explanation, that was exactly what I was looking for:) You're Mesh example isn't badly formatted at all, but exactly what someone without the 3d intuition needed. @joojaa can you please elaborate metaballs? if volumetric isn't set with voxels of predefined resolution, how does it generates the model? – DsCpp Sep 24 '18 at 16:05
  • @DsCpp it can be hierarchical or some pace splitting algorithm. Think of it as having lego brinks of different sizes. Metaballs are points in space that have their density reduce as a function of the distance to the point, the densities of several points then mix to produce a volume value, or a surface level set – joojaa Sep 24 '18 at 16:35
  • Rather than voxels, one volumetric option would be space-filling polyhedra: (mathworld.wolfram.com/Space-FillingPolyhedron.html ) and another would be filling space with surfaces defined by polygon meshes (en.wikipedia.org/wiki/Polygon_mesh )--- you are "inside" Object A until you pass one of the polygons, then you are "inside" Object B and so forth. Kind of like bubbles lumped together into a transparent foam. – elliot svensson Sep 24 '18 at 17:25
  • @elliotsvensson yeah that is how FEM works. – joojaa Sep 24 '18 at 17:30
1

The projected view is the only one of your list which is stored as 2D images in any way and is not in fact a 3D file at all, but rather an array of 2D images which allows user interpretation (and some AI's as well) to create a conceptual 3D understanding.

All 3D files are still binary data, and there are a host of proprietary and open-standards file format for 3D data, each with their relative merits and weaknesses, and with their own userbase and usecase.

Meshes describe only the surface geometry of the given 3D geometry (which are indeed describable as arrays of polygons) and are stored in files such as .obj, .fbx, .stl, .iges, .step, .3ds, .lwo, .lxo and so on - although most of these can also be considered "scene" filetypes, as they can contain non-mesh scene data specific to their respective applications - location, orientation and types of lights, cameras, environment arrays etc. Many 3D DCC (Digital Content Creation) applications have their own proprietary mesh file formats used for storing their own preset libraries - so for example though modo scene files are .lxo, the preset files are .lxl. Be clear though, even just a basic mesh isn't only an array of polys: whether vertices have been correctly merged (welded in Maya terms) matters for distortion or animation of a mesh, but in terms of simply defining polygon locations in space, co-incident vertices are not problematic - so we could for example define all the polys of a mesh such that the polys are in the correct places, with the correct spatial relationships, but not being unified there would be a massive multiplicity of vertices, and an almost-useless mesh in most real-world use-cases. Oh - most mesh-oriented file formats can store polygon tag information, which can relate to smoothing groups, normal maps, UV maps, texture maps, vertex maps, vertex colours, binding and weightmaps... and animation. So where once .obj was the exchange format of choice for most 3D artists, it's more often .fbx these days, as .fbx is super effective and efficient at storing animation and deformation data.

Volumetric does not only refer to voxel modeling, but can rather be generically described as a modeling approach in which all geometries are defined as "solids" versus only surfaces - there are some immense mathematical implications, both for how things are calculated, how objects are defined and how further operations are accomplished when modeling in this manner - most BIM authoring tools (ArchiCAD, Revit, Bently/Microstation for example) think this way - you define the width and height of a linear element like a wall or beam, you tell the BIM tool what the constituent materials are (or composites for walls for example) and then you draw out a given length: the application "knows" enough then about the materials in the composite the calculate correct intersections of you joint two such linear elements together at an oblique angle. This data can be stored in proprietary file formats, and can be (in the case of BIM files) interchanged between competing BIM apps using the IFC file format.

Point clouds, as already described, are effectively a listing of points in space, typically defined by a scan (or sometimes a particle simulation) and can come in one of roughly a half dozen file formats. They were originally most commonly found the in engineering, architecture and survey fields, and used to only convey geometry - these days most point clouds one receives also contain vertex colour info, so if your tool of choice reads in the point cloud correctly, you get a sort of pixilated 3D photo feel in your 3D workspace. these files are actually quite small for the data they contain, but in most BIM or 3D engineering tools, they tend to run wicked heavy on the GPU once you've read your data in. Many 3D DCC tools have meshing algorithms which allow you to create surface meshes from point clouds, setting a target resolution, so that the data you brought in for reference becomes something you can actually work with.

There is these days also a whole other category of volumetric 3D information - the VDB is a widely-used format which though associated with voxel modeling is not unique to it (you can even take point-cloud data and convert it to VDB, which can have some interesting applications and usecases). Bear in mind that most non-engineering fluid-simulation tools commonly used in the 3D modeling world can export their particle cloud data as VDB files - so you can simulate in something like RealFlow and bring your data across to your modeling or rendering tool of choice... and there are all kinds of other cross fertilisations happening now - where you can use a particle simulation in one tool to generate smoke, bring that into another simulation tool and use it as a base for a second simulation run for say sparks and lightning, then bring both sims into yet a third tool for meshing, modeling and rendering.

Hope this helps some.

| improve this answer | |
  • Bim tools actualy think in BREP which is different form volumetric. Its a enclosed volme but thats not exactly same as volumetric (the check is rather weak it cans still be impossible). Usually considered its own category actually, just like CSG – joojaa Sep 25 '18 at 15:52
  • 1
    @joojaa Nope: BREP is one of three modalities in which BIM data is INTERPRETED in model transfer situations - specifically when importing or exporting an IFC file. BREP is the condition in which you explicitly choose to LOSE all the BIM parametry in order to keep exact clean surface interface information, for export, say to the mechanical consultant who doesn't care that the element in question is a beam of type W-21, but only needs to know its exact exterior surface dimensions - versus structural who NEEDS that W-21 parameter, but doesn't give two hoots about surface dimensions! – GerardFalla Sep 25 '18 at 16:37
  • 1
    well its kind of true a BREP model can have parametric info its just that the current BIM solution does not support this. But generally BREP is kind of the go to guy for all these models, internally ist still just BREP even though it lies to you conveniently this is why it can export BREP.. The parametric info is not volumetric there is no description of what the beam looks like inside, such as destiny distributions. Although, you could insert this into the database. If i were to evaluate the beam would still need to do something to it unless i was the one who put it in. – joojaa Sep 25 '18 at 17:14
  • 1
    Anyway BIM is just a database, you could possibly have anything there. The BREPS may be missing. But generally they are just solids, not volumes. Note a solid can have its volume computed, but its does not exist as a description. A bit like a Image does not contain spectral info just RGB primaries, sometimes this is all you need, sometimes not. But it has been few years since i last programmed tools for BIM systems. – joojaa Sep 25 '18 at 17:20
  • 1
    @Geraerad that is exactly how all moder solid modellers work, and they all have brep underneath. Its just that they dont advertise it. The stripping happens because of tech differences in regeneration – joojaa Sep 25 '18 at 20:10
1

In my opinion, that section of the video is a bit messy.

Before the segment he is talking about input, then he goes to "representation" but one is neither representation or input. The rotative phonograph is not a 3D model, it is a sequence of "classic 2d array of 3 RGB values" dam... he or you should just say a sequence of images perceived by our brains as a 3D object. But there is no real 3D data.

But keep in mind that the video is for deep learning, so that image differentiation between the frames helps to reconstruct a 3D space or object. That is what humans do and what they try to teach to the AI.

That input from a rotational object (among different others*) can thru some analysis, can provide you with a point cloud data.

Cloud point data is a raw collection of points in a 3D space. They have no meaning, they have no correlation until you give one. They can be collected by a laser scan, they can be deducted from an analysis of a rotational image sequence... aka video, among other methods.

But a point has no real dimension, it is a point, not a line, not a plane, not a volume.

A first approach to make sense of a data is to give volume to them. Then you use the point as a center of a ball, or a cube. That is where volumetric comes into place. In the video, there is a blob car, made of... blobs.

When the dots are connected... you can define a polygon. Remember that to get one segment of a line, you take 2 points. For a 3D polygon, you take 3 non-colinear points.

Humans model stuff by using the other methods, polygons, primitives, nurbs etc. By the way, the image the dude posted on the video is not 3D primitive, it is a nurb or bezier based model technique.

I did not saw it all. I was not impressed.

The image of the cloud point data image you posted is... another classic 2d array of 3 RGB values... it is just a collection of pixels that our brain interprets as a... 3D bunny...

The same with the others. The "real" data is just raw data. Any image we see is a representation of that data.

Every node, on every type of modeling technique, is simply stored as a 3D coordinate as J.E writed. The notation may differ. Some prefer an XML notation

<theNameOfTheObject>
  the, data, ofIt
</theNameOfTheObject>

Some can just use data as they want.

In Nurbs and Bezier modes, the nodes are not of the vertexes, they are nodes to control the geometry. This geometry is reinterpreted by the program every time you open the file again.

A simple example using a 2D primitive. This is how a circle can be written in SVG.

<svg>
 <circle cx="50" cy="50" r="40" fill="black" />
</svg>

You only need to type what object it is, where is the center (x and y) and what is the radius. Now you have a circle that is redrawn by the application.

If you want to know specifics consult the documentation of the file format you want.

To understand how Nurbs and Bezier work, you can google the term to see some examples.

| improve this answer | |
  • Thanks a lot, cool inputs:) How does NURBS stored (ignoring compression, optimizations, etc.)? do you need to specify the curve function as well? can a NURBS model consist of several different curve functions? – DsCpp Sep 25 '18 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.