Posts by Defrag

  • WIP in WIP, post your level screenshots!

    I agree with ferret. The upper architecture in particular just looks 'wrong' to me, but the lower section looks good. I can't help but feel that rejigging the ceiling to be styled along the lines of a grand old building (which tend to have high ceilings) would prove to be a more fitting choice.

  • retardedly large UE3 screens

    Quote from Gorion

    i was being sarcastic and for some reason i think UT3 can handle AA, else it will be the same thing as with GRAW.. i hate tat game for not handling AA.

    GRAW used deferred shading which is why it couldn't use AA. UE3 uses something similar but not the same and I've definitely read things in the past where Sweeny has stated that GoW couldn't run with AA because they use a deferred way of handling their effects.

    Interview here -- read the "one more question answered via email" answer.

    Quote

    Sweeney- Gears of War runs natively at 1280x720p without multisampling. MSAA performance doesn't scale well to next-generation deferred rendering techniques, which UE3 uses extensively for shadowing, particle systems, and fog.

    At the very least they will write the scene depth to a render target -- this allows the volumetric particle effects and can be used as inputs into things like underwater rendering. Put simply, if you know how far a ray from the eye has to travel to hit a specific point in the scene, you can do much more cool effects. The problem is that if you have something like scene depth written to a render target, then you don't want to blend or alter those values in any way as they become incorrect. It can produce some weird looking results.

    Crysis is also using this sort of thing, so if it breaks AA support, you'd better get used to it because a lot of games are going to follow suit. There are ways to 'fix' the AA but I don't fully understand how they're doing it or whether it can be used in all cases (near the end of the Crysis presentation explains how Crytek corrected it).

    So, unless Epic have come up with a way to fix it post GoW, it will still be running without AA. One alternative is to render at double the size of the frame buffer and then size down to achieve a smoother image (afaik this is similar to super sampling, except you would have to do it manually). You can imagine the performance penalty for doing that

    Personally, I thought GRAW looked really bad without AA, though it was probably because it wouldn't let me run the game at my TFT's native resolution which makes things look doubly bad. I've played and watched GoW in action quite a bit and I didn't think it suffered from the lack of AA much at all (and yes I was playing on a high res monitor, so it wasn't the TV blurring the bejesus out of everything that was hiding the jaggies )). IMO effects like subtle blooming makes the image softer so you don't notice the jaggies so much.

    *edit -

    Quote

    Who needs AA when you have post-processing now.

    I partly agree with that, but sometimes shaders can't really hide all the jaggies. AA does the job regardless of the look, genre etc. You tick a box and off it goes. It 'just works', which is why so many people complain when it is not available. Like I said, I personally thought GoW looked fantastic without AA but it might not be the case for all games (e.g. Crytek probably invested a lot of time and effort in retaining AA -- it can't have been for no reason). I'm fairly sure the hardware boffins will come up with something to replace traditional AA soon, or they'll make it more compatible with the cutting edge techniques that aren't playing nice.

  • The random model thread!

    If it's small on screen, then it won't get the chance to be blurry unless the player is running a really high resolution. Stuff like weapon view models (which occupy a significant proportion of your screen) can often be textured using a 1024 x 512 pixel texture, so it's overkill to use the same texture dimensions for something that won't ever occupy more than a small part of the screen Downsize it and test it ingame and you'll probably find this is the case -- it's misleading to look at it in the viewport of your modelling package as it'll be occupying the whole screen.

  • Crazy Bump 2.6

    Quote from Sindwiller

    No, seriously. It's not just Crazy Bump. It's all this procedural stuff in general. Procedural texture generation, procedural model generation, procedural this, procedural that - Hell, I even know a guy who want's to get rid off his artists in his team because their "lazy asses" and "slow" etc. by replacing their stuff with procedural content. Everyone praises procedural textures these days.And besides, .NET doesn't run on my box :roll:

    When PhilipK gets fired because a machine can do a better job than him, start getting worried. Until then, don't fret. Can you load up an application and type in "metal wall panel texture with 45 degree angles, bevelling, light fixture in the centre of size 64 pixels, rusted detail down the side, scratches along the skirting and a pimped out normal map please."? You could ask a good texture artist for that. I think genetica would be rather confused by such a request.

    Procedural texturing is just another tool. It has its uses and will continue to improve; it can look good in places but ultimately it is still generic content controlled by buttons & sliders. It is no replacement for an experienced artist, but I'm willing to bet that a lot of artists will embrace it and use procedural content wherever they can without compromising the look of the game. It's the same as anything else -- how far do you want to go?

    Do you spend 3 hours unwrapping a simple prop and getting the texture stretching to a state where it is nigh on perfect, or do you spend 20 minutes on it, make some compromises on quality (perhaps you don't unwrap a curved section particularly well so there is some stretching, but it's on the top / bottom / side / whatever, so it will rarely be viewed up close by the player) and then move on to texturing it or making the next prop? Every part of a game has these compromises and, if the developers strike a good balance, the chances are you won't even notice. If someone can use a procedural tool to generate content and it is either unnoticeable or barely noticeable, then it's a good decision. Spend the time where it counts. If a program can make a texture whose usage is low key, then you can spend that time you saved on something that is more visible. It's the old adage of "work smarter, not harder". Tools evolve to fill a hole and, if they're kickass, they change the way we work. If the tools suck or serve no appreciable purpose, then nobody will use 'em.

  • Crazy Bump 2.6

    Any tool that lets you finish the job faster and with a high level of quality can only be viewed as a good thing, IMO. If you're worried that random plebs can push buttons and get the same results as someone who has invested years of practice, don't be. It's ammo for your arsenal -- just another tool to get the job done. A good developer will just use tools as part of their workflow to enhance the final product, whereas a pleb will be limited to pressing buttons, changing sliders and hoping for the best. If the pleb can't get the results they're looking for, they're stumped. I'm speaking as a texturing semi-pleb, btw

  • Unreal vs Source.

    Commandline tools are necessary and useful, but a GUI extension wouldn't go amiss. It helps newbies no ends, plus there are certain things that are just really monotonous to do by hand. E.g. writing qcs is really, really goddamn annoying. Once you have them done, fine, it's easy to compile them again and again using commandline tools (I personally set up a batch file to compile it and pause before exiting), but it'd be so much easier for people to just open a GUI, choose "new model compile", browse to the appropriate destination folder, select the smd, choose the options they want (staticprop etc), whether to create LODs, whether it has multiple textures, animations, whether to convert the smd's source textures to vtf and so on. Even two+ years on, I still find it a real chore to create a new QC, create a batch file etc.

    There's room for both ways. I personally like GUIs when setting stuff up and then commandline tools once everything is set up and I don't need to change anything, just recompile repeatedly.

  • New 3D feature in Hammer?

    Providing you keep your basic geometry to a decent grid size, it actually is quite useful in the latter stages of a map's development, as you can easily resize stuff using the 3d viewport rather than having to guess what you're looking at in the 2d windows I don't use it much, but it does come in handy now and again. If they extended the functionality it'd be a lot more useful.

  • Unreal vs Source.

    They could at least put in an approximation of lighting using real-time lights displayed in the hammer viewport. If the framerate died, we could at least turn it on/off when we needed it. You wouldn't get the subtlety that radiosity lighting has (like indirect lighting) but you would at least get a feel for the intensity, range, coverage, colour, mood etc. of lights.

    I've seen presentations where Valve demonstrated how they integrated radiosity, normal mapping and various other graphical techniques and they showed a picture of the engine running without radiosity-based lighting. It was basically what I just pointed out -- it looked much the same but lacked subtlety & indirect lighting. It was still a good approximation of what to expect.

    It's in here (click).

  • "Fracture" - Real time terrain deformation, here w

    Quote from Wunderboy

    Dunno if anyone knew, but theres some basic displacement deformation code in the Source SDK. You can define a point, sphere size and if you want push, pinch or pull on the surrounding displacement.Not tried it myself, not 100% sure if its fully implemented or just a hack but its there alright.

    Always thought about making artillery rounds blow real craters

    Yeah that'd be cool. Along similar lines, I had an idea for FF where the round starts and most of the terrain is untouched, but as the round goes on, people walking on the displacements wear away the topsoil (no actual geometry deformation, just a change in the blend values). So basically as the round progresses, you would get to see where people are walking as trails & worn patches of ground develop. We never got around to seeing if it was possible, but it would just involve some kind of collision test, a probability factor for whether the blend value would change and then altering the blend value I think it'd be really cool to see routes develop after a long round.

    As for that video, it's pretty cool but does anyone else think it looks really goofy when the guy casually throws out a tiny grenade and it does all that stuff?

  • WIP in WIP, post your level screenshots!

    Yeah they're initially nice when you start using Source after being used to GoldSrc, but that's exactly why they seem nice -- they are familiar. Too familiar. Once you get past the fact that the tools are familiar to you, you realise what you're missing. Tinkering with Doom3 ed was an eye-opener to say the least.

    The only major advance in the mapping side of things (imho) is the entity I/O system which is far, far superior to the old way of doing things. While Valve has definitely improved the SDK and the engine, it's not adding up to huge leaps forward. The tools in particular haven't had much in the way of upgrades since the SDK was released. What's hammer had? All I can think of is model rendering in the viewports and new model viewer which itself has various bugs (can't navigate using mouse in certain areas) and design issues (doesn't cache results, can't open it as a child window for easy selection & placement etc). I remember learning to compile a prop for the first time... oh fun times. It's not so bad now that I've been making props for years, but it could be so much easier and intuitive. You can definitely make some great stuff with source, but I agree with Wunderboy. It could be so much better.

  • WIP in WIP, post your level screenshots!

    It's horses for courses, really. Displacement editing is better for terrain and patches are better for smoothish geometry Developers could merge both into one tool in the editor though. Displacement functionality by default with a checkbox for patch style editing (or vice versa) would be of great use.

  • WIP in WIP, post your level screenshots!

    Valve could've easily implemented patches. Displacements are basically half way there -- all they'd need to do is add the relevant controls in Hammer and then implement the detail stuff in the engine (so the patch can be subdivided the appropriate number of times). The main difference is that displacements are subdivided planes with explicit vertex positions whereas patches are defined by control points. Even then, they could've easily added quadratic or cubic bezier patch controls to Hammer for convenience (so you could edit the displacement as if it were a patch to get curved surfaces, then just bake out the explicit vertex positions and let the engine use them as is).

    The latter compromise would've greatly aided level designers in making some complicated geometry without having to resort to loads of triangular brushes, displacement vertex nudging or props. If you look at just how integral patches are when it comes to making really cool architecture, I think it was a missed opportunity for Source. The valve guys possibly just felt that Half-life2 and their other planned source engine games wouldn't benefit from having patches, but it would've been cool for 3rd party level designers & modders

    I plan on making a displacement editor with patch functionality using C# after I graduate to help me learn the basics of C#. If I can figure out the .vmf & displacement format it shouldn't be too hard as I already have a good handle on bezier curves, and a patch is further step beyond curves.

  • Wanted: Random models for my uni programming project

    Thanks for that. It's still a bit of a bitch to control, though I'm just wondering whether there's a way to set it up so that your camera rotates on the spot without having to change modes etc.

    I've got a cool canyon model from R_Yell (I split it up and max didn't choke when exporting, so yay) and build a little interior scene around nooba's generator. Still working on it, but they're both looking good. I've got to add a better skybox & fog to the exterior scene and make some other changes, but I'll show a few more screens in the coming days . The interior looks pretty good, but it does have Doom3 everything-is-plastic syndrome. I've got some crazy bug in my app where if a light has a radius of > 256 it converges to a sharp point and I have no idea why. It's really pissing me off but I can just build my scenes bearing this limitation in mind (hack hack hack!)

    Anyway here's one of the interior. Everything is still wip (and I didn't really spend much time on the modelling at all and the room doesn't even make sense, I just botched together a few FF textures and shoved nooba's model in). The lights are fully dynamic and it has shadow mapping for directional & spot lights (you can see the shadows cast by the skylights on the ground) and various other things. Some of the meshes don't have normal maps yet so the normals aren't right (lights & generator in particular). I'll add a few more lights to illuminate most of the room when I have time but I don't intend on doing much more with it. The scene file is edited via notepad so you can imagine how old that gets after a few hours... I've been looking at the positions in max then writing them to a file by hand. Trouble is that max needs to swap the y & z axes, so it makes it even more fun when I'm trying to figure out how to offset lights etc. I know the lights shouldn't be casting onto the ceiling like that, but it does look kinda cool and show off the normal mapping. I wish I had spent more time on the scenes but I don't get marked on 'em so ... blarg.

    [Blocked Image: http://homepages.nildram.co.uk/~msimp2k2/university/interior_scene.jpg]

    *edit -- Here's a first crack at the exterior. My fog is a bit shitty at the moment because I'm not using the fixed function pipeline (so I have to replace everything I've taken for granted for the last x years and write my own version), but hopefully I'll have time to make it look better. I plan on adding a nice clear blue sky and some fog with a bit more contrast & blue hues.

    [Blocked Image: http://homepages.nildram.co.uk/~msimp2k2/university/exterior_scene.jpg]