I used some time ago an older version from ObiRope and i have some questions.
Do i really need to instantiate a rope with an solver as parent? (if not, Is there a callback/event where i know i can unparent the rope from the solver?)
Whats the best way to carry an Particle Attachment? In the earlier version there was an script called "ObiParticleHandle" which gave me the opportunity to carry the attachment.
The attachment is an rigidbody object.
I also noticed, that my rope is acting like a snake, how can i make it to behave like a cable which is more sticky?
I am getting this warning when I brought ObiFluid into my game
Assets\Obi\Samples\Fluid\SampleResources\Scripts\FluidColorizer.cs(11,21): warning CS0108: 'FluidColorizer.collider' hides inherited member 'Component.collider'. Use the new keyword if hiding was intended.
I have noticed that my obi fluid is always black even when setting any color. Any ideas? Thanks.
How can I get two actors to collide with each other? They do not seem to collide even though they are inside the same solver. I have tried enabling surface collision for both actors but it is very inefficient performance wise, and it doesn't work anyways. What should I do?
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;