fholm

Thank you for that presentation! That was great. As it turns out I was on the right way (using vertex normals to push the vertices outwards). I'm working on implementing the fading part of the technique they talk about it the presentation, more specifically this is said:

To make the character more visible, we sample the depth buffer and fade the shield as a function of the distance to the shell.
So the nearby areas (likely the character) become more transparent, while the farther areas (which are probably the background) get the full effect.

The shield here is the enlarged mesh.
The shell means the original model (I assume).

I am well familiar with sampling the depth buffer, but how would I calculate the distance to the shell from my current pixel based on the value from the depth buffer? there is no way (I can think of) to know if the depth value comes from the original model or from another player, a wall, etc. ?

It looks preety decent for me. You can also add more glow to it and maybe some subtle distortion (like heat haze), It will make it more lively
(I know it's only 'visual' opinion which you weren't after )

Thank you! I've been thinking about putting other effects on top of this, but both glow and heat haze would require a post-processing effect if i'm not mistaken?

You could try to move all vertices a little bit towards the camera. Though that won't cause model to look a little bigger.

Hmmm, I will try this and see what I come up with.

I saw a nice talk on this on the Bungie website, because Halo has a LOT of force fields. I can't remember the exact talk but it's on that page somewhere sorry!

I can't find the text you're talking about in any of the articles, you sure it's there?

Try something like this instead:

float4 world = mul(MATRIX_MVP, v_in.vertex + v_in.normal * 1.05f);

Although you way want to try a value > 1.05, it's basically what Quake 2 did back in 1998, so it should work.

I've done the vertex movement in both local and world space without any major difference in end result.

I think I explained myself poorly, hplus0603 gave me the response that I was looking for. But I think the rest of you misunderstood me. Basically, I'm not talking about sending input from the controlling client to the server, but rather how to properly propagate this to the remote clients without overwriting conflicting input states, and it was obviously as simple as just forwarding the input state as soon as it gets to the server (and allowing the server to modify it before hand in case some actions are not valid, like shooting when you have no bullets, etc.).

Lawnjelly: Do you run your input on a fixed timestep? How do you deal with rendering a smooth display of movement? I feel that when I run input on a fixed time-step the rendered movement ends up getting a little choppy when the frame render speed don't line up with the fixed time-step. Do you do some sort of local interpolation or just live with the slight choppy-ness?

So, been messing around with clustering my simulation and one issue has come up: Synchronizing simulation steps and game time between different nodes in the cluster. Is this even something you should do, or should the nodes all run their game time completely independent?

If the zoning is "seamless" to the client, then you need to keep the game step counters synchronized between servers. Luckily, servers are generally grouped tightly together, so they will have excellent clock correlation -- you could derive step number from global time, and use NTP to synchronize the time aggressively, for example.

When it comes to clock management in simulations in general, you want to establish a global ordering of events, but the times don't have to be perfectly synchronized as long as all events happen in the same order everywhere. Better clock sync between client/server tyipcally leads to a slight reduction in latency jitter, because the calculated latency will be accurate; on most cases this is much smaller a variation than what you get from transmission itself, or from the time step size, so it usually doesn't matter.

From your response I take it using a server that pulses all nodes is not a good solution? I know you're really good at this stuff, so don't really wanna argue with you but: About NTP? Is it accurate enough? Especially on windows, the wikipedia page about NTP says: "However, the Windows Time Service cannot maintain the system time more accurately than about a 1-2 second range" this is obviously not accurate enough at all. And while doing some research on NTP the general statement on NTP accuracy usually is "it depends". And even only linux/unix systems the accuracy it at best a couple of ms.


I don't know if my idea of using a "time" server that pulses all simulation nodes for each tick, and attaches the correct time to it (and then use a leaky integrator on each node to calculate the current game time) is a good idea either, as it hardly will be more accurate then NTP.

I've been investigating ZMQ for communicating between zones and nodes in my server, I just started on the implementation today and so far the features seem great. For the client<->server communication I'm sticking with a standard UDP library tho.

Don't get me wrong, the basic design idea's are very solid. The problem is when you start adding game related requirements such as bringing up unique instanced data, dealing with instance failures, kicking folks back to entry with a "oops, it crashed message" etc. Due to the desire to hide connection details, ZMQ is a real pain in the ass in these areas unfortunately. If I wanted to write a network layer, I'd start with the ZMQ model at the low level but I would add the things they are most definitely apposed to supporting. Long story short: love the concepts, hate the idealistically imposed limitations.

I can definitely see the problem of using ZMQ as a Client<->Server library, with it's "connection-less" API. But I don't see the inherent problems with using it as a library for doing inter-server communication, like when transfering players from one server to another, etc. As this doesn't really have to be aware of any connections, since you trust the environment servers can just send their "id" or whatever is used to identify them as the header of any message.

I also really like that ZMQ can "bind" and "connect" to any socket, so you don't have to "bind" the "hosting" socket and "connect" the "connecting" socket, basically the model I have right now is insanely simple:

• Each node in the cluster has two sockets, one SUB (in-going) and one PUB (out-going) sockets which are bound to two pre-defined ports based on the node number
• When a node needs to send data to another node, it opens a PUB-socket directly to that nodes SUB-socket
• When a node needs to receive data from another node, it attaches it's own SUB socket to that nodes PUB socket.

I can't really see any inherent drawbacks in this, but I'm sure someone will point them out ;p