A mode between phantom and physical?

Has there been any discussion about a mode for prims that avoids the heavy-duty physics processing of Physical objects but still provides their property of non-interpenetration?

After all these years, it's still the holy grail to produce clothing or hair that drapes properly over a body. It's at least a debateable point that the lack of progress in this area is due to the abrupt jump from Phantom to Physical, with nothing in between.

An intermediate mode that persists after attachment might provide extra room for maneuver, hence the question. (Note that it wouldn't need to work on physical principles --- just an ad hoc "heuristic force" for staying out of the body volume could do wonders!)

Morg.

Non-phantom flexible prims that have their physics handled client-side perhaps would suit best?

That's a good suggestion, I think, because client-side processing is scalable whereas server-side it's not.

However, that would certainly qualify as HARD! In fact, very hard.

My suggestion was for a very lightweight intermediate mode instead, little more than an additional force affecting flexiprim strands or attached child prims in rough proportion to the distance to the nearest physical object.

I used the word "heuristic" on purpose, to convey that this wouldn't need to be exact --- its purpose would be only to reduce the very poor body slicing visuals associated with hair and clothing. If exact behaviour is required then yes, full physics processing becomes mandatory, but I think it can be avoided.

Morg.

Haravikk, thinking ahead, your suggestion has a far far better future than mine, so I'd be inclined to support the full client-side physics approach on that basis.

To cope with the reality of it being hard though, perhaps just a very minimal subset of a full physics library like ODE could be selected initially, to deal only with the really bad body slicing behaviour that's making SL look a bit silly for visuals in 2007. Other physics handling could then be added incrementally.

At least we'd be starting off on very solid ground, and the future would look great.

PS. Looking at the ODE docs, section 3.8 deals with hard and soft constraint types and the Constraint Force Mixing that can be used to control object interpenetration. It seems to be reasonably separate from the rest of ODE -- www.ode.org.

Morg.

Well no, you're completely right that a stripped down and approximated version would be good. I can't think of anything that would really need flexi-prims to be super precise, and the lighter-weight the better these days.

Flexi-prims already divide up into segments with 'joints', all that's really needed is a way to detect if a join is interpenetrating something as you say, and forcing it into a position where it isn't, the other joints will then move to match and can run their own tests. Frequency determined by flexi-prim movement as it is now.

Ultimately flexi-prims are a series of points, which are fairly easy for testing rough collisions (compared to colliding two 3d objects and all their polygons). Throw in some simple fudging for different flexi-prim thicknesses and you've got a decent enough system I think.

Interestingly, that's *precisely* the target application of ODE --- articulated rigid body physics.

And it's worth noting that processing flexiprims for collision constraints could be handled to different degress of precision depending on FPS or on visual proximity using a CLOD approach.

At the lowest level of precision, a flexible strand could be processed as just a single segment with physics constraints only on its free endpoint. When a bit more precision is appropriate, it could be processed as two segments articulated at their midpoint, and so on. I think there would be a lot of power and flexibility in that.

I'm not really sure how regular attachments would be handled though. I guess automatic rotation of linked prims around the attachment point in response to non-penetration constraint forces would be required.

Morg.

Would you need to add p2p comms to keep the clients in sync? It sounds a bit like llTargetOmega where no one sees quite the same thing.

Ed, I guess it depends on the application.

For the original two applications, namely as a way of keeping hair and prim clothing from penetrating into the av body (ie. just a cosmetic improvement), accuracy and sync are of almost no concern in practice. We just want to make a first-order correction to a pretty awful visual fault that we've been suffering since launch.

But for the general case of attached machinery, you're certainly right: we'd need to handle interactions between component parts and keep them in sync, which is a much harder problem. And the fact that this is client-side physics only (and it must be so, because sims can't cope with additional loading) is certainly an issue.

For my part, I'd be very happy to solve just those two simple cases, and anything else would be a bonus. Doing it with ODE would provide a very powerful weapon for future enhancements, so I guess those bonuses would come eventually.

Morg.