Jump to content
  • Advertisement

emiel1

Member
  • Content Count

    68
  • Joined

  • Last visited

Community Reputation

166 Neutral

About emiel1

  • Rank
    Member
  1. emiel1

    Gas dynamic

    As for your last question: for two particles, the attracting force is a mix of many different forces, most notably the "Van der Waals force". For most simple simulations, you don't need to worry about this. If you neglect this attracting force and model the atoms as sphere with a perfectly elastic collision, you have simulated an ideal gas, a good approximation of a real gas. The collision between the atoms is the same as between billiard balls. There are a lot of videos and websites about this, so feel free to search around. Emiel
  2. Quote:Original post by Dawoodoz Why can't I write the plus sign in this forum? You can: +. It just doesn't show in the preview window. The bug report can be seen here. Emiel1
  3. emiel1

    std::vector help!

    I don't know what the problem is: a testprogram on my computer workes fine. Let's see if changing to instances instead of pointers (KulSeran's solution) workes.
  4. emiel1

    std::vector help!

    Does the number of particles in the vector change when you are initialising the vector? Step through that function with the debugger. Is Particle *p correctly created? Check that variable with the debugger. Does any other member function of ParticleEmitter edit and/or remove entries of the vector? Are some of the entries "delete"d after they are initialised?
  5. emiel1

    std::vector help!

    Is your code the same as the code I listed. If not, please copy/paste your code again. I don't see any errors in my code. Is ParticleEmitter::ParticleEmitter() called? Emiel
  6. emiel1

    std::vector help!

    You are creating a vector with pNumParticles with this line:this->m_Particles = new std::vector<Particle*>(pNumParticles);These are created as random pointers. Then you add pNumParticles to the vector, but at the back. The first pNumParticles pointers still point to random memory addresses. You need to change the code to: ParticleEmitter.h#ifndef __PARTICLE_EMITTER_H #define __PARTICLE_EMITTER_H class ParticleEmitter { public: ParticleEmitter(); ParticleEmitter(const Vector3f pPosition, const Vector3f pVelocity, int pNumParticles); ~ParticleEmitter(); Vector3f getVelocity(); Vector3f getPosition(); void move(); void emit(); void draw(); private: Vector3f m_Position; Vector3f m_Velocity; std::vector<Particle*> m_Particles; }; #endif ParticleEmitter.cppParticleEmitter::ParticleEmitter(const Vector3f pPosition, const Vector3f pVelocity, int pNumParticles) : m_Position(pPosition), m_Velocity(pVelocity) { for (int i=0; i<pNumParticles; i++) { Particle *p = new Particle(Vector3f(100.0f, 100.0f, 100.0f), Vector3f(0.0f, 0.0f, 0.0f), 5, 20); m_Particles.push_back(p); } } void ParticleEmitter::emit() { std::vector<Particle*>::iterator particleIterator; for (particleIterator = m_Particles.begin(); particleIterator != m_Particles.end(); ++particleIterator) { (*particleIterator)->emit(); } } This includes various other changes: - Removed "this->" before every member variable (not needed) - Changed Particle::move() to Particle::emit() as the member function call in ParticleEmitter::emit() (probably what you meant) - Changed the function call to the particle constructor to fit the definition of Particle (probably what you meant) - Changed the ParticleEmitter constructor to use the member variable constructors (faster) Emiel
  7. Yes, that is correct. I'd like to make one addition though.float LastTime = 0.0f;This line sets the variable LastTime to a value close to 0.0f. The first time you'll draw your cube, you'll find that:float ThisTime = Time.Now(); float Diff = ThisTime - LastTime;Diff becomes a very large number (= equal to ThisTime, which is probably the time since the machine started). The first frametime, becomes very large and the first rotation therefore becomes very large as well. You'll be better off with this:float LastTime = Time.Now()as the first line in your code-sample. The first Diff becomes 0.0f, which results in no rotation at all, which is better than a lot of rotation. With rotation, this isn't much of a problem, because two full rotations are the same as one full rotation, but when you add frame independent translation to your program, you'll have a problem, because translation doesn't have a wrap-around point. Also, be sure to update LastTime to the current time at the end of RenderGLScene() or your cube will start to spin faster every frame. The code becomes:float LastTime = Time.Now(); float RotPerSec = 1.0f; void DrawGLScene() { float ThisTime = Time.Now(); float Diff = ThisTime - LastTime; RotY += RotPerSec * Diff; //Rotate LastTime = ThisTime; } Good luck with your programming adventure, Emiel
  8. Quote:Original post by nbaztec Is this Timer a inbuilt identity of OpenGL? No, you'll have to build that yourself. There are many ways of doing this and many tutorials to help you. For instance this one on GameDev. You can use QueryPerformanceCounter() for the super_fast_clock() function in Windows. Enough tutorials on how to use this as well. Quote:Also kindly correct me please, before entering Game Loop means during the start of Drawing the Scene but before the objects are painted right? Or it's at the start of program.? The second one is correct: at the start of the program. Quote:Thank you very much. Also what is the command for code-tag, for future. It's {source}{/source}, but with square brackets (I can't do that here, because it will replace it with a source-box). You can use {code}{/code} with square brackets, when you want to use small code samples.They will get formatted like this.Quote:But I *really* want to understand the concept behind this. :) Let's use an example: If we want to rotate the cube by 1.0 every second, and our frametime is exactly one second, then we want to rotate the cube by 1.0 this frame. If our next frame is half a second, we want to rotate the cube by 0.5 (= 1.0 * 0.5). If our next frame is 0.0125 seconds (80 frames per second), we want to rotate the cube by 1.0 * 0.0125. I hope this makes things clear. Emiel
  9. The code you posted is executed every frame. Every frame, 0.2 is added to RotY. Now, since your frame-rate varies with the size of the window, the rotation isn't always the same speed. You must now specify the rotation-speed per second instead of per frame. To calculate the amount of rotation in a frame you multiply this number by the frame-time in seconds. Add this to RotY and you'll have frame-rate independent movement. In code: // Before entering the GameLoop float LastTime = Timer.Now(); // In the GameLoop float RotationInOneSecond = 1.5f; float FrameTimeInSeconds = Timer.Now() - LastTime; LastTime = Timer.Now(); RotY += RotationInOneSecond * FrameTimeInSeconds; glRotate3f(RotY, 0.0f, 1.0f, 0.0f); Edit: This article might be interesting to read. It's the same solution, but a bit more fancy (using a targetfps so you can keep the 0.2f constant) and better written, but for translation instead of rotation. The same concepts apply though. Emiel
  10. emiel1

    Formula for spherical explosion...

    Your function pickDirection() must return a random direction with an equal probability of choosing one vector or another. The standard (and fastest) way of doing this is (I hope this correct C# code, as I code C++):float z = random(-1.0, 1.0); float f = Math.sqrt(1.0 - z * z); float azimuth = random(0.0, MathHelper.TwoPi); return new Vector3(Math.Cos(azimuth) * f, Math.Sin(azimuth) * f, z);See this post (http://www.gamedev.net/community/forums/topic.asp?topic_id=499972&whichpage=1& #3261773) (a href weirdness: remove this space in this url) for more information (warning: C++). Emiel
  11. emiel1

    What math formula to use?

    2nd degree algebra won't help much here. Exponential functions are what you are looking for: with: d = the damage of the club a = the maximum extra damage of the club b = a fraction, which defines how much damage the nails do c = the damage of the club without nails n = the total number of nails in the club Your example: gives: n=0 d=4 n=1 d=7 n=2 d=8.5 n=4 d=9.625 n=8 d=9.977 If you have any questions, please ask... Emiel
  12. emiel1

    Parsing a simple script

    After you read your '(', you know the function name and thus the function declaration. In your move you do something like this: stringstream line; // Already in your main function, just here for clarity for the stringstream string arg1, arg2, arg3; line.getline(arg1, ','); // Check for errors!! line.getline(arg2, ','); // Check for errors!! line.getline(arg3, ')'); // Check for errors!! // Note the ')' in the last function call. // Convert the arg1, arg2 and arg3 to the corresponding variable types and call move(bool, bool, int) in C++ Emiel1
  13. emiel1

    raytracing questions

    I may not know all of your questions, but I'll answer as many as I can. Quote:Q1A: How do I compute the final color using phong illumination plus reflections and possibly refractions?You'll have to calculate the diffuse, reflection and refraction colors first. For diffuse, use Phong. For reflection, just reflect the ray with the surface normal and shoot a new ray. For refraction, just shoot a new ray, from just behind the surface, to avoid a collision at t=0. Use alpha-blend to blend the colors together: Color Final = Diffuse * DifRatio + Reflection * ReflRatio + Refraction * RefrRatio;Quote:Q1B: Is there another better way to compute final material color with light other than phong?Of course there is: the Cook and Torrance model for example. This is much more difficult. To account for multiple bounces of light rays, you can use radiosity lightning, calculated beforehand. As a cheaper alternative, you can spawn secondary rays from the intersection point, to sample the color of incoming light (watch out for infinitive loops, by the way).Quote:Q2: On texture mapping. I have implemented bicubic interpolation and the textures look great when they are near but really crappy when they are far away. How can I determine the distance from which I don't need to apply bi-cubic interpolation? what filter do need to apply for the texture minification?I think your textures are not suffering from the bi-cubic interpolation, but from aliasing. You can avoid this using mipmapping. There are a lot of articles around discussing this, so I won't go in on this.Quote:Q3A: How can I compute the color of a ray passing trough volumetric densities like fog,dust smoke?You'll need to compute the point of entry and the point of exit of your ray in your volumetric shape. When you hit your volumetric shape, while raytracing, use spawn a secondary ray to look for the next material in the same direction (like you do with refraction). You also calculate the exit point of your ray. You then calculate which distance the ray had to pass through your shape (start -> object or start -> exit). You then calculate the fog quotient, using an exponential decay function: float fog = pow(Density, Distance);The result is how much of the color is the fog color.Quote:Q3B: I would like the Light to influence the final color in order to obtain "god rays". Is there another way of getting this effect?I don't know exactly how to achieve this effect. You can use volumetric fog for this, but god rays, aren't exactly that. It's more like adding a color, instead of blending two colors. You could try to use the fog algorithm, but don't blend the colors but add them together. I don't know the results of this.Quote:Q4: How can I get the glow effect?I don't know the raytracing way, but the rasterisation way can apply: just blur the glow map and blend in the results. I hope I have helped you. Feel free to ask questions to what I have said. (My longest post ever!) Emiel1 [Edited by - emiel1 on April 7, 2010 2:11:43 PM]
  14. Siggraph 2006 had an presentation on this subject. The slides can be found here. Along with some other interesting stuff, you'll find fog volumes on page 21 up to and including 25. They use Direct3D 10. I don't know if this can be coded in Direct3D 9. Emiel1
  15. emiel1

    Rendering liquids

    I was thinking of using 2D metaballs, but not triangulating them, but using the GPU to calculate the "charges". 1. Drawing precalculated textures with the "charges" of one metaball on a rendersurface with additive alpha blending. The "charges" will rise. 2. Using a post-processing effect to calculate threshold. Using this method calculates the iso-surface with pixel-precision. I don't know if this method has any major flaws. I hope someone else can comment on that. Edit: I found a reference: here. Emiel1
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!