Page 1 of 2 1 2 LastLast
Results 1 to 10 of 16

Thread: SFM2's limitations, and proposed solutions

  1. #1
    Basic Member MaxOfS2D's Avatar
    Join Date
    Jun 2015
    Location
    France
    Posts
    97

    Lightbulb SFM2's limitations, and proposed solutions

    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.

    Other niggles

    • 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.
    Last edited by MaxOfS2D; 12-16-2016 at 10:33 AM.

  2. #2
    Basic Member
    Join Date
    Apr 2013
    Posts
    22
    I agree with everything. Also will be great to see water reflections (we can see them in game and hummer editor, but not in SFM).
    BTW you can use global light presets from ingame weathers in SFM. Open your Camera in Element Viewer, add new atribute, name it weatherType and choose type int. Then change value from 0 to 10+.

  3. #3
    I believe Valve has missed the needs of the user by quite a mark with the SFM, and I've gone back to the original SFM because of this. Here are a few things that need to be changed, in my opinion:

    File structure

    As filmmakers, we would prioritise the ergonomics of managing assets over the convenience of synchronising assets with the game whenever the Dota 2 client receives an update. Consequently, using the same packages as the base game is detrimental to the user's control in the Dota 2 SFM. We would very much prefer it to be standalone or at least more independent from Dota 2's base game. Now, this would likely have an impact on how maps are handled between Hammer and SFM, but to be quite frank, even the conveniences of the Hammer tool in the Dota 2 SFM over the standalone version is not enough to warrant being unable to modify base content.

    To add to OP's statement of high quality assets,

    It's safe to assume that the majority of content creators have fairly high-end computer rigs, and right now, the Dota 2 SFM, or just the whole workshop tools in general, feels like it was made for the typical gaming consumer. When there are highly noticeable asset quality issues in the works of someone as experienced as MaxOfS2D, it's obvious that these issues need to be addressed. If these artists are even barely able to produce a beautiful work, you could be sure as hell that the rest of the community is going to suffer from the low quality of the game's assets. Additionally, it's no secret that Valve themselves often use higher quality models for their promotional films, but this is a stark contrast with what Valve has done in the past for the characters of L4D, TF2 and other games.

    While I don't expect Valve to release their in-house assets, much of this can be resolved with two things:
    1. Allow the community to edit the game's base assets. The models from the workshop requirements references don't have flexes/morphs, so they aren't optimal for creating custom edits off of. Even if morphs are implemented into those assets, non-hero assets become an issue. Material editing for base content is impossible right now, and texture overriding is difficult as hell as a result. e.g. If I wanted to use the source texture of Beastmaster in the Dota 2 SFM, I would need to create an asset in this exact location: "/[Workshop Mod Content Folder]/materials/models/heroes/beastmaster/beastmaster_arms_color_psd_f249eb60.vtex". This is too much, especially since that "f249eb60" seems to change every few updates. This is where material editing would make life easier, since you can place the source material wherever you want and reassign the diffuse texture.

    Speaking of source textures, we would like them back on the workshop requirements page :S.

    2. Open up some sort of community workshop category specifically for the Dota 2 SFM. One of the main reasons why the standalone SFM community is still so strong today is because of the constant flow of custom assets from the workshop. The Dota 2 SFM does have its own way of importing custom assets, and it really should be taken advantage of by a workshop system.

    3. The render system has a long way to go.
    - As stated before already, water is horrendous in SFM. Even the Hammer editor has better water.
    - Bloom would be nice to have.
    - Particle lighting and shadows would be a cherry on top. Both of these broke in the standalone SFM a while ago.

  4. #4
    Basic Member
    Join Date
    Jul 2015
    Posts
    132
    Just going to add some of my own views on your talking points:

    >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.
    This is extremely frustrating. Going back to your first point, this should really be changed to have a separate asset bank so we can edit main game files. I know that the main files are on lockdown so you cannot do cheats like the pumpkin cheat, but as long as you don't inject the vpk with changed files, why can't we get some sort of sfm map that we can change as sfm users. More specifically, is there a way to maybe sign a copied file of the vmap_c's that are decompiled and usable? Having to build a full map with sfm trees is extremely time consuming and tedious, when all I really need to do is delete/change-out 3 trees in the whole map.


    >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.
    This is wrose than you think. If you ever make a time dependent material dynamic expression, it just won't work correctly because, as you said, and I stated in one of my other threads about this, that there really isn't a 'time' in sfm. There is, but the counter starts as soon as the tools launch, and count up indefinitely. Read more about that here: http://dev.dota2.com/showthread.php?...namic+material

    >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...
    This is also impossible to even change if you want to work on certain heroes. If you want to fix techies' elbows, arms, etc. You can't even get the vmesh without jumping through a shitload of hoops in a vpk viewer. Then, you lose all flex controls. So you might as well either take a hero model off the workshop references (of which some are still erroneously outdated), or you might as well model your own hero. And it is quite sad to see some assets from inhouse productions untouchable by sfm users. I have a tree in my scene that's only rigged to bend and move with the destructible version of the normal dota trees. It looks okay, but obviously not that great.

    >If a volumetric light's frustum intersects with water, the whole plane of water takes on a very white tinge.
    Me and Clinton posted this almost a year ago to still no word on the issue or a fix :/ I assume it has to do with something pretty deep in the HLSL code with their water shader.

    >3D skyboxes do not render.
    They render in game with it added to hammer, even for custom maps, but they're worthless for sfm currently, which is pretty sad considering there's that half dome model and full dome model, and they just don't work, and on top of that, they're pre-compiled so we still can't mess with them and maybe even use the vmats for our own models.
    >Sound does not obey the mute setting on the timeline, and plays back during layoff.
    I actually don't have these issues for some reason. During layoff, my sounds don't play until the render completes, then it just makes the same sound that whatever the last frame to be rendered was playing.

  5. #5
    Basic Member
    Join Date
    Jul 2015
    Posts
    132
    Adding to this, applying particle systems to game models such as this in the particle editor:

    AaCXT5K.png

    Doesn't work as someone pointed out in the slark immortal bug post.

    It should work here:

    shGFzOG.png

    But it doesn't of course.

  6. #6
    Valve Developer
    Join Date
    Jun 2015
    Posts
    15
    Thanks for all the feedback!

    We're not doing patch notes while we're in continuous update mode, but some of those problems will be fixed in an update later today:

    SFM - fixed loading of dota_* map variants, present and future
    SFM - fixed trees getting culled near the edge of the camera view

  7. #7
    Basic Member
    Join Date
    Jul 2015
    Posts
    132
    Quote Originally Posted by joe_prime View Post
    Thanks for all the feedback!

    We're not doing patch notes while we're in continuous update mode, but some of those problems will be fixed in an update later today:

    SFM - fixed loading of dota_* map variants, present and future
    SFM - fixed trees getting culled near the edge of the camera view
    Okay cool. Can confirm both of these work.

    But it would still be great if someone would come by and at least look at these issues and give some sort of sign that they've at least been seen. It doesn't have to be daily obviously, but I mean, once a week if someone could be like "Thanks for the report, we've added it to our list", that would do so much help and make less people, like myself, feel like we're working with an unsupported toolset. Especially with some of these issues like the concept of time in sfm messing up a lot of the assets. Without of those at least being acknowledged, we can't use basic functions of sfm (such as progressive refinement).

  8. #8
    Quote Originally Posted by moartuba View Post
    Okay cool. Can confirm both of these work.

    But it would still be great if someone would come by and at least look at these issues and give some sort of sign that they've at least been seen. It doesn't have to be daily obviously, but I mean, once a week if someone could be like "Thanks for the report, we've added it to our list", that would do so much help and make less people, like myself, feel like we're working with an unsupported toolset. Especially with some of these issues like the concept of time in sfm messing up a lot of the assets. Without of those at least being acknowledged, we can't use basic functions of sfm (such as progressive refinement).
    There's a reason they don't do this. It's better to neither confirm nor deny their awareness of an issue than to acknowledge it and be unable to fix it due to unforeseen circumstances.

    As much as SFM's development doesn't take a very high priority in Valve (and IMO it really shouldn't be over game patches and Steam development), I would really want to see just general stability for the software. When there are 2 annual film contests held every year and the participants of both use SFM extensively, making sure the software is actually working upon every major update should have enough priority for compatibility fixes in the initial update release or at least a Day 1 patch. After all, community creations are one of the biggest sources of marketing material for all active Valve games.

  9. #9
    Basic Member
    Join Date
    Jul 2015
    Posts
    132
    Quote Originally Posted by ClintonM0 View Post
    There's a reason they don't do this. It's better to neither confirm nor deny their awareness of an issue than to acknowledge it and be unable to fix it due to unforeseen circumstances.

    As much as SFM's development doesn't take a very high priority in Valve (and IMO it really shouldn't be over game patches and Steam development), I would really want to see just general stability for the software. When there are 2 annual film contests held every year and the participants of both use SFM extensively, making sure the software is actually working upon every major update should have enough priority for compatibility fixes in the initial update release or at least a Day 1 patch. After all, community creations are one of the biggest sources of marketing material for all active Valve games.
    Well I mean something more along the lines of most forums where there's a color to a post if a dev has at least clicked the link. No need for formal communication or anything, but at least - hey a dev uses these forums or clicks threads. It would help with all the spam as well.

  10. #10
    Basic Member
    Join Date
    Apr 2015
    Posts
    8
    i got "unsupported graphic card" for my GTX 970 with DX 11 installed since day 1 patch, can anyone let me know what should i do or any workaround for this?


    dx 1.PNG
    Last edited by suisiao; 12-19-2016 at 07:26 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •