Develop Reference

How to create Unity3d gaussian plume resembling breathing puffs

I'm working on a project that needs a breath effect such that it emits puffs of droplets for visualization. The puffs need to occur about 10-20 times per minute and look like water vapor expelled during cold weather. I've created several particle generators in Unity that use a cone shaped emitter and tried to adjust it to get something similar to a gaussian plume, but all I get are "rings" and I can't get one generator to create short "puffs". I finally have created 3 generators pithing the same "cone", one emits small particles, one medium sized, and the other large, but it does not resemble a collection of particles that change size after being breathed out, i.e. shrinking due to evaporation, slowing down to terminal velocities appropriate to their changing size, drifting upward due to the thermal gradient in the room, etc. Can someone point me to the documentation that explains how to create a particle generator that would provide for spatially distributed, velocity distributed, size distributed particles where the "puff" could be characterized by vz_avg, vz_sigma, vx_avg = vy_avg, vx_sigma = vy_sigma, and be able to have each particle's speed and acceleration a function of it's size, temperature difference between it and background, evaporation due to humidity and temp, etc?
The Unity engine is good at allowing one to put an avatar into a scene, move and control it representing almost realistic looking behavior, BUT, my difficulty is combining video effects in a manner that is physically realistic, i.e. gravity, buoyancy, evaporation, slowing down, etc.
Pointers appreciated.

I managed to get a series of parameters put together that allowed me to perform this task. I had to use three different emitters, one for large droplets, one for mid range droplets, and one for aerosols. Each used a different setting for gravity to emulate falling, hovering, and rising particles, restpectively. By matching the rate of emission of the "puffs" to the human breathing, the number of particles to approximate the number of viral droplets of the different sizes that have been determined to be in a breath, I was able to create a realistic "looking" cloud of particles that are emitted, drift to the floor, hover, and also rise towards the ceiling.
I just thought I'd post and answer so that others might know that it can be done, but takes a lot of working backwards from the actual physics to the way that Unity displays things to get something realistic.

Translate Unity units of measurement?

