seblague / fluid-sim Goto Github PK

I do not want to get extra items to run this, so I need a .exe or a .msi or something. Thank you.

When I attempt to build using the 2D scenes, I only see a black screen in-game. When I build the 3D scene, spheres are rendered but not in color. Everything works perfectly in the editor. I have tried adding the various shaders to the "Always Included Shaders" list, but this has no effect.

Any explanation for this behavior would be appreciated.

Hello. At the start of your video (around 0:10) you rendered a circle using DrawCircle(Vector2.zero, 1, Colour.lightBlue). I've searched all around the Internet but were unable to find any similar method as a part of UnityEngine. Could you provide some info on the method, please? Did you write it yourself, or is it a part of some extension?

PLEASE PUT UNITY PACKAGE INTO RELEASE

Hello,
this is just a minor thing, but the video link in the README seems to be to your Ant and Slime video.

I am trying to make this a wallpaper for linux and when I build it I just get a black screen after the splash.

Thanks for this, was looking to play around with SPH for ages and this makes it really convenient!

My plan is to create a self gravitating gas cloud, with as high a resolution as possible, but when i increased the particle count by adjusting Num particles per axis, the system just exploded. Seems like energy is injected at every iteration.

Changing viscosity in either direction from the default 0.001 further increases the energy and results in weird patterns if i scale time down.
Setting pressure multiplier to 1 makes it a bit better, but velocities still go crazy in any overdense region.

Is this the correct way to increase particle count: Simulation inspector/Spawner 3D/Num particles per axis?
Where should i look to fix the issue? Are there any constants or calculations that need to be adjusted along with the count?

i have downloaded the file, how do i open it to do the simulation (im new to GitHub sry)

Hello, I've noticed a discrepancy between the Unity version mentioned in the project's README (Unity 2021.3) and the version specified in ProjectSettings/ProjectVersion.txt (m_EditorVersion: 2022.3.8f1).

Cannot wait to dig around and learn more about shaders! I really appreciate the way you simplify complex concepts, making them easy to understand and fun to follow ❤️

Hello! I've received a project and I'm testing it. I have a question – when I build and run Test A, B, and C scenes, the screen appears black in scenes except Test C scene. I'm curious if there are any adjustments needed in project settings or graphic configurations. Thank you!

using unity 2022.3.8

Hei,
is there a reason you are working with hashes rather than a flattened cell index? As I understand, the domain (the box that contains the particles) is always finite and there are never indefinitely many cells. Instead of (cell.x * hashK1) + (cell.y * hashK2) + (cell.z * hashK3) you could compute the flattened index and use it as a unique cell id: cell_key = cell.z * (n_x * n_y) +cell.y *n_x + cell.x. With n_x = ceil(domain_size.x/smoothingRadius). Not sure what your domain is called, is it boundsSize?
So instead of

	int3 cell = GetCell3D(PredictedPositions[index], smoothingRadius);
	uint hash = HashCell3D(cell);
	uint key = KeyFromHash(hash, numParticles);

you could do something like:

	int3 cell = GetCell3D(PredictedPositions[index], smoothingRadius);
	uint key = FlatIndex(cell, domain_size);

No reason to call KeyFromHash anymore, because all cell_key's are already smaller than tableSize (tableSize=n_x*n_y*n_z, which is smaller than numParticles).

The description of the CalculateOffsets Compute Function indicates that an array of sorted keys {0001223333} would produce an array of offsets {0003446666}. However, this behavior would seem to be incorrect, for two reasons.
A. Assignments only occur when key and prevKey do not equal each other, and not for each index of the numParticles sized offsets buffer.
B. The offsets buffer is assigned at the index of the key rather than the index of the invocation.

In actuality, based on the behavior in the program, the output of the offsets buffer would look more like {03460000000}. I'm not sure whether this is an error with the description or an error with the program itself.

EDIT: Based on the code in the other shaders, it would seem like the offsets buffer is only indexed by key, with the buffer size to numParticles to account for edge cases where every key in SpatialIndices is unique. Accordingly, I think this is just an issue with the current description of the shader's behavior.