• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

106 Neutral

About HamiltonLagrange

  • Rank
  1. Perhaps I came on a little too strong. Bregma and alvaro, I appreciate your input, I wasn't trying to belittle any of what you were saying. I hope it wasn't coming across that way. I realize that the two of you are brilliant programmers with probably significantly more experience than I have.
  2. [quote]Yet another link to Wikipedia: The field is called [url="http://en.wikipedia.org/wiki/Machine_translation"]Machine Translation[/url]. [/quote] Cool! Other people have been talking about this kind of thing! This makes me happier. [quote]I think natural language parsing is hard. Very hard. Consider for example, the sentence "Mary can stick the stamp on herself." Good for Mary that she doesn;t need help, but will she not end up all sticky? Or, for another example, consider "Time flies like an arrow; fruit flies like a banana." [/quote] Yep, it would be a very tough problem, but it would be a particularly useful one to solve. But that [url="http://en.wikipedia.org/wiki/Electronic_discovery"]e-discovery[/url] software seems to do something very similar... Even an approximate translation would be better than what we have. [quote]Or, maybe we could just outsource the law to countries where lawyers are paid starvation wages in sweatshops. Our laws would be crap but we could get it cheap and we could wear our sweats to court. [/quote] Another brilliant business plan... allowing foreign lawyers to create our laws for us, "Taiwan owns USA by definition, here see: Article 15 Sec 13.24.5553." I hope nobody EVER decides to actually DO that. I don't believe you're being serious with this suggestion, but the sad thing is that I could imagine some half-baked business plan that revolves around outsourcing your Country's laws to another country, not even thinking about the security problems it would introduce... That could make a really interesting Douglas Adams - style plot.
  3. Alvaro! Yes, you're right. Compilers translate your source code into a binary which is a set of instructions for a computer to follow. It takes a High level language (like c++) and converts it to a lower level language (like Assembly language). [url="http://en.wikipedia.org/wiki/Source-to-source_compiler"]Transcompiler[/url] refers to the fact that you are translating from a High level language to another High level language. Something that translates between human languages would do precisely this.
  4. Hi! It's been awhile since I've been on this forum. I had an idea which I think would be a really useful tool for people to use. I don't know how many of you have tried to sit down and read real legislation, but, it's really dense, difficult to understand, and even if you know what the individual words mean, trying to interpret their real meaning, in full, understanding their loopholes, weaknesses and problems, is one heck of a feat! Normally, before one can really understand the way that laws are written, you need to have had training as a Lawyer... but these days, that training requires you to fork out close to $100,000-$400,000 total before you can complete that training, once they make it out of that training, most people find that they have dismal job prospects. We have this concept in computer science of a transcompiler. It's simple, you take something that is written in one language and you transcribe it into a brand new language. An example of this is "f2c", which translates fortran code to c. We have AI programs which attempt to understand human language in all of it's subtleties. There even exists e-discovery software, which can read and analyze legal documents, in a fraction of the amount of time that it would take for a human being to do it. It's used as a legal tool in court cases... I was thinking that one could actually write a transcompiler for the hybrid of English and Latin, which is our Legal-lexicon, and common English. Knowing that laws come out every day written in this speech that most people can't really understand is a real problem. Software like this could fix that problem, particularly if it was paired with an analysis tool that can summarize points, gists, etc... What do you folks think?
  5. [quote] Ask yourself this: If you were a skilled developer, would you invest your time(which is equivalent to money for any developer with atleast a reasonable amount of skill) into a project lead by a complete stranger who isn't confident enough in the project to put his own money on the line ?[/quote] Good point. Although one runs into a snag when you realize that even the surest bets that you can think of are still unpredictable. Case in point: Shenmue; it cost it's company $47 million to make, every owner of a Dreamcast would have needed to buy 2 copies of Shenmue for them to make a profit on it (of course, they were betting on being able to turn it into a trilogy). Also please don't let this naysaying deter you at all, I'm just voicing my fears. [quote]That said, a revenue share model can work if you can find the right people to work with, Your friends are your best recruitment base for this as they know how good you are (And you know how good they are). It is far easier to convince people who know you that you can pull this off than it is to convince strangers on the internet. [/quote] This makes sense. Where I'm at, I should be able to find someone, maybe. [quote]I did not make those models. They came from the site above.[/quote] Whoops, I should have noticed that immediately! [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] [quote]It helps if you can communicate to artists and musicians in their own language, and the more you know the easier it is to climb the ladders. As for skills that are recommended as “second majors” I would suggest firstly game design. Having a good sense of what makes a good game makes you good at your job. That applies to everyone, not just the programmers.[/quote] Much of this just takes interest and practice, I suspect. If I were in the industry, I'm fairly certain that I'd want to stay in the industry. Thank you, both of you, for your advice.
  6. [quote]What i'm doing is: I'm not hiring anyone to start with, artwork will provided by one freelance artist (who will get payed for delivered content), same with music and possibly sound effects. Everyone(except me) will get payed in full regardless of how the game does financially. (Yes this means i have been forced to work normal jobs for quite some time to save up cash for this project).[/quote] Isn't that a little risky? This means that if what you design turns out to be a flop that you'll eat all of the cost and derive very little of the gain... you might have to default back to the normal job again just to raise enough money for your next project. Of course; if you succeed in a big way, you may find yourself in fantastic shape. How much do you expect to spend on the project? Does the percentage of profits based model not work very well? Thank you for your time and your input, Simon.
  7. Beautiful... clearly you are talented. "The Cat" was one of my favorites on there. It reminded me of "Jungle Landing" from Myst IV. Thank you for sending me the reference, Matias is very good. I'll need to generate some capital before I can use any of his work. ;) Apart from the gameplay, I believe that the music and the atmosphere are the most important aspects that allow a game to draw the players into your world. You built those models too? Based on what I've read, creating life-like humans is one of the most difficult aspects of model building. Given a camera, a tripod, a blue backdrop, and some tape, there are a couple of 2D->3D transformation algorithms which could be used to cheat, I think. Did you write the ray tracer yourself? What did you use to create the models? Did you create your own model building interface for the L. Spiro Engine? To summarize: you play the piano; you're a good composer; a good modeler; a great programmer; you're at the very least bi-lingual; and you're an example of what it takes to be a professional in the industry. You're more specialized as a programmer, I think; but is this what is required to be a member of the industry? To be competent at everything that is related to building games? L. Spiro, thank you very much for your input, I've gained a lot from your response. --- It is only through honing ones skills on great derivative work that you can become something more than derivative yourself. ---
  8. That design actually looks pretty similar to what I did for a small text adventure project that I worked on a while back. I suppose that it would depend on how you handle it... what kind of a game is it? Will it have graphics? How do you handle events in the game? If something in a room changes, how do you keep track of that? I can tell you how I handled the text adventure: (1) There was a parser and an interpreter. The parser's job was to take the information supplied by the user and break it into distinguishable commands. It viewed things as: "command" "description" "object" for 3 inputs, or simply "command" "object" for 2 inputs. First it took the command and compared it to the list of legal commands. Then it would take information from an object library that I created. Each object would have characteristics that described it: Is it a "place" or a "thing". If it's a place, then places have several commands which are legal such as: w "west", n "north", s "south", enter, etc. Objects also have legal actions associated with them. If something is legal, something logical happens which causes the player to interact with the environment. (2) The interpreters job was to handle exceptions and actions for generalized behavior such as; what options are set that change the game behavior? The parser sent information to the interpreter, which the interpreter used to communicate with objects to figure out what to do. Mine was a very simple model. My parser wasn't as sophisticated as Zorks, and this design had a few problems with it. Every time I created a new room, I had to specify the specific behavior of the room every time. But for a simple model it worked pretty well. I was proud of it. I ended up scrapping what I was doing 2 times before I settled on the model I described above. (I was also just learning how to program for the first time back then)
  9. Thank you for your response, Simon. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] What is an intelligent way to go about recruiting or hiring an artist? Seeing that I have very little capital with which to work at the moment; is it a good idea to promise fractional royalty for any real profit? Ok, so assuming that you have 1 programmer, 1 artist, and one composer who produces a game (my idea of a "dream team"). If the original idea for the project is the programmers, what is the smartest way to divide the profit? Would a democratic 33.3% for each be reasonable; or is the amount of work unequal for each role? According to this website: [url="http://www.allartschools.com/art-careers/game-design/video-game-design-career-outlook"]http://www.allartsch...-career-outlook[/url], the different roles are broken down by how much they're paid. So, would it be wiser to determine fraction of royalties based on the roles actually fulfilled by the people working on the project? How would you factor experience into this equation? After reading more of the FAQ's, I realize that many of my questions are historically redundant; hence, I edit my post... as many times as it takes, I hope that's alright. Would anyone be interested in providing their experiences working for small game companies?
  10. Where can I find assets for games? I'm looking for models, errant source code, music, sound, etc. For those who produce models; I know that many use Blender to produce models on their own. Where can I find other people's models that are free? For sounds, I know that libraries exist; are there any that are public domain; free? I can program. I can create a game engine, I'm looking for material that can fill the game that I make with substance. Do most people who work on these projects on their own just produce their own models, music, and sound? Is it some kind of a faux-pas to ask about material like this? If you can answer these questions, I would be grateful.
  11. I see. I apologize, I didn't realize that it was decompiled. I was under the impression that I was look at the original source code. My comments were made based upon what I had in front of me. It's not elf magic; you're right, it's merely a useful way to handle PDEs.
  12. Hey! That thing is really interesting! I think I'll play with it after I finish my homework. Thanks!
  13. Ok... here goes: To solve the Navier Stokes equations; which represent a continuum, one must find a way to discretize it with a mesh or a grid, in which case, it's no longer a continuum. A couple of Astrophysicists back in the 80's figured out a way to treat the fluid as a bunch of particles that behave in a fluid-like way. This is really nice because you don't have to mesh the thing. (Which is a pain.) The key things to know when dealing with SPH is that each property of the fluid is held in the particles: every particle has mass, viscosity, density (weird, I know), velocity, position and any other property which is represented in the equations. Each property is calculated based upon a weighting function. The weighting function for every particle is a function of the difference in the distance from particle p, and every other particle, over a smoothing length. g_p(x,y) ~= f(x',y', h) // Steps in SPH: // (0) Initialize all variables. Apply Boundary Conditions. // (1) Solve for density for all particles // (2) Compute pressure from an Equation of State // (3) Calculate Viscosity from Energy Equation. // (4) Take all calculated quantities and plug them into the // momentum equation, get the Accelerations of the particles. // (Get Force) // (5) Use Acceleration in time integration to get positions and velocities. // (6) Send to rendering pipeline then repeat steps 1-5. I've annotated the java code where I recognize structures. This fellow didn't explain what they did very well at all. We learn a lesson from this: Comment your code, so that the next poor fool who reads it doesn't feel the need to wet themselves. [code]// forked from zlaper's Liquid simulation //Is this demo using MPM algorithm? //What are the node's m, d, gx, gy, u, v, ax and ay variables? //What are particle's x, y, u, v, dudx, dudy, dvdx, dvdy, cx, cy, px[3], py[3], gx[3] and gy[3] variables? //What are the phases in the liquid simulation? What happens and in what order? What are some of the fluid dynamics functions that are used in each chunk? //Where are the code chunks that control the viscosity, smoothing, elasticity and gravity? If they don't exist, how to add them? // This looks like SPH. // m is mass, d is density, gx and gy... weighting function. // u - velocity in x, v - velocity in y // ax - acceleration in x, ay - acceleration in y // dudx --> du/dx, dudy --> du/dy // cx --> speed of sound in x dim, cy --> speed of sound in y dim // px --> pressure in x, py --> pressure in y // Steps in SPH: // (0) Initialize all variables. Apply Boundary Conditions. // (1) Solve for density for all particles // (2) Compute pressure from an Equation of State // (3) Calculate Viscosity from Energy Equation. // (4) Take all calculated quantities and plug them into the // momentum equation, get the Accelerations of the particles. // (Get Force) // (5) Use Acceleration in time integration to get positions and velocities. // (6) Send to rendering pipeline then repeat steps 1-5. package com.jasonpeinko.liquid; import java.util.ArrayList; import com.badlogic.gdx.Gdx; import com.badlogic.gdx.Input; import com.badlogic.gdx.Input.Buttons; import com.badlogic.gdx.graphics.GL10; import com.badlogic.gdx.graphics.Texture; import com.badlogic.gdx.graphics.g2d.SpriteBatch; import com.badlogic.gdx.graphics.glutils.ImmediateModeRenderer; import com.badlogic.gdx.math.Vector2; public class Liquid { boolean mousePressed = false; int mx,my = 0; int mxOld,myOld = 0; Vector2 mVec; private static final float TICK = 1/60.0f; private ArrayList<particle> particles = new ArrayList<particle>(); private int gsizeX = 160; //200 private int gsizeY = 150; //150 private float accum = 0.0f; private Node[][] grid = new Node[gsizeX][gsizeY]; private ArrayList<node> active = new ArrayList<node>(); private Material water = new Material(1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f); //Only the first parameter is used - Material.m ImmediateModeRenderer renderer; Texture texture; Texture texture2; SpriteBatch batch; public Liquid() { mVec = new Vector2(0,0); init(); } public void init() { int i, j; for (i = 0; i < gsizeX; i++) { //The grid is created for (j = 0; j < gsizeY; j++) { this.grid[i][j] = new Node(); } } Particle p; for (i = 0; i < 100; i++) { //10,000 Particles are spawned for (j = 0; j < 100; j++) { p = new Particle(water, (i) + 4f, (j) + 4f, 0.0f, 0.0f); particles.add(p); } } //System.out.println("Particles: " + particles.size()); //Print the quantity of particles renderer = new ImmediateModeRenderer(); texture = new Texture(Gdx.files.internal("data/water.png")); texture2 = new Texture(Gdx.files.internal("data/node.png")); batch = new SpriteBatch(); } public void render() { //Input mxOld = mx; //The MousePos on the previous frame myOld = my; mx = Gdx.input.getX()/4; //The current MousePos my = Gdx.input.getY()/4; mVec.set(mx-mxOld, my-myOld); //System.out.println(mVec.x + "," + mVec.y); //Print Force vector if (Gdx.input.isButtonPressed(Buttons.LEFT)) { mousePressed = true; } else mousePressed = false; accum += Gdx.graphics.getDeltaTime(); while(accum >= TICK) { accum -= TICK; simulate(TICK); } batch.begin(); //We render stuff for (int i = 0 ; i<grid.length; i++)="" {="" we="" don't="" render="" just="" particles,="" but="" part="" of="" the="" grid="" as="" well="" for="" (int="" j="0" ;="" j<grid[i].length;="" j++)="" if="" (grid[i][j].active)="" only="" active="" nodes="" are="" drawn="" batch.draw(texture2,="" i*4,="" j*4);="" }="" (particle="" p="" :="" particles)="" batch.draw(texture,="" p.x*4,="" p.y*4);="" particles="" and="" grid-nodes="" will="" be="" with="" a="" multiplier="" 4.0x,="" since="" simulation="" is="" so="" small="" batch.end();="" mumbo="" jumbo="" begins="" here="" public="" void="" simulate(float="" dt)="" delta="" not="" being="" used="" some="" reason="" i="0;" <="" gsizex;="" this="" to="" reset="" mouse="" affection="" status="" gsizey;="" grid[i][j].affectedbymouse="false;" (node="" n="" active)="" at="" beginning="" step,="" every="" grid-cell="" zeroed="" n.m="(n.d" =="" n.gx="n.gy" n.u="n.v" n.ax="n.ay" 0.0f);="" n.active="false;" active.clear();="" g="mx-10;" g<mx+10;g++)="" check="" what="" affected="" by="" h="my-10;" h<my+10;h++)="" (g<0="" ||="">=gsizeX){ continue; } if (h<0 || h>=gsizeY){ continue; } grid[g][149-h].affectedByMouse = true; } } // H-L Comment // This is comparing each particle with all of the other particles... actually this is inefficient. // It scales as O(N^2). He/She should have used a linked list. //H-L --> // Pressure is calculated. He/She got it from a model. for (Particle p : particles) { //What happens in this loop? p.cx = (int) (p.x - 0.5F); //We check on which grid-cell (node) the particle is standing on p.cy = (int) (p.y - 0.5F); float x = p.cx - p.x; p.px[0] = (0.5F*x*x + 1.5F*x + 1.125F); p.gx[0] = (x + 1.5F); x += 1.0F; p.px[1] = (-x*x + 0.75F); p.gx[1] = (-2.0F*x); x += 1.0F; p.px[2] = (0.5F*x*x - 1.5F*x + 1.125F); p.gx[2] = (x - 1.5F); float y = p.cy - p.y; p.py[0] = (0.5F*y*y + 1.5F*y + 1.125F); p.gy[0] = (y + 1.5F); y += 1.0F; p.py[1] = (-y*y + 0.75F); p.gy[1] = (-2.0F*y); y += 1.0F; p.py[2] = (0.5F*y*y - 1.5F*y + 1.125F); p.gy[2] = (y - 1.5F); // Wow... ok... speed of sound is dynamically calculated. for (int i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { int cxi = p.cx + i; int cyj = p.cy + j; Node n = grid[cxi][cyj]; if (!n.active) { active.add(n); n.active = true; } float phi = p.px[i]*p.py[j]; n.m += phi*water.m; n.d += phi; float dx = p.gx[i]*p.py[j]; float dy = p.px[i]*p.gy[j]; n.gx += dx; n.gy += dy; } } } for (Particle p : particles) { //What happens in this loop? int cx = (int) p.x; int cy = (int) p.y; int cxi = cx + 1; //Area on a cell? int cyi = cy + 1; float p00 = grid[cx][cy].d; //The node's, on which the particle is standing, data is gathered float x00 = grid[cx][cy].gx; float y00 = grid[cx][cy].gy; float p01 = grid[cx][cyi].d; //Corner of a node? float x01 = grid[cx][cyi].gx; float y01 = grid[cx][cyi].gy; float p10 = grid[cxi][cy].d; //Corner of a node? float x10 = grid[cxi][cy].gx; float y10 = grid[cxi][cy].gy; float p11 = grid[cxi][cyi].d; //Corner of a node? float x11 = grid[cxi][cyi].gx; float y11 = grid[cxi][cyi].gy; float pdx = p10 - p00; float pdy = p01 - p00; float C20 = 3.0F*pdx - x10 - 2.0F*x00; float C02 = 3.0F*pdy - y01 - 2.0F*y00; float C30 = -2.0F*pdx + x10 + x00; float C03 = -2.0F*pdy + y01 + y00; float csum1 = p00 + y00 + C02 + C03; float csum2 = p00 + x00 + C20 + C30; float C21 = 3.0F*p11 - 2.0F*x01 - x11 - 3.0F*csum1 - C20; float C31 = -2.0F*p11 + x01 + x11 + 2.0F*csum1 - C30; float C12 = 3.0F*p11 - 2.0F*y10 - y11 - 3.0F*csum2 - C02; float C13 = -2.0F*p11 + y10 + y11 + 2.0F*csum2 - C03; float C11 = x01 - C13 - C12 - x00; float u = p.x - cx; float u2 = u*u; float u3 = u*u2; float v = p.y - cy; float v2 = v*v; float v3 = v*v2; float density = p00 + x00*u + y00*v + C20*u2 + C02*v2 + C30*u3 + C03*v3 + C21*u2*v + C31*u3*v + C12* u*v2 + C13*u*v3 + C11*u*v; //DENSITY MULTIPLIER: //Higher value = lower density density = density*1.0f; float pressure = density - 1.0F; if (pressure > 2.0F) { pressure = 2.0F; } float fx = 0.0F; float fy = 0.0F; if (p.x < 4.0F) fx += water.m*(4.0F - p.x); else if (p.x > gsizeX - 5) { fx += water.m*(gsizeX - 5 - p.x); } if (p.y < 4.0F) fy += water.m*(4.0F - p.y); else if (p.y > gsizeY - 5) { fy += water.m*(gsizeY - 5 - p.y); } for (int i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { Node n = grid[(p.cx + i)][(p.cy + j)]; float phi = p.px[i]*p.py[j]; float gx = p.gx[i]*p.py[j]; float gy = p.px[i]*p.gy[j]; // H-L Poorly labled Force: n.ax += (-(gx*pressure) + fx*phi)*1.4f; //Some interesting parameter of the fluid n.ay += (-(gy*pressure) + fy*phi)*1.4f; } } } // H-L: Nothing magical... finding acceleration. for (Node n : active) { //What happens in this loop? if (n.m > 0.0F) { n.ax /= n.m; n.ay /= n.m; n.ay += 0.03F; //Gravity? >0.06f is negative gravity? } } // H-L: Computes new velocity from acceleration. for (Particle p : particles) { //What happens in this loop? for (int i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { Node n = grid[(p.cx + i)][(p.cy + j)]; float phi = p.px[i]*p.py[j]; p.u += phi*n.ax; p.v += phi*n.ay; } } p.v += -0.06f; //-0.06f float mu = water.m*p.u; float mv = water.m*p.v; for (int i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { Node n = grid[(p.cx + i)][(p.cy + j)]; float phi = p.px[i]*p.py[j]; //Viscosity? n.u += phi*mu*1.0f; //Try multipliers between 0.8 and 1.01 n.v += phi*mv*1.0f; } } } // Computes velocity by dividing momentum by mass. for (Node n : active) { //What happens in this loop? if (n.m > 0.0F) { n.u /= n.m; n.v /= n.m; } } // Positions are calculated then sent to rendering // pipeline. for (Particle p : particles) { //What happens in this loop? float gu = 0.0F; float gv = 0.0F; for (int i = 0; i < 3; i++) { for (int j = 0; j < 3; j++) { Node n = grid[(p.cx + i)][(p.cy + j)]; float phi = p.px[i]*p.py[j]; gu += phi*n.u; gv += phi*n.v; //Mouse interaction if (n.affectedByMouse &amp;&amp; mousePressed) { gu +=(0.07f*mVec.x); gv -=(0.07f*mVec.y); } } } p.x += gu; p.y += gv; p.u += 1.0f*(gu - p.u); //Surface Tension? p.v += 1.0f*(gv - p.v); if (p.x < 1.0F) { p.x = (1.0F + (float) Math.random()*0.01F); p.u = 0.0F; } else if (p.x > gsizeX - 2) { p.x = (gsizeX - 2 - (float) Math.random()*0.01F); p.u = 0.0F; } if (p.y < 1.0F) { p.y = (1.0F + (float) Math.random()*0.01F); p.v = 0.0F; } else if (p.y > gsizeY - 2) { p.y = (gsizeY - 2 - (float) Math.random()*0.01F); p.v = 0.0F; } } //end of simulation } } [/code] You're brave for taking this on. That should be respected. This is one of the best books that I've ever read on this subject. Liu is one of clearest, most concise authors I've ever read. [url="http://books.google.com/books/about/Smoothed_particle_hydrodynamics.html?id=_cwFMmEQvZQC"]http://books.google....id=_cwFMmEQvZQC[/url]</grid.length;></node></node></particle></particle>
  14. Say that you have a triangular pixel: 0 (1) 0 (2) 0 (3) You need to find the normal of the pixel to use in collision detection, to see what angle an object is coming in from. You can create Two Vectors by taking the difference in the coordinates of the vertices: 0 (1) a ^ / 0 (2) ------> 0 (3) b Take the cross product between "a" and "b" to find a normal (there are two of them). N = a x b --------> Why? The cross product has an interesting property which you are exploiting: the cross product between two vectors is always perpendicular (orthogonal) to the two source vectors. Also: N = a x b = |a| |b| sin(x) x is the angle between the two vectors. You can exploit this too. This also means that if two vectors are parallel to each other, their cross product is zero. Dot Product: a * b = |a| |b| cos(x) x is still the angle between the two vectors. This means that if "a" and "b" are perpendicular to one another, their cross product is zero. These are usually the geometric relations you exploit. You care about Normals when you're dealing with regular kinematics. If you want to figure out how particles reflect or bounce when they hit a surface; you need to know the direction of the normal for the floor, this determines how the particles get deflected. Something else: I haven't toyed around with this very much... however, it should be possible that instead of doing tradtional collision detection; you could use fields between the floor and the particles. You could design it such that a field is weak at a distance, but when the particles get very close to the source of the field, they interact; and you can have this dictate the physics of the system. This idea either isn't used because no one has thought of it before... which is unlikely. Or it isn't used because it may be taxing on the poor cpu... which is more likely. That's the only nugget I'm giving you tonight. You're bright; you'll figure it out. ;)
  15. Look into taking a serious differential equations and partial differential equations as well... clever implementations of these let you control the motion of systems using realistic physics. There is something called Geometric Level Set Methods; these are all graphics manipulation algorithms that are based on the use of differential equations. This stuff is powerful! These courses are Junior or Senior level college classes. You can look them up on Khan academy if you're feeling brave. Don't feel bad if you don't understand it initially, like algebra; it's hard the first time you learn it. May the compiler be with you.