I've been working quite a lot with softbodies recently, trying to figure out the basis of the engine and how everything works and functions. One of the things I seemingly can't wrap my head around is the prospect of using Obi for 2D.
I'm aware that this is possible, due to this (http://obi.virtualmethodstudio.com/forum...-2668.html) thread here, and I've also been able to replicate things shown, by utilizing the in-built Unity quad primitive, which worked just fine.
However, in the above mentioned thread, I saw that a flat circular mesh was used, which yielded results identical to that of what I achieved with the quad. I've since tried to replicate such a 'mesh' in blender, making a flat plane and exporting to Unity. However, particles don't seem to generate properly (and the mesh is only visible on one side within the Unity editor) and the softbody collapses and deforms at runtime, even after skinning.
How would I make such a flat mesh that is usable in Obi?
Thank you.
regards,
-woffles
UPDATE:
I was messing around with the solver settings, and found that it could work just fine when setting solver mode to 3D (which resulted in the quad being deformed and not working properly instead). However, when in 2D, the mesh still fails to work. Still not sure why, but I will keep investigating.
I'm aware that it's possible to create some snake-like movement with Obi Rope, through the YouTube channel as well as the demo scene. I was wondering whether it'd be possible to get it even closer to something like this - https://www.youtube.com/watch?v=EUHFG2CnBJ8, done almost 4 years ago, and this - https://www.youtube.com/watch?v=D9lunzyn5yo, around 10 months ago, since the one provided was rather finnicky when climbing or utilizing snake body physics in general.
My Slime Player Character quickly filled up the 4 userdata with:
Motivation: Solid surfaces write 1, Air 0, values dilute to 0, such that only particles near the surface can move, with some moving in desired direction, and some "pushing back" against the surface
Bigness: Each square cell of fluid writes a factor of it's Mass to the particle at the center, which then dilutes outwards. Bigger slime sticks more, smaller slime drops slide off stuff.
Stranded: Particles "Inside" write 1, otherwise sharply dilute to 0. Particles on edge of big-enough slimes hover around 0.7 value, Particles on edge that is a "thin strand of slime" drop to 0.1, and are killed, so that thin strands do not awkwardly hold together large Blobs of Slime, or wrap around edges of objects and prevent Slime Splitting
Teams: An Orange/Blue "Team Signal" writes 0 or 1 to nearest particles, and particles near 0 or 1 Teamness accept input from either "Player 1" or "Player 2", with values around 0.5 being an idle grey that get no input
Workaround?
I can imagine an awful Workaround to the 4-channel limit, by creating one set of intangible "Zombie" Fluid per extra 4 Channels I want. It would copy Position and Velocity, and dilute fluid, and any of my calls to GetUserData(particleIndex, dataIndex) would would send dataIndex 0-3 to "real" Slime, and dataIndices 4-15 to any of the "Zombie" slimes. My need for more UserData has not reached the point to attempt such a disgusting (and probably grossly computationally wasteful) solution.
If Implemented
More UserData would allow me to allocate 2-3 channels to "Team", allowing 4-8 individually-controlled regions of Slime, instead of 2. I could add 1 for Temperature, 1 for Digestion/Energy, a few for Harmful Chemicals. I would especially like to allocate 2 channels to "Applied Forces on x/y axis" such that I can use diffusion to get more "Equal and Opposite Forces", ie applying additional braking where I notice "500 Force magnitude on a particle last frame"
(18-11-2021, 09:44 AM)josemendez Wrote: FYI, the reason why there's only 4 user data channels is because 4 is the length of the SIMD registers used to perform vector operations. This means operating with pairs of user data with 4 components is very efficient. In addition to this we know the data for particle n is at n*4 in the data arrays, making memory access efficient too. Using a variable size for the amount of user data channels would make both accessing the data and operating with it considerably less efficient.
Is there some Compile-Time #pragma technique, locked at runtime, that would maintain performance for 99% of users who stick to 4 channels of UserData?
Type of UserData changing from ObiNativeListVector4 to Vector8, Vector12, Vector16 sounds hairy already. I don't know how it would be implemented.
Adding a 1-4 int picker to ObiFluidEmitterBlueprint is probably totally insufficient, it has to be project-wide, for all fluids, right?
short text message to appease the scripts
I have a testing scene with one ObiCloth object in it. I need surface collision for the project to make sure that no unexpected object penetrating through this cloth object, however when I turn on surface collisions, the performance become significantly worse, <10 fps. When surface collision is turned off, I can get over 60fps.
Is there a way to improve it?
Another behavior that I'm noticing is that after turning on surface collision the cloth object start to "drifting off" the surface it is placed on.
Hello,
one way I use to take control of particles (in this case to pull the around) is to set the inverse mass to 0. This method works very well, the "locked" particles are stable and do what I tell them to do but in the specific case of a softbody (not observable on ObiRope), the particles around those whose inverse mass I've set to 0, are very unstable: their position but mostly their orientation keeps changing wildly and make the softbody look broken at the "grabbed" boundary (meaning the boundary of the set of particles that now have inverse mass = 0).
I am calling actor.UpdateParticleProperties() whenever the inverse mass of particles is set (or set back to its original value), additionally I tried to call actor.SetConstraintsDirty(Oni.ConstraintType.ShapeMatching) but it made no difference.
Important to say that I am using the vertex method in the blueprint and I have 1 bone per particle so I think the problem might also be related to the skinner (and I've tried to bind the mesh with different parameters).
Any ideas?
Thanks all!
void Solver_OnCollision(object sender, Obi.ObiSolver.ObiCollisionEventArgs e) { var world = ObiColliderWorld.GetInstance();
// just iterate over all contacts in the current frame: foreach (Oni.Contact contact in e.contacts) { // if this one is an actual collision: if (contact.distance < 0.01) { ObiColliderBase col = world.colliderHandles[contact.bodyB].owner; if (col != null && col.gameObject.layer == 7) { // do something with the collider. counter=solver.contactCount;
After spending a good amount of time adjusting the fluid parameters in the editor until getting the look I liked, I tried to make a build and was surprised to get a pretty different result. Here are pictures of the editor (left) and the build (right):
I also tried to make a build of one of the examples provided, and I seem to be getting a similar result, where the fluid in the build looks whitened.
I'm using Windows 10, the Build In Render Pipeline, the ParticleShader in the emitter, and I've tested in both Unity 2021.3.8f1 and 2021.3.9f1 Here are the fluid renderer settings I'm using in my scene:
Hi, I have a simple soft body object with some skinned meshes binded to the soft body. I have been trying out the ObiParticlePicker and have observed some glitches.
From above we can see that sometimes my soft body mesh disappears. Sometimes the skinned mesh binded to the softbody with the Softbody skinner can disappear as well.
Any ideas on how I can prevent my meshes from disappearing?
Hello, I checked the forum and the document, and mentioned that the fabric does not support non-manifold mesh.
Forgive me for my unprofessional, after I read the document you shared, I probably understand the non-manifold mesh.
But what I don't understand is what a 2-manifold is?
When I tried to merge the model fixes into the mesh in Blender, the repaired simulations were sometimes even weirder than the unrepaired ones (in skin mode), and there was little difference between before and after the fixes in Cloth mode(This one can be ignored, which may be caused by my incorrect configuration. Modified at 01:56:30 on September 2, 2022)
And I see that OBI seems to automatically merge meshes?
So Obi will automatically deal with repairing some non-manifold meshes?
==============================================================
"Generate a list of merged mesh vertices, ignoring uv and normal seams."-Documen
I'm working on a game project in Unity where we want to use obi bone on a character with braids.
in our setup on the character I have the Obi Solver on the chest bone with the Obi fixed updater. Under the chest bone I have a empty game object with with a Rigidbody component, capsule collider, Obi Collider and Obi rigidbody.
Finally on the hair bones that we want to use I have on the top root hair bone a capsule collider, obi bone, Obi collider, rigidbody and Obi rigidbody. Down the bone chain from that setup I use capsule colliders and obi colliders.
The issue I'm having is that the only way to get the hair to register and interact with the collider under the chest bone is to have a value on Max depenetration on the solver, if not it won't register the collider.
I'm also wondering if this is the correct setup here since I was unsure about that.
