Considerations regarding 3D in openFrameworks

Hello everybody,
in the last year I have worked quite intensively with three.js and openFrameworks. I know that they have a totally different purpose in mind, and that three.js is specifically for 3D, while openFrameworks it isn’t.
But still, after working with 3D in three.js, having to create a 3D scene with some functionalities in OF is a kind of pain, because there are many things that are not implemented. Or it forces you to rely heavily on addons that sometimes are not maintained or that they require some fix before to get them working (usually to update them from ofVec3 to glm::vec3). I do believe that to have some improvements in the core of OF would make things easier for most of us using 3D with openFrameworks. I make a short list of what I think it would be nice to have:

These things should be quite easy to add:

  1. Adding a method to recalculate the normals in an ofMesh. People are keeping writing a method that just does this, people are keeping wrtiting addons that do just this.
  2. Adding a BoundingBox to the ofPrimitive class.
  3. Adding a Ray and a Plane class. These 2 things are quite fundamentals.
  4. A Mesh for the the ofPolyline class, something like

Things that are more difficult to add, but they would be a nice to have.

  1. A GLTF importer (although we do not have a scene in OF, we could create a hierarchy of ofNode)
  2. A PBR material. Almost all 3D engines today have something like this. In one OF meetup in Berlin @arturo suggested to create an addon based on Google Filament and I do think it is a nice idea, but the problem is, would that addon be part of the core, or would it be another addon that brakes with a new release?

I am aware to the fact the OF it is used mostly for computer vision projects, but what I have always liked mostly in OF is the general oriented direction, the possibility to mix fields, like generative design and computer vision, arduino and 2D drawing, sound and sensors, etc… Having a more complete 3D toolset would be just a possibility more.


Thanks Davide, thats a really interesting feature,

I feel that most of us are pasting the same code snippets to solve some basic mesh and 3D funcionalities, like calculaing vector normals, indexing a mesh, calculating AABB or bounding boxes.

I’m totally agree with all the points mentioned by edapx

I use ofxNanoVG for drawing lines (point 4) and ofxPBR to add material and lighting (point 2). The most difficult aspect with 3D (IMHO), is the code modularity, especially when you work with shaders. Without a “standard” path to add these features, the code is often specific for the current task and hard to reuse in the upcoming projects.

a good thought for if something should go in the core is:

a) is this a building block that other addons could be based off of
b) is this solving a universal problem in an elegant way

I agree with more mesh utilities and the (1-4) easy things – this code is super old but I go to it often:

things like gltf / pbr sounds like they could be addons or core addons, such as assimp loader. The thing about core vs non core addon is just deciding if it’s helpful for a beginner to have and issues like breaking relate to authorship and who is maintaining the addon – if an addon is core it gets more testing / love but also it doesn’t change as much so it’s not always the best for brand new or just in progress addons.

1 Like

Also even simple things can be more complicated than they look when they have to cover all the cases. for example calculating normals is fine with that algorithm when the mesh is based on triangles but when you have to cover all the primitive types supported by ofMesh things get more complicated.

In any case agree with zach that more complex things should go into addons.

We should look into having some kind of curated addons section where we make sure that certain things are well supported and up to date even if they are not official addons. which would also make it easier to distribute the maintenance effort


You are absolutely right. And I also think that complicated things should be an addon. The problem is that at the moment the addon ecosystem is a jungle, it is extremely vital but it is difficult to find addons that are up to date and working. CI integration has solved a part of the issue, I think that the second step could be filled out by a list, as you were saying. How should we start? should we create a list with all the addons that are tested on CI? or should we organize them by categories, as the website is doing?

Back to the normal calculation, we could start covering TRIANGLES and TRIANGLE_STRIP geometries. For the mesh modes that are not supported at the moment, we could simply ofLog “The normal calculation for the mesh type X is not supported yet”. I think that with triangle strip and triangles we cover 90% of the cases, if not more. It is incomplete, but it is a beginning.

Off topic maybe, but… in order to digging into the big list of addons, a little trick when searching which fork of a GitHub repository could be more recently updated, you can search for:

ofxTimelime fork:true

Then you can sort for updating dates of an addon.

1 Like