Hi,
Is there any way to do three dimensional graphics or movement through a 3D space with openFrameworks? If not, does anyone know a good library for Xcode to do 3D graphics and environments with?
Thanks.
Hi 
Eloi is right you can do all sorts of 3D with openGL which openFrameworks wraps.
The shapes in ofGraphics are all very basic 2D shapes that people are likely to use, but you should be able to find tons of examples of drawing 3D shapes in openGL.
You could find some openGL code for basic 3D shapes here:
http://nehe.gamedev.net/data/lessons/le-…-?lesson=05
The shapes code always starts with a call to glBegin( ); and ends with glEnd(); The drawing method of the shape is determined by the argument to glBegin - it can be GL_LINE_LOOP which will draw the shape as a wireframe or as they use GL_TRIANGLES which draws the shape solid as a series of triangles. If you look at ofGraphics.cpp we use the same calls for our 2D shapes (ofRect etc ) except to do 3D shapes you just specify a 3rd coordinate using glVertex3f instead of glVertex2f.
Also thanks to a new Addon that our friend Josh Nimoy is working on you will soon be able to load the 3D modeling .obj format files as an openGL shape. This means you can export 3D models from maya, 3D Max, etc into your openFrameworks world.
This should be coming pretty soon - there are just a few more tweaks to be done.
Theo
hmm, good to hear. keep up the good work with obj. but why not collada or fbx? seems to be “the” new hot shit format for every 3d package …
Because the code is already written and plugs in quite nicely 
We can maybe try and get someone to develop a collada importer afterwards - but for most basic purposes obj loading should be enough.
Cheers,
Theo
fine, fine. there should be a lot of valid obj-importer-code out there. will grouping and materials be supported?
collada would be a nice move if xml i/o gets into OF.
3ds and ASE (ASCII Scene Export, we used that a lot in the futurelab) would be nice too. might be a good time/opportunity to refactor importer code
but i would be particularly interested how the rendering with opengl is handled (good ol’ displaylists, ofVertexArray or even ofVertexBufferObject?) … ?!
that in combination with some nice shaders could turn out nice …
cheers, didi
Yes and of course if you have some experience with any of this stuff - it is an opensource project and we would love any contributions you could make - ASE Collada etc -
It would be dope if the importer could handle multiple input formats!
Cheers!
Theo
sure, this might eventually happen. but for now i’m trying to assemble some feedback and fixes for OF from our experiences with the THiNK project and contribute that way …
Yeah, FBX is fun, and I especially enjoy the promise brought by collada. Collada being XML-based (hence implicitly hotShitWorthy) would be especially satisfying to implement thanks to Theo.
Here’s pie in the sky for you . . .
If I were to bridge open source scenes properly, then openFrameworks would have a new addon called blenderSceneImporter which would support VRML, DXF, STL, 3DS, AC, DAE (1.3.1+1.4), OFF, X (activeX), LWF, MD2, BVH, FLT, SVG, PS, EPS, AI, gimp paths, SLP, RAW (whatever that means to blender), PLY, and last but not least, OBJ. But before we get there, we will need at least to give birth to the ofPython addon. If the blenderSceneImporter gets written, then it suddenly becomes very easy to write blenderSceneExporter as well, and just link those extra scripts up. Then you can wrap both importer and exporter classes in one higher level class called simply ofMesh basically supporting the intersection of all the aforementioned 3d formats. Then give this class a nice function like ofMesh::loadFile(char*filename) and then guess the file type based on the dot suffix, or dump an error. The goal at the highest level of the code should be to remain format-neutral.
For now, we’ve got OBJ, because it was a pre-existing C++ class I implemented into jttoolkit, so it works here and now. Also, because it sort of works as its own self contained class whose code you can sift through and learn token parsing from. I think the OBJ parser code is educational. The grouping system [the ‘g’ token] is easy enough for someone to add into the parser step OBJ::loadFile(char*filename), but then group membership would only manifest itself as metadata of a face object. So there would be int objFace::group , and redundantly, there would be a list of groups vector OBJ::groups, each a list of objFace instances. I can think of things that people would use this for, but I can also think of other ways to use the groupage than that.
Another thing I want to see soon in the OBJ addon is support for bezier curves. I mean there’s this whole implementation spec that I could be following at http://orion.math.iastate.edu/burkardt/data/obj/obj-format.txt and so far, I’ve only covered a 40% subset, namely, the stuff I needed the most at the time I wrote the object. But do not let that stop you from adding in the rest! I also need someone to help me build a test folder of OBJ files exported from a variety of apps so I can test them against the importer.
As for materials and textures, texture vertices are already supported, but the function OBJ::fillFaces(), which in turn calls OBJ::renderFace(int id), does not have an internal texture binding system, nor does it import any textures from disk. My decision is to wait until ofImage exposes a public reference to its OpenGL texture ID, so I can glBind it. So I’m yielding to core dev.
cheers
J
if collada import is really critical to anyone, you might find useful stuff at
sounds all reasonable. keep up the good work!
good idea. waiting for that to. or actually it was one of the first changes i made to OF
didi, josh,
a side note, since you are both thinking about this – would you be comfortable with getters for private stuff like private members inside of classes?
like adding this to ofTexture.h:
int getTextureWidth(){ return tex_w; };
int getTextureHeight(){ return tex_w; };
int getWidth(){ return width; };
int getHeight(){ return height; };
float getTextureCoordT(){ return tex_t; };
float getTextureCoordU(){ return tex_u; };
unsigned int getTextureName(){ return texName[0]; }
bool getFlipped(){ return bFlipTexture; };
we want to not make things too public, (so that we can have a clear division about variables people should touch or not touch but we can see very clearly that things need to be accessible (we ourselves make that change too), so that people can write classes that extend OF classes, etc.
or just make everything public but make it in the code what we think shouldn’t be touched?
what do you think? we will change and get into the svn shortly…
thanks!
zach
Yeah - i remember Zach, you brought up getters and setters before. I like the idea, and I like teaching the implementation practice. Languages like ECMAScript provide get and set overloader functions whilst C++ does not. As for the added workload of getter and setter conventions, there exists a wholesome-debate wherein the guy just starts using an associative array. I think that’s a bit too clever.
In this specific case, you can probably just write ofImage::bindTexture() or something even more minimal, like just texture() as in draw(), so texturing remains an engine neutral idea. That’s why I was confused by setUseTexture() when I first saw that.
yeah the deal with setUseTexture is that by default, everything that needs to draw itself (images, movie players, etc) uses a texture, so we need to allocate it with the object itself. The problem is that if you have ALOT of objects, perhaps you don’t need textures for them all (And to take up so much memory on the graphics card). So we allow you to call “setUseTexture()” to allow you to skip the allocation. I admit that it’s confusing, but it’s kind of an advanced usage, so for us it hasn’t been high on the radar. by default, for 90% of things people want to do, they don’t need it.
maybe a good alternative would be to just not allocate until the first draw?
I’m not sure how we would implement texture(), but it’s no problem at all to work in a bind function …
getters and setters will get more attention in the next release, especially as people start to extend OF and need access to those hidden fields.
thanks!!
zach