Valve Info Collection. Please - Avoid posting your thoughts.

Status
Not open for further replies.

ShinRa

Companion Cube
Joined
Jun 23, 2003
Messages
5,044
Reaction score
84
Physics

Q: The physical interactions look perfect, but some sequences felt a little strange. Frame-by-frame analysis of the e3 videos showed exactly what: objects were reacting to impacts prior to the actual, visual impacts. For instance: there's a splash before a box hits the water, boards break before the crowbar reaches them, soldiers start flying away from a girder before it actually contacts them.
--------------------------------------------------------------------------------

A: The physics behaviors you point out are an interpolation artifact during demo playback, not of the physics system. They aren't there when you play. It didn't really occur to us that people would be doing a frame-by-frame analysis of shaky cam video of demo playback. Demo playback is NOT even vaguely pixel or frame accurate to actual gameplay - if you want that you need to make a movie instead and be really careful about how you manage time in your production pipeline (and you will have to ignore pixel and motion artifacts introduced by your compressor). The current demo playback behavior is good enough for our uses.

Q: Sparks appear to show right through other objects (barrels in tech demo sequence, and when manatee thing is shooting at you through cars) They also seem to happen too easily: slow moving barrels bumping into each other don't generate sparks. Dying creatures go limp too fast, like puppets whose strings have been cut. For creatures like headcrabs, you can't even tell if they've actually died, because they just stop moving: there's no twitching, clutching, or flipping over like there was in HL to let the player know that the creature is dying.
----------------------------------------------------------------------------------

A: Both the remaining issues are on our list.

Q: The crowbar. is it just like.. damage straight
ahead, or does it sort of swing, like a bat, and it
depends at what angle you hit something?

A: it's physically simulated - it's a bar swinging through air

Q: In the e3 demo, it says you
can essentially build the guys out of water by
applying the right shader or whatever. well, if you
make the guy out of water.. when you shoot him, does
he still bleed? or will it splash? it would be cool to
see them sort of melt or whatever when they die, but
thats not gonna happen. could that sort of 'splashing'
thing be easily programmed in? (probably, its jus the
sprite and sound right..)"

A: "Yes, they would splash, at least that would be the easy thing to do given the material. Splashes aren't sprites actually."

Q: What restrictions are there to the physics... I noticed in the vehicle driving scene that there is a wooden bridge that the player must drive up... was/is it possible for the bridge to be destroyed? And... if so... what then? Are there alternate routes?

If you can destroy something it may be useful but it can't be critical to completing the game.

Q: The physics in the single player part (judging from the movies from E3) look absolutely fantastic, but how will physics work in multiplayer? Won't there be a problem with sending all the physics information packets to all the players? Are you perhaps scaling the physics engine down for multiplayer?

A: Well, the simple answer is that there are client-side and server-side physics behaviors. You use client-side when maintaining cross-client coherence isn't important. This cuts down network traffic while maintaining the appearance of physical simulation throughout the world.

Q: The downed aliengunship plowing through the busted cars in the desert/buggy sequence... I'd like to know if that was scripted sequence?

A: No, that's the kind of thing you get with physics.

Just a statement from Gabe: Seamless transitions in space. Where you don't ever want to go get some coffee. The world should feel as seamless and continuous as possible. And idealy we should structure the autosaves so that you're not always thinking about quicksaving and quickloading: you're going to trust us. This is something that I think Miyamoto does really well: you can trust his game design.

