View Full Version : A General 3d Visualization Question
10-28-2007, 01:45 PM
Me and some of my friend are planning to build a molecular visualization and editing tool that will also display the structure of the molecule on the screen (consider it as a some kind of graph structure with many verticez (say N) and usually somewhere between 3-4N edges if we consider organic molecules which are usually the large ones).
I was planning to use PDL (perl data language, because I know perl most extensively among all other languages) which has an opengl extension and can handle large calculations sufficiently well. How ever some people that I asked for advice told me that perl might not be the best choice since its main intention is not graphics. And also it may not be as interactive as I would wish it to be (editing the molecule through the window).
My question is would you think using opengl through perl would satisfy my needs or would you propose a better alternative? And also what is the difference in opengl if I use it via C++ or via Perl or other languages.
To get the project going as fast as possible I have chosen the language which I know the best (perl) but ofcourse in the end it will be problematic I will change it. My second preferance would be java, and if not so willingly third would be c++ or c.
Thanks in advance for any advice...
10-29-2007, 01:04 AM
Use the language you feel most comfortable with -- take the path of least resistance.
One of the great aspects of OpenGL is that there's a binding for almost every language under the sun.
10-29-2007, 12:28 PM
Thanks, so what would be the differences of using opengl from perl and from c++? I suppose from your words that the language of choice does not heavly alter the capabilities of opengl?
10-29-2007, 12:40 PM
The capabilities will be the same, as it is the same graphics card and driver being used. With perl you will most likely get slower performance. Still, as your triangle counts are pretty small (for modern computers) and you want an interactive application, performance won't be a factor. If you know perl well, go for it.
10-29-2007, 02:48 PM
I get the part about triangle counts, but the following?
"and you want an interactive application, performance won't be a factor."
How would wanting an interactive application cause the following condition?
As for triangles probably putting them on screen wouldn't ask for much performance true. But could their simultenous rotation, displacement etc around the space be a problem? How much really is the performance difference when using c++ and perl.
I am being very cautious about this particular issue because I have seen molecular modelling tools where it is a real pain to rotate molecules. Ofcourse we are talking about large biomolecules here with say 2000 vertices. If we consider spheres of at least 20 triangles for each their transformations around the space could be a problem?
10-29-2007, 04:21 PM
Interactive applications spend most of their time waiting for user input, that is how I meant it. This is why it is generally possible to sacrifice performance here. The performance is fine as long the program can responce smoothly to user's input(it doesn't really matter if you run 400 or 50 FPS here). As for vertex count... 2000 is not much for today's standart (or are you going to render each vertex as a sphere? then it could be a problem). The trick here is to use GL API effectively. You have to avoid unnesesary calls to the API. Best of all would be if you make a display list (or even better, a VBO - no idea how it works with perl). By offloading the geometry to driver memory you will save CPU time. It is even possible that with large models your perl performance will be on pair with C++.
My advice: put a small sirty testing app together that would renders something similar to the molecules you want. If the framerate is good, stick with perl. If no, maybe you should try Java or C++ (Java's performance should be pretty close to C++, maybe 80-90%).
10-29-2007, 06:50 PM
I am planning to use spheres. Well 2000 vertices is a about somewhere between average and worst case. Worst case is would be something like 10000 I suppose. This applications interactivenes requires extensive computing though because when the user wants to rotate the whole molecule, I will need to do lots of operations with transformations matrices to rotate the whole thing all together... And is there any source (book etc) that could rather than teaching opengl, teach tricks about performance like using paralel algorithms (or what you just said) to make best use of the sources... I will then try a test before I make my final decision thanks...
10-29-2007, 07:12 PM
when the user wants to rotate the whole molecule, I will need to do lots of operations with transformations matrices to rotate the whole thing all together...
// call your display list or VBO of the molecule here
It does not look like a slow path, even with perl bindings : your main loop would have very few calls.
If you wanted to simultaneously show rotating atomic bonds and temperature cinetic energy it would be a different problem.
But as you describe it, once you are done with building the molecule, the geometry does not changes, so it will be fast.
10-29-2007, 07:26 PM
Yes, the program's main intention is to display the molecule and be able to edit it (not to run any chemical or structural calculations on it). If by simultanous showing, you mean while the user holds the mouse button and drags it on the window, the molecule rotates on the graphics window simultaneously, yes I will need that. Because I not yet accustomed to opengl, I am not sure what that code you put does though.
10-29-2007, 07:36 PM
It does what I quoted from your post. With comments :
// select modelview matrix (the other one is the projection matrix)
// set matrix to identity (clears it)
// multiply current matrix by rotation matrix : 'mousex' degrees around the x axis
// same, around the y axis
// draw stuff
// call your display list or VBO of the molecule here
You have a bunch of doc pointers in the OpenGL SDK (http://www.opengl.org/sdk) section of the site.
Take a look at the OpenGL wiki page on transformations (http://www.opengl.org/wiki/index.php/Viewing_and_Transformations)
11-02-2007, 12:39 PM
Ok thanks, here comes another question.
If I were to write this in c++, I would need something more "humane" than c++ to write its graphical user interface. I am not planning an extremely compliacted interface menu. But when the user clicks a button on the menu, the program should be able to change something in the opengl window (like deleting an object or making a difference in the coordinates etc). Would GLUT be good enough for that, or should I be using C#?
11-02-2007, 03:02 PM
FLTK is a good and simple toolkit to control OpenGL windows with GUI, it seems appropriate for your goals. It even has a GUI editor.
GLUT only has support for very simple popup menu and submenus.
Tutorial here :
Nicolai de Haan
11-02-2007, 05:15 PM
I think you will be doing yourself a favor by choosing a language such as Java that comes with an extensive platform-neutral API for building GUI. You can be up and running in less than 50 lines of code. I suggest you take a look at https://jogl.dev.java.net/ and http://www.lwjgl.org. The performance difference between C++ is negligible and can swing both ways these days with JIT compilers. What is much more relevant for performance, than your choice of programming language, is that you use the OpenGL API sensibly and that is language independent. Thus it's a matter of choosing the programming that you're most comfortably in and offers the most advantages. I have no experience using Perl bindings for OpenGL.
Nicolai de Haan Brøgger
11-03-2007, 01:25 PM
Okay thanks, I will certainly consider these two suggestions before choosing c++ or java.
And just where can I get more information about different types of compilers? That issue has always been a mystery to be, I write both my perl and java scripts in command window and compile it from there. By compiler do you mean those that come with the language development kits like JDK or there are other programs that can carry out compilation more sufficiently. I have seen many compiler programs for c++ but never used anything other than command window for java and perl though I know there are...
11-03-2007, 03:17 PM
Don't worry about compilers, the Sun Java SDK compilers and JVM are actually good nowadays.
Use Java 1.6, it does really speedup a lot of things. If you code correctly, you will have few OpenGL calls from Java, and that is what counts most. Java should not be your bottleneck.
Anyway who cares about compiler ? You should care about a good IDE.
For Java, if you use anything less than Eclipse, you are wasting a lot of time.
For C/C++, I do like Dev-C++, it has a bunch of sample programs for GL, downloadable from the IDE itself. You can also use the MS suite, but I find it painful.
11-03-2007, 04:15 PM
I agree on the part of MS suite being painful. Quite painful. I will see out ecplise and Dev-C++... This issue as to whether choose java or c++ is killing me though (atleast I got rid of perl option). Some say java shows %80-90 performance of c++, some say it is an extremely bad choice for graphical programs. I think I will just contact people who have written such tools with java before I make my decision (thanks to nicolai for the library sites, where I have found some such programs). I will report back what they said to here for future reference to other people :p
11-03-2007, 04:55 PM
+ loads and loads of tutorials and code, samples, etc
- well, dirty code
+ clean object oriented
- really fewer samples and tutorials
JOGL seem well alive and kicking :
You may try these demos, especially the "Vertex Buffer Object" one, (even if in your case, the geometry will be static, so it will be potentially much faster) :
If I where you I would probably start the Java route.
EDIT: I just tested the VBO sample, with the convenient WebStart, it is really fast. Go java :)
11-07-2007, 02:32 PM
An opensource project for (nice looking) realtime visualization of molecules :
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.