This content has been marked as final. Show 12 replies
if you need a proper collision detection, i think the best way would be to go with havok and invest some time into getting it to work. If you set up everything correct the box should defenitely fall to the ground :)
Use dashpots or springs to get a grip on the box. you can move the havok controlled body only by forces, impulses, springs, dashpots ... take a close look in the havok reference, it's worth it.
to set up a proper box collision with rays you can use a "trick" by sending the rays not exactly into the direction of the models axis use vectors like "vector(0.0001, 0.9999, 0.0001)" - search the forum for more informations on this topic.
If you go with havok, it would be nice to get some more details about things that you want to do, and where you run into problems.
Hi, thanks for that. I did spend a little time with havok, making the 'load' held by dashpoints, but it was really buggy and ended up going with rayCasting. If I get time nearer the end, I will try and have another go...
The rayCasting works ok on my machine (3ghz 1GB RAM) if I send out plenty of rays, but the users machine is a 3ghz with only 256RAM. I will need to test it out on theirs before making a decision. Unfort, I can't test it on theirs for a while, and am not allowed to post the product up.
Will look at your 'trick' - do you know of any tutorials that mention it?
this is a short version of the "phenomen":
If you want to more optimized raydetection use the propertylist of the ray. in this way you can optimize by distance and by a list of models that are checked by the ray - think you know this allready... otherwise take a look at the livedocs about modelsunderray.
Hi, thanks for that.
I have been using an optimized ray but I don't think its doing what it should. The options list is as follows:
-- build your optional argument list
tOptionsList = [#maxNumberOfModels: 3, #levelOfDetail: #detailed, #modelList:tModelList, #maxDistance: 5]
And am calling this in the 'controlCollision' function.
tPosition = dB.worldPosition
tDirection = -(dB.getworldtransform().xaxis)
tList = p3DMember.modelsUnderRay(tPosition,tDirection,tOptionsList)
if (tList.count) then
If I do a 'put ("hi")' in where I have above, it gets called all the time. I would have thought this would only be called if an object on the list i declared was within 3 of another object. But does not seem the case....
It is possible to achieve very acceptable resutls with modelsUnderRay, and I would only advise using havok if you really require a full physics simulation (eg, you want tumbling balls and boxes falling in a realistic way or something!).
To align a model to a vector (such as your ray cast vector), you can use something like this:
tiltAngle = vector(0,0,1).anglebetween(theVector)
tiltVector = theVector.perpendicularto(vector(0,0,1))
theModel.transform.rotation = vector(0,0,0)
To align it to a ray vector, and display it correctly, if your model was a 'box' from director's default box primitive, you would then want to position it halfway between the ray cast source, and the ray intersect position (because the box's origin is in its centre), and scale it so that it extends the full distance between the two.
Luckily this is actually a frequently asked question, and something that I do quite a lot myself - so I happen to have some demo movies showing it in action!
First here's some roughly compiled information about modelsUnderRay(), mostly advice I've given out on various director mailing lists in the past:
And here are a few demos of how it can be used effectively (including one with visible beams as you described!)
fist of all, you will only need: #maxNumberOfModels: 1, this will make anything three times faster.
maybe you should "put tList" instead of "put "hi" to check if the list is really empty.
May I ask how big your models are? you should use for best results words where 100 units are 1m. This will make all calculations more precise because the 3D engine has a fixed floatprecision of 4.
At the moment i think the #maxdistance property has something to do with the "boundingsphere". Maybe someone here does know how the #maxdistance really works. Would make sense if it checks if the models boundingsphere is within a given distance before it will process the ray calculation...
your code seems like it should work?
whoops, I thought this was the thread about setting objects to make raycasts visible - same poster, but different thread! My previous post was mainly to do with making rays visible but maybe its relevant to this thread too.
hondo3000: will have maxNumberOfModels: 1 - thanks
Have tried having tList instead of "hi", but it brought up loads of things wayy too quick for me to read and hung my computer.
I'm not sure how big the world is to be honest. Will ask the person who modelled it later.
The code does work, i'm just wondering why it was bringing stuff on the tList all the time rather than when something is close to it.
Duckets: Thanks for those examples, and you helped in both posts with the same example. I'm gonna have a go at implementing this on monday and will let u know how I get on.
For now, have a good weekend
Hey duckets, thanks for that code. Got it working on the crane and is great. Really good to actually see where the rays are going!
One issue I do have is regarding the direction. i.e.
tDirection1 = dA.transform.yAxis (dA is a block i am shooting ray from).
When I rotate the group this block is on, it keeps shooting the same way, and not the new rotated direction. What am I doing wrong?
e..g If I set it to shoot towards me, then turn the load, it keeps shooting towards me.
the ray origin and the ray vector aren't inherently tied to any particular object - so rotating an object won't affect where a ray is shooting from.
If you're calculating your ray's vector from dA's rotation, you'll probably need to get it's 'world transform' as opposed to its local transform. If you're rotating an object up the hierarchy from dA (eg, its parent group), then although dA moves as a result, its own local transform values won't actually change. Its world transform will though. You can get an object's world transform like this:
worldXform = dA.getWorldTransform()
hope this helps.
Hi thanks for that. Kinda get what you mean. How would I get just the Y value though. I used the line you said and its shooting the rays down, but not out in the direction I want.
Don't worry, got a way of doing it.
tPositionA = dA.worldPosition
tPositionB = dB.worldPosition
tPositionC = dC.worldPosition
tPositionD = dD.worldPosition
tDirection1 = -(tPositionB - tPositionA)
tDirection2 = -(tPositionB - tPositionC)
Got the world positions and used them to get the vector.
Cheers anyway, hope this works better. An thanks again for the code to show the rays, help soooo much!