I want to model the (biological) cell division process. I have been able to create a 3D cell model and load the model (using glm library). However, I do not know how to make it divide and I don't know where to start.
Does any one know how to make the effect that things replicate in OpenGL? (It is great if I can use glut and glm for that). Maybe you could just show me how to make a sphere replicate.
I think what you're looking for is called meta-particles or meta-balls. I think that by adjusting thresold function you can get cell-divide effect, but this isn't guaranteed - metaballs normally look more like quicksilver and are used to create water out of particles.
They're hard to implement in 3d for a novice - you'll need to be able to make triangular mesh out of mathematically-defined surface (marching cubes algorithm), and result isn't guaranteed to be fully realistic.
I suggest to try something else or use some cheaper way - draw two seme-transparent spheres on top of each other then move them apart or something like that.
Of course, certain way to get desired result is to use modeling package (like blender) and skilled artist, but displaying modeled result in your application will be difficult, because object topology will be changing every frame, plus making satisfactory result will take time and skill.
Related
I am looking for a method by which to generate 3D models for use in video games. The idea is virtual primitives that are simply points with associated data for size, shape, material and rotation.
For instance an asteroid might start as two simple spheres that intersect. Material of dusty rock which would tell the skinning algorithm to provide smooth sandy curves and occasional jagged boulders. Probably end up with a sort of lumpy peanut shape.
After that add smaller spheres with material of void or crater, peppered around the object. These would produce crater like areas in the surface of the peanut and the skin would adjust to suit. In the end you would have a semi plausible representation of an asteroid.
Now with that in mind, my question is, are there any decent open source or public domain examples of skinning algorithms that can find the surface of a model and generate a smooth, evenly distributed quad-strip mesh that could be then textured?
Some more information; I'm looking at CSG methods for the underlying models (adding and subtracting volume) then looking at other methods for remeshing the whole thing.
Skinning is an art more than a scientific process (and so almost impossible to automate) because skinning is a visual approximation of movement. To get something fully automatic, you would either have to assume bone placement or simply assume there are none at all.
Here's an example. This is an open-source project that skins automatically based on the fact that the provided mesh is a humanoid.
http://igl.ethz.ch/projects/fast/
EDIT: Wait, you mean the other way around? Isn't that similar to marching cubes? http://en.wikipedia.org/wiki/Marching_cubes
This is an exciting question and no doubt there are many ways it could be done. Personally I'd probably start by getting basic shapes on .obj format, which is easy to both parse and create programmatically, and then do exactly that in my code: tweak or randomize the the vertices you export from a modelling program to create an infinite variety of similar but slightly different objects, like asteroids. Of course if you need more than asteroids, you'd go back to a different .obj file. It's hard to say the best technique for your case since I think some experimentation would be required no matter what you try.
I was wondering, I have an algorithm of mine that I want to test with a high poly-count model. (I'm using a hard coded cube and surface atm). I know you can draw objects with the GluSolid* commands.
But the problem is, for my alogrithm I need access to the coordinates of the triangles the object consists of. Is there an easy way to access these, or is that not possible?
I think there's not really an easy way to obtain these coordinates as they are just sent to the GL when calling these functions (you might use transform feedback, but that is definitely too cumbersome for your purpose). But these primitives are actually quite simple. You can quite easily generate a sphere or cylinder mesh yourself. Or write a small function for reading a common 3d model format (OBJ is quite common and easy to read), so you can search the web for models or create test models with your favourite modeling software.
I am learning opengl es and am planning to make a program which will have a shape which can be cut into a smaller shape by removing a part of the shape dynamicly. The constraint is I must be able to tell if an object is inside or outside the cut shape.
The option I thought of are:
1) use a stencil buffer made up of just a black and white mask. This way I can also use the same map for collision detection.
2) the other option is to dynamicly change my mind renderd primitive an then tesselating it. This sounds more complex and is currently my least favorite option. It would also make the collision detection more difficult.
PS
I would like the part of the shape removed to be fall of in animation, I am not sure how choosing any of these methods will affect the ease of doing so. Please express your opinion.
What are your thoughts on this?
Keep in mind that I am new to opengl an might be making mistakes without realizing it.
Thanks, Jason
It is generally considered a good idea to issue only write-commands to the graphics card. Basically that is "dont use glGet* commands at all", because the latency of those commands might be somewhat high.
That said option 1) is great if you just want to mask out stuff. As you are trying to make the cut part fall off this is really not an option, as you have to retrieve/reconstruct the vertices of that part.
I don't quite get the "tesselation" part of your second option, but if your primitive is a polygon and your cuts are straight lines, it is easy to calculate the 2 polygons after the cut. In fact the viewport clipping routine in OpenGL does that all the time and there is a lot of literatur, for example http://en.wikipedia.org/wiki/Sutherland-Hodgman
In the long term it is often way better to first build a (non-visual) model of what is going on in the application before visualizing.
Just learning the basics of OpenGL for a class and was looking for something challenging and interesting to try and draw. Any suggestions?
Aiming to photorealism (just plain models, lights, materials, textures, etc.) is one thing, but what is even more interesting in my opinion is demoscene and all kinds of non-photorealistic effects. The idea of a demo is to program some nice animated graphics that automatically change from one effect to another or tell some sort of a story, and have a background music. Here you can find some videos. Just take a look at what some others have done and use your imagination. That's the funniest part of 3D programming in my opinion. Of course what you'll first program would be something extremely simple when compared to those videos on youtube, but everyone has to start from somewhere. Simple also doesn't need to be ugly. Some random suggestions:
mathematical shapes with sin(), cos(), etc.
alpha blending, especially addition blending (glBlendFunc(GL_ONE, GL_ONE);)
terrain rendering
read 3d model data from a file. (Wavefront .OBJ is a relatively simple one)
feedback effects with glCopyTexImage2D, which copies pixels from screen to a texture (in real life you shouldn't use this because it's too slow, but when learning the basics it's ok)
etc...
You might consider building an OBJ viewer. You will get the experience you're looking for, and it's a pretty good project for a beginning 3D graphics programmer, in terms of difficulty.
I believe opengl has built in shapes such as a teapot that you can call and have it draw. For starters, I'd stick with easy shapes like squares, circles, and cones. Try drawing a wireframe model first since that's the easiest, by using either quadstrips ,triangles or just poly lines. After you've gotten that down, learn to set up lighting and materials so you can draw a solid model.
At school we had a very interesting assignement to get started with OpenGL that I will share. The long term goal was to modelize a living room so you basically have to draw:
A table.
Two chairs.
A carpet.
A sofa
Some stuff that you might find interesting to add on the table for
instance a TV!
When you have all the things done, try to polish the scene a little bit by adding some lighting effects!
Hint: for all the objects you simply need to start with a basic rectangle. Then you can construct your scene step by step using translations/rotations.
I am working on a 2d game. Imagine a XY plane and you are a character. As your character walks, the rest of the scene comes into view.
Imagine that the XY plane is quite large and there are other characters outside of your current view.
Here is my question, with opengl, if those objects aren't rendered outside of the current view, do they eat up processing time?
Also, what are some approaches to avoid having parts of the scene rendered that aren't in view. If I have a cube that is 1000 units away from my current position, I don't want that object rendered. How could I have opengl not render that.
I guess the easiest approaches is to calculate the position and then not draw that cube/object if it is too far away.
OpenGL faq on "Clipping, Culling and Visibility Testing" says this:
OpenGL provides no direct support for determining whether a given primitive will be visible in a scene for a given viewpoint. At worst, an application will need to perform these tests manually. The previous question contains information on how to do this.
Go ahead and read the rest of that link, it's all relevant.
If you've set up your scene graph correctly objects outside your field of view should be culled early on in the display pipeline. It will require a box check in your code to verify that the object is invisible, so there will be some processing overhead (but not much).
If you organise your objects into a sensible hierarchy then you could cull large sections of the scene with only one box check.
Typically your application must perform these optimisations - OpenGL is literally just the rendering part, and doesn't perform object management or anything like that. If you pass in data for something invisible it still has to transform the relevant coordinates into view space before it can determine that it's entirely off-screen or beyond one of your clip planes.
There are several ways of culling invisible objects from the pipeline. Checking if an object is behind the camera is probably the easiest and cheapest check to perform since you can reject half your data set on average with a simple calculation per object. It's not much harder to perform the same sort of test against the actual view frustrum to reject everything that isn't at all visible.
Obviously in a complex game you won't want to have to do this for every tiny object, so it's typical to group them, either hierarchically (eg. you wouldn't render a gun if you've already determined that you're not rendering the character that holds it), spatially (eg. dividing the world up into a grid/quadtree/octree and rejecting any object that you know is within a zone that you have already determined is currently invisible), or more commonly a combination of both.
"the only winning move is not to play"
Every glVertex etc is going to be a performance hit regardless of whether it ultimately gets rendered on your screen. The only way to get around that is to not draw (i.e. cull) objects which wont ever be rendered anyways.
most common method is to have a viewing frustum tied to your camera. Couple that with an octtree or quadtree depending on whether your game is 3d/2d so you dont need to check every single game object against the frustum.
The underlying driver may do some culling behind the scenes, but you can't depend on that since it's not part of the OpenGL standard. Maybe your computer's driver does it, but maybe someone else's (who might run your game) doesn't. It's best for you do to your own culling.