(Spoilers talking about new engine) Portal 2 SDK - When? - Developers

[url=http://www.mye.ro]email gratuit[/url] [url=http://www.mye.ro]mail gratis[/url] [url=http://www.mye.ro]mail gratuit[/url] [highlight](User was permabanned for this post ("Spam" - Autumn))[/highlight]

hi jace- oh wait

[QUOTE=wootmonster;29305970]Remember the part with the moving[sp]portals at the neurotoxin part[/sp]? Since they will be possible, I want to do this: [media]http://i981.photobucket.com/albums/ae300/garry_smith/Humor/game_portal_paradox_001.png[/media][/QUOTE] Or the crushing portals thing, AKA Aperture particle accelerator :v:

[QUOTE=Redcow17;29292605]Amazing.. Source Engine 2. Videos, being carried in that room thing without falling around, glass. When are we gonna get all of this awesomeness?[/QUOTE] I noclipped around the room, and apprantly the player is BOUND to be inside it, so when you noclip out of it, you still follow the room.

[QUOTE=Redcow17;29292605]Amazing.. Source Engine 2. Videos, being carried in that room thing without falling around, glass. When are we gonna get all of this awesomeness?[/QUOTE] I believe the glass is just an animated model with its three main states- Unbroken, shattered and broken. So nothing special. The physics engine appears to have been updated slightly through, which is an improvement.

[QUOTE=Downsider;29308947]not being pretentious..[/QUOTE] You're making out like traversing a bsp is an expensive thing to do. You got called out, copy and pasting snippets from wiki's and other sources doesn't help your case. You don't need to be explaining what a bsp is to me, it should be the other way around. Don't make the claim that "props render quicker" when you're uneducated on the subject. It's quicker to determine visible faces and chuck them into a batch every draw than a draw call for every 'prop' in the scene. Your claim is irrelevant and incorrect.

I'm working on a modified Portal 1 fgd to support the new stuff, it will have to do until we can get our hands on the new SDK.

[QUOTE=Downsider;29310698]It means that there's no additional features related to the map format in the engine, otherwise a decompiler wouldn't be able to accurately decompile it due to the additional data/changed data format.[/QUOTE] Only brush side lump has changed, the rest of the features are in the game lumps

[QUOTE=DeanWinchester;29315593]I'm working on a modified Portal 1 fgd to support the new stuff, it will have to do until we can get our hands on the new SDK.[/QUOTE] Garry couldn't load the models in GMod, so it appears the model format has changed.

That's a shame then :(

[QUOTE=Clavus;29315749]Garry couldn't load the models in GMod, so it appears the model format has changed.[/QUOTE] Maybe they're jsut new version of .mdl format.

[QUOTE=layla;29303162]Your whole post is pretentious so I'll just pick apart the worst parts. How is bsp geometry more "CPU-intensive to sort"? The geometry is already sorted to quickly find and draw potentially visible faces, in very few batches. That's the whole point of a bsp tree.[/QUOTE] Where there's a thread on the source engine there's always idiots.

[QUOTE=layla;29315489]You're making out like traversing a bsp is an expensive thing to do. You got called out, copy and pasting snippets from wiki's and other sources doesn't help your case. You don't need to be explaining what a bsp is to me, it should be the other way around. Don't make the claim that "props render quicker" when you're uneducated on the subject. It's quicker to determine visible faces and chuck them into a batch every draw than a draw call for every 'prop' in the scene. Your claim is irrelevant and incorrect.[/QUOTE] Okay Layla. By your logic, rendering a player model with only a diffuse texture applied should be faster if it's organized into a BSP tree. Traversing the tree is [i]stupid[/i] waste of time on the CPU, do you even know how the CPU and GPU work together? The GPU can handle the sorting of faces through the z-buffer. You don't need a cheap sorting algorithm on modern hardware. So no matter how little time it takes to traverse that tree, the batching [i]still[/i] takes a significant amount of time, especially if you're talking about making all those props out of brushes. When you add an unnecessary face to the BSP tree, you add unnecessary complexity. Sorting [i]one origin[/i] for a few thousand faces on a prop (CPU) and doing the rest on the GPU after throwing the batched faces in is [i]much faster[/i] than sorting [i]thousands of faces[/i] by traversing the BSP tree thousands of times. You're wrong. Not only this, but you do realize that by not binding textures and re-using VBO's it's rendered much faster as well, right? There's a reason these props were used other than simply being easier to develop with. I've been working with the Quake 1 engine for more than 4 years, have written my own Quake engine, and ported it to the PSP. So please, good sir, you're biting off more than you can chew. On my PSP engine, I use props liberally and it makes a lot more sense than the bullshit you're spewing out, and I'm using the same basic BSP structure for map format. What experience do you have?

It's possible that the portal engine is more similar to the l4d one. I'm downloading l4d2 atm so i can port the models and try it.

[QUOTE=oskutin;29315794]Maybe they're jsut new version of .mdl format.[/QUOTE] Does that mean I won't be able to load them in ep2?

[QUOTE=Downsider;29316934]Okay Layla. By your logic, rendering a player model with only a diffuse texture applied should be faster if it's organized into a BSP tree. Traversing the tree is [i]stupid[/i] waste of time on the CPU, do you even know how the CPU and GPU work together? The GPU can handle the sorting of faces through the z-buffer. You don't need a cheap sorting algorithm on modern hardware. So no matter how little time it takes to traverse that tree, the batching [i]still[/i] takes a significant amount of time, especially if you're talking about making all those props out of brushes. When you add an unnecessary face to the BSP tree, you add unnecessary complexity. Sorting [i]one origin[/i] for a few thousand faces on a prop (CPU) and doing the rest on the GPU after throwing the batched faces in is [i]much faster[/i] than sorting [i]thousands of faces[/i] by traversing the BSP tree thousands of times. You're wrong. Not only this, but you do realize that by not binding textures and re-using VBO's it's rendered much faster as well, right? There's a reason these props were used other than simply being easier to develop with. I've been working with the Quake 1 engine for more than 4 years, have written my own Quake engine, and ported it to the PSP. So please, good sir, you're biting off more than you can chew. On my PSP engine, I use props liberally and it makes a lot more sense than the bullshit you're spewing out, and I'm using the same basic BSP structure for map format. What experience do you have?[/QUOTE] Shit just got real.

[QUOTE=Redcow17;29292605]Amazing.. Source Engine 2. Videos, being carried in that room thing without falling around, glass. When are we gonna get all of this awesomeness?[/QUOTE] Well, for starters, you'd probably need Portal 2 to get it in the first place. I'm not really sure, though. [editline]20th April 2011[/editline] [QUOTE=IronPhoenix;29316937]It's possible that the portal engine is more similar to the l4d one. I'm downloading l4d2 atm so i can port the models and try it.[/QUOTE] Port the models to what?

[QUOTE=Chaingunfighter;29317435] Port the models to what?[/QUOTE] I'm just taking a guess here with what would be logical. He didn't have l4d2 on his comp and he is downloading it to test if he can port props from portal 2 to l4d2.

[QUOTE=Downsider;29316934]Okay Layla. By your logic, rendering a player model with only a diffuse texture applied should be faster if it's organized into a BSP tree.[/QUOTE] A player model doesn't need per face collision, nor is it spread out so much that it needs visible face determination or a quick broadphase collision check. Of course it doesn't need to be spatially structured, no one is saying that. [QUOTE=Downsider;29316934] especially if you're talking about making all those props out of brushes. [/QUOTE] You seem to be misunderstanding what a brush actually is. The only difference between brush geometry and mesh geometry is that the brushes are spatially sorted, you would have to do the same thing with 'props' so you're only drawing whats potentially visible. (per object, obviously) [QUOTE=Downsider;29316934] you do realize that by not binding textures and re-using VBO's it's rendered much faster as well, right? [/QUOTE] Binding textures is not expensive, although I'm not sure how that is relevant atall, you need to bind textures before you draw anyway incase something was bound to the slot previously. This differs from API to API though and Is totally irrelevant to your statement I'm calling you out on. Who said anything about creating a VBO all the time? This depends on your rendering implementation. You can just draw a certain range of the VBO, there's a few ways to go about it. Not only this but recreating a VBO for your visible set is going to be faster than drawing the entire map that applies complex shaders with many instructions. [QUOTE=Downsider;29316934] There's a reason these props were used other than simply being easier to develop with. [/QUOTE] Huh? [QUOTE=Downsider;29316934]have written my own Quake engine[/QUOTE] So you took a well documented format, read it in and shoved it into a VBO? Well, congratulations! Your point is still irrelevant though.

[QUOTE=layla;29317909]A player model doesn't need per face collision, nor is it spread out so much that it needs visible face determination or a quick broadphase collision check. Of course it doesn't need to be spatially structured, no one is saying that.[/quote] Key word: rendering. [QUOTE=layla;29317909]You seem to be misunderstanding what a brush actually is. The only difference between brush geometry and mesh geometry is that the brushes are spatially sorted, you would have to do the same thing with 'props' so you're only drawing whats potentially visible.[/quote] Prove to me that BSP faces render just as fast. Make a map with some ridiculous brush-rape, then compare it to a map filled with props. [QUOTE=layla;29317909]Binding textures is not expensive, although I'm not sure how that is relevant atall, you need to bind textures before you draw anyway incase something was bound to the slot previously. This differs from API to API though and Is totally irrelevant to your statement I'm calling you out on.[/quote] Renders faster. VBO's when reused render a lot, lot faster. You don't have to push any more geometry each frame, or since it's being reused, multiple copies of geometry. [QUOTE=layla;29317909]Huh?[/quote] [i]Performance in rendering.[/i] What we've been talking about this entire time. Are you that thick? Still waiting on: [quote]What experience do you have?[/quote] EDIT: And about binding textures, it is fairly expensive to upload textures to the GPU, so when working with VRAM constraints (Like on a mobile device) it's important to keep your VRAM usage down. It was a bit irrelevant to Portal 2, though.

[QUOTE=Downsider;29318082] Prove to me that BSP faces render just as fast. Make a map with some ridiculous brush-rape, then compare it to a map filled with props. [/QUOTE] You're missing the point here. There's ALOT of things that factor into this. Saying one technique is faster than another is totally irrelevant. It's like me drawing 50k 6 quad models and batching a 300k quad model. The latter is obviously going to be faster due to one draw call. [QUOTE=Downsider;29318082] Renders faster. VBO's when reused render a lot, lot faster. You don't have to push any more geometry each frame, or since it's being reused, multiple copies of geometry. [/QUOTE] I already covered this. [QUOTE=Downsider;29318082] And about binding textures, it is fairly expensive to upload textures to the GPU [/QUOTE] Binding to a slot isn't uploading to GPU, you have to have your texture already uploaded to the GPU to be able to bind it. [url]http://www.opengl.org/sdk/docs/man/xhtml/glBindTexture.xml[/url]

[QUOTE=BioResearch;29317756]I'm just taking a guess here with what would be logical. He didn't have l4d2 on his comp and he is downloading it to test if he can port props from portal 2 to l4d2.[/QUOTE] Exactly. Since my 750gb drive died, i never had a reason to have l4d2 on my pc...as my games disk is only an old 200gb drive i had lying around. The models and textures will not work in either ep2 or portal. My guess is that they will work in l4d2. Portal 2 has hints in the graphics that it is the most up to date engine, and not just because the physics...well...work.

[QUOTE=layla;29318322]You're missing the point here. There's ALOT of things that factor into this. Saying one technique is faster than another is totally irrelevant. It's like me drawing 50k 6 quad models and batching a 300k quad model. The latter is obviously going to be faster due to one draw call.[/quote] Those 50k 6 quad models should be batched into one call. That's half the point of props and VBO's.. Did you really miss that? [quote]I already covered this.[/QUOTE] You mean: [quote]This depends on your rendering implementation. You can just draw a certain range of the VBO, there's a few ways to go about it. Not only this but recreating a VBO for your visible set is going to be faster than drawing the entire map that applies complex shaders with many instructions.[/quote] Yep, we're talking about Portal 2's rendering implementation, remember? You can test which is faster by throwing a few hundred brushes around and then throwing a model at it. That model most definitely has more faces than those brushes, yet renders faster. Gee, isn't that what I was saying from the beginning? All I'm saying is that the props are there for a reason, the reason is efficiency and ease of development. You're going off on tangents for the most part, trying to prove that in scenario X, Y method renders faster than Z method. I'm talking about Portal 2 on modern hardware. In this scenario, and most game scenarios, props render faster than brushes. Period.

Nope. [quote] Props render quicker and are less CPU-intensive to sort for as opposed to brushes when it comes to rendering[/quote] This statement is what I have a problem with, that has nothing to do with portal 2, but rendering in general, It's also totally irrelevant because it depends entirely on the situation. I'm not sure why you can't see that. In theory you can just convert the worldspawn bmodel into the mesh format they use for props, do that and compare the fps. Maybe you're getting confused because you think I'm saying everything needs to be spatially structured somehow like bsp, I'm not saying that atall. I'm saying your statement is incorrect because if you was to make each brush model into a 'prop' the game would run at unplayable speeds.

[QUOTE=layla;29318602]Nope. This statement is what I have a problem with, that has nothing to do with portal 2, but rendering in general, It's also totally irrelevant because it depends entirely on the situation. I'm not sure why you can't see that. In theory you can just convert the worldspawn bmodel into the mesh format they use for props, do that and compare the fps. Maybe you're getting confused because you think I'm saying everything needs to be spatially structured somehow like bsp, I'm not saying that atall. I'm saying your statement is incorrect because if you was to make each brush model into a 'prop' the game would run at unplayable speeds.[/QUOTE] The world should be a BSP for the sole purpose of collision and partitioning. That's it. Nothing else has any reason to be a BSP model except for the simplest shell of the level. Portal 2 did this and it runs great and looks great. That's what I'm arguing. I don't know why you have a problem with that? If the props were part of the world geometry, then, as I said before, traversing the BSP tree would be a complete waste of time since the faces in the model are densely packed and almost all of them are visible from any angle, and they can be sorted on the GPU. I don't see why you're arguing this, it's what I've been saying from the beginning unless you've misunderstood something along the way.

[QUOTE=Downsider;29318928]The world should be a BSP for the sole purpose of collision and partitioning. That's it.[/QUOTE] So you agree that [quote]Props render quicker and are less CPU-intensive to sort for as opposed to brushes when it comes to rendering[/quote] is incorrect in all situations? Because that's all I'm arguing.

[quote]Binding to a slot isn't uploading to GPU, you have to have your texture already uploaded to the GPU to be able to bind it. [url]http://www.opengl.org/sdk/docs/man/xhtml/glBindTexture.xml[/url][/QUOTE] I should've been more elaborate. In my implementation, when I bind a texture, I often have to unload and load textures to deal with VRAM constraints, although it's done transparently by the API, if you know what you're doing you have control over it. [editline]20th April 2011[/editline] [QUOTE=layla;29318979]So you agree that is incorrect in all situations? Because that's all I'm arguing.[/QUOTE] No? Props don't use any CPU power to sort. It's all done on the GPU. Traversing the BSP tree for thousands of faces is a waste of time, so why do it for a relatively small prop with lots of faces that are all visible at once and don't require complex collision data..? That's why props are used. You're arguing that props don't have any speed gain over a BSP model, at least on the CPU, which is a total fabrication. The GPU handles [i]everything[/i] regarding props. The CPU just passes along a few polygons and says have fun.

Just contradicted yourself then or you're not understanding what I just asked. Read it again.

[QUOTE=layla;29319038]Just contradicted yourself then or you're not understanding what I just asked. Read it again.[/QUOTE] I have no clue what you're asking me here so I'll just make it black-and-white. In a game situation like Portal 2, making complex props out of brushes is a waste of CPU time as, by the nature of a BSP tree in the Source engine, they will be sorted on the CPU. There's no reason to sort them on the CPU. It can be sent off to the GPU since the model is likely relatively small and doesn't require complex collision or sorting. What's not to agree with here?

[QUOTE=Downsider;29319119]I have no clue what you're asking me here so I'll just make it black-and-white. In a game situation like Portal 2, making complex props out of brushes is a waste of CPU time as, by the nature of a BSP tree in the Source engine, they will be sorted on the CPU. There's no reason to sort them on the CPU. It can be sent off to the GPU since the model is likely relatively small and doesn't require complex collision or sorting. What's not to agree with here?[/QUOTE] No, I agree with that completely but It's not what I'm arguing. You said in ALL situations, bsp geometry is useless. You then say bsp geometry is fine for worldspawn. Well if props are a viable solution for everything then why use bsp atall? [QUOTE=Downsider;29318981] You're arguing that props don't have any speed gain over a BSP model, at least on the CPU, which is a total fabrication.[/QUOTE] No I'm not? Because that would be a huge generalization. Like I've said before, that depends on the situation. The time it takes the CPU and GPU to upload part of your bsp geometry is going to be nothing compared to drawing the whole thing (depending on the complexity obviously). If you're limited to video memory you would want to upload parts each frame rather than having the whole thing sit in a buffer.