Why I consider "path finding" useless in SL, and what do people use it for?

[161488303349]

agree

[Mircea Lobo]

FireStorm is the main one, but it's extremely bloated and also slower and laggier so I don't like it. I currently use Teapot viewer. Both are viewer 3 based... I no longer care about viewer 1 so I'm only looking for those.

[161488303349]

Havok have license agreements with quite a few service/platform providers/makers

the core of Havok licenses is that they allow programs written by other developers (sub-licensees) to connect to and use a service provided by the licensee

other companies that have similar licenses are Microsoft, Nintendo, Blizzard, Autodesk, etc

what the license/sublicense dont cover is sub-licensees writing program/interfaces to another service/platform provided by others

eg. the Microsoft Havok license dont allow you to write a program for the Wii (for example) and be covered by the Microsoft license/sublicense. when you connect then you covered by the Nintendo license, not the Microsoft one. even if you dev your game on Microsoft

is the same for linden this. the linden Havok license doesnt sublicense for services provide by Nintendo, XBox, Autodesk, Blizzard, OpenSim, etc

OpenSim is in others camp bc is not owned by linden

+

is actual the same way that your MS SQL license does not cover access to Oracle or IBM databases. or vice versa

+

dunno why you never heard of this. maybe is bc you not much involved in commercial software development. or not interested

[Czari Zenovka]

---

Mircea Lobo wrote:

FireStorm is the main one, but it's extremely bloated and also slower and laggier so I don't like it. I currently use Teapot viewer. Both are viewer 3 based... I no longer care about viewer 1 so I'm only looking for those.

---

Thanks Mircea   This is the second time today I've heard mention of the Teapot viewer.  I'll have to check it out for curiosity if for no other reason...lol.

 

[Solar Legion]

---

Mircea Lobo wrote:

@ 

Solar Legion

: When OpenSim support was dropped, Linden specified that the reason they did that was because "The owners of Havoc would no longer allow them to connect to custom grids". Sorry, but am I the only one who finds that the one of the silliest claims in SL history?

Havoc does not work at Linden Lab. They make a physics engine library for games, which they then sell to game companies that wish to use them. They normally have no authority over the development of SL or what the SL code does. I'd be amazed if anyone over at Havoc even knows what Second Life is in detail, what a simulator is, what --loginuri does, etc. Sure, the owner of the Havoc library get to say "You can include my work with this project or not", but I've never heard of an external person having the authority to give orders to a project they don't work at or know anything about, even in order to allow usage of their library.

I still tend to believe this was just an excuse to cut OpenSim because it was ruining SL grid business. But in case I am wrong and what LL says was true behind closed doors, LL has was a very naive company to give authotiry to other corporations in the development of their project. Personally at least, I never heard of such a thing before. But as far as I'd understand, this makes Havoc part of the SL development team in that case.

---

Apparently you missed the part where Pathfinding is a part of the newer Havok Physics engine.

In short - you're barking up the wrong tree.

[Solar Legion]

And just in case anyone tries to say that Pathfinding is not a part of the Havok engine ....

I direct you to this technical document.

[Mircea Lobo]

I didn't say it's not part of it since I don't know about that. Problem is that until now, I've never heard of any project where including an external library gives authority to its developer to tell you how to code your own project, among the "rules" to distribute their library. For the Xbox example mentioned above, that is at least related to what platform you distribute your library on so it makes sense. But here, I don't believe any of the people at Havoc know what a simulator is or how SL even works. And to impose the removal of a parameter as simple as the --loginuri in that circumstance is silly. What would keep them from also telling LL "You can't use the latest Havoc code unless all physical objects affected by it are colored green", then Linden actually adding a limit for that in the viewer?