In Unity one can use Raycasting to calculate various measurements. Examples such as diameter, thickness of a wall, and width. One way to do this is by capturing a users mouse click on an object and using RaycastHits to capture the location of the mouse click on the object and than casting additional rays depending on the measurement desired.
Seen below:
Thickness of the walls clicked is .0098, .0096, and .0072. Width is .0615, .0611, and .060. Diameter is .0475.
Though these measurements are (believed to be) executed and calculated correctly it's unclear how the results translate to real world units of measurement.
This is best demonstrated and shown in the fourth image. Checking the same diameter in other CAD programs, such as NX, the diameter is 0.4210" or inches. Thickness and width were calculated as well at .075244" and .252872" respectively.
So than, how do the results in Unity, (results produced using Vector3.Distance to calculate the distance between two points) translate to real world units of measurement?
Googling the subject yields a common answer: Unity's measurements are "game units" and can be used however desired. While I grasp this, I don't understand how to accomplish the translation of "game units", or whatever Unity's units of measurement truly are, to the measurement results I can see in CAD programs.
Results (CAD x Unity):
Thickness: .075244" x .0098, .0096, and .0072.
Width: .252872" x .0615, .0611, and .060.
Diameter: 0.4210" x .0475
(note1: model scales are identical in Unity and external CAD program.)
(note2: the slight variation in thickness and width results from Unity measurements coming at angles where the CAD program is measuring distance between the two planes, i.e. .009x and .06x.)
(note3: ignore the incorrect labeling of Width in the second visual as 'Thickness' and the inch labeling in all of the Unity visuals, ", as both incorrect).

1 Unity unit is generally held to be 1 meter, however as you've read it's up to your implementation, in this case it looks like you're actually exporting from CAD with 1 inch = 1 unit, since your results seem similar but slightly off.
The reason you're getting innaccuracies is most likely due to Unity's collision system not being extremely accurate, most colliders are in fact slightly larger than the mesh they represent which will throw off your fine tuned measurements significantly, and on top of that Unity will have much lower precision than CAD, since Unity is a game engine and needs to perform in realtime, 3D position data is not very accurate (it gets pretty hazy around 4 digits of precision), and in fact gets significantly worse as you travel away from the origin.
I wouldn't recommend trying to use Unity for any kind of precise design work, especially when representing the real world, but if you're dead set, you might want to scale your objects up by a factor of 10 or 100 in order to keep your digits closer to the decimal point to reduce floating point error, this is a hack obviously.
You may want to also look at your physics settings: https://docs.unity3d.com/Manual/class-PhysicsManager.html
In particular "Default Contact Offset" may be relevant (although I'm not sure if it affects raycasts)
PS: I'd post this as a comment but the rep system won't let me, your description of the measurements between each environment is really confusing, next time maybe try and format it in a table or something?

Traveling salesman prob on 2d map with walls (obstacles) so pathfinding needed

I need to find optimal path between a number of points on a 2d map.
The 2d map is of a building and will simply have where you can not go (through walls) and all the points on the map. So it's not really a map, rather lines you cannot go through with points to pass through.
I have a number of points, say between 20 and 500
I start with one that I select and then need the route calculated for most optimal path.
I would love hints for where to look for this travelling salesman problem with obstacles. Or even better, done library for doing it.
Bonuses
Things like doors can be weighted as they are less fun to pass through back and forth.
Possibility of prioritizing/Weighting the ability to end close to where you started.
Selecting areas as passable but annoying (weighting down)
.Net/C# code that I can use, I want to use this both on .NET MVC project and Xamarin mobile project so .net code would be great (if code exists)
Update example
In my example here we have an office. Now I have not thought every detail out so this is merely an example.
All the purple dots need to be checked
Yellow area could mean annoying to pass through but doable
Red could mean not active but can be passed if no other option exists.
Blue (walls) are impenetrable and can not be passed.
Green is doors, weighted down possibly as it's annoying to go trough closed doors (usually this would probably make sense anyway as the dots in a room would be easiest to check together.
The user would go to one dot, check it, then the software should tell him which one to do next until he is done.
Bonus could be given for ending close to start place. So for instance in this example, if the red area was normal and contained dots it would have been easy to make it a loop. (So the user comes back close to where he started)
Finally I suppose it would also be smart to differentiate outdoors areas as you would need to get dressed for outdoors, so you only want to go out once.
Also it could be smart to be able to prioritize ending on a point close to stairwell to next floor if they intend to check multiple floors at once.
Of course would have more more complex and larger plans the this exmaple.
Again sorry for just brainstorming out ideas but I have never done this kind of work and is happy for any pointers :-)

Let N be the set of nodes to visit (purple points). For each i and j in N, let c(i,j) be the distance (or travel time) to get from i to j. These can be pre-computed based on actual distances plus walls, doors, other barriers, etc.
Now, you could then add a penalty to c(i,j) if the path from i to j goes through a door, "annoying" area, etc. But a more flexible way might be as follows:
Let k = 1,...,K be the various types of undesirable route attributes (doors, annoying areas, etc.). Let a_k(i,j) be the amount of each of these attributes on the path from i to j. (For example, suppose k=1 represents door, k=2 represents yellow areas, k=3 represents outside. Then from an i in the break area to j in the bathroom might have a_1(i,j) = 1, and from an i to a j both in the yellow areas would have a_2(i,j) = 0.5 or 2.0 or however annoying that area is, etc.)
Then, let p_k be a penalty for each unit of undesirable attribute k -- maybe p_1 = 0.1 if you don't mind going through doors too much but p_2 = 3.0 if you really don't like yellow areas.
Then, let c'(i,j) = c(i,j) + sum{k=1,...,K} p_k * a_k(i,j). In other words, replace the actual distance with the distance plus penalties for all the annoyances. The user can set the p_k values before the optimization in order to express his/her preferences among these. The final penalties p_k * a_k(i,j) should be commensurate with the distance units used for c(i,j), though -- you don't want distances of 100m but penalties of 1,000,000.
Now solve a TSP with distances given by c'(i,j).
The TSP requires you to start and end at the same node, so that preference is really a constraint. If you're going to solve for multiple floors simultaneously, then the stairway times would be in the c(i,j) so there's no need to explicitly encourage routes that end near a stairway -- the solution would tend to do that anyway since stairs are slow. If you're going to solve each floor independently, then just set the start node for each floor equal to the stairway.
I wouldn't do anything about the red (allowable but unused) areas -- that would already be baked into the c(i,j) calculations.
Hope this helps.

Optimising movement on hex grid

I am making a turn based hex-grid game. The player selects units and moves them across the hex grid. Each tile in the grid is of a particular terrain type (eg desert, hills, mountains, etc) and each unit type has different abilities when it comes to moving over the terrain (e.g. some can move over mountains easily, some with difficulty and some not at all).
Each unit has a movement value and each tile takes a certain amount of movement based on its terrain type and the unit type. E.g it costs a tank 1 to move over desert, 4 over swamp and cant move at all over mountains. Where as a flying unit moves over everything at a cost of 1.
The issue I have is that when a unit is selected, I want to highlight an area around it showing where it can move, this means working out all the possible paths through the surrounding hexes, how much movement each path will take and lighting up the tiles based on that information.
I got this working with a recursive function and found it took too long to calculate, I moved the function into a thread so that it didn't block the game but still it takes around 2 seconds for the thread to calculate the moveable area for a unit with a move of 8.
Its over a million recursions which obviously is problematic.
I'm wondering if anyone has an clever ideas on how I can optimize this problem.
Here's the recursive function I'm currently using (its C# btw):
private void CalcMoveGridRecursive(int nCenterIndex, int nMoveRemaining)
{
//List of the 6 tiles adjacent to the center tile
int[] anAdjacentTiles = m_ThreadData.m_aHexData[nCenterIndex].m_anAdjacentTiles;
foreach(int tileIndex in anAdjacentTiles)
{
//make sure this adjacent tile exists
if(tileIndex == -1)
continue;
//How much would it cost the unit to move onto this adjacent tile
int nMoveCost = m_ThreadData.m_anTerrainMoveCost[(int)m_ThreadData.m_aHexData[tileIndex].m_eTileType];
if(nMoveCost != -1 && nMoveCost <= nMoveRemaining)
{
//Make sure the adjacent tile isnt already in our list.
if(!m_ThreadData.m_lPassableTiles.Contains(tileIndex))
m_ThreadData.m_lPassableTiles.Add(tileIndex);
//Now check the 6 tiles surrounding the adjacent tile we just checked (it becomes the new center).
CalcMoveGridRecursive(tileIndex, nMoveRemaining - nMoveCost);
}
}
}
At the end of the recursion, m_lPassableTiles contains a list of the indexes of all the tiles that the unit can possibly reach and they are made to glow.
This all works, it just takes too long. Does anyone know a better approach to this?

As you know, with recursive functions you want to make the problem as simple as possible. This still looks like it's trying to bite off too much at once. A couple thoughts:
Try using a HashSet structure to store m_lPassableTiles? You could avoid that Contains condition this way, which is generally an expensive operation.
I haven't tested the logic of this in my head too thoroughly, but could you set a base case before the foreach loop? Namely, that nMoveRemaining == 0?
Without knowing how your program is designed internally, I would expect m_anAdjacentTiles to contain only existing tiles anyway, so you could eliminate that check (tileIndex == -1). Not a huge performance boost, but makes your code simpler.
By the way, I think games which do this, like Civilization V, only calculate movement costs as the user suggests intention to move the unit to a certain spot. In other words, you choose a tile, and it shows how many moves it will take. This is a much more efficient operation.
Of course, when you move a unit, surrounding land is revealed -- but I think it only reveals land as far as the unit can move in one "turn," then more is revealed as it moves. If you choose to move several turns into unknown territory, you better watch it carefully or take it one turn at a time. :)
(Later...)
... wait, a million recursions? Yeah, I suppose that's the right math: 6^8 (8 being the movements available) -- but is your grid really that large? 1000x1000? How many tiles away can that unit actually traverse? Maybe 4 or 5 on average in any given direction, assuming different terrain types?
Correct me if I'm wrong (as I don't know your underlying design), but I think there's some overlap going on... major overlap. It's checking adjacent tiles of adjacent tiles already checked. I think the only thing saving you from infinite recursion is checking the moves remaining.
When a tile is added to m_lPassableTiles, remove it from any list of adjacent tiles received into your function. You're kind of doing something similar in your line with Contains... what if you annexed that if statement to include your recursive call? That should cut your recursive calls down from a million+ to... thousands at most, I imagine.

