NewtonWorldRaycast - Is the ray infinite? [1.53]

[sybixsus]

Hi,

I'm using Newton via another engine (Truevision3D, as it happens which implements Newton 1.53 as it's Physics Class) and I'm having a lot of problems with raycasts. That is to say, I'm getting collisions being missed and incorrect collisions being hit when I raycast. To be specific, I'm getting hits which are in the opposite direction from the start point, as if the end point was StartPoint+(EndPoint-StartPoint). I can't see to find any pattern to when the rays are cast in the "opposite" direction.

So what I'm wondering is whether this is a bug in Newton or a bug in TV3D or something else. The TV3D developer suggested that it might be that he needs to check the results are within the segment of the ray that I chose to cast. Or at the very least, give priority to those results over results which are not part of the segment. I don't want to give him unnecessary work though, or have him slow things down checking for things which shouldn't exist.

So before I press him to do that, I'd like to know for sure whether NewtonWorldRaycast is an infinite ray and whether it could, should or would pick up results in the opposite direction. For example, if I provide (10,0,0) as my start vector and (20,0,0) as my end vector, is it even possible (theoretically) that Newton should give me an impact at (5,0,0) when there was no collision in the segment I provide? If there was a valid collision at (16,0,0) [Further away than the reverse impact] or I guess in other words, are the collisions you return all in the segment I ask for or are they from a full infinite ray?

[Julio Jerez]

Hi,
I'm using Newton via another engine (Truevision3D, as it happens which implements Newton 1.53 as it's Physics Class) and I'm having a lot of problems with raycasts. That is to say, I'm getting collisions being missed and incorrect collisions being hit when I raycast. To be specific, I'm getting hits which are in the opposite direction from the start point, as if the end point was StartPoint+(EndPoint-StartPoint). I can't see to find any pattern to when the rays are cast in the "opposite" direction.

I keep hearing people saying Newton is this, Newton is that, and each time they are still using a version the is 4 years old, yet they want tyo be competive with engien tah are update amost weekly.

This is a well known bug in 1.53 that was fixed about 3 years ago for 2.0.
In some cases a ray can pick a body that is in a cell of the mutigrid bradphase, but it is behind the ray origin.

The only solution for the is the that to update to 2.0x
Updating to 2.00 is a task that should not take more tahn a day of work, and the pay off is about four fold.
Everty single feature had being improved and the are a whole lot of new ones.
In particular RayCastinmg and convex casting is about 4 time faster and it is perfect in 2.0 since it is a feature that is use a lot now.

[sybixsus]

If it were up to me, I'd be using Version 2.0, but I'm stuck using the version that the TV3D developers implement. I will do my best to nag them into updating soon. Thank you for the quick and clear reply.

[tiresius]

Hi Julio-
I know this is a very unpopular opinion among Newton people on the forums, but will there ever be any chance of having some things fixed in the 1.53 version? Perhaps bugs like the one mentioned here with Raycast and any other well-known bugs? If they are well known perhaps the fix will also be well known (easy to add)? Unless the fix requires a massive change that was part of getting to 2.0...
I understand Newton Game Dynamics has a small dev team. And you can't move forward with development of the engine if one of your feet is stuck in 1.53 (API of 4 years ago). But some of us are almost completely stuck in 1.53 for one reason or another and it would help us out a lot if some of these fixes can trickle down to us.
Again I'm not complaining about how you run things, just wondering if there is any chance. Thanks.

[JernejL]

tiresius: just wondering what's the reason you need to use 1.53? because with newton 2 you won't only get fixes, but also greatly improved performance and new features - like convex cast. You really should try to move on to the beta, the newton 2 code is stable and 2.04 has no show-stopping bugs and in my opinion is is mature for "production use".

[Stucuk]

Fixing bugs in 1.53 would slow down development of the 2.0 range. 2.0 Range already has fixes for all known 1.53 bugs(And as Delfi stated its stable. Proberly more stable than 1.53 is). It would be a waste of Julio's time to work on older versions. If your forced to use 1.53 because your using an engine which only has 1.53 in it then you either have to bug the people who made the engine to upgrade to 2.0 (Which should be painless) or you will need to switch engines if you want bugs fixed.

[tiresius]

what's the reason you need to use 1.53?

I have a long-term, large project in Darkbasic using the Newton dll wrapper that Walaber started 5+ years ago. I've been working with the project on and off since the wrapper was available in 1.23 or so. The latest was 1.32 from 3+ years ago until recently I (reluctantly) updated it to version 1.53 for the bug fixes Newton has done. It still has the standard vehicle joint and ragdoll joint, and they work pretty well. These two things have changed quite a bit in 2.0.

I'm still learning C++ to the point where I can figure out more about Newton itself but it is not coming that easy for me. Perhaps I am being a lazy programmer or enjoy being in my "comfort zone" but I would much rather work on my main project in Basic (a game using Newton) instead of working with Newton itself in C/C++ and wrapping 2.0.

I just want to reiterate that I appreciate all that has been done with Newton and don't want to seem unappreciative or greedy of anyone's precious time. Newton has let me do things that would have been impossible for me to do on my own no matter how much I would try. My own project does not use ragdolls or vehicles and I can get by without the 6DOF joint (as long as the stock joints don't get deprecated). So if I have to wrap most of Newton 2.0 (the interface part that has stayed similar) then I probably can after a months hard work. But the rest of the Darkbasic world is really mostly interested in new character controller, vehicles, and perhaps ragdolls. I would have to spend a lot of time with C/C++ and a lot of time with Newton to get those in so everyone is happy. I'm starting on the new tutorials but have a long way to go.

then you ... have to bug the people who made the engine to upgrade to 2.0

That would me be.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hope I don't sound like a whiny noob programmer, I'm just trying to explain my situation. I know the answer is to stop complaining, stop delaying the inevitable, and just buckle down and learn C/C++ really well. But I get little joy from working with that language. I only use it when I have to. If I find a showstopper bug deep inside Newton.dll 1.53 that stops me from completing my large project, then I will have to do just that.
(And sorry for hijacking the thread sybixsus.)

[JernejL]

tiresius: that is completely understandable, but since interest in newton is big in darkbasic you could have several people work on different parts of the wrapper, i'm sure you would get people to help you with that.

[hpesoj]

As a former DBPro user I look back at the forums every now and again, and even though I rarely use the language any more, I have on several occasions considered writing a wrapper for Newton 2.0; however, these moments quickly pass as I realise I have many other things with which to occupy myself.

I tend to have a habit of commiting myself to projects for which I have no real motivation, but I figure I should be able to help if you wish to write a wrapper (I have written small DBPro plugins in C++ before, it isn't very hard). Once you have a template, it should be a fairly straight forward (however, it may take some time ) to wrap the entire thing. The only area that may be less easy is accessing mesh data for convex hulls and tree collisions, although I seem to remember that you can use memblocks to that effect (though there may be a more efficient way).

I'm not making any promises, but p.m. me if you are interested.

Joe