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: [email protected] 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
