I am in front a simple issue, but I can't find a way to solve it:
I have the coordinates of a lightning source. I would like to draw a white circle centered on this lightning source.
How can I do that? Is there a opengl function or I should add manually verteces to create a circle?
Thanks
OpenGL does not have primitives like circles. It only has triangles, fundamentally.
Your best options are either to make a regular n-gon where n is large enough to satisfy you, or make the circle geometry part of a texture, and just render a square where some of the coordinates are transparent.
Which is most appropriate depends entirely on context.
Use Blender to create a simple circle mesh. Export to one of the available object files, load it in your app and render. You can use Assimp to load the mesh or write your own loader. You can find a lot of examples online on how to do this.
How to draw a circular disc with thickness and then "drill" holes (of any shape) into it at runtime?
The desired outcome would look like CAD drawings without textures.
I am using OpenGL, but I guess this is independant of the graphics API.
I guess what you're after is Constructive solid geometry. Some current graphics/game engines (like Unreal) use it, but most don't do the real thing but approximate (fake) the results with textures or switching a solid geometry with a prepared multipart model. Another approach would involve using voxels, like Minecraft or Voxatron.
OpenCSG should do what you want.
Look into CGAL innards of OpenSCAD if you need the CSG'd geometry and not just a rendered image.
This could be an interesting use of Geometry Shaders. Take in the disc geometry and add the extra vertices for the holes and then pass to the Fragment Shader.
I have been asked to do 3D sphere and adding textures to it so that it looks like different planets in the Solar System. However 3ds max was not mentioned as mandatory.
So, how can I make 3D spheres using OpenGL and add textures to it? using glutsphere or am I suppose to do it some other method and how to textures ?
The obvious route would be gluSphere (note, it's glu, not glut) with gluQuadricTexture to get the texturing done.
I am not sure if glutSolidSphere has texture coordinates (as far as I can remeber they were not correct, or not existant). I remember that this was a great resource to get me started on the subject though:
http://paulbourke.net/texture_colour/texturemap/
EDIT:
I just remembered that subdividing an icosahedron gives a better sphere. Also texture coordinates are easier to implement that way:
see here:
http://www.gamedev.net/topic/116312-request-for-help-texture-mapping-a-subdivided-icosahedron/
and
http://www.sulaco.co.za/drawing_icosahedron_tutorial.htm
and
http://student.ulb.ac.be/~claugero/sphere/
I would like to draw a simple 2D stickman on the screen. I also want it to be anti-aliased.
The problem is that I want to use a bones system, which will be written after I would know how to draw the stickman itself based on the joints positions. This means I can't use sprites - I want my stickman to be fully controlable in the code.
It would be great if it will be possible to draw curves too.
Drawing a 3D stickman using a model would also be great if not better. The camera will be positioned like it's 2D, but I would still have depth. The problem is that I only have experience in Maya, and exporting and vertex weighting of the model in OpenGL seems like a mess...
I tried to find libraries for 2D anti-aliased drawing or enable multi-sampling and draw normally, but I had no luck. I also tried to use OpenGL's native anti-aliasing but it seems deprecated and the line joins are bad...
I don't want it to be too complicated because, well, it shouldn't be - it's just the first part of my program, and it's drawing a stickman...
I hope you guys can help me, I'm sure you know better than me :)
You could enable GL_SMOOTH. To check if you device supports your required line width for smooth lines, you can use glGet(GL_SMOOTH_LINE_WIDTH_RANGE);
If you want your code to be generic, you can also use antialiased textures.
Take a look at this link
http://www.opengl.org/resources/code/samples/advanced/advanced97/notes/node62.html
The only way to get antialiasing is use GL library which knows how to get antialiased GL context, for example, SDL. As of stickman, you can draw him with colored polygons.
I have a program in which I need to apply a 2-dimensional texture (simple image) to a surface generated using the marching-cubes algorithm. I have access to the geometry and can add texture coordinates with relative ease, but the best way to generate the coordinates is eluding me.
Each point in the volume represents a single unit of data, and each unit of data may have different properties. To simplify things, I'm looking at sorting them into "types" and assigning each type a texture (or portion of a single large texture atlas).
My problem is I have no idea how to generate the appropriate coordinates. I can store the location of the type's texture in the type class and use that, but then seams will be horribly stretched (if two neighboring points use different parts of the atlas). If possible, I'd like to blend the textures on seams, but I'm not sure the best manner to do that. Blending is optional, but I need to texture the vertices in some fashion. It's possible, but undesirable, to split the geometry into parts for each type, or to duplicate vertices for texturing purposes.
I'd like to avoid using shaders if possible, but if necessary I can use a vertex and/or fragment shader to do the texture blending. If I do use shaders, what would be the most efficient way of telling it was texture or portion to sample? It seems like passing the type through a parameter would be the simplest way, but possible slow.
My volumes are relatively small, 8-16 points in each dimension (I'm keeping them smaller to speed up generation, but there are many on-screen at a given time). I briefly considered making the isosurface twice the resolution of the volume, so each point has more vertices (8, in theory), which may simplify texturing. It doesn't seem like that would make blending any easier, though.
To build the surfaces, I'm using the Visualization Library for OpenGL and its marching cubes and volume system. I have the geometry generated fine, just need to figure out how to texture it.
Is there a way to do this efficiently, and if so what? If not, does anyone have an idea of a better way to handle texturing a volume?
Edit: Just to note, the texture isn't simply a gradient of colors. It's actually a texture, usually with patterns. Hence the difficulty in mapping it, a gradient would've been trivial.
Edit 2: To help clarify the problem, I'm going to add some examples. They may just confuse things, so consider everything above definite fact and these just as help if they can.
My geometry is in cubes, always (loaded, generated and saved in cubes). If shape influences possible solutions, that's it.
I need to apply textures, consisting of patterns and/or colors (unique ones depending on the point's "type") to the geometry, in a technique similar to the splatting done for terrain (this isn't terrain, however, so I don't know if the same techniques could be used).
Shaders are a quick and easy solution, although I'd like to avoid them if possible, as I mentioned before. Something usable in a fixed-function pipeline is preferable, mostly for the minor increase in compatibility and development time. Since it's only a minor increase, I will go with shaders and multipass rendering if necessary.
Not sure if any other clarification is necessary, but I'll update the question as needed.
On the texture combination part of the question:
Have you looked into 3d textures? As we're talking marching cubes I should probably immediately say that I'm explicitly not talking about volumetric textures. Instead you stack all your 2d textures into a 3d texture. You then encode each texture coordinate to be the 2d position it would be and the texture it would reference as the third coordinate. It works best if your textures are generally of the type where, logically, to transition from one type of pattern to another you have to go through the intermediaries.
An obvious use example is texture mapping to a simple height map — you might have a snow texture on top, a rocky texture below that, a grassy texture below that and a water texture at the bottom. If a vertex that references the water is next to one that references the snow then it is acceptable for the geometry fill to transition through the rock and grass texture.
An alternative is to do it in multiple passes using additive blending. For each texture, draw every face that uses that texture and draw a fade to transparent extending across any faces that switch from one texture to another.
You'll probably want to prep the depth buffer with a complete draw (with the colour masks all set to reject changes to the colour buffer) then switch to a GL_EQUAL depth test and draw again with writing to the depth buffer disabled. Drawing exactly the same geometry through exactly the same transformation should produce exactly the same depth values irrespective of issues of accuracy and precision. Use glPolygonOffset if you have issues.
On the coordinates part:
Popular and easy mappings are cylindrical, box and spherical. Conceptualise that your shape is bounded by a cylinder, box or sphere with a well defined mapping from surface points to texture locations. Then for each vertex in your shape, start at it and follow the normal out until you strike the bounding geometry. Then grab the texture location that would be at that position on the bounding geometry.
I guess there's a potential problem that normals tend not to be brilliant after marching cubes, but I'll wager you know more about that problem than I do.
This is a hard and interesting problem.
The simplest way is to avoid the issue completely by using 3D texture maps, especially if you just want to add some random surface detail to your isosurface geometry. Perlin noise based procedural textures implemented in a shader work very well for this.
The difficult way is to look into various algorithms for conformal texture mapping (also known as conformal surface parametrization), which aim to produce a mapping between 2D texture space and the surface of the 3D geometry which is in some sense optimal (least distorting). This paper has some good pictures. Be aware that the topology of the geometry is very important; it's easy to generate a conformal mapping to map a texture onto a closed surface like a brain, considerably more complex for higher genus objects where it's necessary to introduce cuts/tears/joins.
You might want to try making a UV Map of a mesh in a tool like Blender to see how they do it. If I understand your problem, you have a 3D field which defines a solid volume as well as a (continuous) color. You've created a mesh from the volume, and now you need to UV-map the mesh to a 2D texture with texels extracted from the continuous color space. In a tool you would define "seams" in the 3D mesh which you could cut apart so that the whole mesh could be laid flat to make a UV map. There may be aliasing in your texture at the seams, so when you render the mesh it will also be discontinuous at those seams (ie a triangle strip can't cross over the seam because it's a discontinuity in the texture).
I don't know any formal methods for flattening the mesh, but you could imagine cutting it along the seams and then treating the whole thing as a spring/constraint system that you drop onto a flat surface. I'm all about solving things the hard way. ;-)
Due to the issues with texturing and some of the constraints I have, I've chosen to write a different algorithm to build the geometry and handle texturing directly in that as it produces surfaces. It's somewhat less smooth than the marching cubes, but allows me to apply the texcoords in a way that works for my project (and is a bit faster).
For anyone interested in texturing marching cubes, or just blending textures, Tommy's answer is a very interesting technique and the links timday posted are excellent resources on flattening meshes for texturing. Thanks to both of them for their answers, hopefully they can be of use to others. :)