Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Official Visual Effect Graph Public Roadmap Now Live!

Discussion in 'Visual Effect Graph' started by quixotic, May 6, 2020.

  1. quixotic

    quixotic

    Administrator

    Joined:
    Nov 7, 2013
    Posts:
    122
    Please check out our newly created public roadmap: https://portal.productboard.com/unity/1-unity-graphics/tabs/9-visual-effect-graph

    What do card states mean?

    In Progress means it is currently being worked on. This is not a commitment that it will land in the next version of Unity - a lot can happen in development, larger features might take multiple releases to finish or miss the landing window.

    Next Up this is the work we plan on getting to as we clear out in progress. Votes here might impact the order we do things. As with everything, these items could move around depending on priorities.

    Planned we expect to do this work. This isn't a timeline commitment, just items we have identified as being important to have in Visual Effect Graph. Votes here will definitely help shape priority order.

    Under Consideration we think these might be useful. We could use votes here to know how helpful it is and especially if there's anything burning especially in comparison to everything else on the roadmap.


    How does voting work?

    1) Click on the item you're interested in.

    2) How important is it to you? If it's "Nice-To-Have" that doesn't mean we won't do it - it might be great to knock out a bunch of nice to haves. On the other hand, "Critical" doesn't mean we'll drop everything else for it. Sometimes things are only critical for certain uses, sometimes we have to do other foundational work before we can get to the criticals.

    3) Why do you need this? This information helps us understand why you need something, and we can validate that it will solve your problem. Sometimes people will vote: "I need this in order to do A, B, C, and bananas!" and we'll go "Oh, this solves no bananas problems so we have to create another item to deal with bananas". I will also let our technical writer know about this information - so that as documentation is written with those uses in mind. If you give me something fantastically specific (actual Shader Graph example: "Make rpg party portraits tint-pulse when character is hit/heal and desaturate it when reach zero hp." - I love this) then when folks are creating example content I'll pass it along as an option for the kind of example we might want to make.

    4) Your email address. This has to be a verifiable email address. Your email address will not be added to any mailing lists or get directed to any marketing/sales type things it says just in our feedback directory. I will email you if: we're thinking of an approach to a problem and want to make sure we're solving that problem for you. We have questions about your use case - like "this will really solve our bananas problem" and we're not sure the feature will actually solve for bananas. I might also drop you a line when the feature has landed and, asking if you wouldn't mind trying and giving us feedback (I haven't always done this in the past because sometimes the volume is hard to keep up with).


    Submitting New Ideas

    1) Click "Submit New Idea" in the top right corner.

    2) - 4) Same as "How does voting work" section.

    The only thing to note is that it appears in the inbox as "Unity Graphics" and whatever you write. We have no context for which board you were on when you clicked new idea - so make sure to include thorough information on what feature area. We won't add every item - sometimes we will want to do technical due diligence (as we don't want to put up things we have no idea on the feasibility about), and sometimes items won't be a match for our current priorities (in which case, I do hang onto all of those so we can review them every so often).


    Updating Public Roadmap, Triaging Feedback and New Ideas

    Every 2 weeks I'll be meeting with the wonderful Visual Effect Graph team to 1) make sure our "In Progress" and "Next Up" are accurate (and make changes as needed), 2) Go through all the received feedback, flag any questions or follow up and 3) Go through all the new ideas to see

    Will you folks take a look and please vote on things? In this thread, would love any feedback on the descriptions - this is just the first pass, and I'm sure we could add more clarity. This thread is not for "why isn't feature x on the roadmap?" as the answer I will give is "because you haven't submitted it yet" : D
     
    LooperVFX, BigRookGames, Olmi and 5 others like this.
  2. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    If the items that open up the most potential are prioritised then many of those features would write themselves.

    For example - don't do fluid simulation - just add the features that would allow something like https://github.com/fluviofx/fluviofx to do what it needs to do.

    Allowing HLSL and C# nodes would allow people to add many of the other features on the list. Those and similar enabling features should be top of your priorities.
     
    LooperVFX and yty like this.
  3. JulienF_Unity

    JulienF_Unity

    Unity Technologies

    Joined:
    Dec 17, 2015
    Posts:
    324
    @andybak While I tend to agree with your statement, do not forget one of the main target users of VFX Graph are artists. Not all teams have resources available to extend the VFX Graph, and we also need to ensure it's not only a framework to build on top but the tool is also provided with the required set of features out of the box.

    So all this is not mutually exclusive, we plan to focus on opening doors for extensibility incrementally and all features we're developping are consistent with that. C# API for custom nodes will come when we're happy and sure that the API is mature, robust and clean enough to be made public because once it's public it cannot be changed anymore and we have to ensure backward compatibility (and also API needs to have full doc coverage). So we don't want to rush it and will unlock stuff incrementally. In the meantime we provided a subgraph feature that allows you to extend quite a lot the graph features already (even if of course not replacing C# API but rather complementing it)

    So yes, we're aware of the need to improve extensibility and that it will allow more missing features to emerge and be developped directly by users and we take that into account when defining priorities. Our goal is that the VFX Graph becomes a fully extensible framework both for artists and programmers and we have no plans to keep things hidden or opaque on the code side.
     
    Last edited: May 13, 2020
  4. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    EDIT - on rereading your reply I realise you're mostly agreeing with me so this is probably a touch overstated. I'll leave it as originally written however)

    @JulienF_Unity

    > Not all teams have resources available to extend the VFX Graph,

    This is slightly missing the point. It's not about your "team" it's about the whole community. If VFX Graph is entensible then the Asset Store and Github etc will quickly fill up with reusable components.

    I have a team of 1 but I would immediately benefit from the work of others if the VFX graph were to gain extensibility. So the sooner the better from this perspective!

    Your fear over breakage and backwards compatibility is genuine but it's not solved by delaying extensibility - it's solved by a clear release schedule, upgrade notes and predictable versioning.

    > once it's public it cannot be changed anymore

    Come on! A slight exaggeration?
     
    Last edited: May 13, 2020
    LooperVFX, o2co2 and qsleonard like this.
  5. valarnur

    valarnur

    Joined:
    Apr 7, 2019
    Posts:
    438
    Would it be possible to implement burst compiler with VFX graph for better performance?
     
  6. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    469
    VFX graph is using GPU compute shaders for simulation and i dont think that even bursted cpu particles can reach that level of performance(maybe they can if your cpu have 128 threads).
     
  7. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    569
    The roadmap tool would be a lot more useful if there was a way to see what's changed. Like a simple list of "card x was created", "card y was moved to state z".

    Every time I go back I need to read lots of cards and rely on my memory to get a sense of progress or spot shifts in priority.
     
    LooperVFX, DigitalChaotics and pahe like this.
  8. valarnur

    valarnur

    Joined:
    Apr 7, 2019
    Posts:
    438
    WIll VFG graph v10 have support for skined mesh renderer?
     
  9. VladVNeykov

    VladVNeykov

    Unity Technologies

    Joined:
    Sep 16, 2016
    Posts:
    550
    We expect the skinned mesh renderer sampling functionality to land in the 11.x package, so early in the 2021.1 cycle. Regular (non-skinned) mesh sampling is already available in 10.x
     
    valarnur likes this.
  10. valarnur

    valarnur

    Joined:
    Apr 7, 2019
    Posts:
    438
    Would it be possible to update samples package to latest SRP version?
     
  11. VladVNeykov

    VladVNeykov

    Unity Technologies

    Joined:
    Sep 16, 2016
    Posts:
    550
    Hi @valarus ,
    The VFX Samples repository? Yes, we have a few more samples to add and will update it to 10.x.
    I'm not sure when we'll get around to it, but it's on the to-do list :)

    p.s. Many of the effects should update fairly easily if you'd like to bring them to 10.x, with a possible exception of VFX using Shader Graph, which might have to be manually re-assigned. (the actual issue behind this has been fixed in latest)
     
    valarnur likes this.
  12. WangDL1902

    WangDL1902

    Joined:
    Jun 26, 2018
    Posts:
    2
    VFX shader graph does not support vertex offset
    I want to be able to add this feature
     
  13. Vita-

    Vita-

    Unity Technologies

    Joined:
    Jul 2, 2019
    Posts:
    121
    Hi, operations per vertex are available since 2021.2. You can do so by creating any HDRP or URP Shader Graph and enabling 'Support VFX Graph' in Graph Inspector. After that, in Shader Graph asset, new sub-asset pops up. Assign that sub-asset to VFX Graph and you are good to go.

    Also, I'd like to inform you that Visual Effect Target is deprecated and it is highly recommended to use HDRP/URP Shader Graph targets instead.
     
  14. WangDL1902

    WangDL1902

    Joined:
    Jun 26, 2018
    Posts:
    2
    thank your reply , i will check something
     
  15. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    Custom HLSL Block ,When will it be finished?
     
  16. Vita-

    Vita-

    Unity Technologies

    Joined:
    Jul 2, 2019
    Posts:
    121
    Hopefully, it's gonna be ready for 2023.2 release. Fingers crossed!
     
    LooperVFX and Julien-A like this.
  17. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    thank your reply ,But I don't see any branches on GITHUB.
     
  18. Vita-

    Vita-

    Unity Technologies

    Joined:
    Jul 2, 2019
    Posts:
    121
    It is on our internal repository,I don't think that those branches get mirrored to our public git:)
     
    LooperVFX likes this.
  19. LooperVFX

    LooperVFX

    Joined:
    Dec 3, 2018
    Posts:
    176
    :)
    Great news that this is in the works. Unreal Niagara VFX has been far ahead Unity VFX Graph in this and other kinds of extensibility for the past few years including volume simulation and particle neighbor search, while VFX graph has had its runtime locked in a black box of precompiled C++ with some unsupported custom HLSL generation possible but the mentioned simulation features not being possible within the graph context at all.

    That being said, Unity VFX Graph is generally regarded to have a superior unified user interface and user experience (UI/UX) workflows (perhaps contributing to the slower development cycles to "get the UX right") and I believe that will pay off in the long run.

    While Unreal Niagara VFX is feature laden, the UI/UX is fragmented and thrown together, with afterthought band-aids being slapped on to improve it (Kind of like what happened to Unity Shader Graph, it eventually fails to scale or meet expectations and then requires a complete UI/UX redesign and rebuild.)

    I know all graph tools are being moved to Graph Tools Foundation (GTF) but I think we all know VFX Graph has the more cohesive UI/UX (over Shader Graph) and is already closer in line with GTF conventions. "Shader Graph 2" (GTF based) seems to be more of a complete UI/UX rehaul. Even Shader graph 1 looks and works more like VFX graph than it did on launch (Shader graph now has master stacks and blocks that work like VFX context and blocks, the buggy swizzle node replaced with a port of VFX graph's swizzle node, etc.)

    (No disrespect to the Shader Graph team as the scope during the original development was order of magnitudes larger than that of VFX Graph. VFX Graph seems it was a more nimble greenfield project with very different, more focused goals, had far less cross team overlap / toe stepping and far fewer stakeholders peering in on it than Shader Graph had.)

    I'm trailing off a bit now, these derivative thoughts are of course only based on presumptions from my public 10,000ft view of how products are developed at Unity and other software companies in general.

    Keep up the great work, and we always appreciate the updates and insights. :)
     
    Julien-A, Marie_G, o2co2 and 5 others like this.
  20. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    The only tool that is expected to surpass UE5, Please invest more people. thank you :)
     
    Last edited: Mar 3, 2023
  21. peeweekVFX

    peeweekVFX

    Joined:
    Oct 19, 2015
    Posts:
    14
    I wanted to double down on what @JulienF_Unity was saying about the main audience of VFX Graph : artists. Right now i've spent one year in game production finally being able to stresstest VFXGraph on a real big project as a tech artist / TD, with two other junior artists.

    Even though chasing up Niagara's cutting/bleeding edge features could be seen as a next cool move for VFXGraph, I'm expecting more humble daily bread features that do not look as juicy, but would bring a lot of comprehensiveness and consistency : ensure that it is future-proof, artist-centric and most of all production ready (On some aspects, it is sadly, not... yet)

    It's a message I've been longing to post for some time, sorry for the wall o' text.

    My first opinion on the product board there are some cards that feel really underrated and I'd like to expand a bit more on these. I know that I'm only one among many but

    MOST WANTED : Graph Attributes
    https://portal.productboard.com/uni...ndering-visual-effects/c/121-graph-attributes

    This one is IMHO the most needed feature as it prevents building up an extra layer of (visual) scripting that communicates through the property interface as a workaround. General uses are "simulating a single value" that can be read by the graph (such as a dampened vector, a kill bool condition, etc). However, making it external to the graph, breaks the consistency of the behavior, as the VFX Graph is not autonomous anymore, and need to be bound to a prefab to stay functional.

    Sometimes I've got debate with other artists on why these graph attributes should be attributes and not animated exposed properties. My feeling is that it's a matter of responsibility, as these attributes could be handled by specific contexts, initialized, udpated and simulated over time, which feels consistent with simulated particles. On the contrary, animated exposed properties could be exposed to race conditions with the property interface, let alone that it would introduce a new paradigm on how to get/set these values (and when/where to get/set them).

    Profiling & Tooling
    https://portal.productboard.com/uni...dering-visual-effects/c/104-profiling-tooling

    In dire times of production, these tools lack a a lot, I mean... I'm missing them so much I often want to cry. I've been building some tools myself in my open-source package, as well as other internal tools while working in production, but the bare API is way too bare for (tech)artists to easily get something out of it. We've ramped up with the profiler core package which is a must. But it's still really difficult to get per-asset timings, counts and precise values (somehow, extra data is not conveyed).

    Particle count readback per-system is made every 60 frames so small bursts with quick lifetime get often off-recorded (because they can happen between two fetches), which makes tracking of many systems really difficult, and confusing.

    My feeling is that the lack of (artist-friendly) tooling induces from the artist side a sense of yolo and no way to actually tell if an effect is made efficiently or not. Maybe it's also because the underlying behavior is not visual enough or too complex for non-tech-artists, I am not really sure :/

    Regarding debugging when something goes wrong, it is nearly impossible to track a particle's attribute values, break on an initialize and inspect. I've relied on shenanigans to track problems (especially NaNs) in particles but it feels to me that I've regressed to the point i'm doing print debugging instead of having watches and breakpoints :) I'd really be glad to have API to dump internal buffers, to come up with some kind of attribute spreadsheets dump to CSV or anything like that.

    Finally, NOT on Roadmap (... why?) : EVENT PROCESS (Synchronous) Contexts

    The Direct link feature is really, really, a wonderful addition, greatly underrated, that helps a lot of programmers forge a single batch of init dispatches with different payloads in one go. .... But it's only where it ends currently.... as it relies only on C# to build an alternate system of event dispatches, leading in setting up multiple events... I mean... rewriting the Spawn system outside VFX Graph. As artists, we define one single event and we want it to trickle down to different systems, with different spawn counts, based on the initial event.

    Instead of a state machine such as spawn contexts that will start/stop asynchronously and emit a single spawnevent per frame, have a synchronous event process context, that processes *all* incoming events (either processed as a single one, or as a for loop based on spawncount), uses a bunch of event attribute blocks (for instance to compute a new spawn count based on the incoming spawn count)

    This would help making the wonderful DirectLink complete, and finally artist-centric, moving away a lot of behavior from C#, back into VFX.

    (I know .... this doesn't solve the multiple virtual instancing of spawn contexts though. but batching started tackling that one pretty neatly)


    ...

    Anyway, these are my top tier 3 features I'd long for, based on my recent experience in production and I think these would be more than welcome additions to help solve our biggest problems. Still, I'm really thankful for all the wonderful work from the team, VFX Graph is a wonderful tech and It amazes me every day how much we can push it beyond its limits to come up with crazy ideas. <3 <3 <3
     
    Vita-, Wattosan, florianBrn and 7 others like this.
  22. Qriva

    Qriva

    Joined:
    Jun 30, 2019
    Posts:
    1,291
    This!

    From the very beginning I really appreciated the fact it is often possible to create effect as single "black box". This should be one of key aspects of this tool. Obviously it's not bad to have public API and external scripts to extend functionality, but every feature that eliminates need of external stuff is good feature.
     
  23. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    unity 2023.2.0a7 It doesn't seem to see it?
     
  24. Vita-

    Vita-

    Unity Technologies

    Joined:
    Jul 2, 2019
    Posts:
    121
    It is not there yet, PR is in review :)
     
    LooperVFX and PaulDemeulenaere like this.
  25. LooperVFX

    LooperVFX

    Joined:
    Dec 3, 2018
    Posts:
    176
    Hi Vita,

    Thanks for this insight. Do you know if this PR is reflected on the public Unity Graphics repo on github? As I understand the public repo lags behind the internal working repo nowawadays, but it's been a few weeks and I'm still not finding it. It would be very helpful to have some further insight into this feature pre-release so our teams can plan our tool roadmaps accordingly. Thanks!
     
    o2co2 likes this.
  26. Vita-

    Vita-

    Unity Technologies

    Joined:
    Jul 2, 2019
    Posts:
    121
    Hi @landonth!

    To my knowledge, no, feature PRs are not reflected in the public Graphics repository. The pull requests that are merged into the mainline are mirrored in the public repository from the internal repository on a regular basis.

    Speaking of the feature, if I can provide any information to help with your roadmap planning - holler.
     
    LooperVFX likes this.
  27. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    unity 2023.2
    Can't Custom HLSL use RWStructuredBuffer?
     
    Last edited: Jun 20, 2023
  28. JulienF_Unity

    JulienF_Unity

    Unity Technologies

    Joined:
    Dec 17, 2015
    Posts:
    324
    Hi. You cannot declare RW buffer in VFX Graph at the moment. If you want to be able to write to some buffers from custom HLSL nodes, you have to use global buffers.
     
  29. Thut

    Thut

    Joined:
    Oct 30, 2014
    Posts:
    32
    Just updated to 2023.1.0f1 and was looking for the Output Volumetric Fog HDRP node, can't seem to find it. Was it supposed to be available in this version?
     
  30. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    Thank you for your reply, how to use global buffers? Can you give me a hint? Thanks


    Use Set Custom Attribute, use RWByteAddressBuffer attributeBuffer; but don't know how to get the address of Custom Attribute.

    RWByteAddressBuffer attributeBuffer; Is it possible to iterate over examples of neighboring particles?
     
    Last edited: Jun 21, 2023
  31. JulienF_Unity

    JulienF_Unity

    Unity Technologies

    Joined:
    Dec 17, 2015
    Posts:
    324
  32. JulienF_Unity

    JulienF_Unity

    Unity Technologies

    Joined:
    Dec 17, 2015
    Posts:
    324
    Use Set Custom Attribute, use RWByteAddressBuffer attributeBuffer; but don't know how to get the address of Custom Attribute.


    Custom attributes are not yet handled in HLSL nodes. You can read custom attributes by passing them as parameter but cannot write them in custom HLSL block. This is something that will be adressed in a subsequent PR that adds "attribute blackboard" and should land pretty soon.

    In custom HLSL we don't exposed particle buffers directly but have an interface to read and write attributes. So if you want to export attributes to use them in external computes for instance, you have to read them and store them in a global buffer then use it in your subsequent computes for instance.

    More info here: https://docs.unity3d.com/Packages/com.unity.visualeffectgraph@16.0/manual/Block-CustomHLSL.html
     
    LooperVFX likes this.
  33. JulienF_Unity

    JulienF_Unity

    Unity Technologies

    Joined:
    Dec 17, 2015
    Posts:
    324
    Is it possible to iterate over examples of neighboring particles?


    Not possible out of the box but this is doable with HLSL custom nodes (but has to be implemented manually). We'll release/post examples on how to achieve various things like this with new custom HLSL feature.
     
    LooperVFX likes this.
  34. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    Thank you. I'm looking forward to it.
     
  35. o2co2

    o2co2

    Joined:
    Aug 9, 2017
    Posts:
    45
    Do you have a rough schedule?