I am using FreeGLUT to make a 3D engine for my future games, purely because it is easier to deal with than modern OpenGL, the intention is to be a simple engine that has similar features to the IDTech1/ACKNEX-3/Build Engine.
Until now I have been using a projection matrix like any normal 3D engine, consequently the 2.5D engine look that is targeted is not achieved, especially when rendering sprites on the map as the player looks up and down, they distort instead of keeping the straight proportion.
To mitigate this, instead of just locking the camera so that the player can't look up and down, I decided it was better to try to replicate the y-shearing effect that the old engines had to disguise the "true 3D" projection.
Unfortunately, I have not found any material on methods to help me do this, is it not possible to replicate such an effect in GLUT?
"True 3D" projection / 2.5D projection with y-shearing (desired):
Related
I have worked to develop a GPU-based underwater imaging sonar simulation for real-time applications (see more details in my last paper). The mission part is the reverberation phenomenon, that can be represented by a multipath algorithm.
This work uses precomputed information (normal, depth and angle) during rasterization pipeline using shaders in order to calculate the simulated sonar data, however, this way is restricted to primary reflections. So I need to take account the secondary reflections. Could ray tracing be used only for this part, in a hybrid pipeline (rasterization and ray tracing)?
I hope I can help!
With raytracing, in order to calculate secondary reflections you normally need to first calculate each ray's primary reflection, and you then recursively shoot off another ray from that position. I guess you could skip the first reflection part of raytracing if you can use you shader results to figure out where each ray starts and in which direction it should reflect. You could shoot your rays out of the pixels in the shader's result, using depth information, pixel coordinates, and camera parameters to figure out where the ray's origin is, and using normal information to figure out which direction the ray should go in.
From looking at your project's paper, I think raytracing would be a very useful tool for this project, and I wonder if it might be better to just go for a full raytracing approach to simplify the process. Why exactly do you want to do the primary reflections through shaders? I would recommend looking into nvidia optix, which performs raytracing on the gpu, and looking into global illumination techniques in order to calculate reflections off of all objects in the scene. Global illumination techniques also take into account the fact that surfaces are not perfectly smooth without the use of normal maps, as mentioned in your paper, by using monte carlo integration.
I hope this helps, if you would like me to clarify anything or have any other questions feel free to ask!
I'm interested in trying to create realistic fluids (water), for a 2D game. This game is similar to Terraria. I have heard about how you can slap a bunch of colliding particles on the scene and render over it and voila, realistic acting water.
Terraria uses tile based water, which I am not a fan of.. I want something more advanced.
I thought about using bullet 3D physics (box2d has limits I would hit). For non colliding particle effects, I am thinking about using something like SPARK, since I think that'd give me the best of both worlds.
The issue I am thinking about, is that each block is 16x16, so on a 1600x900 scene, there are about 5 thousand tiles.
So I need to tell the physics engine that these tiles are collidable. Of course, there are void tiles that are considered to be non collidable.
Does anyone have ideas on this? Language is C++, I doubt that's relevant though.
EDIT: i think i'm going to have to cave in and use grid based water. I suppose, in retrospect particle based just makes everything more difficult but for what gain?
Your question is about tiled fluids, but you seem to actually be asking about a particle based approach.
If that's the case, what you're looking for is "Smoothed Particle Hydrodynamics", or SPH, which is a very popular technique for 2D and 3D fluid simulations in realtime situations.
Yes, it's basically just a particle system, with each particle responding to the forces in your environment (gravity, collisions etc.) in a reasonable (mathematically stable) way, combined with a constraint that they must stay a certain distance apart in order that the fluid is incompressible.
You can render the particles as points, if you have enough of them, or you can use them as a source for deriving a surface (for example using marching-cubes, though in 2D I wouldn't worry about that).
http://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
It has the advantage of being relatively easy to code, and indeed to accelerate on a GPU.
Indeed I think they're probably a better approach than trying some kind of tile-based approach, and you get some more interesting results, such as spray kicking up, waves kicking against the edges of objects, etc. It's not too hard to get something pleasing working, I'd give it a go.
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.
Let i have some mesh (for ex. sphere) in the center of room, full of cubes and one light source. How can i make fast and easy shadow-casting in OpenGL, using "standard" (fixed) functions only? Note: the result must contain cube and sphere shadows as well.
If you can generate a silhouette of the sphere then you could use shadow volumes. nVidia hardware has also supported fixed function shadow mapping for a fair while as well.
Shadow volumes have the disadvantage of very high fill rate requirements. Shadow maps can be better but require an extra pass.
If you are projecting on to a single plane it may well be easier to just project the object on to a plane.
There is no fast and easy way. There are lots of differnt techiques, that each have their own pros and cons. You can look at a project I host on github, that uses very simple code to create a shadow, using the shadow volume technique (http://iuiz.github.com/VolumeShadow/). However it is written in Java, but it should not be hard to port it to any other language.
The most important ways to create shadows are the so called "shadow mapping" method, where you render your scene (with the camera at the light source, directed to each shadow casting object) to a texture. And the second technique is the shadow voulume method (made famous with Doom3).
I've found one way using StencilBuffers. Being a little confused for a while, i finally got the idea - whith this the most hard thing would be looping through each light source and projecting all scene objects. This one looks more pretty than texture shadowing and works faster than volumeric shadows. here and here are some resources, which helped me to understand matrix multiplication step (it confused me a bit when i was looking through dino demo). As for me, this method is most easy to understand and use. The only question left to solve is how to calculate multiplication matrix.
Although this method could be changed a bit using textures as shown here.
Thanks everybody! =)
I am building a game and the main character's arm will be following the mouse cursor, so it will be rotating quite frequently. What would be the best way to rotate it?
With SDL you have a few choices.
Rotate all your sprites in advance (pre-render all possible rotations) and render them like you would any other sprite. This approach is fast but uses more memory and more sprites. As #Nick Wiggle pointed out, RotSprite is a great tool for generating sprite transformations.
Use something like SDL_gfx to do real-time rotation/zooming. (Not recommended, very slow)
Use SDL in OpenGL mode and render your sprites to primitives, applying a rotation to the primitives.
Option 3 is probably your best bet because you gain all of the advantages of using OpenGL. It's really up to you how to want to do it. It's also a possibility that you can load your sprites, perform all rotation calculations with SDL_gfx and then save the rotated versions to an SDL_Surface in memory.
EDIT: In response to your comment I would recommend checking out Lazyfoo's SDL tutorials. Specifically, this one about rotation. There is also an OpenGl function, glRotatef, which can be useful in your case. A quick search brought back this little tidbit which could also be helpful.
SDL_RenderCopyEx()
has extra arguments for rotation, flipping, and the rotation center.
You can use a library like SDL_gfx