Quote from CyanideCotdPnutsI disagree. That modeling tutorial is bogus because it teaches you to work with NURBS which is not a standard tool most modelers use, especially for low-poly stuff such as this. If you have access to the HLMV, reference their topology. That's how I learned how to do low-poly organics.
It's actually a sub-d tutorial iirc, so the low poly mesh stuff is also applicable
Quote from Spellbinderabout bolean operations?
About any and every modeling technique / tool available. Just run through some of the tutorials -- there's loads; look through them and find something that covers the basics of the type of modelling you're interested (likely polygonal). Every technique and way of working is ammo for your arsenal.
Just keep practicing...
Read the max tutorials and get a solid grasp of the basics before you ask people what you're doing wrong; there's not much that anyone can say to you other than "learn the basics".
viral advertising? 
Need bigger screenshots. I tend to find that small screenshots are very hard to use for critiquing work / offering suggestions as:
A: they always look better than fullsize screens (not sure why, but they always do) so I find them to be a bit artificial
B: I can't see any detail!
I'm so gonna buy this. Can't wait!
Last time I tried to use the env_tonemap_controller (shortly after the big SDK update) it didn't work with the new engine stuff we use for our mod. Even loading the source sdk base (i.e. the app that does nothing but load the lost coast background map) would result in the message "unknown entity type: env_tonemap_controller" being displayed, and that was valve's stuff, not mine.
Try compiling your map for CS:S / DoD:S and see whether it works as expected. If so, it's likely the new engine stuff that's not working.
Some other links regarding looping:
http://ambient-whisper.cgcommunity.com/ ... age-3.html
There used to be a great page here too, but it's down now 
Hah, that's goddamn sick. Love it.
Procedural methods don't really offer enough flexibility right now -- you tend to find that most procedural textures are generated using similar methods (perlin noise [see the ubiquitous render->clouds in PS...] etc). There's not enough control or finesse available to make game textures as a replacement for hand-made textures imo. I mean, there's enough there to do some stuff and certain materials can be done pretty well, but how do you account for wear and tear, paint splashes, ripped paper, moss, water damage, scuffs and all that kind of thing? I'd say that procedural textures can complement existing methods, but they're a long way away from replacing them.
Quote from NykO18Hey, I know what func_detailling means.But, when half of the map is made of cylindrical tunnels, it's not really a good idea to shape it quickly inside cubic rooms. Especially when there's an insane amount of detail and expensive water.
I prefer waiting 7 or 8 hours (night compiling) and getting better FPS than doing a one hour compile and getting crapy vis-blocking.
You do realise that it isn't free to recurse the bsp tree during runtime? The idea that compile times and runtime performance are somehow disconnected isn't true -- if you have a million tiny little fragmented vis leaves then you also have portals connecting them, particularly when you have a local area that has a disproportionate complexity compared to the rest of the map. This slows down rendering, probably decreases the batching efficiency of the engine, collision detection and visibility determination. It's sometimes not a huge difference, but the assertion that doing it the way suggested will result in "crappy" visblocking and poorer framerates just isn't true. If you do it in an optimised fashion, vis won't suffer in terms of what is being drawn/not drawn. Furthermore, sometimes it is more costly to vis-block something than it is to render it! It's not a black and white issue really, you just need to experiment.
Quote from NykO18Well.. try to make a map with a large natural and irregular exterior with houses and a sewer network just under, composed of cylindrical rooms cut by cylindrical tunnels at 45°. The VVIS will pass a really hard time trying to figure out what's happening in there. And when compiled even if the compilation last 7 or 8 hours, it doesn't bug or whatever, everything's normal.
Like you, I think that for "classic maps", VVIS should not last longer that one hour. But in some other case, it seems to be inevitable.
Like SW said, there are ways to get around a lot of these problems. In many cases you use world brushes at right angles and make up the rest of the shapes using func_details while achieving the exact same visuals.
I wrote a dev journal on this ages ago, you can find it here:
http://www.fortress-forever.com/?a=devj (near the foot of the page).
Some pics along the same lines as SW's:
http://www.fortress-forever.com/~defrag ... e_full.jpg
http://www.fortress-forever.com/~defrag ... _empty.jpg
If it's taking anything approaching an hour I'd be concerned, even with a big map. Your goal is to basically make your base map geometry as simple as possible. Anything that is small or doesn't contribute to visibility blocking should be func_detailed. Slanted geometry can usually also be optimised.
The chances are that you've got some crazy BSP cuts going on somewhere and it's causing a lot of vis errors which creates a much more complex visibility set, causing the compile time to be vastly inflated. Run BSP and output to glview (check the valve wiki if you don't know what I mean), then open glview and look for the high-complexity areas where the leaf complexity / density is all wrong. This is the absolute best way to spot problem areas and oversights.
I use a .bat file to compile the map & run glview. I save a .vmf to "latest.vmf" then run this:
cd "X:\Valve\Steam\SteamApps\youraccountname\sourcesdk\bin"vbsp.exe -glview "X:\Valve\Steam\SteamApps\youraccountname\sourcesdk_content\modname\mapsrc\latest.vmf"
glview.exe -portals "X:\Valve\Steam\SteamApps\youraccountname\sourcesdk_content\modname\mapsrc\latest.gl"
pause
Obviously change the paths & modname to match your own directories.
It's based on the FN-2000 afaik:
http://www.bf2benelux.com/page/bf2sf/wapens/fn_2000.jpg
You can see this gun in loads of games.
Btw, if you want to get some non-functioning links working, just click drag the URL into the address bar and it'll usually open when copy&paste fails. 
Y'see, white zombies walk like this: A doodle dah, de doodle do...
That zombie is so playing air guitar. Great stuff!
Yeah that's cool, hessi. A tutorial would be nice 
I'll try and summarise :
Basically, instead of rendering your geometry in a traditional sense, you instead write out the attributes sans-lighting (position, diffuse colour, normals, depth, any other parameters you need like spec, spec power etc.) to a so-called g-buffer (basically into graphics card memory as a series of render targets [dynamic textures]), then you do the shading as a post process (hence the name, deferred shading). It results in a reduction in rendering cost in terms of reducing the amount of passes it takes to do complicated effects, plus it means you get the added bonus of efficient perfect pixel rasterisation. Using deferred shading, you don't get any wasted effort rendering expensive operations to an area of the screen only for an object to cover the same area later on. It also scales very well for multiple lights on multiple surfaces, but I don't yet undertand how the actual lighting calculations work when using it, so I can't go into that.
http://www.talula.demon.co.uk/DeferredShading.pdf explains it pretty well.
I'm thinking of doing my final year honours project on deferred shading. It's a technology degree (I'm a programmer, allegedly!), so the focus would probably be something along the lines of how deferred shading can be used, what the pros and cons are and whether it is well-suited to current or next generation games. I'd implement a bunch of deferred shading demos and probably contrast them to forward-rendering in a variety of scenarios, then evaluate the technique and how it fits into real-world games.
As I understand it, deferred shading has only really become a possibility with recent graphics cards (geforce 6 onwards) due to branching in shaders (so you can have a wider array of material types as opposed to being stuck with a few) and the prohibitive fill rate demands. As games include more complex lighting models that require multiple passes, deferred shading will probably get more popular since it scales better as lighting compexity increases, plus it has a perfect success rate when it comes to rendering only pixels that are visible. I know it breaks AA and alpha-blending, but you kinda solve the former using an edge blur shader (not as good, but I guess it's ok?) and the latter just by rendering the alpha-blended surfaces using the forward renderer as a separate case.
I'm just reading around the issue right now as we have to decide on a project soon. I was initially set on trying to splice distinctly different scene management strategies (like mixing BSP, portals and octrees to allow a wide-ranging environment in a seamless fashion) but ultimately I don't think I have the technical skills to accomplish that task or, even if I did manage it, I'd probably get bogged down in writing / altering editors, compilers, rendering apps and other things that were necessary, but ultimately on the periphery of what I was trying to achieve (prove a concept).
So basically I'm interested in whether any of you guys have worked on a game or engine that used or was using deferred shading. The reason I say "used" is that I've heard quite a few titles tried it and ditched it because older hardware didn't give satisfactory results. If so, what were your experiences of it in terms of flexibility and how did it stack up against traditional forward rendering? I say this with regard to both technical and artistic angles.
Any thoughts (that you can give me outwith NDA stuff etc) on the subject would be great, cheers. I think this is probably a good topic to tackle as I can't find any consensus on whether deferred shading is or will be a good option to use and there seems to be a lot of debate on certain sites regarding whether engines like Unreal 3 are using deferred shading for specific parts of their rendering code. No consensus makes for a good topic, ja?
