setting up Collision

#1 Ok .. maybe that is not a good question?

a quick description on how the collision should be setup for such an object would help

#2 heh, i been looking into this some what also, only for elevators and not like you have,

i havent tried it yet but have came up with a theory using the existing ai code and waypoints for movement ,and since most of that has areaddy been coded and scripted some what, the hardest thing would be to setup the door/elevator model as an ai charactor.

does that make sence?

#3 no :)
err
the ai has no waypoint, path following code ..
in fact there is none in the engine

easy fix..
the door is ready to go exported from the *.map editor
I have all the relationships setup ..
everything is workin nice ..
now I am gonna finish collision...

without anyone's help or even suggestion no input whatsoever ...
all I can say is thanks to everyone who read this :)

ive decided it dont matter how I setup the collision
cause noone cares anyhow.. it dont seem like gg is interested in doors atm .. or at least not im my doors
so ill figure it out then ill have it going ..
maybe ill post a screenshot

anyhow thanks for taking the timeout to leave that input :)

#4 Ah. But Badguy... many of us ARE very interested in any door implementation, since there isn't one at all atm. I would love to see what you have. I just fear I would have nothing useful to contribute other than a sincere 'thank you'.

#5 Don't get frustrated.
I've felt like people just ignore things I've posted before too.
Sometimes posts get overlooked because they're bumped right away and not every one goes back and reads all of them. I know I don't have time to read every post.

I'd be interested in the use of doors. Once doors are implemented I'm guessing other things would be possible too. Like different types of "movers".

Hang in there.

#6 Ok .. well I would like to finish them before posting them..
but maybe I should post them before finishing them?
that way I could get some help with what im working on

I cant seem to find the easy way to patch my matrix across the Interior relationship's

I cant seem to get the collision to work proper at all when having it all inside the InteriorMoving class

.. something to do with the object pointer in the InteriorConvex when prepared on the InteriorMoving side

these Will be and Are advanced movers already ..
with the ability to calculate angles for a rotation object or a simple path following object ..
I plan to take on path rotations with a moving object after all this other stuff is sorted out..

#7 It'd probably be a good idea to post what you got and try to get some help from some other programmers. I know I haven't even looked into the issue. I've been concentrating on learning the scripting right now. I'm sure there's got to be some others that could help you out once they see what it is you're trying to do. I think a lot of people would like to have "door" objects in their games.

I'll be gone for the weekend, getting the cycle out :)
Hope you can generate some more interest in this issue.

Good luck,
Sabrecyd

#8 I just want to say that I am interested in this code. I see you getting discouraged, and I wish I had some advice or help to offer. All I can say is Thank you for your efforts.

#9 Ditto what Bruce said. Don't give up.

#10 Ok I think ive figured most of it ..

I have all the collision owned by the InteriorMoving

now I need to find out if

Box3F convexBox = mConvex->getBoundingBox(mMatrix, getScale());
mConvex->updateWorkingList(convexBox, sCollisionMoveMask);

will do what I need
and if this is the case then I need to learn how to use these proper .. then I think it will be handled :)

#11 So, to begin with, a Box3F object is an axis-aligned box. getBoundingBox returns one of those, but exactly what defines the box can depend on what derived class of Convex you are invoking it on.

If mConvex is just a base-class Convex object, then the behavior of that getBoundingBox code is to take the bounding box of the object in objectspace, transform and scale it into world space, and then return the axis-aligned bounding box in world space that contains it.

If mConvex is ShapeBaseConvex, basically the same thing, but it looks like the pretransform bounding box is generated from one of the object's collision meshes, according to LOD.

Etc. So one thing we'd need to know to figure out exactly what that code is doing, is what the type of mConvex is.

But basically, getBoundingBox is always going to return an axis-aligned bounding box around your object. And if your door is fairly large and moving fast, this may not be sufficient for creating the working collision list. The query box has got to be able to touch any object that the door might touch over its next tick of movement. So if you just set the query box to enclose the door's current position, it might not find an object that the door would hit only after it had moved partway through its range of motion for the tick. See my thread about item collision, where the query box is large enough to contain everywhere the item might move to over the coming tick... you'd want to do something similar for any other moving object.

If your collision isn't working at all, then this is probably not the only problem, but it is likely one of the problems. Maybe if I could see more of the code and exactly what is happening I'd have more ideas. I'm just now starting to look at this sort of thing myself though.

#12 Joel :
thanks
collision is good and works but if i move the door the collision hull does not move ..

so if mConvex is indeed an InteriorConvex(cause it is),
and that the getBoundingBox has returned the aligned box then can I assume that the call to updateWorkingList
for that mConvex will modify the mConvex box ?

if so then it must be the way im operating things and it will be time to post more code :)

the mConvex is setup in buildConvex just like it happens in InteriorInstance::buildConvex(..) one could watch it happen there

so for each hull in the interior object (which is the actual door) I create a mConvex and add it to a list

then later in say the new processTick I would call the updateWorkingCollisionSet()
where I would then use the afore mentioned functions to hopefully update the list I created but this is where it doesnt seem to go all the way .. as debugging shows it Does indeed create a new box that is indeed repositioned from the matrix but to no avail.