Joints?

We're considering the possibility of removing 'joints' in Second Life as they seem to be rarely used.

If you think that we'll break something you've built if we remove joints as an option, can you please let us know? Just post here -- we'll keep an eye on responses.

Thanks!

Noooo, don't! Darko will cry!
(fine with me, I didn't build anything "jointy"

I tried working with them a few times - but for the most part they were buggy..

that being said I know some folks have used them to make some cute items with them including windchimes and tree swings.

Why remove them? Why not make them more functional?

I have three items in a popular product that uses joints. But they're far from essential. Now what I say and what the people who own my product say is another thing.

I wonder if it's possible for somebody to write a script to simulate joints?

Somebody phone Jeff Gomez!!

If it means a speeded inclusion of Havok2 (not having to have backward compatibility with borked joints), then by all means, rip it from the client.

Joints invariably end up broken/crashed/whatever. Nuke 'em until Havok2 fixes them.

Exactly. They aren't bloating the system by leaving them there... I don't think they get used much because they're not really functional enough at the moment.

Could be a good feature though. I can already think of a few builds I turned down simply because there wasn't any way to build them without more sophisticated joints.

Indeed. I would venture that joints are rarely used not because they're not needed, but because they're not very functional in their current state.

However, I echo other remarks in this thread. If ditching joints means speedier development of Havok 2 integration, kill the joints and re-introduce them at a later date if such an introduction makes sense.

I think it would break the windchimes Beatfox produced. Which would be a shame, I love mine. ;.;

On the other hand, Havok. Finally!

The Wizard of Speed and Time couldn't make Havoc 2 come any faster - it's Godot.

Nowadays when I hear it invoked it just makes me laugh.

I remember the announcement that it was running on a testbed and looking good (from Andrew I beleive) - I think that was over a year ago.. maybe longer.

Until corrected I won't beleive Havoc2 is coming before either the release of the Havoc 6 engine - or SecondLife 3.0.... whichever comes first.

Kinda like Michi and sitting?

Why not just make them work but expand and improve them so that you can use hierarchically linked joints?

All sticks, no carrots.

Even the orientation island uses joints.

There must be someone in the world who can do the math to improve joints. Hire them!

Robin may actuallly not realize, the reason people don't use joints is partially that they are very limited but mostly that they work terribly.

Properly functioning joints, no more powerful than what currently exists, would be used a great deal, especially if there was so good simple to understand help info on how to use them built into the UI.

Properly functioning joints that could at least be made into simple linear "chains" would be used a great deal.

LOL - them were the days!

And yet look - still no default override for anims in the UI!

Won't that break The Gates of SL?

They make for some fun particle-trail experiments.



Really though, if it will make SL better, guess I can do without.

-Ghoti

I didn't see Robin say anything about "joints" OR Havoc2. Make "joints" work rather than take them away. The hammock i have in a tree would move more realistically if the "joint" feature worked. I would think that the videos people are creating could use "joints" to add to their effects as well. I vote for making them more functional rather than doing away with them.

Although Rudy Rucker's Master of Space and Time might be able to.

Anyway, on to the question - there are precisely two (2) serious things in SL I have personally encountered that use joints. And while it would be a shame to have Beatfox's Windchimes break and the Gates of Second Life no-longer viable... I wouldn't lose sleep.

Here's why. Look at the third paragraph of this post.

Just farking do it. We've seen this faux solicitation of customer input already and it is insulting to LL and your customers.

You've made your decision, execute it. I once knew a manager who insisted on having "buy-in" from his staff whether they were in agreement or just feigned it because they were tired of being lobbied by their boss. He accomplished nothing.

Based upon the answers in this thread, it seems that unless there is some compelling reason (as in the buggy joint code causes performance problems even when joints are not used), there seems no good reason to remove them. The emphasis should be on fixing them. Why the sudden urge to remove them after all this time? Understanding the motivations behind removing them may help people to be more accepting of the idea - but without more information, it doesn't seem to make much sense to remove them, even if they are minimally used.

Why not try and make it work instead of giving up on it?

Or is it too difficult?

Thank You for asking. Remove them please.

I think if a reason WHY is given everyone can make a more objective decision.

*IF* the reason is for a port of Havoc 3 and would make that happen smoother - I don't think anyone would complain too much (although we would have to endure posts about mythical prim increases - higher vehicle prim limits - and ragdoll avatars... none of which will probably happen)...

If its just a carpet 'do you think this is a good idea - just because' then folks are gonna have a much more subjective viewpoint.

Thanks for posting!

I don't see anywhere where this is related to havok.

Rick posted a link at the top of the page - a post by Andrew (which probably SHOULD have been linked to by the OP.. again *IF* this is the reason).

Script scheduler pretty much smashed that against the rocks I'm afraid. At least, for procedural joints. Which still work but grossly out of sync now.

Scripted joints with llMoveToTarget could work for simple things, though. Would be nice if we had more power over that at the backend, though. *cough*