5 ms·

Just curious, which library are you referring to when you say "good 3D graphics"? I'm writing a graphics engine using PyOpenGL, but that's just a minimalist wra

by palish 18y ago

Just curious, which library are you referring to when you say "good 3D graphics"? I'm writing a graphics engine using PyOpenGL, but that's just a minimalist wrapper over the standard OpenGL API that's available for dozens of languages.

tlb 18y ago
Yes, I use PyOpenGL in GTK (with GTKGLExt). People have said good things about Gazebo, but I haven't used it. Most of the 3D stuff is performance-critical, so I typically prototype in Python and then convert to C++, which for graphics code isn't too painful. The Boost.Python interface makes it pretty easy. Also, the Cairo graphics interface is wonderful for drawing charts, animated robot stick figures, and many other visualizations. It has a full Postscript rendering model with alpha blending. It looks like PLT Scheme has an OpenGL binding too, though I haven't seen it used. It looks very low-level, for instance it has separate methods named: gl.Vertex3d gl.Vertex3dv gl.Vertex3f gl.Vertex3fv gl.Vertex3i gl.Vertex3iv gl.Vertex3s gl.Vertex3sv
- palish 18y ago
  Nice. Yeah, the GL graphics code is pretty easy to convert to C++ when performance matters. It's wonderful to quickly prototype graphics code in Python with full error checking. Also, if you haven't used it yet, check out Py++. It takes a lot of the pain out of hand-authoring a Boost.Python code file. I'm using Py++ to automatically generate Boost.Python bindings for the C++ library FCollada. (FCollada is a library for accessing 3D modeling data exported into the .dae COLLADA format.) Thanks for the tip about Cairo. Also, glVertex3d, 3dv, 3f, etc are part of the standard GL API. The 'd' suffix indicates 'double', 'f' indicates 'float', 'i' indicates 'int', 's' indicates 'short', and the 'v' suffix indicates that the function accepts a pointer rather than 3 separate components passed by value. Of course, the glVertex* API has been deprecated because VBOs are far more efficient. Just curious again, why do you use OpenGL for Anybots? Do you create simulations before building new robot prototypes?
  - tlb 18y ago
    My point was there's no single 'gl.Vertex3' call that takes native Lisp numbers. Thinking about double/float/int/short should be abstracted out below the Lisp level. We use OpenGL to show real-time renderings of the robot, derived from the gyros and joint angle sensors. We have an analysis tool that shows, either in real time or post-run analysis, renderings synchronized with high-speed video of the robot and scrolling strip charts of every important variable over time. I always see much more looking at slow-motion videos & renderings afterwards than looking at the real robot. OpenGL rendering also turned out to be useful for extracting data from CAD models. Our CAD software (SolidWorks) can export STL files (a list of polygons) and we need to extract center of mass and moment of inertia and such. Doing that without visualizing it is a nightmare. We have done dynamics simulations (using ODE), but they haven't had much predictive value.
    - palish 18y ago
      Ah. Very cool. Are you computing center of mass / moment of inertia yourself, or using a 3rd party library to do it? PhysX is free, and I believe it can do those calculations for you fairly automatically. (In PhysX, a 'scene' is composed of 'actors', and each actor is described by a set of shape descriptors. A shape descriptor can represent a box, a sphere, a capsule, a convex hull, etc. So a laptop actor could crudely be approximated with two box shape descriptors (one for the screen, one for the body) connected by a joint. Given those shape descriptors, the library calculates the actor's center of mass / moment of inertia / etc. If your CAD software simply exports a list of polygons, you'll need to decompose those into a set of convex hulls using convex hull decomposition techniques: http://codesuppository.blogspot.com/2006/04/approximate-convex-decomposition.html http://codesuppository.blogspot.com/2006/04/approximate-conv... ) You also might have better luck running dynamics simulations with PhysX than with ODE. It comes with a large number of code examples to get you started: http://developer.nvidia.com/object/physx_downloads.html http://developer.nvidia.com/object/physx_downloads.html
      - tlb 18y ago
        I use a very simple and exact O(N) algorithm to calculate mass properties of polyhedrons without computing convex hulls or anything: http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html Maybe 80 LOC. I'm not sure why anything more complex is needed. PhysX does seem promising.
- anthonyb 18y ago
  For Python, there are also a number of game libraries around which you might be able to repurpose. Pyglet, Pygame and PyOgre are three which spring to mind. Depending on exactly what you're trying to do, of course...
  - drawkbox 18y ago
    Panda3D, developed by Disney and given to CMU for research. One real MMO built off of it, Pirates of the Caribbean.
    - stcredzero 18y ago
      Panda3D is quite good. It has many basic building blocks for 3D games. When I used it, docs were ok but a bit sparse in places, but you could deduce much from what was auto-generated.
deleted 18y ago
[deleted]

by palish 18y ago

tlb 18y ago

Yes, I use PyOpenGL in GTK (with GTKGLExt). People have said good things about Gazebo, but I haven't used it. Most of the 3D stuff is performance-critical, so I typically prototype in Python and then convert to C++, which for graphics code isn't too painful. The Boost.Python interface makes it pretty easy. Also, the Cairo graphics interface is wonderful for drawing charts, animated robot stick figures, and many other visualizations. It has a full Postscript rendering model with alpha blending. It looks like PLT Scheme has an OpenGL binding too, though I haven't seen it used. It looks very low-level, for instance it has separate methods named: gl.Vertex3d gl.Vertex3dv gl.Vertex3f gl.Vertex3fv gl.Vertex3i gl.Vertex3iv gl.Vertex3s gl.Vertex3sv

palish 18y ago
Nice. Yeah, the GL graphics code is pretty easy to convert to C++ when performance matters. It's wonderful to quickly prototype graphics code in Python with full error checking. Also, if you haven't used it yet, check out Py++. It takes a lot of the pain out of hand-authoring a Boost.Python code file. I'm using Py++ to automatically generate Boost.Python bindings for the C++ library FCollada. (FCollada is a library for accessing 3D modeling data exported into the .dae COLLADA format.) Thanks for the tip about Cairo. Also, glVertex3d, 3dv, 3f, etc are part of the standard GL API. The 'd' suffix indicates 'double', 'f' indicates 'float', 'i' indicates 'int', 's' indicates 'short', and the 'v' suffix indicates that the function accepts a pointer rather than 3 separate components passed by value. Of course, the glVertex* API has been deprecated because VBOs are far more efficient. Just curious again, why do you use OpenGL for Anybots? Do you create simulations before building new robot prototypes?
- tlb 18y ago
  My point was there's no single 'gl.Vertex3' call that takes native Lisp numbers. Thinking about double/float/int/short should be abstracted out below the Lisp level. We use OpenGL to show real-time renderings of the robot, derived from the gyros and joint angle sensors. We have an analysis tool that shows, either in real time or post-run analysis, renderings synchronized with high-speed video of the robot and scrolling strip charts of every important variable over time. I always see much more looking at slow-motion videos & renderings afterwards than looking at the real robot. OpenGL rendering also turned out to be useful for extracting data from CAD models. Our CAD software (SolidWorks) can export STL files (a list of polygons) and we need to extract center of mass and moment of inertia and such. Doing that without visualizing it is a nightmare. We have done dynamics simulations (using ODE), but they haven't had much predictive value.
  - palish 18y ago
    Ah. Very cool. Are you computing center of mass / moment of inertia yourself, or using a 3rd party library to do it? PhysX is free, and I believe it can do those calculations for you fairly automatically. (In PhysX, a 'scene' is composed of 'actors', and each actor is described by a set of shape descriptors. A shape descriptor can represent a box, a sphere, a capsule, a convex hull, etc. So a laptop actor could crudely be approximated with two box shape descriptors (one for the screen, one for the body) connected by a joint. Given those shape descriptors, the library calculates the actor's center of mass / moment of inertia / etc. If your CAD software simply exports a list of polygons, you'll need to decompose those into a set of convex hulls using convex hull decomposition techniques: http://codesuppository.blogspot.com/2006/04/approximate-convex-decomposition.html http://codesuppository.blogspot.com/2006/04/approximate-conv... ) You also might have better luck running dynamics simulations with PhysX than with ODE. It comes with a large number of code examples to get you started: http://developer.nvidia.com/object/physx_downloads.html http://developer.nvidia.com/object/physx_downloads.html
    - tlb 18y ago
      I use a very simple and exact O(N) algorithm to calculate mass properties of polyhedrons without computing convex hulls or anything: http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html Maybe 80 LOC. I'm not sure why anything more complex is needed. PhysX does seem promising.
anthonyb 18y ago
For Python, there are also a number of game libraries around which you might be able to repurpose. Pyglet, Pygame and PyOgre are three which spring to mind. Depending on exactly what you're trying to do, of course...
- drawkbox 18y ago
  Panda3D, developed by Disney and given to CMU for research. One real MMO built off of it, Pirates of the Caribbean.
  - stcredzero 18y ago
    Panda3D is quite good. It has many basic building blocks for 3D games. When I used it, docs were ok but a bit sparse in places, but you could deduce much from what was auto-generated.

deleted 18y ago

[deleted]