• 9
• 16
• 15
• 12
• 9
• ### Similar Content

• I publishing for manufacturing our ray tracing engines and products on graphics API (C++, Vulkan API, GLSL460, SPIR-V): https://github.com/world8th/satellite-oem
For end users I have no more products or test products. Also, have one simple gltf viewer example (only source code).
In 2016 year had idea for replacement of screen space reflections, but in 2018 we resolved to finally re-profile project as "basis of render engine". In Q3 of 2017 year finally merged to Vulkan API.

• By suliman
Hi!
I have a two floats (pan.x and pan.y) which allows the player to move the view in my tile-based 2d-gameworld. I also have a "float scale" for zooming the world in and out.
For drawing most stuff it works fine. I just (where pos is the tile-position of something and #define TILE 20 is the size of a gametile at scale = 1):
drawStuff(pos.x * scale * TILE, pos.y * scale * TILE); When I change scale it draws to the correct position on screen. But when i draw the lines that shows the grid (all the tiles) they do not offset correctly. It works when scale = 1, but when I lower scale they become off. I tried so many variations but I've got stuck. What am I doing wrong?
int tile2 = TILE * scale; int offY = ((int)pan.y) % tile2; // draw horizontal lines for the grid for (int i = 0; i < h; i++) gfx.lineRelative(0, TILE*i*scale + offY, gfx.screenX, 0, col);

• Trying to get ideas here on how I could do this:
I have created a game for a university coursework assignment using a custom game engine (internal to my university, but it's based on OpenGL).
I know that I can use threading but am unsure how thread-safe the operation would be to init the game on another thread.

• I have a particle system with the following layout:
system / emitter / particle

particle is driven by particle data, which contains a range of over lifetime properties, where some can be random between two values or even two curves. to maintain a smooth evaluation between two ranges, i randomize a "lerp offset" on particle init and use that value when evaluating curves. the issue is that i'm using that same offset value for all properties (10ish) and as a result i'm seeing some patterns, which i'd like to remove. The obvious way is to just add more storage for floats, but i'd like to avoid that. The other way is to generate a seed of some sort and a random table, and use that to generate 10 values, ie: start with short/integer, mask it, then renormalize to float 0-1.

any other ideas?
• By dgi
Hey all ,
For a few days I'm trying to solve some problems with my engine's memory management.Basically what is have is a custom heap with pre allocated memory.Every block has a header and so on.I decided to leave it like that(not cache friendly) because my model is that every block will be large and I will have a pool allocators and stack allocators dealing with those blocks internally. So far so good I figure out how to place my per scene resources . There is one thing that I really don't know how to do and thats dealing with containers.What kind of allocation strategy to use here.
If I use vector for my scene objects(entities , cameras , particle emitters .. ) I will fragment my custom heap if I do it in a standard way , adding and removing objects will cause a lot of reallocations . If I use a linked list this will not fragment the memory but it's not cache friendly.I guess if a reserve large amount of memory for those vectors it will work but then I will waste a lot memory.I was thinking for some sort of mix between a vector and a linked list , where you have block of memory that can contain lets say 40 items and if you go over that number a new one will be created and re location of the data would not be needed.There would be some cache misses but it will reduce the fragmentation.

How you guys deal with that ? Do you just reserve a lot data ?

dgi

# Position Based Dynamics Frictional Constraint

## Recommended Posts

I'm trying to implement a frictional constraint using position based dynamics, but it is only half working. I am using the formulation in the paper "Unified Particle Physics for Real-Time Applications".

Here is my implementation:

	Particle *np = particle->nbs[j].neighbour;

vec3  r = particle->x - np->x;
float r_length = glm::length(r);

float distDiff = r_length - restDistance;

if(distDiff >= 0 ) continue;

//Frictional Constraint
vec3 n   = r/r_length;
vec3 xxi = particle->x - xi[particle->getIndex()];
vec3 xxj = np->x - xi[np->getIndex()];

vec3 tangentialDisplacement = (xxi - xxj) - glm::dot(xxi - xxj, n) * n;

float td_length = glm::length(tangentialDisplacement);

float genMass = ( imass / (imass + imass) );

if(td_length < (staticFriciton * distDiff)){
particle->x += genMass * tangentialDisplacement;

np->x += -genMass * tangentialDisplacement;
}else{
float upper = kineticFriction * distDiff;
particle->x += genMass * tangentialDisplacement * std::min(upper/td_length, 1.f);

np->x += -genMass * tangentialDisplacement * std::min(upper/td_length, 1.f);
}

##### Share on other sites

Half working how? What problems are you having, what is it doing that is different from what you think the code should be doing?

##### Share on other sites

And a link tot the failed friction constraint (Friction constraint applied after penetration constraint):

And I just realized that only the else statement gets executed in this part of the code:

  if(td_length < (staticFriciton * distDiff)){
particle->x += genMass * tangentialDisplacement;

np->x += -genMass * tangentialDisplacement;
}else{
float upper = kineticFriction * distDiff;
particle->x += genMass * tangentialDisplacement * std::min(upper/td_length, 1.f);

np->x += -genMass * tangentialDisplacement * std::min(upper/td_length, 1.f);
}

Edited by 7th_Continuum

##### Share on other sites

Can (upper/td_length) ever be negative?

##### Share on other sites

distDiff will always be negative, otherwise there's no interpenetration. So the answer is yes.

I'm thinking the tangentialDisplacement is being calculated wrongly because everything largely depends on it. It is perpendicular to the contact normal, a dot product gives zero.

The other thing I am not sure about is the which interpenetration distance to use, the one from the penetration constraint or the one from the friction. The paper does not make this clear.

Hoping someone has implemented one before, I can't find a reference anywhere.

Edited by 7th_Continuum

##### Share on other sites

If (upper/td_length) is always negative then those std::min calls are redundant because they would only take effect if the value is > 1.  Mainly what I was concerned about was:  Often when min or max calls are done, someone is thinking of magnitudes (i.e.  "make sure the magnitude is between 0 and 1") but accidentally misses the fact that the value is not a magnitude, but can be negative (in which case you would either want to get the magnitude using the absolute value or clamp between -1 and +1).

I'm not familiar with the system you're trying to implement; I'm just looking at "suspicious" code based on my own experience with bugs

Edited by Nypyren

##### Share on other sites

Thanks for the help, I understand what you're saying. I will test the values thoroughly and see if they are producing negative values in the wrong places.

##### Share on other sites

Finally got this to work.