Why Havok2 when Hacok3 is already out.

Ohh young grasshopper, this question has been asked before.

It is scheduled to come out right after the Linux client.

You mean the one currently in Alpha testing?

I can guarantee you the Havok 2 integration has begun. Andrew Linden has been working on it for some time, but its quite a bear. I'm amazed he's maintained his sanity through it.

As to the question of Havok 2 versus Havok 3, version 3 really doesn't bring any advantages to SL that don't already exist in Havok 2. As with most software, the biggest version upgrade is from v1 to v2; v2 to v3 versions typically don't have the major changes between a v1 and v2.

Regards,

-Flip

I am so joyed to see that out, and I don't even use Linux... maybe someday tho.

I was thinking back to what has changed.

Remember avatar and prim ghosting?

I personally don't believe they've even BEGUN Havok 2 integration. Look all all the other crap they've decided was more important than it. I mean, c'mon... we now know where ALL llDialog menus come from... oh, and we don't have hover tooltips unless we want them. And the water ripples now.

Linden Lab is full of hot air and I believe they are blowing their opportunity to BE the metaverse, and instead are creating a lag-infested vaporware of a product that is not going to deliver in the long run.

You mean the one currently in Alpha testing?

I was in Auto Assault beta. It uses the Havok 3 engine. It made me a sad panda. I want to see SL like that. Well minus running down pedestrians and setting them on fire. Wait... forget that last statement.

The Havok2 port was in progress (for the third time) several months ago and is currently stalled again. The problem is that the amount of work required to clean up the code and port the new physics engine is too big for the attention span of LL development process. Rather than tackle it as a monolithic project a fourth time we have to break up the cleanup work into smaller pieces that will go out with the normal updates. A small amount of this cleanup has already been deployed, however the first big chunk (a lot of work salvaged from the third port) hasn't been done yet -- I hope to get to that this month. There are probably two or three more initial cleanup stages that won't introduce any new features at all.

When we actually get around to making the port we'll most likely be working with Havok3 since Havok Inc is no longer 'supporting' Havok2. That's okay, since there is very little difference between Havok3 and Havok2, whereas there is a big difference between Havok1 and Havok2. The only thing relevant to us that was added in Havok3 is a feature called 'continuous collision detection' which allows for more correct collision details and prevents accidental interpenerations during the integration step of the physics engine. Unfortunately, it costs extra CPU cycles, and it isn't clear to us that we'll be using it (it can easily be disabled to fall back on Havok2 behavior).

Incidentally, we're thinking we might stop supporting 'joints' in Havok1 before we move to Havok3. Joints are buggy but very difficult to fix while supporting the legacy format, which is why we haven't fixed them yet. Joints are in desperate need of a complete redesign, and would be much easeir to re-implement after Havok3 rather than trying to provide legacy support during the port. Eliminating joints would remove a big chunk of the work required for the final transition from Havok1 to Havok3, making the whole project easier to break up into achievable pieces.

The Havok2 port was in progress (for the third time) several months ago and is currently stalled again. The problem is that the amount of work required to clean up the code and port the new physics engine is too big for the attention span of LL development process. Rather than tackle it as a monolithic project a fourth time we have to break up the cleanup work into smaller pieces that will go out with the normal updates. A small amount of this cleanup has already been deployed, however the first big chunk (a lot of work salvaged from the third port) hasn't been done yet -- I hope to get to that this month. There are probably two or three more initial cleanup stages that won't introduce any new features at all.

When we actually get around to making the port we'll most likely be working with Havok3 since Havok Inc is no longer 'supporting' Havok2. That's okay, since there is very little difference between Havok3 and Havok2, whereas there is a big difference between Havok1 and Havok2. The only thing relevant to us that was added in Havok3 is a feature called 'continuous collision detection' which allows for more correct collision details and prevents accidental interpenerations during the integration step of the physics engine. Unfortunately, it costs extra CPU cycles, and it isn't clear to us that we'll be using it (it can easily be disabled to fall back on Havok2 behavior).

Incidentally, we're thinking we might stop supporting 'joints' in Havok1 before we move to Havok3. Joints are buggy but very difficult to fix while supporting the legacy format, which is why we haven't fixed them yet. Joints are in desperate need of a complete redesign, and would be much easeir to re-implement after Havok3 rather than trying to provide legacy support during the port. Eliminating joints would remove a big chunk of the work required for the final transition from Havok1 to Havok3, making the whole project easier to break up into achievable pieces.

I'm not quite sure what to say about your post Andrew. Love the phrase "attention span of LL development process" - I'm not sure you mean what it implies, surely? Also, you say "Rather than tackle it as a monolithic project a fourth time". That begs the question as to why you've attempted it three times in that way if you know the cleanup that was needed and the attention span in development was sufficient to support it being done that way.

Your post is way too honest. I mean way too honest.

The Havok2 port was in progress (for the third time) several months ago and is currently stalled again. The problem is that the amount of work required to clean up the code and port the new physics engine is too big for the attention span of LL development process. Rather than tackle it as a monolithic project a fourth time we have to break up the cleanup work into smaller pieces that will go out with the normal updates. A small amount of this cleanup has already been deployed, however the first big chunk (a lot of work salvaged from the third port) hasn't been done yet -- I hope to get to that this month. There are probably two or three more initial cleanup stages that won't introduce any new features at all.

When we actually get around to making the port we'll most likely be working with Havok3 since Havok Inc is no longer 'supporting' Havok2. That's okay, since there is very little difference between Havok3 and Havok2, whereas there is a big difference between Havok1 and Havok2. The only thing relevant to us that was added in Havok3 is a feature called 'continuous collision detection' which allows for more correct collision details and prevents accidental interpenerations during the integration step of the physics engine. Unfortunately, it costs extra CPU cycles, and it isn't clear to us that we'll be using it (it can easily be disabled to fall back on Havok2 behavior).

Incidentally, we're thinking we might stop supporting 'joints' in Havok1 before we move to Havok3. Joints are buggy but very difficult to fix while supporting the legacy format, which is why we haven't fixed them yet. Joints are in desperate need of a complete redesign, and would be much easeir to re-implement after Havok3 rather than trying to provide legacy support during the port. Eliminating joints would remove a big chunk of the work required for the final transition from Havok1 to Havok3, making the whole project easier to break up into achievable pieces.