Fuel 's new websites (X-post) 2004-03-04 - By Barry Swan
Back
> Actually there's very few proxies. In most cases I'm doing
> modelsUnderRay() against the actual geometry that you see.
> There's a few places where we have proxies, most notably the
> rails on the treehouse, and all the cacti.
Ah that's cool - I'm thinking of trying out modelsunderray again - I'm
happy with my own lingo jobby, and it's faster, but it's also got
limitations I'm not happy with - as you may have noticed, the obvious
one is only AABB, which is a bit of a pisser, I want freeform landscapes
:D
> I'm also casting 3 rays per movement, more or less
> corresponding to the body position, and the two shoulders.
> This provides a reasonably decent collision detection, but
> it's definitely not perfect. If you really want to, you can
> squeeze through some of the walls :(
This is also one of my fears about MUR - whether inaccuracies acrue to
allow this.
This kind of thing was the reason I ditched havok for collisions.
> In general I've found this to provide the best overall
> movement, but as you noted it's definitely not perfect. The
> biggest problem we had was actually with the bucket elevator
> going down to the caves. Our current method provides the
> best display of that case . . .
Ah yes, interacting with scenery. I've not got moving platforms or
anything, so I've yet to cross that bridge.
Interactive scenery itself is simple enough, but moving things...
> Until a couple days ago I had it set to 4, but I recently
> changed it to 8. This is definitely something that I'm
> playing around with. Fortunately because we're using
> FlashCom, updating this is as simple as changing 1 line: setFPS(X)
That's nice, although mine's not hard to change either ;)
Merely a few 1000 lines or so :p
> The systems are
> in place for us to arbitrarily limit the number of people who
> can be in each junkyard "room" at one time.
I have the same setup, so I'd be reaaaaaaaaally grateful for any results
you find out.
> Internally we've had 12
> people logged in at once with a good experience for everyone.
> I'm hoping that we can keep it around that limit or more for
> the public at large.
I've got it at 8 for the mo because it seemed 'reasonable' (although
obviously big is always better).
This is actually a throwback because I'm building on my FPS engine,
where there was a maximum of 8 bots ;)
Part of the problem is I don't have many people to test with- I can
open half a dozen connections from my computer but of course that has
it's own framerate issues!
> I'm not sure exactly where the server is located. North
> America, and I believe East Coast, but I'm not 100% sure.
> It's too bad the experience wasn't very good for you. How
> many people were on at the same time?
Not a clue, not too many, maybe 3 or 4.
I wouldn't worry particularly unduly though, given my location.
Having said that I tend to get a smoother output on my own chat, but
again that could be for a billion other reasons.
The server in that case is located in Norway. Movement is pretty jerky
(I've not put all the interpolating code in yet), although because I
don't extrapolate I'm not seeing walking through scenery.
If course, if we had engines that ran fast enough, we'd be doing
collision for the other avatars locally, which would improve it
massively. I doubt either of our engines would tolerate that
particularly well though :(
> Also, did you try out Blackjack?
Didn't try it no, must admit I didn't spend more than about 5 minutes
running around. Still in work hours here :)
> Yeah, again this is something we keep going back and forth
> on. There's just something strange about being able to walk
> through and/or stand on someone though :)
I agree, but collision with moving lagged avatars is a pain anywhere -
if people like John Carmack cant get it perfect, I feel no shame in
'leaving that for another day'.
> Yes, if the environment is setup right for it, this method I
> think will give you the least amount of visual errors for
> users. Unfortunately we have several elevator objects and
> the visual inaccuracies are VERY noticable.
How come? Could you sync the lift starting to the player who triggered
it's update?
How about if when you trigger a lift, a timer is started.
Then the next update to the server you send includes not only the
'triggered lift', but how long from when it started to when the update
was started? This would then give all the other players an offset into
the lift movement which should (in theory) sync with the player
movements. It's all theory of course :D
> However, it looks like I may need to go back to a system more
> like yours, and just put in special case instances for
> elevators that will "lock" remote avatars to the ground they
> are on. I was hoping to avoid that . . .
Yes, special cases are the bane of my existance :(
> I'd suggest setting up a system like ours where each remote
> user has a target transform, and is constantly moving towards
> it. This way all remote movements are smoothed out, and it
> should greatly reduce any jerkiness.
Well it depends. Assuming someone is constantly moving, I see the avatar
constantly moving, changing speeds.
Quite a lot of the time this avatar will be intersecting some level
geometry.
On mine, what I see is: The avatar changes speeds a bit, but does NOT
constantly move. It's very rare that the avatar will penetrate scenery
though. I'm working to remove some of the speed changing and stuttering
(or rather I've planned it but not coded it) - it'll never remove
entirely the ability to stop, because to avoid that I'd have to
extrapolate and we are back to penetrating scenery :(
> I would hope so. As I mentioned we're using FlashCom and I'm
> not sure how well MUS TCP would work for those speeds.
It's not so much the relative speed of Mus of Flashcom code execution,
but the packet send speed - but I think flashcom uses TCP the same as
MUS so in theory it should be the same. UDP now, if only :D
> Looking forward to seeing it!
I'm having fun walking through my FPS level with other people, that's
for sure, but apart from that it's pretty much 'dogs dinner' astheatics!
Functionality at the moment....
Barry
gerbil@(protected)
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Dir3d-l mailing list
Dir3d-l@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
|
|