If I were Linden (which I'm not), I'd drop Havoc and switch to BulletX or ODE, which work great with SL (confirmed on OpenSim). The SL viewer is open source either way, so this would make sense. Bullet physics are used by commercial projects as well, and I'm pretty sure there are pathfinding systems for these also. But that's one of the last things that would qualify as a priority now, so nothing to hope for anytime soon.

[Innula Zenovka]

This was discussed at length over at SLU, back in August when the restrictions on TPVs' access to the Havok libraries were announced, with several leading Open Sim people participating.

The whole thread provides some interesting insights and background.

[161488303349]

is true that they could switch to Bullet. is quite a good physics engine now

back in the day linden tried to make their own physics engine. to hard given the resources available to them at the time. so they end up get Havok bc it was best of breed at the time

+

main problem linden got now in changing is how to do without breaking stuff

the whole truly opensource thing for linden was over when they decide way back to not opensource the server code. Cory Linden quit over that

one of the OpenSim projects is a physic engine based on Bullet. seems pretty good so far. has quite a few more things to do yet. but seems promising

like i say everytime that this comes up. is a good thing that OpenSim will break away from linden/sl cloning. i am encourage that to happen

 

 

[Jadeclaw Denfu]

I disagree here.

First, the platform is not Windows, Linux or MacOS - the platform is SecondLife.

Second, it is not possible to develop a product without knowing, how and where it will be used, so you can be sure, the Havok-people definitely know, what SecondLife and 3D-virtual environments are.

Third, a library supplier/developer can and will restrict, how the library is to be used. Ever heard of patents? Copyright?
If you knowingly use a patented method without a valid licence, damages can be tripled.
And if you do it commercially, the base rate can run up to a six-figure sum quite quickly.
Copyright lawsuits aren't cheap either. Especially in lawsuit-happy America.

Linden Labs has a licence to use the code and methods provided by the Havok-guys and has to follow the rules and terms
laid out in that licence. If that licence means, that the client side code & methods have to be restricted to the SL-grid only,
then so be it. And we have to accept it.

Btw. noone hinders the OpenSim-providers to develop their own technology or to buy a Havok-licence.

( I absolutely agree with Pamela Jones (of Groklaw-fame), that software and patents need a divorce - hard and fast, but that's a topic for another thread. )

 

[Solar Legion]

---

Mircea Lobo wrote:

I didn't say it's not part of it since I don't know about that. Problem is that until now, I've never heard of any project where including an external library gives authority to its developer to tell you how to code your own project, among the "rules" to distribute their library. For the Xbox example mentioned above, that is at least related to what platform you distribute your library on so it makes sense. But here, I don't believe any of the people at Havoc know what a simulator is or how SL even works. And to impose the removal of a parameter as simple as the --loginuri in that circumstance is silly. What would keep them from also telling LL "You can't use the latest Havoc code unless all physical objects affected by it are colored green", then Linden actually adding a limit for that in the viewer?

If I were Linden (which I'm not), I'd drop Havoc and switch to BulletX or ODE, which work great with SL (confirmed on OpenSim). The SL viewer is open source either way, so this would make sense. Bullet physics are used by commercial projects as well, and I'm pretty sure there are pathfinding systems for these also. But that's one of the last things that would qualify as a priority now, so nothing to hope for anytime soon.

---

Gee - from this response alone one would assume that you somehow thought Linden Lab had a direct hand or stake in OpenSim development or were somehow obligated to provide "support" (no kids, adding a bit of code to a client program to allow connection to "competitors" systems is not support) for them.

Further, it is quite clear that you don't have a clue how software lisence agreements of the sort Havok has ... actually work. Linden Lab is not allowed to distribute any part of the Havok code that is proprietary (or considered such) through their open source depositories.

 

 

Your statement concerning Havok making additional stipulations is utterly ridiculous. That is not how this sort of thing works.

Look, I get that you are irked about this but seriously? Stop being utterly absurd. Linden Lab actually following their EULA from the purchase of Havok is not the end of the bloody world.

[Mircea Lobo]

Gee, I didn't know it's so absurd to find it ridiculous that Havoc are telling LL what to do with their own code. Which is NOT the same thing as to WHERE you are allowed to distribute that work. Distributing is a different matter... of course the license can tell you where to do or not do that. But it's the first time when I see an external company affecting actual code development in another company's project directly, and clauses which are out of place being invoked.

Not allowed to distribute any part of the Havoc libs in their open-source repositories? Sure thing... THAT is a normal licensing situation. Having to remove --loginuri is a totally different story however. But really, I don't care about drama right now... and I think everyone made their point and thinks what they will.

[Solar Legion]

---

Mircea Lobo wrote:

Gee, I didn't know it's so absurd to find it ridiculous that Havoc are telling LL what to do

with their own code

. Which is NOT the same thing as to WHERE you are allowed to distribute that work. Distributing is a different matter... of course the license can tell you where to do or not do that. But it's the first time when I see an external company affecting actual code development in another company's project directly, and clauses which are out of place being invoked.

Not allowed to distribute any part of the Havoc libs in their open-source repositories? Sure thing... THAT is a normal licensing situation. Having to remove --loginuri is a totally different story however. But really, I don't care about drama right now... and I think everyone made their point and thinks what they will.

---

No drama to be had - simply correcting your mistaken impressions. Havok is lisenced for use by Linden Lab only. Their official client uses the Havok client side code (some of which is free to allow into the open source libraries, some of which is not - IE: The pathfinding code). To remain in compliance with their EULA for Havok no client which utilizes the Pathfinding client side code can be used to connect to any system not owned by Linden Lab.

How hard is that to understand?

I'm going to be quite blunt here: I - for one - am quite sick and tired of people taking non-issues like this and treating them as if Linden Lab started the Apocalypse. I'm sick of people bleating on and on about Open Sim being harmed by this or that .... Open Sim is not owned by Linden Lab. Heck, if Linden Lab owns all the patents and copyrights to the server code and other factors ... Open Sim's creators are lucky as heck that the Lab didn't shut them down the moment they became aware of what they had done!

The removal of the loginURL code is not a removal of support. Linden Lab never supported Open Sim. It is nothing more than Linden Lab acting to comply with the Havok RULA they were given.

This is not an opinion here - it's fact. Linden Lab could not keep that bit of code in their official clients, nor in any of the distribution libraries after upgrading their Havok Engine.

After all .... a great deal of Linden Lab's server code was reverse-engineered from the calls the client program has to make to the server system. If the Havok engine had more calls that needed to be placed in the client program ... how long do you think it'd be util someone managed to reverse-engineer a clone?

With the present implementation of Pathfinding (and here is where the educated guesswork comes in), it is likely that there are enough calls to the Pathfinding system in the client program to make creating a cone of that subsystem a possibility. So - the official client has the loginurl code removed. It is removed from the libraries. It is quite likely only a matter of time before Linden Lab tells the Third Party Client developers that no third party client can be made to connect to other systems without first removing all pathfinding code calls.

In short - no, it's not a different issue for the Lab to have removed alternate system connectivity from their code base.

[Innula Zenovka]

I don't think it's necessarily the case that Havok insisted LL remove anything from their code.   I think it's more to do with the kind of sub-licences Havok gave LL permission to grant.   

LL grants sublicences to use the Havok technology, according to the text of the subjicence agreement TPV devs must sign, on condition (among other things) that the "Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company."

A good way of ensuring compliance with that, it seems to me, is to make sure that devs have to make a special version of their TPV if they want it to be capable of connecting with other grids.   

[Mircea Lobo]

One thing I agree with there is that Linden was never obligated to support OpenSim in any way. That part is true. Of course, being aware that many people who use their viewer also connect there, it wouldn't have been that bad to show more care to them as well. Legally and as a company they didn't have to, but if LL was all that nice they could have been more caring (eg: Use a different approach for client-side physics, or still offer the --loginuri in a separate circumstance).

I'm an open-source contributor so I tend to think that way about everything I do (that the best approach must be used to make everyone happy). But 99.f% of the time that is not the case with companies, and it's only a few things that really matter there. Again LL is not obligated to OpenSim, but if they really believed in what they do with SL they could have considered OpenSim part of SL and its progress, not a project that's just tolerated there.

[161488303349]

if reduce to the fundamentals

GPL tell people what they can and cant do with GPL code. the rights to do this is the same basic rights that Havok have to tell people who use their stuff what they can and cant do

the outcome is different but the basic rights are the same

[solstyse]

---

Innula Zenovka wrote:

---

solstyse wrote:

For now, most sims I see would probably be best with pathfinding disabled.

---

Why?    What criteria are you using?  

I'm not saying you're mistaken; it's just I certainly wouldn't know how to reach such a diagnosis.   What figures should I be looking at, and what should lead me to say "this is the problem and the way to improve things is probably to turn pathfinding off, rather than to do something else"?

ETA -- the advantage of pathfinding,  from the scripting point of view, isn't that it lowers the script count (though it probably does) but that it performs some tasks considerably economically than the methods we've had to use before.     The sim is having to do a lot less work to acheive the same result, and it's also got dedicated resources for that task, so it's not cutting into the script time available for other tasks.   That's the bonus rather than the amount of memory you're using or not.

---

Well, my criteria is actually very simple.

1. Regions where objects are moving around, from what I've seen, are rare. Since this is what pathfinding enables, there is no harm in turning it off.

2. As more animals, etc. are created with pathfinding in mind, turning it back on would be simple, and when you're equipped to use it would be a better time to enable it.

3. I've seen many pathfinding errors on land, particularly after terraforming, that require a region reset. If you want to tweak your land, and don't use animals, maybe you can simplify things for yourself by not using it.

4. LL has a habit of rolling out features months before they're perfected. I expect no different from pathfinding. By waiting until later to enable it in your region, you can skip the "public beta testing" phase.

If you're looking for actual numbers, sorry, but I don't have any. And I'm not saying pathfinding is a bad thing either. But it is a feature that does things that not all sims need, and those that do probably aren't seeing the performance from it that they will 6 months from now.

[Phil Deakins]

You really need to accept that LL never did support OpenSim in any way other than moral support, and even that was many years ago.

You also need to accept that LL did not cut off support for OpenSim. There was no support. They changed something for ALL third party viewers, which included the OpenSom one.

And, finally, you need to accept that the ball is in OpenSim's court, and not in LL's court. OpenSim is free to do what the Firestorm people do - produce 2 viewer versions. It's simple, isn't it? The OpenSim people probably find it perfectly simple too, and that you are just one individual who is complaining alone.

Don't forget that the OpenSim people stole form LL by reverse engineering the server code. And also don't forget that it was the OpenSim people who unintentionally caused copybotting in SL, together with all the problems that has caused for many people. So stop bleating about the fact that OpenSim has been affected by something that LL did.

[Mircea Lobo]

Although it wasn't specifically supported by LL, it was a creation that grew on their technology and a lot of their (LL grid) users used it as well. As a developer I know you need to consider everyone who depends on something you created, even when you never had to support that as a company rule. Pretty sure that if LL ever broke something you liked, you wouldn't be feeling the same way. But yeah, no worries... we'll survive

Also, instead of seeing it as something who stole from Second Life by reverse-engineering the code, you could look at OpenSim as something that helped expand SL's horrizon as a technology. Supported or not supported, official or unofficial, it was and still will be an important part of SL as a whole, that things wouldn't be the same without for me at least. Just what I think.

[Phil Deakins]

Then, if OpenSim "wasn't specifically supported by LL", as you said, LL could not have cut off support for it, as you claimed at the start of this thread.

 

---

Mircea Lobo wrote:

As a developer I know you need to consider everyone who depends on something you created, even when you never had to support that as a company rule.

---

Generally speaking, there's some truth in that, but OpenSim is very different. OpenSim is a reverse engineered SL server, which was done for the specific purpose of becoming an alternative to SL. There has been no change since then - OpenSim is still used as an alternative to (in competition with) LL. I see no reason for any company to consider such competition when making decisions, especially when the competition is a reverse engineered (morally stolen) version of their own system. To suggest that LL *should* consider OpenSim when making decisions is ridiculous, of course.

In the early days, LL expressed moral support for OpenSim but that was when LL intended the SL system to become open and widespread and, to that end, they'd stated their intention to release the server code. Over time, that changed and now OpenSim provides the means for people to directly compete with LL.

 

---

Mircea Lobo wrote:

Pretty sure that if LL ever broke something you liked, you wouldn't be feeling the same way.

But yeah, no worries... we'll survive

Also, instead of seeing it as something who stole from Second Life by reverse-engineering the code, you could look at OpenSim as something that helped expand SL's horrizon as a technology. Supported or not supported, official or unofficial, it was and still will be an important part of SL as a whole, that things wouldn't be the same without for me at least. Just what I think.

---

LL didn't break anything for OpenSim.

OpenSim didn't "expand SL's horizon" in any way whatsoever, and it never has been a part of "SL as a whole", let alone an important part. OpenSim is completely seperate from SL. The two don't meet or connect in anything, and never have met or connected in anything. You are making the mistake of thinking that, because you like both OpenSim and SL, both of which look the same, they are each part of the whole. For you they are part of the whole, but that's nothing to do with SL and its users. For SL and its users, SL is the whole.

 

ETA: LL did an inter-grid experiment, where an avatar successfully TPed from one autonomous grid (SL) to another autonomous grid (IBM). I don't remember if an OpenSim grid was used at the IBM end or not, but, even if was, it was a very long time ago - back in the days when LL still intended the SL-like system to be open and widespread. If it was OpenSim that was used at the IBM end, then there has been a very short-lived connection between the two but it makes no difference to this discussion. It was a very long time ago and LL have a completely different mind on openness now.

[Innula Zenovka]

---

solstyse wrote:

Well, my criteria is actually very simple.

1. Regions where objects are moving around, from what I've seen, are rare. Since this is what pathfinding enables, there is no harm in turning it off.

2. As more animals, etc. are created with pathfinding in mind, turning it back on would be simple, and when you're equipped to use it would be a better time to enable it.

3. I've seen many pathfinding errors on land, particularly after terraforming, that require a region reset. If you want to tweak your land, and don't use animals, maybe you can simplify things for yourself by not using it.

4. LL has a habit of rolling out features months before they're perfected. I expect no different from pathfinding. By waiting until later to enable it in your region, you can skip the "public beta testing" phase.

If you're looking for actual numbers, sorry, but I don't have any. And I'm not saying pathfinding is a bad thing either. But it is a feature that does things that not all sims need, and those that do probably aren't seeing the performance from it that they will 6 months from now.

---

 What sort of errors are these that you've seen in point 3 that require a region restart?   All I've seen are messages that the Navmesh has pending changes, which anyone with building rights can force the region to commit (or which the region itself commits if you leave it for 10 minutes or so).   See this section of the wiki article on Pathfinding Tools in the Second Life Viewer.   What icon are you seeing that you interpret as indicating "pathfinding errors"?

Everything I've read, you see, leads me to think the ideal state of affairs would be have pathfinding turned on, having first optimised the region for pathfinding.    The disadvantage of having pathfinding turned on in a region that's not been optimised is that the pathfinding objects won't work as well as they should but won't, or shouldn't according to Maestro Linden (who normally knows what he's talking about) , cause any noticable hits to sim performance.   

That's why I'm querying your statement that "most sims I see would probably be best with pathfinding disabled".   I would agree with "most sims I see would probably be best with pathfinding optimised" but I really don't there's a huge disadvantage to having it turned on.

[Mircea Lobo]

Each with their own opinion and way of looking at things I guess. Some clarification though: Although OpenSim is intended as a server for virtual spaces and multiple viewers, I personally used and saw it as a server-side for Second Life, so people could run their own sims on their own grids freely.

But since you mentioned that, I was also thinking of those days when I heard some Lindens were working to allow teleportation between OpenSim grids and SL's. Back then we were hoping they would go all the way through with that, but sadly it ended up at this instead.

[Innula Zenovka]

The thought of having teleportation between grids fills me, as a content creator, with horror.   

[Phil Deakins]

I think the main reason the idea was abandoned by LL was the inventory. I don't think they could come up with anything like a secure way of handling an avatar's inventory. I.e. if an av's inventory went with the avatar when jumping between grids, it could be stolen, or object permissions changed and stolen, etc. Thne owner of the destination grid could steal it, even without the avatar knowing anything had happened. And those grid owners could be absolutely anyone. I may be mistaken but I think that's the main reason why LL abandoned the idea. I think the idea filled LL with horror too

[Phil Deakins]

---

Mircea Lobo wrote:

Each with their own opinion and way of looking at things I guess. Some clarification though: Although OpenSim is intended as a server for virtual spaces and multiple viewers, I personally used and saw it as a server-side for Second Life, so people could run their own sims on their own grids freely.

---

Yes, for you the use of OpenSim and SL are parts of the whole, but that's you, and no doubt there are others too. But SL is totally seperated from OpenSim, and OpenSim isn't a part of 'the whole'.

Some years ago, I had a few OS sims running locally on my computer, and I have to say that it's good for creating offline, prior to creating online, if that's the way a person wants to do it. It's an excellent way to avoid the problems that are present in sandboxes, and it must be an excellent way to test things like animations and textures before uploading to SL. But it doesn't make OS a part of the SL whole, anymore than using PhotoShop makes PhotoShop a part of the SL whole.