Thanks for the input everyone. I solved this by replacing the Recursive function with Dijkstra's Algorithm and it works perfectly.

Opinions on platform game actor/background collision resolving

Imagine the following scenario: I have a level whose physical structure is built up from a collection of bounding rectangles, combined with prerendered bitmap backgrounds. My actors, including the player character, all have their own bounding rectangle. If an actor manages to get stuck inside a level block, partially or otherwise, it'll need to be shifted out again, so that it is flush against the block.
The untested technique I thought up during bio break is as follows:
If an actor's box is found to intersect a level box, determine where the centerpoints of each rect are. If the actor's center is higher than the level box's, move the actor so that the bottom of the actor's rect is flush with the top of the level's rect, and vice versa if it's lower. Then do a similar thing horizontally.
Opinions on that? Suggestions on better methods?
Actually, the bounding rects are XNA BoundingBoxes with their Z spanning from -1 to 1, but it's still 2D gameplay.

Have you read the N Tutorials? They're a wonderful introduction, complete with little demos, of Separating Axis Theorem based collision detection and simple projection response. (They're actually used in the N game to great effect.) The tutorials cover more than you need, but they're very general (extensible to many other shapes), and start to touch on issues with fast-moving objects and other response techniques.
Even if you do decide to go with something simpler than a SAT implementation, this may give you a lot of good ideas.
(When you're done with that and if you want your mind blown, try looking into some of the presentations from the Game Developers Conference physics tutorial day, including realtimecollisiondetection.net publications, the essentialmath.com tutorial slides, both of those books, and/or other stuff linked from those sites. I'd highly recommend the GDC session itself, too. While we still don't need or particularly want fancy GJK on swept hulls on the handheld game platforms we work with, some of the simpler concepts such as "configuration spaces" and Minkowski sums and differences have greatly influenced how I think about physics and collision detection and how we implement it.)

What the "real" physics engines do is find the minimum penetration vector. That is - the smallest vector that represents how far inside each other the two objects penetrate.
For an AABB (axis-aligned bounding box) this is really easy to calculate.
(Consider making your own 2D AABB structure, it will be smaller and therefore better for performance.)
Once you have your minimum penetration vector, you can perform collision response. And the easiest response is to simply separate the two objects by that vector (or separate the one object if the other is static).
Here is a good reference, by the makers of N on how to do this for convex polygons and circles. You should be able to simplify this down for AABBs.

A lot depends on the details. A complete solution could take into account velocities or other issues. But treating this simply...
You don't want to always resolve vertically first. Imagine an actor nudges horizontally into a block. If you resolve vertically first then the actor will pop up above that block, when a small horizontal movement would have sufficed.
Find what the vertical and horizontal movements would need to be to "get out of collision", and then apply the one with the smallest absolute value.
Then repeat a few times, in case the movement puts the actor into another block. But don't repeat forever, because the actor could be wedged somewhere that never resolves.
Maybe if your last movement still leaves you in collision, you could just average the last two movements and leave it there.

Another possible approach is, rather than waiting for a collision and then shifting out, check for possible collisions before you move objects and, if there is going to be a collision, move the player only up to the edge of the block.
I.e., contrast how Adventure does collisions with walls: http://www.youtube.com/watch?v=I6-zN_eaRd8
to how most NES games do collisions with walls.