[BJust a statement from Gabe: Everything is reflected back in physics. It's totally integrated into our game. We have weapons that allow you manipulate objects with physics. All of your conventional weapons are reflected in phsyics. You can throw a grenade bullets exert force player exerts force. You can push things and rolls things and jump on top of things and have them react to your mass. All of those things are integrated into the gameplay and you can do things at a level that you're couldn't do before.[/B]

Just a statement from Gabe: Using combat as an example again: enemies will react to you changing the position of physics obejcts, and if you knock something over maybe they can get behind it and use it for cover, or maybe you could knock it out of the way and they're not in cover anymore. That kind of thing really makes the situaiton more dynamic and more replayable.

Q: How complex will the physics engine be exactly? Is there a limit before things start clipping and not doing what they're supposed to be? Such as some of the ideas going around about making a map with just a huge building made out of wood. Will shooting the supports out from under the building make the rest of the building react? Same if other objects, i.e barrels were put on top of the wood building. Would it all react physically, or is there a limit to the engine?

A: The two scenarios you describe are actually pretty easy. Jay's physics system pretty much does that automatically. We're doing a lot with physics, but we're really curious to see what the MOD community figures out. Where you run out of gas is with lots and lots of objects.

Q: E3 video there was a table that was pushed against the door. if you stood on the table would the table collapse because of the weight? would the result of an interaction depend on the mass/volume of the supports? would the material [E.G. metal, wood, glass] change this?

A: No, the table wouldn't collapse, simply because you don't weigh enough. Yes, you could make a table that would collapse under your weight. Yes, the material does affect the strength. Yes volume drives physical properties (e.g. weight, buoyancy)

Q: Can you define how "thick" water is?

A: Sure. We made it clear to make it easy to see out of the water to the zombie that knocked you in.

Q: Could i make my map completely destructable?

A: Yes

Q: Could I make a mod where if i shot a rocket at the ground,
the ground would deform as a result of the explosion?

A: Yes

Q: I just wanted to ask If your ragdoll efect is implemented for any creature
or just working for human-like bodies?

A: Yes, physics applies to pretty much everything, including non-human bodies.

Q: If a wooden board is floating in the water and you jump onto it, will it slowly sink?

A: Yes

Q: Say I shoot a box.. with that box break and you'll be able to see inside? and the box have things inside it?

A: Yes

Q: WE all know that the physics are amazing, and you can move stuff around and everything, but i have a quesion about that. Do the physics give everything a "damage limit" or something similar so that after you shoot somthing enoguh times, it will blow up/shatter/ whatever? or is that jsut the wood. Could i sit there with a rocket launcher and hit a car a few times and then have it explode, or would it jsut keep sliding back or soemthing, a la Halo? And one final question: Does HL2 have destructable enviroments bulit in, or is that somehting us mod-makers will have code in?

A: It's really easy to create things that are destructible in HL2. Of course it's not limited to wood Mod authors can easily use, script, modify, or extend this behavior.
 
Guinny, what the heck are you doing?

Yo' crazeh, mon.
 
Computer/Tech

Q: Some rumors are going on about the video card on the dell machine (the one that ran the e3 tech demo) featured the Ati radeon 9800 pro 256mb version. Is this true, and does the 256 mb version has an advantage in Half-Life² over the 128 mb version?

A: The way Source is designed, hardware manufacturers can update materials to take advantage of new hardware as it comes out by shipping updates (probably via Steam). So if they come out with a 512 MB card or double the number of instructions possible in a pixel or vertex shader, then customers who have
that card can be updated to take advantage of that.

Specifically to answer your question, I think the cards were actually 128 MB cards but we do take advantage of 256MB cards. If I'm remembering right, we froze the hardware for the demo before ATI had sent us the 256 MB cards.

No, HL-2 doesn't have a SOF-2 style damage system.


Q: The source engine is scalable.. is that dynamic,
like if its starting to run sluggish it lowers the
polys, or is it set when you start the game or
something.

A: yes it is dynamic

Q: I was just wondering if there would be a visual difference between a dx6 card and above type of cards when visual goodies are turned up full? Also I heard that Source would the lod lower automatically if the game was playing at a below playable frame rate...is that true? One more thing, in terms of sound, will the engine take full advantage of an audio card such as audigy2 and will there be music played during singleplayer campaigns and possibly multiplayer?

A: Yes, there will be a big visual difference between DX6 hardware and DX9 hardware. Yes the LOD changes dynamically. I'm not sure what it means to "take full advantage of an audio card such as audigy2" but we do have a very sophisticated sound engine. Yes there is music for singleplayer. We haven't said anything about multiplayer.

Q: well I myself have a radeon 9700, so lets say somewhere outside during half life 2 my fps goes like to 15....will the engine change the LOD so it will boost my fps? Could you give me an example of a big visual difference between DX6 hardware and DX9 hardware? One last thing, I heard some talk about releasing a direct feed of the e3 demo shown at this years e3(like a video of the demo). Would you mind spilling some light on this or is it just speculation?

A: Yes, we dynamically change LODs.

Pretty much everything looks better on DX9 across the board.

Yes, we will be releasing the videos over steam in the next few days.


Q: With the current HL 1 netcode / engine I can easely play HL DM or a mod like CS with no lag (ping 60 for example). I use now ISDN 64K (sometimes 128K) and CS for example is well playable with ISDN. But here is the question: People who can't get broadband in their region, are they able to play HL DM with ISDN without lag?

I heard STEAM is broadband only (they recommand atleast 512kb/s download rate)

Does that mean that people who don't have a broadband connection can't play multiplayer with HL2 anymore? I would be disapointed because even CS is playable with isdn...

A: There are two issues - content delivery and playability.

HL-2 has better netcode than HL-1 thanks to Yahn and Mike Dussault's new approach. It takes less bandwidth for the same game on HL-2 than HL-1.

For content delivery, it's a question of how soon do you want it? If you leave your Steam connection on all the time and we deliver a 10 MB update, it's going to be delivered in the middle of the night so you won't even know that it's happening. If you turn it off and you have to wait for the update when you turn it on, then it's entirely a function of your bandwidth as to how long it will take to be delivered. The reality is that Steam will do content delivery over an arbitrarily slow connection - it's more a question
of whether or not you leave that connection active all the time.


Q: Will Half-Life 2 support Hyper-Threaded CPU's?
In theory shouldn't it take alot of load of the system?

Example, the first processor does all the physics, while the second does some other tasks, like AI, 3d Sound etc

Any Thoughts?

A: Hyperthreaded CPUs attempt to extract thread-level parallelism, as opposed to traditional pipelined architectures which attempt to take advantage of instruction level parallelism. Hyperthreading can be somewhat unpredictable in terms of the performance impact, as you can, in some cases, run slower.

Implementing and maintaining a "deeply" multi-threaded version of Source would be a pain (i.e. multi-threading the renderer). Implementing a hacky version (e.g. having a discreet physics thread or running the client and server in different threads) is something we may do depending upon how much bandwidth we have before we ship. Right now we don't get nearly as much bang for the buck working on hyperthreading as we do on other optimizations. That may change as we run out of things to optimize.

64-bits, in contrast, is a one-time cost and is fairly simple to take advantage of. It's a huge win for tools as it not only gets more work done per instruction, but it also gets us past the current memory limitations, which are a problem for us today on tools.

Distributed computing is harder than hyperthreading but it has the potential to increase performance by a huge amount (8X on our tools) as opposed to hyperthreading (30%). All of our tools are going to a distributed approach.

So the taxonomy looks like this:

- general algorithmic optimization (general good thing to do)
- DX9 optimization (big gains, long term direction)
- 64-bits (not that hard, solves memory problem as well as performance gains)
- hyperthreading (hard initial cost, on-going code maintainence cost, limited unpredictable performance gains, benefits in multiprocessor environments as well)
- distributed computing (hardest to do, biggest potential gains, great for tools, may be great for servers, not sure how it works with clients)

Hope this makes sense.


Q: What program are the vehicals for Half-Life 2 designed in? Hammer or XSI? Or could it be both?

A: you could use either, but we used XSI. We're working with Softimage to release a free version of XSI over Steam.

Q: I was talking with my friend today, and we were discussing HL1 and demos. He is considering making a movie out of demos and it got me thinking about HL2. Demos were a popular thing in HL1, where you can record your sweet moves in multiplayer games and such, and i was wondering what kinds of things will HL2 be doing with demos? Will there be more support for them? Maybe a menu for it or will HL2 be saving demos as AVI's to avoid the painful process of converting them? Any info on what demos are like in HL2 would be appreicated, thanks for your time.

A: Yes. There will be an in-game demo editor.

Q: I have a question about the are the cables/wires (which look FANTASTIC). Especially the way they move in nearby "wind." How does this effect play into map making/model design: do models (like the Alien gunship) have a special flag that means they generate a wind disturbance in their general area? Or does this require some sort of special scripting in C++? Can we make other objects in the game beside the cables/wires react to "wind" or is it an automatic factor of their weight?

A: Currently, blowing ropes around like the gunship requires specific code in the entity that wants to do it. There is an entity that can create a global wind force for non-rope objects, and it has parameters like wind speed, direction, and noise.

Q: How easy are they to create: can you just define two endpoints and give them a certain length or degree of slack?

A: Here's a little breakdown I wrote about them a while ago:

The ropes are simulated as a set of springs in between the endpoints (usually between 5 and 10 springs). So internally, they look like this:

*-----*-----*-----*-----*

where the *'s are the nodes that the engine cares about. It simulates those nodes, then makes a curve through them to draw the rope.

The nodes respond to gravity and wind. Entities can apply force to the ropes to make them sway. The gunship does this continually, and the strider does this when it takes a step.

For a mod maker, it's easy to make a rope between things (like a grappling hook). You call a function and specify what entities you want the endpoints attached to, the rope length, and the rope material. Level designers can place entities at the endpoints.


Q: Just have a question for you. I know the physics in HL2 are amazing, I've seen the videos. I would like to know how they work in multiplayer. Are the physics in the multiplayer client-side so that only you see them? Or are they server-side so if you push a desk infront of a door it's blocking the door for everyone else. And if it is server-side, does the number of interactive objectings in the level impact lag? I would imagine that haveing the server send information about the the objects would create a lot of lag, or have you guys managed to create netcode good enoguh so you don't have to worry about it?

A: Yahn and Mike have been working on the netcode quite a bit. It's much easier for MOD makers to extend now, and has better performance.

In your game code, you decide whether specific physics are client side or server side. Debris spew, for instance, can almost certainly be safely limited to client side. All the players see debris spew, they just don't see the same debris spew. A moving desk, though, would almost certainly need to be server side because the exact position matters to all of the clients.
 
Info from geeK:
geeK:

guinny you know that there already is a thread about this and you could post this in that thread instead of spamming the forums with new threads?


guinny: Yes, but im just a cool guy who is kinda stupid and i wanted the people to see this much quicker and im smart and so one *smile*


geeK: You were the first one to "destroy" the Valve No Discussion thread. Why don't you want people to destroy this thread?

guinny: People should respect me cuz I am a bloody jerk!
 
Computer/Tech Continued...

Q: Does it have a bumpmap texture for every texture?
Can a bumpmap from texture_rock be placed as bumpmap on texture_wood?

A: Bump mapping is defined per texture. Not every texture will need bumpmapping.

Q: Does the texture system have any "color code"?
Like a wall was grey, and you had to add the right color in hammer. (This was just an idea I had, cause it would make it possible to use 1 texture on many walls. And it would not seem to be the same old boring texture.)

A:No. Diffferent textures require... well, different textures.

Q: Is it possible to have animated textures that have a bumpmap?

A: I'm pretty sure this is possible.

Q: Does the new texture system require 8x8 textures? (like 128x128 and 64x64) Or is it now possible with 2000x500?

A: Textures sizes must still be multiples of 8.

Q: understand that you are/have worked on the netcode for half-life 2, and I have a question for you. Does the netcode allow for you to have a bunch of objects that can be manipulated to alter the level (I.e. desks infront of doors, boxes to make ladders, wood that's destroyable) or does this create too much lag?

A: Packet size, which can factor into lag is more dependent on how many objects are changing state per message. The physics system, also, has perf considerations related to the # of objects actively simulating (moving). For desks, boxes, etc., I don't think this will be an issue at all. If you were talking about 100s of objects moving at once, then maybe. I'd have to test that out.

Q: HL voice comm is great, how has this been implemented into hl2?

A: Yes. Higher quality voice codecs.

Q: I'm going to assume that lights can shot out, and will htis have a large impact on lag in multiplayer, wiht dyanamic shadows and everyhting? And is the netcode tweaked enough to support more than 32 players (up to 64 I hope ) with out running into netcode issues? I know the server will be important here, but with a "perfect" server, could will the netcode have probelms with large number of players like that? Oh yeah, one last question that you may or may not be able to answer, are map changes smoother and quicker with the HL2 netcode than they were with HL1 and most other games?

A: Lights would be an entirely client side perf question, so it's not a lag issue.

We haven't made a final call on whether the engine will support > 32 player multiplayer.

We haven't profiled map changes versus HL1, so I don't know how they compare. I would think they would be comparable, but we do have more data to deal with this time around.


Q: I am kinda involved in a short discussion about wether Half-Life² does or does not support dynamic shadows like DooM³. I think it does because a dutch gaming magazine said it does, and they got to see a demo with a lightbulb hanging from a cord in a room and when you push it it swings and the light would go dynamically across the surfaces off the objecs that where installed in the room. and cast dynamic shadows.

A: Yes, we have dynamic shadows. We use a different approach than Doom3.

Q: i will keep this short, i am a graphics artist and i know that hl2 will be shipping with a lightened up version of Softimage|XSI , does that mean that 3dsmax wont be used or will there be plugins and exporters, hl1 was generally optimized for 3dsmax users, will modelling be as easy on multiple different modelling platforms rather than just softimage, i dont want to relearn new software , also will there be tutorials available from valve software ?

A: We use XSI for our modeling, but we will ship exporters for XSI, 3DSMax, and Maya, so most people will be able to use their preferred modeling program.
We will probably include some type of tutorial or documentation with XSI.


Q: Any idea if you guys are planning on releasing some performance metrics/benchmark numbers to the net before Half-Life2's release? I'm sure there are legions of folks out there wondering what kind of performance they can expect out of the game running on high end ATI/nvidia hardware. 30 fps? 60fps? 100fps? I realize the engine is highly scaleable but for the 'ultimate' HL2 experience (ie 1024x768 to 1280x960, 32 bit color, all the eye candy cranked, 60 fps+) are the ATI 9800Pros and Nvidia 5900Ultra's going to be able to deliver? I know I for one want to pull the trigger on a 9800Pro but there's no way I'm jumping in if its not going to run the game the way it deserves to be run. I know the hardware AND gaming sites would love to get this kind of data a la the preliminary Doom3 benchmarks that id/nvidia released a while ago.

A: We target 60 FPS, and then adjust details accordingly. At E3 we were running 60 Hz on a 128 MB 9800 at 13something by 7something (the resolution of the plasma screen, which I don't remember exactly).

We are in the middle of a lot of performance analysis and tuning with ATI and NVIDIA. We will release benchmarking tools before we ship.


Q: my team and I are working out a Spiderman concept. With, ofcoarse, the ability to shoot the web against the walls, and then letting you use that to move from building to building. Same for 'webbing' objects to catapult them to other enemy players and for creating big webs in alleys as obstacles for enemy players. Will this be possible with the Source engine?

A:Yes, this is possible in source. Here's how you'd potentially do some of the things you're talking about :

* Shooting webs against walls + using that to move from building to building.

This could be done with simple tracelines from the player to the world to see what the web hit. At the point where the web hit, you can apply a web decal to the world to show the contact point on the world and use a tool called a meshbuilder to render the web between the first person view and the contact point. If you want to be fancy, you could use a cable simulator we have in the engine to physically simulate the web as if it was a rope, and to cause it to simulate (bouncing off the walls and ground) even after you've let go of that web and shot out a new one. We have the ability to easily modify player movement (far easier than what you had to do in HL1) which you could use to simulate the web-slinging movement.

* Same for 'webbing' objects to catapult them to other enemy players

For this, you could potentially use physics objects. If your web raycast hit a physics object, you tell vphysics to apply forces to the physics object to catapult it across the level. We have systems which automatically apply damage to game entities when they've been hit by a fast-moving physics object (which even take into account material properties of that object.. you'd take more damage from a metal object than from something made out of wood, for example).

* Creating big webs in alleys as obstacles for enemy players

For this, you'd need to use a number of raycasts to find points in the world to anchor the web to. Drawing the web is simple using the meshbuilder. To make it be an obstacle, you can make the web be a trigger entity which gets notified when other entities touch it. The web entity could then slow down or even stop entities that touch it. You also need to define a collision model for the web entity. The simplest method would be to use a bounding box which surrounds the web, which would be a little less accurate, but very simple to code. If you wanted to make an exact collision model, you can do that, but you'd need to implement a custom collision function. There's an example of such a custom collision function in one of the entities we have in our game.


Q: But is it possible? to bind the texture change to a sort of a 'lean' action i mean.

A: Oh yeah; we have a skinning feature; you'd could switch skins based on the leaning state; also we have a way of plugging game state into the shaders so you can make him more or less translucent based on how long you've been leaning against the wall, etc.

Q: Are there any plans to add linux support in the future?

A: No.

Q: I am writing to you about a quick question about Half-Life 2 (which I assume lots and lots of people do). Will Half-Life 2 have any special optimizations for 64-bit processors?

A:I would expect we would run about 30% faster clock for clock comparing an Athlon running 32-bit code and an Athlon 64 running 64-bit code. Release of the 64-bit client will be gated on MS releasing 64-bit Windows.
 
Story

When you start the game, the last thing you the player and "you" the character Gordon Freeman remember is your conversation with the G-Man. You have no idea what has happened, how much time has passed, or why you can't remember it.

Characters

Q: With regards to the Alyx's sidekick robot dog (or robot called DOG), is this an acronym for something? If so, what? Is it going to resemble a dog in any way?

A:Alyx just thought it was amusing to name her robot Dog.

Q: Some very dedicated people with a lot of time on their hands have managed to get this http://community.vugames.com/WebX?2...losure=.efded43 from the end of the 20min video available from Gamespot and Fileplanet. Do the phrases on here actually give anything away about HL2, perhaps explaining why Gordon is to have no memories of the past 15yrs? Or are we maybe reading to much into this?

A: They are there for a reason.

Q: In HL1 if a player shot at the G-Man, he would not be injured, in effect being invincible from player inflicted harm. How are such "player attacks" going to be handled in HL2? If I was to take a shot at Alyx how would the game react to this?

A: She'd shoot you back. It would annoy her. Dog would kick your ass.

Q: I just wondered how do the people in Half-Life 2 know how to move their mouth in time with the speech? And can you make them sing?

A: Yes, they could sing, though I've never tried it.

They move their lips based on data in the wav file that we add with our animation system. The first step is to type in what they're saying, then there's an automatic process that finds exactly when they say each phoneme and how long each phoneme lasts. All this gets written back into the wav file. When each character is told to "play" a sound, they'll move their lips based on the phonemes in the file.

You'd still need to add their facial expressions and body movements to make the performance believable.


Misc. Questions

Q: In the e3 demonstration, you showed the manipulator weapon... now, I was wondering what the restrictions are for the weapon... i.e. Could I pull an enemies weapon from his hand, and is there a "weight" limit to the objects that can be picked up? How will you know which objects are manipulatable? (is that even a word?) I was just worried that it would be like all these other games where, for example, your character can climb walls... but wait... ONLY "special" walls that have the texture "w_rocks1" (just an example)... and then there are walls that have that texture but can't be climbed.

A: The manipulator "opens" when you can pick something up that you are pointing it at. There is a weight limit. Most everything can be picked up. I hate special cases, too.

Q: Finally, will there be a co-operative mode? (I'm probably pushing my luck here, since you said you want to keep the multiplayer side of HL2 a big secret... but hey... you can't blame me for trying...)

A:We aren't doing a cooperative mode, but a couple of MOD teams want to do one so we'll work with one of them.

Q: Considering the SDK for the original Half-Life wasn't ready until months after the game's release, this is great news!

Rumor: The Day of Defeat team is already working with Source.

A:The Day of Defeat team is currently working on the follow up release to Day of Defeat 1.0, which will be version 1.1. They are not yet working with the Source engine
 
I didn't add repeated/uninformational questions. Those are all from the Valve info thread, except in order, and easier to read. Please mods, delete geeks and eternities posts, and lock the thread. Thank you.
 
What an attention whoring post, you just want a sticky, i hope this thread gets locked and deleted and not stickied
 
Or, the fact that in the offical one they asked someone to organize it, and it took me half an hour to do, so go **** your self noob.
 
And what if we just clear that thread from unnecesarry posts, wouldn't that be easier?
 
It's still not organized in order of categories :) I don't care if it's stickied, but mods please delete all these posts that arent the Q&A posts.
 
Don't start getting abusive again you've been warned about this.
 
Status
Not open for further replies.
Back
Top