Re: [hlcoders] Re: Portal
This Portal implementation with teleports calls for a infinite stairs map :D _ \ \ \ \ \ \ -- (adn alike :D) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
There was talk of this over at ModDB. It's possible using just teleporters and some cameras, methinks, but it would probably be better using portals. - This Portal implementation with teleports calls for a infinite stairs map :D _ \ \ \ \ \ \ -- (adn alike :D) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] Well... the early replies were probably correct... but I'm sure certain parts of the code were revamped just for this. On 8/1/06, Adam amckern Mckern [EMAIL PROTECTED] wrote: http://forums.facepunchstudios.com/showthread.php?t=168366 LUA 'Portal' Adam --- Ben \amogan\ K. [EMAIL PROTECTED] wrote: As far as I can tell from what I saw in the trailer they've done the portals in a pretty simple way: First off they used rendertargets etc. on the portals. For (non-player) object going through the portals they just add a temp. copy of the object to the exiting portal and when the actual object is half-way through copy and original switch places and after the object fully exited the portal the temp. copy gets removed. However this doesn't work (or isn't implemented) for the player entity. As you can see in the trailer the player-model doesn't move through the portals seamlessly, it rather really only gets teleported from one location to the other. Of course I can't be 100% sure about this as I didn't have the chance to play the game or look at the code. ;) But that's definitely the way I'd go when coding such portals - and at least it really looks like that's how they've done it, once again watching the trailer. : So far I guess the Portal team didn't have to modify the engine itself a lot. The hardest things to do IMO probably were making the player see his player model when looking through the portals, making entities not collied with the wall when going through portals and adjusting some viewangle stuff. - amogan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
If you look better at the trailer you will see that the same telepoting is done for the player object. In the first task when he must fin an exit he more via the portal and when he is half on the other side he see the still left part of his body to the other portal. :) Regards, The Storm Ben amogan K. wrote: As far as I can tell from what I saw in the trailer they've done the portals in a pretty simple way: First off they used rendertargets etc. on the portals. For (non-player) object going through the portals they just add a temp. copy of the object to the exiting portal and when the actual object is half-way through copy and original switch places and after the object fully exited the portal the temp. copy gets removed. However this doesn't work (or isn't implemented) for the player entity. As you can see in the trailer the player-model doesn't move through the portals seamlessly, it rather really only gets teleported from one location to the other. Of course I can't be 100% sure about this as I didn't have the chance to play the game or look at the code. ;) But that's definitely the way I'd go when coding such portals - and at least it really looks like that's how they've done it, once again watching the trailer. : So far I guess the Portal team didn't have to modify the engine itself a lot. The hardest things to do IMO probably were making the player see his player model when looking through the portals, making entities not collied with the wall when going through portals and adjusting some viewangle stuff. - amogan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] Bah. It just teleports you when you walk on it. On 7/31/06, Adam amckern Mckern [EMAIL PROTECTED] wrote: http://forums.facepunchstudios.com/showthread.php?t=168366 LUA 'Portal' Adam --- Ben \amogan\ K. [EMAIL PROTECTED] wrote: As far as I can tell from what I saw in the trailer they've done the portals in a pretty simple way: First off they used rendertargets etc. on the portals. For (non-player) object going through the portals they just add a temp. copy of the object to the exiting portal and when the actual object is half-way through copy and original switch places and after the object fully exited the portal the temp. copy gets removed. However this doesn't work (or isn't implemented) for the player entity. As you can see in the trailer the player-model doesn't move through the portals seamlessly, it rather really only gets teleported from one location to the other. Of course I can't be 100% sure about this as I didn't have the chance to play the game or look at the code. ;) But that's definitely the way I'd go when coding such portals - and at least it really looks like that's how they've done it, once again watching the trailer. : So far I guess the Portal team didn't have to modify the engine itself a lot. The hardest things to do IMO probably were making the player see his player model when looking through the portals, making entities not collied with the wall when going through portals and adjusting some viewangle stuff. - amogan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Re: Portal
-Original Message- From: Ben amogan K. [mailto:[EMAIL PROTECTED] Sent: July 31, 2006 5:54 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Re: Portal However this doesn't work (or isn't implemented) for the player entity. As you can see in the trailer the player-model doesn't move through the portals seamlessly, it rather really only gets teleported from one location to the other. Uhm.. The player does too. Look at the very first area, with the spikey ceiling coming down. You can see yourself going through the portal. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
Tony omega Sergi wrote: -Original Message- From: Ben amogan K. [mailto:[EMAIL PROTECTED] Sent: July 31, 2006 5:54 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Re: Portal However this doesn't work (or isn't implemented) for the player entity. As you can see in the trailer the player-model doesn't move through the portals seamlessly, it rather really only gets teleported from one location to the other. Uhm.. The player does too. Look at the very first area, with the spikey ceiling coming down. You can see yourself going through the portal. Uhm.. The player does not. Unless you're proposing that the player actually moves into an entirely new room that is not the old room, then by logic the player must have been teleported at some point to another part of the same room. It's just that it does some smoke and mirrors so that it seems like you were never teleported, but just ran into another part of the room. And in fact, if you review the video closely, you can see a small hitch when the player is teleported. I think that hitch is what Ben was talking about, but I don't think it will appear in the final game. The video was probably recorded from a demo, and the demo playback probably caused the hitch. -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. But thats me, who knows what valve would do, I dont think they would goto the extent of creating another copy of the map, but I wouldn't put it past a few guys who are struggling to meet a deadline. :) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] They made Narbacular Drop, I doubt they had problems doing it and meeting a deadline. On 8/1/06, Charles Solar [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. But thats me, who knows what valve would do, I dont think they would goto the extent of creating another copy of the map, but I wouldn't put it past a few guys who are struggling to meet a deadline. :) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
I would imagine that they're just doing some kind of stencil buffer for the portal, and simply rendering to it from an alternate viewpoint. I've never used stencil buffer this way, so I'm not sure what the performance hit would be. Then again, I'm talking openGL, not sure if source directX have a similar feature, but I'd imagine they would, it seems like a simple enough concept. Say, your current view towards the portal/stencil intersects it at a 45 degree angle, and looking through this stencil/portal would take up say 20 degrees of FOV based on your current distance. Rendering into that stencil could be done wiht a viewpoint rotation of 45 degrees, and 20 FOV from the other side of the portal. Then again, I'm not much of a graphics programmer. On 8/1/06, Charles Solar [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. But thats me, who knows what valve would do, I dont think they would goto the extent of creating another copy of the map, but I wouldn't put it past a few guys who are struggling to meet a deadline. :) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
Charles Solar wrote: If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. Why would you do all that complicated stuff that would essentially amount to a teleport anyways, when you can just teleport the player? -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
What's more interesting I think that how to render it, would be if this were turned into a MP game, how would you handle the traceline stuff correctly for bullets and weapons. Would updates to Source automagically handle this? If not, you'd have to check if the traceline ended ona portal, and then do another traceline from the other end of the portal on again. The internals of the traceline endpoint could be complicated too I'd imagine, what if an MP entity is 2/3 the way through the portal, but the traceline ends/collides on the 1/3 of the entity still on the other end? Also if you have dynamic netcode/entity management that only updates entites close to you based on their relevance (usually distance, how we do it at work) that helps it scale up, this assumption of physical distance allowing a measure to rate importance and relevance of net updates is completely shot. Whoever is working on a MP version of Portals, more power to ya ;-) On 8/1/06, Jorge Rodriguez [EMAIL PROTECTED] wrote: Charles Solar wrote: If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. Why would you do all that complicated stuff that would essentially amount to a teleport anyways, when you can just teleport the player? -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] I haven't thought about that.. A MP version of Portal would be nice... but hard to code On 8/1/06, Drew Kirkpatrick [EMAIL PROTECTED] wrote: What's more interesting I think that how to render it, would be if this were turned into a MP game, how would you handle the traceline stuff correctly for bullets and weapons. Would updates to Source automagically handle this? If not, you'd have to check if the traceline ended ona portal, and then do another traceline from the other end of the portal on again. The internals of the traceline endpoint could be complicated too I'd imagine, what if an MP entity is 2/3 the way through the portal, but the traceline ends/collides on the 1/3 of the entity still on the other end? Also if you have dynamic netcode/entity management that only updates entites close to you based on their relevance (usually distance, how we do it at work) that helps it scale up, this assumption of physical distance allowing a measure to rate importance and relevance of net updates is completely shot. Whoever is working on a MP version of Portals, more power to ya ;-) On 8/1/06, Jorge Rodriguez [EMAIL PROTECTED] wrote: Charles Solar wrote: If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. Why would you do all that complicated stuff that would essentially amount to a teleport anyways, when you can just teleport the player? -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
Well, examining the portal trailer frame by frame, it would seem that John was correct in his assumption. The portals seem to be dynamically sized render textures (much like the water refraction and reflection render textures) with entity shadow copies being created as they pass through the portal. My guess is the portals have a special collision routine to allow objects to pass through them in the first place, and the model instance is copied (much like the way ragdolls are perfect copies of the player's model instance) and rendered at the opposite portal until the object's origin passes through, at which point the object and the shadow copy are swapped. This isn't done for players though, if you look at the first part of the video with the spikes, you can see the player running through the portal as he approaches it, as soon as he touches it the player jumps through and appears on the other side. My guess is thats because copying player models with all the attached animations is too complex for the entity shadow system. On the second ingame part, where they drop a box on the turret, you can clearly see that the box copy created on the top portal is very dark (lighting origin is still inside the wall) and then as soon as the swap happens the bottom box turns very dark. There is also a one frame gap where the actual swap happens where the top box disappears. The recursive rendering seems to render entities and world on the first portal but only the world on the second portal (up to a limit of 5 or 6 I would guess). I say this because while the player runs in circles around the portals, if you look 2 portals forward, the player clips the wall. That's pretty much all I can say about that. Good luck to all the portal clones. On 8/1/06, Chris Harris [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] They made Narbacular Drop, I doubt they had problems doing it and meeting a deadline. On 8/1/06, Charles Solar [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] If I was coding portals as they apear in the video, I would atempt a 'wormhole' type design. Where the portal actually connects those two walls in a way so that the player can walk into a portal just like he was walking through a regular door. But thats me, who knows what valve would do, I dont think they would goto the extent of creating another copy of the map, but I wouldn't put it past a few guys who are struggling to meet a deadline. :) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
There is a way, I think, that this could actually be done without the use of render targets. It requires some engine access, though, to wit: 1. Draw the view. If no portals are in view (done with pixelvis or whatnot), terminate recursion (if any). 2. Draw portals. The portal is drawn with a special material that clears the depth buffer. 3. For each portal: a. find the transformed camera position looking through that portal. b. store off portal location info (e.g. on a global stack) c. cull polygons *from the exit portal location* d. go to step 1 *from the transformed camera location through the exit portal* e. retrieve portal location from stack, draw a transparent overlay quad on portal (flames, etc.) That should make it possible to do this without render targets, including the flame effects along the borders that we see. Note, though, that this requires the ability to separate the polygon cull step from the render step in the engine, in step 3c. Models that touch the portal will have still have to be cloned; in fact, there's probably a shadow physics controller at the far portal. Anybody want to try prototyping this on Ogre3D? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] Another problem we haven't thought of is the PVS...they obviously have to add much more to the PVS code to make sure all of the entities on other side of the portal are rendered too -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
Aaron Schiff wrote: Another problem we haven't thought of is the PVS...they obviously have to add much more to the PVS code to make sure all of the entities on other side of the portal are rendered too Source already handles this. Think about HL2's camera system. -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
-- [ Picked text/plain from multipart/alternative ] Yep: engine-AddOriginToPVS On 8/1/06, Jorge Rodriguez [EMAIL PROTECTED] wrote: Aaron Schiff wrote: Another problem we haven't thought of is the PVS...they obviously have to add much more to the PVS code to make sure all of the entities on other side of the portal are rendered too Source already handles this. Think about HL2's camera system. -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] Another problem we haven't thought of is the PVS...they obviously have to add much more to the PVS code to make sure all of the entities on other side of the portal are rendered too PVS should be handled with respect to the remote camera used by the portal. What's visible to that camera (from the camera's point of view) gets rendered to the texture used as the material displayed as the portal. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Re: Portal
Given a 'true' implementation of a portal system (as described at flipcode (http://www.flipcode.com/articles/portals_issue09.shtml) and wikipedia (http://en.wikipedia.org/wiki/Portal_rendering) ) the portals themselves resolve the PVS issue by extending the view frustrum for clipping / rendering purposes. I'd be hoping that the Portal team have in fact gone as far as to add the tech to the core engine rather than spend over a year doing a hack job of it (Narbacular Drop shows they know how to do it, it's 'just' a case of integrating it into Source) - as has been discussed (and demonstrated with the Gmod SWEP) it's possible to do in the current engine with a bit of work and some smoke and mirrors, it just doesn't form a 'true' portal implementation. I guess we'll either have to wait for an official word from valve about it, to save us all going mad figuring it out - or for Portal to be released so we can poke around ourselves and figure it out. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey botman Broome Sent: 01 August 2006 22:20 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Re: Portal Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] Another problem we haven't thought of is the PVS...they obviously have to add much more to the PVS code to make sure all of the entities on other side of the portal are rendered too PVS should be handled with respect to the remote camera used by the portal. What's visible to that camera (from the camera's point of view) gets rendered to the texture used as the material displayed as the portal. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: Portal
http://forums.facepunchstudios.com/showthread.php?t=168366 LUA 'Portal' Adam --- Ben \amogan\ K. [EMAIL PROTECTED] wrote: As far as I can tell from what I saw in the trailer they've done the portals in a pretty simple way: First off they used rendertargets etc. on the portals. For (non-player) object going through the portals they just add a temp. copy of the object to the exiting portal and when the actual object is half-way through copy and original switch places and after the object fully exited the portal the temp. copy gets removed. However this doesn't work (or isn't implemented) for the player entity. As you can see in the trailer the player-model doesn't move through the portals seamlessly, it rather really only gets teleported from one location to the other. Of course I can't be 100% sure about this as I didn't have the chance to play the game or look at the code. ;) But that's definitely the way I'd go when coding such portals - and at least it really looks like that's how they've done it, once again watching the trailer. : So far I guess the Portal team didn't have to modify the engine itself a lot. The hardest things to do IMO probably were making the player see his player model when looking through the portals, making entities not collied with the wall when going through portals and adjusting some viewangle stuff. - amogan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
