Fuel 's new websites (X-post) 2004-03-04 - By Brian Robbins
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
MUR is a bit better now speedwise with the improvements for MX 2004. I
actually have those optimizations in so if you're using the latest
shockwave, you'll have slightly better performance. (It's not great, but
better :)
> This is also one of my fears about MUR - whether inaccuracies acrue to
> allow this.
I actually spent a good deal of time this afternoon trying to figure out
where the problems are, and I think I've figured it out. I'm *pretty* sure
that there's nothing inherently wrong with MUR, rather it's a problem with
the geometry. It seems the most likely places to get through the walls are
where there is a vertical change in the ground, or where the wall isn't
perpindicular to the ground. What I'm doing is checking for the collision,
then using the cross of the isectNormal I "slide" the player along the
normal. If that sliding doesn't cause another collision then I move them in
that direction. I think what's happening is that this has the potential to
move people through the walls either when the normal isn't perfectly aligned
to the face, or when the wall tilts away from the floor. I haven't quite
worked out how to account for this though :(
> This kind of thing was the reason I ditched havok for collisions.
Interesting, I'm not using havok because of the troubles of keeping multiple
remote clients all with the same updated world. I haven't had any problems
with Havok having innacuracies (once you get it setup right). For instance
in the shooting gallery, we are using Havok.
> 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...
Well I'm already halfway there with moving scenery. The server keeps track
of time since it started, and when a client connects it sends that time to
each player. They then update all the animations to match that time. This
actually does a very good job of syncing environment animations across
clients.
> > 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
:)
One other thing which I didn't mention about using FlashCom is that only
sending updates to elements that have changed is built-in. I actually don't
have to worry about it all. I simply set the data on the user's
SharedObject every frame, and if it has changed then the Flash server stuff
tracks that it needs to be sent. If the variable hasn't changed, then it
won't send out an update.
> > 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.
I'll let you know when we start figuring this out.
> 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!
We have dual-monitor setups at the office, and I finally got an nVidia card
a few weeks ago. Through the nVidia drivers I actually have it telling the
OS that I have one monitor that's 2560x1024. This has GREATLY increased
performance for testing as I can now have true hardware acceleration on both
monitors, and OpenGL support again.
> 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 :(
I had thought about at least updating the vertical position of each avatar
locally, but it does require an extra MUR for each character each frame. I
actually had this in a few months ago, but I took it back out because I was
worried about performance . . .
> 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'.
Yeah, but try telling that to the sales guy who has to explain to the
potential client about why you can run through people :)
> > 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
You're right in theory of course. We have two separate styles of lifts
right now. 1 is the main elevator into the well. What happened before is
that if you and I are standing in the bucket (or you are and I'm watching)
then the bucket will start going down at pretty much the same time for each
of us, but we'll each see the other person trailing by half a second to a
second depending on lag. This means that I'll see the bucket go down or up,
with you trailing after it in mid-air.
The other method is that triggered lifts like the "freight elevator" near
the treehouse. This one is a keyframe animation triggered by walking
through an invisible wall. These are only played locally right now, and are
not sent across the network. I'm thinking about changing it, but it will
greatly increase the amount of traffic across the network.
The catch of course is that for both methods I not only have to have the
animations synced between users, but I have to start broadcasting what
geometry a player is standing on so they can be "locked" to it.
> 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 will take another look at this tomorrow and see what the differences are,
but what I'm suggesting is to take the method we're currently using, but
remove the forward interpretation of their speed. This should almost
completely eliminate the geometry penetration as the player's updates will
always match the actual valid position.
> > 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
:)
-Brian
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Dir3d-l mailing list
Dir3d-l@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
|
|
