So, SFM2 is pretty good, but there are some frustating issues and limitations with the tools/engine that are severely hindering its potential.
(for what it's worth, if this adds any credibility to my words, I won the TI5 and the TI6 short film contest with films made in SFM.)
Tons of issues after 7.00
At this point I'd say just check out the rest of this subforum
Grass / wind don't render properly
They're affected by the same "not aware of SFM time" issue as other things.
Not being able to load alternative maps.
Every time a new terrain comes out, it starts out with SFM being unable to load it before someone from Valve steps in and fixes it manually. Every few weeks, the dota_sfm map breaks until, again, someone manually fixes it. Is there something that can be done on Valve's side to prevent these issues in the first place? I'm assuming this has to do with the way the file system works, which segways into my next point...
Not being able to modify base content!
Back in Source 1, we were able to really easily override anything we wanted by just editing the material or texture files, either doing it at the source (dirty) or putting a copy of those files in our own mod/game folder (usermod), the cleaner way. This was simple, a no-nonsense approach.
Now we have some obscure things going on with VPKs everywhere and content/game subfolders, not easily understandable. Now, getting used to a new way of structuring files and folders is not an issue, but as far as I understand it, we are locked from touching anything under the hood of the base game.
I can understand some of this may have an anti-cheat purpose, but either way, it's by far one of the most restrictive aspects of Source 2. My imaginary ideal solution would be a right-click command in the asset browser that allows us to duplicate assets to our own working mod directory, so that we can take an asset and then modify it as we wish. Hell, with S2 having nice dependency tracking, if we asked to duplicate, let's say, sven.vmdl, it could automagically do the same thing with its materials and whatnot.
(in a way, don't we already have this, with particle system instancing?)
Features that work in the game, but work differently (or not at all) in SFM
Some particle operators spazz out (oscillators, noise?). This is not that big of an issue as you can easily instance existing particle systems and remove/replace the offending operators.
The newly introduced grass & vegetation wind display properly in the viewport but behave much like the aforementioned particle operators; they're not aware of time as SFM knows it. The more time it takes to render a frame, the more they'll spazz out in the final render. Video. They also do not get lit up by SFM lights unless using the alpha test command, and the skew (whose purpose is to orient the grass more towards the top-down in-game camera) is not controllable by the user.
Higher fidelity assets?
Most of the hero models are not really good for movie use, mostly due to the texture resolution. Most base textures for a hero are 512x512, but we know from the (older) Steam Workshop art sources that Valve's artists usually create textures at 4x the game resolution, that is to say, 2048x2048. This would be a lot nicer; hell, with the amount of video memory increasing to absurd amounts on GPUs, why not create an Ultra texture setting like how an Ultra shadow setting was created a year ago? If storage space is a concern, it could be enabled with the download of a DLC package, much like the workshop tools. Games like Skyrim have used this method, too!
Providing the SFM versions of character models and other movie assets made by Valve would be super duper awesome as well! For example, the shopkeeper; all we have right now is a low-poly, low-res version of him... other things like custom props, the rigged trees seen in the Monkey King trailer...
No easy/convenient way to tweak global lighting
It'd be immensely helpful to be able to override the map's entities with your own settings, just like you can already override fog.
We are bound to two lighting settings: default day and default night, or a mix in-between... and that's it. We can't fine-tune the colors, the specularity settings, the shadow intensity, etc. all those nice little settings. The only way to do it is to actually edit the map in Hammer, but that comes with its own can of worms... because we don't have all the necessary source files. And even then, that would not be the ideal solution.
So, much like we have individual sliders for fog controls in the camera, being able to control all the global light settings in the same way would be an immense help and super flexible! It could even use the preset system so that we can easily apply all the different weather lighting presets!
Additionally, being able to control the depth bias and resolution of the global shadow map would be kickass. I assume resolution needs a power-of-two size and can't be bound to a slider, but adding a console command so we can go to crazy sizes like 8192x8192 (or even 16k?!) would be great.
There are also commands in the console for cascaded shadows, and assuming it is not an unfinished scrapped capability of the engine, being able to focus a high-resolution cascade wherever you want (regardless of the camera's position or angle) would be awesome. And then you'd be able to leave the background as a second cascade that can cover all the rest where resolution/accuracy doesn't matter as much.
- If a volumetric light's frustum intersects with water, the whole plane of water takes on a very white tinge.
- Ambient occlusion appears on the edge of water.
- 3D skyboxes do not render.
- Sound does not obey the mute setting on the timeline, and plays back during layoff.
- Accidentally "side-clicking" the mouse wheel on wheels that can do that massively screws up the camera
I know there's a lot of other small things I'm forgetting about right now, this is just off the top of my head; but I do hope it will be insightful to Valve employees interested in helping out SFM users to make better films.
If I think of anything else, I will add to this thread.