the 'old' engines were much more fun to work with. you spent 99% of the time inside the level editor. modern engines you spend all your time in 3dsmax/zbrush/photoshop/subtance painter etc. in hammer you could build a lot in one day, for a modern AAA environment you're lucky to finish one complex model in one day. constantly switching around from one sterile looking piece of software to another sucks the fun out of making content. compare that to building-theme games where you could easily spend many hours in one session without ever losing fun/interest. when besieged came out i must have played that shit 10 hours straight, but i could never get myself to model in 3dsmax for that long without getting bored.
shits only getting worse too. i expect in 10 years we'll have a different piece of software for every little fucking detail in a game.
Valve is going to be talking up the new Source engine at GDC in 2016. Some things to know about it are:
>simplified workflow for getting assets into the engine (unconfirmed, but something Gaben himself complained about) >PBR materials (unconfirmed, but widely suspcted from some demo videos that are floating around) >completely free (no royalties at all, no price tag) for anyone to make games with, but they have to release on steam (confirmed, can be released elsewhere as well, which is also confirmed) >modern multi-core/hyperthreading support (confirmed) >there is a real-time tech demo floating around with a single asset (one of the portal robots) rebuilt with over 400k tris, and it's in a similarly detailed environment with other robots wandering around >built in modeling tools (confirmed)
Basically, it's an upgrade that fixes everything that people have been bitching about with Source for a while now. Some people seem to think the SDK will include a compiler for assets that imports .fbx files. If so, that would solve the single biggest problem with the current Source engine.
Does anyone here know of a solid workflow for going from Maya LT to the Source engine? Getting shit into SFM is a nightmare unless you use Blender. Nothing against Blender, but I'd rather use Maya LT because I am more productive with it.
>>506671 lol. whatever you build in hammer in one day will look like shit. %95 of the Source mods out there are absolutely garbage. And you would also need to go through the same process if you wanna import custom models into source which is a neverending living hell even with import tools, where as other apps you just drag and drop and thats it.
Not to mention modern AAA games look and play 5000 times better than anything ever done with Source. Quality stuff takes time to create. You're just stuck with source because you can't keep up with the new stuff and you're destined to use that ancient old clunky shit.
The future is the modern AAA engines and you will slowly die down as your community dries out one by one.
>>506688 i haven't touched source in ages, i've been using UDK/UE4 now for years, i just wanted to say that i miss the 'good old days' of working with simple graphics and BSP geometry, because i remember it being more fun than what i do now. i've been working a whole week now sculpting/modeling floor and wall pieces that would be nothing more than flat BSP geo 8 years ago.
you're wrong to think AAA ultra-realistic graphics are the future, most games are using more dated graphics, stylized graphics, indie shit (2D). chances are that early 2000's graphics will become a thing again just like pixel/2D games are today. the ever increasing demands for realistic graphics will only continue to drive up production costs meaning only a handful of studios will have the resources to invest into making such games. in other words, call of duty / battlefield shit.
>>506704 I honestly don't know much about this topic, but some of the best games (my opinion) I've ever played were on older engines. I don't think it matters what engine it's on, it just depends on who's making the game.
exporting custom 3d models for hammer is such a ridiculous pain in the ass. The best tool i know of is www.wallworm.com its a plug in that works for 3ds max and makes the whole process way simpler after setting it up to work with whatever source game. The wall worm tools allow you to use 3ds Max as a replacement to hammer if you can follow all the documentation. For me it's just an amazing model exporter straight to source. PROPS!
>be playing bf4 on lowest settings on my laptop(toshiba satellite p875-s7310) >able to play well with no hiccups >about 40 to 50 fps constant >WOW THIS PLAYS WELL, LET ME FIRE UP GMOD AND CS GO >complete mess >hiccups every 5 seconds, 20 to 30 fps on lowest settings WITH 480p >get mad and go lurk /3/ >see this thread talking about how great source is >get mad and make a shitty greentext >post it
Garry's Mod used the old Source engine, not the new one that now powers DOTA 2. DOTA 2 doesn't look great desu, but it's a port from the original SOurce and made to run on toasters. Wait till GDC in 16 to see the new SOurce doing its thing.
>>506630 I've been using hammer for 6 years and in that time I have never finished an original project and now days I don't even bother to start new projects because I know im just going to scrap it within 30 minutes.
I also cant seem to pick up any other game engine to learn level design just because it's nothing like hammer.
>>506630 >>506632 >>506672 >>506688 >>506704 >>506732 I've used Source Engine pretty extensively, I'm moving to UE4 mainly because the support for tools isn't there anymore. Making anything look good in engine is pretty difficult whether its UE4 or Source, but its undoubtedly easier to get "good" looking results in UE4 rather than Source. That being said, the renders coming out of Source can still be somewhat impressive. Although UE4 easily blows Source out of the water in almost every respect.
UE4 is actually still fairly new, the cinematic tools for it aren't there right now and doesn't compare to the ease of use of SFM for rendering videos yet.
Wallworm's tools are definitely your best bet if you're into world building with Hammer.
Heres a video I made with SFM, most of it was created with putting props together. The base of the map was decompiled from Hammer and then recompiled to suit my needs.
>>506960 Whoops, what I meant was that Matinee has a long way to go, Epic is still working on making it more sensible to use.
In terms of the amount of features for camera controls such as depth of field, exposure speeds, etc UE4 definitely has a leg up from what I've seen so far... although I haven't seen any kind of shutter speed controls on the Matinee camera yet!
In terms of usability/ease of use SFM's controls has a huge advantage. There are tools that allow you to lock the exactly point of where you want your depth of field to focus onto a bone of a model. Getting a "hand-held" style shot with SFM is way easier as well. From what i've seen with UE4 everything the camera does is keyframe animated which is theoretically what -should- be done for animating cameras but sometimes you just need a dirty hand-held look which is easier to get with SFM.
The way I'm trying to learn how >>506961 to use Matinee at the moment is basically just by looking at examples that Epic has created (the hand to hand fight scene and the infiltrator demo which takes 20 years to load.)
I believe a tool named Director's Tools came out for UE4 which might cover a lot of the grievances I have with it. It costs about $50 right now IIRC, I haven't had time to check it out yet but the trailer looks pretty promising. I'm sure Matinee is definitely capable of really good looking results, just seeing what people have created in the past. However, getting to that level of quality looks like a pain in the ass every step of the way at the momement. Of course that shouldn't stop you from trying... You could probably find tutorials on cg torrent sites but I honestly haven't checked them out yet when I should.
With SFM I baked the animations into the model and then played them as a sequence.... then I edit it with the graph editor in the end to make things fit better... With UE4 it looks one imports the animation onto the model. >>506961 Thx, try Crowbar Decompiler!
Why is there not a simple goddamned way to get assets into SFM? It's like they want it to be as fucking difficult as is possible. It's insane.
Someone should write a single program that takes an FBX and converts everything to the intermediate file types, and then with another click compiles ot the target Source application. Fuck no, though. Shit can't be allowed to be simple.
>>506630 >Any of you boys like world design? Specifically Hammer Editor? I do it. rarely.
Source engine is so backwards, isn't worth your time to learn it.
If soruce 2 is like this, you can grantee that no one will be able to use source 2 for modding because only a select few know now.
>>507034 >Someone should write a single program that takes an FBX and converts everything to the intermediate file types, and then with another click compiles ot the target Source application. Fuck no, though. Shit can't be allowed to be simple. >Fuck yes I mad. There is a program but its guarded its a paid thing.
>>507066 >>507061 >>507073 Guess you guys didn't hear the news, like, last year I think? Dota 2 is on Source 2 now. It's DX11 64bit. It also came with a new Source 2 editor so people can make mods/custom maps for Dota 2. It allows custom modeling importing, scripting/coding, level building and all that jazz. It's much easier to use than the old Hammer editor.
>>506677 >simplified workflow for getting assets into the engine (unconfirmed, but something Gaben himself complained about) already in some form in dota2 toolset >there is a real-time tech demo floating around with a single asset (one of the portal robots) rebuilt with over 400k tris, and it's in a similarly detailed environment with other robots wandering around not surprising, source has little problem handling crazy polycounts, the only limitation so far was that single model could not exceed 30+K iirc >built in modeling tools (confirmed) yup, already in dota2 toolset, includes ability to load any model into editor and modify it for use as a static, possibly full source 2 will take it further >Basically, it's an upgrade that fixes everything that people have been bitching about with Source for a while now. dont think so, I doubt valve will add full support for dynamic lights and do something about their spaghetti code.
>>507527 >dont think so, I doubt valve will add full support for dynamic lights and do something about their spaghetti code. That already happened years ago thanks to the Alien Swarm devs. They implemented a deffered lighting pipeline in Source and Valve brought it into global source and refined it, used it for Dota 2 lighting. You can have dozens of dynamics lights without issue.
>>506677 >PBR materials (unconfirmed, but widely suspcted from some demo videos that are floating around) Dota 2 is already using this... It's a metalness/glossiness workflow (for some reason they're calling the gloss map a specular still). http://media.steampowered.com/apps/dota2/workshop/Dota2ShaderMaskGuide.pdf
>>modern multi-core/hyperthreading support (confirmed) Yup, long since confirmed when Dota 2 moved to DX11 and 64bit Source 2 last year...
>>507532 The scripting language is already confirmed to be LUA, as seen in the Dota 2 workshop tools. https://developer.valvesoftware.com/wiki/Dota_2_Workshop_Tools/Scripting/API#Accessing_the_DOTA_2_Scripting_API_from_Lua
Such as? How do you make a distinction between when use which language?
Also, any ideas on how the license for S2 will look like? I have a serious problem with Unreal as it is now. They are able to freeze your whole project or even force complete deletion of all code and assets, even screens. I'm not sure, but Unity might also have something, where you need to show their brand on the product, but they also can ban you from using it, so in essence they muzzle you as well.
I don't ever want to hear "derp, sorry bubb, but we rejected your submission to Steam, so you can't publish it anywhere else either (we don't want your shit hurting muh brand). Maybe try something less problematic next time. :^)". I swear if they can do that and potentially torpedo years of my work I'm not touching their engine.
>>506671 Please be trolling. You're not seriously implying hammer is a good level editor. It's so cumbersome and limited... Everything is made out of very basic primitives. There is no possible way to make curved brushes. Modeling any remotely complex shape in hammer takes forever and looks like shit. It doesn't help that everything needs to snap to the grid. And sometimes, even if the brush looks alright in hammer, it compiles with slight offsets due to engine limitations. There is also no sense of scale in hammer. You pretty much need to eyeball everything, or use the dev textures. For example, if I want to make stairs, how do I make them all the same size, if there aren't any units, and you have to have exact multiples of certain values, or else you can't do it (because you must be snapping to the grid at all times)? And to add to my comments about the blocky brushes, you can't use displacements because they don't behave as a brush would. And displacements look like shit for anything besides terrain because basic tools like sweep and revolve are missing. The only commendable thing about hammer is the input/output scripting system they added for the source engine.
>>509112 not him but I'm gonna bite >It's so cumbersome and limited... yes, outdated as fuck and really clunky in some areas
>Everything is made out of very basic primitives. yes and no, while they are your main tool, you can use models and displacements
>There is no possible way to make curved brushes. clipping tool, vertex manipulation, displacement tool and arch tool. also you can model it
> Modeling any remotely complex shape in hammer takes forever and looks like shit. hammer is not for modeling, thats what you use max/maya/blender/whatever for
>It doesn't help that everything needs to snap to the grid you can have plenty of things that are off grid, only primitives have to obey grid
>even if the brush looks alright in hammer, it compiles with slight offsets due to engine limitations. stop being a shit mapper, I bet you compile in fast vis
>There is also no sense of scale in hammer. can agree, while hammer uses its own arbitrary scale which is supposed to be in inches, it still does not match real world simply because of FOV used by engine
>You pretty much need to eyeball everything, or use the dev textures >he still uses devtextures other than graygrid
>if I want to make stairs, how do I make them all the same size, if there aren't any units common dimensions in half-life 2 and similar games: wall - 128hu step - 12x8hu vent - 64x64hu
> and you have to have exact multiples of certain values, or else you can't do it (because you must be snapping to the grid at all times)? you dont have to snap at all times unless you use primitives for example if you are doing steps again, max step height is 18hu, which is referenced on wiki btw, and if you wanted to do for example stone steps in some temple that are cracked and irregular, you can easily make them with regular brushes, vertex work and remembering to never make a step higher than 18hu.
>And to add to my comments about the blocky brushes, you can't use displacements because they don't behave as a brush would >And displacements look like shit for anything besides terrain because basic tools like sweep and revolve are missing. displacements main limitation is that they cant seal the void or be turned into an entity (they were supposed to be at one point, notably e3 demo from 2003). other than that, displacements trump brushes in many areas: >they are cheaper to render >they allow blending materials on them >they allow fine tuning of verts >they are primitive sculpting surfaces you can easily make enterable building out of displacements and guess what, all it requires is proper planning. to make a displacement, your desired brush surface needs to be four sided, others dont have to, and to do advanced sculpting where there are not visible seams, like for example in building I mentioned, you just need to plan topology ahead, which is fucking easy considering primitive system that you cry about so much.
now you wouldn't be posting on /3/ if your topology was shit, right?
>The only commendable thing about hammer is the input/output scripting system they added for the source engine. add to that ability to handle crazy-large numbers of polygons at one time
and if you really cant stand polygons, you can build your map chunks in maya/max/blender and just assemble them in hammer, and no, models dont have to snap to grid
Hammer editor is actually kind of fun to user. I've released a couple of maps and made some chunks for other people's maps. Ive also done a lot of optimization in hammer for friend's maps before release. It's a really easy tool to use, you just gotta spend some time learning the terminology, funny quirks, and how vbsp, vvis, and vrad all work.
>>509130 Using models in place of brush geometry doesn't work. Models are not endowed with the same properties and would cause reduced performance. Also, displacements are limited in more ways than just not sealing the world. For example, they can't be turned into brush entities or physboxes. Also, like I mentioned before, there are inadequate sculpting tools.
All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
This is a 4chan archive - all of the shown content originated from that site. This means that 4Archive shows their content, archived. If you need information for a Poster - contact them.
If a post contains personal/copyrighted/illegal content, then use the post's [Report] link! If a post is not removed within 24h contact me at firstname.lastname@example.org with the post's information.