Java3D and Frameworks for CAE Visualization [modified]
-
Hi all, I have been programming C++ on Windows since 1994. However, it has not been possible to keep up with all the things on the programming side lately--I've been doing research in engineering science and mechanics. So, I thought of raising a question that I have, somewhere here at CodeProject. Hope to get your well thought out answers. (I posted a similar message in "General Discussions" but it didn't get any replies for 24+ hours, so I am posting in the Lounge now.) Recently I ran into Java3D and it seems to suit many of my requirements. I wanted a framework with which to rapidly write custom-built visualization programs for certain CAE applications that are based not on the routine tetrahedral meshes (B-Rep) but on the voxel or other representations (e.g. CSG and similar techniques, octrees, or, the points-as-primitives QSplat system of Stanford, etc.). My question is: Does anyone know anything comparable to Java3D, but on the Microsoft platform, preferably using C++? Please note a few things before you answer: This is not a platform-wars related thingie. ... As far as my personal preferences go, I would actually prefer something on VC++ 6/Win2K because that's what I am most acquainted with and find myself most comfortable in. However, I also find that DirectX technology is too inclined towards the games and X-Box sort of development. But CAE applications often do not require many of those advances in rendering as such. For example, CAE apps almost never need texture mapping, advanced translucency-based considerations, etc. At the same time, CAE (and medical, haptics, etc.) applications require some other things which are not provided by either OpenGL or DirectX. For example, consider the following. Imagine a field, say, a CT scan of an organ wherein there is some field value associated with each point/voxel inside the organ volume. Suppose someone wants to take an *oblique* cut through it--i.e. the plane of the cut is not parallel to the main reference system made by the scanning planes. Since the voxel is not a point, some interpolation would be required over the oblique plane, and perhaps, there would also be a need for anti-aliasing the values interpolated along the surface of the cut (not necessarily planar). Here, neither DirectX nor OpenGL gives me what is needed. This was just an example. There are several other considerations (or factors) too. Since many customizations as in the above paragraph would be necessary, I would rather play with an existing renderer. Yet,
-
Hi all, I have been programming C++ on Windows since 1994. However, it has not been possible to keep up with all the things on the programming side lately--I've been doing research in engineering science and mechanics. So, I thought of raising a question that I have, somewhere here at CodeProject. Hope to get your well thought out answers. (I posted a similar message in "General Discussions" but it didn't get any replies for 24+ hours, so I am posting in the Lounge now.) Recently I ran into Java3D and it seems to suit many of my requirements. I wanted a framework with which to rapidly write custom-built visualization programs for certain CAE applications that are based not on the routine tetrahedral meshes (B-Rep) but on the voxel or other representations (e.g. CSG and similar techniques, octrees, or, the points-as-primitives QSplat system of Stanford, etc.). My question is: Does anyone know anything comparable to Java3D, but on the Microsoft platform, preferably using C++? Please note a few things before you answer: This is not a platform-wars related thingie. ... As far as my personal preferences go, I would actually prefer something on VC++ 6/Win2K because that's what I am most acquainted with and find myself most comfortable in. However, I also find that DirectX technology is too inclined towards the games and X-Box sort of development. But CAE applications often do not require many of those advances in rendering as such. For example, CAE apps almost never need texture mapping, advanced translucency-based considerations, etc. At the same time, CAE (and medical, haptics, etc.) applications require some other things which are not provided by either OpenGL or DirectX. For example, consider the following. Imagine a field, say, a CT scan of an organ wherein there is some field value associated with each point/voxel inside the organ volume. Suppose someone wants to take an *oblique* cut through it--i.e. the plane of the cut is not parallel to the main reference system made by the scanning planes. Since the voxel is not a point, some interpolation would be required over the oblique plane, and perhaps, there would also be a need for anti-aliasing the values interpolated along the surface of the cut (not necessarily planar). Here, neither DirectX nor OpenGL gives me what is needed. This was just an example. There are several other considerations (or factors) too. Since many customizations as in the above paragraph would be necessary, I would rather play with an existing renderer. Yet,
If I recall correctly, Java3D is a scenegraph, right? If so, look on SourceForge, there are lots of C++ OpenGL (or DirectX) based scene graph frameworks. Ogre comes to mind as one, OpenInventor (I think that's the name) is another.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
Hi all, I have been programming C++ on Windows since 1994. However, it has not been possible to keep up with all the things on the programming side lately--I've been doing research in engineering science and mechanics. So, I thought of raising a question that I have, somewhere here at CodeProject. Hope to get your well thought out answers. (I posted a similar message in "General Discussions" but it didn't get any replies for 24+ hours, so I am posting in the Lounge now.) Recently I ran into Java3D and it seems to suit many of my requirements. I wanted a framework with which to rapidly write custom-built visualization programs for certain CAE applications that are based not on the routine tetrahedral meshes (B-Rep) but on the voxel or other representations (e.g. CSG and similar techniques, octrees, or, the points-as-primitives QSplat system of Stanford, etc.). My question is: Does anyone know anything comparable to Java3D, but on the Microsoft platform, preferably using C++? Please note a few things before you answer: This is not a platform-wars related thingie. ... As far as my personal preferences go, I would actually prefer something on VC++ 6/Win2K because that's what I am most acquainted with and find myself most comfortable in. However, I also find that DirectX technology is too inclined towards the games and X-Box sort of development. But CAE applications often do not require many of those advances in rendering as such. For example, CAE apps almost never need texture mapping, advanced translucency-based considerations, etc. At the same time, CAE (and medical, haptics, etc.) applications require some other things which are not provided by either OpenGL or DirectX. For example, consider the following. Imagine a field, say, a CT scan of an organ wherein there is some field value associated with each point/voxel inside the organ volume. Suppose someone wants to take an *oblique* cut through it--i.e. the plane of the cut is not parallel to the main reference system made by the scanning planes. Since the voxel is not a point, some interpolation would be required over the oblique plane, and perhaps, there would also be a need for anti-aliasing the values interpolated along the surface of the cut (not necessarily planar). Here, neither DirectX nor OpenGL gives me what is needed. This was just an example. There are several other considerations (or factors) too. Since many customizations as in the above paragraph would be necessary, I would rather play with an existing renderer. Yet,
Ajit Jadhav wrote:
My question is: Does anyone know anything comparable to Java3D, but on the Microsoft platform, preferably using C++?
OpenSceneGraph Ogre SGL nVidia SceneGraph The free list is is about a dozen, though I would have to hunt for the less used ones. The commercial list is about 100. Vterrain.org (virtual terrain project) has used several as their core: http://www.vterrain.org/Implementation/Libs/sg.html[^] so you can pick your choice.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
If I recall correctly, Java3D is a scenegraph, right? If so, look on SourceForge, there are lots of C++ OpenGL (or DirectX) based scene graph frameworks. Ogre comes to mind as one, OpenInventor (I think that's the name) is another.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
Thanks. Pl. see the reply below.
---------- http://www.JadhavResearch.info
-
Ajit Jadhav wrote:
My question is: Does anyone know anything comparable to Java3D, but on the Microsoft platform, preferably using C++?
OpenSceneGraph Ogre SGL nVidia SceneGraph The free list is is about a dozen, though I would have to hunt for the less used ones. The commercial list is about 100. Vterrain.org (virtual terrain project) has used several as their core: http://www.vterrain.org/Implementation/Libs/sg.html[^] so you can pick your choice.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Thanks (to you and to Jim Crafton). For some odd reason, nVidia SceneGraph hadn't come up in Internet search. I got to know of this SDK only now. So, special thanks to you (El Corazon). OK. Sorry if I misled you. But what I really needed was not so much a scene graph by itself as a ready-made and *simple* volume renderer, *and* a very small enabling frame-work on top of which the renderer rests. So, the frame-work would be a layer above DirectX/OpenGL, and the volume renderer will sit on top of the frame-work. I wanted *both*. (Ideally, I also wanted an octree based renderer on top of the framework.) The keywords are *small* frame-work (in source code terms--not thin clients etc. which isn't my concern), and an already existing and strongly object oriented implementation for the volume renderer (again, a small implementation). There *are* a few volume renderers in C++ like VolPack, VolVis, etc. But they are more or less stand-alone. I mean, the underlying framework is not even separately identifiable. (So, I can't use it to try out separate extensions in, say, CSG or octree rep.) There also are scene graph frameworks (like the ones you mentioned). But they come without any of the volume- or octree-renderers. Also, these frameworks tend to be a little too big. There also are some parallel processing volume renderers. (Too big.) And, of course, ray tracers. (Too big.) ----- I think by now I've got you confused thoroughly. :doh: So, let me rephrase the whole thing thus: Say, if a professor has written a scene graph *and* a volume renderer on top of it, both purely from educational (or teaching) point of view, then that code will suit my current requirements best. It would be nice if he had also written the CSG/octree based codes but this is not required right away. More important: It doesn't have to be optimal or industrial strength code. Does such thing exist in C++? :suss: The reason I got attracted to Java3D was (relatively) small size, *and* the fact that there is a simple volume renderer ready-made available. BTW, I have heard of Java to C# source code translator. Does it produce readable code? Thanks in advance.
---------- http://www.JadhavResearch.info
-
Thanks (to you and to Jim Crafton). For some odd reason, nVidia SceneGraph hadn't come up in Internet search. I got to know of this SDK only now. So, special thanks to you (El Corazon). OK. Sorry if I misled you. But what I really needed was not so much a scene graph by itself as a ready-made and *simple* volume renderer, *and* a very small enabling frame-work on top of which the renderer rests. So, the frame-work would be a layer above DirectX/OpenGL, and the volume renderer will sit on top of the frame-work. I wanted *both*. (Ideally, I also wanted an octree based renderer on top of the framework.) The keywords are *small* frame-work (in source code terms--not thin clients etc. which isn't my concern), and an already existing and strongly object oriented implementation for the volume renderer (again, a small implementation). There *are* a few volume renderers in C++ like VolPack, VolVis, etc. But they are more or less stand-alone. I mean, the underlying framework is not even separately identifiable. (So, I can't use it to try out separate extensions in, say, CSG or octree rep.) There also are scene graph frameworks (like the ones you mentioned). But they come without any of the volume- or octree-renderers. Also, these frameworks tend to be a little too big. There also are some parallel processing volume renderers. (Too big.) And, of course, ray tracers. (Too big.) ----- I think by now I've got you confused thoroughly. :doh: So, let me rephrase the whole thing thus: Say, if a professor has written a scene graph *and* a volume renderer on top of it, both purely from educational (or teaching) point of view, then that code will suit my current requirements best. It would be nice if he had also written the CSG/octree based codes but this is not required right away. More important: It doesn't have to be optimal or industrial strength code. Does such thing exist in C++? :suss: The reason I got attracted to Java3D was (relatively) small size, *and* the fact that there is a simple volume renderer ready-made available. BTW, I have heard of Java to C# source code translator. Does it produce readable code? Thanks in advance.
---------- http://www.JadhavResearch.info
Ajit Jadhav wrote:
But what I really needed was not so much a scene graph by itself as a ready-made and *simple* volume renderer, *and* a very small enabling frame-work on top of which the renderer rests.
volume rendering is pretty easy, depending on the (excuse the pun) volume of data. As long as the total volume of data is within your hardware's capablility to draw, simply set it up as a 3D texture, and draw a point cloud within the texture. http://gpwiki.org/index.php/OpenGL_3D_Textures[^] or break the point cloud into planes for hybrid mode http://www.cg.cs.uni-bonn.de/docs/publications/2005/wahl-2005-hybrid.pdf[^] or just render plane slices within the volume directly: http://www.bluevoid.com/opengl/sig00/advanced00/notes/node308.html[^]
Ajit Jadhav wrote:
if he had also written the CSG/octree based codes
From this I assume you have sparse volume data you are trying to cull, or worse, out of core rendering? I am curious what you need the octree for. OpenScene graph can do most culling, and you can create a octree scenegraph visitor and simply store your nodes in octree form. OpenScene graph doesn't preclude you from using portals, or octrees or anything like that, and can actually help you do so. there are papers on octree volume rendering: http://www.cs.utah.edu/~knolla/octsurvey.pdf[^] nVidia Scene Graph is here: http://developer.nvidia.com/object/nvsg_details.html[^] but it doesn't sound like what you want, per se. 3D volumes are relatively easy in OpenGL, only about a dozen or so lines of code, but it soun
-
Hi all, I have been programming C++ on Windows since 1994. However, it has not been possible to keep up with all the things on the programming side lately--I've been doing research in engineering science and mechanics. So, I thought of raising a question that I have, somewhere here at CodeProject. Hope to get your well thought out answers. (I posted a similar message in "General Discussions" but it didn't get any replies for 24+ hours, so I am posting in the Lounge now.) Recently I ran into Java3D and it seems to suit many of my requirements. I wanted a framework with which to rapidly write custom-built visualization programs for certain CAE applications that are based not on the routine tetrahedral meshes (B-Rep) but on the voxel or other representations (e.g. CSG and similar techniques, octrees, or, the points-as-primitives QSplat system of Stanford, etc.). My question is: Does anyone know anything comparable to Java3D, but on the Microsoft platform, preferably using C++? Please note a few things before you answer: This is not a platform-wars related thingie. ... As far as my personal preferences go, I would actually prefer something on VC++ 6/Win2K because that's what I am most acquainted with and find myself most comfortable in. However, I also find that DirectX technology is too inclined towards the games and X-Box sort of development. But CAE applications often do not require many of those advances in rendering as such. For example, CAE apps almost never need texture mapping, advanced translucency-based considerations, etc. At the same time, CAE (and medical, haptics, etc.) applications require some other things which are not provided by either OpenGL or DirectX. For example, consider the following. Imagine a field, say, a CT scan of an organ wherein there is some field value associated with each point/voxel inside the organ volume. Suppose someone wants to take an *oblique* cut through it--i.e. the plane of the cut is not parallel to the main reference system made by the scanning planes. Since the voxel is not a point, some interpolation would be required over the oblique plane, and perhaps, there would also be a need for anti-aliasing the values interpolated along the surface of the cut (not necessarily planar). Here, neither DirectX nor OpenGL gives me what is needed. This was just an example. There are several other considerations (or factors) too. Since many customizations as in the above paragraph would be necessary, I would rather play with an existing renderer. Yet,
Ajit Jadhav wrote:
Imagine a field, say, a CT scan of an organ wherein there is some field value associated with each point/voxel inside the organ volume. Suppose someone wants to take an *oblique* cut through it--i.e. the plane of the cut is not parallel to the main reference system made by the scanning planes. Since the voxel is not a point, some interpolation would be required over the oblique plane, and perhaps, there would also be a need for anti-aliasing the values interpolated along the surface of the cut (not necessarily planar).
looking back at this, this is exactly what 3D texturing does for you. You can define the CT data as the 3D texture, not a voxel list. Draw the plane where you want the cut, and you can view a slice at any oblique angle already smoothly textured and bilinear (or trinear) interpolated and fully antialiased. This is fully suppored by both OpenGL and DirectX.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Ajit Jadhav wrote:
But what I really needed was not so much a scene graph by itself as a ready-made and *simple* volume renderer, *and* a very small enabling frame-work on top of which the renderer rests.
volume rendering is pretty easy, depending on the (excuse the pun) volume of data. As long as the total volume of data is within your hardware's capablility to draw, simply set it up as a 3D texture, and draw a point cloud within the texture. http://gpwiki.org/index.php/OpenGL_3D_Textures[^] or break the point cloud into planes for hybrid mode http://www.cg.cs.uni-bonn.de/docs/publications/2005/wahl-2005-hybrid.pdf[^] or just render plane slices within the volume directly: http://www.bluevoid.com/opengl/sig00/advanced00/notes/node308.html[^]
Ajit Jadhav wrote:
if he had also written the CSG/octree based codes
From this I assume you have sparse volume data you are trying to cull, or worse, out of core rendering? I am curious what you need the octree for. OpenScene graph can do most culling, and you can create a octree scenegraph visitor and simply store your nodes in octree form. OpenScene graph doesn't preclude you from using portals, or octrees or anything like that, and can actually help you do so. there are papers on octree volume rendering: http://www.cs.utah.edu/~knolla/octsurvey.pdf[^] nVidia Scene Graph is here: http://developer.nvidia.com/object/nvsg_details.html[^] but it doesn't sound like what you want, per se. 3D volumes are relatively easy in OpenGL, only about a dozen or so lines of code, but it soun
Thanks for a lot of useful information and URLs. I will go through the links and come back later, probably at the Graphics forum. About octrees: Not all my ideas are so well thought as yet, and some parts of them go right across the domain and onto the mechanics side of computational mechanics. ... I wanted octrees not so much for culling of fine-grained 3D volume data, as for its seeming opposite: for progressive and non-uniform refining so as to get more accurate field computations in the regions of interest (or greatest change of field variable). Now, in abstract terms, this is not at all a new idea. Automatic mesh refining is something that is routinely done in engineering analysis methods like FEM. It's just that there would be some difference in the nature of field computations or mathematics (between FEM and what I want to do), and so, I would like to have a control over the process at the source code level. Also see my reply to your other answer. Let me think over all these matters and come back in Graphics forum. (Right now, the ideas are in a very fluid stage.) Thanks, again!
---------- http://www.JadhavResearch.info
-
Ajit Jadhav wrote:
Imagine a field, say, a CT scan of an organ wherein there is some field value associated with each point/voxel inside the organ volume. Suppose someone wants to take an *oblique* cut through it--i.e. the plane of the cut is not parallel to the main reference system made by the scanning planes. Since the voxel is not a point, some interpolation would be required over the oblique plane, and perhaps, there would also be a need for anti-aliasing the values interpolated along the surface of the cut (not necessarily planar).
looking back at this, this is exactly what 3D texturing does for you. You can define the CT data as the 3D texture, not a voxel list. Draw the plane where you want the cut, and you can view a slice at any oblique angle already smoothly textured and bilinear (or trinear) interpolated and fully antialiased. This is fully suppored by both OpenGL and DirectX.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
looking back at this, this is exactly what 3D texturing does for you. You can define the CT data as the 3D texture, not a voxel list. Draw the plane where you want the cut, and you can view a slice at any oblique angle already smoothly textured and bilinear (or trinear) interpolated and fully antialiased. This is fully suppored by both OpenGL and DirectX.
I didn't know about *that*!! I thought texture mapping only meant taking a bitmap and laying or shrink-wrapping it over a surface. ... Actually a lot of my graphics knowledge is actually a bit dated. It consists of Foley, van Damme et al (ancient, I know!), F S Hill (to allow for an academic sort of mapping between Foley et al and OpenGL), and the practical OpenGL books like, e.g., OpenGL SuperBible by Wright and Sweet. Now, out of this range, only the last book talks about 3D texture mapping, but the topic is so small and hidden that I realized it is there only after you mentioned it! I also need to pick up on many other things... Now, coming back to the present thing. We can discuss it later at the Graphics forum, but just to let you know for now: The requirements could include millions of voxels (at least for the high-end, refined applications). Taking a cut through them using 3D textures is, it seems, practically not possible with OpenGL as of today. (Perhaps this is what you mean by out-of-core rendering.) Secondly, what I would like to have is customization of the interpolation--say, via a callback function facility. Third, the oblique cut could be a non-planar surface. I think the whole purpose differs. In OpenGL 3D texture, the idea is to help in rendering. What I have in mind is something more on the analysis side, but with a tighter integration with rendering as well... Alright. Thanks for your replies. I have learnt something useful. See you later in Graphics forum.
---------- http://www.JadhavResearch.info